https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117761
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html
That is gcc does not currently implements this paper.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117761
--- Comment #1 from Andrew Pinski ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117761
Bug ID: 117761
Summary: Incorrect name lookup within decltype used as part of
an id-expression for a class member access
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112841
--- Comment #5 from Halalaluyafail3 ---
(In reply to Joseph S. Myers from comment #4)
> Fixed for GCC 15.
It seems like this patch also makes typeof_unqual(_Atomic int[2]) equivalent to
int[2] which I believe is not correct, since _Atomic int[2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117658
--- Comment #1 from accelerator0099 at gmail dot com ---
main.cc:
import std;
import pr;
int main() {
std::printf("%d\n",
pr::alias_printable>);
}
pr.cc:
module;
import std;
namespace pr {
struct alias_t {};
constexpr alias_t alias;
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117736
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117736
--- Comment #7 from Andrew Pinski ---
Created attachment 59686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59686&action=edit
Reduced as far I could make it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922
--- Comment #14 from Eric Gallager ---
(In reply to Sam James from comment #12)
> GCC lacks an equivalent for Clang's -Wdeprecated-non-prototype, right?
This has been added for GCC 15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117760
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-11-24
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117760
Bug ID: 117760
Summary: `a != b` implies that a or b is also non-zero
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117741
--- Comment #3 from Andrew Pinski ---
Created attachment 59685
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59685&action=edit
Patch which I am tresting
Simple patch wich copies what the C parser does to the gimple fe parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112358
--- Comment #14 from John David Anglin ---
The warning is bogus.
Theoretically, current_used + count can wrap around to zero without undefined
behaviour. But as noted by Florian, these are counts of link maps
(among other things). Link maps h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117118
--- Comment #5 from GCC Commits ---
The master branch has been updated by Lewis Hyatt :
https://gcc.gnu.org/g:18cace467402a35fa2344f6b48890b2e986ad2a5
commit r15-5618-g18cace467402a35fa2344f6b48890b2e986ad2a5
Author: Lewis Hyatt
Date: Mon O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117724
--- Comment #6 from uecker at gcc dot gnu.org ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669873.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114540
--- Comment #4 from Heiko Eißfeldt ---
After realizing my error in the previous patch (relying on an ERANGE check for
the wanted integer type instead of a check of long type range) I manually
tested my corrected patch. Corner cases behave like o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114540
Heiko Eißfeldt changed:
What|Removed |Added
Attachment #59671|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88052
--- Comment #11 from GCC Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:fd118f4c54c374882bf91c9e61b756767c0d3634
commit r15-5611-gfd118f4c54c374882bf91c9e61b756767c0d3634
Author: Jerry DeLisle
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116388
Paul Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116388
--- Comment #8 from GCC Commits ---
The releases/gcc-13 branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:a50d2acc48f45c6bbf256e51440d181794079a0f
commit r13-9209-ga50d2acc48f45c6bbf256e51440d181794079a0f
Author: Paul Thomas
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116388
--- Comment #7 from GCC Commits ---
The releases/gcc-14 branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:c53a8c0410b4858d1a1b628b9d950eee47bc345c
commit r14-10975-gc53a8c0410b4858d1a1b628b9d950eee47bc345c
Author: Paul Thomas
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345
--- Comment #8 from Paul Thomas ---
Fixed on all affected branches.
Thanks for the report.
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345
--- Comment #7 from GCC Commits ---
The releases/gcc-12 branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:8a4cb2a758938df6e51d88e48340f5fede0061d1
commit r12-10828-g8a4cb2a758938df6e51d88e48340f5fede0061d1
Author: Paul Thomas
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:25b24d72c7989d2b86920fb078c994c5498204a9
commit r13-9208-g25b24d72c7989d2b86920fb078c994c5498204a9
Author: Paul Thomas
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345
--- Comment #5 from GCC Commits ---
The releases/gcc-14 branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:d65a599795df85fd0974bdfc1597cc3013b670f9
commit r14-10974-gd65a599795df85fd0974bdfc1597cc3013b670f9
Author: Paul Thomas
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117745
--- Comment #9 from Andrew Pinski ---
Maybe related to the new C parser.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43374
Andrew Pinski changed:
What|Removed |Added
CC||xieym3 at zohomail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117754
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117756
Andrew Pinski changed:
What|Removed |Added
Known to work||4.9.4
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117745
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-11-23
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117745
Andrew Pinski changed:
What|Removed |Added
Known to fail||11.2.0, 4.1.2, 4.5.3, 4.9.4
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115823
--- Comment #15 from GCC Commits ---
The releases/gcc-14 branch has been updated by Gaius Mulley
:
https://gcc.gnu.org/g:8e3b5a74145c1db9c7af8c5037705b313c3efe11
commit r14-10972-g8e3b5a74145c1db9c7af8c5037705b313c3efe11
Author: Gaius Mulley
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117457
Sam James changed:
What|Removed |Added
Blocks||102445
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115804
--- Comment #11 from GCC Commits ---
The releases/gcc-14 branch has been updated by Gaius Mulley
:
https://gcc.gnu.org/g:8a6b30148d76cf88148622898f1db6c756b21dde
commit r14-10971-g8a6b30148d76cf88148622898f1db6c756b21dde
Author: Gaius Mulley
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117744
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117744
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117744
--- Comment #7 from GCC Commits ---
The releases/gcc-12 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:7f04fddec3bc33b6fb418f3980995b9b7697e6b1
commit r12-10827-g7f04fddec3bc33b6fb418f3980995b9b7697e6b1
Author: Georg-Johan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117751
--- Comment #8 from Jonathan Wakely ---
I agree, adding the new option to this test makes perfect sense.
I'll check for other tests where we do this kind of thing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117751
Sam James changed:
What|Removed |Added
Attachment #59681|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117744
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:360ed41076c81ce9caeb215250eb627e4f45e2fe
commit r13-9207-g360ed41076c81ce9caeb215250eb627e4f45e2fe
Author: Georg-Johann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #22 from Tamar Christina ---
Ok, so the problem with the ones on trunk isn't necessarily the
canonicalization itself but that our externals handling is a bit shallow.
On externals we determine that we have no information on the DF a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117744
--- Comment #5 from GCC Commits ---
The releases/gcc-14 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:f66748d61dea45ee301e78afdbec7ec6563ff97e
commit r14-10970-gf66748d61dea45ee301e78afdbec7ec6563ff97e
Author: Georg-Johan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117759
Maciej W. Rozycki changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117759
Bug ID: 117759
Summary: Alpha: `_Atomic' keyword not respected for !BWX and
8-bit/16-bit stores
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: major
checking --disable-multilib --disable-shared
--disable-bootstrap --enable-languages=c,c++
--prefix=/data/xieym/exp/gcc/test_data/gcc-latest-install
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241123 (experimental) (GCC)
$ gcc-trunk -x c -std=c2x -c 2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117744
--- Comment #4 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:ee8e6784876aa050d2e01f54d1da4acf758b635a
commit r15-5607-gee8e6784876aa050d2e01f54d1da4acf758b635a
Author: Georg-Johann Lay
Dat
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241123 (experimental) (GCC)
$ gcc-trunk -x c -std=c2x -c 1.c -o /dev/null
1.c: In function ‘d’:
1.c:6:14: error: conflicting types for ‘h’; have ‘int[4][4][4][4][4][4][4]’
6 | static int h[4][4][4][4][4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117751
Jakub Jelinek changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117730
--- Comment #7 from Paul Thomas ---
(In reply to anlauf from comment #6)
> I looked at the fortran dump, and also at the verbose asm, comparing
> with and w/o non_overridable.
snip
> Could that be related to child_reset being invoked, al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117751
--- Comment #6 from Sam James ---
Created attachment 59681
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59681&action=edit
reduced.ii
Attached an attempted reduction but I don't think it's very useful. It clearly
relies on a side-effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117744
Georg-Johann Lay changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
|a/show_bug.cgi?i
-latest-install
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241123 (experimental) (GCC)
$ gcc-trunk -x c -std=c2x -c 20241123025220_9.c -o /dev/null
20241123025220_9.c:2:22: error: expected ‘(’ before ‘noinline’
2 | void __attribute__ ( noinline ) bar
ata/gcc-latest-src/configure
--enable-coverage --enable-checking --disable-multilib --disable-shared
--disable-bootstrap --enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241123 (experimental) (GCC)
$ gcc-trunk -x c -std=c2x
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241123 (experimental) (GCC)
$ gcc-trunk -x c -std=c2x -c 20241123025220_16.c -o /dev/null
20241123025220_16.c:5:6: error: ‘n’ redeclared as different kind of symbol
5 | void n(int[n], int[n], int[n], int[n], int[n], int[n], int[n
-latest-src/configure
--enable-coverage --enable-checking --disable-multilib --disable-shared
--disable-bootstrap --enable-languages=c,c++
--prefix=/data/xieym/exp/gcc/test_data/gcc-latest-install
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117751
--- Comment #1 from Sam James ---
Program received signal SIGABRT, Aborted.
t__pthread_kill_implementation (threadid=, signo=6, no_tid=0) at
pthread_kill.c:44
44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO
(ret) : 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117751
Sam James changed:
What|Removed |Added
Summary|[15 regression] |[15 regression]
|18_suppo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117751
--- Comment #5 from Sam James ---
Created attachment 59680
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59680&action=edit
a-50594.ii.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117751
--- Comment #4 from Sam James ---
(In reply to Sam James from comment #3)
> Just -O1 -fwhole-program is enough, obviously.
>
> What I'm wondering is what's special here. Jakub is very thorough so either
> missed it or something else is happenin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117751
--- Comment #3 from Sam James ---
Just -O1 -fwhole-program is enough, obviously.
What I'm wondering is what's special here. Jakub is very thorough so either
missed it or something else is happening.
xp/gcc/test_data/gcc-latest-src/configure
--enable-coverage --enable-checking --disable-multilib --disable-shared
--disable-bootstrap --enable-languages=c,c++
--prefix=/data/xieym/exp/gcc/test_data/gcc-latest-install
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117751
Bug ID: 117751
Summary: [15 regression] 18_support/50594.cc fails
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: testsuite-fail, wrong-code
Severity: normal
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241123 (experimental) (GCC)
$ gcc-trunk -x c -std=c2x -c 20241123025220_13.c -o /dev/null
20241123025220_13.c: In function ‘find_base_value’:
20241123025220_13.c:15:1: warning: old-style function definit
--enable-languages=c,c++
--prefix=/data/xieym/exp/gcc/test_data/gcc-latest-install
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241123 (experimental) (GCC)
$ gcc-trunk -x c -std=c2x -c 20241123025220_11.c -o /dev/null
20241123025220_11.c:1:1: error: ‘__GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117573
--- Comment #9 from Tarik Ibrahimović ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Tarik Ibrahimović from comment #7)
> > Does "corrupted" mean it got mixed up somewhere in the compiling process? I
> > emphasize once again, tha
/gcc-latest-install
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241123 (experimental) (GCC)
$ gcc-trunk -x c -std=c2x -c 20241123025220_10.c -o /dev/null
20241123025220_10.c: In function ‘bar’:
20241123025220_10.c:7:8: error: ‘x’ redeclared as different
15.0.0 20241123 (experimental) (GCC)
$ gcc-trunk -x c -std=c2x -c 20241123025220_1.c -o /dev/null
20241123025220_1.c:1:1: error: ‘__GIMPLE’ only valid with ‘-fgimple’
1 | __GIMPLE
| ^~~~
20241123025220_1.c: In function ‘foo’:
20241123025220_1.c:3:10: error: ‘b’ undeclared (first use in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117745
--- Comment #5 from Xieym ---
Sorry, one line was missing. Here is the complete code:
void g0(void) { f0 ( ;
}
static void f1(void);
void g1(void) {
if (0) {
();
}
}
static int f2(void);
void g2(void) { 0 ? f2() : 0; }
static int f3(voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117745
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117745
--- Comment #4 from Sam James ---
I can't either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117745
--- Comment #3 from Xieym ---
(In reply to Andrew Pinski from comment #1)
> I can't reproduce this. It errors out pretty quickly for me. I tested it
> with r15-5604-g7ff5900399c889 .
I used the following command: timeout 60 gcc-trunk -x c -std=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117741
--- Comment #2 from Andrew Pinski ---
*** Bug 117746 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117746
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117745
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117745
--- Comment #1 from Andrew Pinski ---
I can't reproduce this. It errors out pretty quickly for me. I tested it with
r15-5604-g7ff5900399c889 .
--enable-checking --disable-multilib --disable-shared
--disable-bootstrap --enable-languages=c,c++
--prefix=/data/xieym/exp/gcc/test_data/gcc-latest-install
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241123 (experimental) (GCC)
Possibly related to https
-latest-install
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241123 (experimental) (GCC)
$ cat 20241123012943_2.c
static void f0(void);
void g0(void) { f0 ( ;
}
static void f1(void);
void g1(void) {
if (0) {
();
}
}
static int f2(void);
void g2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117573
--- Comment #8 from Andrew Pinski ---
(In reply to Tarik Ibrahimović from comment #7)
> Does "corrupted" mean it got mixed up somewhere in the compiling process? I
> emphasize once again, that the generated code does not cause any
> misalignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117744
--- Comment #2 from Georg-Johann Lay ---
Created attachment 59679
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59679&action=edit
pr111683-1.c.339r.cprop_hardreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117744
--- Comment #1 from Georg-Johann Lay ---
Created attachment 59678
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59678&action=edit
pr111683-1.c.338r.fold_mem_offsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117573
--- Comment #7 from Tarik Ibrahimović ---
Does "corrupted" mean it got mixed up somewhere in the compiling process? I
emphasize once again, that the generated code does not cause any misalignments
when -O0 is used.
One more thing which may be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117573
--- Comment #6 from Tarik Ibrahimović ---
Does "corrupted" mean it got mixed up somewhere in the compiling process? I
emphasize once again, that the generated code does not cause any misalignments
when -O0 is used.
One more thing which may be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117744
Bug ID: 117744
Summary: cprop_hardreg deleted an insns that's not dead
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: r
83 matches
Mail list logo
