https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111953
Andrew Pinski changed:
What|Removed |Added
Summary|stringify operator #|stringify operator #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111930
Andrew Pinski changed:
What|Removed |Added
Summary|aarch64: SME is still not |aarch64: SME should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112367
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112108
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid, wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112361
--- Comment #5 from Andrew Pinski ---
The patch that caused this one, also causes a bootstrap comparison failure with
--with-arch=skylake-avx512, see PR 112374 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
Andrew Pinski changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
Andrew Pinski changed:
What|Removed |Added
Host||x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
Andrew Pinski changed:
What|Removed |Added
Summary|--with-arch=native |[14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
--- Comment #1 from Andrew Pinski ---
Testing with `--with-arch=skylake`, if that works will try with
`skylake-avx512`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
Bug ID: 112374
Summary: --with-arch=native bootstrap is broken on `Xeon(R)
D-2166NT`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369
Andrew Pinski changed:
What|Removed |Added
Summary|[14 regression] ICE when|[14 regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-checking
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|needs-reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98541
--- Comment #4 from CVS Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:6e9ee44d96e5bda8808dd9d8ccf58d2525383f6b
commit r14-5115-g6e9ee44d96e5bda8808dd9d8ccf58d2525383f6b
Author: Martin Uecker
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321
--- Comment #5 from Edwin Lu ---
(In reply to seurer from comment #3)
This also appears in GCC 14 for riscv64 targets with the same output pattern
above. After a quick comparison with the expected output, this output is
missing
> contract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97245
--- Comment #5 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:5340f48b7639fcc874f64aac214f9ef9ae43d43e
commit r14-5114-g5340f48b7639fcc874f64aac214f9ef9ae43d43e
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104320
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50755
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92887
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105660
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110703
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109450
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109450
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 109970, which changed state.
Bug 109970 Summary: -Wstringop-overflow should work with parameter forward
declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109970
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109970
uecker at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112373
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112373
Bug ID: 112373
Summary: cppcheck: libcpp/charset.cc: 3 * obvious performance
issue
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70418
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91038
uecker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112368
--- Comment #2 from Francois-Xavier Coudert ---
Could have been fixed by 8c40b72036c967fbb1d1150515cf70aec382f0a2
But the set of failures on Linux and Darwin are not exactly the same, so we
will see in the next regtest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193
uecker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100
uecker at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |14.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101604
Bug 101604 depends on bug 98536, which changed state.
Bug 98536 Summary: warning with -Wvla-parameter for unspecified bound getting
specified later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98536
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98536
uecker at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||11.1.0
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112372
--- Comment #4 from Giuliano Procida ---
The provided example was exactly my original test case.
It's part of our test suite for
https://android.googlesource.com/platform/external/stg/.
I'm currently running multiple versions of GCC and Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84510
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101027
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101027
Andrew Pinski changed:
What|Removed |Added
CC||oremanj at mit dot edu
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112360
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97245
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112372
--- Comment #3 from Andrew Pinski ---
(In reply to Giuliano Procida from comment #2)
> The symbols are not aliased (which is what I thought might have happened
> with very aggressive optimisations). If they had been aliased, it would be
> much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112368
--- Comment #1 from Andrew Pinski ---
I was getting similar failures on x86_64-linux-gnu for the last week of October
too. I wonder if this is now fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112372
--- Comment #2 from Giuliano Procida ---
The symbols are not aliased (which is what I thought might have happened with
very aggressive optimisations). If they had been aliased, it would be much
harder to give the symbols types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112372
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112372
Bug ID: 112372
Summary: GCC omits function location in DWARF at higher
optimisation levels
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769
--- Comment #6 from Andrew Pinski ---
(In reply to Shaohua Li from comment #5)
> I probably bisected to the wrong commit. I bisected it again and it should
> be r14-2675-gef28aadad6e
Right, but that does not mean the underlying issue is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97245
--- Comment #3 from anlauf at gcc dot gnu.org ---
Potential fix:
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index f848e52be4c..9e3571d3dbe 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -5064,6 +5064,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110903
--- Comment #4 from Andrew Pinski ---
(In reply to Thomas Koenig from comment #3)
> The code from comment#2 and from comment#3 no longer calls foo
> with current trunk, r14-5108-g751fc7bcdcdf25 .
>
> Now, to see which commit fixed it...
My
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92887
--- Comment #9 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:413ac2c8608cd0378955af27f69e45274b025b32
commit r14-5111-g413ac2c8608cd0378955af27f69e45274b025b32
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369
--- Comment #4 from Andrew Pinski ---
(In reply to Sam James from comment #3)
> (In reply to Sam James from comment #2)
> > Created attachment 56504 [details]
> > Hti5.cpp.ii
> >
> > Kostadin started a reduction earlier and got this. It needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110903
--- Comment #3 from Thomas Koenig ---
The code from comment#2 and from comment#3 no longer calls foo
with current trunk, r14-5108-g751fc7bcdcdf25 .
Now, to see which commit fixed it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112288
--- Comment #9 from Fabio Alemagna ---
(In reply to Patrick Palka from comment #8)
> The issue was probably latent before r6-6830. The testcase is kind of
> strange,
It's the "friend injection" technique. In this case, it's used to create a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369
--- Comment #3 from Sam James ---
(In reply to Sam James from comment #2)
> Created attachment 56504 [details]
> Hti5.cpp.ii
>
> Kostadin started a reduction earlier and got this. It needs some cleaning up.
btw, his was reduced from the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369
--- Comment #2 from Sam James ---
Created attachment 56504
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56504=edit
Hti5.cpp.ii
Kostadin started a reduction earlier and got this. It needs some cleaning up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111766
Sam James changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112288
--- Comment #8 from Patrick Palka ---
The issue was probably latent before r6-6830. The testcase is kind of strange,
e.g. 'slot_allocated' is defined within 'allocate_slot' instead of within
'slot', which would arguably be more natural given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #11 from Martin Uecker ---
This is one possible way to read it. But as written, I think one can easily
understand it the other way, because calloc never mentions requested total size
but only about space for an array of objects of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #10 from joseph at codesourcery dot com ---
The wording refers to "the size requested", which I consider to be the
product of two arguments in the case of calloc - not a particular argument
to calloc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111766
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111766
--- Comment #3 from Andrew Macleod ---
fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111766
--- Comment #2 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:7ab79a40b546a1470abaf76bec74c63e9990fe47
commit r14-5110-g7ab79a40b546a1470abaf76bec74c63e9990fe47
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #9 from Martin Uecker ---
(In reply to jos...@codesourcery.com from comment #7)
> I believe "size requested" refers to the product nmemb * size in the case
> of calloc, so getting the arguments the "wrong" way round does not affect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263
Jonathan Wakely changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315
--- Comment #6 from Rimvydas (RJ) ---
(In reply to Xi Ruoyao from comment #5)
> Maybe related to PR112263 but I'm not sure.
Can confirm that with patch posted at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263#c7 the stacktrace.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #7 from joseph at codesourcery dot com ---
I believe "size requested" refers to the product nmemb * size in the case
of calloc, so getting the arguments the "wrong" way round does not affect
the required alignment. The point of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950
--- Comment #9 from Tamar Christina ---
Right, I've tried to apply that patch to my early break patch series and many
of the tests fail, all the same way in compute_live_loop_exits.
I guess we'll have a conflict here. So I'll post my patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #3 from Mikael Morin ---
Possible culprit:
ifunction.m4 has this code:
retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
if (alloc_size == 0)
{
/* Make sure we have a zero-sized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369
--- Comment #1 from Andrew Pinski ---
Reducing ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112370
--- Comment #1 from Alexander Grund ---
Created attachment 56503
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56503=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #2 from Mikael Morin ---
If dim == 3, the ubound and shape are (/ 9, 3, 7 /) as expected.
That is, the problem only arises if the resulting array is empty.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #1 from Mikael Morin ---
(In reply to Mikael Morin from comment #0)
> i = 1
> (...)
> r = sum(a, dim=i)
If i is inlined, that is
r = sum(a, dim=1)
the shape and ubound are (/ 3, 0, 7 /) as expected.
The difference is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
Bug ID: 112371
Summary: Wrong upper bound for the result of reduction
intrinsics if the array is empty
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112370
Bug ID: 112370
Summary: -Wfree-nonheap-object in std::vector dtor on
sapphirerapids with -O3
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
||
--- Comment #8 from Richard Biener ---
Created attachment 56502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56502=edit
patch
Remaining and polished patch. Will ICE the following testcases I added:
FAIL: gfortran.dg/20231103-1.f90 -O (internal compiler er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112365
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P5
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112365
Sam James changed:
What|Removed |Added
Keywords||ice-checking
Summary|[14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335
--- Comment #10 from Jonathan Wakely ---
Ah, now I understand what you've been saying about the postcondition.
Yes, but the compiler doesn't know the postcondition, it's just words in the
standard, so not visible to the optimization passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112369
Bug ID: 112369
Summary: [14 regression] ICE when building webkit-gtk with
-march=raptorlake
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950
--- Comment #7 from Richard Biener ---
Bootstrap & regtest is fine but CPU 2017 has two ICEs I'm reducing right now.
Testing the vectorizable_live_operation simplification right now, will push new
test-coverage and defer the rest until next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112368
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Host|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112368
Bug ID: 112368
Summary: Darwin failures for avx256_move_by_pieces and
avx256_store_by_pieces
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950
--- Comment #6 from Richard Biener ---
Created attachment 56500
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56500=edit
patch
Some of the "fixup"s done earlier get in the way of simplifying things.
Specifically
/* If the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111066
Francois-Xavier Coudert changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042
Francois-Xavier Coudert changed:
What|Removed |Added
Build||x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769
--- Comment #5 from Shaohua Li ---
(In reply to Shaohua Li from comment #3)
> I tried to bisect it and it was bisected to r14-2674-gd0de3bf9175, which is
> different from the bisection point in bug110641
I probably bisected to the wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #20 from Martin Uecker ---
Ah, this is how it works. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
Sam James changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111721
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 111721, which changed state.
Bug 111721 Summary: RISC-V: Failed to SLP for gather_load in RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111721
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112347
--- Comment #18 from Martin Uecker ---
I think this can be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #6 from Martin Uecker ---
For reference, this is were the revised wording in C comes. This is
intentional. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2293.htm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950
--- Comment #5 from Richard Biener ---
t.c:6:10: note: init: stmt relevant? iftmp.0_9 = _32 ? 1 : iftmp.0_39;
t.c:6:10: note: vec_stmt_relevant_p: used out of loop.
t.c:6:10: note: vect_is_simple_use: operand _1 != 0, type of def:
1 - 100 of 165 matches
Mail list logo