https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101744
--- Comment #5 from Martin Liška ---
> > ```
> Just want to clarify that it's our developping lam version which is at
> https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master
What can you see for a vanilla GCC compiler?
O -fprofile-generate=dir tst.c
> $ ./a.out
> $ echo $?
> 0
> $ ls -l dir/*.gcda
> -rw-r--r-- 1 vlefevre vlefevre 0 2021-08-04 14:48:01
> dir/#home#vlefevre#a-tst.gcda
It works for me:
$ gcc --version
gcc (GCC) 12.0.0 20210804 (experimental)
$ df -h /tmp/ramdisk
Filesystem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100977
--- Comment #2 from Jakub Jelinek ---
Created attachment 51258
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51258=edit
gcc12-pr100977-1.patch
I think I found a bug in the makeucnid.c program, sometimes the ranges are
split
even when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from H.J. Lu ---
> A patch is posted at:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576697.html
I gave it a quick try by restarting a previously
> From: Andreas Schwab
> Cc: Richard Sandiford , Eli Zaretskii
>
> Date: Wed, 04 Aug 2021 15:35:04 +0200
>
> On Aug 04 2021, Eli Zaretskii via Gcc-bugs wrote:
>
> > I'd love to, but please tell me where. I couldn't find any
> > information about reporting libiberty bugs, sorry if I missed
>
> Date: Wed, 4 Aug 2021 14:03:21 +0100
> From: Jonathan Wakely
> Cc: gcc-bugs@gcc.gnu.org
>
> In GCC's bugzilla.
That's what I tried originally, but there's no libiberty there among
the various "components". So I decided the GCC Bugzilla was not the
right place. If it is the right place,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100977
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
Tamar Christina changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #8 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:9fcb8ec60302f5f110f94a885b618993c28d18d3
commit r12-2734-g9fcb8ec60302f5f110f94a885b618993c28d18d3
Author: Tamar Christina
On Aug 04 2021, Eli Zaretskii via Gcc-bugs wrote:
> I'd love to, but please tell me where. I couldn't find any
> information about reporting libiberty bugs, sorry if I missed
> something obvious.
The libiberty README says to report bugs to gcc-bugs@gcc.gnu.org.
Andreas.
--
Andreas Schwab,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101742
--- Comment #2 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:f2e5d2717d9e249edc5e0d45e49e4f9ef81fc694
commit r12-2732-gf2e5d2717d9e249edc5e0d45e49e4f9ef81fc694
Author: H.J. Lu
Date: Tue Aug 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
H.J. Lu changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #17 from Haoxin Tu ---
Thank you all for the detailed clarification! I have got the answer now. Let's
try together to make compilers a better place:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101638
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-08-04
In GCC's bugzilla. You could also report it to the sourceware.org
bugzilla for binutils, but I think GCC is the upstream for libiberty.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101744
--- Comment #4 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #3)
> x86 also get 2 new failures
> ```
> FAIL: c-c++-common/hwasan/alloca-gets-different-tag.c -O2 -flto
> -fuse-linker-plugin -fno-fat-lto-objects execution test
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #4 from Vincent Lefèvre ---
GCOV_EXIT_AT_ERROR is not documented in the man page.
Anyway, it doesn't seem to work:
$ export GCOV_EXIT_AT_ERROR=1
$ printenv GCOV_EXIT_AT_ERROR
1
$ gcc-test -O -fprofile-generate=dir tst.c
$ ./a.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
H.J. Lu changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #16 from Martin Liška ---
Oh, you are right, I moved syntactically valid inputs (with a potential UBSAN)
into the same bag with syntactically invalid input.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
> From: Richard Sandiford
> Cc: Eli Zaretskii
> Date: Wed, 04 Aug 2021 13:04:24 +0100
>
> Eli Zaretskii via Gcc-bugs writes:
> > The version of rust-demangle.c included with Binutils 2.37 doesn't
> > compile with MinGW:
> >
> > mingw32-gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -I.
>
Hi,
Eli Zaretskii via Gcc-bugs writes:
> The version of rust-demangle.c included with Binutils 2.37 doesn't
> compile with MinGW:
>
> mingw32-gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -I.
> -I../../binutils-2.37/libiberty/../include -W -Wall -Wwrite-strings
> -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #15 from Jakub Jelinek ---
(In reply to Richard Biener from comment #14)
> I disagree - syntactically valid input should not crash the compiler or make
> it slow. Yes, fixing cases with obvious non-sensical input might be low
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97010
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97010
Jonathan Wakely changed:
What|Removed |Added
CC||johelegp at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96193
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603
Bug 101603 depends on bug 48078, which changed state.
Bug 48078 Summary: accepts-invalid: taking address of private member function
from template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002
Bug 59002 depends on bug 48078, which changed state.
Bug 48078 Summary: accepts-invalid: taking address of private member function
from template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
Jonathan Wakely changed:
What|Removed |Added
CC||cgd at google dot com
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48078
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #2 from Vincent Lefèvre ---
An immediate exit() might yield other files, the terminal, etc. in a bad state.
IMHO, the best thing to do is to stop attempting to write to the file (possibly
attempt to remove it, but this might fail),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #14 from Richard Biener ---
(In reply to Martin Liška from comment #12)
> > I am asking the question because I am thinking whether the effort is
> > worthing or not if I devise a tool that can produce diverse syntactic valid
> > but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101774
--- Comment #2 from Jonathan Wakely ---
Not a regression as far as I can tell, GCC 4.1 did the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101774
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101774
Jonathan Wakely changed:
What|Removed |Added
CC||mytbk920423 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101775
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101775
Bug ID: 101775
Summary: G++ drops namespace prefix of argument in the
referenced function symbol
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101774
Bug ID: 101774
Summary: using-declaration and typedef alter name for linkage
purposes of unnamed struct
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53181
--- Comment #7 from Jonathan Wakely ---
GCC 7 accepts it in C++17 mode because of r241137
Implement P0386R2 - C++17 inline variables
That's because an out-of-class definition is not needed in C++17, the compiler
will generate one from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90642
--- Comment #5 from Jonathan Wakely ---
Fixed by r11-1571: c++: Refinements to "more constrained".
And the backport r10-8343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
--- Comment #1 from Richard Biener ---
The question is what to do, exit() or alternatively simply stop attempting to
write to the file? (or even remove it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101756
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101756
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:87a0b607e40f8122c7fc45d496ef48799fe11550
commit r12-2727-g87a0b607e40f8122c7fc45d496ef48799fe11550
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
--- Comment #9 from Richard Biener ---
The full satd_8x4 looks like the following, the 2nd loop isn't to be
disregarded
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
#define HADAMARD4(d0, d1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773
Bug ID: 101773
Summary: errors when writing to .gcda file are not checked
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 91094, which changed state.
Bug 91094 Summary: BB vectorization is too quick to disable itself because of
possible unrolling needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91094
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 91094, which changed state.
Bug 91094 Summary: BB vectorization is too quick to disable itself because of
possible unrolling needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91094
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91094
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101759
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:af31cab04770f7a1a1da069415ab62ca2ef54fc4
commit r12-2726-gaf31cab04770f7a1a1da069415ab62ca2ef54fc4
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101743
--- Comment #2 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:9f26640f7b89c771b0ebffd7e7f5019d0709a955
commit r12-2724-g9f26640f7b89c771b0ebffd7e7f5019d0709a955
Author: liuhongt
Date: Wed Aug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101756
--- Comment #4 from Richard Biener ---
So we have
of_14 = of.3[iter.9_16];
ea_13 = ea.2[iter.9_16];
kk_3 = kk.4[iter.9_16];
_32 = kk_3 != 0;
_33 = ea_13 != -1;
_43 = ea_13 != -2;
_36 = MAX_EXPR <_33, _43>;
_41 = _32 < _36;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85251
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-08-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64615
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101763
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101763
--- Comment #3 from Aldy Hernandez ---
evrp is on the chopping block for this release, and if everything goes
according to plan, so will VRP.
If VRP survives this release, we can go back and fix things like this.
However, if you feel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90642
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > This seems fixed in GCC 11+.
>
> And in GCC 10.4.
I meant 10.3.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90642
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> This seems fixed in GCC 11+.
And in GCC 10.4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90642
--- Comment #2 from Andrew Pinski ---
This seems fixed in GCC 11+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749
--- Comment #7 from Jakub Jelinek ---
(In reply to Martin Liška from comment #6)
> (In reply to Xi Ruoyao from comment #1)
> > I guess it's fixed in trunk by something in
> > 90e46074e6b3561ae7d8ebd205127f286cc0c6b6:
>
> Does it really fix the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90085
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2019-04-16 00:00:00 |2021-8-4
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #13 from Haoxin Tu ---
(In reply to Martin Liška from comment #12)
Ok, got you. Thanks for your speedy reply~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #12 from Martin Liška ---
>
> (1)From my understanding, compilers should compile well (no crashing or
> performance issue) with those test programs although they contain UB.
Yes, a compiler should produce a valid error message and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #7 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #6)
> On Wed, 4 Aug 2021, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
> >
> > --- Comment #5 from Tamar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53181
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2019-02-11 00:00:00 |2021-8-4
--- Comment #6 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101769
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101765
--- Comment #1 from Iain Sandoe ---
I am not sure that a VLA can be used in a coroutine (neither can alloca, if I
remember correctly) [so not sure that this is ICE on valid, it could be ICE on
invalid]
Either way, we should not ICE from it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101769
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4d562591018a51f155a2e5d8b9f3e5860111a327
commit r12-2721-g4d562591018a51f155a2e5d8b9f3e5860111a327
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #11 from Haoxin Tu ---
Hi all.
I hope you all are doing well.
I am sorry to bother you again. May I ask a quick question about how do you
treat the bug-revealing test case which may include the valid syntax but
contain the UB?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101772
Bug ID: 101772
Summary: [12 regression] ICE in ix86_expand_epilogue, at
config/i386/i386.c:9267
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39328
Andrew Pinski changed:
What|Removed |Added
CC||modysk at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61936
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40664
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101749
Martin Liška changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86558
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86703
Andrew Pinski changed:
What|Removed |Added
Known to work||9.1.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
Yujie Yang changed:
What|Removed |Added
CC||yangyujie at alumni dot
sjtu.edu.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59931
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #6 from rguenther at suse dot de ---
On Wed, 4 Aug 2021, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
>
> --- Comment #5 from Tamar Christina ---
> And yes the same semantics apply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040
--- Comment #7 from Andrew Pinski ---
GCC, ICC, clang and MSVC all fail the same way. Are we sure this is valid?
Even this fails:
void(Derived:: *t)() = ::bar;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101769
--- Comment #2 from Richard Biener ---
free_all2_r loses it during CDDCE1 which elides the original while loop. Then
tail-recursion discovers a new loop from the following IL
void free_all2_r (struct Node * n_)
{
struct Node * t;
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #5 from Tamar Christina ---
And yes the same semantics apply to 'i', but if I read it right the patch in
r12-2523 is tracking variables that are read but never written to. So 'i'
escaped the same issue because it's written to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101744
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66766
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59342
--- Comment #1 from Andrew Pinski ---
Seems fixed in GCC 6+ (but I can't figure out what fixed it).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
--- Comment #4 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #3)
> On Tue, 3 Aug 2021, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101750
> >
> > --- Comment #2 from Tamar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59144
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58428
--- Comment #1 from Andrew Pinski ---
ICC rejects it with the following message:
(5): error: a qualified friend template declaration must refer to a
specific previously declared template
template friend class A::B;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-08-04
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47929
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2013-11-10 00:00:00 |2021-8-3
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52460
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2012-03-02 00:00:00 |2021-8-3
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52809
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Severity|minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53251
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44906
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|NEW
Last reconfirmed|2011-09-23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96193
--- Comment #5 from Andrew Pinski ---
(In reply to Johel Ernesto Guerrero Peña from comment #4)
> It actually fails for dependent calls. See https://godbolt.org/z/E64Pbb.
This seems to have been fixed in GCC 11+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101769
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-08-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39970
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2018-09-13 00:00:00 |2021-8-3
--- Comment #11 from Andrew
201 - 300 of 300 matches
Mail list logo
