----------------------------------------
> CC: ebotcazou gcc-patches gingold rth joseph jay.krell
> From: mikestump
> To: palves
>
> On Jun 15, 2012, at 2:22 AM, Pedro Alves <pal...@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
