https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
Chris Green changed:
What|Removed |Added
CC||greenc at fnal dot gov
--- Comment #28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #27 from Iain Sandoe ---
(In reply to Uroš Bizjak from comment #26)
> + /* If we don't find any, we've got an empty function body; i.e.
> + completely empty - without a return or branch. Reaching an
> + empty function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #26 from Uroš Bizjak ---
+ /* If we don't find any, we've got an empty function body; i.e.
+completely empty - without a return or branch. Reaching an
+empty function body means UB. Let's trap it. */
+ if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #25 from Iain Sandoe ---
Created attachment 37324
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37324=edit
Avoid empty function bodies V1
So...
The #if TARGET_MACHO code in ix86_output_function_epilogue () is supposed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #22 from Iain Sandoe ---
OK, So this has been biting me some more.
It might be another case where Darwin has thrown up a more general problem.
What's happening is that, where functions are ending up zero-sized, an FDE is
still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #23 from mrs at gcc dot gnu.org ---
On the platform, external symbols are defined to be 1 or more bytes. 0 is not
one or more. Once that is fixed, then the problem goes away. If you want to
have Apple update their abi for future
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #24 from Iain Sandoe ---
(In reply to m...@gcc.gnu.org from comment #23)
> On the platform, external symbols are defined to be 1 or more bytes. 0 is
> not one or more. Once that is fixed, then the problem goes away. If you
> want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #21 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #20)
Still present at revision 203491 and the patch in comment #14 does not help.
Trivial reproducer:
=
__attribute__((noinline))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #16 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org ---
Yes please. If you can run:
dwarfdump --eh-frame --verify file.o
on all the .o files and see if there are any more lurking in there. Any that
fail verification will need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #17 from Dara Hazeghi dhazeghi at yahoo dot com ---
(In reply to m...@gcc.gnu.org from comment #16)
Yes please. If you can run:
dwarfdump --eh-frame --verify file.o
on all the .o files and see if there are any more lurking in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #18 from Jack Howarth howarth at nitro dot med.uc.edu ---
Do we have any idea why this problem is latent with --checking=release and
--checking=yes but is triggered by --disable-checking?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #19 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org ---
I'll build my own tree, thanks. I was hoping that it was a singular issue and
we'd be done with it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed:
What|Removed |Added
CC||mrs at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #12 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org ---
Ok, new theory. Does this patch fix it for you:
Index: varasm.c
===
--- varasm.c(revision 199270)
+++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #13 from Dara Hazeghi dhazeghi at yahoo dot com ---
(In reply to m...@gcc.gnu.org from comment #12)
Ok, new theory. Does this patch fix it for you:
Thanks for the patch. Just tried bootstrapping with it and checking disabled,
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #14 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org ---
Thanks, how about this one?
Index: target.def
===
--- target.def(revision 199270)
+++ target.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #15 from Dara Hazeghi dhazeghi at yahoo dot com ---
(In reply to m...@gcc.gnu.org from comment #14)
Thanks, how about this one?
Seems to be the same - assert in the same spot. Shall I upload the varasm.s
produced with the second
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
Jack Howarth howarth at nitro dot med.uc.edu changed:
What|Removed |Added
CC||howarth at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu ---
The trigger for this bug is the use of --disable-checking. The linker crash
doesn't occur when --enable-checking=release or --enable-checking=yes is passed
to configure instead.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #4 from Dara Hazeghi dhazeghi at yahoo dot com ---
Aha! I will try using plain make and leaving checking alone. I don't suppose
this is documented anywhere?
As to reporting the bug to Apple, is this in fact a linker bug, as opposed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #5 from Dara Hazeghi dhazeghi at yahoo dot com ---
(In reply to Dara Hazeghi from comment #4)
Aha! I will try using plain make and leaving checking alone. I don't
suppose this is documented anywhere?
make (not bootstrap) with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu ---
I've opened radar://14005298, linker crash when building FSF gcc with
--disable-checking with a standalone test case of the failing linkage of cc1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #7 from Dara Hazeghi dhazeghi at yahoo dot com ---
(In reply to Jack Howarth from comment #6)
I've opened radar://14005298, linker crash when building FSF gcc with
--disable-checking with a standalone test case of the failing linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu ---
The darwin linker developer's analysis of the failing linkage of cc1 is
below...
The assertion is about the file libbackend.a(varasm.o). There are overlapping
FDEs. If you run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #9 from Mike Stump mikestump at comcast dot net ---
If you can attach the .s file for varasm.c that does result in the crash that
would be good. If this is a regression, identifying the change that broken it
would be handy. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #10 from Dara Hazeghi dhazeghi at yahoo dot com ---
Created attachment 30211
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30211action=edit
varasm.s.gz
varasm.s resulting in the crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
This seems better reported to Apple than here as it is Apple's provided ld that
is crashing.
28 matches
Mail list logo
