diff mbox

[AArch64,ILP32] 5/5 Define _ILP32 and __ILP32__

Message ID 51CB6E64.7010105@arm.com
State New
Headers show

Commit Message

Yufeng Zhang June 26, 2013, 10:42 p.m. UTC
This patch defines _ILP32 and __ILP32__ for the AArch64 port when the 
ILP32 ABI is in use.

This helps libraries, e.g. libgloss and glibc, recognize which model is 
being compiled.

OK for the trunk?

Thanks,
Yufeng


gcc/
	* config/aarch64/aarch64.h (TARGET_CPU_CPP_BUILTINS): Define _ILP32
	and __ILP32__ when the ILP32 model is in use.

Comments

Joseph Myers June 27, 2013, 12:56 a.m. UTC | #1
On Wed, 26 Jun 2013, Yufeng Zhang wrote:

> This patch defines _ILP32 and __ILP32__ for the AArch64 port when the ILP32
> ABI is in use.
> 
> This helps libraries, e.g. libgloss and glibc, recognize which model is being
> compiled.

GCC already defines _LP64 and __LP64__ in architecture-independent code 
for LP64 systems.  Libraries can use those to distinguish the two models 
for AArch64, so I don't see any need to add architecture-specific macros 
with the opposite sense.
Yufeng Zhang June 27, 2013, 6:48 p.m. UTC | #2
On 06/27/13 01:56, Joseph S. Myers wrote:
> On Wed, 26 Jun 2013, Yufeng Zhang wrote:
>
>> This patch defines _ILP32 and __ILP32__ for the AArch64 port when the ILP32
>> ABI is in use.
>>
>> This helps libraries, e.g. libgloss and glibc, recognize which model is being
>> compiled.
>
> GCC already defines _LP64 and __LP64__ in architecture-independent code
> for LP64 systems.  Libraries can use those to distinguish the two models
> for AArch64, so I don't see any need to add architecture-specific macros
> with the opposite sense.

We need a reliable way to tell we are compiling for ILP32.  On one hand 
LLP64 support may be added in the future; on the other hand, not all 
AArch64 compilers may define _LP64 and __LP64__.

Other ports like x86_64, ia64-hpux and pa-hpux also define one or both.

Thanks,
Yufeng
Joseph Myers June 27, 2013, 7:28 p.m. UTC | #3
On Thu, 27 Jun 2013, Yufeng Zhang wrote:

> We need a reliable way to tell we are compiling for ILP32.  On one hand LLP64
> support may be added in the future; on the other hand, not all AArch64

If thinking of adding a third ABI, that suggests you should be using 
something along the lines of _MIPS_SIM - a macro that's always defined, 
with an integer value depending on the ABI in used.

> compilers may define _LP64 and __LP64__.

Why should all such compilers define the ILP32 macros, but not all define 
the LP64 macros?  Do you have an AArch64 equivalent of the ACLE that 
specifies such things?

> Other ports like x86_64, ia64-hpux and pa-hpux also define one or both.

If multiple ports define something, that might be an indication for 
defining it in target-independent code (like _LP64) rather than repeating 
it for more targets.  Although of course the macros __SIZEOF_INT__, 
__SIZEOF_LONG__, __SIZEOF_LONG_LONG__ and __SIZEOF_POINTER__ have been 
around for a long time, so new macros would just be for convenience (which 
may nevertheless be a sensible reason to define macros) at the expense of 
startup time.
Yufeng Zhang June 28, 2013, 5:46 p.m. UTC | #4
On 06/27/13 20:28, Joseph S. Myers wrote:
> On Thu, 27 Jun 2013, Yufeng Zhang wrote:
>
>> We need a reliable way to tell we are compiling for ILP32.  On one hand LLP64
>> support may be added in the future; on the other hand, not all AArch64
>
> If thinking of adding a third ABI, that suggests you should be using
> something along the lines of _MIPS_SIM - a macro that's always defined,
> with an integer value depending on the ABI in used.
>
>> compilers may define _LP64 and __LP64__.
>
> Why should all such compilers define the ILP32 macros, but not all define
> the LP64 macros?  Do you have an AArch64 equivalent of the ACLE that
> specifies such things?

There will be ACLE for AArch64 and it is in the view that both macros 
will be specified.

Since a few other ports that support ILP32 have already defined these 
macros, it shall help the code porting with them defined for AArch64 as 
well.

>> Other ports like x86_64, ia64-hpux and pa-hpux also define one or both.
>
> If multiple ports define something, that might be an indication for
> defining it in target-independent code (like _LP64) rather than repeating
> it for more targets.

I can propose a patch later to have _ILP32 and __ILP32__ defined in the 
target-independent code instead and see if the community like it?

Thanks,
Yufeng
Yufeng Zhang July 18, 2013, 10:32 a.m. UTC | #5
Ping~

Thanks,
Yufeng

On 06/26/13 23:42, Yufeng Zhang wrote:
> This patch defines _ILP32 and __ILP32__ for the AArch64 port when the
> ILP32 ABI is in use.
>
> This helps libraries, e.g. libgloss and glibc, recognize which model is
> being compiled.
>
> OK for the trunk?
>
> Thanks,
> Yufeng
>
>
> gcc/
> 	* config/aarch64/aarch64.h (TARGET_CPU_CPP_BUILTINS): Define _ILP32
> 	and __ILP32__ when the ILP32 model is in use.
Marcus Shawcroft July 19, 2013, 9:20 a.m. UTC | #6
On 26 June 2013 23:42, Yufeng Zhang <Yufeng.Zhang@arm.com> wrote:

> gcc/
>         * config/aarch64/aarch64.h (TARGET_CPU_CPP_BUILTINS): Define _ILP32
>         and __ILP32__ when the ILP32 model is in use.
>

OK
/Marcus
diff mbox

Patch

diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index d468dd8..e5dadb3 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -49,6 +49,11 @@ 
 	    break;					\
 	}						\
 							\
+      if (TARGET_ILP32)					\
+	{						\
+	  cpp_define (parse_in, "_ILP32");		\
+	  cpp_define (parse_in, "__ILP32__");		\
+	}						\
     } while (0)