[Bug c++/115588] New: ICE: in tsubst_stmt, at cp/pt.cc:18527
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115588
Bug ID: 115588
Summary: ICE: in tsubst_stmt, at cp/pt.cc:18527
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
Target: x86_64
***
The compiler produces an internal error during the tsubst_lambda_expr when
compiling the provided code with the specified options.
The issue can also be reproduced on Compiler Explorer.
***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-15/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /root/gdbtest/gcc/obj/../gcc/configure
--prefix=/root/gdbtest/gcc/gcc-15 --enable-languages=c,c++,fortran,go
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240509 (experimental) (GCC)
***
Program:
# cat t.c
template
int f (int n)
{
int x[1][n];
return [x[0]] /* () { return 0; } */;
}
int i = f<1>(1);
***
Command Lines:
# g++ t.c -flto -fwhole-program -g -gdwarf-4 -ggdb3 -grecord-gcc-switches
-fanalyzer -fdump-analyzer -Wno-analyzer-nul
l-dereference -Wno-analyzer-use-after-free -c -o t.o
t.c: In function ‘int f(int)’:
t.c:6:12: error: expected ‘,’ before ‘[’ token
6 | return [x[0]] /* () { return 0; } */;
|^
|,
t.c:6:12: error: expected identifier before ‘[’ token
t.c: In lambda function:
t.c:6:39: error: expected ‘{’ before ‘;’ token
6 | return [x[0]] /* () { return 0; } */;
| ^
t.c: In instantiation of ‘int f(int) [with int N = 1]’:
t.c:9:13: required from here
9 | int i = f<1>(1);
| ^~~
t.c:6:10: sorry, unimplemented: capture of variably-modified type ‘int [1][n]’
that is not an N3639 array of runtime bound
6 | return [x[0]] /* () { return 0; } */;
| ^~
t.c:6:10: note: because the array element type ‘int [n]’ has variable size
t.c:6:15: internal compiler error: in tsubst_stmt, at cp/pt.cc:18514
6 | return [x[0]] /* () { return 0; } */;
| ^
0x8308a0 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18514
0xce1718 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18410
0xce1718 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:19850
0xcbe1a0 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:21757
0xcc4837 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:19482
0xcc6446 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18434
0xcc6106 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18410
0xcc6106 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18424
0xcc6bee tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18797
0xce0b52 tsubst_stmt
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:18410
0xce0b52 instantiate_body
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:27107
0xcc4425 instantiate_decl(tree_node*, bool, bool)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:27392
0xcf0c4b instantiate_pending_templates(int)
/root/gdbtest/gcc/obj/../gcc/gcc/cp/pt.cc:27468
0xb8cc67 c_parse_final_cleanups()
/root/gdbtest/gcc/obj/../gcc/gcc/cp/decl2.cc:5195
0xddf3a0 c_common_parse_file()
/root/gdbtest/gcc/obj/../gcc/gcc/c-family/c-opts.cc:1329
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/115579] [15 regression] wrong code at -Os with "-fno-tree-sra" on x86_64-linux-gnu since r15-1391-g4b75ed33fa5fd6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115579 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener --- Mine. This is probably a latent issue.
[Bug c/115587] [14/15 Regression] Possible uninitialized variable (decl) in c_parser_omp_loop_nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115587 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.2
[Bug c/115589] New: (aarch64) clobbered register variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115589
Bug ID: 115589
Summary: (aarch64) clobbered register variables
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pietro.braione at gmail dot com
Target Milestone: ---
/*
* compiled with gcc -O0, on my platform (Ubuntu 22.04 aarch64) prints:
*
* 4
* 2
*
* This is a very simplified example. In my production code I have
* variables that are assigned register x21-x23, and gcc generates
* code that uses these registers as temporaries without saving
* elsewhere the content of the variables, that are lost.
*/
#include
int a = 1, b = 1, c = 1, d = 1;
void main() {
register int x asm("x0");
x = 0;
printf("%d\n", a + b + c + d);
printf("%d\n", x);
}
[Bug sanitizer/115590] New: Bad dereferences through -> operator not detected by sanitizers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115590
Bug ID: 115590
Summary: Bad dereferences through -> operator not detected by
sanitizers
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: nrk at disroot dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Minimal testcase:
int main(void)
{
struct { int v; } *p = 0;
p->v;
return 0;
}
Compile and run with:
[/tmp]~> gcc -fsanitize=address,undefined -O0 -o test ./test.c &&
./test
Doesn't detect the null pointer deref. Same with clang:
[/tmp]~> clang -fsanitize=address,undefined -O0 -o test ./test.c &&
./test
./test.c:4:5: warning: expression result unused [-Wunused-value]
p->v;
~ ^
1 warning generated.
test.c:4:5: runtime error: member access within null pointer of type
'struct (unnamed struct at ./test.c:3:2)'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.c:4:5 in
test.c:4:5: runtime error: load of null pointer of type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test.c:4:5 in
[Bug tree-optimization/115579] [15 regression] wrong code at -Os with "-fno-tree-sra" on x86_64-linux-gnu since r15-1391-g4b75ed33fa5fd6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115579 --- Comment #8 from Richard Biener --- Ah, ok - the situation is new in that store-flag re-use is only considered for loops which have all stores in a single BB and of course there always_stored is always the same but now ref_can_have_store_data_races can be different for stores. I have a fix, it's to some extent not optimal as we emit unnecessary loads up to the first var that needs the MT model. There's the general optimization opportunity missing to share flag vars for stores that are stored in the same BBs.
[Bug middle-end/114855] ICE: Segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- Note looking at -O1 is the most important thing, as we tell people to use -O1 for autogenerated code. There I suppose comment#4 still applies and likely this is ranger as well. Maybe DOMs ranger use can be tuned down at -O1 (when -ftree-vrp is off).
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #23 from Jürgen Reuter --- Created attachment 58486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58486&action=edit Shorter reproducer This is a shorter reproducer, two files of a few hundred lines each. It seems that the problem with the vectorization appears only if the call and the double do loop are in two different files.
[Bug ada/115591] New: ICE in riscv64-elf cross compiler, handling imported addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115591 Bug ID: 115591 Summary: ICE in riscv64-elf cross compiler, handling imported addresses Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 58487 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58487&action=edit Reproducer Compiler in use: gnat-riscv64-elf-darwin-14.1.0-3 from https://github.com/alire-project/GNAT-FSF-builds/releases Compiling the attached reproducer with riscv64-elf-gcc -c --RTS=. bug.adb results in during RTL pass: expand +===GNAT BUG DETECTED==+ | 14.1.0 (riscv64-elf) in tree_to_uhwi, at tree.h:4951 | | Error detected around bug.adb:29:24 | | Compiling bug.adb| | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). system.ads bug.adb bug.ads s-stoele.ads s-stoele.adb ada.ads a-unccon.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:412 Note that * this error doesn’t happen with an arm-eabi cross compiler * it was present from GCC 12.2.0
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #24 from Richard Biener --- (In reply to Jürgen Reuter from comment #23) > Created attachment 58486 [details] > Shorter reproducer > > This is a shorter reproducer, two files of a few hundred lines each. It > seems that the problem with the vectorization appears only if the call and > the double do loop are in two different files. Thanks, but see comment#21 where I already reduced a testcase. I've posted a fix already at https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655376.html
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #25 from Jürgen Reuter --- (In reply to Richard Biener from comment #24) > (In reply to Jürgen Reuter from comment #23) > > Created attachment 58486 [details] > > Shorter reproducer > > > > This is a shorter reproducer, two files of a few hundred lines each. It > > seems that the problem with the vectorization appears only if the call and > > the double do loop are in two different files. > > Thanks, but see comment#21 where I already reduced a testcase. I've posted > a fix already at > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655376.html Oh, yes, thanks, I should've read my emails in causal order. Thanks for the quick action. If the fix is pushed our CI will tell me Monday morning if everything works as expected again.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #26 from Jürgen Reuter --- (In reply to Richard Biener from comment #24) > (In reply to Jürgen Reuter from comment #23) > > Created attachment 58486 [details] > > Shorter reproducer > > > > This is a shorter reproducer, two files of a few hundred lines each. It > > seems that the problem with the vectorization appears only if the call and > > the double do loop are in two different files. > > Thanks, but see comment#21 where I already reduced a testcase. I've posted > a fix already at > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655376.html So your reproducer doesn't segfault with the corresponding commit, it just produces wrong code, right?
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #27 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #26) > (In reply to Richard Biener from comment #24) > > (In reply to Jürgen Reuter from comment #23) > > > Created attachment 58486 [details] > > > Shorter reproducer > > > > > > This is a shorter reproducer, two files of a few hundred lines each. It > > > seems that the problem with the vectorization appears only if the call and > > > the double do loop are in two different files. > > > > Thanks, but see comment#21 where I already reduced a testcase. I've posted > > a fix already at > > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655376.html > > So your reproducer doesn't segfault with the corresponding commit, it just > produces wrong code, right? Ok, forgot the -fno-inline. I really need to focus on the whole content. :(
[Bug target/115589] (aarch64) clobbered register variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115589 Andrew Pinski changed: What|Removed |Added Keywords||inline-asm --- Comment #1 from Andrew Pinski --- variables that are assigned register x21-x23, and gcc generates * code that uses these registers as temporaries without saving Iirc this is not the use of local register variables.
[Bug target/115589] (aarch64) clobbered register variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115589 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Local-Register-Variables.html The only supported use for this feature is to specify registers for input and output operands when calling Extended asm
[Bug target/115589] (aarch64) clobbered register variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115589 --- Comment #3 from Andrew Pinski --- Some developers use Local Register Variables in an attempt to improve gcc’s allocation of registers, especially in large functions. In this case the register name is essentially a hint to the register allocator. While in some instances this can generate better code, improvements are subject to the whims of the allocator/optimizers. Since there are no guarantees that your improvements won’t be lost, this usage of Local Register Variables is discouraged.
[Bug sanitizer/115590] Bad dereferences through -> operator not detected by sanitizers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115590 --- Comment #1 from Andrew Pinski --- In this case we remove the load early on even at -O0. Way before address santiizer annotates the load. I am not 100% sure want to keep these around even at -O0 since they don't have any behavior effect.
[Bug sanitizer/115590] Bad dereferences through -> operator not detected by sanitizers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115590 --- Comment #2 from Andrew Pinski --- Note if you assign it to a temporary, GCC will catch it at -O0.
[Bug sanitizer/115590] Bad dereferences through -> operator not detected by sanitizers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115590
--- Comment #3 from nrk at disroot dot org ---
> I am not 100% sure want to keep these around even at -O0 since they don't
> have any behavior effect.
I'd strongly argue that if you're using sanitizers, you'd want these to be
caught :)
Also worth noting that bad array deref gets caught even if they don't have any
effect:
[/tmp]~> cat test.c
int main(void)
{
int v[1];
v[1];
return 0;
}
[/tmp]~> gcc -fsanitize=address,undefined -O0 -o test ./test.c &&
./test
test.c:4:3: runtime error: index 1 out of bounds for type 'int [1]'
[Bug target/115589] (aarch64) clobbered register variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115589 --- Comment #4 from Pietro Braione --- I see. Sorry for the noise.
[Bug c++/115592] New: CWG DR 2823 seems incompletely implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115592
Bug ID: 115592
Summary: CWG DR 2823 seems incompletely implemented
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
Per CWG 2823 (https://cplusplus.github.io/CWG/issues/2823.html), dereferencing
a null pointer is UB no matter whether indirect access happens.
So the following code snippet should be rejected, but GCC currently accepts it.
https://godbolt.org/z/15ed7ec8b
```
static_assert([]{
struct S {};
*static_cast(nullptr);
return true;
}());
```
In the case where a non-static member function is called, GCC starts to reject
the example since 14.
https://godbolt.org/z/Kzjhdqddh
```
static_assert([]{
struct S {
constexpr void get() const {}
};
static_cast(nullptr)->get();
return true;
}());
```
It's curious whether calling a static member function should be rejected.
Per [expr.ref] (after CWG 2813), given a static member `m`, `a` in `a.m` is a
discarded-value expression. But `p` in `p->m` is not - it's semantically
dereferenced even though the result of dereferencing is unused.
Currently GCC also accepts the following example.
https://godbolt.org/z/9hGn7KajT
```
static_assert([]{
struct S {
static constexpr void get() {}
};
static_cast(nullptr)->get();
return true;
}());
```
It's unclear to me whether it's better to consider the pointer to be
dereferenced here, which is currently required and hence results in constant
evaluation failure. If the dereferencing is undesired, perhaps we should submit
a new CWG issue for changing.
[Bug fortran/55978] class_optional_2.f90 -Os fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978
--- Comment #33 from anlauf at gcc dot gnu.org ---
I've been repeatedly struggling with the testcase in comment#19.
Since the dump-tree did not reveal anything, I ran a reduced version
under gdb to see why the code crashes at -O0 and -Og but not at higher
optimization. I got them impression that the dump-tree does not tell
the full truth: subroutine one has
{
struct array01_integer(kind=4) * D.4292;
D.4292 = x != 0B ? (struct array01_integer(kind=4) *)
_gfortran_internal_pack (x) : 0B;
two (D.4292);
if (x != 0B && (integer(kind=4)[0:] *) x->data != (integer(kind=4)[0:] *)
D.4292)
{
_gfortran_internal_unpack (x, D.4292);
__builtin_free ((void *) D.4292);
}
}
but to my untrained eye it looked like the test x->data != D.4292 was
executed before x != 0B. This lead me to the following tentative patch:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 19d69aec9c0..06bfea1f461 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -9025,7 +9100,7 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr * expr,
bool g77,
fold_convert (TREE_TYPE (tmp), ptr), tmp);
if (fsym && fsym->attr.optional && sym && sym->attr.optional)
- tmp = fold_build2_loc (input_location, TRUTH_AND_EXPR,
+ tmp = fold_build2_loc (input_location, TRUTH_ANDIF_EXPR,
logical_type_node,
gfc_conv_expr_present (sym), tmp);
Strangely enough, this gives exactly the same dump-tree!
(If someone knows why, please enlighten me!)
But it fixed the issue.
The I looked at the optimized tree. The reference version has:
[local count: 1073741824]:
# _5 = PHI <_19(3), y_17(D)(2)>
two (_5);
_1 = y_17(D) != 0B;
_2 = y_17(D)->data;
_3 = _2 != _5;
_4 = _1 & _3;
if (_4 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 354334800]:
__builtin_free (_5);
This explains the "boom".
The version with the ANDIF has:
[local count: 1073741824]:
# _2 = PHI <_16(3), y_14(D)(2)>
two (_2);
if (y_14(D) != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 751619280]:
_1 = y_14(D)->data;
if (_1 != _2)
goto ; [53.47%]
else
goto ; [46.53%]
[local count: 401890828]:
__builtin_free (_2);
This looks sane to me: the data component is not referenced if the dummy
is seen to be absent.
Regtesting...
[Bug modula2/115536] Expression is evaluated incorrectly when encountering relops and indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115536 --- Comment #2 from Gaius Mulley --- Created attachment 58488 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58488&action=edit Proposed fix Here is a proposed fix. When in a const expression the fix creates marked boolean constvars which are resolved to TRUE and FALSE in the respective control flow paths. The basic block and constant resolving is applied on the current scope and one path will be removed (with the unused assignment). When outside a const expression a temporary boolean variable is created.
[Bug c++/115567] Internal Compiler Error: Segmentation Fault during build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115567 --- Comment #5 from Andrew Pinski --- Works for me on the trunk.
[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #7 from cqwrteur --- The patch has passed the CI. It is time to review and merge my patch. Thank you. https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655430.html https://patchwork.sourceware.org/project/gcc/patch/sa1pr11mb713044b81eab485b95d8fb7fb2...@sa1pr11mb7130.namprd11.prod.outlook.com/
[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #8 from Andrew Pinski --- (In reply to cqwrteur from comment #7) > The patch has passed the CI. It is time to review and merge my patch. Thank > you. Before we can review it, can you make sure you follow https://gcc.gnu.org/contribute.html ? You are missing a changelog for one. Second since you are not using your real name, do you have a copyright assignment on file with the FSF? If not please resubmit with your real name and add a signed-off by. Or put in place a copyright assignment.
[Bug c/115549] ICE: tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in common_handle_aligned_attribute, at c-family/c-attribs.cc:2665 with invalid aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115549
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-06-22
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Confirmed.
A slightly better testcase:
```
__attribute__((aligned,optimize(s)))
int s()
{
}
```
[Bug c/115593] New: invalid optimize attribute accepted without warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115593
Bug ID: 115593
Summary: invalid optimize attribute accepted without warning
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
void d(){}
__attribute__((optimize(d)))
void s(){}
```
I would have expected this to at least warn that d is not a valid
string/integer.
[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #9 from cqwrteur --- (In reply to Andrew Pinski from comment #8) > (In reply to cqwrteur from comment #7) > > The patch has passed the CI. It is time to review and merge my patch. Thank > > you. > > Before we can review it, can you make sure you follow > https://gcc.gnu.org/contribute.html ? > You are missing a changelog for one. > Second since you are not using your real name, do you have a copyright > assignment on file with the FSF? If not please resubmit with your real name > and add a signed-off by. Or put in place a copyright assignment. https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655461.html Is this ok now?
[Bug c/115566] Arrays of character type initialized with parenthesized string literals shouldn't be diagnosed with -pedantic (at least in C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115566 --- Comment #7 from Joseph S. Myers --- The initializer with _Generic should not be accepted; that should be reported as a bug.
[Bug libstdc++/115585] --disable-libstdcxx-verbose causes undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_, version GLIBCXX_3.4.30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115585 --- Comment #10 from cqwrteur --- https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655462.html
[Bug c++/115594] New: requires expression permits arrays of voids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115594
Bug ID: 115594
Summary: requires expression permits arrays of voids
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program
```
template
concept C = requires(T t[2]) {
t;
};
static_assert(!C);
```
seems valid because arrays of voids are not allowed, and it is accepted by
Clang and MSVC. But in GCC static_assert evaluates to opposite value. Online
demo: https://gcc.godbolt.org/z/nM8Mj8qrb
[Bug c++/115594] requires expression permits arrays of voids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115594 --- Comment #1 from Andrew Pinski --- The interesting thing is the reason why clang outputs: :2:25: note: because 't' would be invalid: array has incomplete element type 'void' Is not exactly correct as if you change void to being a incomplete type: struct A; static_assert(C); it is accepted by all compilers ...
[Bug c++/115594] requires expression permits arrays of voids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115594 --- Comment #2 from Andrew Pinski --- I think this is a dup of bug 24664.
[Bug c/115566] Arrays of character type initialized with parenthesized string literals shouldn't be diagnosed with -pedantic (at least in C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115566
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #8 from Harald van Dijk ---
I believe this bug is valid; the change from
> A parenthesized expression is a primary expression. Its type and value are
> identical to those of the unparenthesized expression. It is an lvalue, a
> function designator, or a void expression if the unparenthesized expression
> is, respectively, an lvalue, a function designator, or a void expression.
to the already quoted
> A parenthesized expression is a primary expression. Its type, value, and
> semantics are identical to those of the unparenthesized expression.
only makes sense if the intent was to to also make parenthesized expressions
equivalent to unparenthesized expressions in other ways than those previously
enumerated.
But at any rate, GCC is inconsistent. The exact same argument applies to null
pointer constants. Null pointer constants are defined as
> An integer constant expression with the value 0, or such an expression cast
> to type void *, is called a null pointer constant.
Note that such an expression cast to type void *, and then wrapped in
parentheses, is not explicitly included.
Yet GCC accepts
#define NULL ((void*)0)
int main(void) {
void(*fp)(void) = NULL;
}
when the same overly pedantic reading should result in "ISO C forbids
initialization between function pointer and 'void *'" here.
Either parenthesized expressions are just generally equivalent to
non-parenthesized expressions, and both the OP's code and this program are
valid, or parenthesized expressions are only like the non-parenthesized
expressions in the specifically enumerated ways, in which case both the OP's
code and this program violate a constraint and require a diagnostic. You can
choose which of those interpretations you prefer, but they both indicate a bug
in GCC.
[Bug target/115485] CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at config/arm/arm.c:7855
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485 --- Comment #10 from Andrew Pinski --- Can you provide the preprocessed source (which you can get via -save-temps)? This is mentioned in https://gcc.gnu.org/bugs/ on what we require.
[Bug tree-optimization/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 --- Comment #7 from Andrew Pinski --- Trying to reduce it ...
[Bug tree-optimization/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 --- Comment #8 from Andrew Pinski --- Created attachment 58489 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58489&action=edit First step at reducing Keeps map_to_vector the same, changes the lamdba just to set resultIsStatic to false and removes the rest of the function. (also removes some unused code too). Changes the to use __built_trap after the function call to make it easier to test it. The bug is still hit.
[Bug tree-optimization/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 --- Comment #9 from Andrew Pinski --- If I manually inline map_range into map_to_vector, it works ...
[Bug tree-optimization/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 --- Comment #10 from Andrew Pinski --- (In reply to Andrew Pinski from comment #9) > If I manually inline map_range into map_to_vector, it works ... I take that back, it still fails. I must have been testing something else.
[Bug tree-optimization/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 Andrew Pinski changed: What|Removed |Added Attachment #58489|0 |1 is obsolete|| --- Comment #11 from Andrew Pinski --- Created attachment 58490 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58490&action=edit Further Removed SmallVector and ArrayRef. Should have a run time test soon. Note for this code, I need to add `-fno-early-inlining` to get the failure.
[Bug tree-optimization/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 Andrew Pinski changed: What|Removed |Added Attachment #58178|0 |1 is obsolete|| Attachment #58490|0 |1 is obsolete|| --- Comment #12 from Andrew Pinski --- Created attachment 58491 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58491&action=edit Runtime testcase Works at -O0 and -O2 but fails at `-O2 -fno-early-inlining`.
[Bug tree-optimization/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2024-05-10 00:00:00 |2024-06-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #13 from Andrew Pinski --- Confirmed with my reduced testcase. Note the header files are still needed, I didn't try to get rid of std::move or std::forward just yet. The other 2 header files are just for uint64_t/int64_t/size_t .
[Bug ipa/115533] [12/13/14/15 regression] flac miscompiled with -O3 -march=znver2 -fipa-pta -fno-vect-cost-model since r12-3893-g6390c5047adb75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533 Sam James changed: What|Removed |Added Attachment #58484|0 |1 is obsolete|| --- Comment #17 from Sam James --- Created attachment 58492 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58492&action=edit test.c This seems to be the best I can get out of it. The original (upstream) code passes with -ffp-contract=off, so if this is invalid, no feelings will be hurt. I'm going to keep looking for other IPA miscompilations when I have spare cycles. This reduced testcase passes with gcc 11 with -O3 -march=znver2 -fno-vect-cost-model -fipa-pta -ffp-contract=fast, but fails with 12+ with the same options. The relationship with the vectoriser here makes it hard to understand (in addition to my inexperience with FP so far).
[Bug tree-optimization/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 --- Comment #14 from Andrew Pinski --- Created attachment 58493 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58493&action=edit Reduced all the way, removing std::forward/std::move This now fails at -O2 (since I marked the functions that needed not to be inlined).
[Bug tree-optimization/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 --- Comment #15 from Andrew Pinski --- Created attachment 58494 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58494&action=edit Removing the lamdba and making it C This is an alternative which removes the lamdba and makes it a GNU C testcase.
[Bug tree-optimization/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033 Sam James changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108250 --- Comment #16 from Sam James --- (In reply to Richard Biener from comment #4) > so it might be interesting to try reducing it further. I'll note that > using -fno-ipa-modref avoids FRE doing the CSE but -fno-strict-aliasing > doesn't. So maybe it's a genuine modref bug. IIRC there are some > that might be fixed in GCC 14 but not yet earlier. It also looks similar to one of the tblgen issues we had before but couldn't make standalone.
[Bug ipa/115135] [12/13/14/15 regression] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants since r12-5113-gd70ef65692fced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115033 --- Comment #11 from Andrew Pinski --- Looking the same as PR 115033 ...
[Bug rtl-optimization/951] Documentation of compiler passes and sources very out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=951 --- Comment #15 from Eric Gallager --- (In reply to Richard Biener from comment #14) > (In reply to Andrew Pinski from comment #13) > > (In reply to Eric Gallager from comment #12) > > > Patch posted that might help with this a little bit: > > > https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648306.html > > > > I don't know how much of that patch overlaps with what Richi pushed: > > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655312.html > > Forgot about that, but ISTR I approved something in the end? > > Anyway, reading over it the situation isn't as bad as described. So, is it ok to close this yet, or...?
[Bug c/115587] [14/15 Regression] Possible uninitialized variable (decl) in c_parser_omp_loop_nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115587 --- Comment #2 from sandra at gcc dot gnu.org --- I'll take care of this.
[Bug c/115587] [14/15 Regression] Possible uninitialized variable (decl) in c_parser_omp_loop_nest since r14-3489-g143151ac2013c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115587 Sam James changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-06-23 Ever confirmed|0 |1 Summary|[14/15 Regression] Possible |[14/15 Regression] Possible |uninitialized variable |uninitialized variable |(decl) in |(decl) in |c_parser_omp_loop_nest |c_parser_omp_loop_nest ||since ||r14-3489-g143151ac2013c2
[Bug target/114139] ICE: RTL check: expected code 'const_int', have 'reg' in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8438 with -O2 -fpic -mexplicit-relocs -mcpu=sifive-p450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114139 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2024-06-23 CC||law at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug target/115485] CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at config/arm/arm.c:7855
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485 --- Comment #11 from Gang Peng --- (In reply to Andrew Pinski from comment #10) > Can you provide the preprocessed source (which you can get via -save-temps)? > This is mentioned in https://gcc.gnu.org/bugs/ on what we require. Dear Andrew, Thank you very much for your kindly reply. Attached is the build log with -save-temps, If need any other info, please feel free to let me know. Thanks & BRs Gang Peng
[Bug target/115485] CASEServer.cpp:203:1: internal compiler error: in require_pic_register, at config/arm/arm.c:7855
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115485 --- Comment #12 from Gang Peng --- Created attachment 58495 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58495&action=edit build_save_temp_log.tar.gz
[Bug target/115409] avx512 intrinsics trigger -Wshift-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115409 --- Comment #5 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:4c957d7ba84d8bbce6e778048f38e92ef71806c8 commit r15-1563-g4c957d7ba84d8bbce6e778048f38e92ef71806c8 Author: Collin Funk Date: Mon Jun 10 06:36:47 2024 + AVX-512: Pacify -Wshift-overflow=2. [PR115409] A shift of 31 on a signed int is undefined behavior. Since unsigned int is 32-bits wide this change fixes it and silences the warning. gcc/ChangeLog: PR target/115409 * config/i386/avx512fp16intrin.h (_mm512_conj_pch): Make the constant unsigned before shifting. * config/i386/avx512fp16vlintrin.h (_mm256_conj_pch): Likewise. (_mm_conj_pch): Likewise. Signed-off-by: Collin Funk
