[Bug middle-end/113669] -fsanitize=undefined failed to check a signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113669 --- Comment #3 from Jiajing_Zheng --- (In reply to Jakub Jelinek from comment #1) > This is because already the FE optimizes it, when it sees that > ((int)(g_B * g_A[1])) & (g_A[1] & g_A[0]) | g_A[0] > is just being added to unsigned char element, the upper bits of it aren't > needed, so the multiplication and & and | are all performed in unsigned char > rather than wider types. Thanks for your reply. I then used 'gcc -O2 mutation.c -fsanitize=undefined -S' to generate mutation.s. As shown below, the relevant compilation sections 'addl %r13d, %r13d' show that the statement 'g_A[0] += temp & (g_A[1] & g_A[0]) | g_A[0];' in the loop is optimized to 'g_A[0] += g_A[0];'. .L8: addl%r13d, %r13d movslq %ebx, %rsi movb%r13b, g_A(%rip) cmpq$4, %rsi jnb .L12 Is that what you mean by "the FE optimizes it"? I want to see the file generated by a file.c after FE optimization, should I go to the corresponding assembly file.s?
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #2 from Niclas Rosenvik --- (In reply to Andrew Pinski from comment #1) > >I tried to add the gcc12 and up parts of > > It is correct except it should just use GCC 14 I think. I forgot to mention that the problem with _Float16 aka __extendhfdf2 has happened on gcc12 as well as gcc14. If it was possible to not just choose one version of gcc then I would have marked gcc12 to 14.
[Bug tree-optimization/113692] ICE: in lower_stmt, at gimple-lower-bitint.cc:5444 at -O with _BitInt() in a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113692 --- Comment #3 from Richard Biener --- integer to pointer conversions are not constrained in GIMPLE, only pointer-to-int widening conversions are.
[Bug target/113690] [13/14 Regression] ICE: in as_a, at machmode.h:381 with -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113690 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/113687] -Warray-bounds is not emitted inside class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113687 Richard Biener changed: What|Removed |Added Blocks||56456 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-01 --- Comment #2 from Richard Biener --- (In reply to Andrew Pinski from comment #1) > The warning only happens if the vague linkage function is used. and IIRC > that is by design. Yeah, we try to avoid diagnosing things on "dead" code and here the whole functions are dead. IIRC even -fanalyzer runs after cgraph removes unreachable functions. It would be still nice to diagnose these kind of trivial cases. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug testsuite/113685] [14 regression] gcc.dg/vect/vect-117.c fails profile checking with Invalid sum after r14-4089-gd45ddc2c04e471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113685 Richard Biener changed: What|Removed |Added Last reconfirmed||2024-02-01 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |14.0 Keywords||testsuite-fail Summary|[14 regression] xxx fails |[14 regression] |after yyy |gcc.dg/vect/vect-117.c ||fails profile checking with ||Invalid sum after ||r14-4089-gd45ddc2c04e471 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- As said in the other PR, this is more for Honza who thought checking we do not end with invalid profiles for all vect testcases is a good thing ;) Btw, the wrong count pops up in DOM3: t.c.203t.dom3:;; Invalid sum of incoming counts 138435014 (estimated locally, freq 3.0936), should be 134239200 (estimated locally, freq 2.) so it seems to be a jump threading issue. It's gone with -fno-thread-jumps. Very likely a latent issue, but of course the change triggering this does have an effect on jump threading. Confirmed.
[Bug target/113684] Cross compiler without assembler and linker should assume that all assembler and linker features are available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113684 --- Comment #3 from Richard Biener --- I'm usually having cross assembler/linker around as they are easy to build.
[Bug target/113700] libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 --- Comment #1 from Andrew Pinski --- >I tried to add the gcc12 and up parts of It is correct except it should just use GCC 14 I think.
[Bug libgcc/113700] New: libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700 Bug ID: 113700 Summary: libgcc_s does not include symbols for _Float16 and __bf16 on Solaris/Illumos even though gcc generates code for _Float16 and __bf16 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: youremailsarecrap at gmail dot com Target Milestone: --- Created attachment 57277 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57277&action=edit _Float16 and __bf16 that breaks on Illumos When compiling the code included in the .ii files on illumos the output claims that it can't find the symbols __extendhfdf2, __extendbfsf2 and __truncsfbf2 . Command line and output: g++ -march=native -shared -shared-libgcc -fPIC -Wl,--no-undefined -o f16-bf16.so f16-bf16.cc Undefined first referenced symbol in file __extendhfdf2 f16-bf16.so-f16-bf16.o __extendbfsf2 f16-bf16.so-f16-bf16.o __truncsfbf2f16-bf16.so-f16-bf16.o ld: fatal: symbol referencing errors. No output written to f16-bf16.so collect2: error: ld returned 1 exit status The -Wl,--no-undefined is used here to not have create a executable that links to the so files to cause the error. -march=native is used since sse2 seems to be needed for f16 and bf16 on x86 platforms if I understand the half-precision doc in gcc correctly, I used a system with sse2 when compiling this. My own fix, that may not be correct: I tried to add the gcc12 and up parts of libgcc/config/i386/libgcc-glibc.ver to libgcc/config/i386/libgcc-sol2.ver rebuilt gcc and then it linked correctly. Some maintainer could take a look at that.
[Bug rust/113553] rust fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553 --- Comment #2 from Andrew Pinski --- Which glibc are you using? See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82346 and maybe https://sourceware.org/bugzilla/show_bug.cgi?id=22146
[Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403 --- Comment #8 from Chenghui Pan --- (In reply to Xi Ruoyao from comment #4) > After r14-5545 this issue became latent. > > And at some point before r14-5545 this issue became nondeterministic: a > compiled program *sometimes* crashes. Really strange... After applying this commit, GCC does not apply loop peeling while processing the openmp reduction directive, which I think is the spawn point of the problematic codes (According to Guo Jie's sample).
[Bug target/113560] Strange code generated when optimizing a multiplication on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113560 --- Comment #8 from GCC Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:2f14c0dbb789852947cb58fdf7d3162413f053fa commit r14-8680-g2f14c0dbb789852947cb58fdf7d3162413f053fa Author: Roger Sayle Date: Thu Feb 1 06:10:42 2024 + PR target/113560: Enhance is_widening_mult_rhs_p. This patch resolves PR113560, a code quality regression from GCC12 affecting x86_64, by enhancing the middle-end's tree-ssa-math-opts.cc to recognize more instances of widening multiplications. The widening multiplication perception code identifies cases like: _1 = (unsigned __int128) x; __res = _1 * 100; but in the reported test case, the original input looks like: _1 = (unsigned long long) x; _2 = (unsigned __int128) _1; __res = _2 * 100; which gets optimized by constant folding during tree-ssa to: _2 = x & 18446744073709551615; // x & 0x __res = _2 * 100; where the BIT_AND_EXPR hides (has consumed) the extension operation. This reveals the more general deficiency (missed optimization opportunity) in widening multiplication perception that additionally both __int128 foo(__int128 x, __int128 y) { return (x & 1000) * (y & 1000) } and unsigned __int128 bar(unsigned __int128 x, unsigned __int128) { return (x >> 80) * (y >> 80); } should be recognized as widening multiplications. Hence rather than test explicitly for BIT_AND_EXPR (as in the first version of this patch) the more general solution is to make use of range information, as provided by tree_non_zero_bits. As a demonstration of the observed improvements, function foo above currently with -O2 compiles on x86_64 to: foo:movq%rdi, %rsi movq%rdx, %r8 xorl%edi, %edi xorl%r9d, %r9d andl$1000, %esi andl$1000, %r8d movq%rdi, %rcx movq%r9, %rdx imulq %rsi, %rdx movq%rsi, %rax imulq %r8, %rcx addq%rdx, %rcx mulq%r8 addq%rdx, %rcx movq%rcx, %rdx ret with this patch, GCC recognizes the *w and instead generates: foo:movq%rdi, %rsi movq%rdx, %r8 andl$1000, %esi andl$1000, %r8d movq%rsi, %rax imulq %r8 ret which is perhaps easier to understand at the tree-level where __int128 foo (__int128 x, __int128 y) { __int128 _1; __int128 _2; __int128 _5; [local count: 1073741824]: _1 = x_3(D) & 1000; _2 = y_4(D) & 1000; _5 = _1 * _2; return _5; } gets transformed to: __int128 foo (__int128 x, __int128 y) { __int128 _1; __int128 _2; __int128 _5; signed long _7; signed long _8; [local count: 1073741824]: _1 = x_3(D) & 1000; _2 = y_4(D) & 1000; _7 = (signed long) _1; _8 = (signed long) _2; _5 = _7 w* _8; return _5; } 2023-02-01 Roger Sayle Richard Biener gcc/ChangeLog PR target/113560 * tree-ssa-math-opts.cc (is_widening_mult_rhs_p): Use range information via tree_non_zero_bits to check if this operand is suitably extended for a widening (or highpart) multiplication. (convert_mult_to_widen): Insert explicit casts if the RHS or LHS isn't already of the claimed type. gcc/testsuite/ChangeLog PR target/113560 * g++.target/i386/pr113560.C: New test case. * gcc.target/i386/pr113560.c: Likewise. * gcc.dg/pr87954.c: Update test case.
[Bug middle-end/113699] during GIMPLE pass: bitintlower ICE: SIGSEGV in var_to_partition (tree-ssa-live.h:163) with _BitInt() used in __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113699 --- Comment #2 from Andrew Pinski --- The code for lowering asm is not expecting an SSA_NAME_IS_DEFAULT_DEF here ...
[Bug middle-end/113699] during GIMPLE pass: bitintlower ICE: SIGSEGV in var_to_partition (tree-ssa-live.h:163) with _BitInt() used in __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113699 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-01 Component|tree-optimization |middle-end Keywords||ice-on-valid-code Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. This happens with an uninitialized variable only. Here is a valid code testcase: ``` void foo (void) { _BitInt(129) i; __asm__ ("": :"rm" (i)); } ```
[Bug tree-optimization/113699] New: during GIMPLE pass: bitintlower ICE: SIGSEGV in var_to_partition (tree-ssa-live.h:163) with _BitInt() used in __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113699 Bug ID: 113699 Summary: during GIMPLE pass: bitintlower ICE: SIGSEGV in var_to_partition (tree-ssa-live.h:163) with _BitInt() used in __asm__ Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57276&action=edit reduced testcase (from gcc.target/i386/pr41985.c) Compiler output: $ x86_64-pc-linux-gnu-gcc testcase.c -wrapper valgrind,-q ==30321== Invalid read of size 8 ==30321==at 0x271DC7F: var_to_partition (tree-ssa-live.h:163) ==30321==by 0x271DC7F: lower_asm (gimple-lower-bitint.cc:5203) ==30321==by 0x271DC7F: (anonymous namespace)::bitint_large_huge::lower_stmt(gimple*) (gimple-lower-bitint.cc:5240) ==30321==by 0x2720009: gimple_lower_bitint() (gimple-lower-bitint.cc:6564) ==30321==by 0x13CDCBA: execute_one_pass(opt_pass*) (passes.cc:2646) ==30321==by 0x13CE5AF: execute_pass_list_1(opt_pass*) (passes.cc:2755) ==30321==by 0x13CE5E8: execute_pass_list(function*, opt_pass*) (passes.cc:2766) ==30321==by 0xFCDC05: expand (cgraphunit.cc:1843) ==30321==by 0xFCDC05: cgraph_node::expand() (cgraphunit.cc:1796) ==30321==by 0xFCEB19: output_in_order (cgraphunit.cc:2193) ==30321==by 0xFCEB19: symbol_table::compile() [clone .part.0] (cgraphunit.cc:2397) ==30321==by 0xFD1AC7: compile (cgraphunit.cc:2313) ==30321==by 0xFD1AC7: symbol_table::finalize_compilation_unit() (cgraphunit.cc:2585) ==30321==by 0x150FF61: compile_file() (toplev.cc:474) ==30321==by 0xDE840B: do_compile (toplev.cc:2152) ==30321==by 0xDE840B: toplev::main(int, char**) (toplev.cc:2308) ==30321==by 0xDE9BEA: main (main.cc:39) ==30321== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==30321== during GIMPLE pass: bitintlower0 testcase.c: In function 'foo': testcase.c:2:1: internal compiler error: Segmentation fault 2 | foo (void) | ^~~ 0x150fa7f crash_signal /repo/gcc-trunk/gcc/toplev.cc:317 0x271dc7f var_to_partition(_var_map*, tree_node*) /repo/gcc-trunk/gcc/tree-ssa-live.h:163 0x271dc7f lower_asm /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5203 0x271dc7f lower_stmt /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5240 0x2720009 gimple_lower_bitint /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6564 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. $ x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240131 (experimental) (GCC)
[Bug libgomp/113698] GNU OpenMP with OMP_PROC_BIND alters thread affinity in a way that negatively affects performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113698 --- Comment #2 from Andrew Pinski --- Actually I misread the testcase, because it looks like LLVM's libomp follows the same as GCC's. And it looks like the OpenMP spec is specific about that behavior too.
[Bug libgomp/113698] GNU OpenMP with OMP_PROC_BIND alters thread affinity in a way that negatively affects performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113698 --- Comment #1 from Andrew Pinski --- https://www.openmp.org/spec-html/5.0/openmpse52.html > Otherwise, the execution environment should not move OpenMP threads between > OpenMP places, thread affinity is enabled, and __the initial thread is bound > to the first place in the OpenMP place list prior to the first active > parallel region__. Hmm. Maybe LLVM's libomp does not follow the openmp spec.
[Bug libgomp/113698] New: GNU OpenMP with OMP_PROC_BIND alters thread affinity in a way that negatively affects performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113698 Bug ID: 113698 Summary: GNU OpenMP with OMP_PROC_BIND alters thread affinity in a way that negatively affects performance Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: kugan at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 57275 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57275&action=edit testcase When OMP_PROC_BIND=true it seems gomp set the affinity even before main() starts. In particular, the main thread gets affinity 0x1 (i.e. pinned to the first core). For the attached, I get $ OMP_NUM_THREADS=72 ./a.out [main thread affinity right after main()]. tid:ae511020 aff:... duration: 402.949 msec $ OMP_PROC_BIND=true OMP_NUM_THREADS=72 ./a.out [main thread affinity right after main()]. tid:fffdded50020 aff:...0001 duration: 7879.59 msec $ OMP_PROC_BIND=true OMP_NUM_THREADS=72 ./a.out [main thread affinity right after main()]. tid:ae54c020 aff:...0001 duration: 311219 msec Compiler options used: gcc -O0 -fopenmp repro.c gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/11/lto-wrapper Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --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-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
[Bug middle-end/93509] Stack protector should offer trap-only handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93509 --- Comment #3 from Matheus Afonso Martins Moreira --- Equivalent feature request in the LLVM issue tracker: https://github.com/llvm/llvm-project/issues/80236
[Bug c/113697] New: RISC-V: Redundant vsetvl insn in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113697 Bug ID: 113697 Summary: RISC-V: Redundant vsetvl insn in function Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pan2.li at intel dot com Target Milestone: --- Give the sample code as below, build with -march=rv64gcv -O3 -g0 int foo (int * __restrict a, int n) { int result = 0; for (int i = 0; i < n; i++) result += a[i]; return result; } The asm code looks like below, we have one duplicated vsetvl insn here. foo: .LFB0: .cfi_startproc ble a1,zero,.L4 vsetvli a5,zero,e32,m1,ta,ma vmv.v.i v1,0 .L3: vsetvli a5,a1,e32,m1,tu,ma sllia4,a5,2 sub a1,a1,a5 vle32.v v2,0(a0) add a0,a0,a4 vadd.vv v1,v2,v1 bne a1,zero,.L3 li a5,0 vsetivlizero,1,e32,m1,ta,ma vmv.s.x v2,a5 vsetvli a5,zero,e32,m1,ta,ma <== redundant vsetvl vredsum.vs v1,v1,v2 vmv.x.s a0,v1 ret .L4: li a0,0 ret
[Bug c/113696] New: RISC-V: ineffective vsetvl behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113696 Bug ID: 113696 Summary: RISC-V: ineffective vsetvl behavior Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pan2.li at intel dot com Target Milestone: --- Given we have a sample code, build with '-march=rv64gcv -O3 -g0'. #include "riscv_vector.h" void f (int32_t * restrict in, int32_t * restrict out, size_t n, size_t cond, size_t cond2) { for (size_t i = 0; i < n; i++) { if (i == cond) { vint8mf8_t v = *(vint8mf8_t*)(in + i + 100); *(vint8mf8_t*)(out + i + 100) = v; } else if (i == cond2) { vfloat32mf2_t v = *(vfloat32mf2_t*)(in + i + 200); *(vfloat32mf2_t*)(out + i + 200) = v; } else if (i == (cond2 - 1)) { vuint16mf2_t v = *(vuint16mf2_t*)(in + i + 300); *(vuint16mf2_t*)(out + i + 300) = v; } else { vint8mf4_t v = *(vint8mf4_t*)(in + i + 400); *(vint8mf4_t*)(out + i + 400) = v; } } } when we have asm code as below, the vsetvl insn is somehow ineffective and can be refined up to a point. f: .LFB0: .cfi_startproc beq a2,zero,.L12 addia7,a0,400 addia6,a1,400 addia0,a0,1600 addia1,a1,1600 li a5,0 addit6,a4,-1 vsetvli t3,zero,e8,mf8,ta,ma .L7: beq a3,a5,.L15 beq a4,a5,.L16 beq t6,a5,.L17 vsetvli t1,zero,e8,mf4,ta,ma vle8.v v1,0(a0) vse8.v v1,0(a1) vsetvli t3,zero,e8,mf8,ta,ma .L4: addia5,a5,1 addia7,a7,4 addia6,a6,4 addia0,a0,4 addia1,a1,4 bne a2,a5,.L7 .L12: ret .L15: vle8.v v1,0(a7) vse8.v v1,0(a6) j .L4 .L17: vsetvli t1,zero,e8,mf4,ta,ma addit5,a0,-400 addit4,a1,-400 vle16.v v1,0(t5) vse16.v v1,0(t4) vsetvli t3,zero,e8,mf8,ta,ma j .L4 .L16: addit5,a0,-800 addit4,a1,-800 vle32.v v1,0(t5) vse32.v v1,0(t4) j .L4
[Bug target/113249] RISC-V: regression testsuite errors -mtune=generic-ooo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249 --- Comment #5 from GCC Commits --- The master branch has been updated by Edwin Lu : https://gcc.gnu.org/g:4b799a16ae59fc0f508c5931ebf1851a3446b707 commit r14-8674-g4b799a16ae59fc0f508c5931ebf1851a3446b707 Author: Edwin Lu Date: Wed Jan 31 10:45:43 2024 -0800 RISC-V: Use default cost model for insn scheduling Use default cost model scheduling on these test cases. All these tests introduce scan dump failures with -mtune generic-ooo. Since the vector cost models are the same across all three tunes, some of the tests in PR113249 will be fixed with this patch series. PR target/113249 gcc/testsuite/ChangeLog: * g++.target/riscv/rvv/base/bug-1.C: use default scheduling * gcc.target/riscv/rvv/autovec/reduc/reduc_call-2.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-102.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-108.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-114.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-119.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-12.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-16.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-17.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-19.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-21.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-23.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-25.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-27.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-29.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-31.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-33.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-35.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-4.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-40.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-44.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-50.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-56.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-62.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-68.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-74.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-79.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-8.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-84.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-90.c: ditto * gcc.target/riscv/rvv/base/binop_vx_constraint-96.c: ditto * gcc.target/riscv/rvv/base/float-point-dynamic-frm-30.c: ditto * gcc.target/riscv/rvv/base/pr108185-1.c: ditto * gcc.target/riscv/rvv/base/pr108185-2.c: ditto * gcc.target/riscv/rvv/base/pr108185-3.c: ditto * gcc.target/riscv/rvv/base/pr108185-4.c: ditto * gcc.target/riscv/rvv/base/pr108185-5.c: ditto * gcc.target/riscv/rvv/base/pr108185-6.c: ditto * gcc.target/riscv/rvv/base/pr108185-7.c: ditto * gcc.target/riscv/rvv/base/shift_vx_constraint-1.c: ditto * gcc.target/riscv/rvv/vsetvl/pr111037-3.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-28.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-29.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-32.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-33.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_single_block-17.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_single_block-18.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_single_block-19.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-11.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-12.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-4.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-5.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-6.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-7.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-8.c: ditto * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-9.c: ditto * gfortran.dg/vect/vect-8.f90: ditto Signed-off-by: Edwin Lu
[Bug target/113690] [13/14 Regression] ICE: in as_a, at machmode.h:381 with -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113690 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|target --- Comment #2 from Andrew Pinski --- (gdb) p debug_rtx(tem) (expr_list:REG_EQUAL (mult:V1TI (reg:V1TI 101 [ _12 ]) (const_int 3 [0x3])) (nil)) That seems wrong ... It was introduced by stv1 pass with: (insn 32 31 33 2 (set (reg:V1TI 132 [ _20 ]) (reg:V1TI 101 [ _12 ])) "t5.c":9:5 2025 {movv1ti_internal} (expr_list:REG_DEAD (reg:V1TI 130 [ BIT_FIELD_REF ]) (expr_list:REG_DEAD (reg:V1TI 129 [ BIT_FIELD_REF ]) (expr_list:REG_UNUSED (reg:CC 17 flags) (expr_list:REG_EQUAL (mult:V1TI (reg:V1TI 101 [ _12 ]) (const_int 3 [0x3])) (nil)) Which was before it: (insn 32 31 33 2 (set (reg:TI 132 [ _20 ]) (reg:TI 101 [ _12 ])) "t5.c":9:5 83 {*movti_internal} (expr_list:REG_DEAD (reg:TI 130 [ BIT_FIELD_REF ]) (expr_list:REG_DEAD (reg:TI 129 [ BIT_FIELD_REF ]) (expr_list:REG_UNUSED (reg:CC 17 flags) (expr_list:REG_EQUAL (mult:TI (reg:TI 101 [ _12 ]) (const_int 3 [0x3])) (nil)) it should have been replaced with `(const_vect (const_int 3))`. So this is a target specific pass which is causing the issue.
[Bug rtl-optimization/113690] [13/14 Regression] ICE: in as_a, at machmode.h:381 with -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113690 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-01 Status|UNCONFIRMED |NEW Target Milestone|--- |13.3 --- Comment #1 from Andrew Pinski --- Confirmed. Note there is some missed optimizations on the gimple level too ...
[Bug target/113657] [14 Regression] ICE Segmentation fault with -mstrict-align and __arm_data512_t since r14-1187-gd6b756447cd58b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113657 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug target/113657] [14 Regression] ICE Segmentation fault with -mstrict-align and __arm_data512_t since r14-1187-gd6b756447cd58b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113657 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:dbf847d2c8d1c910948ba34c9338939c67323273 commit r14-8671-gdbf847d2c8d1c910948ba34c9338939c67323273 Author: Andrew Pinski Date: Tue Jan 30 00:50:56 2024 -0800 aarch64: -mstrict-align vs __arm_data512_t [PR113657] After r14-1187-gd6b756447cd58b, simplify_gen_subreg can return NULL for "unaligned" memory subreg. Since V8DI has an alignment of 8 bytes, using TImode causes simplify_gen_subreg to return NULL. This fixes the issue by using DImode instead for the loop. And then we will have later on the STP/LDP pass combine it back into STP/LDP if needed. Since strict align is less important (usually used for firmware and early boot only), not doing LDP/STP here is ok. Built and tested for aarch64-linux-gnu with no regressions. PR target/113657 gcc/ChangeLog: * config/aarch64/aarch64-simd.md (split for movv8di): For strict aligned mode, use DImode instead of TImode. gcc/testsuite/ChangeLog: * gcc.target/aarch64/acle/ls64_strict_align.c: New test. Signed-off-by: Andrew Pinski
[Bug analyzer/113253] gcc -g causes -fanalyzer to issue false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113253 --- Comment #4 from David Malcolm --- Should be fixed on trunk for gcc 14 by the above patch. Keeping open to backport to other branches.
[Bug analyzer/113253] gcc -g causes -fanalyzer to issue false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113253 --- Comment #3 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:cc7aebff74d8967563fd9af5cb958dfcc8c111e8 commit r14-8670-gcc7aebff74d8967563fd9af5cb958dfcc8c111e8 Author: David Malcolm Date: Wed Jan 31 18:26:26 2024 -0500 analyzer: fix skipping of debug stmts [PR113253] PR analyzer/113253 reports a case where the analyzer output varied with and without -g enabled. The root cause was that debug stmts were in the FOR_EACH_IMM_USE_FAST list for SSA names, leading to the analyzer's state purging logic differing between the -g and non-debugging cases, and thus leading to differences in the exploration of the user's code. Fix by skipping such stmts in the state-purging logic, and removing debug stmts when constructing the supergraph. gcc/analyzer/ChangeLog: PR analyzer/113253 * region-model.cc (region_model::on_stmt_pre): Add gcc_unreachable for debug statements. * state-purge.cc (state_purge_per_ssa_name::state_purge_per_ssa_name): Skip any debug stmts in the FOR_EACH_IMM_USE_FAST list. * supergraph.cc (supergraph::supergraph): Don't add debug stmts to the supernodes. gcc/testsuite/ChangeLog: PR analyzer/113253 * gcc.dg/analyzer/deref-before-check-pr113253.c: New test. Signed-off-by: David Malcolm
[Bug c/113695] RISC-V: Sources with different EEW must use different registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113695 --- Comment #1 from JuzheZhong --- Since both operand are input operand, early clobber "&" constraint can not help.
[Bug c/113695] New: RISC-V: Sources with different EEW must use different registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113695 Bug ID: 113695 Summary: RISC-V: Sources with different EEW must use different registers 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: --- As this PR in LLVM, https://github.com/llvm/llvm-project/issues/80099 RVV ISA: A vector register cannot be used to provide source operands with more than one EEW for a single instruction. A mask register source is considered to have EEW=1 for this constraint. An encoding that would result in the same vector register being read with two or more different EEWs, including when the vector register appears at different positions within two or more vector register groups, is reserved. #include #include void foo(vuint64m2_t colidx, uint32_t* base_addr, size_t vl) { vuint32m1_t values = __riscv_vget_v_u32m2_u32m1(__riscv_vreinterpret_v_u64m2_u32m2 (colidx), 0); __riscv_vsuxei64_v_u32m1(base_addr, colidx, values, vl); } foo: vsetvli zero,a1,e32,m1,ta,ma vsuxei64.v v8,(a0),v8 ret It is incorrect those 2 input operand with different EEW should not be the same register (v8). Current GCC RTL machine description and constraint can not allow us to fix it. Even though it is a bug, I think we can only revisit it in GCC-15.
[Bug middle-end/113694] Allow renaming stack smashing protector symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113694 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/113689] wrong code with unused _BitInt() division with -O2 -fprofile -mcmodel=large -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-01-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. s/511/(256-63)/ is the min to reproduce this issue. Basically just enough to auto-vectorize. I get the feeling that mcount causes alignment differences ...
[Bug middle-end/113694] New: Allow renaming stack smashing protector symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113694 Bug ID: 113694 Summary: Allow renaming stack smashing protector symbols Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: matheus.a.m.moreira at gmail dot com Target Milestone: --- I'm writing freestanding Linux applications which are compiled with -ffreestanding -nostdlib. In order to integrate with the stack smashing protector, I need to provide the following symbols: __stack_chk_guard __stack_chk_fail It would be nice if there was a compiler option to rename these symbols to something else. I want to make them consistent with the rest of my code, thereby improving its quality. A couple of options would be enough: -fstack-protector-canary=my_variable -fstack-protector-handler=my_function Attributes could work too: uintptr_t my_canary __attribute__((stack_protector_canary)); __attribute__((noreturn, stack_protector_handler)) void __stack_chk_fail(void);
[Bug tree-optimization/113691] ICE: in lower_stmt, at gimple-lower-bitint.cc:5444 with function declaration with no parameter specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113691 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113692 Last reconfirmed||2024-01-31 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code --- Comment #1 from Andrew Pinski --- ``` intD.6 * pD.2782; _BitInt(129) i.0_1; ;; basic block 2, loop depth 0, count 1073741824 (estimated locally, freq 1.), maybe hot ;;prev block 0, next block 1, flags: (NEW, REACHABLE, VISITED) ;;pred: ENTRY [always] count:1073741824 (estimated locally, freq 1.) (FALLTHRU,EXECUTABLE) # VUSE <.MEM_2(D)> i.0_1 = iD.2768; # PT = nonlocal escaped null p_4 = (intD.6 *) i.0_1; ``` Confirmed. The problem is the same as recorded in PR 113692. The cast between _BitInt and a pointer is not expected ..
[Bug tree-optimization/113693] ICE: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647 with _BitInt() at -O2 -fdbg-cnt=vect_loop:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113693 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-31 --- Comment #1 from Andrew Pinski --- Confirmed. Though I wonder if -fdbg-cnt is just broken for the vectorizer now ...
[Bug libstdc++/108636] [10 Regression] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636 Mark Bourgeault changed: What|Removed |Added CC||Mark_B53 at yahoo dot com --- Comment #9 from Mark Bourgeault --- In 12.3, GCC still fails with -std=c++20 -fkeep-inline-functions, but passes with -std=c++17 -fkeep-inline-functions. Curiously, the other versions (10.5, 11.4, 13.1) pass with both option sets.
[Bug middle-end/93509] Stack protector should offer trap-only handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93509 Matheus Afonso Martins Moreira changed: What|Removed |Added CC||matheus.a.m.moreira at gmail dot c ||om --- Comment #2 from Matheus Afonso Martins Moreira --- I also need this feature. I'm writing freestanding Linux applications which are compiled with -ffreestanding -nostdlib. I would not need to implement __stack_chk_fail if GCC could be configured to emit traps instead of calling a function. The sanitizers already have trapping modes: -fsanitize-trap[=opts] The -fsanitize-trap= option instructs the compiler to report for sanitizers mentioned in comma-separated list of opts undefined behavior using __builtin_trap rather than a libubsan library routine. The advantage of this is that the libubsan library is not needed and is not linked in, so this is usable even in freestanding environments. This feature would be the stack smashing protector equivalent.
[Bug tree-optimization/113692] ICE: in lower_stmt, at gimple-lower-bitint.cc:5444 at -O with _BitInt() in a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113692 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-01-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > My bet you could get the same error with: > _BitInt(129) i; > > void * > foo(void) > { > void *ret = 0; > ret = (void *)(__SIZETYPE__)(i & 1); > return ret; > } the above works. The question is there an extra cast in the IR between _BitInt and void* required or not? PHIOPT/match-and-simplify does: ``` phiopt match-simplify trying: _2 != 0 ? 1B : 0B Matching expression match.pd:2274, gimple-match-3.cc:23 Matching expression match.pd:2823, gimple-match-2.cc:35 Matching expression match.pd:2826, gimple-match-1.cc:66 Matching expression match.pd:2833, gimple-match-2.cc:96 Matching expression match.pd:2274, gimple-match-3.cc:23 Applying pattern match.pd:3396, gimple-match-6.cc:2527 Applying pattern match.pd:5327, gimple-match-9.cc:17991 phiopt match-simplify back: _5 = _2 != 0; _6 = (void *) _2; result: _6 ``` Notice how there is just cast a between _2 and `void*`.
[Bug c/112571] [13/14 Regression] ICE with nested redefinition of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112571 Joseph S. Myers changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org Known to work||14.0 Status|NEW |ASSIGNED --- Comment #4 from Joseph S. Myers --- Fixed for GCC 14 so far.
[Bug c/112571] [13/14 Regression] ICE with nested redefinition of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112571 --- Comment #3 from GCC Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:d22d1a9346f27db41459738c6eb404f8f0956e6f commit r14-8669-gd22d1a9346f27db41459738c6eb404f8f0956e6f Author: Joseph Myers Date: Wed Jan 31 21:39:53 2024 + c: Fix ICE for nested enum redefinitions with/without fixed underlying type [PR112571] Bug 112571 reports an ICE-on-invalid for cases where an enum is defined, without a fixed underlying type, inside the enum type specifier for a definition of that same enum with a fixed underlying type. The ultimate cause is attempting to access ENUM_UNDERLYING_TYPE in a case where it is NULL. Avoid this by clearing ENUM_FIXED_UNDERLYING_TYPE_P in thie case of inconsistent definitions. Bootstrapped wth no regressions for x86_64-pc-linux-gnu. PR c/112571 gcc/c/ * c-decl.cc (start_enum): Clear ENUM_FIXED_UNDERLYING_TYPE_P when defining without a fixed underlying type an enumeration previously declared with a fixed underlying type. gcc/testsuite/ * gcc.dg/c23-enum-9.c, gcc.dg/c23-enum-10.c: New tests.
[Bug tree-optimization/113693] New: ICE: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647 with _BitInt() at -O2 -fdbg-cnt=vect_loop:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113693 Bug ID: 113693 Summary: ICE: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647 with _BitInt() at -O2 -fdbg-cnt=vect_loop:1 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57274&action=edit reduced testcase (from gcc.dg/pr68766.c) Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -fdbg-cnt=vect_loop:1 testcase.c ***dbgcnt: lower limit 1 reached for vect_loop.*** ***dbgcnt: upper limit 1 reached for vect_loop.*** during GIMPLE pass: vect testcase.c: In function 'fn1': testcase.c:4:1: internal compiler error: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647 4 | fn1(void) | ^~~ 0x865e0d check_loop_closed_ssa_def /repo/gcc-trunk/gcc/tree-ssa-loop-manip.cc:647 0x1695c07 check_loop_closed_ssa_bb /repo/gcc-trunk/gcc/tree-ssa-loop-manip.cc:672 0x1695fa6 verify_loop_closed_ssa(bool, loop*) /repo/gcc-trunk/gcc/tree-ssa-loop-manip.cc:697 0x1695fa6 verify_loop_closed_ssa(bool, loop*) /repo/gcc-trunk/gcc/tree-ssa-loop-manip.cc:681 0x13ca929 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2106 0x13cad2e execute_todo /repo/gcc-trunk/gcc/passes.cc:2142 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240131 (experimental) (GCC)
[Bug tree-optimization/113692] ICE: in lower_stmt, at gimple-lower-bitint.cc:5444 at -O with _BitInt() in a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113692 --- Comment #1 from Andrew Pinski --- My bet you could get the same error with: _BitInt(129) i; void * foo(void) { void *ret = 0; ret = (void *)(__SIZETYPE__)(i & 1); return ret; }
[Bug tree-optimization/113692] New: ICE: in lower_stmt, at gimple-lower-bitint.cc:5444 at -O with _BitInt() in a condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113692 Bug ID: 113692 Summary: ICE: in lower_stmt, at gimple-lower-bitint.cc:5444 at -O with _BitInt() in a condition Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57273 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57273&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc testcase.c -O during GIMPLE pass: bitintlower testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5444 4 | foo(void) | ^~~ 0xd8cab5 lower_stmt /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5444 0x2720009 gimple_lower_bitint /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6564 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240131 (experimental) (GCC)
[Bug tree-optimization/113691] New: ICE: in lower_stmt, at gimple-lower-bitint.cc:5444 with function declaration with no parameter specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113691 Bug ID: 113691 Summary: ICE: in lower_stmt, at gimple-lower-bitint.cc:5444 with function declaration with no parameter specification Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57272 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57272&action=edit reduced testcase I don't know if the code is valid or not, but GCC does not reject the code unless -pedantic-errors or -std=c23 is passed. Compiler output: $ x86_64-pc-linux-gnu-gcc -O testcase.c during GIMPLE pass: bitintlower testcase.c: In function 'bar': testcase.c:3:6: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5444 3 | void bar() { foo(bar_i); } | ^~~ 0xd8cab5 lower_stmt /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5444 0x2720009 gimple_lower_bitint /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6564 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240131 (experimental) (GCC)
[Bug rtl-optimization/113690] New: [13/14 Regression] ICE: in as_a, at machmode.h:381 with -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113690 Bug ID: 113690 Summary: [13/14 Regression] ICE: in as_a, at machmode.h:381 with -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types -funroll-loops Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57271&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types -funroll-loops testcase.c during RTL pass: cse2 testcase.c: In function 'foo': testcase.c:10:1: internal compiler error: in as_a, at machmode.h:381 10 | } | ^ 0x814e46 scalar_int_mode as_a(machine_mode) /repo/gcc-trunk/gcc/machmode.h:381 0x8196e0 scalar_mode as_a(machine_mode) /repo/gcc-trunk/gcc/simplify-rtx.cc:3179 0x8196e0 wi::int_traits >::get_precision(std::pair const&) /repo/gcc-trunk/gcc/rtl.h:2283 0x8196e0 unsigned int wi::get_precision >(std::pair const&) /repo/gcc-trunk/gcc/wide-int.h:2168 0x8196e0 wide_int_ref_storage::wide_int_ref_storage >(std::pair const&) /repo/gcc-trunk/gcc/wide-int.h:1089 0x8196e0 generic_wide_int >::generic_wide_int >(std::pair const&) /repo/gcc-trunk/gcc/wide-int.h:847 0x8196e0 simplify_context::simplify_binary_operation_1(rtx_code, machine_mode, rtx_def*, rtx_def*, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/simplify-rtx.cc:3338 0x14dd0ad simplify_context::simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/simplify-rtx.cc:2667 0x26c4a74 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/rtl.h:3493 0x26c4a74 fold_rtx /repo/gcc-trunk/gcc/cse.cc:3719 0x26c5ff2 canonicalize_insn /repo/gcc-trunk/gcc/cse.cc:4461 0x26c6511 cse_insn /repo/gcc-trunk/gcc/cse.cc:4544 0x26cc0e3 cse_extended_basic_block /repo/gcc-trunk/gcc/cse.cc:6574 0x26cc0e3 cse_main /repo/gcc-trunk/gcc/cse.cc:6719 0x26ccb00 rest_of_handle_cse2 /repo/gcc-trunk/gcc/cse.cc:7617 0x26ccb00 execute /repo/gcc-trunk/gcc/cse.cc:7672 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240131 (experimental) (GCC)
[Bug c/113688] verify_type fails for compatible structs with FAM in C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688 uecker at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-01-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug c/113438] ICE (segfault) in dwarf2out_decl with -g -std=c23 on c23-tag-composite-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438 uecker at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from uecker at gcc dot gnu.org --- I filed PR113688 for the verify_type failures with -g. This bug is fixed on trunk.
[Bug target/113689] New: wrong code with unused _BitInt() division with -O2 -fprofile -mcmodel=large -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689 Bug ID: 113689 Summary: wrong code with unused _BitInt() division with -O2 -fprofile -mcmodel=large -mavx Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-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: x86_64-pc-linux-gnu Created attachment 57270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57270&action=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O2 -fprofile -mcmodel=large -mavx testcase.c $ ./a.out Aborted "b" (and then "x") seems to be garbage. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-8665-20240131161256-g3fed1609f61-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240131 (experimental) (GCC)
[Bug c/113688] verify_type fails for compatible structs with FAM in C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688 uecker at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |14.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113438
[Bug c/113688] New: verify_type fails for compatible structs with FAM in C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688 Bug ID: 113688 Summary: verify_type fails for compatible structs with FAM in C23 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: uecker at gcc dot gnu.org Target Milestone: --- Extracted from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438#c1 FAIL: gcc.dg/gnu23-tag-1.c (internal compiler error: 'verify_type' failed) FAIL: gcc.dg/gnu23-tag-4.c (internal compiler error: 'verify_type' failed) FAIL: gcc.dg/gnu23-tag-alias-1.c (internal compiler error: 'verify_type' failed)
[Bug middle-end/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607 --- Comment #24 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:8123f3ca3fd891034a8366518e756f161c4ff40d commit r14-8668-g8123f3ca3fd891034a8366518e756f161c4ff40d Author: Robin Dapp Date: Tue Jan 30 18:39:08 2024 +0100 match: Fix vcond into conditional op folding [PR113607]. In PR113607 we see an invalid fold of _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0, ... }); vect_prephitmp_129.51_282 = _429; vect_iftmp.55_287 = VEC_COND_EXPR ; to Applying pattern match.pd:9607, gimple-match-10.cc:3817 gimple_simplified to vect_iftmp.55_287 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0, ... }); where we essentially use COND_SHL's else instead of VEC_COND_EXPR's. This patch adjusts the corresponding match.pd pattern and makes it only match when the else values are the same. That, however, causes the exact test case for which this pattern was introduced for to fail. Therefore XFAIL it for now. gcc/ChangeLog: PR middle-end/113607 * match.pd: Make sure else values match when folding a vec_cond into a conditional operation. gcc/testsuite/ChangeLog: * gcc.target/aarch64/sve/pre_cond_share_1.c: XFAIL. * gcc.target/riscv/rvv/autovec/pr113607-run.c: New test. * gcc.target/riscv/rvv/autovec/pr113607.c: New test.
[Bug target/53929] [meta-bug] -masm=intel with global symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #27 from Eric Gallager --- is this really a meta-bug? Normally meta-bugs depend on other bugs...
[Bug c/113492] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113492 uecker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from uecker at gcc dot gnu.org --- Fixed on trunk.
[Bug c/113438] ICE (segfault) in dwarf2out_decl with -g -std=c23 on c23-tag-composite-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438 --- Comment #6 from GCC Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:f6ba433d3c30c20fadd393eed31617a4da81789c commit r14-8666-gf6ba433d3c30c20fadd393eed31617a4da81789c Author: Martin Uecker Date: Tue Jan 23 13:33:34 2024 +0100 Fix ICE with -g and -std=c23 when forming composite types [PR113438] Set TYPE_STUB_DECL to an artificial decl when creating a new structure as a composite type. PR c/113438 gcc/c/ * c-typeck.cc (composite_type_internal): Set TYPE_STUB_DECL. gcc/testsuite/ * gcc.dg/pr113438.c: New test.
[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #10 from John David Anglin --- I hit this error in stage1 after a small change to pa.cc. It seems to have gone after updating to Debian binutils 2.42-2. I just rebuilt without any changes to gcc tree. The error occurred with binutils 2.41.90.20240122-1.
[Bug c++/113687] -Warray-bounds is not emitted inside class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113687 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Andrew Pinski --- The warning only happens if the vague linkage function is used. and IIRC that is by design.
[Bug c++/113687] New: -Warray-bounds is not emitted inside class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113687 Bug ID: 113687 Summary: -Warray-bounds is not emitted inside class method Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nmmm at nmmm dot nu Target Milestone: --- No warning -Warray-bounds is shown when code is inside class method, defined inside the class body or outside if they are inline or constexpr. struct S{ int p(){ int x[2] = {0, 0}; return x[3]; // no warning shown } static int ps(){ int x[2] = {0, 0}; return x[3]; // no warning shown } int ps2inl(); int ps2(); }; inline int S::ps2inl(){ int x[2] = {0, 0}; return x[3]; // no warning shown } int S::ps2(){ int x[2] = {0, 0}; return x[3]; // warning shown correctly } int f(){ int x[2] = {0, 0}; return x[3]; // warning shown correctly } int main(){ }
[Bug fortran/104908] [11/12/13/14 Regression] incorrect Fortran out-of-bound runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:5741e5fc53161ccf2056e0670334ea528431feb7 commit r13-8266-g5741e5fc53161ccf2056e0670334ea528431feb7 Author: Harald Anlauf Date: Sat Jan 27 17:41:43 2024 +0100 Fortran: fix bounds-checking errors for CLASS array dummies [PR104908] Commit r11-1235 addressed issues with bounds of unlimited polymorphic array dummies. However, using the descriptor from sym->backend_decl does break the case of CLASS array dummies. The obvious solution is to restrict the fix to the unlimited polymorphic case, thus keeping the original descriptor in the ordinary case. gcc/fortran/ChangeLog: PR fortran/104908 * trans-array.cc (gfc_conv_array_ref): Restrict use of transformed descriptor (sym->backend_decl) to the unlimited polymorphic case. gcc/testsuite/ChangeLog: PR fortran/104908 * gfortran.dg/pr104908.f90: New test. (cherry picked from commit ce61de1b8a1bb3a22118e900376f380768f2ba59)
[Bug analyzer/113253] gcc -g causes -fanalyzer to issue false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113253 --- Comment #2 from David Malcolm --- I'm testing a fix. The bug observably affects trunk and gcc 13.2. It it probably also present but latent on gcc 12, 11, and 10 (-Wanalyzer-deref-before-check was added in gcc 13).
[Bug target/113686] [RISC-V] TLS (Local Exec) relaxation on structures (LE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113686 palmer at gcc dot gnu.org changed: What|Removed |Added CC||nelsonc1225 at sourceware dot org, ||palmer at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-01-31 --- Comment #1 from palmer at gcc dot gnu.org --- (In reply to H. Peter Anvin from comment #0) > When the Local Exec TLS model is in use, gcc generates inefficient code for > accessing the member of a structure: > > struct foobar { >int alpha; >int beta; > }; > > _Thread_local struct foobar foo; > > void func(int bar) > { > foo.beta = bar; > } > > # Version 1 > luia1,%tprel_hi(foo) > adda1,a1,tp,%tprel_add(foo) > addi a1,a1,%tprel_lo(foo) > sw a0,4(a1) > > However, in this case it could be generated as: > > # Version 2 > luia1,%tprel_hi(sym+4) > addi a1,a1,tp,%tprel_add(sym+4) > sw a0,%tprel_lo(sym+4)(a1) > > ... which, if %tprel_hi(sym+4) == 0, as it often is for small embedded > software, the linker can relax to a simple (tp) reference: > > # Version 2a (post-relaxation with small .tbss) > sw a0,%tprel_lo(sym+4)(tp) > > The linker will *not* relax version 1 all the way; leaving an unnecessary mv: > > # Version 1a (post-relaxation with small .tbss) > mv a1,tp > sw a0,%tprel_lo(sym+4)(tp) > > It is of course trickier for the case of multiple subsequent references to > the structure if the structure is not aligned, as gcc can't know a priori > where the 4K breaks are[*]. The version 1 code is more efficient in that > case (3 instructions + 1 instruction/field as opposed to 3 > instructions/field.) > > However, if the structure *is* aligned, gcc will still not optimize 1 into 2. > > There are at least a few options I see: > > 1. gcc option: gcc can generate version 2 code for a single field reference, > or if the alignment is such that all fields are guaranteed to fall inside > the same 4K window. IIUC we could do this without adding anything to the linker or psABI, it's just better code from GCC (we already have TPREL_LO12_S for the stores). That's just better code so it seems uncontroversial to me. > 2. gcc and optional ABI option: introduce a "TLS TE-tiny" model for deep > embedded use, where the combined size of the TSS area is limited to 4K > equivalent to the way direct gp references [or zero, if the global pointer > is 0] work. Thus, direct (tp) references can be used. Unless I'm missing something, we never emit direct GP references from GCC right now. We rely on the linker to relax them. > NOTE: With the current binutils, this will error unless .option norelax is > in effect. It might be desirable to instead have a new relocation type, > which would require binutils support. Alternatively, ld should recognize > that the TLS offset is within +/- 2K and suppress the warning in that case > (since at that point the address is available the the linker.) > > The linker could be further optimized by allowing the TLS to offset; > presumably equivalently to the __global_pointer$ symbol. > > 3. binutils option: teach ld to relax these kinds of chained pointer > references. I'd favor adding support better for relaxing TP-relative sequences to the linker where we can, it avoids the need for a new code model and we've already got most of the linker complexity as it's required for GP. So I think we can essentially just call these LD missed optimizations. Nelson might be out for a bit, but I added him to the CC list. > [*] Rant: in my opinion, the lui/auipc instructions are fundamentally > misdesigned by not having an overlap bit to guarantee a sizable window. I agree we've got auipc issues, it bites us all over the place (we essentially can't share a hi* between multiple lo*s, as we don't know when overflow is going to happen). There'd been some vague proposals to add a third relocation in the chain to align things, but I think they fizzled out because it'd require talking to the psABI folks. I think we're broadly safe for lui, though, so not sure if I'm missing something there? The low bits are always 0 so the intermediate alignment is known.
[Bug target/113686] New: [RISC-V] TLS (Local Exec) relaxation on structures (LE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113686 Bug ID: 113686 Summary: [RISC-V] TLS (Local Exec) relaxation on structures (LE) Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hpa at zytor dot com Target Milestone: --- When the Local Exec TLS model is in use, gcc generates inefficient code for accessing the member of a structure: struct foobar { int alpha; int beta; }; _Thread_local struct foobar foo; void func(int bar) { foo.beta = bar; } # Version 1 luia1,%tprel_hi(foo) adda1,a1,tp,%tprel_add(foo) addi a1,a1,%tprel_lo(foo) sw a0,4(a1) However, in this case it could be generated as: # Version 2 luia1,%tprel_hi(sym+4) addi a1,a1,tp,%tprel_add(sym+4) sw a0,%tprel_lo(sym+4)(a1) ... which, if %tprel_hi(sym+4) == 0, as it often is for small embedded software, the linker can relax to a simple (tp) reference: # Version 2a (post-relaxation with small .tbss) sw a0,%tprel_lo(sym+4)(tp) The linker will *not* relax version 1 all the way; leaving an unnecessary mv: # Version 1a (post-relaxation with small .tbss) mv a1,tp sw a0,%tprel_lo(sym+4)(tp) It is of course trickier for the case of multiple subsequent references to the structure if the structure is not aligned, as gcc can't know a priori where the 4K breaks are[*]. The version 1 code is more efficient in that case (3 instructions + 1 instruction/field as opposed to 3 instructions/field.) However, if the structure *is* aligned, gcc will still not optimize 1 into 2. There are at least a few options I see: 1. gcc option: gcc can generate version 2 code for a single field reference, or if the alignment is such that all fields are guaranteed to fall inside the same 4K window. 2. gcc and optional ABI option: introduce a "TLS TE-tiny" model for deep embedded use, where the combined size of the TSS area is limited to 4K equivalent to the way direct gp references [or zero, if the global pointer is 0] work. Thus, direct (tp) references can be used. NOTE: With the current binutils, this will error unless .option norelax is in effect. It might be desirable to instead have a new relocation type, which would require binutils support. Alternatively, ld should recognize that the TLS offset is within +/- 2K and suppress the warning in that case (since at that point the address is available the the linker.) The linker could be further optimized by allowing the TLS to offset; presumably equivalently to the __global_pointer$ symbol. 3. binutils option: teach ld to relax these kinds of chained pointer references. [*] Rant: in my opinion, the lui/auipc instructions are fundamentally misdesigned by not having an overlap bit to guarantee a sizable window.
[Bug testsuite/113685] New: [14 regression] xxx fails after yyy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113685 Bug ID: 113685 Summary: [14 regression] xxx fails after yyy Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:d45ddc2c04e471d0dcee016b6edacc00b8341b16, r14-4089-gd45ddc2c04e471 make -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-117.c" FAIL: gcc.dg/vect/vect-117.c scan-tree-dump-not optimized "Invalid sum" FAIL: gcc.dg/vect/vect-117.c -flto -ffat-lto-objects scan-tree-dump-not optimized "Invalid sum" # of expected passes8 # of unexpected failures2 Note this was also reported in pr111462 but the fix for it did not fix this failure. commit d45ddc2c04e471d0dcee016b6edacc00b8341b16 (HEAD) Author: Richard Biener Date: Thu Sep 14 13:06:51 2023 +0200 tree-optimization/111294 - backwards threader PHI costing * gcc.dg/vect/vect-117.c: Make scan for not Invalid sum conditional on lp64.
[Bug c++/113674] [11/12/13/14 Regression] [[____attr____]] causes internal compiler error: in decl_attributes, at attribs.cc:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674 --- Comment #5 from Joseph S. Myers --- C supports _Noreturn (and thus ___Noreturn__) as an attribute name, so that code with "#define noreturn _Noreturn" (probably from stdnoreturn.h) works with C23 [[noreturn]].
[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402 --- Comment #7 from Jakub Jelinek --- See https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644521.html
[Bug libgcc/113402] Incorrect symbol versions for __builtin_nested_func_ptr_created, __builtin_nested_func_ptr in libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #6 from John David Anglin --- I'm now seeing: In file included from ../../../gcc/libgcc/libgcc2.c:56: ../../../gcc/libgcc/libgcc2.h:32:13: warning: conflicting types for built-in fun ction '__gcc_nested_func_ptr_created'; expected 'void(void *, void *, void *)' [ -Wbuiltin-declaration-mismatch] 32 | extern void __gcc_nested_func_ptr_created (void *, void *, void **); | ^
[Bug libstdc++/90276] PSTL tests fail in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276 --- Comment #9 from frs.dumont at gmail dot com --- Here is the reason of the 20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc FAIL. Maybe it fixes some other tests too, I need to run all of them. libstdc++: Do not forward arguments several times [PR90276] Forwarding several times the same arguments results in UB. It is detected by the _GLIBCXX_DEBUG mode as an attempt to use a singular iterator which has been moved. libstdc++-v3/ChangeLog PR libstdc++/90276 * testsuite/util/pstl/test_utils.h: Remove std::forward<> calls when done several times on the same arguments. Ok to commit ? François On 31/01/2024 14:11, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276 > > Jonathan Wakely changed: > > What|Removed |Added > > See Also||https://github.com/llvm/llv > ||m-project/issues/80136 >
[Bug target/113684] Cross compiler without assembler and linker should assume that all assembler and linker features are available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113684 --- Comment #2 from H.J. Lu --- (In reply to Andrew Pinski from comment #1) > This usecase is only for GCC developers and it might even confuse regular > users of GCC ... True, such cross compilers are only for GCC developers. Regular won't run into it.
[Bug middle-end/113682] Branches in branchless binary search rather than cmov/csel/csinc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|middle-end --- Comment #3 from Andrew Pinski --- >From the looks of it, jump threading is getting in the way of conditional move generation.
[Bug c++/113683] explicit template instantiation wrongly checks private base class accessibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113683 --- Comment #1 from Andrew Pinski --- MSVC rejects this also for the same reason: (10): error C2243: 'static_cast': conversion from 'const B *' to 'const A *' exists, but is inaccessible clang accepts it though ...
[Bug target/113684] Cross compiler without assembler and linker should assume that all assembler and linker features are available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113684 Andrew Pinski changed: What|Removed |Added Keywords||internal-improvement --- Comment #1 from Andrew Pinski --- This usecase is only for GCC developers and it might even confuse regular users of GCC ...
[Bug target/113684] Cross compiler without assembler and linker should assume that all assembler and linker features are available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113684 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/113281] [11/12/13 Regression] Latent wrong code due to vectorization of shift reduction and missing promotions since r9-1590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 Target Milestone|14.0|11.5 Summary|[14 Regression] Wrong code |[11/12/13 Regression] |due to vectorization of |Latent wrong code due to |shift reduction and missing |vectorization of shift |promotions since r14-3027 |reduction and missing ||promotions since r9-1590
[Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403 --- Comment #7 from Xi Ruoyao --- (In reply to Andreas Schwab from comment #6) > GDB disables ASLR. Indeed, with "setarch -R" it always crashes.
[Bug fortran/113503] [14 Regression] xtb test miscompilation starting with r14-870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113503 --- Comment #4 from Jakub Jelinek --- It is the PR fortran/82774 (alloc_scalar_allocatable_subcomponent): Shorten the function name and replace the symbol argument with the se string length. If a deferred length character length is either not present or is not a variable, give the typespec a variable and assign the string length to that. Use gfc_deferred_strlen to find the hidden string length component. (gfc_trans_subcomponent_assign): Convert the expression before the call to alloc_scalar_allocatable_subcomponent so that a good string length is provided. (gfc_trans_structure_assign): Remove the unneeded derived type symbol from calls to gfc_trans_subcomponent_assign. part of the changes that cause this, reverting those hunks (had to revert one manually as tree size; declaration has been added there later) makes the testcase not warn anymore or in the other case not ICE anymore.
[Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403 --- Comment #6 from Andreas Schwab --- GDB disables ASLR.
Enclosed is a voice message for your reference 835-477-0103 - GCC
Time: 1/31/2024 5:13 PM Message length is 0:19 secs
[Bug target/113618] [14 Regression] AArch64: memmove idiom regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618 Wilco changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org --- Comment #4 from Wilco --- (In reply to Alex Coplan from comment #1) > Confirmed. > > (In reply to Wilco from comment #0) > > A possible fix would be to avoid emitting LDP/STP in memcpy/memmove/memset > > expansions. > > Yeah, so I had posted > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636855.html for that > but held off from committing it at the time as IMO there wasn't enough > evidence to show that this helps in general (and the pass could in theory > miss opportunities which would lead to regressions). > > But perhaps this is a good argument for going ahead with that change (of > course it will need rebasing). Yes I have a patch based on current trunk + my outstanding memset cleanup patch. It's slightly faster but causes a small codesize regression. This appears mostly due to GCC being overly aggressive in changing loads/stores with a zero offset into indexing, a non-zero offset or a lo_sym. This not only blocks LDP opportunities but also increases register pressure and spilling.
[Bug modula2/111627] modula2: Excess test fails with a case-preserving-case-insensitive source tree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111627 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Gaius Mulley --- Bootstrapped on a jfs case-preserving-case-insensitive gnu-linux system. All regressions pass. Optimistically closing the PR.
[Bug c++/113674] [11/12/13/14 Regression] [[____attr____]] causes internal compiler error: in decl_attributes, at attribs.cc:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674 --- Comment #4 from Marek Polacek --- Note that [[pure]] int g (int i) { return i; } doesn't crash: pure isn't a standard attribute. The crash seems to occur only with an attribute that is registered twice: the GNU version and the standard version.
[Bug rtl-optimization/113682] Branches in branchless binary search rather than cmov/csel/csinc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682 --- Comment #2 from Andrew Pinski --- I should note that on x86, 2 cmov in a row might be an issue and worse than branches. There is a cost model and the x86 backend rejects that. There are some cores where it is worse. I don't know if it applies to recent ones though.
[Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403 --- Comment #5 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #4) > After r14-5545 this issue became latent. > > And at some point before r14-5545 this issue became nondeterministic: a > compiled program *sometimes* crashes. Really strange... At r14-5544, if running the compiled program in GDB it *always* crash, but if directly running it it *sometimes* crash. What's the difference between GDB or not?!
[Bug target/111403] LoongArch: Wrong code with -O -mlasx -fopenmp-simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111403 --- Comment #4 from Xi Ruoyao --- After r14-5545 this issue became latent. And at some point before r14-5545 this issue became nondeterministic: a compiled program *sometimes* crashes. Really strange...
[Bug c++/113674] [11/12/13/14 Regression] [[____attr____]] causes internal compiler error: in decl_attributes, at attribs.cc:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Maybe we shouldn't canonicalize attribute names like this, because they can be then canonicalized multiple times, each time removing the __ and __ pair from it and so could lead to inconsistencies. Now, no standard nor supported attribute name starts with _, so perhaps it could be even just punt if it is prefixed with ___ instead of __ (though, guess one can use -Wno-attributes=something::_foo ).
[Bug analyzer/113253] gcc -g causes -fanalyzer to issue false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113253 David Malcolm changed: What|Removed |Added Last reconfirmed||2024-01-31 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug analyzer/113253] gcc -g causes -fanalyzer to issue false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113253 --- Comment #1 from David Malcolm --- Created attachment 57268 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57268&action=edit Reduced reproducer Thanks for filing this bug. The attached is a simplified reproducer on trunk, with: -fanalyzer -O2 -g (emits warning) -fanalyzer O2 (doesn't emit warning) Also reproduced at: https://godbolt.org/z/dzeo3c6KP using -g0 for the latter, since I think godbolt is injecting a -g. I'm investigating.
[Bug target/113684] New: Cross compiler without assembler and linker should assume that all assembler and linker features are available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113684 Bug ID: 113684 Summary: Cross compiler without assembler and linker should assume that all assembler and linker features are available Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- When configuring GCC with --target=TARGET to build a cross compiler to reproduce a compiler bug, as and collect have ORIGINAL_AS_FOR_TARGET="" ORIGINAL_LD_FOR_TARGET="" As the result, many target features are disabled which makes it almost impossible to reproduce the bug. When there are no as nor ld, the compiler build isn't a working build. In this case, configure can assume that all assembler and linker features are available so that the partially built cross compiler can be used to reproduce the bug.
[Bug c++/113674] [11/12/13/14 Regression] [[____attr____]] causes internal compiler error: in decl_attributes, at attribs.cc:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674 --- Comment #2 from Marek Polacek --- [[maybe_unused]] int g (int i) { return i; } crashes in cc1plus since r8-2418-g577eec56569258 which is probably the real culprit: commit 577eec5656925889d99c658de2a54ba8bd3ebf79 Author: Martin Liska Date: Mon Aug 7 10:37:07 2017 +0200 Canonicalize names of attributes.
[Bug target/113679] long long minus double with gcc -m32 produces different results than other compilers or gcc -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679 --- Comment #11 from Jakub Jelinek --- Anyway, seems clang is buggy: clang -O2 -m32 -mno-sse -mfpmath=387 -fexcess-precision=standard #include int main () { #if FLT_EVAL_METHOD == 2 && LDBL_MANT_DIG == 64 && DBL_MANT_DIG == 53 if ((double) 191.18831051580915 == 191.18831051580915) __builtin_abort (); #endif } should always succeed, because if FLT_EVAL_METHOD is 2, it ought to be evaluated as (long double) (double) 191.18831051580915L == 191.18831051580915L and (double) 191.18831051580915L is 0x1.7e606a3c65c95p+7 while 191.18831051580915L is 0x1.7e606a3c65c9503ap+7L, so they aren't equal.
[Bug c++/112737] [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #7 from Patrick Palka --- (In reply to Patrick Palka from comment #6) > Perhaps we need to relax structural_comptypes in this case. I guess I can submit a patch to that effect.
[Bug modula2/111627] modula2: Excess test fails with a case-preserving-case-insensitive source tree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111627 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:4fd094835a8997cdcc3d18d7d297debe1527202d commit r14-8663-g4fd094835a8997cdcc3d18d7d297debe1527202d Author: Gaius Mulley Date: Wed Jan 31 15:44:32 2024 + PR modula2/111627 Excess test fails with a case-preserving-case-insensitive source tree This patch renames gm2 testsuite modules whose names conflict with library modules. The conflict is not seen on case preserving case sensitive file systems. gcc/testsuite/ChangeLog: PR modula2/111627 * gm2/pim/pass/stdio.mod: Moved to... * gm2/pim/pass/teststdio.mod: ...here. * gm2/pim/run/pass/builtins.mod: Moved to... * gm2/pim/run/pass/testbuiltins.mod: ...here. * gm2/pim/run/pass/math.mod: Moved to... * gm2/pim/run/pass/testmath.mod: ...here. * gm2/pim/run/pass/math2.mod: Moved to... * gm2/pim/run/pass/testmath2.mod: ...here. Signed-off-by: Gaius Mulley
[Bug c++/112737] [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737 --- Comment #6 from Patrick Palka --- Ah, this seems to be a general declaration matching issue not specific to modules. Here's a non-modules testcase: template class TT, class T> decltype(TT{T()}) f(); // #1 template class TT, class T> decltype(TT{T()}) f(); // #2, should be considered a redeclaration of #1 template struct A { A(T); }; int main() { f(); // ambiguity error } We (wrongly?) consider the return types of the two f's to be different, because the CTAD placeholders refer to different TEMPLATE_DECLs (of a logically equivalent ttp) and structural_comptypes uses pointer identity here. Perhaps we need to relax structural_comptypes in this case.
[Bug c++/113683] New: explicit template instantiation wrongly checks private base class accessibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113683 Bug ID: 113683 Summary: explicit template instantiation wrongly checks private base class accessibility Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: schaumb at gmail dot com Target Milestone: --- The compiler wrongly checks that the (private) base class is accessible when explicit template instantiation happens. (standard: C++20) It shouldn't, see https://eel.is/c++draft/temp.spec#general-6 template struct I{}; struct A {}; class B : A { static const B b; }; I need to instantiate the B::b object address with const A*. But this line is failing: template struct I(&B::b)>; // fails on static_cast Simplified "real" example code: https://godbolt.org/z/zj9co5bMh
[Bug middle-end/113680] Missed optimization: Redundant cmp/test instructions when comparing (x - y) > 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680 --- Comment #3 from Kang-Che Sung --- Oops. I made a typo in the test code. func4() shouldn't have that redundant brace. The corrected example: ``` void func4(int x, int y) { int diff = x - y; if (diff > 0) putchar('>'); if (x < y) putchar('<'); } ```
[Bug c++/106052] ICE with -Wmismatched-tags with partially specialized friend struct of self type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106052 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Started with r10-7424-g04dd734b52de12: commit 04dd734b52de121853e1ea6b3c197a598b294e23 Author: Martin Sebor Date: Fri Mar 27 12:07:45 2020 -0400 c++: avoid -Wredundant-tags on a first declaration in use [PR 93824]
[Bug c++/112737] [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737 --- Comment #5 from Patrick Palka --- Reduced: $ cat 112737.h template class _Cont> using _DeduceExpr1 = decltype(_Cont{}); $ cat 112737_a.H #include "112737.h" $ cat 112737_b.C import "112737_a.H"; #include "112737.h" $ g++ -fmodules-ts 112737_a.H 112737_b.C In file included from 112737_b.C:2: 112737.h:2:7: error: conflicting declaration of template ‘template class _Cont> using _DeduceExpr1 = decltype (_Cont<...auto...>{})’ 2 | using _DeduceExpr1 = decltype(_Cont{}); | ^~~~ In file included from 112737_a.H:1, of module ./112737_a.H, imported at 112737_b.C:1: 112737.h:2:7: note: previous declaration ‘template class _Cont> using _DeduceExpr1 = decltype (_Cont<...auto...>{})’ 2 | using _DeduceExpr1 = decltype(_Cont{}); | ^~~~
[Bug testsuite/113502] gcc.target/aarch64/vect-early-break-cbranch.c and gcc.target/aarch64/sve/vect-early-break-cbranch.c testcase are too sensitive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113502 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED CC||tnfchris at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Tamar Christina --- Fixed, thanks
[Bug sanitizer/112644] [14 Regression] Some of the hwasan testcase fail after the recent merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644 Tamar Christina changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Tamar Christina --- Fixed. Thanks
[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=112737 CC||ppalka at gcc dot gnu.org --- Comment #7 from Patrick Palka --- The xtreme-header-{4,5,6} fails need -mx32 (rather than -m32) on x86_64-linux. The error is: .../x86_64-pc-linux-gnu/libstdc++-v3/include/format:3662:28: error: invalid use of non-static data member ‘std::basic_format_args, wchar_t> >::__as_base ::’ 3662 | __arg._M_val = _M_values[__i]; |^ The xtreme-header{,2} fails are also tracked by PR112737, and the error on x86_64-linux is: /src/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: error: conflicting global module declaration 'template class _Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr1 = decltype (_Cont<...auto...>(declval<_Rg>(), (declval<_Args>)()...))' ...
[Bug testsuite/113502] gcc.target/aarch64/vect-early-break-cbranch.c and gcc.target/aarch64/sve/vect-early-break-cbranch.c testcase are too sensitive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113502 --- Comment #2 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:f7935beef7b02fbba0adf33fb2ba5c0a27d7e9ff commit r14-8662-gf7935beef7b02fbba0adf33fb2ba5c0a27d7e9ff Author: Tamar Christina Date: Wed Jan 31 14:52:59 2024 + AArch64: relax cbranch tests to accepted inverted branches [PR113502] Recently something in the midend had started inverting the branches by inverting the condition and the branches. While this is fine, it makes it hard to actually test. In RTL I disable scheduling and BB reordering to prevent this. But in GIMPLE there seems to be nothing I can do. __builtin_expect seems to have no impact on the change since I suspect this is happening during expand where conditions can be flipped regardless of probability during compare_and_branch. Since the mid-end has plenty of correctness tests, this weakens the backend tests to just check that a correct looking sequence is emitted. gcc/testsuite/ChangeLog: PR testsuite/113502 * gcc.target/aarch64/sve/vect-early-break-cbranch.c: Ignore exact branch. * gcc.target/aarch64/vect-early-break-cbranch.c: Likewise.
[Bug sanitizer/112644] [14 Regression] Some of the hwasan testcase fail after the recent merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644 --- Comment #11 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:0a640455928a050315f6addd88ace5d945eba130 commit r14-8661-g0a640455928a050315f6addd88ace5d945eba130 Author: Tamar Christina Date: Wed Jan 31 14:51:36 2024 + hwasan: Remove testsuite check for a complaint message [PR112644] With recent updates to hwasan runtime libraries, the error reporting for this particular check is has been reworked. I would question why it has lost this message. To me it looks strange that num_descriptions_printed is incremented whenever we call PrintHeapOrGlobalCandidate whether that function prints anything or not. (See PrintAddressDescription in libsanitizer/hwasan/hwasan_report.cpp). The message is no longer printed because we increment this num_descriptions_printed variable indicating that we have found some description. I would like to question this upstream, but it doesn't look that much of a problem and if pressed for time we should just change our testsuite. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. gcc/testsuite/ChangeLog: PR sanitizer/112644 * c-c++-common/hwasan/hwasan-thread-clears-stack.c: Update testcase.