[4.5/Ada] Fix build with 4.6 compiler

[4.5/Ada] Fix build with 4.6 compiler

[Eric Botcazou]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

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.


-- 
Eric Botcazou

[-- Attachment #2: boot_ada.diff --]
[-- Type: text/x-diff, Size: 3087 bytes --]

Index: init.c
===================================================================
--- 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)
+int   __gl_main_cpu                      = -1;
+#endif
 int   __gl_time_slice_val                = -1;
 char  __gl_wc_encoding                   = 'n';
 char  __gl_locking_policy                = ' ';
Index: types.ads
===================================================================
--- types.ads	(revision 186078)
+++ types.ads	(working copy)
@@ -125,8 +125,9 @@
 
    subtype Big_String is String (Positive);
    type Big_String_Ptr is access all Big_String;
-   for Big_String_Ptr'Storage_Size use 0;
-   --  Virtual type for handling imported big strings
+   --  Virtual type for handling imported big strings. Note that we should
+   --  never have any allocators for this type, but we don't give a storage
+   --  size of zero, since there are legitimate deallocations going on.
 
    function To_Big_String_Ptr is
      new Unchecked_Conversion (System.Address, Big_String_Ptr);
@@ -200,13 +201,14 @@
    --  Source_Buffer_Ptr, see Osint.Read_Source_File for details.
 
    type Source_Buffer_Ptr is access all Big_Source_Buffer;
-   for Source_Buffer_Ptr'Storage_Size use 0;
    --  Pointer to source buffer. We use virtual origin addressing for source
    --  buffers, with thin pointers. The pointer points to a virtual instance
    --  of type Big_Source_Buffer, where the actual type is in fact of type
    --  Source_Buffer. The address is adjusted so that the virtual origin
    --  addressing works correctly. See Osint.Read_Source_Buffer for further
-   --  details.
+   --  details. Again, as for Big_String_Ptr, we should never allocate using
+   --  this type, but we don't give a storage size clause of zero, since we
+   --  may end up doing deallocations of instances allocated manually.
 
    subtype Source_Ptr is Text_Ptr;
    --  Type used to represent a source location, which is a subscript of a
Index: par-ch3.adb
===================================================================
--- par-ch3.adb	(revision 186078)
+++ par-ch3.adb	(working copy)
@@ -111,7 +111,6 @@
    --  current token, and if this is the first such message issued, saves
    --  the message id in Missing_Begin_Msg, for possible later replacement.
 
-
    ---------------------------------
    -- Check_Restricted_Expression --
    ---------------------------------
@@ -2107,7 +2106,6 @@
       Range_Node : Node_Id;
       Save_Loc   : Source_Ptr;
 
-
    --  Start of processing for P_Range_Or_Subtype_Mark
 
    begin
Index: uintp.adb
===================================================================
--- uintp.adb	(revision 186078)
+++ uintp.adb	(working copy)
@@ -239,7 +239,7 @@
 
    function Hash_Num (F : Int) return Hnum is
    begin
-      return Standard."mod" (F, Hnum'Range_Length);
+      return Types."mod" (F, Hnum'Range_Length);
    end Hash_Num;
 
    ---------------

Re: [4.5/Ada] Fix build with 4.6 compiler

[Jakub Jelinek]

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

Re: [4.5/Ada] Fix build with 4.6 compiler

[Eric Botcazou]

> 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?

-- 
Eric Botcazou

Re: [4.5/Ada] Fix build with 4.6 compiler

[Jakub Jelinek]

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

Re: [4.5/Ada] Fix build with 4.6 compiler

[Eric Botcazou]

> 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.

-- 
Eric Botcazou

Re: [4.5/Ada] Fix build with 4.6 compiler

[Arnaud Charlet]

> 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

Re: [4.5/Ada] Fix build with 4.6 compiler

[Eric Botcazou]

> 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.

-- 
Eric Botcazou

Re: [4.5/Ada] Fix build with 4.6 compiler

[Richard Guenther]

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.