https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #33 from CVS Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:537c96588026aec09b9a00d6d0f3670f612428b5
commit r12-7346-g537c96588026aec09b9a00d6d0f3670f612428b5
Author: Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #32 from Richard Biener ---
(In reply to Segher Boessenkool from comment #31)
> A straightforward backport of that gives
>
> In file included from /home/segher/src/gcc/gcc/config/rs6000/rs6000.cc:28765:
> ./gt-rs6000.h:143:6: error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #31 from Segher Boessenkool ---
A straightforward backport of that gives
In file included from /home/segher/src/gcc/gcc/config/rs6000/rs6000.cc:28765:
./gt-rs6000.h:143:6: error: 'atomic_update_decl' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #30 from Segher Boessenkool ---
(In reply to Richard Biener from comment #28)
> Huh, yes - I assumed that had been fixed. Segher? Can you please fix that
> GTY bug?
I'll look at it. It's over three years old, will need some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #29 from Arseny Solokha ---
Let me clarify: I cannot reproduce that ICE from comment 5 as well, but
probably because of the same underlying reason that "fixed" the ICE from
comment 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #27 from Arseny Solokha ---
Does it make sense to commit the patch from comment 17 (or comment 18)
nonetheless?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #25 from Arseny Solokha ---
I cannot reproduce it anymore w/ gcc 12.0.1 20220220 snapshot
(g:e49508ac6b36adb8a2056c5a1fb6e0178de2439d).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #24 from rguenther at suse dot de ---
On Fri, 21 Dec 2018, asolokha at gmx dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
>
> --- Comment #23 from Arseny Solokha ---
> (In reply to rguent...@suse.de from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #23 from Arseny Solokha ---
(In reply to rguent...@suse.de from comment #22)
> Where do the vars get created from? (backtrace from the
> gimple_add_tmp_var places?)
(gdb) where
#0 gimple_add_tmp_var (tmp=0x77fcf510)
at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #22 from rguenther at suse dot de ---
On Fri, 21 Dec 2018, asolokha at gmx dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
>
> --- Comment #21 from Arseny Solokha ---
> (In reply to Arseny Solokha from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #21 from Arseny Solokha ---
(In reply to Arseny Solokha from comment #13)
> In decl_address_invariant_p() we hit this break:
>
> 3423 case VAR_DECL:
> 3424 if ((TREE_STATIC (op) || DECL_EXTERNAL (op))
> 3425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #20 from Segher Boessenkool ---
The original problem doesn't fail for me also if I use a glibc >= 2.19
(I used 2.28).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #19 from Arseny Solokha ---
Patch from comment 17 fixes the second ICE (the one filed in comment 5).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #18 from Segher Boessenkool ---
Or, if you want your compiler to build:
===
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 5120202..c041f15 100644
--- a/gcc/config/rs6000/rs6000.c
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #17 from Segher Boessenkool ---
Like this:
===
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 5120202..429eac5 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -38865,7 +38865,9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #16 from rguenther at suse dot de ---
On Thu, 20 Dec 2018, asolokha at gmx dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
>
> --- Comment #15 from Arseny Solokha ---
> In build_atomic_assign() we have
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #15 from Arseny Solokha ---
In build_atomic_assign() we have
4222 /* Create the expressions for floating-point environment
4223 manipulation, if required. */
4224 bool need_fenv = (flag_trapping_math
4225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #14 from Segher Boessenkool ---
And none of the compilers I built crash. (Most have checking enabled, but some
not, so that's not it either).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #13 from Arseny Solokha ---
In decl_address_invariant_p() we hit this break:
3423 case VAR_DECL:
3424 if ((TREE_STATIC (op) || DECL_EXTERNAL (op))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #12 from rguenther at suse dot de ---
On Tue, 11 Dec 2018, asolokha at gmx dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
>
> --- Comment #10 from Arseny Solokha ---
> Could your r266973 fix a root cause of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #11 from Segher Boessenkool ---
AT12.0 however, like on godbolt, does in fact crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #10 from Arseny Solokha ---
Could your r266973 fix a root cause of this issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #9 from Segher Boessenkool ---
I cannot get that to fail either, with a trunk compiler :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #8 from Arseny Solokha ---
Aha. Segher, you've helpfully reminded me about -msoft-float w/ your recent
commit. So it's not (solely) my misconfiguration once again:
https://gcc.godbolt.org/z/sshcIF
(it's g++, because gcc for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|UNCONFIRMED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #5 from Arseny Solokha ---
And if my guess that the problem is somehow related to the handling of FPU-less
cores in the rs6000 and powerpcspe backends is correct, than I see whan might
be another manifestation of that issue:
%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #4 from Arseny Solokha ---
(In reply to rguent...@suse.de from comment #3)
> The
> powerpc64[le]-linux crosses insist that -mcpu=860 requires a 64bit CPU...
Which is strange, as 860 is a 32-bit CPU w/o FPU (perhaps a key here?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #3 from rguenther at suse dot de ---
On Wed, 21 Nov 2018, asolokha at gmx dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
>
> --- Comment #2 from Arseny Solokha ---
> Sure, will paste it tomorrow. In the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #2 from Arseny Solokha ---
Sure, will paste it tomorrow. In the meantime, could you please try w/ -m32 (or
w/o -m64) instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
34 matches
Mail list logo
