[Bug target/111366] error: inlining failed in call to 'always_inline' 'hwy::PreventElision(int&)void': target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366 --- Comment #19 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:a65b38e361320e0aa45adbc969c704385ab1f45b commit r14-4247-ga65b38e361320e0aa45adbc969c704385ab1f45b Author: Kewen Lin Date: Mon Sep 25 00:28:19 2023 -0500 rs6000: Skip empty inline asm in rs6000_update_ipa_fn_target_info [PR111366] PR111366 exposes one thing that can be improved in function rs6000_update_ipa_fn_target_info is to skip the given empty inline asm string, since it's impossible to adopt any hardware features (so far HTM). Since this rs6000_update_ipa_fn_target_info related approach exists in GCC12 and later, the affected project highway has updated its target pragma with ",htm", see the link: https://github.com/google/highway/commit/15e63d61eb535f478bc I'd not bother to consider an inline asm parser for now but will file a separated PR for further enhancement. PR target/111366 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_update_ipa_fn_target_info): Skip empty inline asm. gcc/testsuite/ChangeLog: * g++.target/powerpc/pr111366.C: New test.
[Bug target/111380] Inconsistent behaviors between non-LTO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111380 --- Comment #1 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:266dfed68b881702e9660889f63408054b7fa9c0 commit r14-4246-g266dfed68b881702e9660889f63408054b7fa9c0 Author: Kewen Lin Date: Mon Sep 25 00:27:59 2023 -0500 rs6000: Use default target option node for callee by default [PR111380] As PR111380 (and the discussion in related PRs) shows, for now how function rs6000_can_inline_p treats the callee without any target option node is wrong. It considers it's always safe to inline this kind of callee, but actually its target flags are from the command line options (target_option_default_node), it's possible that the flags of callee don't satisfy the condition of inlining, but it is still inlined, then result in unexpected consequence. As the associated test case pr111380-1.c shows, the caller main is attributed with power8, but the callee foo is compiled with power9 from command line, it's unexpected to make main inline foo since foo can contain something that requires power9 capability. Without this patch, for lto (with -flto) we can get error message (as it forces the callee to have a target option node), but for non-lto, it's inlined unexpectedly. This patch is to make callee adopt target_option_default_node when it doesn't have a target option node, it can avoid wrong inlining decision and fix the inconsistency between LTO and non-LTO. It also aligns with what the other ports do. PR target/111380 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_can_inline_p): Adopt target_option_default_node when the callee has no option attributes, also simplify the existing code accordingly. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr111380-1.c: New test. * gcc.target/powerpc/pr111380-2.c: New test.
[Bug target/111581] New: [arm-none-eabi-gcc] / suboptimal optimization /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111581
Bug ID: 111581
Summary: [arm-none-eabi-gcc] / suboptimal optimization /
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cptarse-luke at yahoo dot com
Target Milestone: ---
it seems like, i should have filed this separately:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111500
i think the uxth/sxth is superfluous here,
since nobody ever looks at the high half word...
> arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/9.3.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --disable-decimal-float --disable-libffi
--disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libstdcxx-pch --disable-libstdc__-v3 --disable-nls --disable-shared
--disable-threads --disable-tls --disable-werror --enable-__cxa_atexit
--enable-c99 --enable-gnu-indirect-function --enable-interwork
--enable-languages=c,c++ --enable-long-long --enable-multilib --enable-plugins
--host= --libdir=/usr/lib --libexecdir=/usr/lib --prefix=/usr
--target=arm-none-eabi --with-gmp --with-gnu-as --with-gnu-ld
--with-headers=/usr/arm-none-eabi/include --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-isl --with-libelf --with-mpc
--with-mpfr --with-multilib-list=rmprofile
--with-native-system-header-dir=/include --with-newlib
--with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/usr/arm-none-eabi
--with-system-zlib
Thread model: single
gcc version 9.3.0 (GCC)
> arm-none-eabi-gcc -save-temps -S a.c -O3 -g -mcpu=cortex-m0plus -mthumb -Wall
> --specs=nosys.specs -nostdlib -fdata-sections -ffunction-sections
> -ffreestanding -Winline
> cat a.i
# 1 "a.c"
# 1 "/tmp//"
# 1 ""
# 1 ""
# 1 "a.c"
void artiSXTH(volatile short * a) {
short b = *a;
*a = b;
}
> cat a.s
artiSXTH:
ldrhr3, [r0]
sxthr3, r3
strhr3, [r0]
bx lr
[Bug target/111580] New: [arm-none-eabi-gcc] / suboptimal optimization / b.n to bx lr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111580
Bug ID: 111580
Summary: [arm-none-eabi-gcc] / suboptimal optimization / b.n to
bx lr
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cptarse-luke at yahoo dot com
Target Milestone: ---
it seems like, i should have filed this separately:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111500
i feel like gcc should output a "bx lr" instead of a jump ("b .L1") to a "bx
lr"...
the file "a.i" is:
# 1 "a.c"
# 1 "/tmp//"
# 1 ""
# 1 ""
# 1 "a.c"
int artiBN2BX(int a, int b) {
if (a arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/9.3.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --disable-decimal-float --disable-libffi
--disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libstdcxx-pch --disable-libstdc__-v3 --disable-nls --disable-shared
--disable-threads --disable-tls --disable-werror --enable-__cxa_atexit
--enable-c99 --enable-gnu-indirect-function --enable-interwork
--enable-languages=c,c++ --enable-long-long --enable-multilib --enable-plugins
--host= --libdir=/usr/lib --libexecdir=/usr/lib --prefix=/usr
--target=arm-none-eabi --with-gmp --with-gnu-as --with-gnu-ld
--with-headers=/usr/arm-none-eabi/include --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-isl --with-libelf --with-mpc
--with-mpfr --with-multilib-list=rmprofile
--with-native-system-header-dir=/include --with-newlib
--with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/usr/arm-none-eabi
--with-system-zlib
Thread model: single
gcc version 9.3.0 (GCC)
> arm-none-eabi-gcc -save-temps -S a.c -O3 -g -mcpu=cortex-m0plus -mthumb -Wall
> --specs=nosys.specs -nostdlib -fdata-sections -ffunction-sections
> -ffreestanding -Winline
> cat a.s
artiBN2BX:
cmp r0, r1
blt .L5
mulsr0, r1
.L1:bx lr
.L5:addsr0, r0, r1
b .L1
[Bug target/111500] [arm-none-eabi-gcc] / suboptimal optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111500
--- Comment #4 from Luke ---
the a.i file for example #1a is:
# 1 "a.c"
# 1 "/tmp//"
# 1 ""
# 1 ""
# 1 "a.c"
void artiSUBS() {
for (int i=100; i>0; i--)
*(volatile int*)0xE000E014 = i;
}
the command-line was:
> arm-none-eabi-gcc -save-temps -S a.c -O3 -g -mcpu=cortex-m0plus -mthumb -Wall
> --specs=nosys.specs -nostdlib -fdata-sections -ffunction-sections
> -ffreestanding -Winline
and the resulting a.s file contains that subs/cmp sequence...
[Bug target/111500] [arm-none-eabi-gcc] / suboptimal optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111500 --- Comment #3 from Luke --- maybe i should also say the "-v" output? > arm-none-eabi-gcc -v Using built-in specs. COLLECT_GCC=arm-none-eabi-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/9.3.0/lto-wrapper Target: arm-none-eabi Configured with: ../configure --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-libstdc__-v3 --disable-nls --disable-shared --disable-threads --disable-tls --disable-werror --enable-__cxa_atexit --enable-c99 --enable-gnu-indirect-function --enable-interwork --enable-languages=c,c++ --enable-long-long --enable-multilib --enable-plugins --host= --libdir=/usr/lib --libexecdir=/usr/lib --prefix=/usr --target=arm-none-eabi --with-gmp --with-gnu-as --with-gnu-ld --with-headers=/usr/arm-none-eabi/include --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-isl --with-libelf --with-mpc --with-mpfr --with-multilib-list=rmprofile --with-native-system-header-dir=/include --with-newlib --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/usr/arm-none-eabi --with-system-zlib Thread model: single gcc version 9.3.0 (GCC)
[Bug ada/111579] New: gnatpp error at start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111579 Bug ID: 111579 Summary: gnatpp error at start Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: thiebauddick2 at aol dot com CC: dkm at gcc dot gnu.org Target Milestone: --- dick@dick1:~/src$ gnatpp cursor.adb >prt gnat1: warning: unrecognized gcc debugging option: u gnat1: warning: unrecognized gcc debugging option: m gnat1: warning: unrecognized gcc debugging option: b gnat1: warning: unrecognized gcc debugging option: s gnat1: warning: unrecognized gcc debugging option: e gnat1: warning: unrecognized gcc debugging option: - gnat1: warning: unrecognized gcc debugging option: e gnat1: warning: unrecognized gcc debugging option: t gnat1: you must provide one source file gnatpp: cannot compile "cursor.adb" cursor.adb builds successfully with gnatmake gnat version 10.5.0
[Bug ada/111578] New: GNAT ada.textio.setline gives incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111578
Bug ID: 111578
Summary: GNAT ada.textio.setline gives incorrect result
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: thiebauddick2 at aol dot com
CC: dkm at gcc dot gnu.org
Target Milestone: ---
building the following program with gnatmake:
with ada.text_io; use ada.text_io;
procedure Cursor is
begin
Put(ASCII.ESC & "[2J" & ASCII.ESC & "[;H");
set_col(1);
set_line(6);
put ("");
set_col(1);
set_line(7);
put ("");
set_col(3);
set_line(5);
put ("");
end Cursor;
Gives the result:
It should give the result
b
GNAT 10.5.0 on Linux Mint 21.2
[Bug target/111533] [14 Regression] ICE: RTL check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111533 xuli1 at eswincomputing dot com changed: What|Removed |Added CC||xuli1 at eswincomputing dot com --- Comment #1 from xuli1 at eswincomputing dot com --- Hi, Patrick, I can't reproduce your problem, my steps are as follows: cd riscv_gnu_toolchian ../configure --with-arch=rv64gc --with-abi=lp64d --enable-multilib --enable-gcc-checking=rtl make -j32 Am I doing the right thing?
[Bug middle-end/111576] gcc generates conditional branch for bitwise "&"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576 --- Comment #5 from Paul Eggert --- (In reply to Andrew Pinski from comment #4) > >111715 > > That is not a valid bug # either. Sorry, I meant Bug 111575.
[Bug middle-end/111577] -Os gives significantly bigger code than -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111577 --- Comment #2 from Andrew Pinski --- I suspect you forgot to count the other functions which get emitted here. And you are just counting the size of main but that is wrong really. Anyways the overall size of the executable's text section is smaller at -Os which is the point.
[Bug middle-end/111577] -Os gives significantly bigger code than -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111577 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Andrew Pinski --- [apinski@xeond2 gcc]$ ~/upstream-gcc/bin/g++ -Os -std=c++2b -march=skylake -m64 t.cc [apinski@xeond2 gcc]$ size -A a.out a.out : section size addr .interp28 4195096 .note.gnu.property 32 4195128 .note.ABI-tag 32 4195160 .hash 76 4195192 .gnu.hash 52 4195272 .dynsym 336 4195328 .dynstr 494 4195664 .gnu.version 28 4196158 .gnu.version_r144 4196192 .rela.dyn 48 4196336 .rela.plt 192 4196384 .init 27 4198400 .plt 144 4198432 .text1341 4198576 .fini 13 4199920 .rodata99 4202496 .eh_frame_hdr 92 4202596 .eh_frame 440 4202688 .gcc_except_table 29 4203128 .init_array 8 4210128 .fini_array 8 4210136 .dynamic 528 4210144 .got 16 4210672 .got.plt 88 4210688 .data 16 4210776 .bss8 4210792 .comment 108 0 .gnu.build.attributes7368 4218992 Total 11795 [apinski@xeond2 gcc]$ ~/upstream-gcc/bin/g++ -O0 -std=c++2b -march=skylake -m64 t.cc [apinski@xeond2 gcc]$ size -A a.out a.out : section size addr .interp28 4195096 .note.gnu.property 32 4195128 .note.ABI-tag 32 4195160 .hash 368 4195192 .gnu.hash 356 4195560 .dynsym 1272 4195920 .dynstr 3067 4197192 .gnu.version 106 4200260 .gnu.version_r176 4200368 .rela.dyn 48 4200544 .rela.plt 264 4200592 .init 27 4202496 .plt 192 4202528 .text6162 4202720 .fini 13 4208884 .rodata 106 4210688 .eh_frame_hdr 548 4210796 .eh_frame2276 4211344 .gcc_except_table 85 4213620 .init_array 8 4218320 .fini_array 8 4218328 .dynamic 528 4218336 .got 16 4218864 .got.plt 112 4218880 .data 16 4218992 .bss8 4219008 .comment 108 0 .gnu.build.attributes7368 4227208 Total 23330 For me on the trunk with the correct output -Os is smaller. 1341 vs 6162 for the text size.
[Bug c++/111577] New: -Os gives significantly bigger code than -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111577
Bug ID: 111577
Summary: -Os gives significantly bigger code than -O0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: socketpair at gmail dot com
Target Milestone: ---
Yes, I saw #35806, #41175 and others.
See https://godbolt.org/z/Pnh89Y3Yb
```
#include
using namespace std;
int main(int argc, char* argv[]) {
if (argv[0] == nullptr || argv[1] == nullptr) return 0;
string zxc(argv[0]);
string qwe(argv[1]);
string asd(argv[2]);
zxc = qwe + asd;
return zxc.size();
}
```
-Os -std=c++2b -march=skylake -m64 (615 bytes)
compare size with the smae, but with options:
-O0 -std=c++2b -march=skylake -m64 (409 bytes)
-O0 - is much LESS (!) in bytes. I think it's a bug.
[Bug tree-optimization/111285] vector ABSU is lowered incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111285 --- Comment #3 from Andrew Pinski --- Created attachment 55985 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55985=edit Patch which fixes the issue I am not sure this is the best patch but we don't pass down 2 inner types into do_unop (or a different version of this).
[Bug tree-optimization/110386] [11/12/13/14 Regression] ICE with ABSU in backprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110386 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/631257.html --- Comment #7 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631257.html
[Bug middle-end/111576] gcc generates conditional branch for bitwise "&"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576 --- Comment #4 from Andrew Pinski --- >111715 That is not a valid bug # either.
[Bug middle-end/79045] bool expanded as 2 jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79045 Andrew Pinski changed: What|Removed |Added CC||eggert at cs dot ucla.edu --- Comment #6 from Andrew Pinski --- *** Bug 111576 has been marked as a duplicate of this bug. ***
[Bug middle-end/111576] gcc generates conditional branch for bitwise "&"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 79045. *** This bug has been marked as a duplicate of bug 79045 ***
[Bug middle-end/111576] gcc generates conditional branch for bitwise "&"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |middle-end Target||x86_64 --- Comment #2 from Andrew Pinski --- There is a dup of this bug.
[Bug ada/111434] [13/14 regression] infinite loop with limited with clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111434 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Investigating.
[Bug tree-optimization/111576] gcc generates conditional branch for bitwise "&"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576 --- Comment #1 from Paul Eggert --- Created attachment 55984 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55984=edit Generated assembly language for the program
[Bug tree-optimization/111576] New: gcc generates conditional branch for bitwise "&"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111576 Bug ID: 111576 Summary: gcc generates conditional branch for bitwise "&" Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: eggert at cs dot ucla.edu Target Milestone: --- Created attachment 55983 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55983=edit source code for branch-free test for "." or ".." Although this is low prioriy for me, I thought I'd mention it in case it would help GCC optimize better for others. I looked into implementing a test for "." or ".." that was branch free. In other words, implement "strcmp (p, ".") == 0 || strcmp (p, "..") == 0" without using conditional branches. I came up with an expression that should do this, but GCC translates a bitwise "&" into code that involves conditional branches. Normally I would think conditional branches would be better avoided for bitwise "&". To see the situation, compile the attached program t.c with 'gcc -O2 -S t.c' using gcc (GCC) 13.2.1 20230728 (Red Hat 13.2.1-1). It generates the attached assembly language output t.s. The code generated for 'f' contains two conditional branches, even though the source uses '&'. Furthermore, the generated code evaluates the more complicated side of the '&' first, to see whether it should evaluate the easy part, and this is not likely to be faster than just evaluating the whole thing. The code generated for the logically equivalent function 'g' is branch free, but g's source code is trickier as it substitutes "~+!!" for plain "!". (The "+" is present to work around GCC bug 111715.)
[Bug ada/111434] [13/14 regression] infinite loop with limited with clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111434 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2023-09-24 Summary|Infinite loop with limited |[13/14 regression] infinite |withs? |loop with limited with ||clauses Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Confirmed, it's an assertion failure on the mainline: eric@fomalhaut:~/build/gcc/native/tmp>gcc -c pyside6-qtcore.adb +===GNAT BUG DETECTED==+ | 14.0.0 20230918 (experimental) [master r14-4085-g93996cfb308] (x86_64-suse-linux) | | Assert_Failure sem_ch10.adb:5305 | | Error detected at pyside6-qtcore-qtmsgtype.ads:2:23 | | Compiling pyside6-qtcore.adb |
[Bug ada/111433] bogus error about null exclusion with mix of anonymous and named access types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111433 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-09-24 Summary|Erroneous message "error: |bogus error about null |null exclusion for "O" does |exclusion with mix of |not match" |anonymous and named access ||types Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- Strange indeed, but at least the workaround is trivial.
[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13 since r13-7813-gb96e66fd4ef3e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111528 --- Comment #3 from Richard Sandiford --- This was the problem that g:10d59b802a7db9ae908291fb20627c1493cfa26c fixed. I wasn't sure it was worth backporting because it only triggers for out-of-bounds array accesses, or uninitialised Fortran array indices.
[Bug c/111575] New: -Wbool-operation mistakenly warns about an int operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111575
Bug ID: 111575
Summary: -Wbool-operation mistakenly warns about an int
operation
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at cs dot ucla.edu
Target Milestone: ---
Compile the following with 'gcc -Wall -O2 -S u.c' (gcc (GCC) 13.2.1 20230728
(Red Hat 13.2.1-1 on x86-64):
int
f (int x)
{
return ~((int) !x);
}
It generate the following false positive:
u.c: In function ‘f’:
u.c:4:10: warning: ‘~’ on a boolean expression [-Wbool-operation]
4 | return ~((int) !x);
| ^
u.c:4:10: note: did you mean to use logical not?
4 | return ~((int) !x);
| ^
| !
The expression is an int expression, not a bool expression, so it should not be
warned about.
I put in the cast to pacify GCC's false alarm but the cast didn't work.
[Bug c++/111569] Problem finding in Library functions with parametres: 32, 8 , 32 Bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111569 Hans-Jürgen Herbert changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Hans-Jürgen Herbert --- Sorry.
[Bug target/111556] OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556 --- Comment #3 from Silvio Traversaro --- Thanks for the quick reply! I imagined something like that, but I preferred anyhow to have a clear bug on the libgomp so that I can refer to it and for other people that could encounter this behavior. Feel free to close as WONTFIX, thanks again!
[Bug middle-end/111574] [14 Regression] Illegal instruction with "-O3 -fno-toplevel-reorder -fno-tree-bit-ccp -fno-tree-dce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574 --- Comment #6 from Andrew Pinski --- What is happening is: ``` if (_1 != 0) goto ; [INV] else goto ; [INV] : _28 = (uint8_t) _1; // predicted unlikely by early return (on trees) predictor. goto ; [INV] : _7 = func_34 (0); : # _17 = PHI <_28(6), 0(7)> ``` Is being converted into: ``` if (_1 != 0) goto ; [INV] else goto ; [INV] : // predicted unlikely by early return (on trees) predictor. goto ; [INV] : _7 = func_34 (0); : # _new = PHI <_1(6), 0(7)> _17 = (uint8_t) _new; ``` And then incorrectly into: ``` _7 = func_34 (0); _17 = (uint8_t) _1; ``` Removing the if statement. The same way as the other bug is being incorrectly handled too.
[Bug tree-optimization/111469] [14 Regression] Wrong code at -Os on x86_64-linux-gnu since r14-573-g69f1a8af45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111469 Andrew Pinski changed: What|Removed |Added CC||19373742 at buaa dot edu.cn --- Comment #7 from Andrew Pinski --- *** Bug 111574 has been marked as a duplicate of this bug. ***
[Bug middle-end/111574] [14 Regression] Illegal instruction with "-O3 -fno-toplevel-reorder -fno-tree-bit-ccp -fno-tree-dce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- Dup of bug 111469. That is the patch which fixes PR 111469 will fix this one too. *** This bug has been marked as a duplicate of bug 111469 ***
[Bug middle-end/111574] [14 Regression] Illegal instruction with "-O3 -fno-toplevel-reorder -fno-tree-bit-ccp -fno-tree-dce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- This is another phiopt issue ...
[Bug c++/99631] decltype of non-type template-parameter shouldn't be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631 --- Comment #14 from danakj at orodu dot net --- Thank you =)
[Bug ada/88610] ICE with new ACATS test c452003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88610 Eric Botcazou changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #5 from Eric Botcazou --- .
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 108736, which changed state. Bug 108736 Summary: [concepts] multidimensional subscript operator inside requires with variable template arguments is broken https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108736 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/108736] [concepts] multidimensional subscript operator inside requires with variable template arguments is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108736 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- dup of the recently fixed PR111493 *** This bug has been marked as a duplicate of bug 111493 ***
[Bug c++/111493] [concepts] multidimensional subscript operator inside requires is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111493 Patrick Palka changed: What|Removed |Added CC||ldalessandro at gmail dot com --- Comment #6 from Patrick Palka --- *** Bug 108736 has been marked as a duplicate of this bug. ***
[Bug c++/111493] [concepts] multidimensional subscript operator inside requires is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111493 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.3 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed for GCC 13.3 / 14, thanks for the bug report.
[Bug c++/99631] decltype of non-type template-parameter shouldn't be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |13.3 Resolution|--- |FIXED --- Comment #13 from Patrick Palka --- Fixed for GCC 13.3 / 14.
[Bug c++/111493] [concepts] multidimensional subscript operator inside requires is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111493 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:40d2dec34b58c3c31b1c731049a914204ec252c3 commit r13-7837-g40d2dec34b58c3c31b1c731049a914204ec252c3 Author: Patrick Palka Date: Fri Sep 22 06:27:48 2023 -0400 c++: missing SFINAE in grok_array_decl [PR111493] We should guard both the diagnostic and backward compatibilty fallback code with tf_error, so that in a SFINAE context we don't issue any diagnostics and correctly treat ill-formed C++23 multidimensional subscript operator expressions as such. PR c++/111493 gcc/cp/ChangeLog: * decl2.cc (grok_array_decl): Guard diagnostic and backward compatibility fallback code paths with tf_error. gcc/testsuite/ChangeLog: * g++.dg/cpp23/subscript15.C: New test. (cherry picked from commit 1fea14def849dd38b098b0e2d54e64801f9c1f43)
[Bug c++/111485] [11/12/13/14 Regression] Constraint mismatch on template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111485 --- Comment #3 from CVS Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:59f5786c20a42be13ac6fec567ffe840045012ad commit r13-7836-g59f5786c20a42be13ac6fec567ffe840045012ad Author: Patrick Palka Date: Fri Sep 22 06:25:49 2023 -0400 c++: constraint rewriting during ttp coercion [PR111485] In order to compare the constraints of a ttp with that of its argument, we rewrite the ttp's constraints in terms of the argument template's template parameters. The substitution to achieve this currently uses a single level of template arguments, but that never does the right thing because a ttp's template parameters always have level >= 2. This patch fixes this by including the outer template arguments in the substitution, which ought to match the depth of the ttp. The second testcase demonstrates it's better to substitute the concrete outer template arguments instead of generic ones since a ttp's constraints could depend on outer parameters. PR c++/111485 gcc/cp/ChangeLog: * pt.cc (is_compatible_template_arg): New parameter 'args'. Add the outer template arguments 'args' to 'new_args'. (convert_template_argument): Pass 'args' to is_compatible_template_arg. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-ttp5.C: New test. * g++.dg/cpp2a/concepts-ttp6.C: New test. (cherry picked from commit 6f902a42b0afe3f3145bcb864695fc290b5acc3e)
[Bug c++/99631] decltype of non-type template-parameter shouldn't be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99631 --- Comment #12 from CVS Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:b9e02590f7d35f1f8e8e95ab1f2e30f24113f551 commit r13-7835-gb9e02590f7d35f1f8e8e95ab1f2e30f24113f551 Author: Patrick Palka Date: Tue Sep 19 08:21:05 2023 -0400 c++: constness of decltype of NTTP object [PR99631] This corrects resolving decltype of a (class) NTTP object as per [dcl.type.decltype]/1.2 and [temp.param]/6 in the type-dependent case. Note that in the non-dependent case we resolve the decltype ahead of time, in which case finish_decltype_type drops the const VIEW_CONVERT_EXPR wrapper around the TEMPLATE_PARM_INDEX, and the latter has the desired non-const type. In the type-dependent case, at instantiation time tsubst drops the VIEW_CONVERT_EXPR since the substituted NTTP is the already-const object created by get_template_parm_object. So in this case finish_decltype_type sees the const object, which this patch now adds special handling for. PR c++/99631 gcc/cp/ChangeLog: * semantics.cc (finish_decltype_type): For an NTTP object, return its type modulo cv-quals. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/nontype-class60.C: New test. (cherry picked from commit ddd064e3571c4a9e6258c75eba65585a07367712)
[Bug c/111574] Illegal instruction with "-O3 -fno-toplevel-reorder -fno-tree-bit-ccp -fno-tree-dce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574 --- Comment #3 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 55982 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55982=edit The compiler output
[Bug c/111574] Illegal instruction with "-O3 -fno-toplevel-reorder -fno-tree-bit-ccp -fno-tree-dce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574 --- Comment #2 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 55981 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55981=edit The preprocessed file
[Bug c/111574] Illegal instruction with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574 --- Comment #1 from CTC <19373742 at buaa dot edu.cn> --- *** OS and Platform: Ubuntu 20.04.4 LTS *** gcc version: $ gcc -v Using built-in specs. COLLECT_GCC=/home/cuisk/ctc/gcc-releases/gcc-14/bin/gcc COLLECT_LTO_WRAPPER=/home/cuisk/ctc/gcc-releases/gcc-14/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/cuisk/ctc/gcc-releases/gcc-14 --disable-multilib --enable-language=c,c++ Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230917 (experimental) (GCC) *** Command Lines: $ gcc -I /home/cuisk/ctc/csmith/include/csmith-2.3.0 -O3 -fno-toplevel-reorder -fno-tree-bit-ccp -fno-tree-dce /home/cuisk/gcc/tmp/a.c -o w 2>ii.out $ ./w Illegal instruction (core dumped) $ gcc -I /home/cuisk/ctc/csmith/include/csmith-2.3.0 /home/cuisk/gcc/tmp/a.c -o w $ ./w checksum = 0
[Bug c/111574] New: Illegal instruction with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111574 Bug ID: 111574 Summary: Illegal instruction with Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 19373742 at buaa dot edu.cn Target Milestone: ---
[Bug c++/111569] Problem finding in Library functions with parametres: 32, 8 , 32 Bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111569 --- Comment #2 from Andrew Pinski --- You would have caught the bad code if in your compile.sh script you added: ``` set -e ``` As that would error out if one of the programs exit with a non-zero return code which gcc does on an error.
[Bug ipa/111571] [13/14 Regression] ICE in modify_call, at ipa-param-manipulation.cc:656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |13.3
[Bug tree-optimization/111572] [14 Regression] Wrong code at -O2 on x86_64-linux-gnu since r14-301-gf2d6beb7a4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572
--- Comment #3 from Andrew Pinski ---
Self contained testcase:
```
void gg(void)
{
static int t = 0;
if (t != 0) __builtin_abort();
t++;
}
int a, b = -8, e, f, h;
char c, d, g;
static int i(long k) {
e = 8;
for (; e; e = f) {
d = 6;
for (; d<7; d++) {
unsigned char j = 0;
for (; (unsigned char)(1 + k) + j <= 3; j++)
gg();
}
for (; g; g++)
;
}
return 0;
}
int main() {
h = 26 & b;
i((short)(h - 65557) + 65535);
}
```
[Bug tree-optimization/111572] [14 Regression] Wrong code at -O2 on x86_64-linux-gnu since r14-301-gf2d6beb7a4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-09-24 Ever confirmed|0 |1 Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW Summary|Wrong code at -O2 on|[14 Regression] Wrong code |x86_64-linux-gnu since |at -O2 on x86_64-linux-gnu |r14-301-gf2d6beb7a4d|since r14-301-gf2d6beb7a4d --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/111572] Wrong code at -O2 on x86_64-linux-gnu since r14-301-gf2d6beb7a4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572
--- Comment #1 from Andrew Pinski ---
__builtin_printf ("%u\n", _79);
__builtin_unreachable ();
[Bug tree-optimization/111563] Missed optimization of LICM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111563 --- Comment #4 from Yi <652023330028 at smail dot nju.edu.cn> --- (In reply to Andrew Pinski from comment #3) > (In reply to Yi from comment #2) > > (In reply to Andrew Pinski from comment #1) > > > _5 = var_0_16(D) + var_6_18(D); > > > invariant up to level 1, cost 1. > > > > > > Basically because the cost is not high enough ... > > > > > > If you use --param=lim-expensive=1. then it will pull it out of the > > > loop. > > > > > > So the cost model is doing the correct thing here ... > > > > > > Thank you very much for your prompt reply! It took me some time to confirm > > our work. For Example 1, GCC does exactly what you say it does. But for > > Example 2, it doesn't seem to work as expected. > > > > We note that `(-(200 / var_10)) + (-var_8) + var_14 + var_2` as a whole can > > be treated as a loop invariant, but gcc-trunk -O3 --param=lim-expensive=1 > > does not: > > _4 = _2 + var_24_lsm.5_21; > _6 = _4 + _5; > > So this is again reassociation with LIM, the same issue as PR 111560. I see. Thank you very much for your reply!
[Bug tree-optimization/111563] Missed optimization of LICM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111563 --- Comment #3 from Andrew Pinski --- (In reply to Yi from comment #2) > (In reply to Andrew Pinski from comment #1) > > _5 = var_0_16(D) + var_6_18(D); > > invariant up to level 1, cost 1. > > > > Basically because the cost is not high enough ... > > > > If you use --param=lim-expensive=1. then it will pull it out of the loop. > > > > So the cost model is doing the correct thing here ... > > > Thank you very much for your prompt reply! It took me some time to confirm > our work. For Example 1, GCC does exactly what you say it does. But for > Example 2, it doesn't seem to work as expected. > > We note that `(-(200 / var_10)) + (-var_8) + var_14 + var_2` as a whole can > be treated as a loop invariant, but gcc-trunk -O3 --param=lim-expensive=1 > does not: _4 = _2 + var_24_lsm.5_21; _6 = _4 + _5; So this is again reassociation with LIM, the same issue as PR 111560.
[Bug tree-optimization/111563] Missed optimization of LICM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111563
--- Comment #2 from Yi <652023330028 at smail dot nju.edu.cn> ---
(In reply to Andrew Pinski from comment #1)
> _5 = var_0_16(D) + var_6_18(D);
> invariant up to level 1, cost 1.
>
> Basically because the cost is not high enough ...
>
> If you use --param=lim-expensive=1. then it will pull it out of the loop.
>
> So the cost model is doing the correct thing here ...
Thank you very much for your prompt reply! It took me some time to confirm our
work. For Example 1, GCC does exactly what you say it does. But for Example 2,
it doesn't seem to work as expected.
https://godbolt.org/z/eeWThnqWs
Given the following code:
```c++
extern int var_24;
void test(int var_2, int var_3, int var_8, int var_10, int var_14) {
for (int i_2 = -3247424; i_2 < 19; i_2 += var_3 + 1056714155)
{
if(var_3){
var_24 += (-(200 / var_10)) + (-var_8);
var_24 += var_14 + var_2;
}
i_2+=i_2/3;
}
}
```
We note that `(-(200 / var_10)) + (-var_8) + var_14 + var_2` as a whole can be
treated as a loop invariant, but gcc-trunk -O3 --param=lim-expensive=1 does
not:
```asm
test(int, int, int, int, int):
mov r10d, edx
testesi, esi
je .L1
mov eax, -200
mov edx, -1
mov r9d, DWORD PTR var_24[rip]
add r8d, edi
idivecx
lea edi, [rsi+1056714155]
mov ecx, -3247424
sub eax, r10d
.L3:
movsx rdx, ecx
mov esi, ecx
add r9d, eax# ... + (-(200 / var_10)) + (-var_8)
imulrdx, rdx, 1431655766
sar esi, 31
add r9d, r8d# ... + var_14 + var_2
shr rdx, 32
sub edx, esi
add ecx, edx
add ecx, edi
cmp ecx, 18
jle .L3
mov DWORD PTR var_24[rip], r9d
.L1:
ret
```
[Bug fortran/80757] Internal compiler error when omitting upper subscript of a character substring in a module subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80757 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- This appears to be fixed, at least as far back as GNU Fortran (GCC) 11.2.1 20210728 I will prepare a testcase for 13-branch and mainline before closing. Cheers Paul
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276 Bug 19276 depends on bug 92586, which changed state. Bug 92586 Summary: ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from Paul Thomas --- Fixed on 13-branch and mainline. Thanks for the report Paul
[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586 --- Comment #14 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:9eb2f102d38697011d3069fac759b7c6e149bed4 commit r13-7834-g9eb2f102d38697011d3069fac759b7c6e149bed4 Author: Paul Thomas Date: Sun Sep 24 15:34:57 2023 +0100 Fortran: Supply a missing dereference [PR92586] 2023-09-24 Paul Thomas gcc/fortran PR fortran/92586 * trans-expr.cc (gfc_trans_arrayfunc_assign): Supply a missing dereference for the call to gfc_deallocate_alloc_comp_no_caf. gcc/testsuite/ PR fortran/92586 * gfortran.dg/pr92586.f90 : New test
[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68155 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Paul Thomas --- Fixed on 13-branch and mainline. Thanks for the report and sorry that it has taken a little while to fix. Regards Paul
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276 Bug 19276 depends on bug 68155, which changed state. Bug 68155 Summary: ICE on initializing character array in type (len_lhs <> len_rhs) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68155 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68155 --- Comment #14 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:8c1925ece0193058120e94614e99360e9600777e commit r13-7833-g8c1925ece0193058120e94614e99360e9600777e Author: Paul Thomas Date: Sun Sep 24 15:26:01 2023 +0100 Fortran: Pad mismatched charlens in component initializers [PR68155] 2023-09-24 Paul Thomas gcc/fortran PR fortran/68155 * decl.cc (fix_initializer_charlen): New function broken out of add_init_expr_to_sym. (add_init_expr_to_sym, build_struct): Call the new function. gcc/testsuite/ PR fortran/68155 * gfortran.dg/pr68155.f90: New test.
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #9 from Xi Ruoyao --- .
[Bug middle-end/111573] New: lambda functions often not inlined and optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111573
Bug ID: 111573
Summary: lambda functions often not inlined and optimized out
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
#include
using namespace std;
static int dosum(std::function fn)
{
return fn(5,6);
}
int test()
{
auto sum = [](int a, int b) {
return a + b;
};
int s;
for (s = 0; s < 10; s++)
s+= dosum(sum);
return s;
}
Gets optimized well only with early inlining. compiled with -fno-early-inlining
yields to:
_Z4testv:
.LFB2166:
.cfi_startproc
subq$56, %rsp
.cfi_def_cfa_offset 64
xorl%ecx, %ecx
.p2align 4,,10
.p2align 3
.L8:
leaq12(%rsp), %rdx
leaq8(%rsp), %rsi
movl$5, 8(%rsp)
leaq16(%rsp), %rdi
movl$6, 12(%rsp)
call
_ZNSt17_Function_handlerIFiiiEZ4testvEUliiE_E9_M_invokeERKSt9_Any_dataOiS6_
leal1(%rcx,%rax), %ecx
cmpl$9, %ecx
jle .L8
movl%ecx, %eax
addq$56, %rsp
.cfi_def_cfa_offset 8
ret
So we fail to inline since ipa-prop fails to track the constant function
address. I think this is really common in typical lambda function usage
[Bug tree-optimization/111572] New: Wrong code at -O2 on x86_64-linux-gnu since r14-301-gf2d6beb7a4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572
Bug ID: 111572
Summary: Wrong code at -O2 on x86_64-linux-gnu since
r14-301-gf2d6beb7a4d
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: jh at suse dot cz
Target Milestone: ---
gcc at -O2 produces the wrong code.
Bisected to r14-301-gf2d6beb7a4d
Compiler explorer: https://godbolt.org/z/reETd3ee4
$ cat a.c
int printf(const char *, ...);
int a, b = -8, e, f, h;
char c, d, g;
static int i(long k) {
e = 8;
for (; e; e = f) {
d = 6;
for (; d<7; d++) {
unsigned char j = 0;
for (; (unsigned char)(1 + k) + j <= 3; j++)
printf("%u\n", (unsigned char)(1 + k) + j);
}
for (; g; g++)
;
}
return 0;
}
int main() {
h = 26 & b;
i((short)(h - 65557) + 65535);
}
$
$ gcc -O0 a.c && ./a.out
3
$ gcc -O2 a.c && ./a.out
3
3
3
3
(Truncated)
$
[Bug tree-optimization/111571] [13/14 Regression] ICE in modify_call, at ipa-param-manipulation.cc:656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571 Martin Jambor changed: What|Removed |Added Last reconfirmed||2023-09-24 Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org CC||jamborm at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Martin Jambor --- Clearly mine.
[Bug analyzer/104940] RFE: integrate analyzer with an SMT solver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940 --- Comment #6 from David Malcolm --- https://github.com/kristerw/pysmtgcc
[Bug tree-optimization/111571] New: [13/14 Regression] ICE in modify_call, at ipa-param-manipulation.cc:656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
Bug ID: 111571
Summary: [13/14 Regression] ICE in modify_call, at
ipa-param-manipulation.cc:656
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: mjambor at suse dot cz
Target Milestone: ---
gcc at -O2 crashes on the following testcase.
Bisected to r13-4685-g4834e9360f7
Compiler explorer: https://godbolt.org/z/3b9ra7Kf8
$ cat a.c
struct a {
int b;
};
struct c {
long d;
struct a e;
long f;
};
int g, h, i;
int j() {return 0;}
static void k(struct a l, int p) {
if (h)
g = 0;
for (; g; g = j())
if (l.b)
break;
}
static void m(struct c l) {
k(l.e, l.f);
for (;; --i)
;
}
int main() {
struct c n = {10, 9};
m(n);
}
$
$ gcc -O2 a.c
during IPA pass: inline
a.c: In function ‘main’:
a.c:25:9: internal compiler error: in modify_call, at
ipa-param-manipulation.cc:655
25 | m(n);
| ^~~~
0x7f9be5bb7082 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug analyzer/104940] RFE: integrate analyzer with an SMT solver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940 --- Comment #5 from David Malcolm --- See also: https://kristerw.github.io/2022/11/01/verifying-optimizations/
[Bug target/108575] Bug in gcc arm non eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108575 --- Comment #8 from Nikos Tosis --- We found the problem, the bug was in Embedded Ecoder from Mathworks. So the Coder has generated wrong C Code. Thank you all.
[Bug c++/111569] Problem finding in Library functions with parametres: 32, 8 , 32 Bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111569 Xi Ruoyao changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- The test case is invalid: upro1.cpp: In function 'int upro1(char*, u32, u8, u32)': upro1.cpp:4:8: error: 'b32' was not declared in this scope; did you mean 'u32'? 4 | return b32 + c8 + d32 ; |^~~ |u32 upro1.cpp:4:14: error: 'c8' was not declared in this scope; did you mean 'c'? 4 | return b32 + c8 + d32 ; | ^~ | c upro1.cpp:4:19: error: 'd32' was not declared in this scope; did you mean 'u32'? 4 | return b32 + c8 + d32 ; | ^~~ | u32
[Bug demangler/111570] New: -march=generic prints error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111570 Bug ID: 111570 Summary: -march=generic prints error Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: brjd_epdjq36 at kygur dot com Target Milestone: --- When compiling, it prints out an error: 'generic' CPU can be used only for '-mtune=' switch. However, the compiler help prints out: Known valid arguments for -march= option: i386 i486 i586 pentium ... generic native Not sure if this is a bug or it means something else.
[Bug c++/111569] New: Problem finding in Library functions with parametres: 32, 8 , 32 Bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111569 Bug ID: 111569 Summary: Problem finding in Library functions with parametres: 32, 8 , 32 Bits Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hjherbert at web dot de Target Milestone: --- Created attachment 55980 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55980=edit 4 source files and a shell script which runs on Odroid-C4 The Linker does not find in Library functions, if the function has parameters: ( char *p, u32 b, u8 c, u32 d ) But it finds in Library functions with the parameters: ( char *p, u32 b, u32 c, u32 d ) ( char *p, u8 b, u32 c, u32 d ) Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-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
[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550
--- Comment #3 from 康桓瑋 ---
Let me report another issue I observed on this PR.
According to [range.adaptor.object], adaptor(args...) uses
std::forward(args).. . to forward arguments into the call
wrapper's decayed member, whereas libstdc++ unconditionally uses std::moves,
which causes the following code to be rejected:
https://godbolt.org/z/EYoxzfWKn
#include
struct NonMovable {
NonMovable() = default;
NonMovable(const NonMovable&) = default;
NonMovable(NonMovable&&) = delete;
};
int main() {
NonMovable nonmovable;
auto r = std::views::take(nonmovable); // hard error in libc++ and
lidstdc++
}
The libc++ implementation uses std::bind_back, so it will also produce a hard
error because std::bind_back requires that the argument must be
move-constructible.
It seems like only MSVC conforms to the standard's wording.
The standard does not require the type of args... here to be move-constructible
like other call wrapper factories (such as
std::bind_front/std::bind_back/std::bind) do, which seems to introduce some
inconsistencies.
Although I don't think such constraint is necessary, and I don't know if it's
worthy of an LWG?
[Bug libstdc++/111568] New: std::not_fn can accept non-movable function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111568
Bug ID: 111568
Summary: std::not_fn can accept non-movable function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
It seems that std::not_fn should reject the following code according to
[func.not.fn]: "Mandates: is_constructible_v &&
is_move_constructible_v is true."
https://godbolt.org/z/MsrqnbY74
#include
struct OnlyCopyableFun {
OnlyCopyableFun() = default;
OnlyCopyableFun(const OnlyCopyableFun&) = default;
OnlyCopyableFun(OnlyCopyableFun&&) = delete;
bool operator()(auto) const;
};
int main() {
OnlyCopyableFun f;
auto nf = std::not_fn(f); // only ill-formed in libc++
}
Not quite sure why these standard call wrapper factories (std::bind_front,
std::bind, etc.) require all argument types to be move-constructible, although
the call wrapper produced in the above example is still move-constructible as
its underlying type has a copy constructor.
It seems to me that just requiring is_constructible_v is enough, which
is what the range adaptor object does.
[Bug c++/111544] [14 regression] assignment of read-only location after r14-4111-g6e92a6a2a72d3b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544 --- Comment #13 from Jonathan Wakely --- But the code is "ill-formed, no diagnostic required" and GCC is now being more helpful by diagnosing it.
[Bug c++/111544] [14 regression] assignment of read-only location after r14-4111-g6e92a6a2a72d3b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111544 --- Comment #12 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #10) > So clang most likely thinks b.t and c->t are still type depedent even though > they don't need to be ... Which is fine. It's QoI whether non-dependent errors in uninstantiated templates are diagnosed. So Clang is not wrong to accept it. And GCC is not wrong to reject it.
[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550 --- Comment #2 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #1) > I think all four bugs related to adaptor closures are very similar and could > be a single bug report. Perhaps. Maybe I should collect them all. Sorry for bringing up bits and pieces.
[Bug libstdc++/111550] The range adaptor closure object generated by adaptor(args...) is not a perfect forwarding call wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111550 --- Comment #1 from Jonathan Wakely --- I think all four bugs related to adaptor closures are very similar and could be a single bug report.
[Bug analyzer/111567] RFE: support __attribute__((counted_by)) in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111567 --- Comment #1 from David Malcolm --- This PR tracks adding support for the attribute to -fanalyzer (which I can take a look at). Adding the attribute itself is tracked by PR 108896.
[Bug gcov-profile/111559] [14 regression] ICE when building Python with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559 Franz Sirl changed: What|Removed |Added CC||sirl at gcc dot gnu.org --- Comment #3 from Franz Sirl --- Looks like a dup of the profiledbootstrap fail bug 111283
[Bug analyzer/111567] New: RFE: support counted_by in analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111567 Bug ID: 111567 Summary: RFE: support counted_by in analyzer Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: ---
[Bug target/111546] [14 Regression] ICE: gfortran.dg/overload_5.f90:53:2: internal compiler error: in emit_move_insn, at expr.cc:4219 since r14-4163-gbea89f78f2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111546 --- Comment #2 from CVS Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:deb844c67f1e2b116518f9742a6acbe6f19ea28f commit r14-4243-gdeb844c67f1e2b116518f9742a6acbe6f19ea28f Author: Pan Li Date: Sun Sep 24 11:36:11 2023 +0800 RISC-V: Fix fortran ICE/PR111546 when RV32 vec_init When broadcast the reperated element, we take the mask_int_mode by mistake. This patch would like to fix it by leveraging the machine mode of the element. The below test case in RV32 will be fixed. * gcc/testsuite/gfortran.dg/overload_5.f90 PR target/111546 gcc/ChangeLog: * config/riscv/riscv-v.cc (expand_vector_init_merge_repeating_sequence): Bugfix Signed-off-by: Pan Li
[Bug tree-optimization/102032] missed optimization on 2 equivalent expressions when -fwrapv is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102032 --- Comment #4 from Vincent Lefèvre --- Note that as said in PR111560 comment 6, re-association may break CSE, e.g. if there are also a + b + d and a + c + e with my example. So, re-association for global optimal CSE, in addition to being difficult, will not allow the optimization in all cases of equivalent expressions.
[Bug gcov-profile/111559] [14 regression] ICE when building Python with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111559 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #2 from Sergei Trofimovich --- Possibly exposed by r14-3459-g0c78240fd7d519 "Check that passes do not forget to define profile"
[Bug target/111566] RISC-V Vector Fortran: ICE in final_scan_insn_1 (final RTL pass)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111566 Andrew Pinski changed: What|Removed |Added Component|middle-end |target Keywords||ice-on-valid-code --- Comment #1 from Andrew Pinski --- fmax-stack-var-size just changes if (the VLA) dc, ch, ci, and cj are allocated on the stack or in the heap.
[Bug middle-end/111566] New: RISC-V Vector Fortran: ICE in final_scan_insn_1 (final RTL pass)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111566
Bug ID: 111566
Summary: RISC-V Vector Fortran: ICE in final_scan_insn_1 (final
RTL pass)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremy.bennett at embecosm dot com
Target Milestone: ---
Created attachment 55979
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55979=edit
Reproducer
Issue discovered with the SPEC CPU 2017 627.cam4_s benchmark. It appears to be
an interaction between RISC-V vector and the -fmax-stack-var-size parameter.
Reproducer (test.f90)
module a
integer,parameter :: SHR_KIND_R8 = selected_real_kind(12)
end module a
module b
use a, c => shr_kind_r8
contains
subroutine d(cg , km, i1, i2)
real (c) ch(i2,km)
real (c) cg(4,i1:i2,km)
real dc(i2,km)
real(c) ci(i2,km)
real(c) cj(i2,km)
do k=2,ck
do i=i1,0
cl = ci(i,k) *ci(i,1) / cj(i,k)+ch(i,1)
cm = cg(1,i,k) - min(e,cg(1,i,co))
dc(i,k) = sign(cm, cl)
enddo
enddo
if ( cq == 0 ) then
do i=i1,i2
if( cr <= cs ) then
cg= sign( min(ct, cg), cg)
endif
enddo
endif
end subroutine d
end module b
Compile with:
riscv64-unknown-linux-gnu-gfortran -w -march=rv64gcv -mabi=lp64d -c -Ofast
-ftree-vectorize --param=riscv-autovec-preference=scalable
-fallow-argument-mismatch -fmax-stack-var-size=65536 test.f90
Output is:
27 | end subroutine d
| ^
Error: could not split insn
(insn 967 168 1115 (set (mem/c:V16DI (plus:DI (reg/f:DI 2 sp)
(const_int 128 [0x80])) [4 %sfp+[-1024, -16] S128 A128])
(mem/c:V16DI (reg/f:DI 2 sp) [4 %sfp+[-1152, -16] S128 A128]))
"test.f90":16:44 1117 {*movv16di_mem_to_mem}
(nil))
during RTL pass: final
test.f90:27:18: internal compiler error: in final_scan_insn_1, at final.cc:2808
0x9d3f63 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/jeremy/gittrees/mustang/gcc/gcc/rtl-error.cc:108
0x965949 final_scan_insn_1
/home/jeremy/gittrees/mustang/gcc/gcc/final.cc:2808
0xe952af final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/jeremy/gittrees/mustang/gcc/gcc/final.cc:2887
0xe954f4 final_1
/home/jeremy/gittrees/mustang/gcc/gcc/final.cc:1979
0xe9601a rest_of_handle_final
/home/jeremy/gittrees/mustang/gcc/gcc/final.cc:4240
0xe9601a execute
/home/jeremy/gittrees/mustang/gcc/gcc/final.cc:4318
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug fortran/111271] gcc/fortran/trans-expr.cc:1134:8: warning: duplicated ‘if’ condition [-Wduplicated-cond]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111271 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Thomas --- Fixed - thanks for the report. Paul
[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68155 --- Comment #13 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c23ce23e9ce162c49bca8900c8a20079b49501c9 commit r14-4242-gc23ce23e9ce162c49bca8900c8a20079b49501c9 Author: Paul Thomas Date: Sun Sep 24 09:00:52 2023 +0100 Fortran: Pad mismatched charlens in component initializers [PR68155] 2023-09-24 Paul Thomas gcc/fortran PR fortran/68155 * decl.cc (fix_initializer_charlen): New function broken out of add_init_expr_to_sym. (add_init_expr_to_sym, build_struct): Call the new function. PR fortran/111271 * trans-expr.cc (gfc_conv_intrinsic_to_class): Remove repeated condition. gcc/testsuite/ PR fortran/68155 * gfortran.dg/pr68155.f90: New test.
[Bug fortran/111271] gcc/fortran/trans-expr.cc:1134:8: warning: duplicated ‘if’ condition [-Wduplicated-cond]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111271 --- Comment #3 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c23ce23e9ce162c49bca8900c8a20079b49501c9 commit r14-4242-gc23ce23e9ce162c49bca8900c8a20079b49501c9 Author: Paul Thomas Date: Sun Sep 24 09:00:52 2023 +0100 Fortran: Pad mismatched charlens in component initializers [PR68155] 2023-09-24 Paul Thomas gcc/fortran PR fortran/68155 * decl.cc (fix_initializer_charlen): New function broken out of add_init_expr_to_sym. (add_init_expr_to_sym, build_struct): Call the new function. PR fortran/111271 * trans-expr.cc (gfc_conv_intrinsic_to_class): Remove repeated condition. gcc/testsuite/ PR fortran/68155 * gfortran.dg/pr68155.f90: New test.
[Bug target/111565] New: ICE: in riscv_expand_strcmp_scalar, at config/riscv/riscv-string.cc:382 with -mcpu=thead-c906 -minline-strncmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111565 Bug ID: 111565 Summary: ICE: in riscv_expand_strcmp_scalar, at config/riscv/riscv-string.cc:382 with -mcpu=thead-c906 -minline-strncmp Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: riscv64-unknown-linux-gnu Created attachment 55978 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55978=edit reduced testcase Compiler output: $ riscv64-unknown-linux-gnu-gcc -mcpu=thead-c906 -minline-strncmp testcase.c during RTL pass: expand testcase.c: In function 'foo': testcase.c:4:10: internal compiler error: in riscv_expand_strcmp_scalar, at config/riscv/riscv-string.cc:382 4 | return __builtin_strncmp (p, q, 0x800); | ^~~ 0xedd797 riscv_expand_strcmp_scalar /repo/gcc-trunk/gcc/config/riscv/riscv-string.cc:382 0xedd797 riscv_expand_strcmp(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/config/riscv/riscv-string.cc:513 0x20dd6af gen_cmpstrnsi(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/config/riscv/riscv.md:3528 0x14948a8 maybe_expand_insn(insn_code, unsigned int, expand_operand*) /repo/gcc-trunk/gcc/optabs.cc:8276 0x11d9ad1 expand_cmpstrn_or_cmpmem(insn_code, rtx_def*, rtx_def*, rtx_def*, tree_node*, rtx_def*, long) /repo/gcc-trunk/gcc/expr.cc:2377 0x107f6f1 expand_builtin_strncmp /repo/gcc-trunk/gcc/builtins.cc:4956 0x10837e9 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) /repo/gcc-trunk/gcc/builtins.cc:7789 0x11e8c05 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.cc:11912 0x11e152a expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.cc:9010 0x11e152a expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier) /repo/gcc-trunk/gcc/expr.h:310 0x11e152a expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /repo/gcc-trunk/gcc/expr.cc:9345 0x11e5982 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.cc:12200 0x11f5fa3 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /repo/gcc-trunk/gcc/expr.cc:9010 0x11f5fa3 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier) /repo/gcc-trunk/gcc/expr.h:310 0x11f5fa3 store_expr(tree_node*, rtx_def*, int, bool, bool) /repo/gcc-trunk/gcc/expr.cc:6208 0x11f6ed5 expand_assignment(tree_node*, tree_node*, bool) /repo/gcc-trunk/gcc/expr.cc:6043 0x10aa62a expand_call_stmt /repo/gcc-trunk/gcc/cfgexpand.cc:2829 0x10aa62a expand_gimple_stmt_1 /repo/gcc-trunk/gcc/cfgexpand.cc:3880 0x10aa62a expand_gimple_stmt /repo/gcc-trunk/gcc/cfgexpand.cc:4044 0x10af936 expand_gimple_basic_block /repo/gcc-trunk/gcc/cfgexpand.cc:6100 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ riscv64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4240-20230924001658-g08b887fd41c-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-isa-spec=2.2 --with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu --with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld --with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-4240-20230924001658-g08b887fd41c-checking-yes-rtl-df-extra-riscv64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20230924 (experimental) (GCC)
[Bug tree-optimization/111564] Missed optimization of Loop Unswitch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111564 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Keywords||missed-optimization --- Comment #3 from Richard Biener --- You can alter --param max-unswitch-insns to get these cases unswitched.
[Bug tree-optimization/111560] Missed optimization of available expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111560
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2023-09-24
--- Comment #6 from Richard Biener ---
Confirmed. Simpler testcase:
int e,f;
void test(int a, int b, int c, int d)
{
e=a+b+c; //line 5
f=d+b+c; //"b+c" can be replaced with the value at line 5
}
it's as Andrew says plus re-associating for global optimal CSE is difficult,
imagine adding
g = a + b + d;
to the above. There's either a + b in common with e but then that breaks
commoning b + c in e and f or there is b + d in common with f also breaking
the other CSE.
Our re-association only produces a canonical order within a single expression.
That doesn't by design allow CSE of common subexpressions in other expressions.
I don't know of any work (paper) describing how to attack this global
optimization problem.
[Bug tree-optimization/111543] `(a & b) & ~a` could be optimized before reassociation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111543 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug tree-optimization/111543] `(a & b) & ~a` could be optimized before reassociation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111543 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:1bf0cd05cb30889cae4b6cf06e80b7f3a13c40c1 commit r14-4241-g1bf0cd05cb30889cae4b6cf06e80b7f3a13c40c1 Author: Andrew Pinski Date: Sat Sep 23 04:38:02 2023 + MATCH: Add `(X & ~Y) & Y` and `(X | ~Y) | Y` Even though this gets optimized by reassociation, catching it more often will always be better. Note the reason why I didn't add `(X ^ ~Y) ^ Y` is that it gets caught by prefering `~(X ^ Y)` to `(X ^ ~Y)` which then it is caught by the the pattern for `(X ^ Y) ^ Y` already. PR tree-optimization/111543 gcc/ChangeLog: * match.pd (`(X & ~Y) & Y`, `(X | ~Y) | Y`): New patterns. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/bitops-4.c: New test.
[Bug middle-end/111551] Fix for PR106081 is not working with profile feedback on imagemagick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111551 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Blocks||26163 Keywords||missed-optimization --- Comment #1 from Richard Biener --- we don't know yet whether it's the vectorization? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
