https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
Jürgen Reuter changed:
What|Removed |Added
Attachment #50391|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #5 from Jürgen Reuter ---
Created attachment 50393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50393&action=edit
New short reproducer, this time consistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #6 from Jürgen Reuter ---
Actually, the last example missed a line that I overeagerly deleted too much.
This one is the correct reproducer:
module m
implicit none
private
public :: m_t
type :: m_t
private
end type m_t
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #7 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #3)
> Here is a shorter reproducer, and this time it is the -fcheck=pointer that
> leads to the problem. I was able to reproduce this to 80 lines, leading to
> the erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99606
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.3
--- Comment #1 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99601
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99603
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99604
Richard Biener changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99605
Richard Biener changed:
What|Removed |Added
Summary|[11 regress] new test case |[11 regresson] new test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99607
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99610
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #8 from Paul Thomas ---
(In reply to Jürgen Reuter from comment #6)
> Actually, the last example missed a line that I overeagerly deleted too
> much. This one is the correct reproducer:
> module m
> implicit none
> private
> pub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99612
Bug ID: 99612
Summary: Remove "#pragma GCC system_header" from atomic file to
warn on incorrect memory order
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #9 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #8)
>
> Paul
$ gfortran -fcheck=pointer repro.f90
reuter@Manwe:~/local/packages/whizard/trunk/_build_flags/RT_20210315$ ./a.out
At line 38 of file repro.f90
Fortran r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
--- Comment #5 from Martin Liška ---
All right, can you please attach a pre-processed source file using -E option?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99445
--- Comment #7 from Martin Liška ---
@Jason: Can you please take a look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99607
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
Eric Botcazou changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98834
--- Comment #10 from Martin Liška ---
@Richi: Do you still need a bisection or is what Jakub provided accurately
identified?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99542
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fcefc59befd396267b824c170b6a37acaf10874e
commit r11-7683-gfcefc59befd396267b824c170b6a37acaf10874e
Author: Jakub Jelinek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
--- Comment #2 from Alex Coplan ---
> Unless I'm missing something, I don't think "Uxi" is a valid constraint.
> Perhaps the "Ux" constraint was intended instead?
D'oh, this is of course the union of the Ux (MVE-specific) constraint and the
"i"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99542
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2021-03-16
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99563
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:82085eb3d44833bd1557fdd932c4738d987f559d
commit r11-7684-g82085eb3d44833bd1557fdd932c4738d987f559d
Author: Jakub Jelinek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #10 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #9)
> (In reply to Paul Thomas from comment #8)
>
> >
> > Paul
>
> $ gfortran -fcheck=pointer repro.f90
> reuter@Manwe:~/local/packages/whizard/trunk/_build_flags/R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57141
Antonio changed:
What|Removed |Added
CC||aasdelat at yahoo dot es
--- Comment #5 from A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #29 from Jakub Jelinek ---
So fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96307
--- Comment #12 from Kito Cheng ---
> This disables the CC_HAS_KASAN_GENERIC config of the kernel, making KASAN
> unavailable.
H, I checked with kernel source code, it only feed
-fsanitize=kernel-address during checking, but in fact it must
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97252
--- Comment #3 from Alex Coplan ---
FWIW, for the related testcase (which we also ICE on):
typedef int __attribute((vector_size(16))) V;
V v;
void f() { v = (V){4095}; }
clang pushes the constant out to the constant pool:
$ clang -target arm i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Bug ID: 99613
Summary: Static variable destruction order race condition
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99614
Bug ID: 99614
Summary: diagnostic-manager.cc:85: possible missing copy
constructor ?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57141
--- Comment #6 from Tobias Burnus ---
(In reply to Antonio from comment #5)
> I am experiencing this problem in gfortran from gcc version 10.2.0 and the
> same workaround also works. It seems to be a regression.
Hi Antonio.
Do you use exactly t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99615
Bug ID: 99615
Summary: gcc/cp/decl.c:10038:possible null pointer dereference
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99616
Bug ID: 99616
Summary: gcc/cp/decl.c:12220: pointless test ?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99617
Bug ID: 99617
Summary: gcc/cp/coroutines.cc:2807: member variables not
initialised in constructor ?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99496
--- Comment #14 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:7b900dca607dceaae2db372365f682a4979c7826
commit r11-7687-g7b900dca607dceaae2db372365f682a4979c7826
Author: Nathan Sidwell
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99496
--- Comment #15 from Nathan Sidwell ---
oops, I was juggling too many computers yesterday
* 7b900dca607 2021-03-15 | c++: Incorrect type equivalence [PR 99496]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99614
Richard Biener changed:
What|Removed |Added
Version|unknown |11.0
--- Comment #1 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
Paul Thomas changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99296
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99420
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99433
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93632
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442
Richard Biener changed:
What|Removed |Added
CC||jeanmichael.celerier@gmail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442
--- Comment #10 from Richard Biener ---
Mark, you're looking after -gsplit-dwarf - can you comment on whether we can
drop the -gpubnames "requirement"?
In the end I'd suggest to change the implementation to emit pubnames from the
pruned DIE tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99614
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99612
--- Comment #1 from Jonathan Wakely ---
I'd prefer if the compiler just got it right. This seems like a warning that
should fire even in system headers. Or it should track that the value is a
function parameter and came from a non-system header a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99615
Martin Liška changed:
What|Removed |Added
CC||fjahanian at apple dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99616
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99617
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99617
--- Comment #2 from Iain Sandoe ---
(In reply to Martin Liška from comment #1)
> I'm going to handle it.
actually, I was already on it .. but if you want to...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99617
--- Comment #3 from Martin Liška ---
(In reply to Iain Sandoe from comment #2)
> (In reply to Martin Liška from comment #1)
> > I'm going to handle it.
>
> actually, I was already on it .. but if you want to...
I have a patch with changelog don
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Jakub Jelinek changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #4 from Michal Zientkiewicz ---
The problem is that the order of destruction is incorrect if there's a race
condition.
Consider 2 threads initializing static variables S1 and S2:
Thread A Thread B
acquire
construct S1
re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99617
--- Comment #4 from Iain Sandoe ---
(In reply to Martin Liška from comment #3)
> (In reply to Iain Sandoe from comment #2)
> > (In reply to Martin Liška from comment #1)
> > > I'm going to handle it.
> >
> > actually, I was already on it .. but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #47 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:6ee24638ed0ad51e568c799bacf149ba9bd7628b
commit r11-7688-g6ee24638ed0ad51e568c799bacf149ba9bd7628b
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:995a740cb01a0671a2082cb1ae13d0c356d4b568
commit r11-7689-g995a740cb01a0671a2082cb1ae13d0c356d4b568
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:6ee24638ed0ad51e568c799bacf149ba9bd7628b
commit r11-7688-g6ee24638ed0ad51e568c799bacf149ba9bd7628b
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99617
--- Comment #5 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Martin Liška from comment #3)
> > (In reply to Iain Sandoe from comment #2)
> > > (In reply to Martin Liška from comment #1)
> > I have a patch with cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #5 from Jakub Jelinek ---
The variables can be constructed even exactly at the same time, or at least the
ctors can be started concurrently and end concurrently. I don't think you can
rely on a particular ordering of the destructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #6 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> Or do you mean it is possible that for two unrelated variables
> variable 1 with its guard variable 2 with its guard
> __cxa_guard_acquire succeeds
> ct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #7 from Jakub Jelinek ---
Swapping __cxa_guard_release with __cxa_atexit would "fix" the case where the
user program would in all threads access all the local variables in the same
order. So all threads first access f<0>(), then f<1>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #8 from Michal Zientkiewicz ---
Jakub: You read coorectly, I was checking for global construction/destruction
order of many variables. I agree that a global lock is a heavy-handed solution
- and likely the only one that would always g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #9 from Michal Zientkiewicz ---
(My previous comment may seem unclear, so let me clarify):
The _demo_ is not very useful, but the example in the example from the previous
comment is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
Bug ID: 99618
Summary: `.gnu.debuglto_.debug_macro' referenced in section
`.gnu.debuglto_.debug_macro' of X defined in discarded
section
Product: gcc
Version: 11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #10 from Jakub Jelinek ---
Even the swapping of the two calls would be IMHO a significant slowdown.
Because __cxa_atexit under the hood holds a global lock (fortunately not across
the duration of the whole user ctor, but across the in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
--- Comment #6 from Arnd Bergmann ---
Created attachment 50395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50395&action=edit
preprocessed /usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h
I've changed from the Ubuntu gcc-11 s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99609
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491
Tobias Burnus changed:
What|Removed |Added
CC||Boyce at engineer dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
--- Comment #1 from Richard Biener ---
Hmm, so the linker complains that .debug_macro refers to COMDAT .debug_macro
which is discarded. Quite possibly the linker misses special-casing of
.debug_macro because it's called .gnu.debuglto_.debug_macr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #11 from Michal Zientkiewicz ---
Created attachment 50396
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50396&action=edit
Demo with dependent variables
I added a new demo which shows that dependent variable gets destroyed afte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #12 from Michal Zientkiewicz ---
As a side note - Clang emits the call to atexit between acquire and release and
the last demo works fine when compiled with Clang, but not GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99618
Martin Liška changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92935
Luc Van Oostenryck changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed|2021-03-08 00:00:00 |2021-3-16
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
Martin Liška changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #7 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |12.0
--- Comment #8 from Martin Liška --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99296
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
--- Comment #9 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:408d137027b1c39546d39fdbca7347b3dddba8ea
commit r11-7691-g408d137027b1c39546d39fdbca7347b3dddba8ea
Author: Martin Liska
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860
Bug 92860 depends on bug 99592, which changed state.
Bug 99592 Summary: arm: internal compiler error using arm_neon.h with -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
Jürgen Reuter changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99565
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99341
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99253
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:65767abfdc07547b5435083a5af6ab085e013a4d
commit r10-9447-g65767abfdc07547b5435083a5af6ab085e013a4d
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99224
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:7e9c43ce0d7b5ef1a1f11bf91d1a06614460b7d8
commit r10-9448-g7e9c43ce0d7b5ef1a1f11bf91d1a06614460b7d8
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99253
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #14 from Michal Zientkiewicz ---
https://eel.is/c++draft/basic.start.term#3
If the completion of the constructor or dynamic initialization of an object
with static storage duration strongly happens before that of another, the
complet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
Jake Hemstad changed:
What|Removed |Added
CC||jacobhemstad at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
seurer at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466
--- Comment #5 from Iain Buclaw ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Iain Buclaw from comment #3)
> > Oldest compiler version have tried it one is 8.4.0, and there's an ICE there
> > as well.
>
> On Darwin16 : ICE back to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99565
--- Comment #5 from Marek Polacek ---
I think I added OEP_LEXICOGRAPHIC specifically for -Wduplicated-branches
(do_warn_duplicated_branches used it first), so we can have it do whatever we
want for the warning. So your change looks fine to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99466
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Buclaw from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > (In reply to Iain Buclaw from comment #3)
> > > Oldest compiler version have tried it one is 8.4.0, and there's an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #16 from Jakub Jelinek ---
Created attachment 50399
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50399&action=edit
gcc11-pr99613.patch
Untested patch that swaps the two calls.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #6 from Vladimir Makarov ---
(In reply to Segher Boessenkool from comment #5)
> Thanks Vladimir. It is indeed a problem in LRA (or triggered by it).
> We have
> 8: {[r121:DI+low(unspec[`*.LANCHOR0',%2:DI]
> 47+0x92a4)]=asm_operan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99613
--- Comment #17 from Richard Biener ---
I think for the non-dependent case there's no good fix but the standard can be
read in a way that only the dependent case has well-defined order of
destruction.
1 - 100 of 147 matches
Mail list logo
