[Bug c++/111352] Inconsistent constructor behavior associated with auto lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111352 --- Comment #4 from Andrew Pinski --- also see https://en.wikipedia.org/wiki/Most_vexing_parse for more explanation on why this mistake in GCC happened.
[Bug c++/111352] Inconsistent constructor behavior associated with auto lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111352
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-09-09
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||rejects-valid
--- Comment #3 from Andrew Pinski ---
You can also use this as a workaround:
```
AA aa{Constructor([](auto& p) { p.x = 1; })};
```
Confirmed.
The problem is GCC starts parsing as a function declaration for aa that takes a
type of arrays of function pointers that has a function argument named
Constructor and then noticed the `{` and decides whoops we need to back up. But
it is too late as GCC already error'd for the auto too early on.
Basically GCC errors out on auto too soon (during the parsing) rather
afterwards ...
[Bug target/111354] [7/10/12 regression] The instructions of the DPDK demo program are different and run time increases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111354 --- Comment #2 from Andrew Pinski --- It might be the case DPDK is tuned towards xeon's rather than the i series also.
[Bug target/111354] [7/10/12 regression] The instructions of the DPDK demo program are different and run time increases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111354 --- Comment #1 from Andrew Pinski --- First off the performance is difference is die to micro-arch issues with unaligned stores of 256 bits. Also iirc rte_mov128blocks is tuned at copying blocks which are aligned at least to 32 bytes wide. But you are better asking the dpdk forum why they don't just use memcpy here.
[Bug libstdc++/111347] Memory leak loading a shared library built with --static-libsdtc++ when version script is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111347 --- Comment #3 from George Yunaev --- Indeed making a unique symbol local results in a leak.
[Bug target/111354] New: [7/10/12 regression] The instructions of the DPDK demo program are different and run time increases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111354 Bug ID: 111354 Summary: [7/10/12 regression] The instructions of the DPDK demo program are different and run time increases. Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: d_vampile at 163 dot com Target Milestone: --- Created attachment 55863 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55863=edit test case Test platform: x86_64 The test platform supports avx2 and sse4.2 Default mtune=generic Compiler Options: gcc main.c -g -o main -O2 -msse4.2 -mavx2 -fno-inline GCC 7.3.0 produces: .L3: vmovdqu (%rsi), %xmm3 subq$-128, %rdi subq$-128, %rsi vmovdqu -96(%rsi), %xmm2 vinserti128 $0x1, -112(%rsi), %ymm3, %ymm3 vmovdqu -64(%rsi), %xmm1 vinserti128 $0x1, -80(%rsi), %ymm2, %ymm2 vmovdqu -32(%rsi), %xmm0 vinserti128 $0x1, -48(%rsi), %ymm1, %ymm1 vinserti128 $0x1, -16(%rsi), %ymm0, %ymm0 vmovups %xmm3, -128(%rdi) vextracti128$0x1, %ymm3, -112(%rdi) vmovups %xmm2, -96(%rdi) vextracti128$0x1, %ymm2, -80(%rdi) vmovups %xmm1, -64(%rdi) vextracti128$0x1, %ymm1, -48(%rdi) vmovups %xmm0, -32(%rdi) vextracti128$0x1, %ymm0, -16(%rdi) cmpq%rax, %rdi jne .L3 vzeroupper Runtime with gcc7.3.0: $ time ./main_gcc7.3 2000 start to run 2000. end to run 2000. real6m30.461s user6m26.587s sys 0m0.814s GCC 10.3.0 produces: .L3: vmovdqu (%rsi), %xmm4 vmovdqu 32(%rsi), %xmm5 subq$-128, %rdi subq$-128, %rsi vmovdqu -64(%rsi), %xmm6 vmovdqu -32(%rsi), %xmm7 vinserti128 $0x1, -112(%rsi), %ymm4, %ymm3 vinserti128 $0x1, -80(%rsi), %ymm5, %ymm2 vinserti128 $0x1, -48(%rsi), %ymm6, %ymm1 vinserti128 $0x1, -16(%rsi), %ymm7, %ymm0 vmovdqu %xmm3, -128(%rdi) vextracti128$0x1, %ymm3, -112(%rdi) vextracti128$0x1, %ymm2, -80(%rdi) vmovdqu %xmm2, -96(%rdi) vextracti128$0x1, %ymm1, -48(%rdi) vextracti128$0x1, %ymm0, -16(%rdi) vmovdqu %xmm1, -64(%rdi) vmovdqu %xmm0, -32(%rdi) cmpq%rax, %rdi jne .L3 vzeroupper Runtime with gcc10.3.0: $ time ./main_gcc10.3 2000 start to run 2000. end to run 2000. real7m18.696s user7m13.912s sys 0m1.098s GCC 12.3.0 produces: .L3: vmovdqu (%rsi), %ymm2 vmovdqu 32(%rsi), %ymm1 subq$-128, %rdi subq$-128, %rsi vmovdqu -64(%rsi), %ymm0 vmovdqu -32(%rsi), %ymm3 vmovdqu %ymm2, -128(%rdi) vmovdqu %ymm3, -32(%rdi) vmovdqu %ymm1, -96(%rdi) vmovdqu %ymm0, -64(%rdi) cmpq%rax, %rdi jne .L3 vzeroupper Runtime with gcc12.3.0: $ time ./main_gcc12.3 2000 start to run 2000. end to run 2000. real10m1.303s user9m52.527s sys 0m2.253s Why does it seem that the instructions of gcc12 are simpler but run time is significantly increased in the same test environment and compilation options? What is the reason for the different instructions generated by these three versions of gcc？
[Bug go/90685] failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90685 Eric Gallager changed: What|Removed |Added Host||i?86-*-* --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > (In reply to Ian Lance Taylor from comment #1) > > What kind of system are you running on? > > > > What is the output of > > ../gcc-9.1.0/config.guess > > ? > > I just got a similar error on gcc13 on the compile farm; config.guess there > reports: > > $ ../config.guess > x86_64-pc-linux-gnu > > So, confirmed. Oops wait make that gcc14, not gcc13 (since there isn't even any machine called gcc13 on the compile farm in the first place)
[Bug go/90685] failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90685 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-09-09 --- Comment #2 from Eric Gallager --- (In reply to Ian Lance Taylor from comment #1) > What kind of system are you running on? > > What is the output of > ../gcc-9.1.0/config.guess > ? I just got a similar error on gcc13 on the compile farm; config.guess there reports: $ ../config.guess x86_64-pc-linux-gnu So, confirmed.
[Bug libstdc++/111351] constexpr std::string objects permitted to escape constant evaluation when SSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351 --- Comment #1 from Arthur O'Dwyer --- (Author of the blog post here.) In contrast to James' view, I think the libstdc++/MSVC behavior is relatively easy to explain; I think libc++'s `if consteval` approach is baroque and confusing. [That is, _both_ behaviors are confusing to the newbie and need expert explanation, but libc++'s choice is confusing even for the experts, who have to maintain its split-brain SSO logic forever because Hyrum's Law. If you have to maintain something forever, you should at least choose to make it _simple_! As I say in the blog post, in hindsight I think libc++ screwed up here.] IMHO it is a feature, not a bug, that I can write these lines: constinit std::string s1; constinit std::vector v1; libstdc++ would be within its rights, paper-Standard-wise, to reject both of these lines; but I don't think libstdc++ _should_ reject either of them. They're both fine code as far as I'm concerned. I think libc++ is the user-hostile/broken implementation here, not libstdc++. Anyone who thinks libstdc++ ought to reject `s1` above should at least be forced to explain what libstdc++ ought to do about `v1`. From the user-programmer's POV, there's no difference between a default-initialized string and a default-initialized vector. Users don't care about these SSO details; they just want the code to work. That's what libstdc++ currently does. Good, IMO.
[Bug libstdc++/111353] New: bits/new_allocator.h: No such file or directory in freestanding C++ toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111353 Bug ID: 111353 Summary: bits/new_allocator.h: No such file or directory in freestanding C++ toolchain Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- D:/toolchains/gnu/x86_64-w64-mingw32/x86_64-elf/x86_64-elf/include/c++/14.0.0/x86_64-elf/bits/c++allocator.h:33:10: fatal error: bits/new_allocator.h: No such file or directory 33 | #include | ^~ As I reported to wg21 before, there is no way to allocate memory in constexpr context for freestanding. clang provides __builtin_operator_new and __builtin_operator_delete. Maybe gcc needs that too?
[Bug libstdc++/111347] Memory leak loading a shared library built with --static-libsdtc++ when version script is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111347 --- Comment #2 from George Yunaev --- Adding -fno-gnu-unique to the makefile for libleak.so doesn't remove the leak.
[Bug c++/111352] Inconsistent constructor behavior associated with auto lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111352 --- Comment #2 from Andrew Pinski --- 99% sure this is because we start parsing as a function declaration and then see it is not but we errored out already.
[Bug c++/111352] Inconsistent constructor behavior associated with auto lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111352 Peter Fletcher changed: What|Removed |Added CC||peter.fletcher@bandicootima ||ging.com.au --- Comment #1 from Peter Fletcher --- Created attachment 55862 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55862=edit Source file Source code
[Bug c++/111352] New: Inconsistent constructor behavior associated with auto lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111352
Bug ID: 111352
Summary: Inconsistent constructor behavior associated with auto
lambda
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: peter.fletcher at bandicootimaging dot com.au
Target Milestone: ---
Created attachment 55861
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55861=edit
Output of gcc -v -save_temps
When a constructor involving an auto lambda is called in two different
contexts, one triggers a compilation error, one does not.
g++ test_bug3.cpp -o test_bug3 -Wall -Wextra
test_bug3.cpp: In function ‘int main(int, char**)’:
test_bug3.cpp:41:27: error: ‘auto’ parameter not permitted in this context
41 | AA aa(Constructor([&](auto& p) { p.x = 1; }));
| ^~~~
Compilation exited abnormally with code 1 at Sat Sep 9 08:50:05
template struct Constructor
{
const L& lambda;
Constructor(const L& lambda) :
lambda(lambda)
{
}
template operator T () const
{
T out;
lambda(out);
return out;
}
};
struct A
{
int x;
};
struct AA
{
int x{0};
AA()
{
}
AA(A op) :
x(op.x)
{
}
};
int main(int argc, char* argv[])
{
AA aa(Constructor([&](auto& p) { p.x = 1; }));
AA bb = AA(Constructor([&](auto& p) { p.x = 1; }));
return aa.x+bb.x+argc+argv[0][0];
}
[Bug libstdc++/111351] New: constexpr std::string objects permitted to escape constant evaluation when SSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351 Bug ID: 111351 Summary: constexpr std::string objects permitted to escape constant evaluation when SSO Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: foom at fuhm dot net Target Milestone: --- In C++20, libstdc++ currently allows an std::string instance to escape from constant evaluation to runtime, as long as the string fit within the SSO length. E.g., as a global variable, compiled with -std=c++20: constexpr std::string s1; // OK constexpr std::string s1 = ""; // OK constexpr std::string s1 = "0123456789abcde"; // OK constexpr std::string s2 = "0123456789abcdef"; // FAIL I believe all of the above ought to fail to compile. This will result in user code which can be built or not based on whether their string happens to fit within the SSO string length. I find that quite unfortunate, since it is supposed to be an internal implementation detail/optimization, and this makes it effectively part of the API that code will grow to depend on. As comparison, libc++ rejects all the above examples, by forcing the SSO-size to zero in constant evaluation context, so that a pointer to an external allocation is always used. This was brought to my attention from https://quuxplusone.github.io/blog/2023/09/08/constexpr-string-firewall/
[Bug tree-optimization/109878] missed simplifications of MAX and MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109878 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-08 --- Comment #1 from Andrew Pinski --- Mine.
[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350 --- Comment #5 from Iain Sandoe --- (In reply to Iain Sandoe from comment #4) > (In reply to Francois-Xavier Coudert from comment #3) > > Clang: 14.0.0 build 1400 > > CLT: 14.2.0.0.1.1668646533 > > ah, it seems the vfcmulcph insn, at least, is not supported before XC14, and > it gives the error at 14.0b3 and 14.3. It seems fixed at XC 15b7. perhaps we can add something to the "avx512fp16" target test that requires assembly of one of those insns so that the tests will be automatically unsupported for broken assemblers.
[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350 --- Comment #4 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #3) > Clang: 14.0.0 build 1400 > CLT: 14.2.0.0.1.1668646533 ah, it seems the vfcmulcph insn, at least, is not supported before XC14, and it gives the error at 14.0b3 and 14.3. It seems fixed at XC 15b7.
[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350 --- Comment #3 from Francois-Xavier Coudert --- Clang: 14.0.0 build 1400 CLT: 14.2.0.0.1.1668646533
[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350 --- Comment #2 from Iain Sandoe --- (In reply to Andrew Pinski from comment #1) > This seems like a bug in darwin's assembler as all of those registers are > distinct ... indeed, it does look that way - what version of Xcode?
[Bug target/111350] gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350 --- Comment #1 from Andrew Pinski --- This seems like a bug in darwin's assembler as all of those registers are distinct ...
[Bug target/111350] New: gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends fail on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111350
Bug ID: 111350
Summary: gcc.target/i386/avx512fp16-vfcmulcph-1b.c and friends
fail on x86_64-apple-darwin21
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
We're seeing these failures on x86_64-apple-darwin21:
FAIL: gcc.target/i386/avx512fp16-vfcmulcph-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16-vfcmulcsh-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16-vfmulcph-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16-vfmulcsh-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16vl-vfcmulcph-1b.c (test for excess errors)
FAIL: gcc.target/i386/avx512fp16vl-vfmulcph-1b.c (test for excess errors)
The errors are all similar-looking:
FAIL: gcc.target/i386/avx512fp16-vfmulcsh-1b.c (test for excess errors)
Excess errors:
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//cclz0cVD.s:379:2: warning:
Destination register should be distinct from source registers
vfmulcsh{rn-sae}, %xmm1, %xmm3, %xmm0{%k1}
^
FAIL: gcc.target/i386/avx512fp16-vfcmulcph-1b.c (test for excess errors)
Excess errors:
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//ccB0dfAf.s:475:2: warning:
Destination register should be distinct from source registers
vfcmulcph _src2(%rip), %zmm2, %zmm0{%k1}
^
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//ccB0dfAf.s:540:2: warning:
Destination register should be distinct from source registers
vfcmulcph {rn-sae}, %zmm7, %zmm6, %zmm0{%k1}
^
I tried to reduce one, and got:
$ cat avx512fp16vl-vfcmulcph-1b.i
typedef _Float16 __m256h __attribute__ ((__vector_size__ (32), __may_alias__));
typedef _Float16 __v16hf __attribute__ ((__vector_size__ (32)));
typedef union {
__m256h ymmh[2];
unsigned short u16[32];
} V512;
V512 src1, src2;
int n_errs = 0;
extern __inline __m256h __attribute__ ((__gnu_inline__, __always_inline__,
__artificial__))
_mm256_mask_fcmul_pch (__m256h __A, unsigned char __B, __m256h __C, __m256h
__D)
{ return (__m256h) __builtin_ia32_vfcmulcph256_mask ((__v16hf) __C, (__v16hf)
__D, (__v16hf) __A, __B); }
void check_results(void *got, void *exp, int n_elems, char *banner) {
int i;
V512 *v1 = (V512*)got;
V512 *v2 = (V512*)exp;
for (i = 0; i < n_elems; i++) {
if (v1->u16[i] != v2->u16[i] &&
((v1->u16[i] > (v2->u16[i] + 1)) ||
(v1->u16[i] < (v2->u16[i] - 1 {
n_errs++;
break;
}
}
}
int main () {
V512 res;
V512 exp;
res.ymmh[0] = _mm256_mask_fcmul_pch (res.ymmh[0], 0xcc, src1.ymmh[0],
src2.ymmh[0]);
check_results ((void*), (void*), (256 / 16),
"_mm256_mask_fcmul_pch");
}
which yields the warning:
$ /Users/fx/ibin/gcc/xgcc -B/Users/fx/ibin/gcc/ avx512fp16vl-vfcmulcph-1b.i -O2
-mavx512fp16 -mavx512vl -mavx512dq -c
/var/folders/_8/7ft0tbns6_l87s21n4s_1sc8gn/T//ccruiM7F.s:57:2: warning:
Destination register should be distinct from source registers
vfcmulcph _src2(%rip), %ymm1, %ymm0{%k1}
^
[Bug tree-optimization/111349] `Optimize (a CMP CST1) ? max : a` pattern's cmp is missing :c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111349 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-09-08 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug tree-optimization/111349] New: `Optimize (a CMP CST1) ? max : a` pattern's cmp is missing :c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111349 Bug ID: 111349 Summary: `Optimize (a CMP CST1) ? max : a` pattern's cmp is missing :c Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization Assignee: pinskia at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- ``` /* Optimize (a CMP CST1) ? max : a */ (for cmp(gt ge lt le) minmax (min min max max) (simplify (cond (cmp @0 @1) (minmax:c@2 @0 @3) @4) ``` Just like PR 111348 really.
[Bug tree-optimization/111348] `(a CMP b) ? minmax : minmax` pattern missing :c on CMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111348 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-08
[Bug libstdc++/111347] Memory leak loading a shared library built with --static-libsdtc++ when version script is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111347 --- Comment #1 from Andrew Pinski --- I am pretty sure _ZNSt8messagesIwE2idE is marked as GNU unique
[Bug tree-optimization/111348] `(a CMP b) ? minmax : minmax` pattern missing :c on CMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111348 --- Comment #1 from Andrew Pinski --- Need a testcase for this though.
[Bug tree-optimization/111348] New: `(a CMP b) ? minmax : minmax` pattern missing :c on CMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111348 Bug ID: 111348 Summary: `(a CMP b) ? minmax : minmax` pattern missing :c on CMP Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: internal-improvement, missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization Assignee: pinskia at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- ``` (for minmax (min max) (for cmp (lt le gt ge ne) (simplify (cond (cmp @1 @3) (minmax:c @1 @4) (minmax:c @2 @4)) ``` Is missing :c on cmp because we could have (@3 < @1) ? min(@1, @4) : min(@2, @4) Which should match for and provide the same as `@1 > @3 ? min(@1, @4) : min(@2, @4)`
[Bug libstdc++/111347] New: Memory leak loading a shared library built with --static-libsdtc++ when version script is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111347
Bug ID: 111347
Summary: Memory leak loading a shared library built with
--static-libsdtc++ when version script is used
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gyunaev at ulduzsoft dot com
Target Milestone: ---
Created attachment 55860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55860=edit
The source code of the library, tester and Makefile
Gcc 13.2 built from the source. Linux x86_64, OpenSuSe Leap 15.5.
Our team has found that when building a C++ DSO using --static-libgcc and
--static-libstdc++ and using a version script to hide the visibility of
symbols, loading and unloading the resulting shared library leaks memory each
time such dlopen/dlclose happens.
If a version script is not used, there is no leak.
Smallest shared library source which reproduces the issue:
-- libtest.cpp --
#include
int test()
{
std::string a;
return a.length();
}
---
The version script:
-- libtest.ver --
{
global:
test;
local:
*;
};
---
Built with:
g++ -fPIC -shared -static-libgcc -static-libstdc++
-Wl,--version-script=libtest.ver libtest.cpp -o libtest.so
load-unload of this library leaks memory each time it unloads.
Loading-unloading is all that is needed - you don't need to call test or even
dlsym it. Easiest to see it when running dlclose( dlopen( "./libtest.so",
RTLD_NOW)) in a loop.
If you remove --version-script and rebuild the library, load-unload will not
leak.
Experimentally we found out that adding the symbol "_ZNSt8messagesIwE2idE;"
into global: section of version script would stop the leak, but this isn't
obvious to me why. This symbol demangles into std::messages::id;
Attaching the tester, makefile and the loader.
[Bug tree-optimization/111346] `X <= MINMAX` pattern is missing :c on the cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111346 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-08 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Have to find a testcase or 2 that fails because of the missing :c though.
[Bug tree-optimization/111346] New: `X <= MINMAX` pattern is missing :c on the cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111346
Bug ID: 111346
Summary: `X <= MINMAX` pattern is missing :c on the cmp
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: internal-improvement, missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
The pattern:
```
/* X <= MAX(X, Y) -> true
X > MAX(X, Y) -> false
X >= MIN(X, Y) -> true
X < MIN(X, Y) -> false */
(for minmax (min min max max )
cmp(ge lt le gt )
(simplify
(cmp @0 (minmax:c @0 @1))
{ constant_boolean_node (cmp == GE_EXPR || cmp == LE_EXPR, type); } ))
```
Is missing :c on the cmp which causes us to miss:
MAX(X, Y) >= X -> true
etc.
[Bug tree-optimization/111345] `X % Y is smaller than Y.` pattern could be simpified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111345 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-08
[Bug tree-optimization/111345] New: `X % Y is smaller than Y.` pattern could be simpified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111345
Bug ID: 111345
Summary: `X % Y is smaller than Y.` pattern could be simpified
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: internal-improvement
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Right now it is defined as:
```
(for cmp (lt ge)
(simplify
(cmp (trunc_mod @0 @1) @1)
(if (TYPE_UNSIGNED (TREE_TYPE (@0)))
{ constant_boolean_node (cmp == LT_EXPR, type); })))
(for cmp (gt le)
(simplify
(cmp @1 (trunc_mod @0 @1))
(if (TYPE_UNSIGNED (TREE_TYPE (@0)))
{ constant_boolean_node (cmp == GT_EXPR, type); })))
```
But it could be simplified to:
```
(for cmp (lt ge)
(simplify
(cmp:c (trunc_mod @0 @1) @1)
(if (TYPE_UNSIGNED (TREE_TYPE (@0)))
{ constant_boolean_node (cmp == LT_EXPR, type); })))
```
This simplifies the written code but the produced code is the same ...
[Bug c/29280] misleading warning for assignment used as truth construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29280 Andrew Pinski changed: What|Removed |Added CC||markgaleck at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 111344 has been marked as a duplicate of this bug. ***
[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111344
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #7 from Andrew Pinski ---
Dup of bug 29280.
The warning needs some fine tuning on the wording but the parentheses is not
there. The syntax for, while and if requires parentheses for the truth value.
That is it is not:
```
if a = b
{
}
```
But:
```
if (a = b)
{
}
```
the assignment in this case is used where a truth value would be used, there is
no parentheses around the assignment.
*** This bug has been marked as a duplicate of bug 29280 ***
[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111344
--- Comment #6 from Mark Galeck ---
(In reply to Andrew Pinski from comment #5)
> Reduced:
> ```
> int *f(const char*);
> int *g(int*);
> int main()
> {
> int* pdir;
> int* pentry;
>
> pdir = f("d");
>
> while (pentry = g(pdir)) ;
> }
> ```
>
> No this warning is not bogus and is telling you exactly what it says.
Andrew I respect your opinion and certainly you are more experienced at gcc
than me. But, with all due respect, I disagree with "is telling you exactly
what it says"
No it doesn't... it says "suggest parentheses around " and the parentheses is
there.
Maybe it should say something like "suggest double parentheses, to confirm that
you meant = and not == , although, I fail to see how double parent should
confirm such a thing.
[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111344
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Andrew Pinski ---
Reduced:
```
int *f(const char*);
int *g(int*);
int main()
{
int* pdir;
int* pentry;
pdir = f("d");
while (pentry = g(pdir)) ;
}
```
No this warning is not bogus and is telling you exactly what it says.
The reason for the warning is because GCC is telling the user that sometimes
they might have meant for == rather than = here.
If you add an extra parentheses around `pentry = g(pdir)`, then the warning
goes away because you are explictly saying you meant that assignment rather
than an equality comparison.
[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111344 --- Comment #4 from Mark Galeck --- I am getting seemingly bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]". I see long time ago there were such reports, fixed at the time, but this is happening now for me with gcc 13.1.0 The preprocessed file foobar.i is attached. The warning is triggered by: $gcc-13 -Wall -lc -c foobar.i foobar.c: In function ‘main’: foobar.c:11:16: warning: suggest parentheses around assignment used as truth value [-Wparentheses] 11 | while (pentry = readdir(pdir)) ; |^~ If I add ANOTHER parentheses as the warning seems to suggest: while ((pentry = readdir(pdir))) the warning disappears. foobar.i is attached $ gcc-13 -v Using built-in specs. COLLECT_GCC=gcc-13 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/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='Ubuntu 13.1.0-8ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --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-13-IvzKaI/gcc-13-13.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-IvzKaI/gcc-13-13.1.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 --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.1.0 (Ubuntu 13.1.0-8ubuntu1~22.04)
[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111344 --- Comment #3 from Mark Galeck --- Created attachment 55859 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55859=edit preprocessed SSCCE foobar.i
[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111344 --- Comment #2 from Mark Galeck --- Created attachment 55858 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55858=edit preprocessed SSCCE foobar.i
[Bug target/111343] [SH] Including in C++23 causes an ICE with -m4-single-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111343 --- Comment #1 from Andrew Pinski --- Most likely introduced by r13-2887-gb04208895fed34171eac6 which implements C++23 extended floating point types ... And the use of _Float32 but now sizeof(double) == sizeof(float) == sizeof(_Float32)
[Bug c/111344] bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111344 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2023-09-08 --- Comment #1 from Andrew Pinski --- Can you provide a testcase?
[Bug c/111344] New: bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111344 Bug ID: 111344 Summary: bogus "warning: suggest parentheses around assignment used as truth value [-Wparentheses]" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: markgaleck at gmail dot com Target Milestone: ---
[Bug c++/111343] New: [SH] Including in C++23 causes an ICE with -m4-single-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111343
Bug ID: 111343
Summary: [SH] Including in C++23 causes an ICE with
-m4-single-only
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gyrovorbis at gmail dot com
Target Milestone: ---
We recently updated from GCC12 to GCC13 in the Sega Dreamcast indie SDK,
KallistiOS, and while pretty much everything has worked fantastically, we are
encountering a pretty serious ICE when attempting to include the header
with the -m4-single-only SH-specific flag (which treats doubles as floats),
when compiling as C++23.
The minimal program to reproduce the issue is here:
#include
int main(int argc, char* argv[]) {
return 0;
}
We are building with: -std=c++23 -m4-single-only
Note that without the -m4-single-only flag, the ICE disappears. Note also that
without including , with this flag, the following static assertion
fails:
static_assert(sizeof(__STDCPP_FLOAT64_T__) == 8,
"Oh god, Dreamcast broke!");
Here is a link to a repro in Compiler Explorer: https://godbolt.org/z/MrE8a47oq
I'm assuming the addition of the new C++23 types is clashing with
the `-m4-single-only` flag, as it doesn't seem as though when these types are
created, there is any checking for sizeof(double) or anything target-specific:
https://github.com/gcc-mirror/gcc/blob/a7d052b3200c7928d903a0242b8cfd75d131e374/gcc/c-family/c-cppbuiltin.cc#L1265
[Bug c++/111075] ICE on g++.dg/torture/tail-padding1.C on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111075
--- Comment #1 from Francois-Xavier Coudert ---
Preprocessed source:
% cat a-tail-padding1.ii
# 0 "/Users/fx/gcc-upstream/gcc/testsuite/g++.dg/torture/tail-padding1.C"
# 0 ""
# 0 ""
# 1 "/Users/fx/gcc-upstream/gcc/testsuite/g++.dg/torture/tail-padding1.C"
struct X { ~X() {} int n; char d; };
struct Y { Y(); char c[3]; };
struct Z : X, virtual Y { Z(); };
X f() { X nrvo; __builtin_memset(, 0, sizeof(X)); return nrvo; }
Z::Z() : Y(), X(f()) {}
Y::Y() { c[0] = 1; }
int main() {
Z z;
if (z.c[0] != 1)
__builtin_abort ();
}
Backtrace of the ICE:
* frame #0: 0x000101b76378 cc1plus`internal_error(char const*, ...)
[inlined] auto_diagnostic_group::auto_diagnostic_group(this=) at
diagnostic.cc:2320:14
frame #1: 0x000101b76378 cc1plus`internal_error(gmsgid="in %s, at
%s:%d")
frame #2: 0x000101f92296
cc1plus`fancy_abort(file="/Users/fx/gcc-upstream/gcc/cp/constexpr.cc",
line=2918, function="cxx_eval_call_expression") at diagnostic.cc:2311:18
frame #3: 0x000101c8254e
cc1plus`::__second_sect_of_cxx_eval_call_expression() at constexpr.cc:2918:3
frame #4: 0x000100054f3b
cc1plus`::cxx_eval_constant_expression(ctx=0x7ff7bfefe500, t=,
lval=vc_prvalue, non_constant_p=0x7ff7bfefe4ee,
overflow_p=0x7ff7bfefe4ef, jump_target=0x) at
constexpr.cc:7257:36
frame #5: 0x000100060156
cc1plus`::cxx_eval_outermost_constant_expr(t=0x0001045b9880,
allow_non_constant=true, strict=, manifestly_const_eval=mce_false,
constexpr_dtor=false, object=0x) at constexpr.cc:8500:36
frame #6: 0x00010006601c cc1plus`maybe_constant_value(t=,
decl=0x, manifestly_const_eval=mce_false) at
constexpr.cc:8788:45
frame #7: 0x000100091cf1 cc1plus`::cp_fold(x=,
flags=) at cp-gimplify.cc:3052:31
frame #8: 0x000100091f46 cc1plus`::cp_fold_r(stmt_p=0x0001045a3ca0,
walk_subtrees=0x7ff7bfefe8dc, data_=0x7ff7bfefe9a0) at
cp-gimplify.cc:1077:28
frame #9: 0x000101952268 cc1plus`walk_tree_1(tp=,
func=, data=0x7ff7bfefe9a0, pset=,
lh=(cc1plus`cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*) at tree.cc:5453:1))(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*)) at
tree.cc:11398:25
frame #10: 0x000101952f0a cc1plus`walk_tree_1(tp=,
func=, data=0x7ff7bfefe9a0, pset=,
lh=(cc1plus`cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**,
int*, void*), void*, hash_set >*) at tree.cc:5453:1))(tree_node**, int*,
void*), void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*)) at
tree.cc:11514:4
frame #11: 0x000100087c18
cc1plus`cp_fold_function(fndecl=0x0001045be000) at cp-gimplify.cc:1199:3
frame #12: 0x0001000dc0b9
cc1plus`finish_function(inline_p=) at decl.cc:18345:22
frame #13: 0x0001001938bf
cc1plus`::maybe_thunk_body(fn=0x0001045b4e00, force=) at
optimize.cc:445:26
frame #14: 0x00010019443a
cc1plus`maybe_clone_body(fn=0x0001045b4e00) at optimize.cc:557:38
frame #15: 0x000100278978
cc1plus`expand_or_defer_fn_1(fn=0x0001045b4e00) at semantics.cc:4901:24
frame #16: 0x000100278c5e
cc1plus`expand_or_defer_fn(fn=0x0001045b4e00) at semantics.cc:4932:28
frame #17: 0x00010013c6d8
cc1plus`synthesize_method(fndecl=) at method.cc:1842:24
frame #18: 0x0001000ee7c2 cc1plus`mark_used(decl=0x0001045be000,
complain=) at decl2.cc:5855:25
frame #19: 0x00010002016b cc1plus`::build_over_call(cand=,
flags=, complain=3) at call.cc:10403:21
frame #20: 0x00010001d900
cc1plus`build_new_method_call(instance=0x0001044305d0,
fns=0x000104591f20, args=, conversion_path=,
flags=1, fn_p=0x, complain=3) at call.cc:11710:31
frame #21: 0x00010001eac0
cc1plus`build_special_member_call(instance=,
name=0x000104422100, args=0x7ff7bfeff110, binfo=, flags=1,
complain=3) at call.cc:11190:31
frame #22: 0x00010010fc1d cc1plus`::expand_aggr_init_1(tree, tree,
tree, tree, int, tsubst_flags_t) at init.cc:2203:40
frame #23: 0x00010010fb34
cc1plus`::expand_aggr_init_1(binfo=0x0001045b02a0,
true_exp=0x, exp=0x0001044305d0, init=,
flags=1, complain=3)
frame #24: 0x000100117964
cc1plus`emit_mem_initializers(mem_inits=) at init.cc:1562:23
frame #25: 0x0001001ebec0
cc1plus`::cp_parser_ctor_initializer_opt_and_function_body(parser=0x0001045ac150,
in_function_try_block=false) at parser.cc:17188:29
frame #26: 0x0001001ed6e0
cc1plus`::cp_parser_function_definition_after_declarator(parser=0x0001045ac150,
inline_p=false) at parser.cc:32243:7
frame #27: 0x0001001eecbe
[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111330 --- Comment #4 from Jakub Jelinek --- Seems sed -i -e 's/ -fcase / -fcase -Wno-all /' libgm2/*/Makefile.am sed -i -e 's/ -fcase / -fcase -Wno-all /' libgm2/*/Makefile.in can work as a work-around for this bug, but it would still be nice to understand what's going on and get it fixed.
[Bug c++/106310] [12/13 Regression] lookup after this-> seems wrong for dependent lookup since r12-6754-g30f2c22def739211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106310 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #15 from Marek Polacek --- I tried to backport the patch to gcc11 but cp_parser_lookup_name has changed too much.
[Bug target/111342] New: ICE for g++.target/i386/pr105980.C on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111342
Bug ID: 111342
Summary: ICE for g++.target/i386/pr105980.C on
x86_64-apple-darwin21
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
There is an ICE for g++.target/i386/pr105980.C on x86_64-apple-darwin21. It is
linked to the -mforce-indirect-call option passed by the testcase: without that
option, the test can compile fine.
$ cat pr105980.ii
# 0 "/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C"
# 0 ""
# 0 ""
# 1 "/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C"
struct A {
virtual ~A();
};
struct B : virtual A {};
void bar() { B(); }
$ /Users/fx/ibin/gcc/testsuite/g++/../../cc1plus -fpreprocessed pr105980.ii
-fPIC -quiet -mforce-indirect-call -std=gnu++20
/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C: In member
function ‘virtual void B::_ZTv0_n24_N1BD1Ev()’:
/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C:8:19: error:
unrecognizable insn:
8 | void bar() { B(); }
| ^
(call_insn/j 4 3 5 (call (mem:QI (symbol_ref/i:DI ("_ZN1BD1Ev") [flags 0x8001]
) [0 S1 A8])
(const_int 0 [0]))
"/Users/fx/gcc-upstream/gcc/testsuite/g++.target/i386/pr105980.C":7:8 -1
(nil)
(nil))
The backtrace, obtained under lldb, is:
* frame #0: 0x000101b76378 cc1plus`internal_error(char const*, ...)
[inlined] auto_diagnostic_group::auto_diagnostic_group(this=) at
diagnostic.cc:2320:14
frame #1: 0x000101b76378 cc1plus`internal_error(gmsgid="in %s, at
%s:%d")
frame #2: 0x000101f92296
cc1plus`fancy_abort(file="/Users/fx/gcc-upstream/gcc/config/i386/i386.md",
line=22310, function="insn_default_length") at diagnostic.cc:2311:18
frame #3: 0x000101ebe875 cc1plus`_fatal_insn(msgid=,
insn=0x0001046cfd80, file="/Users/fx/gcc-upstream/gcc/config/i386/i386.md",
line=22310, function="insn_default_length") at rtl-error.cc:108:15
frame #4: 0x000101ebe893
cc1plus`_fatal_insn_not_found(insn=, file=,
line=, function=) at rtl-error.cc:116:17
frame #5: 0x000101dd06fb cc1plus`insn_default_length(rtx_insn*) at
i386.md:22310:9
frame #6: 0x00010101883d cc1plus`shorten_branches(first=)
at final.cc:1088:35
frame #7: 0x0001019f32bc
cc1plus`::x86_output_mi_thunk(file=0x7ff84841be00,
thunk_fndecl=0x0001046b5300, delta=,
vcall_offset=, function=) at i386.cc:22087:20
frame #8: 0x000100ead83a cc1plus`expand_thunk(node=0x0001046cb000,
output_asm_thunks=, force_gimple_thunk=) at
symtab-thunks.cc:388:39
frame #9: 0x000100ebf673
cc1plus`cgraph_node::assemble_thunks_and_aliases(this=0x00010451bdd0) at
cgraphunit.cc:1763:15
frame #10: 0x000100ebf9a4 cc1plus`cgraph_node::expand() at
cgraphunit.cc:1914:31
frame #11: 0x000100ebf7b0
cc1plus`cgraph_node::expand(this=0x00010451bdd0)
frame #12: 0x000100ec10c0
cc1plus`symbol_table::compile(this=0x000104506000) at cgraphunit.cc:2191:19
frame #13: 0x000100ec4656
cc1plus`symbol_table::finalize_compilation_unit() [inlined]
symbol_table::compile(this=0x000104506000) at cgraphunit.cc:2311:3
frame #14: 0x000100ec4645
cc1plus`symbol_table::finalize_compilation_unit(this=0x000104506000)
frame #15: 0x0001015b5efe cc1plus`::compile_file() at toplev.cc:471:41
frame #16: 0x000101f96942 cc1plus`toplev::main(this=0x7ff7bfeff8fe,
argc=, argv=) at toplev.cc:2126:24
frame #17: 0x000101f9712e cc1plus`main(argc=8, argv=0x7ff7bfeffa48)
at main.cc:39:23
[Bug c++/105512] compilation with -fmodules-ts and std=c++20 leads to segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105512 Gerrit Albrecht changed: What|Removed |Added CC||m...@gerrit-albrecht.de --- Comment #2 from Gerrit Albrecht --- Hi. I can confirm both reports. Tried it with "g++.exe (Rev2, Built by MSYS2 project) 13.2.0" MinGW64 compiler; both -std=c++23 and -std=c++20 segfault together with -fmodules-ts. It works without -std option and with D_GLIBCXX_USE_CXX11_ABI=0. Thanks.
[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111330 --- Comment #3 from Jakub Jelinek --- So, narrowed it down to Fedora build doing essentially (stripped down from all languages etc.): CC=gcc \ CXX=g++ \ CFLAGS='-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' \ CXXFLAGS=' -O2 -g -grecord-gcc-switches -Wformat -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection ' \ XCFLAGS='-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' \ TCFLAGS='-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' \ ../configure --disable-bootstrap --enable-languages=c,c++,m2,lto --enable-checking=release --enable-multilib --disable-libsanitizer --with-gcc-major-version-only --enable-plugin --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux make -j32 'BOOT_CFLAGS=-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' LDFLAGS_FOR_TARGET=-Wl,-z,relro,-z,now And what matters is using -Wall during the build in *FLAGS. /builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/./gcc/gm2 -B/builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/./gcc/ -c -O2 -Wall -fm2-pathname=m2iso -I. -Ilibm2iso -I/builddir/build/BUILD/gcc-13.2.1-20230728/gcc/m2/gm2-libs-iso -fm2-pathname=m2pim -I/builddir/build/BUILD/gcc-13.2.1-20230728/gcc/m2/gm2-libs -fiso -fextended-opaque -fm2-g -g -Wreturn-type -fcase -fm2-prefix=m2iso ../../../../libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/SeqFile.mod -fPIC -DPIC -o .libs/SeqFile.o; echo $? ../../gcc/m2/gm2-compiler/M2SymInit.def:1:case statement has no matching selection 1 while /builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/./gcc/gm2 -B/builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/./gcc/ -c -O2 -fm2-pathname=m2iso -I. -Ilibm2iso -I/builddir/build/BUILD/gcc-13.2.1-20230728/gcc/m2/gm2-libs-iso -fm2-pathname=m2pim -I/builddir/build/BUILD/gcc-13.2.1-20230728/gcc/m2/gm2-libs -fiso -fextended-opaque -fm2-g -g -Wreturn-type -fcase -fm2-prefix=m2iso ../../../../libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/SeqFile.mod -fPIC -DPIC -o .libs/SeqFile.o; echo $? 0 Shouldn't -Wall affect just warnings (without -Werror) and not whether compilation succeeds or fails?
[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111330 --- Comment #2 from Jakub Jelinek --- Though, bisection points to r13-7651-g824a37d0bfa9f5c232 as first commit which fails to build.
[Bug fortran/111339] bounds-check does not detect nonconforming functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111339 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-09-08 --- Comment #1 from anlauf at gcc dot gnu.org --- The use of the intrinsic TRANSFER produces the equivalent of a function but with non-constant size, derived from pr34740, also not detected: program p real, allocatable :: ivec(:) real :: jvec(3) = [1,2,3] ivec= [1.,2.] ivec(:) = transfer (jvec, [1.]) end Detected by NAG, but not by Intel.
[Bug fortran/111341] New: Elemental operator on zero-sized array seg-faults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111341
Bug ID: 111341
Summary: Elemental operator on zero-sized array seg-faults
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: everythingfunctional at protonmail dot com
Target Milestone: ---
There were some scenarios in the real code for this that it doesn't segfault,
but the following reproducer was able to do it reliably for me.
fpm.toml
name = "empty_elemental"
version = "0.1.0"
license = "license"
author = "Brad Richardson"
maintainer = "everythingfunctio...@protonmail.com"
copyright = "Copyright 2023, Brad Richardson"
[dependencies]
strff = { git = "https://gitlab.com/everythingfunctional/strff.git;, tag =
"v4.0.0" }
iso_varying_string = { git =
"https://gitlab.com/everythingfunctional/iso_varying_string.git;, tag =
"v3.0.3" }
app/main.f90
program main
use iso_varying_string, only: varying_string, operator(//), put_line
use strff, only: join
implicit none
call put_line(join("'" // empty() // "'", ","))
contains
pure function empty()
type(varying_string), allocatable :: empty(:)
allocate(empty(0))
end function
end program main
For context, varying_string just has an allocatable deferred length character
component, operator(//) is elemental, join concatenates an array of strings
with the given separator between each, and put_line is basically just print for
varying_string. So the above program should just print a single, zero length
character.
[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111330 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |13.3
[Bug modula2/111330] [13 Regression] Bootstrap failure building SeqFile.lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111330 --- Comment #1 from Jakub Jelinek --- So far bisected to between r13-7647 (builds fine) and r13-7660 (fails to build), and can reproduce even without bootstrap. I suspect r13-7650 but will confirm it or not soon.
[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111336 --- Comment #5 from Andrew Pinski --- (In reply to Xi Ruoyao from comment #4) > (In reply to Andrew Pinski from comment #3) > > Note -fwrapv or -fno-ivopts causes the issue to disappear. > > Does your patch for PR111331 work for this one too? No because it is unrelated, there was no min or max in the IR either.
[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111336 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104167 --- Comment #14 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:294d11837367455499786578377c530a0238b6ca commit r13-7782-g294d11837367455499786578377c530a0238b6ca Author: Jonathan Wakely Date: Thu Aug 31 18:31:32 2023 +0100 libstdc++: Avoid useless dependency on read_symlink from tzdb chrono::tzdb::current_zone uses filesystem::read_symlink, which creates a dependency on the fs_ops.o object in libstdc++.a, which then creates dependencies on several OS functions if --gc-sections isn't used. For more details see PR libstdc++/104167 comment 8 and comment 11. In the cases where that causes linker failures, we probably don't have readlink anyway, so the filesystem::read_symlink call will always fail. Repeat the preprocessor conditions for filesystem::read_symlink in the body of chrono::tzdb::current_zone so that we don't create a dependency on fs_ops.o for a function that will always fail. libstdc++-v3/ChangeLog: * src/c++20/tzdb.cc (tzdb::current_zone): Check configure macros for POSIX readlink before using filesystem::read_symlink. (cherry picked from commit f2eb6132c6951edf7960a82828c571a1b98a1a09)
[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111336 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #4 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #3) > Note -fwrapv or -fno-ivopts causes the issue to disappear. Does your patch for PR111331 work for this one too?
[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111336 --- Comment #3 from Andrew Pinski --- Note -fwrapv or -fno-ivopts causes the issue to disappear.
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 --- Comment #7 from TC --- Confirmed with my reporter that this fixes their actual code too.
[Bug c++/99599] [11/12/13/14 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 --- Comment #18 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2154bcd6d43cfd821ca70e1583880c4ed955355d commit r14-3809-g2154bcd6d43cfd821ca70e1583880c4ed955355d Author: Patrick Palka Date: Fri Sep 8 12:02:20 2023 -0400 c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599] As described in detail in the PR, the CWG 2369 resolution has the surprising consequence of introducing constraint recursion in seemingly valid and innocent code. This patch attempts to fix this surpising behavior for the majority of problematic cases. Rather than checking satisfaction before _all_ non-dependent conversions, as specified by the CWG resolution, this patch makes us first check "safe" non-dependent conversions, then satisfaction, then followed by other non-dependent conversions. A conversion is considered "safe" if computing it is guaranteed to not induce template instantiation, and we conservatively determine this by checking for user-declared constructors (resp. conversion functions) in the parm (resp. arg) class type, roughly. PR c++/99599 gcc/cp/ChangeLog: * pt.cc (check_non_deducible_conversions): Add bool parameter passed down to check_non_deducible_conversion. (fn_type_unification): Call check_non_deducible_conversions an extra time before satisfaction with noninst_only_p=true. (conversion_may_instantiate_p): Define. (check_non_deducible_conversion): Add bool parameter controlling whether to compute only conversions that are guaranteed to not induce template instantiation. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-recursive-sat4.C: Make 'Int' non-aggregate in order to preserve intent of the testcase. * g++.dg/cpp2a/concepts-nondep4.C: New test.
[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin or fails on x86_64-linux-gnu with -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340 Jakub Jelinek changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Of course, what exactly falls under the "g" constraint is target specific. Though, because that constraint also allows the constant to be reload into a register, if such constant isn't valid, then RA should have reloaded it into register or memory. Seems the failure is that i386.cc (output_pic_addr_const) doesn't have the CONST_WIDE_INT case unlike output_addr_const.
[Bug target/110960] TestSatWidenMulPairwiseAdd in the Google Highway test suite fails when compiled with GCC 12 or later with the -mcpu=power9 option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960 --- Comment #8 from Andrew Pinski --- (In reply to Mathieu Malaterre from comment #7) > @rguenth You added `needs-bisection` keyword, but the example is quite > small: 154 lines of code. needs-bisection means to figure out which commit caused the regression. That is different from needs-reduction keyword which says we need a reduction still ...
[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin or fails on x86_64-linux-gnu with -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340
--- Comment #3 from Jakub Jelinek ---
Seems to be a pre-existing problem.
void
bar (void)
{
__asm ("# %0" : : "g" unsigned __int128) 0x123456789abcdef0ULL) << 64) |
0x0fedcba987654321ULL));
}
fails the same way.
void
baz (void)
{
__asm ("# %0" : : "g" (0x0fedcba987654321ULL));
}
works with both -fpic and -fno-pic.
If it is solely about the testsuite FAIL, I can certainly add -fno-pic to
dg-options
in there.
But this is instead whether 128-bit integer constants work with "g" in
-fpic/-fpie modes (on 64-bit arches), 65..128 bit _BitInt on 32-bit arches
would expand like the 575 bit one into memory rather than CONST_WIDE_INT.
[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340 --- Comment #2 from Francois-Xavier Coudert --- Created attachment 55857 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55857=edit Output of -fdump-rtl-final
[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Target|x86_64-apple-darwin |x86_64-*-* Status|UNCONFIRMED |NEW Build|x86_64-apple-darwin | Last reconfirmed||2023-09-08 Host|x86_64-apple-darwin | --- Comment #1 from Andrew Pinski --- The testcase also fails on x86_64-linux-gnu with -fPIE too with the same error message.
[Bug c/111340] New: gcc.dg/bitint-12.c fails on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111340 Bug ID: 111340 Summary: gcc.dg/bitint-12.c fails on x86_64-apple-darwin Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- gcc.dg/bitint-12.c fails on x86_64-apple-darwin, with excess error: /Users/fx/gcc-upstream/gcc/testsuite/gcc.dg/bitint-12.c:18:3: error: invalid 'asm': invalid expression as operand I am not sure what the cause is, I don't know x86_64 assembler :(
[Bug c/111337] ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #1 from Robin Dapp --- This is gcc.dg/pr70252.c BTW. What happens is that, starting with maskdest = (vec_cond mask1 1 0) >= (vec_cond mask2 1 0) we fold to maskdest = mask1 >= (vec_cond (mask2 1 0)) and then sink the ">=" into the vec_cond so we end up with maskdest = vec_cond (mask2 ? mask1 : 0), i.e. a vec_cond with a mask "data mode". In gimple-isel, when the target does not provide a vcond_mask implementation for that (which none does) we assert that the mask mode be MODE_VECTOR_INT. IMHO this should not happen and we should not sink comparisons (that could be folded to masks) into vec_cond. I'm preparing a patch that prevents the sinking of comparisons for mask types.
[Bug middle-end/111296] RISC-V vector: ICE in lra_split_hard_reg_for during reload pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111296 Jeremy Bennett changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jeremy Bennett --- I can confirm this patch resolves the issue.
[Bug target/111295] RISC-V vector ICE in vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295 Jeremy Bennett changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Jeremy Bennett --- I can confirm this patch resolves the issue.
[Bug c/109393] Very trivial address calculation does not fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393 --- Comment #9 from Manolis Tsamis --- Created attachment 55856 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55856=edit Address calculation pattern v1
[Bug tree-optimization/111331] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111331 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/629701.html Keywords||patch --- Comment #12 from Andrew Pinski --- Trunk patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629701.html Patches for the other branches will almost the same except the match.pd part is removed since it is not there.
[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111336
Shaohua Li changed:
What|Removed |Added
CC||yinyuefengyi at gmail dot com
--- Comment #2 from Shaohua Li ---
I have another similar test case that even affects GCC-12 (bisected to
r12-6087-g51a24e4a984)
Compiler explorer: https://godbolt.org/z/d6hjfGqzj
I reported another bug111331, which also looks similar but has different
bisection point.
$ cat a.c
int printf(const char *, ...);
int a, b;
long c = 3521733542;
int d[2];
int e(int f, int g) {
if (f == 0)
return 0;
if (f > 200)
return 0;
if (g)
return 5000 * f;
return 0;
}
int main() {
int h = 0;
for (;e((int)c + 773233762, c + 773233760) + (int)c + 773228714 + h < 2; h++)
d[h] = b;
printf("%d\n", a);
}
$
[Bug middle-end/111338] [14 Regression] ice in vn_walk_cb_data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111338 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-09-08 --- Comment #5 from Jakub Jelinek --- Created attachment 55855 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55855=edit gcc14-pr111338.patch Untested fix.
[Bug middle-end/111338] [14 Regression] ice in vn_walk_cb_data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111338 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |14.0 Summary|ice in vn_walk_cb_data |[14 Regression] ice in ||vn_walk_cb_data Component|c |middle-end Version|unknown |14.0
[Bug c/111338] ice in vn_walk_cb_data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111338
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Slightly cleaned up, still -O1:
_BitInt(575) e;
int
main ()
{
__atomic_fetch_and (, 1, __ATOMIC_RELAXED);
}
(otherwise you'd want the wb suffix on the large constant to avoid warning).
Or even
_BitInt(575) e;
_BitInt(575)
foo (void)
{
return e & 1;
}
The problem is that push_partial_def uses a fixed size 512-bit buffer, for
larger stuff it fails and my PR93582 patch assumed it doesn't fail.
[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051 Sergei Trofimovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Sergei Trofimovich --- Sounds reasonable. Closing as FIXED.
[Bug c/111338] ice in vn_walk_cb_data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111338 David Binderman changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #3 from David Binderman --- Jakub seems to have implemented a lot of the _BitInt support.
[Bug c/111338] ice in vn_walk_cb_data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111338 --- Comment #2 from David Binderman --- The code first seems to go wrong sometime between g:c1597e7fb9f9ecb9 and g:10d59b802a7db9ae, which is 36 commits.
[Bug c/111338] ice in vn_walk_cb_data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111338
--- Comment #1 from David Binderman ---
Reduced code is:
_BitInt(575) e;
main() {
__atomic_fetch_and(
,
40418462630594385361724744395454079240140931656245750192534103967695265126850678980088699287669565365078793986191778469857714756111026776864987769580622009237241167211461,
__ATOMIC_RELAXED);
}
[Bug fortran/111339] New: bounds-check does not detect nonconforming functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111339 Bug ID: 111339 Summary: bounds-check does not detect nonconforming functions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org CC: anlauf at gcc dot gnu.org, dfranke at gcc dot gnu.org, gcc-bugs at gcc dot gnu.org, P.Schaffnit at access dot rwth-aachen.de, tkoenig at gcc dot gnu.org, urbanjost at comcast dot net, vivekrao4 at yahoo dot com Depends on: 31059 Blocks: 27766, 37802 Target Milestone: --- +++ This bug was initially created as a clone of Bug #31059 +++ Gfortran does not report an error if an allocatable array is set to a function of larger size, for example in the code below. program p integer, allocatable :: ivec(:) ivec = [1, 2] ! ivec(:) = func() ! case 1 (already diagnosed) ! ivec(:) = ivec + func() ! case 2 ! ivec(:) = func() + ivec ! case 3 contains function func() integer :: func(3) func = [7, 8, 9] end function func end Uncomment either case 1, case 2 or case 3, and see if the program leads to a runtime error with -fcheck=bounds. Case 1 is diagnosed, but not case 2 and neither case 3. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766 [Bug 27766] [meta-bug] -fbounds-check related bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059 [Bug 31059] bounds-check does not detect nonconforming assignment arrays https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37802 [Bug 37802] Improve wording for matmul bound checking
[Bug middle-end/111329] [14 regression] gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c fails after r14-3745-g4f4fa2501186e4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111329 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-08 Ever confirmed|0 |1 --- Comment #6 from Jakub Jelinek --- Created attachment 55854 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55854=edit gcc14-pr111329.patch So far only very lightly tested patch (tested that the test FAILs in bootstrapped build, applied patch, make -j32 in the stage3 directory, make check for the test again, which now PASSes). Had to put the out of line function into wide-int-print.cc rather than pretty-print.cc, because otherwise e.g. modula2 doesn't link.
[Bug target/110960] TestSatWidenMulPairwiseAdd in the Google Highway test suite fails when compiled with GCC 12 or later with the -mcpu=power9 option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110960 --- Comment #7 from Mathieu Malaterre --- @rguenth You added `needs-bisection` keyword, but the example is quite small: 154 lines of code.
[Bug c++/106310] [12/13 Regression] lookup after this-> seems wrong for dependent lookup since r12-6754-g30f2c22def739211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106310 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #14 from Florian Weimer --- (In reply to Martin Liška from comment #4) > Started with r12-6754-g30f2c22def739211. And this was backported as r11-9991-g8d2f59c8e26960df, so this issue currently exists on the gcc-11 branch.
[Bug target/111051] [14 Regression] highway-1.0.6 fails to build as gcc-14.0.0/lib/gcc/x86_64-unknown-linux-gnu/14.0.0/include/avxintrin.h:1238:1: error: inlining failed in call to 'always_inline' '__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111051 Mathieu Malaterre changed: What|Removed |Added CC||malat at debian dot org --- Comment #6 from Mathieu Malaterre --- looks like this one should be marked fixed.
[Bug c/111338] New: ice in vn_walk_cb_data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111338 Bug ID: 111338 Summary: ice in vn_walk_cb_data Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- >From the gcc testsuite: $ ~/gcc/results/bin/gcc -c -w ./gcc.dg/bitint-18.c $ $ ~/gcc/results/bin/gcc -c -w -O1 ./gcc.dg/bitint-18.c during GIMPLE pass: fre ./gcc.dg/bitint-18.c: In function ‘main’: ./gcc.dg/bitint-18.c:44:1: internal compiler error: in vn_walk_cb_data, at tree-ssa-sccvn.cc:1866 44 | } | ^ 0x10897ff vn_walk_cb_data::vn_walk_cb_data(vn_reference_s*, tree_node*, tree_node**, vn_lookup_kind, bool, tree_node*, bool) ../../trunk.year/gcc/tree-ssa-sccvn.cc:1866 0x10784e7 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind, vn_reference_s**, bool, tree_node**, tree_node*, bool) ../../trunk.year/gcc/tree-ssa-sccvn.cc:4017 0x10860ec visit_nary_op(tree_node*, gassign*) ../../trunk.year/gcc/tree-ssa-sccvn.cc:5427 $ ~/gcc/results/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/dcb38/gcc/results/bin/gcc COLLECT_LTO_WRAPPER=/home/dcb38/gcc/results.20230908.asan.ubsan/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../trunk.year/configure --prefix=/home/dcb38/gcc/results.20230908.asan.ubsan --disable-multilib --disable-bootstrap --with-build-config=bootstrap-asan --with-build-config=bootstrap-ubsan --with-pkgversion=daaed758517c81fc --enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20230907 (experimental) (daaed758517c81fc)
[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311 --- Comment #4 from JuzheZhong --- Update status: All C++ FAILs are fixed. There are only 38 FAILs in total: FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.vsetvl, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions compariso n FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.vsetvl, -O3 -g comparison FAIL: gcc.dg/Wstringop-overflow-70.c (test for warnings, line 22) FAIL: gcc.dg/pr104992.c scan-tree-dump-times optimized " % " 9 FAIL: gcc.dg/pr70252.c (internal compiler error: in gimple_expand_vec_cond_expr, at gimple-isel.cc:284) FAIL: gcc.dg/pr70252.c (test for excess errors) FAIL: gcc.dg/pr92301.c execution test FAIL: gcc.dg/signbit-2.c scan-tree-dump-not optimized "\\s+>>\\s+31" FAIL: gcc.dg/signbit-5.c execution test FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't roll" FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6" FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1" FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding Accumulator" FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump cunroll "optimized: loop with [0-9]+ iterations completely unrolled" FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump-not optimized "foo" FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized "BIT_FIELD_REF" 0 FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized "BIT_INSERT_EXPR" 0 FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized "BIT_FIELD_REF" 0 FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized "BIT_INSERT_EXPR" 1 FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect "vectorized 0 loops" 1 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect "vectorized 0 loops" 1 FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1 FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1 FAIL: gcc.dg/tree-ssa/loop-bound-1.c scan-tree-dump ivopts "bounded by 254" FAIL: gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump ivopts "bounded by 254" FAIL: gcc.dg/tree-ssa/predcom-2.c scan-tree-dump-times pcom "Unrolling 2 times." 2 FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Combination" 1 FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Unrolling 3 times." 1 FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Combination" 2 FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Unrolling 3 times." 1 FAIL: gcc.dg/tree-ssa/predcom-9.c scan-tree-dump pcom "Executing predictive commoning without unrolling" FAIL: gcc.dg/tree-ssa/reassoc-46.c scan-tree-dump-times optimized "(?:vect_)?sum_[\\d._]+ = (?:(?:vect_)?_[\\d._]+ \\+ (?:vect_)?sum_[\\d._]+|(?:v ect_)?sum_[\\d._]+ \\+ (?:vect_)?_[\\d._]+)" 1 FAIL: gcc.dg/tree-ssa/scev-10.c scan-tree-dump-times ivopts " Type:\\tREFERENCE ADDRESS\n" 1 FAIL: gcc.dg/tree-ssa/scev-11.c scan-tree-dump-times ivopts " Type:\\tREFERENCE ADDRESS\n" 2 FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump ivopts "Overflowness wrto loop niter:\tNo-overflow" FAIL: gcc.dg/tree-ssa/scev-9.c scan-tree-dump-times ivopts " Type:\\tREFERENCE ADDRESS\n" 1 FAIL: gcc.dg/tree-ssa/split-path-11.c scan-tree-dump-times split-paths "join point for if-convertable half-diamond" 1 FAIL: gcc.target/riscv/rvv/base/vector-abi-9.c (test for warnings, line 9) Most of them are Dump FAIL which are because of missing VLS modes patterns. Will address them soon
[Bug c/111337] New: ICE in gimple-isel.cc for RISC-V port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337
Bug ID: 111337
Summary: ICE in gimple-isel.cc for RISC-V port
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
This following case cause ICE:
extern unsigned char a [150];
extern unsigned char b [150];
extern unsigned char c [150];
extern unsigned char d [150];
extern unsigned char e [150];
void foo () {
for (int i = 92; i <= 141; i += 2) {
int tmp = (d [i] && b [i]) <= (a [i] > c [i]);
e [i] = tmp >> b [i];
}
}
auto.c:7:6: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:284
7 | void foo () {
| ^~~
0x1a9e309 gimple_expand_vec_cond_expr
../../../../gcc/gcc/gimple-isel.cc:283
0x1a9ea56 execute
../../../../gcc/gcc/gimple-isel.cc:390
Bause of this piece of code:
gcc_assert (GET_MODE_CLASS (TYPE_MODE (TREE_TYPE (op0)))
== MODE_VECTOR_INT);
The statement cause such assertion FAIL was produced by "vrp2":
Before auto.c.202t.vrp2:
mask__5.33_165 = vect__3.26_157 > vect__4.31_163;
vect_patt_67.34_168 = VEC_COND_EXPR ;
vect_patt_68.35_169 = (vector([4,4]) int) vect_patt_67.34_168;
mask__7.36_170 = vect_patt_68.35_169 >= vect_patt_66.22_152;
vect_patt_69.37_173 = VEC_COND_EXPR ;
vect_patt_70.38_174 = (vector([4,4]) unsigned char) vect_patt_69.37_173;
vect_patt_71.39_176 = MIN_EXPR ;
vect_patt_72.40_177 = vect_patt_70.38_174 >> vect_patt_71.39_176;
.MASK_LEN_SCATTER_STORE (vectp_e.42_181, { 0, 2, 4, ... }, 1,
vect_patt_72.40_177, { -1, ... }, _186, 0);
auto.c.202t.vrp2:
mask__5.33_165 = vect__3.26_157 > vect__4.31_163;
vect_patt_67.34_168 = VEC_COND_EXPR ;
vect_patt_68.35_169 = VEC_COND_EXPR ;
mask__7.36_170 = VEC_COND_EXPR ;
vect_patt_69.37_173 = VEC_COND_EXPR ;
vect_patt_70.38_174 = VEC_COND_EXPR ;
vect_patt_71.39_176 = MIN_EXPR ;
vect_patt_72.40_177 = vect_patt_70.38_174 >> vect_patt_71.39_176;
.MASK_LEN_SCATTER_STORE (vectp_e.42_181, { 0, 2, 4, ... }, 1,
vect_patt_72.40_177, { -1, ... }, _186, 0);
There is a odd STMT here:
mask__7.36_170 = VEC_COND_EXPR ;
It seems that it should be logical operations of MASK?
[Bug fortran/108957] Fortran FE memleak with interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957 Mikael Morin changed: What|Removed |Added Last reconfirmed||2023-09-08 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Mikael Morin --- (In reply to anlauf from comment #4) > Mikael, > > are you still onto it? Thanks for the reminder. This PR had disappeared from my radar. Taking it.
[Bug tree-optimization/111336] [14 Regression] Wrong code at -O2/3 since r14-2472-g14b10ff30ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111336 Xi Ruoyao changed: What|Removed |Added Summary|Wrong code at -O2/3 since |[14 Regression] Wrong code |r14-2472-g14b10ff30ad |at -O2/3 since ||r14-2472-g14b10ff30ad Status|UNCONFIRMED |NEW Last reconfirmed||2023-09-08 Ever confirmed|0 |1 Component|c |tree-optimization --- Comment #1 from Xi Ruoyao --- Confirmed.
[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #15 from Xi Ruoyao ---
(In reply to chenglulu from comment #13)
> (In reply to Xi Ruoyao from comment #12)
> > (In reply to chenglulu from comment #11)
> > > (In reply to Xi Ruoyao from comment #10)
> > > > (In reply to Xi Ruoyao from comment #9)
> > > >
> > > > > (define_insn "di3_fake"
> > > > >[(set (match_operand:DI 0 "register_operand" "=r,,")
> > > > > - (sign_extend:DI
> > > > > - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > > > - (match_operand:DI 2 "register_operand"
> > > > > "r,r,r"]
> > > > > - ""
> > > > > + (if_then_else
> > > > > + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > > > > +(sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > > > > +(eq (match_operand:DI 2 "register_operand" "r,r,r")
> > > > > +(sign_extend:DI (subreg:SI (match_dup 2) 0
> > > > > + (sign_extend:DI
> > > > > + (any_div:SI (subreg:SI (match_dup 1) 0)
> > > > > + (subreg:SI (match_dup 2) 0)))
> > > > > + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
> > > >
> > > > With this the compiler will still believe all bad {div,mod}.w{,u}
> > >
> > > I think this is already defined as UNSPEC. Isn’t the simpler the logic,
> > > the
> > > better?
> >
> > Yes, I think we should just use 4 different UNSPEC_ values and the simple
> > version. But I've not find a way to use 4 different UNSPEC_ values in the
> > RTL template except duplicating everything 4 times...
>
> I still have a question that I don't quite understand, that is, why that the
> four generated strings are equivalent when using an UNSPEC name? My template
> names are different, and they will not be automatically matched during
> optimization.???
Oh I get it, you mean
(define_insn "di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,,")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"]
+ (unspec:DI [(any_div:DI
+ (match_operand:DI 1 "register_operand" "r,r,0")
+ (match_operand:DI 2 "register_operand" "r,r,r"))]
+UNSPEC_ANY_DIV)))]
""
{
return loongarch_output_division (".w\t%0,%1,%2", operands);
Good idea! I think it's better than my stupid hacks :).
I'd been thinking about:
(define_insn "di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,,")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"]
+ (unspec:DI [(match_operand:DI 1 "register_operand" "r,r,0")
+ (match_operand:DI 2 "register_operand" "r,r,r")]
+UNSPEC_ANY_DIV)))]
""
{
return loongarch_output_division (".w\t%0,%1,%2", operands);
and this is just wrong.
[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #14 from Xi Ruoyao ---
I'm trying
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 75f641b38ee..44d9b99b2f5 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -64,6 +64,12 @@ (define_c_enum "unspec" [
UNSPEC_CRC
UNSPEC_CRCC
+ ;; 32-bit divisions can produce unspecified value if TARGET_64BIT
+ UNSPEC_DIV_W
+ UNSPEC_UDIV_W
+ UNSPEC_MOD_W
+ UNSPEC_UMOD_W
+
UNSPEC_LOAD_FROM_GOT
UNSPEC_PCALAU12I
UNSPEC_ORI_L_LO12
@@ -461,6 +467,8 @@ (define_code_iterator neg_bitwise [and ior])
;; This code iterator allows unsigned and signed division to be generated
;; from the same template.
(define_code_iterator any_div [div udiv mod umod])
+(define_code_attr ANY_DIV [(div "DIV") (udiv "UDIV")
+ (mod "MOD") (umod "UMOD")])
;; This code iterator allows addition and subtraction to be generated
;; from the same template.
@@ -918,8 +926,9 @@ (define_insn "*3"
(define_insn "di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,,")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"]
+ (unspec:SI [(match_operand:DI 1 "register_operand" "r,r,0")
+ (match_operand:DI 2 "register_operand" "r,r,r")]
+UNSPEC_)))]
""
{
return loongarch_output_division (".w\t%0,%1,%2", operands);
But:
../../gcc/gcc/config/loongarch/loongarch.md:931:23: error: invalid decimal
constant "UNSPEC_"
[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #13 from chenglulu ---
(In reply to Xi Ruoyao from comment #12)
> (In reply to chenglulu from comment #11)
> > (In reply to Xi Ruoyao from comment #10)
> > > (In reply to Xi Ruoyao from comment #9)
> > >
> > > > (define_insn "di3_fake"
> > > >[(set (match_operand:DI 0 "register_operand" "=r,,")
> > > > - (sign_extend:DI
> > > > - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > > - (match_operand:DI 2 "register_operand"
> > > > "r,r,r"]
> > > > - ""
> > > > + (if_then_else
> > > > + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > > > + (sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > > > + (eq (match_operand:DI 2 "register_operand" "r,r,r")
> > > > + (sign_extend:DI (subreg:SI (match_dup 2) 0
> > > > + (sign_extend:DI
> > > > + (any_div:SI (subreg:SI (match_dup 1) 0)
> > > > + (subreg:SI (match_dup 2) 0)))
> > > > + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
> > >
> > > With this the compiler will still believe all bad {div,mod}.w{,u}
> >
> > I think this is already defined as UNSPEC. Isn’t the simpler the logic, the
> > better?
>
> Yes, I think we should just use 4 different UNSPEC_ values and the simple
> version. But I've not find a way to use 4 different UNSPEC_ values in the
> RTL template except duplicating everything 4 times...
I still have a question that I don't quite understand, that is, why that the
four generated strings are equivalent when using an UNSPEC name? My template
names are different, and they will not be automatically matched during
optimization.???
[Bug c/111336] New: Wrong code at -O2/3 since r14-2472-g14b10ff30ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111336
Bug ID: 111336
Summary: Wrong code at -O2/3 since r14-2472-g14b10ff30ad
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: hubicka at gcc dot gnu.org
Target Milestone: ---
gcc at -O2/3 produced the wrong code on the following testcase.
Bisected to r14-2472-g14b10ff30ad
Compiler explorer: https://godbolt.org/z/njdcv5aK8
$ cat a.c
int printf(const char *, ...);
int a, b;
long c = 3521733542;
int d[2];
int e(int f, int g) {
if (f == 0)
return 0;
if (f > 200)
return 0;
if (g)
return 5 * f;
return 0;
}
int main() {
int h = 0;
for (; e((int)c + 773233762, c + 60) + 773163185 + h < 2; h++)
d[h] = b;
printf("%X\n", a);
}
$
$ gcc -O0 a.c && ./a.out
0
$ gcc -O2 a.c && ./a.out
Segmentation fault
$
[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #12 from Xi Ruoyao ---
(In reply to chenglulu from comment #11)
> (In reply to Xi Ruoyao from comment #10)
> > (In reply to Xi Ruoyao from comment #9)
> >
> > > (define_insn "di3_fake"
> > >[(set (match_operand:DI 0 "register_operand" "=r,,")
> > > - (sign_extend:DI
> > > - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > - (match_operand:DI 2 "register_operand" "r,r,r"]
> > > - ""
> > > + (if_then_else
> > > + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > > +(sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > > +(eq (match_operand:DI 2 "register_operand" "r,r,r")
> > > +(sign_extend:DI (subreg:SI (match_dup 2) 0
> > > + (sign_extend:DI
> > > + (any_div:SI (subreg:SI (match_dup 1) 0)
> > > + (subreg:SI (match_dup 2) 0)))
> > > + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
> >
> > With this the compiler will still believe all bad {div,mod}.w{,u}
>
> I think this is already defined as UNSPEC. Isn’t the simpler the logic, the
> better?
Yes, I think we should just use 4 different UNSPEC_ values and the simple
version. But I've not find a way to use 4 different UNSPEC_ values in the RTL
template except duplicating everything 4 times...
[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #11 from chenglulu ---
(In reply to Xi Ruoyao from comment #10)
> (In reply to Xi Ruoyao from comment #9)
>
> > (define_insn "di3_fake"
> >[(set (match_operand:DI 0 "register_operand" "=r,,")
> > - (sign_extend:DI
> > - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > - (match_operand:DI 2 "register_operand" "r,r,r"]
> > - ""
> > + (if_then_else
> > + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> > + (sign_extend:DI (subreg:SI (match_dup 1) 0)))
> > + (eq (match_operand:DI 2 "register_operand" "r,r,r")
> > + (sign_extend:DI (subreg:SI (match_dup 2) 0
> > + (sign_extend:DI
> > + (any_div:SI (subreg:SI (match_dup 1) 0)
> > + (subreg:SI (match_dup 2) 0)))
> > + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
>
> With this the compiler will still believe all bad {div,mod}.w{,u}
I think this is already defined as UNSPEC. Isn’t the simpler the logic, the
better?
> instructions generate the exactly same unspecified value. But I don't think
> this is really relevant: if a program depends on the unspecified value (no
> matter one value or multiple values) it's already wrong.
>
> If we are really "paranoid" about this we can make 4 UNSPEC_BAD_* constants
> and use [(match_dup 1) (match_dup 2)] instead of [(const_int 0)].
>
> > + "TARGET_64BIT"
> > {
> >return loongarch_output_division (".w\t%0,%1,%2", operands);
> > }
[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #10 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #9)
> (define_insn "di3_fake"
>[(set (match_operand:DI 0 "register_operand" "=r,,")
> - (sign_extend:DI
> - (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> - (match_operand:DI 2 "register_operand" "r,r,r"]
> - ""
> + (if_then_else
> + (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
> +(sign_extend:DI (subreg:SI (match_dup 1) 0)))
> +(eq (match_operand:DI 2 "register_operand" "r,r,r")
> +(sign_extend:DI (subreg:SI (match_dup 2) 0
> + (sign_extend:DI
> + (any_div:SI (subreg:SI (match_dup 1) 0)
> + (subreg:SI (match_dup 2) 0)))
> + (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
With this the compiler will still believe all bad {div,mod}.w{,u} instructions
generate the exactly same unspecified value. But I don't think this is really
relevant: if a program depends on the unspecified value (no matter one value or
multiple values) it's already wrong.
If we are really "paranoid" about this we can make 4 UNSPEC_BAD_* constants and
use [(match_dup 1) (match_dup 2)] instead of [(const_int 0)].
> + "TARGET_64BIT"
> {
>return loongarch_output_division (".w\t%0,%1,%2", operands);
> }
[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334
--- Comment #9 from Xi Ruoyao ---
(In reply to chenglulu from comment #7)
> (In reply to Xi Ruoyao from comment #6)
> > (In reply to Xi Ruoyao from comment #5)
> > > (In reply to chenglulu from comment #3)
> > > > This involves the template di3_fake:
> > > > (define_insn "di3_fake"
> > > > [(set (match_operand:DI 0 "register_operand" "=r,,")
> > > > (sign_extend:DI
> > > > (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
> > > > (match_operand:DI 2 "register_operand"
> > > > "r,r,r"]
> > > > ""
> > > > {
> > > > return loongarch_output_division (".w\t%0,%1,%2", operands);
> > > > }
> > > > [(set_attr "type" "idiv")
> > > >(set_attr "mode" "SI")
> > > >(set (attr "enabled")
> > > > (if_then_else
> > > > (match_test "!!which_alternative ==
> > > > loongarch_check_zero_div_p()")
> > > > (const_string "yes")
> > > > (const_string "no")))])
> > > >
> > > >
> > > > I think there is a problem with the implementation of this template.
> > > > First, the instructions generated in the template are [u]div.w[u], etc.
> > > > The
> > > > description of such instructions in the instruction manual is that if
> > > > the
> > > > upper 32 bits are not extended by the 31st bit sign then the result is
> > > > uncertain.
> > >
> > > I think this reason alone makes the pattern looks very wrong.
> > >
> > > I'll take a look...
> >
> > Hmm, I guess we should just make di3_fake an UNSPEC because there is no way
> > to use div.w and its friends out of 3.
>
> I agree with your idea, so I tried changing it to something like this.Do you
> think it's okay for me to change like this?
>
>
> (define_insn "di3_fake"
> [(set (match_operand:DI 0 "register_operand" "=r,,")
> (sign_extend:DI
> (unspec:SI [(any_div:SI (match_operand:DI 1 "register_operand"
> "r,r,0")
> (match_operand:DI 2 "register_operand" "r,r,r"))]
>UNSPEC_ANY_DIV)))]
> ""
> {
> return loongarch_output_division (".w\t%0,%1,%2", operands);
> }
> [(set_attr "type" "idiv")
>(set_attr "mode" "SI")
>(set (attr "enabled")
> (if_then_else
> (match_test "!!which_alternative == loongarch_check_zero_div_p()")
> (const_string "yes")
> (const_string "no")))])
I'm not sure if we can use a single UNSPEC_ANY_DIV value for 4 different
operations (I'm afraid it will make a further CSE pass believe "a % b" is same
as "a / b" but maybe I'm wrong here).
I came up with a more detailed template:
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 75f641b38ee..d162013695f 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -64,6 +64,9 @@ (define_c_enum "unspec" [
UNSPEC_CRC
UNSPEC_CRCC
+ ;; {div,mod}.w{,u} with bad input
+ UNSPEC_BAD_DIVW
+
UNSPEC_LOAD_FROM_GOT
UNSPEC_PCALAU12I
UNSPEC_ORI_L_LO12
@@ -880,7 +883,7 @@ (define_expand "3"
(match_operand:GPR 2 "register_operand")))]
""
{
- if (GET_MODE (operands[0]) == SImode)
+ if (TARGET_64BIT && GET_MODE (operands[0]) == SImode)
{
rtx reg1 = gen_reg_rtx (DImode);
rtx reg2 = gen_reg_rtx (DImode);
@@ -917,10 +920,16 @@ (define_insn "*3"
(define_insn "di3_fake"
[(set (match_operand:DI 0 "register_operand" "=r,,")
- (sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"]
- ""
+ (if_then_else
+ (and (eq (match_operand:DI 1 "register_operand" "r,r,0")
+ (sign_extend:DI (subreg:SI (match_dup 1) 0)))
+ (eq (match_operand:DI 2 "register_operand" "r,r,r")
+ (sign_extend:DI (subreg:SI (match_dup 2) 0
+ (sign_extend:DI
+ (any_div:SI (subreg:SI (match_dup 1) 0)
+ (subreg:SI (match_dup 2) 0)))
+ (unspec:DI [(const_int 0)] UNSPEC_BAD_DIVW)))]
+ "TARGET_64BIT"
{
return loongarch_output_division (".w\t%0,%1,%2", operands);
}
[Bug target/111334] [14 regression] ICE is reported during the combine pass optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111334 --- Comment #8 from chenglulu --- (In reply to Andrew Pinski from comment #4) > (In reply to chenglulu from comment #3) > > This involves the template di3_fake: > > (define_insn "di3_fake" > > [(set (match_operand:DI 0 "register_operand" "=r,,") > > (sign_extend:DI > > (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0") > > (match_operand:DI 2 "register_operand" "r,r,r"] > > That pattern definitely looks broken. > Divide's operands' mode must match the mode of the divide IIRC. OK, thanks! So the compilation failure is caused by an error in this template, right? （Sorry, I don't understand the optimization of this combine）
