[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #9 from Jakub Jelinek ---
Unfortunately the above patch regressed g++.dg/opt/is_constant_evaluated3.C
test.
For constructors, even when they have VOID_TYPE_P, initialized_type actually
returns non-VOID type, so constructors are optimized (though, dunno if not
differently on arm where initialized_type will likely return class* while on
other targets class).
So, we'd need to treat that way just destructors (if it shouldn't be fixed
elsewhere):
2024-03-23 Jakub Jelinek
PR c++/114426
* cp-gimplify.cc (cp_fold): Don't call maybe_const_value on
CALL_EXPRs to cdtors.
* g++.dg/cpp2a/pr114426.C: New test.
--- gcc/cp/cp-gimplify.cc.jj2024-02-23 18:55:05.377594277 +0100
+++ gcc/cp/cp-gimplify.cc 2024-03-22 16:46:49.381442914 +0100
@@ -3395,7 +3395,13 @@ cp_fold (tree x, fold_flags_t flags)
Do constexpr expansion of expressions where the call itself is not
constant, but the call followed by an INDIRECT_REF is. */
if (callee && DECL_DECLARED_CONSTEXPR_P (callee)
- && !flag_no_inline)
+ && !flag_no_inline
+ /* Don't invoke it on dtors. On
+ !targetm.cxx.cdtor_returns_this () it won't do anything as it
+ has void type, so don't do it on
+ targetm.cxx.cdtor_returns_this () targets either for
+ consistency. */
+ && !DECL_DESTRUCTOR_P (callee))
{
mce_value manifestly_const_eval = mce_unknown;
if (flags & ff_mce_false)
--- gcc/testsuite/g++.dg/cpp2a/pr114426.C.jj2024-03-22 16:49:55.650882841
+0100
+++ gcc/testsuite/g++.dg/cpp2a/pr114426.C 2024-03-22 16:48:51.829759997
+0100
@@ -0,0 +1,6 @@
+// PR c++/114426
+// { dg-do compile }
+
+struct A { virtual ~A (); };
+struct B : virtual A { virtual void foo () = 0; };
+struct C : B { C () {} };
[Bug testsuite/109549] [14 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 Sam James changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #12 from Sam James --- Changing back to NEW, although stefansf may want to take it(?)
[Bug c++/114439] New: [14 Regression] icu4c-73.2 build failure: invalid initializer for array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439
Bug ID: 114439
Summary: [14 Regression] icu4c-73.2 build failure: invalid
initializer for array member
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially observed build failure on icu4c-73.2 using gcc
r14-9636-gc2e28df90a1640 .
The build fails there as:
regexst.cpp: In constructor
'icu_73::RegexStaticSets::RegexStaticSets(UErrorCode*)':
regexst.cpp:75:52: error: invalid initializer for array member
'icu_73::UnicodeSet icu_73::RegexStaticSets::fPropSets [13]'
75 | RegexStaticSets::RegexStaticSets(UErrorCode *status) {
|^
regexst.cpp:75:52: error: invalid initializer for array member
'icu_73::Regex8BitSet icu_73::RegexStaticSets::fPropSets8 [13]'
regexst.cpp:75:52: error: invalid initializer for array member
'icu_73::UnicodeSet icu_73::RegexStaticSets::fRuleSets [3]'
Minimized example:
$ cat regexst.cpp.cpp
struct UnicodeSet {
int *list = stackList;
int stackList[];
};
struct RegexStaticSets {
RegexStaticSets() {}
UnicodeSet fPropSets[2]{};
};
$ g++-14 -std=c++11 -c regexst.cpp.cpp -o bug.o
regexst.cpp.cpp: In constructor 'RegexStaticSets::RegexStaticSets()':
regexst.cpp.cpp:6:21: error: invalid initializer for array member 'UnicodeSet
RegexStaticSets::fPropSets [2]'
6 | RegexStaticSets() {}
| ^
For comparison gcc-13 looks fine:
$ g++-13 -std=c++11 -c regexst.cpp.cpp -o bug.o
Compiler version:
$ g++-14 -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.1/bin/g++
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.1/libexec/gcc/x86_64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-14.0.1
--with-gmp-include=/<>/gmp-6.3.0-dev/include
--with-gmp-lib=/<>/gmp-6.3.0/lib
--with-mpfr-include=/<>/mpfr-4.2.1-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.1/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.39-dev/include
--with-build-sysroot=/
--with-gxx-include-dir=/<>/gcc-14.0.1/include/c++/14.0.1/
--program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 (experimental) (GCC)
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #5 from Sam James --- I can't reproduce this when building poedit. Don't have pbcopper or s2geometry packaged.
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 --- Comment #26 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8fc5593df8e0d36cc5bd8ea21097a491a634a866 commit r14-9639-g8fc5593df8e0d36cc5bd8ea21097a491a634a866 Author: Jakub Jelinek Date: Sat Mar 23 11:17:44 2024 +0100 predcom: Punt for steps which aren't multiples of access size [PR111683] On the following testcases, there is no overlap between data references within a single iteration, but the data references have size which is twice as large as the step, which means the data references overlap with the next iteration which predcom doesn't take into account. As discussed in the PR, even if the reference size is smaller than step, if step isn't a multiple of the reference size, there could be overlaps with some other iteration later on. The initial version of the patch regressed (test still passed, but predcom didn't optimize anymore) pr71083.c which has a packed char, short structure and was reading/writing the short 2 bytes in there with step 3. The following patch deals with that by retrying for COMPONENT_REFs also the aggregate sizes etc., so that it then compares 3 bytes against step 3. In make check-gcc/check-g++ this patch I believe affects code generation for only the 2 new testcases according to statistics I've gathered. 2024-03-23 Jakub Jelinek PR middle-end/111683 * tree-predcom.cc (pcom_worker::suitable_component_p): If has_write and comp_step is RS_NONZERO, return false if any reference in the component doesn't have DR_STEP a multiple of access size. * gcc.dg/pr111683-1.c: New test. * gcc.dg/pr111683-2.c: New test.
[Bug tree-optimization/114425] wrong code with _BitInt() __builtin_add_overflow_p() and __builtin_mul_overflow_p() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f92cf8cbbe199bda70d0dd7893e8c8836777e2d0
commit r14-9640-gf92cf8cbbe199bda70d0dd7893e8c8836777e2d0
Author: Jakub Jelinek
Date: Sat Mar 23 11:19:09 2024 +0100
bitint: Handle complex types in build_bitint_stmt_ssa_conflicts [PR114425]
The task of the build_bitint_stmt_ssa_conflicts hook for
tree-ssa-coalesce.cc next to special casing the
multiplication/division/modulo is to ignore statements with
large/huge _BitInt lhs which isn't in names bitmap and on the
other side pretend all uses of the stmt are used in a later stmt
(single user of that SSA_NAME or perhaps single user of lhs of
the single user etc.) where the lowering will actually emit the
code.
Unfortunately the function wasn't handling COMPLEX_TYPE of the large/huge
BITINT_TYPE, while the FE doesn't really support such types, they are
used under the hood for __builtin_{add,sub,mul}_overflow{,_p}, they are
also present or absent from the names bitmap and should be treated the
same.
Without this patch, the operands of .ADD_OVERFLOW were incorrectly
pretended
to be used right in that call statement rather than on the cast stmt from
IMAGPART_EXPR of .ADD_OVERFLOW return value to some integral type.
2024-03-23 Jakub Jelinek
PR tree-optimization/114425
* gimple-lower-bitint.cc (build_bitint_stmt_ssa_conflicts): Handle
_Complex large/huge _BitInt types like the large/huge _BitInt
types.
* gcc.dg/torture/bitint-67.c: New test.
[Bug tree-optimization/114433] ICE: verify_ssa failed: definition in block 9 does not dominate use in block 8 with _BitInt() bitfield shift at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114433 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4a46a48ebc7b7b3976af49f6f8dabd65c6ddf64b commit r14-9641-g4a46a48ebc7b7b3976af49f6f8dabd65c6ddf64b Author: Jakub Jelinek Date: Sat Mar 23 11:20:00 2024 +0100 bitint: Fix bitfield loads in handle_cast [PR114433] We ICE on the following testcase, because handle_cast was incorrectly testing !m_first to see whether it should use m_data[m_bitfld_load + 1] or fresh SSA_NAME for a PHI result. Now, m_first is in the routine sometimes temporarily cleared in between doing prepare_data_in_out and the !m_first check and only before returning restored from the save_first copy. Without this patch, we try to use the same SSA_NAME (_12 here) in 2 different PHI results which is obviously invalid IL and ICEs very quickly. 2024-03-23 Jakub Jelinek PR tree-optimization/114433 * gimple-lower-bitint.cc (bitint_large_huge::handle_cast): For m_bitfld_load check save_first rather than m_first. * gcc.dg/torture/bitint-68.c: New test.
[Bug middle-end/111683] [11/12/13 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |Incorrect answer when using |Incorrect answer when using |SSE2 intrinsics with -O3|SSE2 intrinsics with -O3 |since |since |r7-3163-g973625a04b3d9351f2 |r7-3163-g973625a04b3d9351f2 |485e37f7d3382af2aed87e |485e37f7d3382af2aed87e --- Comment #27 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/114425] wrong code with _BitInt() __builtin_add_overflow_p() and __builtin_mul_overflow_p() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/114433] ICE: verify_ssa failed: definition in block 9 does not dominate use in block 8 with _BitInt() bitfield shift at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114433 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 --- Comment #6 from Sam James --- Got it with pbcopper. Reducing.
[Bug tree-optimization/114440] New: Fail to recognize a chain of lane-reduced operations for loop reduction vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114440
Bug ID: 114440
Summary: Fail to recognize a chain of lane-reduced operations
for loop reduction vect
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fxue at os dot amperecomputing.com
Target Milestone: ---
In a loop reduction path containing a lane-reduced operation
(DOT_PROD/SAD/WIDEN_SUM), current vectorizer could not handle the pattern if
there are other operations, which might be a normal or another lane-reduced
one. A pseudo example is represented as:
char *d0, *d1;
char *s0, *s1;
char *w;
int *n;
...
int sum = 0;
for (i) {
...
sum += d0[i] * d1[i]; /* DOT_PROD */
...
sum += abs(s0[i] - s1[i]); /* SAD */
...
sum += w[i];/* WIDEN_SUM */
...
sum += n[i];/* Normal */
...
}
... = sum;
For the case, reduction vectype would vary with operations, and this causes
mismatch on count of vectorized defs and uses, a possible means might be fixing
that by generating extra trivial pass-through copies. Given a concrete example
as:
sum = 0;
for (i) {
sum += d0[i] * d1[i]; /* 16*char -> 4*int */
sum += n[i];/* 4*int -> 4*int */
}
Final vetorized statements could be:
sum_v0 = { 0, 0, 0, 0 };
sum_v1 = { 0, 0, 0, 0 };
sum_v2 = { 0, 0, 0, 0 };
sum_v3 = { 0, 0, 0, 0 };
for (i / 16) {
sum_v0 += DOT_PROD (v_d0[i: 0 .. 15], v_d1[i: 0 .. 15]);
sum_v1 += 0; // copy
sum_v2 += 0; // copy
sum_v3 += 0; // copy
sum_v0 += v_n[i: 0 .. 3];
sum_v1 += v_n[i: 4 .. 7];
sum_v2 += v_n[i: 8 .. 11];
sum_v3 += v_n[i: 12 .. 15];
}
sum = REDUC_PLUS(sum_v0 + sum_v1 + sum_v2 + sum_v3);
In the above sequence, one summation statement simply forms one pattern.
Though, we could easily compose a somewhat more complicated variant that gets
into the similar situation. That is, a chain of lane-reduced operations comes
from the non-reduction addend in one summation statement, like:
sum += d0[i] * d1[i] + abs(s0[i] - s1[i]) + n[i];
Probably, this requires some extension in the vector pattern formation stage to
split the patterns.
[Bug c++/91493] g++ 9.2.1 crashes compiling clickhouse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91493 Sam James changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Sam James --- *** This bug has been marked as a duplicate of bug 91500 ***
[Bug c++/91500] [9 Regression] gcc-9 ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91500 Sam James changed: What|Removed |Added CC||rafaeldtinoco at ubuntu dot com --- Comment #5 from Sam James --- *** Bug 91493 has been marked as a duplicate of this bug. ***
[Bug libstdc++/114400] The resolution of LWG3950 seems incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114400 --- Comment #7 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f4605c53ea2eeafc13e14dd1ad00a0caf80057e2 commit r14-9642-gf4605c53ea2eeafc13e14dd1ad00a0caf80057e2 Author: Jonathan Wakely Date: Wed Mar 20 11:07:56 2024 + libstdc++: Use std::type_identity_t in as per LWG 3950 [PR114400] The difference between __type_identity_t and std::type_identity_t is observable, as demonstrated in the PR. Nobody in LWG seems to think this an example we should really care about, but it seems easy and harmless to change this. libstdc++-v3/ChangeLog: PR libstdc++/114400 * include/std/string_view (operator==): Use std::type_identity_t in C++20 instead of our own __type_identity_t.
[Bug c++/114441] New: Relocation issues when compiling with -O1,-O2,and -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114441
Bug ID: 114441
Summary: Relocation issues when compiling with -O1,-O2,and -Os
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
Target Milestone: ---
The source file is:
root@ubuntu:~/test/111# cat 222.cpp
#include
int a[1][1][1][1][1];
short b[6268435456];
void c() {
for (size_t d;;)
for (size_t e;;)
for (size_t f;;)
for (size_t g;;)
for (size_t i = 0; i < 16; ++i)
a[d][e][f][g][i] = 2;
}
main() {}
The version of g++:
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/root/software/IP-gcc/gcc-trunk/bin/g++
COLLECT_LTO_WRAPPER=/root/software/IP-gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/root/software/IP-gcc/gcc-trunk
--enable-languages=c,c++ --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240318 (experimental) (GCC)
The issue I had when compiling at different optimization level.At the -O0 and
-O3 optimization level, the compilation proceeded without any errors, but any
attempt to compile with other three optimization levels (-01, -O2 and -Os)
resulted in relocation-related errors, which is also present in exsiting
releases:
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -O0
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -O3
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -O1
/tmp/ccizb4WS.o: In function `c()':
222.cpp:(.text+0xd): relocation truncated to fit: R_X86_64_32S against symbol
`a' defined in .bss section in /tmp/ccizb4WS.o
collect2: error: ld returned 1 exit status
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -O2
/tmp/cchi03vq.o: In function `c()':
222.cpp:(.text+0x13): relocation truncated to fit: R_X86_64_32S against symbol
`a' defined in .bss section in /tmp/cchi03vq.o
collect2: error: ld returned 1 exit status
root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test
-w -Os
/tmp/ccHbxau8.o: In function `c()':
222.cpp:(.text+0x7): relocation truncated to fit: R_X86_64_32S against symbol
`a' defined in .bss section in /tmp/ccHbxau8.o
collect2: error: ld returned 1 exit status
[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439 Sergei Trofimovich changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Sergei Trofimovich --- Bisected down to r14-9622-gd1d8fd2884b445 "c++: direct-init of an array of class type [PR59465]".
[Bug analyzer/114408] [13/14 Regression] ICE when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408 --- Comment #6 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:80a0cb37456c49dbc25cca7cd554f78bc504373e commit r14-9646-g80a0cb37456c49dbc25cca7cd554f78bc504373e Author: David Malcolm Date: Sat Mar 23 09:52:38 2024 -0400 analyzer: fix ICE and false positive with -Wanalyzer-deref-before-check [PR114408] gcc/analyzer/ChangeLog: PR analyzer/114408 * engine.cc (impl_run_checkers): Free up any dominance info that we may have created. * kf.cc (class kf_ubsan_handler): New. (register_sanitizer_builtins): New. (register_known_functions): Call register_sanitizer_builtins. gcc/testsuite/ChangeLog: PR analyzer/114408 * c-c++-common/analyzer/deref-before-check-pr114408.c: New test. * c-c++-common/ubsan/analyzer-ice-pr114408.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/108455] -Wanalyzer-deref-before-check false positive seen in git pack-revindex.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108455 --- Comment #5 from David Malcolm --- Note: the above patch caused the ICE in bug 114408.
[Bug analyzer/114408] [13 Regression] ICE when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408 David Malcolm changed: What|Removed |Added Summary|[13/14 Regression] ICE when |[13 Regression] ICE when |invoking strcmp multiple|invoking strcmp multiple |times with |times with |-fsanitize=undefined -O1|-fsanitize=undefined -O1 |-fanalyzer -flto|-fanalyzer -flto --- Comment #7 from David Malcolm --- Should be fixed on trunk by the above patch. The ICE was introduced by r13-5261-g0d6f7b1dd62e9c9dccb0b9b673f9cc3238b7ea6d when fixing bug 108455. Keeping open to track backporting to GCC 13.
[Bug target/114442] New: ICE: in riscv_sched_variable_issue, at config/riscv/riscv.cc:8421 with -O2 -mtune=xiangshan-nanhu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114442
Bug ID: 114442
Summary: ICE: in riscv_sched_variable_issue, at
config/riscv/riscv.cc:8421 with -O2
-mtune=xiangshan-nanhu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu
Created attachment 57787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57787&action=edit
reduced testcase
Compiler output:
$ riscv64-unknown-linux-gnu-gcc -O2 -mtune=xiangshan-nanhu testcase.c
during RTL pass: sched2
testcase.c: In function 'foo':
testcase.c:1:18: internal compiler error: in riscv_sched_variable_issue, at
config/riscv/riscv.cc:8421
1 | void foo (void) {}
| ^
0xb84f66 riscv_sched_variable_issue
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:8421
0xb84f66 riscv_sched_variable_issue
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:8401
0x2a4205e schedule_block(basic_block_def**, void*)
/repo/gcc-trunk/gcc/haifa-sched.cc:6912
0x16b4f74 schedule_region
/repo/gcc-trunk/gcc/sched-rgn.cc:3203
0x16b4f74 schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.cc:3525
0x16b540d schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.cc:3511
0x16b540d rest_of_handle_sched2
/repo/gcc-trunk/gcc/sched-rgn.cc:3749
0x16b540d execute
/repo/gcc-trunk/gcc/sched-rgn.cc:3888
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9644-20240323110757-g543585046d1-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--enable-libsanitizer --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9644-20240323110757-g543585046d1-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240323 (experimental) (GCC)
[Bug modula2/114443] New: missing quote causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114443 Bug ID: 114443 Summary: missing quote causes ICE Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- A missing end of string quote causes an ICE, for example: MODULE missingquote ; CONST MyConst = 'foobar BEGIN END missingquote. $ gm2 missingquote.mod missingquote.mod:4: MyConst = 'foobar missingquote.mod:4: ^^^ missingquote.mod:4:missing terminating quote, ' cc1gm2: internal compiler error: in libc_abort, at m2/mc-boot-ch/Glibc.c:161
[Bug modula2/114443] missing quote causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114443 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2024-03-23 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug modula2/114443] missing quote causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114443 --- Comment #1 from Gaius Mulley --- Created attachment 57788 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57788&action=edit Proposed fix This patch inserts a missing quotation at the end of a line if required (after an appropiate error message is generated). gcc/m2/ChangeLog: * m2.flex: Call AddTokCharStar with a stringtok if end of line is reached without a closing quote. gcc/testsuite/ChangeLog: * gm2/pim/fail/missingquote.mod: New test.
[Bug modula2/114443] missing quote causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114443 --- Comment #2 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:c8a343f9f8602f4e6c1b385ddbeb58572234d447 commit r14-9647-gc8a343f9f8602f4e6c1b385ddbeb58572234d447 Author: Gaius Mulley Date: Sat Mar 23 15:49:23 2024 + PR modula2/114443 missing quote cause ICE This patch inserts a missing quotation at the end of a line if required (after an appropiate error message is generated). gcc/m2/ChangeLog: PR modula2/114443 * m2.flex: Call AddTokCharStar with a stringtok if end of line is reached without a closing quote. gcc/testsuite/ChangeLog: PR modula2/114443 * gm2/pim/fail/missingquote.mod: New test. Signed-off-by: Gaius Mulley
[Bug modula2/114443] missing quote causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114443 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Gaius Mulley --- Closing now the patch has been applied.
[Bug modula2/114444] New: An error in the FLOAT/TRUNC will cause ICE due to malformed error specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 Bug ID: 11 Summary: An error in the FLOAT/TRUNC will cause ICE due to malformed error specifier Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- When blackbox testing it appears that an error relating to either TRUNC or FLOAT will cause an ICE. Upon gdb stack back trace it shows a malformed error format.
[Bug modula2/114444] An error in the FLOAT/TRUNC will cause ICE due to malformed error specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-03-23 --- Comment #1 from Gaius Mulley --- Confirmed.
[Bug modula2/114444] An error in the FLOAT/TRUNC will cause ICE due to malformed error specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 --- Comment #2 from Gaius Mulley --- Created attachment 57789 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57789&action=edit Proposed fix This patch corrects two error format specifiers. gcc/m2/ChangeLog: * gm2-compiler/M2Quads.mod (BuildTruncFunction): Correct error format specifier. (BuildFloatFunction): Correct error format specifier.
[Bug modula2/114444] An error in the FLOAT/TRUNC will cause ICE due to malformed error specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:a68458187d4c889dc11b2b95f08a61adf087f69d commit r14-9648-ga68458187d4c889dc11b2b95f08a61adf087f69d Author: Gaius Mulley Date: Sat Mar 23 16:04:23 2024 + PR modula2/11 trunc float malformed error cause ICE This patch corrects two error format specifiers. gcc/m2/ChangeLog: PR modula2/11 * gm2-compiler/M2Quads.mod (BuildTruncFunction): Correct error format specifier. (BuildFloatFunction): Correct error format specifier. Signed-off-by: Gaius Mulley
[Bug modula2/114444] An error in the FLOAT/TRUNC will cause ICE due to malformed error specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Gaius Mulley --- Closing now the patch has been applied.
[Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114441 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- This is not a GCC bug, You need to use -mcmodel=large if you have huge statically allocated arrays. The default -mcmodel=medium does not support more than 2GB size arrays See https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html#index-mcmodel_003dlarge-3
[Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114441 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #2 from Sam James --- It might be worth filing an ld bug for a better error message.
[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member with initialization of array of struct containing flexible arrays since r14-962
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Summary|[14 Regression] icu4c-73.2 |[14 Regression] icu4c-73.2 |build failure: invalid |build failure: invalid |initializer for array |initializer for array |member |member with initialization ||of array of struct ||containing flexible arrays ||since r14-962 Keywords||rejects-valid Target Milestone|--- |14.0
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #13 from dave.anglin at bell dot net --- With the patch, we now have: name7161.cc:5: error: #error '__cpp_lib_text_encoding' is false compiler exited with status 1 UNSUPPORTED: std/text_encoding/cons.cc -std=gnu++26 UNSUPPORTED: std/text_encoding/members.cc -std=gnu++26 name7161.cc:5: error: #error '__cpp_lib_text_encoding' is false compiler exited with status 1 UNSUPPORTED: std/text_encoding/requirements.cc -std=gnu++26 The FAILs are gone.
[Bug libstdc++/114103] FAIL: 29_atomics/atomic/lock_free_aliases.cc -std=gnu++20 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103 John David Anglin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #18 from John David Anglin --- Fixed.
[Bug ada/114424] gnat: Ada.Calendar.Clock crashes on 32bit architectures with 64bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114424 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Why don"t you use s-osprim__posix2008.adb if you use s-parame__posix2008.ads? *** This bug has been marked as a duplicate of bug 114065 ***
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #5 from Eric Botcazou --- *** Bug 114424 has been marked as a duplicate of this bug. ***
[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member with initialization of array of struct containing arrays since r14-962
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-03-23 Status|UNCONFIRMED |NEW Summary|[14 Regression] icu4c-73.2 |[14 Regression] icu4c-73.2 |build failure: invalid |build failure: invalid |initializer for array |initializer for array |member with initialization |member with initialization |of array of struct |of array of struct |containing flexible arrays |containing arrays since |since r14-962 |r14-962 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed. The array inside UnicodeSet does not need to be flexible to have this rejected.
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #1 from anlauf at gcc dot gnu.org --- Can you be a little more explicit? If I extend the program as follows: type(params) :: p p = params( 0.1, 2.0 ) write(*,*) p p = params( 0.1, 2 ) write(*,*) p I get with all compilers I have access to (Intel, NAG, Nvidia, flang, gfortran) Not the structure constructor 0.10001 4. 0.10001 2. This is what I would have naively expected in accordance with "Note 1": The form ’name(...)’ is interpreted as a generic function-reference if possible; it is interpreted as a structure-constructor only if it cannot be interpreted as a generic function-reference. which gives a precedence to function-reference over structure-constructor, making it possible to override the default constructor. Are you saying that one cannot override the default constructor?
[Bug libgomp/114445] New: [OpenMP] indirect - potential race when creating reverse-offload hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114445
Bug ID: 114445
Summary: [OpenMP] indirect - potential race when creating
reverse-offload hash
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
It looks as if when starting two kernels very quickly after another as in
#pragma omp target nowait
...
#pragma omp target
...
Two device threads might concurrently create the hash in
libgomp/config/accel/target-indirect.c's build_indirect_map
if (!indirect_htab)
{
/* Count the number of entries in the NULL-terminated address map. */
for (map_entry = GOMP_INDIRECT_ADDR_MAP; *map_entry;
map_entry += 2, num_ind_funcs++);
indirect_htab = htab_create (num_ind_funcs);
The issue only occurs if the assignment of the allocated memory done in the
first thread occurs after the second kernel has checked for indirect_htab ==
NULL, which seems to be rather unlikely to happen in the real world, but IMHO
cannot be ruled out.
Thus, I was wondering (see email) whether a tmp variable + CAS should be used
for indirect_htab; if the swap failed, the memory could just be freed as
another process was faster - and has also completed by then the creation of the
htab.
See also
r14-9629-g637e76b90e8b045c5e25206a41e3be55deace8d5
openmp: Change to using a hashtab to lookup offload target addresses for
indirect function calls
and review email at
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647755.html
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #1) > Can you be a little more explicit? > > If I extend the program as follows: > > type(params) :: p > p = params( 0.1, 2.0 ) > write(*,*) p > p = params( 0.1, 2 ) > write(*,*) p > > I get with all compilers I have access to (Intel, NAG, Nvidia, flang, > gfortran) > > Not the structure constructor > 0.10001 4. > 0.10001 2. > > This is what I would have naively expected in accordance with "Note 1": > > The form ’name(...)’ is interpreted as a generic function-reference if > possible; it is interpreted as a structure-constructor only if it cannot > be interpreted as a generic function-reference. > > which gives a precedence to function-reference over structure-constructor, > making it possible to override the default constructor. > > Are you saying that one cannot override the default constructor? I thought C7108 was clear. C7108 (R756) If derived-type-spec is a type name that is the same as a generic name, the component-spec-list shall not be a valid actual-arg-spec-list for a function reference that is resolvable as a generic reference to that name (15.5.5.2). The derived-type-spec is 'params'. The generic name is 'params'. The component-spec-list for the derived type in 'p = params(3.0,2.0)' has types of 'real' and 'real'. The generic reference is 'p = params(3.0,2.0)', which resolves to 'default_params'. 'default_params' has an actual-arg-spec-list with types of 'real' and 'real'. Thus, 'params(real,real)' is ambiguous. Is it the structure constructor or a generic function reference? Note, you cannot use keywords as the components of the derive type 'params' are 'x' and 'y', and the dummy arguments for 'default_params' are also 'x' and 'y'. Finally, 'p = params(3,2.0)' is a structure constructor, because the generic interface does not include a function with types of 'integer' and 'real'. Thus, here, this is not a function reference. It must be a structure constructor. The rules of intrinsic assignment are now in play, and 'params(3,2.0)' is treated as 'params(3.0,2.0)' after type conversion. Of course, I could be wrong.
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #3 from anlauf at gcc dot gnu.org --- The same text existed in F2018, so it is not new: F2018:C7103 and Note 1. Either every compiler developer team misunderstood that clause, or we need an interp, based on the example, to be able to convince all of them. (I know of developers who do overwrite default constructors, and it currently works "everywhere", so clarification is important.) What do you think?
[Bug fortran/55978] class_optional_2.f90 -Os fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 --- Comment #32 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:57062bc355aece623c6a38c5e813ed24f8b775f1 commit r13-8491-g57062bc355aece623c6a38c5e813ed24f8b775f1 Author: Harald Anlauf Date: Fri Mar 22 18:17:15 2024 +0100 Fortran: no size check passing NULL() without MOLD argument [PR55978] gcc/fortran/ChangeLog: PR fortran/55978 * interface.cc (gfc_compare_actual_formal): Skip size check for NULL() actual without MOLD argument. gcc/testsuite/ChangeLog: PR fortran/55978 * gfortran.dg/null_actual_5.f90: New test.
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:344b60addb79278c95b7a5712aaf38721a27 commit r13-8492-g344b60addb79278c95b7a5712aaf38721a27 Author: Harald Anlauf Date: Fri Mar 15 20:14:07 2024 +0100 Fortran: fix for absent array argument passed to optional dummy [PR101135] gcc/fortran/ChangeLog: PR fortran/101135 * trans-array.cc (gfc_get_dataptr_offset): Check for optional arguments being present before dereferencing data pointer. gcc/testsuite/ChangeLog: PR fortran/101135 * gfortran.dg/missing_optional_dummy_6a.f90: Adjust diagnostic pattern. * gfortran.dg/ubsan/missing_optional_dummy_8.f90: New test.
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.3 Status|NEW |RESOLVED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to 13-branch. Closing. Thanks for the report and the draft patch!
[Bug c/101478] [11/12/13/14 Regression] ICE with statement expression and offsetof like expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101478
Andrew Pinski changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13/14 Regression]
|ICE on invalid code:|ICE with statement
|recompute_tree_invariant_fo |expression and offsetof
|r_addr_expr |like expression
Priority|P4 |P3
Keywords|error-recovery, |ice-on-valid-code
|ice-on-invalid-code |
--- Comment #4 from Andrew Pinski ---
You can make this valid (maybe not runtime defined) GNU C code that ICEs in the
same way:
```
struct obj {
int n;
int l;
};
int main() {
(struct obj *)((char *)(__SIZE_TYPE__)({ 0; }) - (char *)&((struct obj
*)0)->l);
}
```
[Bug c/98621] [11/12/13/14 Regression] ICE: x from g referenced in f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98621 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||14.0 --- Comment #7 from Andrew Pinski --- Looks like this was fixed on the trunk.
[Bug c/109618] [12/13/14 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in generic_simplify_CONVERT_EXPR, at generic-match.cc since r12-3278-g823685221de986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109618 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.4 Summary|ICE: tree check: expected |[12/13/14 Regression] ICE: |class ‘type’, have |tree check: expected class |‘exceptional’ (error_mark) |‘type’, have ‘exceptional’ |in |(error_mark) in |generic_simplify_CONVERT_EX |generic_simplify_CONVERT_EX |PR, at generic-match.cc |PR, at generic-match.cc |since |since |r12-3278-g823685221de986|r12-3278-g823685221de986
[Bug c/109618] [12/13/14 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in generic_simplify_CONVERT_EXPR, at generic-match.cc since r12-3278-g823685221de986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109618 --- Comment #3 from Andrew Pinski --- This one seems harder to fix. We have: ``` (gdb) p debug_tree(value) unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x77822000 precision:64 min max > readonly arg:0 readonly used unsigned read SI t2.c:3:22 size unit-size align:32 warn_if_not_align:0 context initial >> ``` Before calling fold. So we turn var_1's type to error_mark when merging the 2 decls (after an error). But then the rest of the front-end/middle-end is still not ready for types all the time to have an error_mark. Note I don't think we should revert r12-3278 even though it has had a lot of fall out because it produces better error recovery in general. Note for this simplified testcase we could look through the NOP_EXPR in c_sizeof_alignof but a more complex one which does s/var_5[var_1]/var_5[13 * var_1]/, we can't as we get: (sizetype) ((unsigned int) var_1 * 13) And that one ICEs in tree_nonzero_bits. CASE_CONVERT: return wide_int::from (tree_nonzero_bits (TREE_OPERAND (t, 0)), TYPE_PRECISION (TREE_TYPE (t)), TYPE_SIGN (TREE_TYPE (TREE_OPERAND (t, 0;
[Bug c/101313] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in count_type_elements, at expr.c:6273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101313
--- Comment #3 from Andrew Pinski ---
This fixes the ICE:
```
[apinski@xeond2 gcc]$ git diff
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 2918c469735..06f640009c6 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -7014,7 +7014,7 @@ count_type_elements (const_tree type, bool for_ctor_p)
of the fields. */
n = 1;
for (f = TYPE_FIELDS (type); f ; f = DECL_CHAIN (f))
- if (TREE_CODE (f) == FIELD_DECL)
+ if (TREE_CODE (f) == FIELD_DECL && !error_operand_p (f))
{
m = count_type_elements (TREE_TYPE (f), false);
/* If the field doesn't span the whole union, add an extra
```
Since this function is only called from the FE or while gimplifying, the check
for error_operand should be ok.
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #3) > The same text existed in F2018, so it is not new: F2018:C7103 and Note 1. > > Either every compiler developer team misunderstood that clause, or we > need an interp, based on the example, to be able to convince all of them. > > (I know of developers who do overwrite default constructors, and it currently > works "everywhere", so clarification is important.) > > What do you think? I don't have other compilers to check, but I think my interpretation of F2023:C7108 was intended to prevent ambiguity. Note, F2003:C489 is nearly verbatim with F2023:c7108. So, this goes back years as a constraint. I forgot to mention that I found this at https://fortran-lang.discourse.group/t/type-mismatch-in-literal-constant-constructor-for-derived-type-allowed/7669
[Bug c/98195] ICE after `void value not ignored as it ought to be` error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98195 Andrew Pinski changed: What|Removed |Added Summary|internal compiler error:|ICE after `void value not |Segmentation fault |ignored as it ought to be` ||error Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- We have: ``` (gdb) p debug_tree(*expr_p) > side-effects arg:0 addressable used ignored read VOID t9.c:9:2 align:8 warn_if_not_align:0> arg:1 side-effects fn constant arg:0 t9.c:9:7 start: t9.c:9:7 finish: t9.c:9:9> t9.c:9:7 start: t9.c:9:7 finish: t9.c:9:27> t9.c:9:4 start: t9.c:9:4 finish: t9.c:9:5> ``` Maybe we should have created a target_expr with an error_mark instead. Let me look into this.
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 --- Comment #10 from Marcel Jacobse --- Great, already working on compiler explorer with gfortran (trunk). Thanks a lot!
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #3) > The same text existed in F2018, so it is not new: F2018:C7103 and Note 1. > > Either every compiler developer team misunderstood that clause, or we > need an interp, based on the example, to be able to convince all of them. > > (I know of developers who do overwrite default constructors, and it currently > works "everywhere", so clarification is important.) > > What do you think? I sent an email to the J3 mailing list https://mailman.j3-fortran.org/pipermail/j3/2024-March/014649.html I included a question whether keywords can be used.
[Bug target/57054] Compilation with -O3 passes, with -O2 fails (ARM/NEON)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57054 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=63870 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed in GCC 6 by the patches that were done for PR 63870. So closing.
[Bug c/93577] [11/12/13/14 Regression] internal compiler error: tree check: expected integer_cst, have non_lvalue_expr in get_len, at tree.h:5902
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93577 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|11.5|10.0 Status|NEW |RESOLVED --- Comment #11 from Andrew Pinski --- Fixed.
[Bug preprocessor/114436] #pragma GCC system_header vs. _Pragma("GCC system_header")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114436 Lewis Hyatt changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||48297.html --- Comment #3 from Lewis Hyatt --- Slight variation of the above submitted for review at https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648297.html
[Bug c/107683] [13/14 Regression] ICE in int_fits_type_p, at tree.cc:8044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107683 Andrew Pinski changed: What|Removed |Added Known to work||14.0 Keywords||needs-bisection --- Comment #4 from Andrew Pinski --- Looks to be fixed on the trunk.
[Bug c/112571] [13 Regression] ICE with nested redefinition of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112571 Andrew Pinski changed: What|Removed |Added CC||gs...@t-online.de --- Comment #5 from Andrew Pinski --- *** Bug 107683 has been marked as a duplicate of this bug. ***
[Bug c/107683] [13/14 Regression] ICE in int_fits_type_p, at tree.cc:8044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107683 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup. Even though PR 112571 is newer, it is the one which has the fix associated with it. *** This bug has been marked as a duplicate of bug 112571 ***
[Bug c/100544] ICE: in default_conversion with destructor attribute at the top level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100544 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |13.0 Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- It is a dup. *** This bug has been marked as a duplicate of bug 90658 ***
[Bug c/90658] [10/11/12/13 Regression] ICE in default_conversion, at c/c-typeck.c:2159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90658 Andrew Pinski changed: What|Removed |Added CC||cnsun at uwaterloo dot ca --- Comment #13 from Andrew Pinski --- *** Bug 100544 has been marked as a duplicate of this bug. ***
[Bug c/100993] ICE with -O2: Segmentation fault, cgraph_update_edges_for_call_stmt(gimple*, tree_node*, gimple*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100993
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-23
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #4 from Andrew Pinski ---
Note a better testcase now is:
```
int __builtin_acc_on_device(int dev) { return __builtin_acc_on_device(dev); }
```
[Bug ada/114424] gnat: Ada.Calendar.Clock crashes on 32bit architectures with 64bit time_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114424 --- Comment #4 from Matthias Klose --- are there any other files which should be used?
[Bug target/96866] ICE in print_operand_address, at config/rs6000/rs6000.c:13560
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96866
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|powerpc-*-linux-gnu |powerpc*-*-linux-gnu
Last reconfirmed||2024-03-23
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed.
Testcase just in case the source file disappears from the testsuite:
```
void f (void) { extern int x; asm volatile ("#%a0" :: "X" (&x)); }
```
[Bug target/93353] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93353 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED --- Comment #10 from Andrew Pinski --- Fixed so closing as such as GCC 10 no longer being updated. Note the aarch64 bug which was reported (incorrectly in this bug report) is a dup of PR 96357.
[Bug c++/99916] ICE Segmentation fault when erroneous structured bindings appears in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99916 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103408 Target Milestone|--- |12.0
[Bug c++/99916] ICE Segmentation fault when erroneous structured bindings appears in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99916 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Fixed by r12-5710 (PR 103408).
[Bug c++/50846] internal compiler error in finish_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50846
Andrew Pinski changed:
What|Removed |Added
Known to work|13.1.0 |
--- Comment #2 from Andrew Pinski ---
New testcase for GCC 13+:
```
struct A
{
A();
} global;
void __static_initialization_and_destruction_0( ) { }
```
[Bug target/51631] Trunk ICE for case vst1_lanes64.c with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51631 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.8.0 Resolution|--- |FIXED Known to work||5.1.0 Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Fixed by r0-118901-g058e2674514e24 for GCC 4.8.0.
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #5) > (In reply to anlauf from comment #3) > > The same text existed in F2018, so it is not new: F2018:C7103 and Note 1. > > > > Either every compiler developer team misunderstood that clause, or we > > need an interp, based on the example, to be able to convince all of them. > > > > (I know of developers who do overwrite default constructors, and it > > currently > > works "everywhere", so clarification is important.) > > > > What do you think? > > I sent an email to the J3 mailing list > > https://mailman.j3-fortran.org/pipermail/j3/2024-March/014649.html > > I included a question whether keywords can be used. See mailing list for response. gfortran's current behavior appears corrects with the possible exception that gfortran does not detect and report the violation of a numbered constraint. Perhaps, a warning should be emitted under -Wall or -Wsurprising.
[Bug c++/114446] New: Spurious "inconsistent parameter pack deduction" error when constraining template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114446
Bug ID: 114446
Summary: Spurious "inconsistent parameter pack deduction" error
when constraining template function
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugzilla at maycontaincode dot com
Target Milestone: ---
Created attachment 57790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57790&action=edit
Minimal C++ source file that reproduces the issue
I have a file "bug.cpp", a 24-line C++ source file that does not include any
headers, its full content is at the bottom of this description. Within, there
are two template functions that each take a typename, a parameter pack of types
deduced from the function arguments, and a non-type template parameter with
default value. One of them uses an enable_if construct for the nontype template
argument to constrain based on the first template argument, but in this file it
never causes SFINAE (which is correct). I try a few methods of calling these
functions, each time passing the same two template arguments and the same one
function argument.
The behavior that seems incorrect to me is that GCC apparently gives different
treatment for the template function that is constrained unless the function
argument is casted to the type it would have been implicitly converted to
anyway. The unconstrained template doesn't care that the function parameter
doesn't exactly match the explicitly-specified template parameter, it happily
performs the implicit conversion. Everything else is the same so I do not
understand what could be causing this behavior. I also tried replacing the
enable_if construct with a template using alias that doesn't constrain, and GCC
accepts that without error, so it seems like the issue only happens when using
template class partial specialization.
I am unable to reproduce the issue in MSVC 14.40.33617 or Clang 18.1.0, they
both accept "bug.cpp" without incident.
I did some searching through other bug reports, but could not find anything
that looked related, and searching the exact error message in summary-only mode
actually gave me zero results.
Output of gcc -v:
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14'
> --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
> --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
> --with-gcc-major-version-only --program-suffix=-12
> --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
> --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
> --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
> --enable-gnu-unique-object --disable-vtable-verify --enable-plugin
> --enable-default-pie --with-system-zlib --enable-libphobos-checking=release
> --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
> --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
> --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
> --enable-offload-targets=nvptx-none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr
> --enable-offload-defaulted --without-cuda-driver --enable-checking=release
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 12.2.0 (Debian 12.2.0-14)
I have also used Compiler Explorer to try "x86-64 gcc 5.1", "x86-64 gcc 13.2"
and "x86-64 gcc (trunk)", all three produce the same issue as my local GCC
version: https://gcc.godbolt.org/z/9b6faWanW
Command line that produces the issue:
> g++ -std=c++17 bug.cpp
Output of above command:
> bug.cpp: In function ‘void runtest2b()’:
> bug.cpp:22:25: error: no matching function for call to ‘test2 int*>(std::nullptr_t)’
>22 | test2(nullptr); //3
> | ^
> bug.cpp:11:6: note: candidate: ‘template enable_if_not_void::type > void test2(Args&& ...)’
>11 | void test2(Args&&...){}
> | ^
> bug.cpp:11:6: note: template argument deduction/substitution failed:
> bug.cpp:22:25: note: inconsistent parameter pack deduction with ‘int*’ and
> ‘std::nullptr_t’
>22 | test2(nullptr); //3
> | ^
Adding -save-temps to the command line generates a file "a-bug.ii" with this
content, which is identical to the "bug.cpp" file after the first several
lines, other than om
[Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114441 --- Comment #3 from Yang Wang --- (In reply to Andrew Pinski from comment #1) > This is not a GCC bug, > > You need to use -mcmodel=large if you have huge statically allocated arrays. > > The default -mcmodel=medium does not support more than 2GB size arrays > > See > https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html#index- > mcmodel_003dlarge-3 Thanks for your reply! Indeed, the compilation was successful when either the -mcmodel=medium or -mcmodel=large was enabled. However, I'm still curious why it can be compiled successfully at the -O3 optimization level when the default -mcmodel=small is enabled? As far as I know, the -O3 optimization level is the highest. root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test -w -mcmodel=medium -O0 root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test -w -mcmodel=medium -O3 root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test -w -mcmodel=medium -O1 root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test -w -mcmodel=medium -O2 root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test -w -mcmodel=medium -Os root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test -w -mcmodel=small -O0 root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test -w -mcmodel=small -O3 root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test -w -mcmodel=small -O1 /tmp/ccdtPXUH.o: In function `c()': 222.cpp:(.text+0xd): relocation truncated to fit: R_X86_64_32S against symbol `a' defined in .bss section in /tmp/ccdtPXUH.o collect2: error: ld returned 1 exit status root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test -w -mcmodel=small -O2 /tmp/ccbjzODN.o: In function `c()': 222.cpp:(.text+0x13): relocation truncated to fit: R_X86_64_32S against symbol `a' defined in .bss section in /tmp/ccbjzODN.o collect2: error: ld returned 1 exit status root@ubuntu:~/test/111# /root/software/IP-gcc/gcc-trunk/bin/g++ 222.cpp -o test -w -mcmodel=small -Os /tmp/ccUUdbLp.o: In function `c()': 222.cpp:(.text+0x7): relocation truncated to fit: R_X86_64_32S against symbol `a' defined in .bss section in /tmp/ccUUdbLp.o collect2: error: ld returned 1 exit status
