[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #17 from Sam James --- Is there by chance a workaround we can apply for this downstream (some flag)? It prevents building Chromium on arm64 for us w/ gcc unfortunately.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #11 from Georg-Johann Lay --- I tried with the test case, but the expensive shifts are still there except for the cset_32bit30_not case, which improved as noted above. cset_32bit30 however goes from the 3-instruction code to: cset_32bit30: movw r26,r24 ; 19 [c=4 l=2] *movsi/0 movw r24,r22 ldi r18,30 ; 26 [c=44 l=7] *lshrsi3_const/3 1: lsr r27 ror r26 ror r25 ror r24 dec r18 brne 1b andi r24,lo8(1) ; 21 [c=4 l=1] *andqi3/1 ret ; 24 [c=0 l=1] return So we are back where we started? All except one case use expensive shift.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #12 from Georg-Johann Lay --- ...my bad, I tried "extzv", which didn't work out as expected. So we have shifts : bit-extract = 3 : 2. Is it worth trying to write combine patterns to catch this? Or will there be better lowering for the remaining caases?
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #18 from Jakub Jelinek --- Created attachment 55124 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55124&action=edit gcc14-pr109505.patch I actually think it isn't that bad, we don't have that many, I've looked at match.pd patterns which check for 2 CONSTANT_CLASS_P operands and then try to combine them using some operation and counted just 10 spots which I think need ! added.
[Bug ipa/109914] New: --suggest-attribute=pure misdiagnoses static functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914 Bug ID: 109914 Summary: --suggest-attribute=pure misdiagnoses static functions Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 55125 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55125&action=edit test case GCC's --suggest-attribute=pure diagnoses static functions, even though the 'pure' attribute is useless for static functions (after all, the compiler has deduced the property on its own). This is leading to my having to litter code with '__attribute__ (pure)' declarations merely to pacify GCC. GCC should treat the 'pure' attribute like other attributes (e.g., malloc, const), and should issue the diagnostic only for non-static functions where the attribute is in fact useful. How to reproduce: $ gcc --version gcc (GCC) 13.1.0 ... $ gcc -Wsuggest-attribute=pure -O2 -S file-has-acl.c file-has-acl.c: In function ‘have_xattr’: file-has-acl.c:3385:14: warning: function might be candidate for attribute ‘pure’ if it is known to return normally [-Wsuggest-attribute=pure] 3385 | static _Bool have_xattr (char const *attr, char const *listbuf, ssize_t listsize) | ^~
[Bug ipa/85734] --suggest-attribute=malloc misdiagnoses static functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85734 --- Comment #6 from Sam James --- Paul noted at https://lists.gnu.org/archive/html/bug-gnulib/2023-05/msg00139.html that this seems to have come back, but interestingly, this bug never got closed in the first place.
[Bug ipa/109915] New: --suggest-attribute=const misdiagnoses static functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109915 Bug ID: 109915 Summary: --suggest-attribute=const misdiagnoses static functions Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 55126 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55126&action=edit test case date.c GCC's --suggest-attribute=const diagnoses static functions, even though the 'const' attribute is useless for static functions (after all, the compiler has deduced the property on its own). This is leading to my having to litter code with '__attribute__ (const)' declarations merely to pacify GCC. GCC should treat the 'const' attribute like other attributes (e.g., malloc, pure), and should issue the diagnostic only for non-static functions where the attribute is in fact useful. How to reproduce: $ gcc --version gcc (GCC) 13.1.0 ... $ gcc -ftrapv -Wsuggest-attribute=pure -O2 -S date.c date.c: In function ‘res_width’: date.c:5658:12: warning: function might be candidate for attribute ‘const’ if it is known to return normally [-Wsuggest-attribute=const] 5658 | static int res_width (long int res) |^
[Bug ipa/109916] New: warning reported despite of "#pragma GCC diagnostic ignored", due to -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109916 Bug ID: 109916 Summary: warning reported despite of "#pragma GCC diagnostic ignored", due to -flto Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 55127 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55127&action=edit test case sources s.tar.xz When adding option '-flto' to the gcc command line, diagnostics that are ordinarily suppressed through "#pragma GCC diagnostic ignored ..." get reported nevertheless. How to reproduce: 1. Unpack the attached sources s.tar.xz. $ gcc --version gcc (GCC) 13.1.0 ... $ gcc -Wmaybe-uninitialized -O2 s/*.c -o cut $ gcc -Wmaybe-uninitialized -O2 s/*.c -o cut -flto In function ‘getndelim2’, inlined from ‘cut_fields’ at s/cut.c:5185:17: s/getndelim2.c:2015:23: warning: ‘c’ may be used uninitialized [-Wmaybe-uninitialized] 2015 | *read_pos = c; | ^ s/getndelim2.c: In function ‘cut_fields’: s/getndelim2.c:1934:11: note: ‘c’ was declared here 1934 | int c; | ^
[Bug ipa/109916] warning reported despite of "#pragma GCC diagnostic ignored", due to -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109916 Alexander Monakov changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- There's a family of similar reports that "late" warnings do not observe this pragma under LTO. I think it's best to make this a dup of the "canonical" PR. *** This bug has been marked as a duplicate of bug 80922 ***
[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922 Alexander Monakov changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #11 from Alexander Monakov --- *** Bug 109916 has been marked as a duplicate of this bug. ***
[Bug c/96114] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96114 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #3 from Martin Uecker --- Maybe related to PR108423 and probably covered by the patch. Seems latent since 13 though. https://godbolt.org/z/WMqW57aP1
[Bug c/109917] New: gcctk hangs at -O0 but normally terminates at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109917
Bug ID: 109917
Summary: gcctk hangs at -O0 but normally terminates at -O2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
Below is the testcase:
```
int foo(int a0, int a1, int a2, int a3, int a4, int a5,
int a6, int a7, int a8, int a9, int a10, int a11,
int a12, int a13, int a14, int a15, int a16) {
register int v0 asm("rax") = a3;
register int v5 asm("rdi") = a8;
register int v1 asm("rbx") = a4;
register int v2 asm("rcx") = a5;
register int v3 asm("rdx") = a6;
register int v4 asm("rsi") = a7;
register int v6 asm("r8") = a9;
register int v7 asm("r9") = a10;
register int v8 asm("r10") = a11;
register int v9 asm("r11") = a12;
register int v10 asm("r12") = a13;
register int v11 asm("r13") = a14;
register int v12 asm("r14") = a15;
register int v13 asm("r15") = a16;
int x;
asm goto("" : "=r"(x) : : : lab);
lab:
return v0 + v1 + v2 + v3 + v4 + v5 + v6 + v7 + v8 + v9 +
v10 + v11 + v12 + v13 + a0 + a1 + a2;
}
```
When compile it with gcctk -O0, gcctk hangs, my gcctk version:
```
$ gcctk -v
Using built-in specs.
COLLECT_GCC=./install/bin/gcc
COLLECT_LTO_WRAPPER=/home/wierton/disk/gcc-project-trunk-compile/install/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/wierton/gcc-project-trunk/configure
--prefix=/home/wierton/disk/gcc-project-trunk-compile/install
--enable-languages=c,c++ --disable-bootstrap --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230520 (experimental) (GCC)
$ gcctk --version
gcc (GCC) 14.0.0 20230520 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #9 from Michel Morin --- > (which even mentions the std::string((const char*)nullptr) case): > https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_semantics.html Oh, that's good to know. Understood that PEDASSERT fits better. > can we add a "pednonnull" attribute or something to produce a -Wnonnull > warning like the nonnull attribute but w/o affecting code generation as well? I think such an attribute (like Clang's _Nonnull) would be a nice addition. So I grepped Nonnull on libc++, but strangely there are __no__ uses of _Nonnull/__nonnull. I only found a few __gnu__::__nonnull__ in __memory_resource/memory_resource.h. In libc++, std::string constructors have assertions for nullptr check, but there are no attributes.
[Bug middle-end/109917] gcctk hangs at -O0 but normally terminates at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109917 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 109520. Where is this code located anyways? *** This bug has been marked as a duplicate of bug 109520 ***
[Bug middle-end/109520] compiler never terminates with an inline-asm goto and an output with high register pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109520 Andrew Pinski changed: What|Removed |Added CC||141242068 at smail dot nju.edu.cn --- Comment #4 from Andrew Pinski --- *** Bug 109917 has been marked as a duplicate of this bug. ***
[Bug ipa/109915] --suggest-attribute=const misdiagnoses static functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109915 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- const and pure are handled by the same code so this is a dup. *** This bug has been marked as a duplicate of bug 109914 ***
[Bug ipa/109914] --suggest-attribute=pure misdiagnoses static functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914 --- Comment #1 from Andrew Pinski --- *** Bug 109915 has been marked as a duplicate of this bug. ***
[Bug middle-end/109917] gcctk hangs at -O0 but normally terminates at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109917 --- Comment #2 from wierton <141242068 at smail dot nju.edu.cn> --- (In reply to Andrew Pinski from comment #1) > Dup of bug 109520. > > Where is this code located anyways? > > *** This bug has been marked as a duplicate of bug 109520 *** Thanks for your reply. This test case is mutated from the file 'asmgoto-5.c' which locates at gcc's testsuite: 'gcc/gcc/testsuite/gcc.c-torture/compile'.
[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257
--- Comment #6 from LIU Hao ---
gcc/config/i386/i386.cc:
```
void
ix86_print_operand (FILE *file, rtx x, int code)
{
if (code)
{
switch (code)
{
case 'A':
switch (ASSEMBLER_DIALECT)
{
case ASM_ATT:
putc ('*', file);
break;
case ASM_INTEL:
/* Intel syntax. For absolute addresses, registers should not
be surrounded by braces. */
if (!REG_P (x))
{
putc ('[', file);
ix86_print_operand (file, x, 0);
putc (']', file);
return;
}
break;
default:
gcc_unreachable ();
}
ix86_print_operand (file, x, 0);
return;
```
I hope someone can clean this up a bit. The AT&T part is an obvious recursion,
so why should we write something like that? It could be
```
case 'A':
if (ASSEMBLER_DIALECT == ASM_ATT)
{
putc ('*', file);
break;
}
// intel stuff here.
return;
```
[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 &bool1 and bool0 <= bool1 as !bool0 | bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807 --- Comment #5 from Andrew Pinski --- Created attachment 55128 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55128&action=edit Patch which I am testing This one includes the cost model here. Did a quick test on mips to see it produces the set compare instruction still.
[Bug c++/109918] New: Unexpected -Woverloaded-virtual with virtual conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109918
Bug ID: 109918
Summary: Unexpected -Woverloaded-virtual with virtual
conversion operators
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
Now that the -Woverloaded-virtual=1 is enabled by default with -Wall, the
following code raises warning while I think it should not (for the specific
case of conversion operators):
#include
struct A
{
virtual operator int() { return 42; }
virtual operator char() = 0;
};
struct B : public A
{
operator char() override { return 'A'; }
};
int main()
{
B b;
std::cout << static_cast(b) << std::endl; // int conversion was not
hiden, contrary to what -Woverloaded-virtual claims
std::cout << static_cast(b) << std::endl;
}
Godbolt link: https://godbolt.org/z/4Wb9rxbMP
Compiled with -Wall, it raises this warning:
:5:13: warning: 'virtual A::operator int()' was hidden
[-Woverloaded-virtual=]
5 | virtual operator int() { return 42; }
| ^~~~
: note: by 'operator'
ASM generation compiler returned: 0
:5:13: warning: 'virtual A::operator int()' was hidden
[-Woverloaded-virtual=]
5 | virtual operator int() { return 42; }
| ^~~~
: note: by 'operator'
Execution build compiler returned: 0
Program returned: 0
42
A
I have hit this issue in a real code base, while migrating to gcc 13.
Cheers,
Romain
[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 &bool1 and bool0 <= bool1 as !bool0 | bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807
--- Comment #6 from Andrew Pinski ---
Looks like I only implemented this for do_store_flag which is good but it needs
to also implemented for do_jump too.
Take:
```
#define bool _Bool
bool j(void);
bool h(void);
bool f(bool a, bool b)
{
if(a
[Bug c++/109918] [10/11/12/13/14 Regression] Unexpected -Woverloaded-virtual with virtual conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109918 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Summary|Unexpected |[10/11/12/13/14 Regression] |-Woverloaded-virtual with |Unexpected |virtual conversion |-Woverloaded-virtual with |operators |virtual conversion ||operators Known to work||7.1.0, 7.5.0 Known to fail||8.1.0 Last reconfirmed||2023-05-20 Target Milestone|--- |10.5 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. GCC 7.5 didn't warn with -Woverloaded-virtual but GCC 8 does. Maybe introduced by r8-2977-g940ab2e08e2414 .
[Bug fortran/109846] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7259fd5bd4c922f396465c9cfec2ec342969f9a9 commit r12-9628-g7259fd5bd4c922f396465c9cfec2ec342969f9a9 Author: Harald Anlauf Date: Sun May 14 21:53:51 2023 +0200 Fortran: CLASS pointer function result in variable definition context [PR109846] gcc/fortran/ChangeLog: PR fortran/109846 * expr.cc (gfc_check_vardef_context): Check appropriate pointer attribute for CLASS vs. non-CLASS function result in variable definition context. gcc/testsuite/ChangeLog: PR fortran/109846 * gfortran.dg/ptr-func-5.f90: New test. (cherry picked from commit fa0569e90efe8a5cb895a3f50dd502f849940828)
[Bug fortran/109846] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:fb47733938b352c6d84ef342fc11d2bd478d1218 commit r11-10795-gfb47733938b352c6d84ef342fc11d2bd478d1218 Author: Harald Anlauf Date: Sun May 14 21:53:51 2023 +0200 Fortran: CLASS pointer function result in variable definition context [PR109846] gcc/fortran/ChangeLog: PR fortran/109846 * expr.c (gfc_check_vardef_context): Check appropriate pointer attribute for CLASS vs. non-CLASS function result in variable definition context. gcc/testsuite/ChangeLog: PR fortran/109846 * gfortran.dg/ptr-func-5.f90: New test. (cherry picked from commit fa0569e90efe8a5cb895a3f50dd502f849940828)
[Bug fortran/109846] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.4 Status|ASSIGNED|RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and on release branches down to 11.
[Bug rtl-optimization/109919] New: ICE on valid code at -O2 and -O3 with "-fno-tree-dce -fno-tree-vrp" on x86_64-linux-gnu: in emit_move_insn, at expr.cc:4224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109919
Bug ID: 109919
Summary: ICE on valid code at -O2 and -O3 with "-fno-tree-dce
-fno-tree-vrp" on x86_64-linux-gnu: in emit_move_insn,
at expr.cc:4224
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a very recent regression.
[611] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230520 (experimental) [master r14-924-gd709841ae0f] (GCC)
[612] %
[612] % gcctk -O2 -fno-tree-dce -fno-tree-vrp small.c
during RTL pass: expand
small.c: In function ‘main’:
small.c:5:17: internal compiler error: in emit_move_insn, at expr.cc:4224
5 | short c = b && ((a || a) & (a * c));
| ~~^~~
0x758d96 emit_move_insn(rtx_def*, rtx_def*)
../../gcc-trunk/gcc/expr.cc:4224
0xba80fa expand_and(machine_mode, rtx_def*, rtx_def*, rtx_def*)
../../gcc-trunk/gcc/expmed.cc:5484
0xbbd7af expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-trunk/gcc/expr.cc:9829
0xbc0a7d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-trunk/gcc/expr.cc:10800
0xbbd4fb expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-trunk/gcc/expr.cc:8999
0xbbd4fb expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../gcc-trunk/gcc/expr.h:310
0xbbd4fb expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-trunk/gcc/expr.cc:9321
0xbbe19e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-trunk/gcc/expr.cc:12152
0xbb85ea expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../gcc-trunk/gcc/expr.h:310
0xbb85ea expand_single_bit_test
../../gcc-trunk/gcc/expr.cc:12959
0xbb85ea do_store_flag
../../gcc-trunk/gcc/expr.cc:13166
0xbb9019 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-trunk/gcc/expr.cc:10251
0xa93a0e expand_gimple_stmt_1
../../gcc-trunk/gcc/cfgexpand.cc:3983
0xa93a0e expand_gimple_stmt
../../gcc-trunk/gcc/cfgexpand.cc:4044
0xa984a0 expand_gimple_basic_block
../../gcc-trunk/gcc/cfgexpand.cc:6106
0xa9a407 execute
../../gcc-trunk/gcc/cfgexpand.cc:6841
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.
[613] %
[613] % cat small.c
int a;
int main() {
int b = 1;
while (a) {
short c = b && ((a || a) & (a * c));
}
return 0;
}
[Bug middle-end/109919] [14 Regression] ICE on valid code at -O2 and -O3 with "-fno-tree-dce -fno-tree-vrp" on x86_64-linux-gnu: in emit_move_insn, at expr.cc:4224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109919 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Summary|ICE on valid code at -O2|[14 Regression] ICE on |and -O3 with "-fno-tree-dce |valid code at -O2 and -O3 |-fno-tree-vrp" on |with "-fno-tree-dce |x86_64-linux-gnu: in|-fno-tree-vrp" on |emit_move_insn, at |x86_64-linux-gnu: in |expr.cc:4224|emit_move_insn, at ||expr.cc:4224 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |14.0 Ever confirmed|0 |1 Last reconfirmed||2023-05-20 --- Comment #1 from Andrew Pinski --- Almost positive this is my bug.
[Bug middle-end/109919] [14 Regression] ICE on valid code at -O2 and -O3 with "-fno-tree-dce -fno-tree-vrp" on x86_64-linux-gnu: in emit_move_insn, at expr.cc:4224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109919 --- Comment #2 from Andrew Pinski --- Simple one line fix: ``` apinski@xeond:~/src/upstream-gcc/gcc/objdir/gcc$ git diff diff --git a/gcc/expr.cc b/gcc/expr.cc index 2070198acda..02f24c00148 100644 --- a/gcc/expr.cc +++ b/gcc/expr.cc @@ -12956,7 +12956,7 @@ expand_single_bit_test (location_t loc, enum tree_code code, intermediate_type = ops_unsigned ? unsigned_type : signed_type; inner = fold_convert_loc (loc, intermediate_type, inner); - rtx inner0 = expand_expr (inner, target, VOIDmode, EXPAND_NORMAL); + rtx inner0 = expand_expr (inner, NULL_RTX, VOIDmode, EXPAND_NORMAL); inner0 = extract_bit_field (inner0, 1, bitnum, 1, target, operand_mode, mode, 0, NULL); ``` To explain what is happening is simple, target in this case is QImode but for inner we would need a SImode. Anyways the fix is not specify if we should use target as an hint here.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 Andrew Pinski changed: What|Removed |Added Depends on||108847 --- Comment #13 from Andrew Pinski --- (In reply to Georg-Johann Lay from comment #12) > ...my bad, I tried "extzv", which didn't work out as expected. > > So we have shifts : bit-extract = 3 : 2. > > Is it worth trying to write combine patterns to catch this? Or will there > be better lowering for the remaining caases? So for the `a < 0` (which is the same as `a >> negbit` which you wrote originally; cset_32bit31, cset_24bit23 and cset_32bit31_not), I noticed it got expanded using arithmetic shift right followed by an `and` rather than a logical shift right, even on x86. PR 108847 shows the behavior there. I will go and look into fixing that PR in next few days. I will check back the resulting AVR code generation (and the initial RTL) for those 3 cases after I fix the shifting issue to see if there is anything else to do. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847 [Bug 108847] unnecessary bitwise AND on boolean types and shifting of the "sign" bit
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
Andrew Pinski changed:
What|Removed |Added
Depends on|108847 |
--- Comment #14 from Andrew Pinski ---
Actually I take back on what is going on those 3. But I will be looking into
it.
x.0_1 = (signed long) x_4(D);
_2 = x.0_1 >> 31;
_3 = (unsigned char) _2;
_5 = _3 & 1;
That is what is causing arithmetic shift but we only need the first bit in the
end.
If we optimized that to:
x.0_1 = (unsigned long) x_4(D);
_2 = x.0_1 >> 31;
_3 = (unsigned char) _2;
_5 = _3 & 1;
similar to:
uint8_t cset_32bit31_1 (uint32_t x)
{
if (x & (1ull<<31))
return 1;
return 0;
}
Then there is still an issue. I have some ideas of how to handling the first
case but I might need a few weeks.
Note GCC 14 code generation here is similar now to GCC 4.5.x so that is the
good news that this part is not a regression.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847
[Bug 108847] unnecessary bitwise AND on boolean types and shifting of the
"sign" bit
[Bug analyzer/109437] -Wanalyzer-out-of-bounds is emitted at most once per frame.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109437 Benjamin Priour changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Benjamin Priour --- I mark it as fixed as my current hotfix on PR109439 proved this one was indeed just a consequence of it, and not a standalone bug. *** This bug has been marked as a duplicate of bug 109439 ***
[Bug analyzer/109439] RFE: Spurious -Wanalyzer-use-of-uninitialized-value tagging along -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109439 --- Comment #1 from Benjamin Priour --- *** Bug 109437 has been marked as a duplicate of this bug. ***
[Bug analyzer/109432] [meta-bug] tracker bug for issues with -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109432 Bug 109432 depends on bug 109437, which changed state. Bug 109437 Summary: -Wanalyzer-out-of-bounds is emitted at most once per frame. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109437 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug libobjc/109913] [14 regression] r14-976-g9907413a3a6aa3 causes more than 300 objc/objc++ failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 --- Comment #4 from rep.dot.nop at gmail dot com --- On 20 May 2023 00:39:45 CEST, "pinskia at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 > >Andrew Pinski changed: > > What|Removed |Added > > Target Milestone|--- |14.0 > Ok. I don't have time for this, let's revert it.
[Bug libobjc/109913] [14 regression] r14-976-g9907413a3a6aa3 causes more than 300 objc/objc++ failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 --- Comment #5 from Andrew Pinski --- (In reply to rep.dot@gmail.com from comment #4) > On 20 May 2023 00:39:45 CEST, "pinskia at gcc dot gnu.org" > wrote: > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 > > > >Andrew Pinski changed: > > > > What|Removed |Added > > > > Target Milestone|--- |14.0 > > > > Ok. I don't have time for this, let's revert it. As I mentioned the patch to libobjc is simple so please don't revert it just yet. I just need someone to test the patch I attached.
[Bug middle-end/108847] unnecessary bitwise AND on boolean types and shifting of the "sign" bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847 --- Comment #3 from Andrew Pinski --- So looking into this a little futher. The problem is VRP turns !=0 into (bool) and then expand comes along and decides that a cast to bool needs &1 because well it just. I am going to look into see if I can remove the &1 there ...
[Bug middle-end/108847] [10/11/12/13/14 Regression] unnecessary bitwise AND on boolean types and shifting of the "sign" bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847 Andrew Pinski changed: What|Removed |Added Severity|enhancement |trivial
[Bug middle-end/108847] [10/11/12/13/14 Regression] unnecessary bitwise AND on boolean types and shifting of the "sign" bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||deferred
[Bug middle-end/108847] [10/11/12/13/14 Regression] unnecessary bitwise AND on boolean types and shifting of the "sign" bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847 --- Comment #4 from Andrew Pinski --- VRP starting doing this in GCC 5: Folding statement: _5 = _4 != 0; Folded into: _5 = (bool) _4;
[Bug libobjc/109913] [14 regression] r14-976-g9907413a3a6aa3 causes more than 300 objc/objc++ failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 --- Comment #6 from rep.dot.nop at gmail dot com --- On 21 May 2023 01:27:29 CEST, "pinskia at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 > >--- Comment #5 from Andrew Pinski --- >(In reply to rep.dot@gmail.com from comment #4) >> On 20 May 2023 00:39:45 CEST, "pinskia at gcc dot gnu.org" >> wrote: >> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 >> > >> >Andrew Pinski changed: >> > >> > What|Removed |Added >> > >> > Target Milestone|--- |14.0 >> > >> >> Ok. I don't have time for this, let's revert it. > >As I mentioned the patch to libobjc is simple so please don't revert it just >yet. I just need someone to test the patch I attached. > Yeah, but it's a can of worms. I'd revert it, but if anyone wants to have a look, then fine.
[Bug middle-end/109919] [14 Regression] ICE on valid code at -O2 and -O3 with "-fno-tree-dce -fno-tree-vrp" on x86_64-linux-gnu: in emit_move_insn, at expr.cc:4224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109919 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:ee0f1f2294baaecfa0c038fe7e8361949d1ebd68 commit r14-1020-gee0f1f2294baaecfa0c038fe7e8361949d1ebd68 Author: Andrew Pinski Date: Sat May 20 21:14:23 2023 + Fix PR 109919: ICE in emit_move_insn with some bit tests The problem is I used expand_expr with the target but we don't want to use the target here as it is the wrong mode for the original expression. The testcase would ICE deap down while trying to do a move to use the target. Anyways just calling expand_expr with NULL_EXPR fixes the issue. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. PR middle-end/109919 gcc/ChangeLog: * expr.cc (expand_single_bit_test): Don't use the target for expand_expr. gcc/testsuite/ChangeLog: * gcc.c-torture/compile/pr109919-1.c: New test.
[Bug middle-end/109919] [14 Regression] ICE on valid code at -O2 and -O3 with "-fno-tree-dce -fno-tree-vrp" on x86_64-linux-gnu: in emit_move_insn, at expr.cc:4224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109919 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #15 from Andrew Pinski --- So there is another way of fixing this. take: Trying 6 -> 12: 6: r49:SI=r50:SI>>0x1f REG_DEAD r50:SI 12: r24:QI=r49:SI#0&0x1 REG_DEAD r49:SI Failed to match this instruction: (set (reg/i:QI 24 r24) (neg:QI (subreg:QI (ashiftrt:SI (reg:SI 50) (const_int 31 [0x1f])) 0))) It is correct but maybe the subreg should combine with the shift and change it just (lshiftrt:QI (subreg:QI (reg:SI 50)) (const_int 7)) . Once combine does that, then maybe that could match ... What is interesting is subreg1 does the splitting for HI mode . Maybe Roger could look improving that since he was touching it recently for avr IIRC.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #16 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #14)
> Actually I take back on what is going on those 3. But I will be looking into
> it.
>
>
> x.0_1 = (signed long) x_4(D);
> _2 = x.0_1 >> 31;
> _3 = (unsigned char) _2;
> _5 = _3 & 1;
we could pattern match this on the gimple using something like:
(simplify
(bit_and (convert? (rshift (nop_convert? @1) INTEGER_CST@2)) integer_onep)
(if (wi::to_wide (@2) == TYPE_PRECISION (TREE_TYPE (@0)) - 1)
(with
{ tree utype = unsigned_type_for (type); }
(convert (rshift (convert:utype @1) @2)))
But that still fails because combine really does not like subregs:
Trying 6 -> 12:
6: r47:SI=r48:SI 0>>0x1f
REG_DEAD r48:SI
12: r24:QI=r47:SI#0
REG_DEAD r47:SI
Failed to match this instruction:
(set (reg/i:QI 24 r24)
(subreg:QI (lshiftrt:SI (reg:SI 48)
(const_int 31 [0x1f])) 0))
