[4.5/Ada] Fix build with 4.6 compiler

Arno, do you have objections to me applying the attached patch to the 4.5 
branch?  It makes it possible to build (and bootstrap) the Ada compiler on the 
4.5 branch (oldest supported branch) with the 4.6 compiler, which is now the 
system compiler in recent Linux distributions.

The patch backports minor fixes from the 4.6 branch.  The only potentially 
controversial thing is the preprocessor trick in init.c, which arranges for 
the new symbol __gl_main_cpu not to be added to the runtime.

Bootstrapped/regtested with 4.3 and 4.6 compilers on x86 and x86-64/Linux.


2012-04-04  Eric Botcazou  <ebotcazou@adacore.com>

	Backport from 4.6 branch
	* init.c (__gl_main_cpu): New global variable.
	* par-ch3.adb: Remove a couple of blank lines.
	* types.ads (Big_String_Ptr): Don't give it zero storage size.
	(Source_Buffer_Ptr): Likewise.
	* uintp.adb (Hash_Num): Use "mod" operator from Types.

On Wed, Apr 04, 2012 at 09:36:52AM +0200, Eric Botcazou wrote:
> --- init.c	(revision 186078)
> +++ init.c	(working copy)
> @@ -86,6 +86,9 @@
>  
>  /* Global values computed by the binder.  */
>  int   __gl_main_priority                 = -1;
> +#if (__GNUC__ * 10 + __GNUC_MINOR__ > 45)

Shouldn't this be * 100 and > 405 ?  I mean, we already had GCC
2.95, 2.96, 2.97 and 20 + 95 is > 45...

	Jakub

> Arno, do you have objections to me applying the attached patch to the 4.5
> branch?  It makes it possible to build (and bootstrap) the Ada compiler on the
> 4.5 branch (oldest supported branch) with the 4.6 compiler, which is now the
> system compiler in recent Linux distributions.

Well, we don't guarantee such compatibility in general,
so I'd like to make it clear that people shouldn't expect this combination
to work, and if more complex patches are submitted, we'll likely NOT
integrate them.

The init.c change is clearly already on the edge of kludgy changes and is
NOT ok as is, it requires a clear comments explaining why it's there.

OK with the comment changes.

Arno

> Shouldn't this be * 100 and > 405 ?  I mean, we already had GCC
> 2.95, 2.96, 2.97 and 20 + 95 is > 45...

This idiom is the one already used in tracebak.c for example.  Would that 
really matter in practice?

> Well, we don't guarantee such compatibility in general,
> so I'd like to make it clear that people shouldn't expect this combination
> to work, and if more complex patches are submitted, we'll likely NOT
> integrate them.

That's mainly for GCC developers; without this, it will be a pain to keep 
testing the 4.5.x Ada compiler on modern Linux distributions.

> The init.c change is clearly already on the edge of kludgy changes and is
> NOT ok as is, it requires a clear comments explaining why it's there.

OK, will add a ??? comment, thanks.

On Wed, Apr 04, 2012 at 10:08:50AM +0200, Eric Botcazou wrote:
> > Shouldn't this be * 100 and > 405 ?  I mean, we already had GCC
> > 2.95, 2.96, 2.97 and 20 + 95 is > 45...
> 
> This idiom is the one already used in tracebak.c for example.  Would that 
> really matter in practice?

It is a bad idiom, given that we already had >= 10 __GNUC_MINOR__ and it
is possible we'll have 4.10 as well.
E.g. __GNUC_PREREQ macro in glibc shifts left major by 16, but even
multiplying by 100 instead of 10 is better.

	Jakub

> It is a bad idiom, given that we already had >= 10 __GNUC_MINOR__ and it
> is possible we'll have 4.10 as well.
> E.g. __GNUC_PREREQ macro in glibc shifts left major by 16, but even
> multiplying by 100 instead of 10 is better.

OK, we'll change the idiom on mainline.

On Wed, Apr 4, 2012 at 9:51 AM, Arnaud Charlet <charlet@adacore.com> wrote:
>> Arno, do you have objections to me applying the attached patch to the 4.5
>> branch?  It makes it possible to build (and bootstrap) the Ada compiler on the
>> 4.5 branch (oldest supported branch) with the 4.6 compiler, which is now the
>> system compiler in recent Linux distributions.
>
> Well, we don't guarantee such compatibility in general,
> so I'd like to make it clear that people shouldn't expect this combination
> to work, and if more complex patches are submitted, we'll likely NOT
> integrate them.

Maybe you should start to do that though.  Otherwise you'll simply lose
the easy (but not required) testing of Ada when I (or others) backport
changes to still maintained branches on machines where the system Ada
compiler is newer than the oldest maintained branch.

So - it's all for your own benefit ;)  [you can think of using a new
-we-are-building-gcc
switch for the compile where you'd enable some backward compatibility or so]

Thanks,
Richard.