https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116357
--- Comment #12 from rguenther at suse dot de ---
On Fri, 24 Jan 2025, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116357
>
> --- Comment #10 from Jakub Jelinek ---
> So, shall we go for
> --- gcc/c/c-decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118490
--- Comment #4 from GCC Commits ---
The master branch has been updated by Soumya AR :
https://gcc.gnu.org/g:d8a7f07f7cf008e359dad631aaae1028776b9e18
commit r15-7222-gd8a7f07f7cf008e359dad631aaae1028776b9e18
Author: Soumya AR
Date: Mon Jan 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118670
--- Comment #4 from Andrew Pinski ---
(In reply to Jeremy R. from comment #3)
> Thanks Andrew,
> Two thoughts:
> Firstly, I'm surprised to see a normal reference and a
> std::reference_wrapper behaving differently for this diagnostic. What's the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118670
Jeremy R. changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #3 from Jeremy R. ---
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
Andrew Pinski changed:
What|Removed |Added
CC||llvm at rifkin dot dev
--- Comment #24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118670
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #2 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118670
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118670
Bug ID: 118670
Summary: -Wdangling-reference false positive when returning a
reference from a reference_wrapper
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
Peter Bergner changed:
What|Removed |Added
Summary|[15 Regression] ICE: in |[15 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118657
--- Comment #9 from Andi Kleen ---
With constexpr you are guaranteed an visible initializer. const would
potentially require messing with IPA and might impossible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118665
--- Comment #1 from Jonathan Wakely ---
Such a generator fails to meet the requirements so the program has undefined
behaviour.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118647
--- Comment #13 from Jonathan Wakely ---
(In reply to Arthur O'Dwyer from comment #11)
> Personally I encourage libstdc++ to join libc++ in optimizing as if P3349
> were already the law of the land. You're free to say "no, we must not
> perform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118647
--- Comment #12 from Jonathan Wakely ---
(In reply to Alfredo Correa from comment #10)
> In that case, wouldn't it be more consistent that the `contiguous_iterator`
> concept checks for these `noexcept` characteristics?
No, the standard is very
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
--- Comment #1 from Andrew Pinski ---
I suspect the issue is just not using the misaligned type.
One thing to try is if gcc produces the misaligned store with -mstrict-align
(which is will check when I get home).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
Bug ID: 118669
Summary: Misaligned store after after vectorization
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118657
--- Comment #8 from Andrew Pinski ---
Constexpr is for c/c++ specific ideas of const expressions and not relevant to
optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118657
--- Comment #7 from Andrew Pinski ---
(In reply to Andi Kleen from comment #6)
> The C test case needs to use constexpr too.
No it does not. Const variables which are initialized at compile time should be
enough for the optimization. We alread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118657
--- Comment #6 from Andi Kleen ---
The C test case needs to use constexpr too.
#define DATA_SIZE 1024
static constexpr int TO_DATA_INDEX[DATA_SIZE] = {};
bool foo(int* data, unsigned char first_idx)
{
int second_idx = TO_DATA_INDEX[first_idx]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
Peter Bergner changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #5 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110993
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118666
--- Comment #3 from Andrew Pinski ---
Looking into code generation for branches.
https://godbolt.org/z/zWvYaKhWx
The same applies as non branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118600
Gaius Mulley changed:
What|Removed |Added
Attachment #60236|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110993
--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 60286
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60286&action=edit
Draft patch
This patch also handles the case of interfaces of procedures with C binding.
Currently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118667
Bug ID: 118667
Summary: lambda references to bit-fields via structure binding
is invalid
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: accepts-inval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118668
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118668
Bug ID: 118668
Summary: lambda explict reference to anonymous union is allowed
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: accepts-invalid, c++-lambda
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118666
--- Comment #2 from Andrew Pinski ---
https://godbolt.org/z/xsYzTTzdE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118666
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118666
Bug ID: 118666
Summary: Canonicalization of `(a & CST) == CST` and `((~a) &
CST) == 0`
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110993
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=118663
--- Comment #4 from Peter Bergner ---
So this isn't 32-bit specific. powerpc-linux defaults to -mcpu=601 and
powerpc64-linux defaults to -mcpu=power4. Using -mcpu=power4 with either -m32
or -m64, we do not ICE. When using -mcpu=601 with eithe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292
--- Comment #9 from Sam James ---
Review is underway, see
https://inbox.sourceware.org/gcc-patches/694bccdd-277b-43c4-8e99-38a38d45a...@redhat.com/.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292
--- Comment #8 from Franck Behaghel
---
> Patch submitted in
> https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671590.html
Thanks for the fix. Look fine indeed. No more ICE. Could someone merge this
into trunk ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118665
Bug ID: 118665
Summary: std::uniform_int_distribution infinite loop with
generator returning 0
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96087
Paul Thomas changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118640
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
Last re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118661
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
--- Comment #9 from Sam James ---
That's why I blushed when I realised :D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Sam James from comment #1)
> > Same on arm64.
>
> Well aarch64 does not have V4QI (I hope to finish that up for GCC 16 though).
And char is unsign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-01-26
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
--- Comment #6 from Andrew Pinski ---
Created attachment 60284
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60284&action=edit
Self contained testcase
This now fails with `-O2 -mavx`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
--- Comment #5 from Andrew Pinski ---
(In reply to Sam James from comment #1)
> Same on arm64.
Well aarch64 does not have V4QI (I hope to finish that up for GCC 16 though).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #25 from Thomas Koenig ---
Created attachment 60283
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60283&action=edit
Preliminary patch
Here's a mostly-complete patch. It lacks test cases and and
ChangeLog entries, but should w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
Peter Bergner changed:
What|Removed |Added
Last reconfirmed||2025-01-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118657
--- Comment #5 from Andrew Pinski ---
(In reply to Andi Kleen from comment #3)
> I don't think you need range analysis for this, just the constexpr array
> lookup needs to supply a constant.
In the simplified testcase, saying all values of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118664
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118647
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118664
Bug ID: 118664
Summary: Improve -Wswitch and -Wswitch-enum warnings for enum
types
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114085
--- Comment #4 from Jeffrey A. Law ---
So not really working on this, but figured I could take a quick looksie to see
if it was something simple/easy to fix.
The problem is we have this instruction heading into allocation:
(insn 31 30 33 7 (set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114085
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #11 from Brecht Sanders ---
Apparently MinGW-w64 dosn't like extern char** environ;
To avoid this issue for now I commented out the following in gcc/cp/module.cc:
extern char **environ;
while (const char *var = environ[vars.leng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #10 from Brecht Sanders ---
Looks like _pgmptr was superseded by _get_pgmptr().
So I tried this quick and dirty fix to get past the issue:
patch -ulbf libbacktrace/fileline.c << EOF
@@ -262,3 +262,7 @@
to the wine binar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118646
Bug 118646 depends on bug 118103, which changed state.
Bug 118103 Summary: [15 Regression] GCC miscompile rvv intrinsics at `-O3`,
missing the `fsrm` instruction to the recover status of frm CSR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118103
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
Sam James changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
See Al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #9 from Brecht Sanders
---
Same thing happens with --enable-languages=c,c++,fortran,d
What is causing the error: "undefined reference to `__imp___p__pgmptr'" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116330
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653
Sam James changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[14/15 Regression] ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #8 from Brecht Sanders
---
Yes, that was with --languages=d only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #7 from Sam James ---
Huh, is that really only with D enabled? I would expect it to happen otherwise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #6 from Brecht Sanders
---
Sorry it took me a while to get the hang of building a canadian cross from
Linux.
When building gdc for Windows 64-bit I get the following:
make[2]: Entering directory
'/home/brecht/build-gcc/build_stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118657
--- Comment #4 from Ionuț Nicula ---
Note that my actual usecase with this kind of transformation is slightly more
complex. Instead of having the lookup table filled with zeros (or any single
value), it's filled with arbitrary values that satisf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
Sam James changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
Sam James changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
See A
ecking-yes-rtl-df-extra-powerpc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250126 (experimental) (GCC)
And for the reduced testcase:
$ /repo/build-gcc-trunk-powerpc/gcc/cc1 _sd_to_si.i -O2
_sd_to_si.i:3:1: warning: no semicolon at end o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
Sam James changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #3 from Sam James ---
(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
--- Comment #2 from Sam James ---
```
int addup(char *num) {
int val = num[0] + num[1] + num[2] + num[3];
if (num[3] >= 0)
val++;
return val;
}
int main(int, char *[]) {
char num[4] = {1, 1, 1, -1};
if (addup(num) != 2)
__buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
Sam James changed:
What|Removed |Added
Component|target |tree-optimization
Summary|-ftree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
Bug ID: 118662
Summary: -ftree-slp-vectorize causes incorrect math
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118661
--- Comment #2 from Andrew Pinski ---
Related
https://cplusplus.github.io/CWG/issues/2140.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95646
Sam James changed:
What|Removed |Added
Target Milestone|--- |10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95646
Sam James changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118661
Sam James changed:
What|Removed |Added
Summary|Reading volatile qualified |[12/13/14/15 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118661
Bug ID: 118661
Summary: Reading volatile qualified std::nullptr_t should be
valid in a constant expression
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118658
--- Comment #2 from Andrew Pinski ---
Note like PR 118660 implementing this optimization gets in the way.
That is take:
```
unsigned short f(unsigned a)
{
if ((a & 3) != 3) return a | 1;
return a | 1;
}
```
Afterwards we get:
```
[local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118660
--- Comment #2 from Andrew Pinski ---
This one is slightly harder to handle:
```
unsigned short f(unsigned a)
{
if ((a & 3) != 3) return a & 1;
return a & 1;
}
```
We get:
```
[local count: 1073741824]:
_1 = a_4(D) & 3;
if (_1 != 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118653
--- Comment #13 from David Binderman ---
Also before 2024-04-01:
foundBugs $ ../results.d8cf8917ed3d7e07/bin/gcc -c -w -g -O3 bug1083.c
during GIMPLE pass: vect
runData/keep/in.39468.c: In function ‘main’:
runData/keep/in.39468.c:1246:5: intern
80 matches
Mail list logo
