This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)


----------------------------------------
> CC: ebotcazou gcc-patches gingold rth joseph jay.krell
> From: mikestump
> To: palves
>
> On Jun 15, 2012, at 2:22 AM, Pedro Alves <palves@redhat.com> wrote:
> > It's not about example, but the fact that host compilers have been
> > compiling that code as part of building gcc for years, without anyone
> > complaining
>
> Yeah, I think we should just jump to c++ 11 and not look back... Fighting against using a 10 year old language standard I think is silly; and I like have the old obsolete ports in gcc.


64bit integer might not be called "long long", it could be "long" or "__int64", size_t/ptrdiff_t, etc..





I do find gcc's portability impressive, and one might suggest multiple precision arithmetic,

a pair of longs, but indeed compilers lacking some 64bit integer by some name are rare, and one could always

bootstrap via older gcc or take advantage of "biarch/multiarch" and first build "native 32bit"

and then "native 64bit" with the native 32bit gcc as the bootstrap compiler.



(I relatively recently bootstrapped hppa-hpux-gcc-4.x via K&R cc via gcc 3.x (3.3?). Obviously it is more time and work,
but it does work, and frees mainline gcc from caring.)


Heck, one could even automate this like how there is a multi-pass bootstrap, adding earlier stages
that go via e.g. gcc 3.3. The earlier compiler stages could be stripped down, e.g. no optimizer, no debug info output, no LTO.


?- Jay

 		 	   		  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]