https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #88 from Tamar Christina ---
Thanks Jakub!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #87 from Jakub Jelinek ---
Author: jakub
Date: Tue Apr 30 16:30:44 2019
New Revision: 270705
URL: https://gcc.gnu.org/viewcvs?rev=270705=gcc=rev
Log:
PR target/89093
* gcc.target/aarch64/return_address_sign_3.c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #86 from Tamar Christina ---
for aarch64-none-linux-gnu. I am still building the toolchain to take a look so
not able to give more detail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #84 from Jakub Jelinek ---
Author: jakub
Date: Tue Apr 30 12:07:27 2019
New Revision: 270690
URL: https://gcc.gnu.org/viewcvs?rev=270690=gcc=rev
Log:
PR target/89093
* config/aarch64/aarch64.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #82 from ian at gcc dot gnu.org ---
Author: ian
Date: Wed Apr 24 12:45:45 2019
New Revision: 270542
URL: https://gcc.gnu.org/viewcvs?rev=270542=gcc=rev
Log:
PR target/89093
runtime: mark unwind functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #81 from Jakub Jelinek ---
Fixed for Ada as well, only Go left to do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #80 from Jakub Jelinek ---
Author: jakub
Date: Wed Apr 24 08:16:07 2019
New Revision: 270535
URL: https://gcc.gnu.org/viewcvs?rev=270535=gcc=rev
Log:
PR target/89093
* raise-gcc.c (TARGET_ATTRIBUTE): Define.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #78 from Jakub Jelinek ---
Author: jakub
Date: Tue Apr 23 10:03:41 2019
New Revision: 270504
URL: https://gcc.gnu.org/viewcvs?rev=270504=gcc=rev
Log:
PR target/89093
* config/arm/arm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Jakub Jelinek changed:
What|Removed |Added
Attachment #46205|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Jakub Jelinek changed:
What|Removed |Added
Attachment #46202|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #75 from Jakub Jelinek ---
It failed for me as well. And a GCC version check won't really help when using
earlier GCC 9 snapshot as system compiler (though, admittedly that isn't
supported).
Another option would be to define the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Bernd Edlinger changed:
What|Removed |Added
Attachment #46200|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #73 from Bernd Edlinger ---
Okay, the requirement is only to be able to boot-strap with
a released gcc version, so gcc-8 should not use the pragma,
while gcc-9 should use the pagma.
I was able to bootstrap from x86_64 -> arm cross ->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #72 from Bernd Edlinger ---
I use host Compiler from last week:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/9.0.1/lto-wrapper
Target:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #71 from Bernd Edlinger ---
I am sorry, but my native arm bootstrap Fails:
g++ -std=gnu++98 -fno-PIE -c -I../../gcc-trunk-r270444/gcc/../libgcc
-DEH_MECHANISM_arm -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #70 from Bernd Edlinger ---
Yes, thanks, now switching to your latest patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Jakub Jelinek changed:
What|Removed |Added
Attachment #46198|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #68 from Jakub Jelinek ---
Comment on attachment 46200
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46200
updated patch
I believe the second hunk in libgo/runtime/go-unwind.c is incorrect, that is on
code not guarded with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #67 from Bernd Edlinger ---
Created attachment 46200
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46200=edit
updated patch
So, that is what I am going to bootstrap now.
Adds a libgo patch and some minor changes, mostly where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #66 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #65)
> Created attachment 46198 [details]
> gcc9-pr89093.patch
>
> So, can we converge to a single patch that does everything? Attached is
> completely untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #65 from Jakub Jelinek ---
Created attachment 46198
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46198=edit
gcc9-pr89093.patch
So, can we converge to a single patch that does everything? Attached is
completely untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #64 from Bernd Edlinger ---
Okay, using Ian's suggestion I've got this now:
Index: libphobos/libdruntime/gcc/deh.d
===
--- libphobos/libdruntime/gcc/deh.d (revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #63 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #59)
> That looks like a D FE bug then.
That shouldn't be difficult, I've create PR d/90136 to keep track of that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gdcproject dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #61 from Jakub Jelinek ---
At least looking at x86_64-linux gcc/deh.o, I really don't see any .text
comdats, only data comdats, all STT_FUNC symbols are in the same section,
except for the global ctors in .text.startup and dtors in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #60 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #59)
> That looks like a D FE bug then.
> In any case, why can't you just use -mgeneral-regs-only on the deh.d
> compilation command line?
Could work, just anxious,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #59 from Jakub Jelinek ---
That looks like a D FE bug then.
In any case, why can't you just use -mgeneral-regs-only on the deh.d
compilation command line?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #58 from Bernd Edlinger ---
No, sorry, the attribute on the prototype gets ignored, as the following
is compiled without generating an error:
private int test(double x)
{
return x > 1.0;
}
static if (GNU_ARM_EABI_Unwinder)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #57 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #56)
> Can't you just add prototypes?
> Like:
> static if (GNU_ARM_EABI_Unwinder)
> {
> @attribute("target", ("general-regs-only"))
> private _Unwind_Reason_Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #56 from Jakub Jelinek ---
Can't you just add prototypes?
Like:
static if (GNU_ARM_EABI_Unwinder)
{
@attribute("target", ("general-regs-only"))
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #55 from Bernd Edlinger ---
But, how about that:
Index: deh.d
===
--- deh.d (revision 270395)
+++ deh.d (working copy)
@@ -28,6 +28,7 @@
import
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #54 from Bernd Edlinger ---
Hmm, I see. What I am trying to accomplish is, put the target
attribute on every function that calls directly or in-directly
to CONTINUE_UNWINDING. And do that only for ARM.
For gdc_personality it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #53 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #52)
> I digged a bit, and found a D syntax for the target attribute,
> it is a bit of a complication since D does not have a pre-processor,
> but an empty target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #52 from Bernd Edlinger ---
I digged a bit, and found a D syntax for the target attribute,
it is a bit of a complication since D does not have a pre-processor,
but an empty target attribute does seem to be ignored without warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #51 from Jakub Jelinek ---
Author: jakub
Date: Wed Apr 17 08:30:44 2019
New Revision: 270404
URL: https://gcc.gnu.org/viewcvs?rev=270404=gcc=rev
Log:
PR target/89093
* config/arm/arm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #50 from Jakub Jelinek ---
(In reply to Florian Weimer from comment #49)
> (In reply to Bernd Edlinger from comment #48)
> > (In reply to Florian Weimer from comment #47)
> > > (In reply to Bernd Edlinger from comment #43)
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #49 from Florian Weimer ---
(In reply to Bernd Edlinger from comment #48)
> (In reply to Florian Weimer from comment #47)
> > (In reply to Bernd Edlinger from comment #43)
> > > does anybody know what is the Ada and/or D syntax for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #48 from Bernd Edlinger ---
(In reply to Florian Weimer from comment #47)
> (In reply to Bernd Edlinger from comment #43)
> > does anybody know what is the Ada and/or D syntax for that?
>
> Syntax for what?
I mean the Ada and D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #47 from Florian Weimer ---
(In reply to Bernd Edlinger from comment #43)
> does anybody know what is the Ada and/or D syntax for that?
Syntax for what?
I fear we need eagerly load all vector registers before calling the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #46 from Jakub Jelinek ---
Author: jakub
Date: Sat Apr 13 15:20:46 2019
New Revision: 270339
URL: https://gcc.gnu.org/viewcvs?rev=270339=gcc=rev
Log:
PR target/89093
* config/arm/arm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #45 from Ramana Radhakrishnan ---
(In reply to Jakub Jelinek from comment #42)
> Thanks for the explanation.
> In that case, I think it would be better to just add
> __attribute__((target("general-regs-only")))
> to the
> #ifdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #44 from Bernd Edlinger ---
Comment on attachment 46013
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46013
updated patch.
@@ -122,12 +122,21 @@ extern tree arm_fp16_type_node;
#define TARGET_32BIT_P(flags) (TARGET_ARM_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #43 from Bernd Edlinger ---
does anybody know what is the Ada and/or D syntax for that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #42 from Jakub Jelinek ---
Thanks for the explanation.
In that case, I think it would be better to just add
__attribute__((target("general-regs-only")))
to the
#ifdef __ARM_EABI_UNWINDER__
_Unwind_Reason_Code
PERSONALITY_FUNCTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #41 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #39)
> (and, note, not just C++ personality routine, we have also libgcc/unwind-c.c
> with C personality routine (also changed in the patch) and perhaps
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #40 from Bernd Edlinger ---
Not that I invented this, but as far as I understand,
normally the interrupted execution context registers are saved on a
register file in memory. But not on ARM.
On arm only the core registers are saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #39 from Jakub Jelinek ---
(In reply to Richard Biener from comment #38)
> Isn't the issue also latent on all branches?
It is, but we have been lucky that the RA didn't decide to emit that.
On the trunk (unless something changed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #38 from Richard Biener ---
Isn't the issue also latent on all branches?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #37 from Bernd Edlinger ---
If a non-general-regs-only function is called from here,
it will only preserve d8-d15, and the call-clobbered registers
d0-d7 would of course be modified.
But is that a problem at all, if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #36 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #35)
> (In reply to Bernd Edlinger from comment #33)
> > (In reply to Ramana Radhakrishnan from comment #32)
> > >
> > > Either I drop the warning or I keep the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #35 from Jonathan Wakely ---
(In reply to Bernd Edlinger from comment #33)
> (In reply to Ramana Radhakrishnan from comment #32)
> >
> > Either I drop the warning or I keep the hunk in eh_personality.cc - any
> > preferences /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #34 from Jakub Jelinek ---
@@ -30877,6 +30883,11 @@ arm_valid_target_attribute_rec (tree args, struct
gcc_options *opts)
else if (!strncmp (q, "arm", 3))
opts->x_target_flags &= ~MASK_THUMB;
+ else if (!strncmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #33 from Bernd Edlinger ---
(In reply to Ramana Radhakrishnan from comment #32)
>
> Either I drop the warning or I keep the hunk in eh_personality.cc - any
> preferences / thoughts ?
It would feel safer, if only the functions that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Ramana Radhakrishnan changed:
What|Removed |Added
Attachment #45552|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #31 from Jakub Jelinek ---
(In reply to Ramana Radhakrishnan from comment #30)
> (In reply to Jakub Jelinek from comment #29)
> > Ramana, any progress on this?
>
> I'm still trying to get the various spec files and the t-multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #30 from Ramana Radhakrishnan ---
(In reply to Jakub Jelinek from comment #29)
> Ramana, any progress on this?
I'm still trying to get the various spec files and the t-multilib bits sorted
and half-term has intervened here in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #29 from Jakub Jelinek ---
Ramana, any progress on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #28 from Bernd Edlinger ---
(In reply to Ramana Radhakrishnan from comment #27)
> (In reply to Bernd Edlinger from comment #25)
> > you might consider adding something like that to your patch:
> >
> > Index: elf.h
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #27 from Ramana Radhakrishnan ---
(In reply to Bernd Edlinger from comment #25)
> you might consider adding something like that to your patch:
>
> Index: elf.h
> ===
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #26 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #25)
> you might consider adding something like that to your patch:
>
> Index: elf.h
> ===
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #25 from Bernd Edlinger ---
you might consider adding something like that to your patch:
Index: elf.h
===
--- elf.h (revision 268337)
+++ elf.h (working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Andrew Pinski changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #23 from Jakub Jelinek ---
Created attachment 45580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45580=edit
gcc9-pr89093.patch
This is what we are successfully using in Fedora for now (passed
bootstrap/regtest and fixed the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #22 from Jakub Jelinek ---
One more issue, shouldn't the #pragma GCC target be added before all include
files? Various define many inline functions, e.g. unwind-pe.h or unwind-cxx.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #20 from Florian Weimer ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
>
> Testing this and would be grateful for a test run.
I can confirm that this patch fixes the glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Jakub Jelinek changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #18 from Florian Weimer ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
>
> Testing this and would be grateful for a test run.
Is this hunk needed as well, or will the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #17 from Florian Weimer ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
>
> Testing this and would be grateful for a test run.
I believe the #pragma GCC push_options needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #16 from Ramana Radhakrishnan ---
(In reply to Jakub Jelinek from comment #14)
> We require GNU make, so one can use something like:
> unwind-arm.o unwind-c.o libunwind.o pr-support.o: CFLAGS += -mfpu=none
> or similar in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Ramana Radhakrishnan changed:
What|Removed |Added
Attachment #45547|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #14 from Jakub Jelinek ---
We require GNU make, so one can use something like:
unwind-arm.o unwind-c.o libunwind.o pr-support.o: CFLAGS += -mfpu=none
or similar in libgcc/config/arm/t-arm (or similar) with a comment explaining
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #12 from Jakub Jelinek ---
If one appends -mfloat-abi=soft to command lines of those files, does that
imply incompatible ABI even if nothing is passed in float/VFP etc. registers
nor there is any floating point code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #11 from Jakub Jelinek ---
Comment on attachment 45547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45547
untested prototype patch.
Doesn't the whole unwinder (so eh_personality.cc (whole, not just one function
in it),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #10 from Ramana Radhakrishnan ---
Created attachment 45547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45547=edit
untested prototype patch.
Not sure if this is complete yet but it gives a framework to dig further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #9 from Jakub Jelinek ---
If the EABI has such requirements, then libgcc/config/arm/t-arm (or whatever
else) needs to pass down -msoft-float (or whatever else disables the VFP
registers), rather than relying on that the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #8 from joseph at codesourcery dot com ---
The Arm rule is that the EH machinery needs to avoid using VFP (or other
non-core) registers so that the unwinder can save them on-demand only.
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #6 from Florian Weimer ---
Okay, please assume that __gxx_personality_v0 is a red herring. Apparently,
there is unwinding information for VFP registers, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #5 from Jakub Jelinek ---
I admit I don't know much about ARM unwinding, which is different from all the
other arches, but normally the personality routine doesn't call the landing pad
code nor anything similar, it should set some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #4 from Florian Weimer ---
So I'm not really an Arm person or a GCC person, but doesn't the personality
routine call the landing pad, as identified by the LDSA? And then that ends
with a call to __cxa_end_cleanup, which is clear a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #3 from Jakub Jelinek ---
Like in https://bugzilla.redhat.com/show_bug.cgi?id=1670069 (another wrong-code
that has been reported to us today), eh_personality.cc (__gxx_personality_v0)
is compiled this way since r266385. Though, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
Andrew Pinski changed:
What|Removed |Added
Known to work||8.1.0
Target Milestone|---
89 matches
Mail list logo
