This is GCC Bugzilla

This is GCC Bugzilla Version 2.20+

Full Text Bug Listing

This is a regression since GCC 3.2, triggered by the following patch:
http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01259.html
I initially reported the bug on the GCC list on 18 october 2002 in http://gcc.gnu.org/ml/gcc/2002-10/msg00901.html
Geoffrey Keating wrote a good synopsis of the issue in
http://gcc.gnu.org/ml/gcc/2002-10/msg01071.html

Symptom is:
stage1/xgcc -Bstage1/ -B/usr/local/powerpc-apple-darwin6.4/bin/ -c -g -O2      -gnatpg -gnata -g -O1 -fno-inline \
 -I- -I. -Iada -I/Users/bosch/gcc/gcc/ada /Users/bosch/gcc/gcc/ada/a-except.adb -o ada/a-except.o
/var/tmp//ccRkTAgH.s:unknown:Can't emit reloc {- symbol "L65$pb"} @ file address 9596.
/var/tmp//ccRkTAgH.s:unknown:Can't emit reloc {- symbol "L65$pb"} @ file address 9592.
/var/tmp//ccRkTAgH.s:unknown:Can't emit reloc {- symbol "L64$pb"} @ file address 9484.
...
...

Release:
3.3

How-To-Repeat:
configure --enable-languages=c,ada
make bootstrap

Fix:
Quoting from message http://gcc.gnu.org/ml/gcc/2002-10/msg01071.html by Geoffrey:
Since we can't do the nice thing, probably a good second-best is, for  functions that need this restore (perhaps those that have  current_function_has_nonlocal_label set) to ensure that the original  load_macho_picbase never gets deleted by adding a suitable USE of the  PIC register.

Responsible-Changed-From-To: unassigned->shebs
Responsible-Changed-Why: Assigned to Darwin maintainer - knowledge required is darwin-specific, not Ada-specific

State-Changed-From-To: open->analyzed
State-Changed-Why: Problem was analyzed in emails referenced in the desciption below.

Hello,

I can confirm that this problem is still present on gcc 3.3 branch and mainline (20030531).

Dara

*** Bug 11046 has been marked as a duplicate of this bug. ***

Geoff,

You seemed to have some insight in how this bug could be fixed. Could you see if you could 
produce a patch along the lines of what you described?

I'd be glad to do the testing etc. for you. This bug really hinders my work on GCC as my
laptop runs this configuration and I can't use it anymore for builds.

  -Geert

A work around for the mainline is to compile gcc with -mdynamic-no-pic as I
said in my email but 
I also wantted to put here so that someone else looking for the bug can see the
workaround.

I was looking into this bug and it seems some how 
ada__exceptions__subprogram_descriptors is being marked as being defined (prefix of 
!D__) so the symbol is being used instead of a lazy pointer one being created and that 
one being used. Checking more to see it gets set as being defined.

The problem is that the Ada front end is marking 
ada__exceptions__subprogram_descriptors as common and having a DECL_INITIAL 
and that is what is causing it to be marked as defined which is wrong.
Fix in the works.

Okay, this cannot be reproduced at all with a C example.  The Ada Front-end
converts its 
functions interweaved.  I think the fix here is to have a hashtable in 
machopic_function_base_name with each of the functions and the PIC strings.

Created an attachment (id=4327) [edit]
Patch which should fix all the problems.

I just added a hashtable to machopic_function_base_name and I am bootstrapping
right now but I think this should work.
Here is the combined patch which contains the first patch which gets bootstrap
further and the one I am testing right now with the hashtable.
I will submit this to gcc-patches@ once it gets passed stage2.

Subject: Re:  Ada bootstrap fails on PPC-Darwin - invalid assembler emitted -
PIC related

On Wednesday, Jul 2, 2003, at 10:28 America/New_York, pinskia at 
physics dot uc dot edu wrote:

> Okay, this cannot be reproduced at all with a C example.  The Ada 
> Front-end converts its functions interweaved.  I think the fix here is 
> to
> have a hashtable in machopic_function_base_name with each of the
> functions and the PIC strings.

Thanks a lot for your investigations, Andrew. That explains why all my
attempts to distill a C example for Geoffrey failed. What I don't
understand is whether this very target-specific bug has anything to
do with problems in the Ada front end, is a bug in the back end that
only gets triggered by Ada, or is a result of unclear back end / front 
end
interface. From your description so far, the problem seems to be in
the third category, but if that's the case we probably should also
strengthen the documentation (including comments) a bit.

Also, I think it would be useful at this point if we would be able to
add Ada tests to the GCC test suite, but I have absolutely no clue on
how to do that.

   -Geert

I think the reason why machopic_function_base_name was done the way without a
hashtable was 
because the frontend Apple supported had the conversion to rtl interwoven so
Apple only tested it 
with c, objective-c and c++.  But as we saw other frontends the conversion to
rtl is interwoven but 
I do not really know if the Ada frontend is right to do this but I only working
around the problem in 
Darwin's backend and removing the constraint of the rtl have been not
interwoven.  
I wish someone figure out who is right here, I think the Ada frontend is right
at what it is doing.

