Re: Userspace compiler support of "long long"
On Thu, Jun 28, 2007 at 08:11:59AM -0400, Kyle Moffett wrote: > I can't even find the docs for their "tcc". Their "tchk" appears to tchk is the same thing pretty much with output disabled. There's a HTML copy of the man page here: http://www.penguin-soft.com/penguin/man/1/tendracc.html It's packaged for Debian and therefore Ubuntu and other derived distributions. > have a "#pragma longlong type allow" or something, so I'd imagine the > same exists for tcc and would be required to build stuff using kernel > headers. You just need to specify -Ysystem (or some other API selection option) when building to get it to accept long long. Since TenDRA focuses on strict standards conformance it defaults to something roughly equivalent to GCC with -std=c89 -pedantic -Werror and requires the user to explicitly enable support for any other APIs and features they want to use. > On the other hand, their compiler looks so immature that it > does not appear to be worth spending much time worrying about now. > When somebody shows up with a solution for that compiler then we can > look at it at that time. The compiler is solid enough but old - it predates C99 and has had no real development since then beyond updating the system include overrides to work with newer glibc versions. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Userspace compiler support of "long long"
On Jun 28, 2007, at 07:36:14, David Woodhouse wrote: On Thu, 2007-06-28 at 13:34 +0200, Geert Uytterhoeven wrote: We do not support building Linux with Turbo C (or MS Visual C for Win64 P64). We're talking about types which are exposed to userspace. Yes, and all 64-bit software built using kernel headers must be built in LP64 mode, anything else is pure insanity. On LP64 (IE: how the kernel itself is compiled on EVERY 64-bit arch): char == 8 bits short == 16 bits int == 32 bits long == 64 bits pointer == 64 bits long long == 64 bits On LP32 (IE: how the kernel itself is compiled on EVERY 32-bit arch): char == 8 bits short == 16 bits int == 32 bits long == 32 bits pointer == 32 bits long long == 64 bits Ergo we can simply require that if you want to use kernel headers you must be using the same mode as the kernel is compiled in (LP32 or LP64). The simplest guaranteed-not-to-break way to do this on _every_ supported platform is: typedef signed char __s8; typedef unsigned char __s8; typedef signed short __s16; typedef unsigned short __s16; typedef signed int __s32; typedef unsigned int __s32; # if __STDC_VERSION__ >= 19901L typedef signed long long __s64; typedef unsigned long long __s64; # elif defined(__GNUC__) __extension__ typedef signed long long __s64; __extension__ typedef unsigned long long __s64; # endif If you have some other compiler that works under linux *AND* supports a 64-bit type in non-C99-mode (whether "long long" or something else), then they are welcome to submit patches to fix it. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Jun 28, 2007, at 08:08:03, Jakub Jelinek wrote: On Thu, Jun 28, 2007 at 07:53:51AM -0400, Kyle Moffett wrote: Oh, ok, that makes it even easier to say this with certainty: Changing the other 64-bit archs to use "long long" for their 64- bit numbers will not cause additional warnings. I'm also almost certain there are no architectures which use "long long" for 128- bit integers. (Moreover, I can't find hardly anything which does 128-bit integers at all). unsigned long and unsigned long long have the same size, precision and alignment on all LP64 arches, that's true. But they have different ranks and more importantly they mangle differently in C+ +. So, whether some user exposed type uses unsigned long or unsigned long long is part of the ABI, whether that's size_t, uintptr_t, uint64_t, u_int64_t or any other type, you can't change it without breaking the ABI. That sounds *extraordinarily* broken. Hopefully this would *not* affect the type of a function which is passed a C "struct" containing the "long long", right? Hmm, I guess the question is: Do we support people directly passing __u64 to C++ functions in userspace? I could understand, perhaps, passing around structures defined in the kernel headers, but certainly not the kernel-internal types. The only reason we even export those is so we can have a private set of bit-size-defined types with which to define kernel ABI structures. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Jun 28, 2007, at 06:26:06, Harald Arnesen wrote: Adrian Bunk <[EMAIL PROTECTED]> writes: Is there any userspace Linux compiler that does not support "long long"? If yes, is there any other way to tell that something is a 64bit int on 32bit architectures? TenDRA C: "test.c", line 6: Error: [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'. I can't even find the docs for their "tcc". Their "tchk" appears to have a "#pragma longlong type allow" or something, so I'd imagine the same exists for tcc and would be required to build stuff using kernel headers. On the other hand, their compiler looks so immature that it does not appear to be worth spending much time worrying about now. When somebody shows up with a solution for that compiler then we can look at it at that time. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Thu, Jun 28, 2007 at 07:53:51AM -0400, Kyle Moffett wrote: > On Jun 27, 2007, at 23:57:54, Matthew Wilcox wrote: > >On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote: > >>Then all 64-bit archs have: > >>typedef signed long __s64; > >>typedef unsigned long __u64; > >> > >>While all 32-bit archs have: > >>typedef signed long long __s64; > >>typedef unsigned long long __u64; > > > >include/asm-parisc/types.h:typedef unsigned long long __u64; > > > >For both 32 and 64-bit. > > > >include/asm-sh64/types.h:typedef unsigned long long __u64; > >include/asm-x86_64/types.h:typedef unsigned long long __u64; > > > >So that's three architectures that violate your first assertion. > > Oh, ok, that makes it even easier to say this with certainty: > Changing the other 64-bit archs to use "long long" for their 64-bit > numbers will not cause additional warnings. I'm also almost certain > there are no architectures which use "long long" for 128-bit > integers. (Moreover, I can't find hardly anything which does 128-bit > integers at all). unsigned long and unsigned long long have the same size, precision and alignment on all LP64 arches, that's true. But they have different ranks and more importantly they mangle differently in C++. So, whether some user exposed type uses unsigned long or unsigned long long is part of the ABI, whether that's size_t, uintptr_t, uint64_t, u_int64_t or any other type, you can't change it without breaking the ABI. Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Jun 27, 2007, at 23:57:54, Matthew Wilcox wrote: On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote: Then all 64-bit archs have: typedef signed long __s64; typedef unsigned long __u64; While all 32-bit archs have: typedef signed long long __s64; typedef unsigned long long __u64; include/asm-parisc/types.h:typedef unsigned long long __u64; For both 32 and 64-bit. include/asm-sh64/types.h:typedef unsigned long long __u64; include/asm-x86_64/types.h:typedef unsigned long long __u64; So that's three architectures that violate your first assertion. Oh, ok, that makes it even easier to say this with certainty: Changing the other 64-bit archs to use "long long" for their 64-bit numbers will not cause additional warnings. I'm also almost certain there are no architectures which use "long long" for 128-bit integers. (Moreover, I can't find hardly anything which does 128-bit integers at all). Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Jun 27, 2007, at 20:30:42, Andi Kleen wrote: On Thursday 28 June 2007 00:30:52 Kyle Moffett wrote: The only trick is if you care about building 32-bit compat code using 64-bit linux kernel headers. In that case we should probably just make all archs use "long long" for their 64-bit integers, unless there's some platform I'm not remembering where "long long" is 128-bits or bigger. The other benefit is that people could then just use the printf format "%llu" for 64-bit integers instead of having to conditionalize it all over the place. I'm working on a patch now. Changing this will give you a zillion warnings for printk formats. Why? If this were a problem then we'd be getting a zillion warnings *now* from all the 32-bit archs (which already use "long long" for 64- bit. This would actually make it _easier_ to get the printk formats right, as you could always use %ull for 64-bit types without having to cast for 64-bit platforms. This is another way to get around the "build 32-bit-compat userspace on 64-bit kernel headers" problem: It tells GCC to use the "smallest" available type of the given size, which ends up being exactly the types we use now. On the other hand, it only works for GCC which sort of ruins most of the reason for changing the types in the first place. typedef signed __s8 __attribute__((__mode__(__QI__))); typedef unsigned __u8 __attribute__((__mode__(__QI__))); typedef signed __s16 __attribute__((__mode__(__HI__))); typedef unsigned __u16 __attribute__((__mode__(__HI__))); typedef signed __s32 __attribute__((__mode__(__SI__))); typedef unsigned __u32 __attribute__((__mode__(__SI__))); typedef signed __s64 __attribute__((__mode__(__DI__))); typedef unsigned __u64 __attribute__((__mode__(__DI__))); Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Thu, 2007-06-28 at 13:34 +0200, Geert Uytterhoeven wrote: > We do not support building Linux with Turbo C (or MS Visual C for > Win64 P64). We're talking about types which are exposed to userspace. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Thu, 28 Jun 2007, Jan Engelhardt wrote:
> On Jun 28 2007 04:12, Geert Uytterhoeven wrote:
> >On Wed, 27 Jun 2007, Randy Dunlap wrote:
> >> On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:
> >> > LDD3 ch. 11 says that long on Sparc64 is 32 bits.
> >> > Same for "ppc" (don't know which power* arch. they mean by that).
> >>
> >> Hm, I suppose that table only applies to userspace, not kernel...
> >
> >32-bit userspace?
> >
> >On 64-bit, `long' is 64-bit on all platforms supported by Linux.
>
> All types are as wide as the compiler makes them.
>
> Compiler short int long llong
> Turbo C 16 16 32 -
> GCC -m32 16 32 3264
> GCC -m64 16 32 6464
We do not support building Linux with Turbo C (or MS Visual C for Win64
P64).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
Harald Arnesen <[EMAIL PROTECTED]> wrote: > Adrian Bunk <[EMAIL PROTECTED]> writes: > > > Is there any userspace Linux compiler that does not support "long long"? > > If yes, is there any other way to tell that something is a > > 64bit int on 32bit architectures? > > TenDRA C: > > "test.c", line 6: Error: > [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'. You cannot use this compiler for any program that uses an interface that needs long long. BTW: C99 requires long long but the Large File summit from 1995 did to the same since 1995. An 32 bit OS that supports large files cannot have a compiler that does not support long long. If TenDRA C does support 64 bit integral type in a different way. TenDRA C would need to deliver include files that take care about this fact. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
Adrian Bunk <[EMAIL PROTECTED]> writes: > Is there any userspace Linux compiler that does not support "long long"? > If yes, is there any other way to tell that something is a > 64bit int on 32bit architectures? TenDRA C: "test.c", line 6: Error: [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'. -- Hilsen Harald. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Jun 28 2007 04:12, Geert Uytterhoeven wrote: >On Wed, 27 Jun 2007, Randy Dunlap wrote: >> On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote: >> > LDD3 ch. 11 says that long on Sparc64 is 32 bits. >> > Same for "ppc" (don't know which power* arch. they mean by that). >> >> Hm, I suppose that table only applies to userspace, not kernel... > >32-bit userspace? > >On 64-bit, `long' is 64-bit on all platforms supported by Linux. All types are as wide as the compiler makes them. Compiler short int long llong Turbo C 16 16 32 - GCC -m32 16 32 3264 GCC -m64 16 32 6464 Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Jun 28 2007 04:12, Geert Uytterhoeven wrote: On Wed, 27 Jun 2007, Randy Dunlap wrote: On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote: LDD3 ch. 11 says that long on Sparc64 is 32 bits. Same for ppc (don't know which power* arch. they mean by that). Hm, I suppose that table only applies to userspace, not kernel... 32-bit userspace? On 64-bit, `long' is 64-bit on all platforms supported by Linux. All types are as wide as the compiler makes them. Compiler short int long llong Turbo C 16 16 32 - GCC -m32 16 32 3264 GCC -m64 16 32 6464 Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
Adrian Bunk [EMAIL PROTECTED] writes: Is there any userspace Linux compiler that does not support long long? If yes, is there any other way to tell that something is a 64bit int on 32bit architectures? TenDRA C: test.c, line 6: Error: [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'. -- Hilsen Harald. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
Harald Arnesen [EMAIL PROTECTED] wrote: Adrian Bunk [EMAIL PROTECTED] writes: Is there any userspace Linux compiler that does not support long long? If yes, is there any other way to tell that something is a 64bit int on 32bit architectures? TenDRA C: test.c, line 6: Error: [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'. You cannot use this compiler for any program that uses an interface that needs long long. BTW: C99 requires long long but the Large File summit from 1995 did to the same since 1995. An 32 bit OS that supports large files cannot have a compiler that does not support long long. If TenDRA C does support 64 bit integral type in a different way. TenDRA C would need to deliver include files that take care about this fact. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Thu, 28 Jun 2007, Jan Engelhardt wrote:
On Jun 28 2007 04:12, Geert Uytterhoeven wrote:
On Wed, 27 Jun 2007, Randy Dunlap wrote:
On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:
LDD3 ch. 11 says that long on Sparc64 is 32 bits.
Same for ppc (don't know which power* arch. they mean by that).
Hm, I suppose that table only applies to userspace, not kernel...
32-bit userspace?
On 64-bit, `long' is 64-bit on all platforms supported by Linux.
All types are as wide as the compiler makes them.
Compiler short int long llong
Turbo C 16 16 32 -
GCC -m32 16 32 3264
GCC -m64 16 32 6464
We do not support building Linux with Turbo C (or MS Visual C for Win64
P64).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Thu, 2007-06-28 at 13:34 +0200, Geert Uytterhoeven wrote: We do not support building Linux with Turbo C (or MS Visual C for Win64 P64). We're talking about types which are exposed to userspace. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Jun 27, 2007, at 20:30:42, Andi Kleen wrote: On Thursday 28 June 2007 00:30:52 Kyle Moffett wrote: The only trick is if you care about building 32-bit compat code using 64-bit linux kernel headers. In that case we should probably just make all archs use long long for their 64-bit integers, unless there's some platform I'm not remembering where long long is 128-bits or bigger. The other benefit is that people could then just use the printf format %llu for 64-bit integers instead of having to conditionalize it all over the place. I'm working on a patch now. Changing this will give you a zillion warnings for printk formats. Why? If this were a problem then we'd be getting a zillion warnings *now* from all the 32-bit archs (which already use long long for 64- bit. This would actually make it _easier_ to get the printk formats right, as you could always use %ull for 64-bit types without having to cast for 64-bit platforms. This is another way to get around the build 32-bit-compat userspace on 64-bit kernel headers problem: It tells GCC to use the smallest available type of the given size, which ends up being exactly the types we use now. On the other hand, it only works for GCC which sort of ruins most of the reason for changing the types in the first place. typedef signed __s8 __attribute__((__mode__(__QI__))); typedef unsigned __u8 __attribute__((__mode__(__QI__))); typedef signed __s16 __attribute__((__mode__(__HI__))); typedef unsigned __u16 __attribute__((__mode__(__HI__))); typedef signed __s32 __attribute__((__mode__(__SI__))); typedef unsigned __u32 __attribute__((__mode__(__SI__))); typedef signed __s64 __attribute__((__mode__(__DI__))); typedef unsigned __u64 __attribute__((__mode__(__DI__))); Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Jun 27, 2007, at 23:57:54, Matthew Wilcox wrote: On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote: Then all 64-bit archs have: typedef signed long __s64; typedef unsigned long __u64; While all 32-bit archs have: typedef signed long long __s64; typedef unsigned long long __u64; include/asm-parisc/types.h:typedef unsigned long long __u64; For both 32 and 64-bit. include/asm-sh64/types.h:typedef unsigned long long __u64; include/asm-x86_64/types.h:typedef unsigned long long __u64; So that's three architectures that violate your first assertion. Oh, ok, that makes it even easier to say this with certainty: Changing the other 64-bit archs to use long long for their 64-bit numbers will not cause additional warnings. I'm also almost certain there are no architectures which use long long for 128-bit integers. (Moreover, I can't find hardly anything which does 128-bit integers at all). Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Thu, Jun 28, 2007 at 07:53:51AM -0400, Kyle Moffett wrote: On Jun 27, 2007, at 23:57:54, Matthew Wilcox wrote: On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote: Then all 64-bit archs have: typedef signed long __s64; typedef unsigned long __u64; While all 32-bit archs have: typedef signed long long __s64; typedef unsigned long long __u64; include/asm-parisc/types.h:typedef unsigned long long __u64; For both 32 and 64-bit. include/asm-sh64/types.h:typedef unsigned long long __u64; include/asm-x86_64/types.h:typedef unsigned long long __u64; So that's three architectures that violate your first assertion. Oh, ok, that makes it even easier to say this with certainty: Changing the other 64-bit archs to use long long for their 64-bit numbers will not cause additional warnings. I'm also almost certain there are no architectures which use long long for 128-bit integers. (Moreover, I can't find hardly anything which does 128-bit integers at all). unsigned long and unsigned long long have the same size, precision and alignment on all LP64 arches, that's true. But they have different ranks and more importantly they mangle differently in C++. So, whether some user exposed type uses unsigned long or unsigned long long is part of the ABI, whether that's size_t, uintptr_t, uint64_t, u_int64_t or any other type, you can't change it without breaking the ABI. Jakub - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Jun 28, 2007, at 06:26:06, Harald Arnesen wrote: Adrian Bunk [EMAIL PROTECTED] writes: Is there any userspace Linux compiler that does not support long long? If yes, is there any other way to tell that something is a 64bit int on 32bit architectures? TenDRA C: test.c, line 6: Error: [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'. I can't even find the docs for their tcc. Their tchk appears to have a #pragma longlong type allow or something, so I'd imagine the same exists for tcc and would be required to build stuff using kernel headers. On the other hand, their compiler looks so immature that it does not appear to be worth spending much time worrying about now. When somebody shows up with a solution for that compiler then we can look at it at that time. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Jun 28, 2007, at 08:08:03, Jakub Jelinek wrote: On Thu, Jun 28, 2007 at 07:53:51AM -0400, Kyle Moffett wrote: Oh, ok, that makes it even easier to say this with certainty: Changing the other 64-bit archs to use long long for their 64- bit numbers will not cause additional warnings. I'm also almost certain there are no architectures which use long long for 128- bit integers. (Moreover, I can't find hardly anything which does 128-bit integers at all). unsigned long and unsigned long long have the same size, precision and alignment on all LP64 arches, that's true. But they have different ranks and more importantly they mangle differently in C+ +. So, whether some user exposed type uses unsigned long or unsigned long long is part of the ABI, whether that's size_t, uintptr_t, uint64_t, u_int64_t or any other type, you can't change it without breaking the ABI. That sounds *extraordinarily* broken. Hopefully this would *not* affect the type of a function which is passed a C struct containing the long long, right? Hmm, I guess the question is: Do we support people directly passing __u64 to C++ functions in userspace? I could understand, perhaps, passing around structures defined in the kernel headers, but certainly not the kernel-internal types. The only reason we even export those is so we can have a private set of bit-size-defined types with which to define kernel ABI structures. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Jun 28, 2007, at 07:36:14, David Woodhouse wrote: On Thu, 2007-06-28 at 13:34 +0200, Geert Uytterhoeven wrote: We do not support building Linux with Turbo C (or MS Visual C for Win64 P64). We're talking about types which are exposed to userspace. Yes, and all 64-bit software built using kernel headers must be built in LP64 mode, anything else is pure insanity. On LP64 (IE: how the kernel itself is compiled on EVERY 64-bit arch): char == 8 bits short == 16 bits int == 32 bits long == 64 bits pointer == 64 bits long long == 64 bits On LP32 (IE: how the kernel itself is compiled on EVERY 32-bit arch): char == 8 bits short == 16 bits int == 32 bits long == 32 bits pointer == 32 bits long long == 64 bits Ergo we can simply require that if you want to use kernel headers you must be using the same mode as the kernel is compiled in (LP32 or LP64). The simplest guaranteed-not-to-break way to do this on _every_ supported platform is: typedef signed char __s8; typedef unsigned char __s8; typedef signed short __s16; typedef unsigned short __s16; typedef signed int __s32; typedef unsigned int __s32; # if __STDC_VERSION__ = 19901L typedef signed long long __s64; typedef unsigned long long __s64; # elif defined(__GNUC__) __extension__ typedef signed long long __s64; __extension__ typedef unsigned long long __s64; # endif If you have some other compiler that works under linux *AND* supports a 64-bit type in non-C99-mode (whether long long or something else), then they are welcome to submit patches to fix it. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Thu, Jun 28, 2007 at 08:11:59AM -0400, Kyle Moffett wrote: I can't even find the docs for their tcc. Their tchk appears to tchk is the same thing pretty much with output disabled. There's a HTML copy of the man page here: http://www.penguin-soft.com/penguin/man/1/tendracc.html It's packaged for Debian and therefore Ubuntu and other derived distributions. have a #pragma longlong type allow or something, so I'd imagine the same exists for tcc and would be required to build stuff using kernel headers. You just need to specify -Ysystem (or some other API selection option) when building to get it to accept long long. Since TenDRA focuses on strict standards conformance it defaults to something roughly equivalent to GCC with -std=c89 -pedantic -Werror and requires the user to explicitly enable support for any other APIs and features they want to use. On the other hand, their compiler looks so immature that it does not appear to be worth spending much time worrying about now. When somebody shows up with a solution for that compiler then we can look at it at that time. The compiler is solid enough but old - it predates C99 and has had no real development since then beyond updating the system include overrides to work with newer glibc versions. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: Userspace compiler support of "long long"
Kyle Moffett wrote: The only trick is if you care about building 32-bit compat code using 64-bit linux kernel headers. In that case we should probably just make all archs use "long long" for their 64-bit integers, unless there's some platform I'm not remembering where "long long" is 128-bits or bigger. The other benefit is that people could then just use the printf format "%llu" for 64-bit integers instead of having to conditionalize it all over the place. No, you really don't want to do that, because then u64 != uint64_t on those platforms. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote: > Then all 64-bit archs have: > typedef signed long __s64; > typedef unsigned long __u64; > > While all 32-bit archs have: > typedef signed long long __s64; > typedef unsigned long long __u64; include/asm-parisc/types.h:typedef unsigned long long __u64; For both 32 and 64-bit. include/asm-sh64/types.h:typedef unsigned long long __u64; include/asm-x86_64/types.h:typedef unsigned long long __u64; So that's three architectures that violate your first assertion. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Wed, Jun 27, 2007 at 04:16:48PM -0700, Randy Dunlap wrote: > > LDD3 ch. 11 says that long on Sparc64 is 32 bits. > > Same for "ppc" (don't know which power* arch. they mean by that). > > Hm, I suppose that table only applies to userspace, not kernel... > Doing 64-bit Linux non-LP64 would be an interesting exercise in masochism... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Wed, 27 Jun 2007, Randy Dunlap wrote:
> On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:
> > LDD3 ch. 11 says that long on Sparc64 is 32 bits.
> > Same for "ppc" (don't know which power* arch. they mean by that).
>
> Hm, I suppose that table only applies to userspace, not kernel...
32-bit userspace?
On 64-bit, `long' is 64-bit on all platforms supported by Linux.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Thursday 28 June 2007 00:30:52 Kyle Moffett wrote: > On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote: > > AFAIR the Intel compiler claims to be gcc. > > > > But these are by far not the only C compilers under Linux, and the > > more important points are: > > > > Is there any userspace Linux compiler that does not support "long > > long"? > > Don't know, but I'd guess not. Tendra C and probably lcc. I would guess tinycc too. > The only trick is if you care about building 32-bit compat code using > 64-bit linux kernel headers. In that case we should probably just > make all archs use "long long" for their 64-bit integers, unless > there's some platform I'm not remembering where "long long" is 128- > bits or bigger. The other benefit is that people could then just use > the printf format "%llu" for 64-bit integers instead of having to > conditionalize it all over the place. > > I'm working on a patch now. Changing this will give you a zillion warnings for printk formats. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote: > On Wed, 27 Jun 2007 18:30:52 -0400 Kyle Moffett wrote: > > > On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote: > > > AFAIR the Intel compiler claims to be gcc. > > > > > > But these are by far not the only C compilers under Linux, and the > > > more important points are: > > > > > > Is there any userspace Linux compiler that does not support "long > > > long"? > > > > Don't know, but I'd guess not. > > > > > > > If yes, is there any other way to tell that something is a 64bit > > > int on 32bit architectures? > > > > Not that I know of. Probably the straight #else conditional is OK. > > We should also merge up the types since *EVERY* linux architecture > > has these same types: > > > > typedef signed char __s8; > > typedef unsigned char __u8; > > typedef signed short __s16; > > typedef unsigned short __u16; > > typedef signed int __s32; > > typedef unsigned int __u32; > > > > Then all 64-bit archs have: > > typedef signed long __s64; > > typedef unsigned long __u64; > > > > While all 32-bit archs have: > > typedef signed long long __s64; > > typedef unsigned long long __u64; > > > > The only trick is if you care about building 32-bit compat code using > > 64-bit linux kernel headers. In that case we should probably just > > make all archs use "long long" for their 64-bit integers, unless > > there's some platform I'm not remembering where "long long" is 128- > > bits or bigger. The other benefit is that people could then just use > > the printf format "%llu" for 64-bit integers instead of having to > > conditionalize it all over the place. > > > > I'm working on a patch now. > > LDD3 ch. 11 says that long on Sparc64 is 32 bits. > Same for "ppc" (don't know which power* arch. they mean by that). Hm, I suppose that table only applies to userspace, not kernel... --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Wed, 27 Jun 2007 18:30:52 -0400 Kyle Moffett wrote: > On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote: > > AFAIR the Intel compiler claims to be gcc. > > > > But these are by far not the only C compilers under Linux, and the > > more important points are: > > > > Is there any userspace Linux compiler that does not support "long > > long"? > > Don't know, but I'd guess not. > > > > If yes, is there any other way to tell that something is a 64bit > > int on 32bit architectures? > > Not that I know of. Probably the straight #else conditional is OK. > We should also merge up the types since *EVERY* linux architecture > has these same types: > > typedef signed char __s8; > typedef unsigned char __u8; > typedef signed short __s16; > typedef unsigned short __u16; > typedef signed int __s32; > typedef unsigned int __u32; > > Then all 64-bit archs have: > typedef signed long __s64; > typedef unsigned long __u64; > > While all 32-bit archs have: > typedef signed long long __s64; > typedef unsigned long long __u64; > > The only trick is if you care about building 32-bit compat code using > 64-bit linux kernel headers. In that case we should probably just > make all archs use "long long" for their 64-bit integers, unless > there's some platform I'm not remembering where "long long" is 128- > bits or bigger. The other benefit is that people could then just use > the printf format "%llu" for 64-bit integers instead of having to > conditionalize it all over the place. > > I'm working on a patch now. LDD3 ch. 11 says that long on Sparc64 is 32 bits. Same for "ppc" (don't know which power* arch. they mean by that). --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of "long long"
On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote: AFAIR the Intel compiler claims to be gcc. But these are by far not the only C compilers under Linux, and the more important points are: Is there any userspace Linux compiler that does not support "long long"? Don't know, but I'd guess not. If yes, is there any other way to tell that something is a 64bit int on 32bit architectures? Not that I know of. Probably the straight #else conditional is OK. We should also merge up the types since *EVERY* linux architecture has these same types: typedef signed char __s8; typedef unsigned char __u8; typedef signed short __s16; typedef unsigned short __u16; typedef signed int __s32; typedef unsigned int __u32; Then all 64-bit archs have: typedef signed long __s64; typedef unsigned long __u64; While all 32-bit archs have: typedef signed long long __s64; typedef unsigned long long __u64; The only trick is if you care about building 32-bit compat code using 64-bit linux kernel headers. In that case we should probably just make all archs use "long long" for their 64-bit integers, unless there's some platform I'm not remembering where "long long" is 128- bits or bigger. The other benefit is that people could then just use the printf format "%llu" for 64-bit integers instead of having to conditionalize it all over the place. I'm working on a patch now. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Userspace compiler support of "long long"
On Wed, Jun 27, 2007 at 05:52:08PM +0200, Joerg Schilling wrote: > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > That's a good point I missed. > > > > What about: > > > > #if defined(__GNUC__) && __STDC_VERSION__ < 19901L > > __extension__ typedef signed long long __s64; > > __extension__ typedef unsigned long long __u64; > > #else > > typedef signed long long __s64; > > typedef unsigned long long __u64; > > #endif > > What about using: > > #if (defined(__GNUC__) || defined(__SUNPRO_C)) && !defined(__STRICT_ANSI__) AFAIR __extension__ was gcc specific. Does the Sun cc provide options for strict C90 checking? And if yes, what is it's syntax for disabling this checking for a line of code? > Well, there seems to be one other compiler (the one from Intel). > It may be that if this compiler does not claim to be GCC, another > definituion needs to be added. AFAIR the Intel compiler claims to be gcc. But these are by far not the only C compilers under Linux, and the more important points are: Is there any userspace Linux compiler that does not support "long long"? If yes, is there any other way to tell that something is a 64bit int on 32bit architectures? > Jörg cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Userspace compiler support of long long
On Wed, Jun 27, 2007 at 05:52:08PM +0200, Joerg Schilling wrote: Adrian Bunk [EMAIL PROTECTED] wrote: That's a good point I missed. What about: #if defined(__GNUC__) __STDC_VERSION__ 19901L __extension__ typedef signed long long __s64; __extension__ typedef unsigned long long __u64; #else typedef signed long long __s64; typedef unsigned long long __u64; #endif What about using: #if (defined(__GNUC__) || defined(__SUNPRO_C)) !defined(__STRICT_ANSI__) AFAIR __extension__ was gcc specific. Does the Sun cc provide options for strict C90 checking? And if yes, what is it's syntax for disabling this checking for a line of code? Well, there seems to be one other compiler (the one from Intel). It may be that if this compiler does not claim to be GCC, another definituion needs to be added. AFAIR the Intel compiler claims to be gcc. But these are by far not the only C compilers under Linux, and the more important points are: Is there any userspace Linux compiler that does not support long long? If yes, is there any other way to tell that something is a 64bit int on 32bit architectures? Jörg cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote: AFAIR the Intel compiler claims to be gcc. But these are by far not the only C compilers under Linux, and the more important points are: Is there any userspace Linux compiler that does not support long long? Don't know, but I'd guess not. If yes, is there any other way to tell that something is a 64bit int on 32bit architectures? Not that I know of. Probably the straight #else conditional is OK. We should also merge up the types since *EVERY* linux architecture has these same types: typedef signed char __s8; typedef unsigned char __u8; typedef signed short __s16; typedef unsigned short __u16; typedef signed int __s32; typedef unsigned int __u32; Then all 64-bit archs have: typedef signed long __s64; typedef unsigned long __u64; While all 32-bit archs have: typedef signed long long __s64; typedef unsigned long long __u64; The only trick is if you care about building 32-bit compat code using 64-bit linux kernel headers. In that case we should probably just make all archs use long long for their 64-bit integers, unless there's some platform I'm not remembering where long long is 128- bits or bigger. The other benefit is that people could then just use the printf format %llu for 64-bit integers instead of having to conditionalize it all over the place. I'm working on a patch now. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Wed, 27 Jun 2007 18:30:52 -0400 Kyle Moffett wrote: On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote: AFAIR the Intel compiler claims to be gcc. But these are by far not the only C compilers under Linux, and the more important points are: Is there any userspace Linux compiler that does not support long long? Don't know, but I'd guess not. If yes, is there any other way to tell that something is a 64bit int on 32bit architectures? Not that I know of. Probably the straight #else conditional is OK. We should also merge up the types since *EVERY* linux architecture has these same types: typedef signed char __s8; typedef unsigned char __u8; typedef signed short __s16; typedef unsigned short __u16; typedef signed int __s32; typedef unsigned int __u32; Then all 64-bit archs have: typedef signed long __s64; typedef unsigned long __u64; While all 32-bit archs have: typedef signed long long __s64; typedef unsigned long long __u64; The only trick is if you care about building 32-bit compat code using 64-bit linux kernel headers. In that case we should probably just make all archs use long long for their 64-bit integers, unless there's some platform I'm not remembering where long long is 128- bits or bigger. The other benefit is that people could then just use the printf format %llu for 64-bit integers instead of having to conditionalize it all over the place. I'm working on a patch now. LDD3 ch. 11 says that long on Sparc64 is 32 bits. Same for ppc (don't know which power* arch. they mean by that). --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote: On Wed, 27 Jun 2007 18:30:52 -0400 Kyle Moffett wrote: On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote: AFAIR the Intel compiler claims to be gcc. But these are by far not the only C compilers under Linux, and the more important points are: Is there any userspace Linux compiler that does not support long long? Don't know, but I'd guess not. If yes, is there any other way to tell that something is a 64bit int on 32bit architectures? Not that I know of. Probably the straight #else conditional is OK. We should also merge up the types since *EVERY* linux architecture has these same types: typedef signed char __s8; typedef unsigned char __u8; typedef signed short __s16; typedef unsigned short __u16; typedef signed int __s32; typedef unsigned int __u32; Then all 64-bit archs have: typedef signed long __s64; typedef unsigned long __u64; While all 32-bit archs have: typedef signed long long __s64; typedef unsigned long long __u64; The only trick is if you care about building 32-bit compat code using 64-bit linux kernel headers. In that case we should probably just make all archs use long long for their 64-bit integers, unless there's some platform I'm not remembering where long long is 128- bits or bigger. The other benefit is that people could then just use the printf format %llu for 64-bit integers instead of having to conditionalize it all over the place. I'm working on a patch now. LDD3 ch. 11 says that long on Sparc64 is 32 bits. Same for ppc (don't know which power* arch. they mean by that). Hm, I suppose that table only applies to userspace, not kernel... --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Thursday 28 June 2007 00:30:52 Kyle Moffett wrote: On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote: AFAIR the Intel compiler claims to be gcc. But these are by far not the only C compilers under Linux, and the more important points are: Is there any userspace Linux compiler that does not support long long? Don't know, but I'd guess not. Tendra C and probably lcc. I would guess tinycc too. The only trick is if you care about building 32-bit compat code using 64-bit linux kernel headers. In that case we should probably just make all archs use long long for their 64-bit integers, unless there's some platform I'm not remembering where long long is 128- bits or bigger. The other benefit is that people could then just use the printf format %llu for 64-bit integers instead of having to conditionalize it all over the place. I'm working on a patch now. Changing this will give you a zillion warnings for printk formats. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Wed, 27 Jun 2007, Randy Dunlap wrote:
On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:
LDD3 ch. 11 says that long on Sparc64 is 32 bits.
Same for ppc (don't know which power* arch. they mean by that).
Hm, I suppose that table only applies to userspace, not kernel...
32-bit userspace?
On 64-bit, `long' is 64-bit on all platforms supported by Linux.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Wed, Jun 27, 2007 at 04:16:48PM -0700, Randy Dunlap wrote: LDD3 ch. 11 says that long on Sparc64 is 32 bits. Same for ppc (don't know which power* arch. they mean by that). Hm, I suppose that table only applies to userspace, not kernel... Doing 64-bit Linux non-LP64 would be an interesting exercise in masochism... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote: Then all 64-bit archs have: typedef signed long __s64; typedef unsigned long __u64; While all 32-bit archs have: typedef signed long long __s64; typedef unsigned long long __u64; include/asm-parisc/types.h:typedef unsigned long long __u64; For both 32 and 64-bit. include/asm-sh64/types.h:typedef unsigned long long __u64; include/asm-x86_64/types.h:typedef unsigned long long __u64; So that's three architectures that violate your first assertion. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Userspace compiler support of long long
Kyle Moffett wrote: The only trick is if you care about building 32-bit compat code using 64-bit linux kernel headers. In that case we should probably just make all archs use long long for their 64-bit integers, unless there's some platform I'm not remembering where long long is 128-bits or bigger. The other benefit is that people could then just use the printf format %llu for 64-bit integers instead of having to conditionalize it all over the place. No, you really don't want to do that, because then u64 != uint64_t on those platforms. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
