https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #7 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116594
Bug 116594 depends on bug 116590, which changed state.
Bug 116590 Summary: unrecognized opcode th.vmv8r.v th.vfrec7.v when compiling
for risc-v xtheadvector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116590
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116590
Cooper Qu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47253
--- Comment #9 from H.J. Lu ---
Created attachment 60445
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60445&action=edit
A patch
[hjl@gnu-tgl-3 pr47253]$ cat y.c
void t(), f();
void
decide(bool ok)
{
if (ok)
t();
else
f();
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97991
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #4 from Haochen Jiang ---
(In reply to Haochen Jiang from comment #3)
> Which makes this thing more weird than my expected is that avx10_2rounding
> and avx10_2minmax intrin file seems not reporting the warning. It also
> should from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #3 from Haochen Jiang ---
Which makes this thing more weird than my expected is that avx10_2rounding and
avx10_2minmax intrin file seems not reporting the warning. It also should from
my understanding, but it may shed the light of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767
--- Comment #23 from Sam James ---
(In reply to Xi Ruoyao from comment #22)
> Maybe it's worthy to try the new LLVM TBAA sanitizer for this?
Good idea. It has no complaints.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #2 from Haochen Jiang ---
My guess (and probably it should be) is on the push and pop target for AVX10
related options and evex512 usage causing the issue.
AVX10.2-256 will only use 256 size, and there is elsewhere enabling evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118809
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #1 from Andrew Pinski ---
Also notice the diagnostic does NOT mention which function this is from either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
--- Comment #12 from Haochen Jiang ---
And the define seems not to be the workaround for those two PRs. It is much
like a typo when moving things around for AVX10 since GCC13 (before AVX10
introduction), it is still wrapped by #ifdef.
: ---
Target: x86_64
```
#include
```
With -Wsystem-headers -std=c17 gives notices:
```
In file included from
/opt/compiler-explorer/gcc-trunk-20250209/lib/gcc/x86_64-linux-gnu/15.0.1/include/immintrin.h:151:
/opt/compiler-explorer/gcc-trunk-20250209/lib/gcc/x86_64-linux-gnu/15.0.1/include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
--- Comment #10 from Andrew Pinski ---
```
In file included from
/opt/compiler-explorer/gcc-trunk-20250209/lib/gcc/x86_64-linux-gnu/15.0.1/include/immintrin.h:61,
from :1:
/opt/compiler-explorer/gcc-trunk-20250209/lib/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
--- Comment #11 from Haochen Jiang ---
It should be #ifdef instead of #if here from my first glance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
Andrew Pinski changed:
What|Removed |Added
Component|preprocessor|target
Summary|[14/15 regres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
Andrew Pinski changed:
What|Removed |Added
CC||lukeshu at lukeshu dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118814
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118814
--- Comment #2 from Andrew Pinski ---
Wait this is a dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
--- Comment #8 from Andrew Pinski ---
https://github.com/srsran/srsRAN_4G/commit/94a06867a3c3efbb8c6eb36e1ac2fa5f1aa2dc07
I like how it was someone else that reported the issue to GCC 3 years later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Or PR 96174.
it was definitely to workaround PR 96174 (just checked and srsran uses
_mm512_cmp_ps_mask ).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96174
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.4
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
Sam James changed:
What|Removed |Added
Keywords||internal-improvement
--- Comment #1 from Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118814
Sam James changed:
What|Removed |Added
Summary|-Warray-bounds causes |[13/14/15 regression]
|in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118814
Bug ID: 118814
Summary: -Warray-bounds causes internal compiler error:
Segmentation fault during GIMPLE pass: vrp
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
Sam James changed:
What|Removed |Added
Summary|Compile error when using|[14/15 regression] Compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117315
--- Comment #17 from Sam James ---
Looking at trunk. LHS (-) is with malloc attribute (-> crashes), RHS (+) is
without (-> works).
In local-pure-const, we get:
```
--- a/libwsutil.so-wmem_tree.c.054t.local-pure-const1
+++ b/libwsutil.so-wmem_tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813
Bug ID: 118813
Summary: Compile error when using __OPTIMIZE__ without value
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118812
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118812
Bug ID: 118812
Summary: Improve diagnostic for non class used as a base class
(even a typedef)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: diagnos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96957
Andrew Pinski changed:
What|Removed |Added
See Also||https://bugs.llvm.org/show_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117315
Sam James changed:
What|Removed |Added
Attachment #59461|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #9 from Andrew Pinski ---
So looking into this slightly, tzdb_list deconstructor will call the
deconstructor of shared_ptr<_Node>. But that should always be called after the
deconstructor of BackgroundThread.
Oh I get the failure o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117315
--- Comment #15 from Sam James ---
(In reply to Sam James from comment #14)
> Is this like a 'lifetime-dse' thing? Is it legal for wmem_tree_new_autoreset
> to modify 'tree' before it's returned like that for the malloc attribute?
(The issue no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #5 from Nicholas Williams ---
Created attachment 60442
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60442&action=edit
.ii file from buggy RHEL/GCC14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117315
--- Comment #14 from Sam James ---
Looking at this again, wmem_tree_new_autoreset has __attribute__((malloc))
which promises that the memory returned isn't aliased by anything else
("fresh").
In wmem_test_tree, we birth 'tree' with wmem_tree_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #8 from Andrew Pinski ---
Works on the trunk.
[apinski@xeond2 upstream-gcc-isel]$ ~/upstream-gcc-isel/bin/g++ -std=c++20
-fsanitize=address -fsanitize-address-use-after-scope -Wall -Wextra -Werror
-D_GLIBCXX_ASSERTIONS -D_GLIBCXX_DEB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #7 from Nicholas Williams ---
I think I have now attached everything. Under the "What we do not want" on the
bug reporting instructions, it says "An attached archive (tar, zip, shar,
whatever) containing all (or some) of the above."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #6 from Nicholas Williams ---
Created attachment 60443
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60443&action=edit
.ii file from working Ubuntu/GCC13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #4 from Nicholas Williams ---
Created attachment 60441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60441&action=edit
runtime output from working Ubuntu/GCC13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #3 from Nicholas Williams ---
Created attachment 60440
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60440&action=edit
runtime output from buggy RHEL/GCC14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #2 from Nicholas Williams ---
Created attachment 60439
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60439&action=edit
gcc -v output from working Ubuntu/GCC13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #1 from Nicholas Williams ---
Created attachment 60438
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60438&action=edit
gcc -v output from buggy RHEL/GCC14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118796
--- Comment #3 from Sam James ---
(In reply to Sam James from comment #2)
Ignore the last install. We obviously don't want/need that. If you do for some
reason, then add the custom install prefix on the cmake command.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108608
fengfei.xi at horizon dot auto changed:
What|Removed |Added
CC||fengfei.xi at horizon do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
Bug ID: 118811
Summary: SIGABRT (or ASAN heap-use-after-free) in
chrono::locate_zone--chrono::tzdb_list during exit
handlers
Product: gcc
Version: 14.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118796
--- Comment #2 from Sam James ---
```
mkdir /tmp/fortran && cd /tmp/fortran
# Unfortunately, we have to install at least one library, so we do it in
/tmp/fortran/prefix to keep it off the real system.
mkdir /tmp/fortran/prefix
git clone https:/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900
Andrew Pinski changed:
What|Removed |Added
Keywords||false-positive
--- Comment #10 from Andr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #21 from Andrew Pinski ---
So after r15-580, we can optimize:
```
extern void* malloc (long unsigned int);
void fun (unsigned *x) {
if (x == 0)
__builtin_unreachable();
unsigned *a = malloc (*x);
if (a == 0)
return;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70349
--- Comment #3 from John David Anglin ---
Created attachment 60436
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60436&action=edit
64-bit assembler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118808
Kio changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118789
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56423
--- Comment #6 from anlauf at gcc dot gnu.org ---
Created attachment 60435
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60435&action=edit
Patch
This patch diagnoses the rank mismatch as well as the vector subscripts,
and is currently regt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806
--- Comment #2 from Georg-Johann Lay ---
(In reply to Xi Ruoyao from comment #1)
> Maybe it can also be done if main is [[noreturn]]?
Not sure about that.
The proposed patch /sets/ [[noreturn]] provided the conditions are right, i.e.
-mno-call-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118159
Thomas Koenig changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118159
--- Comment #6 from Andrew Pinski ---
(In reply to Thomas Koenig from comment #5)
> Andrew, are you still onto this? If not, I could do it.
No I am not working on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118159
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88124
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791
Tobias Burnus changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56423
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=117166
Sam James changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56423
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #3)
> > $ cat z2.f90
> > program p
> >integer, target :: x(3) = [7, 8, 9]
> >type t
> > integer, pointer :: a(:)
> >end type
> >type(t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
Thomas Koenig changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102390
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118809
Andrew Pinski changed:
What|Removed |Added
Keywords||compile-time-hog
--- Comment #1 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118810
Bug ID: 118810
Summary: collect2 should delay creating of temp
.cdtor.c/.cdtor.o files until needed
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118598
--- Comment #3 from Andrew Pinski ---
(In reply to Jeffrey A. Law from comment #2)
> It looks like it shrink-wraps to me. The frame setup happens after the a ==
> 42 early exit. Where you expecting something else?
There should be a shrink wra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118598
--- Comment #2 from Jeffrey A. Law ---
It looks like it shrink-wraps to me. The frame setup happens after the a == 42
early exit. Where you expecting something else?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #9 from Sam James ---
(In reply to Jakub Jelinek from comment #7)
> Can you bisect to one TU using -f{,no-}range-for-ext-temps?
I started last night, but the crashers are plugins which makes it a nuisance.
I'll work more on it if th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #8 from Jakub Jelinek ---
In the rhbz bug Alessandro Astone came up with:
#include
#include
#include
#include
#include
#include
using namespace std::chrono_literals;
struct TimerAwaiter {
std::chrono::milliseconds duratio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118805
Sam James changed:
What|Removed |Added
Summary|[15 Regression] wrong code |[15 Regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99302
--- Comment #3 from Thomas Koenig ---
(In reply to Roland Illig from comment #2)
> Maybe you can ask Martin Sebor for details regarding the diagnostics.
>
> There are several other code smells in that area, such as:
"Code smells" is not a prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100733
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114385
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114622
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #20 from David Malcolm ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115123
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:22e30d60b971eed9a4754ea920d05b1b7e89090a
commit r15-7451-g22e30d60b971eed9a4754ea920d05b1b7e89090a
Author: Jeff Law
Date: Sun Feb 9 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115123
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791
--- Comment #4 from sandra at gcc dot gnu.org ---
Ooops, I meant "specific to OG14 branch" in my last comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791
--- Comment #3 from sandra at gcc dot gnu.org ---
Curiously, on the OG14 development branch the rvalue calls work but the lvalue
ones are broken instead:
$ install/bin/x86_64-none-linux-gnu-g++ -fopenmp -S quux.C
quux.C: In instantiation of 'vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117263
Jeffrey A. Law changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118809
Bug ID: 118809
Summary: Excessive memory usage with global
std::vector> in C++20 mode
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117263
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:b81bb3ed216213fdaba82addae9fc34619ad6ec7
commit r15-7450-gb81bb3ed216213fdaba82addae9fc34619ad6ec7
Author: Dario Gjorgjevski
Date: Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117006
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115202
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767
--- Comment #22 from Xi Ruoyao ---
Maybe it's worthy to try the new LLVM TBAA sanitizer for this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115675
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #21 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116215
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116479
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117957
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
1 - 100 of 124 matches
Mail list logo