In fact I download the Ada compiler yesterday and get the first patch done
within a hour.
The second one I had to figure out why the PIC labels were different between
the one in the restore 
from the setjmp and the one in the function and that was just having gdb stop
inside 
machopic_function_base_name when a label was generated and I say ali_scan_ali
came up twice 
with another in between so I knew something was wrong (or right in the case for
Ada) so I saw I 
could just store the function name and the label in a hashtable and lookup it
up and see if there 
was alreay one there, I left the old way of finding the pic label so that the
speed of gcc would not 
slow down too far.  I am running bootstrap right now on the patch but it should
be past the old 
place of failure soon.

There is still more do to as it gets passed ali.adb were it was failing last
time but now fails on 
atree, I will look into it some more.  This one might be caused by the inliner
though.

Subject: Re:  Ada bootstrap fails on PPC-Darwin - invalid assembler emitted -
PIC related


On Wednesday, Jul 2, 2003, at 12:57 America/New_York, pinskia at 
physics dot uc dot edu wrote:

> There is still more do to as it gets passed ali.adb were it was 
> failing last time but now fails on  atree, I will look into it some 
> more.
> This one might be caused by the inliner though.

Is this an assembler error too?

   -Geert

Yes this is another asm error:
atree.s:43299:non-relocatable subtraction expression, "L00000000617$pb" minus "LSJR2316"
atree.s:43299:symbol: "L00000000617$pb" can't be undefined in a subtraction expression
atree.s:43298:non-relocatable subtraction expression, "L00000000617$pb" minus "LSJR2316"
atree.s:43298:symbol: "L00000000617$pb" can't be undefined in a subtraction expression
atree.s:42878:non-relocatable subtraction expression, "L00000000614$pb" minus "LSJR2302"
atree.s:42878:symbol: "L00000000614$pb" can't be undefined in a subtraction expression
atree.s:42877:non-relocatable subtraction expression, "L00000000614$pb" minus "LSJR2302"
atree.s:42877:symbol: "L00000000614$pb" can't be undefined in a subtraction expression
atree.s:unknown:Undefined local symbol L00000000614$pb
atree.s:unknown:Undefined local symbol L00000000617$pb

Okay I think I figured out how this one is happening, now the problem is
figuring out how to fix it.
The problem is the Darwin's backend depends on current_function_decl which Ada
changes the 
name inside it for some reason to be one with a .n (where n is an integer). So
the problem is the 
hashtable will not caught every thing so on when the setjmp is generated,
current_function_decl is 
without the .n but when the function is generated it has a .n, so this is
confusing Darwin's 
backend.  Now I do not know the currect fix at all and this problem seems to be
needed to be fixed 
in the Ada frontend.

Subject: Re:  Ada bootstrap fails on PPC-Darwin - invalid assembler emitted -
PIC related

> Date: 2 Jul 2003 14:28:29 -0000
> From: "pinskia at physics dot uc dot edu" <gcc-bugzilla@gcc.gnu.org>

> Okay, this cannot be reproduced at all with a C example.  The Ada
> Front-end converts its functions interweaved.  I think the fix here
> is to have a hashtable in machopic_function_base_name with each of
> the functions and the PIC strings.

If you're going to touch that code at all, it would be better to just
defer the choosing of the name until the string is actually output
during final; make the name something like '<pic offset>', and
recognize that string during ASM_OUTPUT_*.  This code is already
horribly ugly and broken.

You can't keep the 'strings' in the hash table, because there is only
one; the entire design of the function relies on there being one
string that it changes.  Did I mention that it was horribly ugly and
broken?

Moving to 3.3.2 because I will not get copyright assignments in time (I sent
them in 
yesterday, 20030708) and taking over the bug because I have several patches
which I 
am going to submit as I now have a working Ada compiler on my computer, one
more 
patch than that is listed here and has been accepted which also fixes some C++ 
problems.

This is almost fixed on the mainline (one more patch needs to be accepted), I
will ask again about 
it.  It was the first patch I submitted.

Ada bugs are not release critical; removing target milestone.

The patch needed to fix this is here:
<http://gcc.gnu.org/ml/gcc-patches/2003-07/
msg00171.html>.

The patches pointed to by this bug patch version 1.38 of darwin.c which is NOT
the version 
released with gcc-3.3.2.  Would it be possible to get a patch for gcc-3.3.2 as
I am hitting this 
problem when compiling c code with gcc 3.3.2.

Just to make clear: the fixes for this have not been applied to cvs yet. If
somebody would review 
and apply them, that would of course be greatly appreciated :-)

No longer mine (Ada might not be in 3.5.0 anyways).

Subject: Re:  Ada bootstrap fails on PPC-Darwin - invalid assembler emitted -
PIC related

> No longer mine (Ada might not be in 3.5.0 anyways).

It is fine to unassign bugs, however the 'anyways' should not be used as an
excuse for current bugs with current sources.

