https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337
--- Comment #2 from emsr at gcc dot gnu.org ---
It looks like try blocks in constexpr is in. p1002r1. This may be enough to
do some constexpr library bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53404
Eric Gallager changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69777
Eric Gallager changed:
What|Removed |Added
Blocks||87403
--- Comment #6 from Eric Gallager
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89051
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
Eric Gallager changed:
What|Removed |Added
CC||joseph at codesourcery dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406
--- Comment #13 from Ian Lance Taylor ---
I increased the timeouts and fixed another case. Let me know what it looks
like now. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89406
--- Comment #12 from ian at gcc dot gnu.org ---
Author: ian
Date: Sat Mar 2 00:50:30 2019
New Revision: 269338
URL: https://gcc.gnu.org/viewcvs?rev=269338=gcc=rev
Log:
PR go/89406
go/internal/gccgoimporter: remove temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530
--- Comment #7 from dcci ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to dcci from comment #5)
> > (In reply to Jakub Jelinek from comment #4)
> > > Also, we usually bisect which gcc revision introduced a problem and from
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89416
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87716
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757
Joseph S. Myers changed:
What|Removed |Added
CC||andres_takach at mentor dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89540
Joseph S. Myers changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89554
Bug ID: 89554
Summary: Incorrect location of warning
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77583
--- Comment #6 from Steve Kargl ---
On Fri, Mar 01, 2019 at 09:58:43PM +, anlauf at gcc dot gnu.org wrote:
> (In reply to kargl from comment #4)
> > (In reply to Manuel López-Ibáñez from comment #2)
> > > check_conflict is sometimes called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77583
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
--- Comment #2 from David Malcolm ---
Can you attach the testcase please, rather than pasting it as a comment. I
can't reproduce the note from the example, but whitespace is significant here,
and I'm not sure roundtripping through a BZ comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88820
--- Comment #7 from Marek Polacek ---
A little bit more simplified:
template struct S;
template struct W {
template static int foo();
bool b = foo();
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67894
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> Works also if len_trim is replaced by len.
>
> I wonder if this is related to PR86249.
Sorry, off-by-one, that should have been PR86248.
Also the date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89421
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596
--- Comment #8 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #7)
> The above testcase reproduced, reduced to following, started with r266385.
> Note, this testcase ICEd in gcc 7.x and earlier too, got fixed with r258504
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
--- Comment #22 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 1 19:06:36 2019
New Revision: 269332
URL: https://gcc.gnu.org/viewcvs?rev=269332=gcc=rev
Log:
PR middle-end/89497
* g++.dg/tree-prof/devirt.C: Adjust also the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89452
--- Comment #6 from Baykov Nikita ---
There is one more issue.
ISO/IEC 14882:2017(E) and N4800 specify that seekpos(sp, which) and
seekoff(off_type(sp), ios_base::beg, which) should be equivalent, but it seems
that they are not equivalent in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89416
--- Comment #9 from Jakub Jelinek ---
So fixed now for real?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89421
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89553
Bug ID: 89553
Summary: "static const double x = 2" is treated equivalent to
"static constexpr double x = 2"
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89459
--- Comment #5 from Andres Takach ---
Works in 8.3.0. Needed to use lib64 to link, otherwise was picking up earlier
version of the library that had the bug.
Version 6.2.0 (as first reported) does have the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89540
--- Comment #4 from Andres Takach ---
Works in 8.3.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #6 from Jakub Jelinek ---
And in the *.sra dump, I really don't see any way how it could be two:
MEM[(struct &) clique 22 base 1] ={v} {CLOBBER};
...
n1D.7146 ={v} {CLOBBER};
...
MEM[(struct &) clique 27 base 1] ={v}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #11 from Piotr Kubaj ---
Hm, sorry, I copied the Entering directive from a line before.
Nevertheless, setting -O1 helps with GCC 7 and 8.
But building GCC 9 still fails (I'm testing the newest snapshot). I tried both
-O0 and -O1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
--- Comment #14 from Dominique d'Humieres ---
The patch in comment 13 fixes the ICE for pr69102.c. Testing will start soon.
Thanks for the work!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538
--- Comment #3 from Taewook Oh ---
Here's the compiler command and the preprocessed source.
command: https://gist.github.com/taewookoh/45e710594497b887e2ac54168c86c17f
source: https://gist.github.com/taewookoh/00f38b4a2f617e78b30d33c8103a7703
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #5 from Jakub Jelinek ---
You mean -fno-strict-aliasing? I guess many options change the behavior that
it doesn't trigger anymore.
In the #c3 dump, I really don't see how aliasing could matter though, all are
MEM_REFs with addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44859
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89548
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89548
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403
--- Comment #8 from Alex Henrie ---
Why weren't Manuel's patches accepted?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530
--- Comment #6 from Jakub Jelinek ---
(In reply to dcci from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Also, we usually bisect which gcc revision introduced a problem and from
> > that change we can often see what goes wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89552
Azat changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85899
--- Comment #5 from Alexander Monakov ---
Author: amonakov
Date: Fri Mar 1 16:18:04 2019
New Revision: 269319
URL: https://gcc.gnu.org/viewcvs?rev=269319=gcc=rev
Log:
haifa-sched: handle fallthru edge to EXIT block (PR 85899)
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #4 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #3)
> ...But in the sra pass dump that possibility is gone:
I am still double checking because it is easy to make a mistake but I
have seen a (potential) path in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85899
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89552
Bug ID: 89552
Summary: odr namespace
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530
--- Comment #5 from dcci ---
(In reply to Jakub Jelinek from comment #4)
> Also, we usually bisect which gcc revision introduced a problem and from
> that change we can often see what goes wrong quickly. Both Red Hat and SUSE
> have terrabytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89551
Bug ID: 89551
Summary: [9 regression] Test case gcc.dg/uninit-pred-8_b.c
fails after r269302
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530
--- Comment #4 from Jakub Jelinek ---
Also, we usually bisect which gcc revision introduced a problem and from that
change we can often see what goes wrong quickly. Both Red Hat and SUSE have
terrabytes of built gcc revisions to make such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530
--- Comment #3 from Jakub Jelinek ---
In GCC people don't disable passes usually, but just use -fdump-tree-all and/or
-da and look at the dumps where it broke. We do have
-fdisable--{,=range-list} options to disable individual passes if
needed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89452
--- Comment #5 from Baykov Nikita ---
I apologize for my careless mistake.
I have some other questions that I would like to clarify. Hope it will be right
to do it here.
1. You mentioned that pptr() was no longer required to be null pointer in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89452
--- Comment #4 from Baykov Nikita ---
I apologize for my careless mistake.
I have some other questions that I would like to clarify. Hope it will be right
to do it here.
1. You mentioned that pptr() was no longer required to be null pointer in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89532
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Fri Mar 1 15:57:46 2019
New Revision: 269318
URL: https://gcc.gnu.org/viewcvs?rev=269318=gcc=rev
Log:
PR c++/89537 - missing location for error with non-static member fn.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89532
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Fri Mar 1 15:55:56 2019
New Revision: 269317
URL: https://gcc.gnu.org/viewcvs?rev=269317=gcc=rev
Log:
PR c++/89532 - ICE with incomplete type in decltype.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89542
--- Comment #4 from puffydaemon at gmail dot com ---
Okay, I am going to try with clang...
El vie., 1 mar. 2019 a las 10:37, rguenth at gcc dot gnu.org (<
gcc-bugzi...@gcc.gnu.org>) escribió:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89542
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530
--- Comment #2 from dcci ---
Thanks Jakub. We're trying to report more of these but it's hard to filter out
duplicates. A possible way we thought was that of stopping at some point in the
pipeline (so running a subset of the optimizations), to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89051
--- Comment #8 from Martin Sebor ---
The test passes without the -Wno-error=pedantic so it looks like it's not
necessary. I must have thought it was for some reason.
But to make sure I understand you correctly: do you mean that -Wpedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952
--- Comment #16 from Daniel Borkmann ---
(In reply to Martin Liška from comment #15)
> (In reply to Daniel Borkmann from comment #12)
> > I've been looking into this issue quite recently and improved the benchmark
> > tool a bit along the way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550
Bug ID: 89550
Summary: Spurious array-bounds warning when using
__PRETTY_FUNCTION__ as a string_view.
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2019-3-1
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
Bug ID: 89549
Summary: -Wmisleading-indentation is disabled from this point
onwards, since column-tracking was disabled due to the
size of the code/headers
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952
Martin Liška changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
--- Comment #15 from Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35362
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #12 from Michael Matz ---
(In reply to H.J. Lu from comment #11)
> (In reply to Michael Matz from comment #10)
> > Ah, I missed that. Yeah, I'd like to be co-owner.
>
> Please send me your gitlab account name.
Err, right, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #11 from H.J. Lu ---
(In reply to Michael Matz from comment #10)
> Ah, I missed that. Yeah, I'd like to be co-owner.
Please send me your gitlab account name.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #10 from Michael Matz ---
Ah, I missed that. Yeah, I'd like to be co-owner.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #9 from H.J. Lu ---
(In reply to Michael Matz from comment #7)
> What about this variant of the second part?
>
Hi Michael,
I moved x86 psABI repo to
https://gitlab.com/x86-psABIs
Would you like to be co-owners?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89539
--- Comment #6 from Jürgen Reuter ---
Yep, fixed, thanks for the overnight reaction^^. (and next time I think I have
the guts to mark it as 'bootstrap' right from the beginning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
H.J. Lu changed:
What|Removed |Added
Attachment #45868|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
--- Comment #13 from Andrey Belevantsev ---
So now I understand, finally. We move up an sp decrement and are supposed to
check that sp is available on the paths that are not touched by the move. There
are several successors of the move target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89051
--- Comment #7 from Martin Liška ---
@Martin:
I've noticed that these tests has a suspicious construct:
gcc/testsuite/g++.dg/ext/flexary16.C:// { dg-options "-Wpedantic
-Wno-error=pedantic" }
gcc/testsuite/g++.dg/ext/flexary18.C:// {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #7 from Michael Matz ---
What about this variant of the second part?
diff --git a/x86-64-ABI/low-level-sys-info.tex
b/x86-64-ABI/low-level-sys-info.tex
index 66270b9..93b5e95 100644
--- a/x86-64-ABI/low-level-sys-info.tex
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89513
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 89513, which changed state.
Bug 89513 Summary: constexpr functions with function try block shouldn't be
accepted at least with -pedantic in -std=c++{11,14,17} modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89513
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 1 14:20:03 2019
New Revision: 269314
URL: https://gcc.gnu.org/viewcvs?rev=269314=gcc=rev
Log:
Implement P1002R1, Try-catch blocks in constexpr functions
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
H.J. Lu changed:
What|Removed |Added
Attachment #45866|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89491
--- Comment #5 from Dávid Bolvanský ---
Let's take the original example with small modification:
int square(int x) { return x*x; }
int add(int x) { return x + x; }
typedef int (*p)(int);
static const p arr[4] = {square, add};
int test(int x) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89517
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89517
--- Comment #2 from Tamar Christina ---
Author: tnfchris
Date: Fri Mar 1 14:07:38 2019
New Revision: 269313
URL: https://gcc.gnu.org/viewcvs?rev=269313=gcc=rev
Log:
AArch64: Make every option in options.def one line (GCC-8).
Due to config.gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89544
--- Comment #4 from Richard Earnshaw ---
An alternative way of fixing this might be if the backend could somehow control
DECL_ARG_TYPE for the parameter, to set it to a variant without the additional
alignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #5 from H.J. Lu ---
(In reply to Richard Biener from comment #3)
> It probably implements what we do but changing 32 to 1024*1024 shows that we
> (possibly up to MAX_OFILE_ALIGNMENT) align parameters to arbitrarily high
X86 backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #4 from H.J. Lu ---
(In reply to Michael Matz from comment #2)
> I think we should say something about the addresses of stack slots
> individual overaligned arguments as well (i.e. that the slot itself will
> also be aligned
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #3 from Richard Biener ---
It probably implements what we do but changing 32 to 1024*1024 shows that we
(possibly up to MAX_OFILE_ALIGNMENT) align parameters to arbitrarily high
values. Maybe we should cap that to some value (but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89547
--- Comment #2 from maqsood3525 at live dot com ---
Hi ,
pardon me for the my tardinees , i should have mentioned the gcc version that
is gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
the -flto output is attached.
Thanks
Haroon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
--- Comment #12 from Andrey Belevantsev ---
(In reply to Jakub Jelinek from comment #11)
> Any progress on this?
I know what happens but am not fully sure as of why. The sp register should not
be available for the problematic move, so I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89517
--- Comment #1 from Tamar Christina ---
Author: tnfchris
Date: Fri Mar 1 13:34:14 2019
New Revision: 269309
URL: https://gcc.gnu.org/viewcvs?rev=269309=gcc=rev
Log:
AArch64: Make every option in options.def one line
Due to config.gcc all the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89547
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #3 from Jakub Jelinek ---
The gimple dumps aren't exactly readable with so many different tuple/type etc.
types, where it is unclear what exact offset is something being stored at.
That said, in cplxlower1 I still see a possibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #2 from Michael Matz ---
I think we should say something about the addresses of stack slots individual
overaligned arguments as well (i.e. that the slot itself will also be aligned
accordingly), not just for the overall effect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87234
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #1 from H.J. Lu ---
Created attachment 45866
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45866=edit
An psABI patch
How about this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89548
Bug ID: 89548
Summary: reinterpret_cast treats xvalue as prvalue
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546
--- Comment #2 from Jakub Jelinek ---
When get_tail is esra optimized the old way, main is:
int n1$tail$head$payload;
struct type D.9885;
struct tuple D.9880;
struct type D.9879;
struct type D.9878;
struct type D.9875;
[local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89541
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84072
Bug 84072 depends on bug 86952, which changed state.
Bug 86952 Summary: Avoid jump table for switch statement with
-mindirect-branch=thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952
--- Comment #13 from H.J. Lu ---
Reopened with new info.
1 - 100 of 161 matches
Mail list logo
