Bug 57188

Summary:	[4.9 regression] Ada bootstrap broken on Solaris/x64: No_Implicit_Dynamic_Code violation
Product:	gcc	Reporter:	Rainer Orth <ro>
Component:	ada	Assignee:	Rainer Orth <ro>
Status:	RESOLVED FIXED
Severity:	normal	CC:	charlet, ebotcazou
Priority:	P3
Version:	4.9.0
Target Milestone:	4.9.0
URL:	http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00394.html
Host:	amd64-pc-solaris2.1[01]	Target:	amd64-pc-solaris2.1[01]
Build:	amd64-pc-solaris2.1[01]	Known to work:
Known to fail:		Last reconfirmed:	2013-05-06 00:00:00

Description Rainer Orth 2013-05-06 15:37:52 UTC

For at least two weeks, Ada bootstrap on Solaris/x64 (i.e. the 64-bit-default
configuration) is broken:

ro@arenal 26 > ../../gnatbind -I- -I../rts -I. -I/vol/gcc/src/hg/trunk/local/gcc/ada -o b_gnatm.adb gnatmake.ali
error: "system.ads" has restriction No_Implicit_Dynamic_Code
error: but the following files violate this restriction:
error:   "make.adb"
error:   "makeutl.adb"
error:   "prj.adb"
error:   "prj-env.adb"
error:   "prj-conf.adb"
error:   "prj-proc.adb"
error:   "prj-nmsc.adb"

This doesn't happen in sparcv9-sun-solaris2* or i386-pc-solaris2* configurations.

  Rainer

Comment 1 Eric Botcazou 2013-05-06 16:55:04 UTC

> This doesn't happen in sparcv9-sun-solaris2* or i386-pc-solaris2*
> configurations.

gcc-interface/Makefile.in was a little changed so you probably need to adjust the relevant regexp here:

# x86 and x86-64 solaris
ifeq ($(strip $(filter-out %86 %x86_64 solaris2%,$(arch) $(osys))),)
  LIBGNAT_TARGET_PAIRS_COMMON = \

Comment 2 ro@CeBiTec.Uni-Bielefeld.DE 2013-05-07 14:57:20 UTC

> --- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-05-06 16:55:04 UTC ---
>> This doesn't happen in sparcv9-sun-solaris2* or i386-pc-solaris2*
>> configurations.
>
> gcc-interface/Makefile.in was a little changed so you probably need to adjust
> the relevant regexp here:
>
> # x86 and x86-64 solaris
> ifeq ($(strip $(filter-out %86 %x86_64 solaris2%,$(arch) $(osys))),)
>   LIBGNAT_TARGET_PAIRS_COMMON = \

That was it indeed.  The following patch restored amd64-pc-solaris2.10
bootstrap for, and also survived i386-pc-solaris2.11 bootstrap:

diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -1098,7 +1098,7 @@ ifeq ($(strip $(filter-out sparc% sun so
 endif
 
 # x86 and x86-64 solaris
-ifeq ($(strip $(filter-out %86 %x86_64 solaris2%,$(arch) $(osys))),)
+ifeq ($(strip $(filter-out %86 %x86_64 %amd64 solaris2%,$(arch) $(osys))),)
   LIBGNAT_TARGET_PAIRS_COMMON = \
   a-intnam.ads<a-intnam-solaris.ads \
   s-inmaop.adb<s-inmaop-posix.adb \

But what's the justification for the relevant change, which wasn't
posted to gcc-patches AFAICS?

2013-04-23  Eric Botcazou  <ebotcazou@adacore.com>
            Pascal Obry    <obry@adacore.com>

        * gcc-interface/Makefile.in (targ): Fix target name check.

Having to deal with the target_alias instead of the canonical form found
in target seems rather counterintuitive and fragile to me.

	Rainer

Comment 3 Eric Botcazou 2013-05-07 15:06:45 UTC

> But what's the justification for the relevant change, which wasn't
> posted to gcc-patches AFAICS?
> 
> 2013-04-23  Eric Botcazou  <ebotcazou@adacore.com>
>             Pascal Obry    <obry@adacore.com>
> 
>         * gcc-interface/Makefile.in (targ): Fix target name check.
> 
> Having to deal with the target_alias instead of the canonical form found
> in target seems rather counterintuitive and fragile to me.

The ChangeLog entry is misleading, neither Pascal nor I have anything to do with the change.  Yes, this is very fragile and has already caused various issues.

Comment 4 ro@CeBiTec.Uni-Bielefeld.DE 2013-05-07 15:09:04 UTC

> --- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-05-07
> 15:06:45 UTC ---
>> But what's the justification for the relevant change, which wasn't
>> posted to gcc-patches AFAICS?
>> 
>> 2013-04-23  Eric Botcazou  <ebotcazou@adacore.com>
>>             Pascal Obry    <obry@adacore.com>
>> 
>>         * gcc-interface/Makefile.in (targ): Fix target name check.
>> 
>> Having to deal with the target_alias instead of the canonical form found
>> in target seems rather counterintuitive and fragile to me.
>
> The ChangeLog entry is misleading, neither Pascal nor I have anything to do
> with the change.  Yes, this is very fragile and has already caused various
> issues.

This seems to argue for reverting or at least reworking the change.  I
suppose I'll withhold my patch until it's decided how to proceed.

	Rainer

Comment 5 Eric Botcazou 2013-05-07 16:04:07 UTC

> This seems to argue for reverting or at least reworking the change.  I
> suppose I'll withhold my patch until it's decided how to proceed.

I'd post it on the list in any case and see what the other maintainers think.

Comment 6 Rainer Orth 2013-05-08 09:29:11 UTC

Mine, patch posted.

Comment 7 charlet@adacore.com 2013-05-13 07:15:23 UTC

> >>         * gcc-interface/Makefile.in (targ): Fix target name check.
> >> 
> >> Having to deal with the target_alias instead of the canonical form found
> >> in target seems rather counterintuitive and fragile to me.
> >
> > The ChangeLog entry is misleading, neither Pascal nor I have anything to
> > do
> > with the change.  Yes, this is very fragile and has already caused various
> > issues.
> 
> This seems to argue for reverting or at least reworking the change.  I
> suppose I'll withhold my patch until it's decided how to proceed.

This change is useful for many cross configurations which have similar
names, so I would suggest you post your patch to gcc-patches@.
Your patch is pre-approved FWIW, so feel free to apply it.

Arno

Comment 8 Rainer Orth 2013-05-13 11:08:08 UTC

Fixed for 4.9.0.