I'll do my best to have Ada included in 3.5.0, so please do not start
using this argument as an excuse for not looking at failures/regressions,
thanks :-)

Arno

Subject: Bug 10129

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	pinskia@gcc.gnu.org	2004-04-08 17:17:27

Modified files:
	gcc            : ChangeLog 

Log message:
	2004-04-08  Andrew Pinski  <pinskia@physics.uc.edu>
	
	PR target/10129
	* config/darwin.c (darwin_encode_section_info): When the decl has
	a DECL_INITIAL, it is only defined also when it is not a common.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.3362&r2=2.3363

Fix was applied to 3.5.0 currently queued for 3.4.1 as 3.4.0 is frozen right
now.

Mark, this is patch okay for the 3.4 branch, it has already been applied to the
mainline, it 
fixes build Ada on powerpc-apple-darwin and has been in my tree for a long
time.

Subject: Re:  [3.4 only] Ada bootstrap fails on PPC-Darwin
 - invalid assembler emitted - PIC related

pinskia at gcc dot gnu dot org wrote:

>------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-22 16:36 -------
>Mark, this is patch okay for the 3.4 branch, it has already been applied to the mainline, it 
>fixes build Ada on powerpc-apple-darwin and has been in my tree for a long time.
>  
>
Where is the version of the patch that was committed to mainline?  Is it 
the same patch that is in the PR?

That patch has a coding-style problem:

+      if (pic_labels_htab == NULL)
+        {
+          pic_labels_htab = htab_create_ggc (31, pic_named_entry_hash,
+                                          pic_entry_eq, NULL);
+        }

There should be no braces since there is only one dependent statement.

Furthermore:

+          /* I did not find the function in the hashtable, create a new label. */

is not a good comment; we avoid using "I" in comments in favor of "we".  
Or, even better, just say "The function was not in the hash table so a 
new label must be created."

As for applying the patch to the 3.4 branch, I will leave that up to a 
Darwin maintainer.  I'd probably be inclined not to apply it, but if a 
Darwin maintainer thinks it's worthwhile, that's OK with me.

Thanks,

Mark sorry not being clear on this one, the patch is which needed to checked in
was at:
<http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00171.html>.   The reason why I
asking you 
because for the darwin maintainers are not as responsive as you are, as you can
see that the patch was 
from july of last year but only got applied this month to the mainline.

The patch which you looked over was superseded by a different patch which was
applied already to the 
mainline when it was 3.4.0.

Subject: Re:  [3.4 only] Ada bootstrap fails on PPC-Darwin
 - invalid assembler emitted - PIC related

pinskia at gcc dot gnu dot org wrote:

>------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-22 17:48 -------
>Mark sorry not being clear on this one, the patch is which needed to checked in was at:
><http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00171.html>.   The reason why I asking you 
>because for the darwin maintainers are not as responsive as you are, as you can see that the patch was 
>from july of last year but only got applied this month to the mainline.
>
>The patch which you looked over was superseded by a different patch which was applied already to the 
>mainline when it was 3.4.0.
>  
>
That's a simpler patch, certainly.  However, I still think a Darwin 
maintainer should sign off, since this is not a regression.  I am not 
enough of a Darwin expert to make a good determination.

Subject: Re:  [3.4 only] Ada bootstrap fails on PPC-Darwin - invalid assembler
emitted - PIC related


On Apr 22, 2004, at 13:59, mark at codesourcery dot com wrote:
> That's a simpler patch, certainly.  However, I still think a Darwin
> maintainer should sign off, since this is not a regression.  I am not
> enough of a Darwin expert to make a good determination.

This is a regression, as explained in the beginning of the bug
report. Geoff checked in a change in the handling of PIC that broke
the Ada bootstrap. Since then various people, Andrew Pinsky most of
all, spent a lot of time trying to analyze/fix the issue. We really
should fix this regression, so Darwin will have a 3.4 based compiler
that includes Ada.

   -Geert

Note that the problem of generating invalid assembly on darwin is NOT ada
specific.  I've run into the 
problem using the C++ compiler.

Ada bugs are not showstoppers.

Sp just closing as fixed for 3.5.0 then :(.

I can't understand. This bug is obviously a regression, there is an easy and 
simple patch which already went to mainline, so it should go to the branch 
automatically. You asked for further approval from Mark, and he deferred this 
to the Darwin maintainers.

Why did you close this bug as fixed? I would think the Darwin maintainers would 
like to have this regression fixed in 3.4 as well.

Subject: Bug 10129

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	pinskia@gcc.gnu.org	2004-06-19 17:52:43

Modified files:
	gcc            : ChangeLog 
	gcc/config     : darwin.c 

Log message:
	2004-06-19  Andrew Pinski  <pinskia@physics.uc.edu>
	
	PR target/10129
	* config/darwin.c (darwin_encode_section_info): When the decl has
	a DECL_INITIAL, it is only defined also when it is not a common.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.512&r2=2.2326.2.513
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/darwin.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.55&r2=1.55.6.1

Fixed now for 3.4.1 sorry for the miss reading.