[Bug c/111421] New: constexpr not working with array subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111421
Bug ID: 111421
Summary: constexpr not working with array subscript
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: malekwryyy at gmail dot com
Target Milestone: ---
Created attachment 55903
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55903=edit
the c program that results in the error
compiled with: -std=c2x -Wall -Wextra
When trying to subscript a constexpr array, the compiler says the expression is
not constant.
I would expect if the index is an integer literal (or a constexpr integer) then
the resulting expression should still be constant.
I tried this with -std=c2x and -std=gnu2x
// program start
typedef struct S { int i; } S;
constexpr int a = (constexpr S){.i = 3}.i; // works as expected
constexpr int b = ( &(constexpr S){.i = 3} )->i; // works as expected
constexpr int y = (constexpr int[]){3}[0]; // doesn't work. Compiler says
expression not constant
int main()
{
return 0;
}
// program end
the compiler error I get is:
:7:19: error: initializer element is not constant
7 | constexpr int y = (constexpr int[]){3}[0]; // doesn't work. Compiler
says expression not constant
| ^
:7:15: warning: 'y' defined but not used [-Wunused-const-variable=]
7 | constexpr int y = (constexpr int[]){3}[0]; // doesn't work. Compiler
says expression not constant
| ^
:5:15: warning: 'b' defined but not used [-Wunused-const-variable=]
5 | constexpr int b = ( &(constexpr S){.i = 3} )->i; // works as expected
| ^
:3:15: warning: 'a' defined but not used [-Wunused-const-variable=]
3 | constexpr int a = (constexpr S){.i = 3}.i; // works as expected
| ^
Compiler returned: 1
[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > Actually we should transform it into > ((convert)zero_one_valued_p) & (a != 0) > > Or ^1 for the == 0 case ... > > This should allow for better code I think. Or better yet: (((Convert)cmp) & b) != 0 Into cmp & (b!=0) Icmp for == 0. Now I have seen that before too.
[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992 --- Comment #7 from Andrew Pinski --- Actually we should transform it into ((convert)zero_one_valued_p) & (a != 0) Or ^1 for the == 0 case ... This should allow for better code I think.
[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #6 from Andrew Pinski ---
One way of fixing this is:
/* Transform (a * { 0 or 1 }) !=/== 0 into (a & { 0 or 1 }) !=/== 0. */
(for cmp (ne eq)
(simplify
(cmp (mult:cs @0 zero_one_valued_p@1) integer_zerop@2)
(cmp (bit_and @0 @1) @2)))
That is (a*zero_one_valued_p)!=0 transform it into (a & zero_one_valued_p) != 0
if the multiply was single use.
That is how I am going to fix this.
[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
Andrew Pinski changed:
What|Removed |Added
Target Milestone|14.0|13.3
Summary|[14 Regression] Dead Code |[13/14 Regression] missed
|Elimination Regression at |VRP optimization due to
|-O3 since |transformation of `a &
|r14-1654-g7ceed7e3e29 |-zero_one_valued_p` into `a
||* zero_one_valued_p`
--- Comment #5 from Andrew Pinski ---
Hmm, I think this is a ranger issue really.
Take:
```
int f(unsigned b, short c)
{
int bt = b;
int bt1 = bt;
int t = bt1 & -(c!=0);
// int t = bt1 * (c!=0);
if (!t) return 0;
foo(bt == 0);
return 0;
}
```
That `bt == 0` should be figured out that is 0 there. We could figure that out
in GCC 12 even. But in GCC 13+ we could not.
That is traced back to r13-793-g8fb94fc6097c but really the ranger should
figure out if you have a*b != 0, then both a and b should be non-zero ...
But currently that is not support
It looks like we only handle `a & b` that way ...
[Bug target/110665] RISC-V do not preserve vector registers in interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110665 --- Comment #3 from Lehua Ding --- Fixed by the commit https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fdd59c0f73e9e681cd5f4d0eee2dd58d60d8dbe1 with compiler option --param=riscv-vector-abi. Confirmed after support riscv-vector-abi in default.
[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 #17 from Kewen Lin ---
(In reply to Mathieu Malaterre from comment #16)
> Interesting, the following works for me:
>
> % /usr/bin/c++ -O1 -mcpu=power8 -mno-htm -flto=auto -c skeleton_test.cc
Yeah, the suggestion on an extra option -mno-htm is for command line options,
since they are used for compiling the callee PreventElision.
It makes that:
- the callee(PreventElision): -mcpu=power8 -mno-htm
- caller: -mcpu=power10
caller doesn't have the htm capability (as it's compiled with p10 which drops
htm), but the callee claims it doesn't need htm with -mno-htm, so it's safe to
do the inlining.
If you want to adjust the pragma
#define HWY_BEFORE_NAMESPACE() HWY_PUSH_ATTRIBUTES(",cpu=power10")
, it should be:
#define HWY_BEFORE_NAMESPACE() HWY_PUSH_ATTRIBUTES(",cpu=power10,htm")
it pretends that the caller has the htm support, then it's also fine.
[Bug target/111381] RISC-V: missed autovec MULH for signed * unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111381 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Lehua Ding : https://gcc.gnu.org/g:68cb873fd360dbb64f2a6dfb28e79399ff99d07d commit r14-4008-g68cb873fd360dbb64f2a6dfb28e79399ff99d07d Author: Lehua Ding Date: Thu Sep 14 23:35:42 2023 +0800 RISC-V: Support combine extend and reduce sum to widen reduce sum This patch add combine pattern to combine extend and reduce sum to widen reduce sum. The pattern in autovec.md was adjusted as needed. Note that the current vectorization cannot generate reduce operand which is LMUL=M8, because this means that we need an LMUL=M16 for the extended operand, which is currently not possible. So I've added VI_QHS_NO_M8 and VF_HS_NO_M8 mode iterator, which exclude mode which is LMUL=M8. PR target/111381 gcc/ChangeLog: * config/riscv/autovec-opt.md (*reduc_plus_scal_): New combine pattern. (*fold_left_widen_plus_): Ditto. (*mask_len_fold_left_widen_plus_): Ditto. * config/riscv/autovec.md (reduc_plus_scal_): Change from define_expand to define_insn_and_split. (fold_left_plus_): Ditto. (mask_len_fold_left_plus_): Ditto. * config/riscv/riscv-v.cc (expand_reduction): Support widen reduction. * config/riscv/vector-iterators.md (UNSPEC_WREDUC_SUM): Add new iterators and attrs. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/widen/widen_reduc-1.c: New test. * gcc.target/riscv/rvv/autovec/widen/widen_reduc_order-1.c: New test. * gcc.target/riscv/rvv/autovec/widen/widen_reduc_order-2.c: New test. * gcc.target/riscv/rvv/autovec/widen/widen_reduc_order_run-1.c: New test. * gcc.target/riscv/rvv/autovec/widen/widen_reduc_order_run-2.c: New test. * gcc.target/riscv/rvv/autovec/widen/widen_reduc_run-1.c: New test.
[Bug target/111418] ICE with the CVE-2023-4039 patches applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #4 from Sam James --- Thanks, your test case is nicer than mine in the original.
[Bug sanitizer/80998] Implement -fsanitize=pointer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80998 --- Comment #11 from Andrew Pinski --- https://reviews.llvm.org/D33305
[Bug target/111420] relocation truncated to fit: R_RISCV_JAL against `.L12287'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420 AK changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #5 from AK --- Created: https://sourceware.org/bugzilla/show_bug.cgi?id=30855
[Bug target/111420] relocation truncated to fit: R_RISCV_JAL against `.L12287'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420 --- Comment #4 from AK --- good catch. By mistake i built at -O0, i wanted to build at -O3.
[Bug target/111420] relocation truncated to fit: R_RISCV_JAL against `.L12287'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420 --- Comment #3 from Andrew Pinski --- Or just this function is huge for -O0 in which case riscv does not have a good code model for that case
[Bug target/111420] relocation truncated to fit: R_RISCV_JAL against `.L12287'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420 --- Comment #2 from Andrew Pinski --- This might be a binutils bug ...
[Bug c/111420] relocation truncated to fit: R_RISCV_JAL against `.L12287'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420 --- Comment #1 from AK --- I got this error while building clang (ninja clang) on a riscv machine. root@lpi4a:~# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-linux-gnu/13/lto-wrapper Target: riscv64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 13.1.0-6' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --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-libitm --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 --disable-werror --disable-multilib --with-arch=rv64gc --with-abi=lp64d --enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu --target=riscv64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=32 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.1.0 (Debian 13.1.0-6) -- root@lpi4a:~# uname -a Linux lpi4a 5.10.113-g7b352f5ac2ba #1 SMP PREEMPT Wed Apr 12 12:06:11 UTC 2023 riscv64 GNU/Linux
[Bug c/111420] New: relocation truncated to fit: R_RISCV_JAL against `.L12287'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111420 Bug ID: 111420 Summary: relocation truncated to fit: R_RISCV_JAL against `.L12287' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hiraditya at msn dot com Target Milestone: --- CGBuiltin.cpp:(.text._ZN5clang7CodeGen15CodeGenFunction20EmitRISCVBuiltinExprEjPKNS_8CallExprENS0_15ReturnValueSlotE+0x10d0): relocation truncated to fit: R_RISCV_JAL against `.L12287' command: : && /usr/bin/c++ -fPIC -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -Wl,-z,defs -Wl,-z,nodelete -Wl,-rpath-link,/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/build/./lib -Wl,--gc-sections -shared -Wl,-soname,libclangCodeGen.so.18git -o lib/libclangCodeGen.so.18git tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/ABIInfo.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/ABIInfoImpl.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/BackendUtil.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGAtomic.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGBlocks.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGBuiltin.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGCUDANV.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGCUDARuntime.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGCXX.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGCXXABI.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGCall.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGClass.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGCleanup.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGCoroutine.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGDebugInfo.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGDecl.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGDeclCXX.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGException.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGExpr.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGExprAgg.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGExprCXX.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGExprComplex.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGExprConstant.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGExprScalar.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGGPUBuiltin.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGHLSLRuntime.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGLoopInfo.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGNonTrivialStruct.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGObjC.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGObjCGNU.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGObjCMac.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGObjCRuntime.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGOpenCLRuntime.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGOpenMPRuntime.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGOpenMPRuntimeGPU.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGRecordLayoutBuilder.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGStmt.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGStmtOpenMP.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGVTT.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CGVTables.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenABITypes.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenAction.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenFunction.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenModule.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenPGO.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenTBAA.cpp.o tools/clang/lib/CodeGen/CMakeFiles/obj.clangCodeGen.dir/CodeGenTypes.cpp.o
[Bug tree-optimization/110992] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1654-g7ceed7e3e29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992
--- Comment #4 from Andrew Pinski ---
What we had before in GCC 13:
# RANGE [irange] unsigned short [0, 1] NONZERO 0x1
d.3_19 = (unsigned short) _3;
_21 = -d.3_19;
_22 = (short intD.17) _21;
_6 = (short intD.17) b.0_1;
_7 = _6 & _22;
Which then after r14-1654-g7ceed7e3e29 gives us:
_t = (short intD.17) d.3_19
_7 = _6 * _t
What we get after that match patch:
_3 = c.1_2 != 0;
_25 = (short intD.17) _3;
_22 = -_25;
_6 = (short intD.17) b.0_1;
_7 = _6 & _22;
That is we lose the range information.
If I add this to match.pd:
```
diff --git a/gcc/match.pd b/gcc/match.pd
index 97db0eb5f25..e68e2c57e25 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2181,6 +2181,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& (TYPE_UNSIGNED (type)
|| TYPE_PRECISION (type) > 1
+(match zero_one_valued_p
+ (convert@0 zero_one_valued_p@1))
+
/* Transform { 0 or 1 } * { 0 or 1 } into { 0 or 1 } & { 0 or 1 }. */
(simplify
(mult zero_one_valued_p@0 zero_one_valued_p@1)
```
Then this fails again.
I am thinking about adding this anyways so I am going to keep this one open.
[Bug tree-optimization/110992] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1654-g7ceed7e3e29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992 --- Comment #3 from Andrew Pinski --- So this was fixed by accident via r14-3721-ge6bcf83989478348428c732 .
[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 --- Comment #11 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-September/059756.html
[Bug c++/111419] Eager instantiation of function return type in concept causes compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111419
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2023-09-14
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
CC||ppalka at gcc dot gnu.org
Keywords||rejects-valid
Ever confirmed|0 |1
--- Comment #1 from Patrick Palka ---
Confirmed, not a regression. Related C++98 testcase:
template
struct A { T t; };
void f(A& a) {
a;
}
[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #10 from anlauf at gcc dot gnu.org --- I am working on a patch.
[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Andrew Pinski --- Invalid as it is hw issue it seems
[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111393 --- Comment #9 from AK --- i think it is okay to close this bug as this doesn't seem to be related to gcc.
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 Richard Sandiford changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-14 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from Richard Sandiford --- Working on a fix.
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
--- Comment #7 from Richard Sandiford ---
It's proving difficult to generate a reliable reproducer from
pure C code, due to the ways in which we handle out-of-range
offsets. But FWIW, here's one that uses the RTL frontend,
compiled with -O -fdisable-rtl-postreload -fpeephole2:
extern int data[];
void __RTL (startwith ("ira")) foo (void *ptr)
{
(function "foo"
(param "ptr"
(DECL_RTL (reg/v:DI <0> [ ptr ]))
(DECL_RTL_INCOMING (reg/v:DI x0 [ ptr ]))
) ;; param "ptr"
(insn-chain
(block 2
(edge-from entry (flags "FALLTHRU"))
(cnote 3 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 4 (set (reg:DI <0>) (reg:DI x0)))
(insn 5 (set (reg:DI <1>)
(plus:DI (reg:DI <0>) (const_int 768
(insn 6 (set (mem:SI (plus:DI (reg:DI <0>)
(const_int 508)) [1 +508 S4 A4])
(const_int 0)))
(insn 7 (set (mem:SI (plus:DI (reg:DI <1>)
(const_int -256)) [1 +512 S4 A4])
(const_int 0)))
(edge-to exit (flags "FALLTHRU"))
) ;; block 2
) ;; insn-chain
) ;; function
}
(This one doesn't rely on -fstack-protector-strong, or on the recent
patches.)
The problem is that the LDP/STP formation code is too loose in the
check for valid addresses: it thinks it's enough for the second address
to be valid, even though that's not the one used in the STP.
[Bug tree-optimization/111414] [14 Regression] ICE in verify_gimple failed since r14-3719-gb34f3736356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Septemb ||er/630366.html Keywords||patch --- Comment #3 from Andrew Pinski --- PAtch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630366.html
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 --- Comment #6 from Richard Sandiford --- Thanks, I can reproduce it now. I had been trying with tip of trunk, but it seems to have gone latent after 9ea74d235c7e7816b996a17c61288f02ef767985.
[Bug c++/111419] New: Eager instantiation of function return type in concept causes compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111419
Bug ID: 111419
Summary: Eager instantiation of function return type in concept
causes compilation error
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code fails to compile on GCC:
template
auto invoke(F f) -> decltype(f());
template
concept invocable = requires(F&& f) {
::invoke(f);
};
struct Incomplete;
template struct Holder { T t; };
static_assert(invocable& ()>);
It produces the following error on GCC:
: In instantiation of 'struct Holder':
:6:11: required from here
:10:37: error: 'Holder::t' has incomplete type
10 | template struct Holder { T t; };
| ^
:9:8: note: forward declaration of 'struct Incomplete'
9 | struct Incomplete;
|^~
Compiler returned: 1
My understanding is that this should be valid, because nothing actually
requires instantiating the return type of `f()` here, but I'm not sufficiently
well-versed in the details of concepts to know for sure.
Clang and MSVC accept the code.
Godbolt: https://godbolt.org/z/9G5zj47an
[Bug target/111404] [AArch64] 128-bit __sync_val_compare_and_swap is not atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111404 Wilco changed: What|Removed |Added Last reconfirmed||2023-09-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target|arm64-*-* |aarch64 --- Comment #1 from Wilco --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630198.html
[Bug target/111416] [Armv7/v8 Mixing Bug]: 64-bit Sequentially Consistent Load can be Reordered before Store of RMW when v7 and v8 Implementations are Mixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111416 Wilco changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||wilco at gcc dot gnu.org Last reconfirmed||2023-09-14 Target||arm-* Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org Component|translation |target --- Comment #1 from Wilco --- This will be fixed by https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629607.html
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 --- Comment #5 from Sam James --- (In reply to Richard Sandiford from comment #4) > I'm struggling to reproduce this. Do you know what your -mcpu=native expands > to? # arch=native; for t in param target; do cmd="gcc -Q -O2 -mcpu=$arch --help=$t"; diff -U0 <(LANG=C $cmd -mcpu=generic) <(LANG=C $cmd -mcpu=native); done --- /dev/fd/63 2023-09-14 16:31:42.423739708 - +++ /dev/fd/62 2023-09-14 16:31:42.423739708 - @@ -8 +8 @@ - -mcpu= generic + -mcpu= ares+crc+crypto+ssbs Also needs -fstack-protector-strong. But you're also welcome to have access to the environment if needed. ``` $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/14/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-14.0.0./work/gcc-14.0.0./configure --host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu --prefix=/usr --bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/14 --includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/14/include --datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14 --mandir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14/man --infodir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/14/info --with-gxx-include-dir=/usr/lib/gcc/aarch64-unknown-linux-gnu/14/include/g++-v14 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/14/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 14.0.0 p, commit d0b55776a4e1d2f293db5ba0e4a04aefed055ec4' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --without-isl --enable-default-pie --enable-host-pie --disable-host-bind-now --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20230913 (experimental) 3af2af15798cb6243e2643f98f62c9270b1ca5d2 (Gentoo 14.0.0 p, commit d0b55776a4e1d2f293db5ba0e4a04aefed055ec4) ```
[Bug target/111418] ICE with the CVE-2023-4039 patches applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418 --- Comment #3 from Martin Jansa --- Reproduced with: 13.2.1 20230914 (revision 9cddebd822aeff9b7c0e9951909d5ec96c959e4f) and 14.0.0 20230914 (experimental) (revision 8517317ce8e9fbea0b4c7a8f87a86d07d95dc8c7) as well.
[Bug target/105928] [AArch64] 64-bit constants with same high/low halves can use ADD lsl 32 (-Os at least)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105928 --- Comment #3 from Wilco --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630358.html
[Bug target/111362] [14 Regression] '-fcompare-debug' failure (length) with -O -fno-tree-ch --param=max-completely-peel-times=0 -march=rv64iv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111362
--- Comment #2 from Zdenek Sojka ---
Thank you the fix; the testcase is still failing with a bit different flags
though:
Adding -fno-dce -fschedule-insns:
$ riscv64-unknown-linux-gnu-gcc -O -fno-tree-ch
--param=max-completely-peel-times=0 -march=rv64iv -fcompare-debug -fno-dce
-fschedule-insns testcase.c -save-temps
riscv64-unknown-linux-gnu-gcc: error: testcase.c: '-fcompare-debug' failure
$ diff -u *gkd
--- a-testcase.c.gkd2023-09-14 17:09:28.262936149 +0200
+++ a-testcase.gk.c.gkd 2023-09-14 17:09:28.342935710 +0200
@@ -51,14 +51,6 @@
(sign_extend:DI (plus:SI (reg:SI 8 s0 [orig:134 ivtmp_6 ] [134])
(const_int -1 [0x] "testcase.c":3:26
discrim 1# {addsi3_extended}
(nil))
-(insn # 0 0 (set (reg:DI 11 a1)
-(const_int 0 [0])) "testcase.c":4:5# {*movdi_64bit}
- (nil))
-(insn # 0 0 (set (reg:DI 10 a0)
-(lo_sum:DI (reg/f:DI 9 s1 [138])
-(symbol_ref/f:DI ("*.LC0") [flags 0x82] )))
"testcase.c":4:5# {*lowdi}
- (expr_list:REG_EQUAL (symbol_ref/f:DI ("*.LC0") [flags 0x82] )
-(nil)))
(jump_insn # 0 0 (set (pc)
(if_then_else (ne (reg:DI 8 s0 [orig:134 ivtmp_6 ] [134])
(const_int 0 [0]))
@@ -104,6 +96,14 @@
(barrier # 0 0)
(code_label # 0 0 3 (nil) [1 uses])
(note # 0 0 [bb 5] NOTE_INSN_BASIC_BLOCK)
+(insn # 0 0 (set (reg:DI 11 a1)
+(const_int 0 [0])) "testcase.c":4:5# {*movdi_64bit}
+ (nil))
+(insn # 0 0 (set (reg:DI 10 a0)
+(lo_sum:DI (reg/f:DI 9 s1 [138])
+(symbol_ref/f:DI ("*.LC0") [flags 0x82] )))
"testcase.c":4:5# {*lowdi}
+ (expr_list:REG_EQUAL (symbol_ref/f:DI ("*.LC0") [flags 0x82] )
+(nil)))
(call_insn # 0 0 (parallel [
(set (reg:DI 10 a0)
(call (mem:SI (symbol_ref:DI ("printf") [flags 0x41]
) [ __builtin_printf S4 A32])
[Bug middle-end/111401] Middle-end: Missed optimization of MASK_LEN_FOLD_LEFT_PLUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401 --- Comment #6 from Robin Dapp --- Created attachment 55902 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55902=edit Tentative You're referring to the case where we have init = -0.0, the condition is false and we end up wrongly doing -0.0 + 0.0 = 0.0? I suppose -0.0 the proper neutral element for PLUS (and WIDEN_SUM?) when honoring signed zeros? And 0.0 for MINUS? Doesn't that also depend on the rounding mode? neutral_op_for_reduction could return a -0 for PLUS if we honor it for that type. Or is that too intrusive? Guess I should add a test case for that as well. Another thing is that swapping operands is not as easy with COND_ADD because the addition would be in the else. I'd punt for that case for now. Next problem - might be a mistake on my side. For avx512 we create a COND_ADD but the respective MASK_FOLD_LEFT_PLUS is not available, causing us to create numerous vec_extracts as fallback that increase the cost until we don't vectorize anymore. Therefore I added a vectorized_internal_fn_supported_p (IFN_FOLD_LEFT_PLUS, TREE_TYPE (lhs)). SLP paths and ncopies != 1 are excluded as well. Not really happy with how the patch looks now but at least the testsuites on aarch and x86 pass.
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 --- Comment #4 from rsandifo at gcc dot gnu.org --- I'm struggling to reproduce this. Do you know what your -mcpu=native expands to?
[Bug tree-optimization/111415] False positive array-bounds warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111415 --- Comment #1 from Andrew Pinski --- I am pretty sure there is a dup of this bug already.
[Bug c/111417] Incorrect optimization when linker-generated symbols are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111417 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- You either need to use -fno-delete-null-pointer-checks if you want symbols to be at address 0 . Or you mark MRAM2_region_size as being weak which allows the symbol to be null and the check for 0 to be there still.
[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411 Andrew Pinski changed: What|Removed |Added CC||ross at burtonini dot com --- Comment #3 from Andrew Pinski --- *** Bug 111418 has been marked as a duplicate of this bug. ***
[Bug target/111418] ICE with the CVE-2023-4039 patches applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 111411. *** This bug has been marked as a duplicate of bug 111411 ***
[Bug target/111418] ICE with the CVE-2023-4039 patches applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418
--- Comment #1 from Martin Jansa ---
https://github.com/csmith-project/creduce
reduced my test case to:
typedef a;
typedef struct {
short b __attribute__((aligned(8)))
} c;
typedef struct {
short d __attribute__((aligned(8)))
} e;
typedef struct {
int f;
a g
} h;
typedef struct {
int i;
int j;
a k;
h l;
e m;
a n;
a o;
a p;
a a;
a q
} r;
typedef struct {
r s;
r t;
r u;
r b;
a : 2, : 22, : 10;
a : 4, : 4, : 16;
struct {
char c;
c d;
c e
}
} v;
w;
x() {
v a;
w = __builtin_alloca(sizeof(e));
a.s.l.f = a.s.l.g = x;
ai(a);
}
$ aarch64-oe-linux-gcc --version
aarch64-oe-linux-gcc (GCC) 13.2.0
And to reproduce need to use -fstack-protector-strong as well as -O2:
$ aarch64-oe-linux-gcc -fstack-protector-strong -O2 -c test.c
... bunch of warnings ...
test.c:43:1: error: unrecognizable insn:
43 | }
| ^
(insn 87 27 29 2 (parallel [
(set (mem/c:SI (plus:DI (reg/f:DI 29 x29)
(const_int -260 [0xfefc])) [1 a.s.l.f+0 S4
A32])
(reg:SI 4 x4 [107]))
(set (mem/c:SI (plus:DI (reg/f:DI 29 x29)
(const_int -256 [0xff00])) [1 a.s.l.g+0 S4
A128])
(reg:SI 4 x4 [107]))
]) "test.c":42:3 -1
(expr_list:REG_DEAD (reg:SI 4 x4 [107])
(nil)))
during RTL pass: cprop_hardreg
test.c:43:1: internal compiler error: in extract_insn, at recog.cc:2791
0x18d8d3b internal_error(char const*, ...)
???:0
0x6b3c5a fancy_abort(char const*, int, char const*)
???:0
0x692708 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x69272a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
0xbe23ef extract_constrain_insn(rtx_insn*)
???:0
Will check with gcc trunk if it's still reproducible there. gcc-12.3.0 shows
the same ICE while gcc-11.4.0 built the same code OK.
[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 #16 from Mathieu Malaterre --- Interesting, the following works for me: % /usr/bin/c++ -O1 -mcpu=power8 -mno-htm -flto=auto -c skeleton_test.cc
[Bug tree-optimization/111414] [14 Regression] ICE in verify_gimple failed since r14-3719-gb34f3736356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> I see what I did wrong.
> Looks like I need to check to make sure the integer_onep is a non vector.
That is:
diff --git a/gcc/match.pd b/gcc/match.pd
index 07ffd831132..97db0eb5f25 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4206,8 +4206,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* `(1 >> X) != 0` -> `X == 0` */
/* `(1 >> X) == 0` -> `X != 0` */
(simplify
- (cmp (rshift integer_onep @0) integer_zerop)
- (icmp @0 { build_zero_cst (TREE_TYPE (@0)); })))
+ (cmp (rshift integer_onep@1 @0) integer_zerop)
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@1)))
+(icmp @0 { build_zero_cst (TREE_TYPE (@0)); }
/* (CST1 << A) == CST2 -> A == ctz (CST2) - ctz (CST1)
(CST1 << A) != CST2 -> A != ctz (CST2) - ctz (CST1)
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164 --- Comment #18 from Andrew Pinski --- I think the only thing left is supporting floating point.
[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106164 --- Comment #17 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:5e4a248b03f01f422b0dbc9e1464eb6c2f2bafc6 commit r14-3995-g5e4a248b03f01f422b0dbc9e1464eb6c2f2bafc6 Author: Andrew Pinski Date: Wed Sep 13 16:50:33 2023 -0700 MATCH: Support `(a != (CST+1)) & (a > CST)` optimizations Even though this is done via reassocation, match can support these with a simple change to detect that the difference is just one. This allows to optimize these earlier and even during phiopt for an example. This patch adds the following cases: (a != (CST+1)) & (a > CST) -> a > (CST+1) (a != (CST-1)) & (a < CST) -> a < (CST-1) (a == (CST-1)) | (a >= CST) -> a >= (CST-1) (a == (CST+1)) | (a <= CST) -> a <= (CST+1) Canonicalizations of comparisons causes this case to show up more. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/106164 gcc/ChangeLog: * match.pd (`(X CMP1 CST1) AND/IOR (X CMP2 CST2)`): Expand to support constants that are off by one. gcc/testsuite/ChangeLog: * gcc.dg/pr21643.c: Update test now that match does the combing of the comparisons. * gcc.dg/tree-ssa/cmpbit-5.c: New test. * gcc.dg/tree-ssa/phi-opt-35.c: New test.
[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 #15 from Mathieu Malaterre ---
For some reason the no-htm flag does not seems to work in my case:
% /usr/bin/c++ -O1 -mcpu=power8 -flto=auto -c skeleton_test.cc
skeleton_test.cc: In member function 'TestFloorLog2::operator() >(int, detail::CappedTagChecker)void':
skeleton_test.cc:5:44: error: inlining failed in call to 'always_inline'
'hwy::PreventElision(int)': target specific option mismatch
5 | inline __attribute__((always_inline)) void PreventElision(int output) {
|^~
skeleton_test.cc:36:26: note: called from here
36 | hwy::PreventElision(sum);
| ~~~^
with:
% cat skeleton_test.cc
#include
#define HWY_PRAGMA(tokens) _Pragma(#tokens)
namespace hwy {
#define HWY_PUSH_ATTRIBUTES(targets_str) HWY_PRAGMA(GCC target targets_str)
inline __attribute__((always_inline)) void PreventElision(int output) {
asm("" : "+r"(output) : : "memory");
}
} // namespace hwy
#if HWY_TARGET == HWY_PPC10
#define HWY_BEFORE_NAMESPACE() HWY_PUSH_ATTRIBUTES(",cpu=power10,no-htm")
#endif
HWY_BEFORE_NAMESPACE() namespace detail {
template struct CappedTagChecker {};
}
template
using CappedTag = detail::CappedTagChecker;
template size_t Lanes(D);
template struct ForeachCappedR {
static void Do(size_t min_lanes, size_t max_lanes) {
CappedTag d;
Test()(int(), d);
Do(min_lanes, max_lanes);
}
};
template struct ForPartialVectors {
template void operator()(T t) {
(void)t;
ForeachCappedR::Do(1, 1);
}
};
struct TestFloorLog2 {
template void operator()(T, DF df) {
size_t count = Lanes(df);
int sum;
for (size_t i; count; ++i)
hwy::PreventElision(sum);
}
};
void TestAllFloorLog2() { ForPartialVectors()(float()); }
[Bug c++/111272] [13/14 Regression] Truncated error messages with -std=c++23 and -std=c++26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111272 --- Comment #5 from Marek Polacek --- (In reply to Paul Keir from comment #4) > I believe P2448R2 would only allow the code, without the static_assert. > Explicitly calling `test()`, `Jam::Jam()` and then `Jam::ft()` here would > mean evaluating a non-constexpr function (i.e. `ft`). ft is > *constexpr-suitable*, but still needs the `constexpr` specifier when it is > constant evaluated. I agree.
[Bug tree-optimization/111414] [14 Regression] ICE in verify_gimple failed since r14-3719-gb34f3736356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-valid-code Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2023-09-14 --- Comment #1 from Andrew Pinski --- I see what I did wrong. Looks like I need to check to make sure the integer_onep is a non vector.
[Bug target/111231] [13/14 Regression] armhf: Miscompilation at O2 level (O1 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 --- Comment #6 from Mathieu Malaterre --- Code in #c4 and #c5 are bogus. They also fails with g++-12. Let me start my cvise machinery over again (may take some time).
[Bug c++/111357] [11/12/13/14 Regression] __integer_pack fails to work with values of dependent type convertible to integers in noexcept context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:27fce25cc07f7efe11db05eb2fe74a465c41475f commit r11-11008-g27fce25cc07f7efe11db05eb2fe74a465c41475f Author: Jonathan Wakely Date: Thu Sep 14 09:18:34 2023 +0100 libstdc++: Add workaround for std::make_integer_sequence bug [PR111357] The compiler bug has been fixed on trunk, but we need this workaround on the branches. libstdc++-v3/ChangeLog: PR c++/111357 * include/std/utility (make_integer_sequence): Add cast. * testsuite/20_util/integer_sequence/pr111357.cc: New test. (cherry picked from commit 7b0abd4a8ee9d2057febe443de67009dcdfe7574)
[Bug c++/111357] [11/12/13/14 Regression] __integer_pack fails to work with values of dependent type convertible to integers in noexcept context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:eba46f1137683b6f92ea6f95ed84e3e5cfc42377 commit r12-9877-geba46f1137683b6f92ea6f95ed84e3e5cfc42377 Author: Jonathan Wakely Date: Thu Sep 14 09:18:34 2023 +0100 libstdc++: Add workaround for std::make_integer_sequence bug [PR111357] The compiler bug has been fixed on trunk, but we need this workaround on the branches. libstdc++-v3/ChangeLog: PR c++/111357 * include/bits/utility.h (make_integer_sequence): Add cast. * testsuite/20_util/integer_sequence/pr111357.cc: New test. (cherry picked from commit 7b0abd4a8ee9d2057febe443de67009dcdfe7574)
[Bug c++/111357] [11/12/13/14 Regression] __integer_pack fails to work with values of dependent type convertible to integers in noexcept context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357 --- Comment #8 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7b0abd4a8ee9d2057febe443de67009dcdfe7574 commit r13-7817-g7b0abd4a8ee9d2057febe443de67009dcdfe7574 Author: Jonathan Wakely Date: Thu Sep 14 09:18:34 2023 +0100 libstdc++: Add workaround for std::make_integer_sequence bug [PR111357] The compiler bug has been fixed on trunk, but we need this workaround on the branches. libstdc++-v3/ChangeLog: PR c++/111357 * include/bits/utility.h (make_integer_sequence): Add cast. * testsuite/20_util/integer_sequence/pr111357.cc: New test.
[Bug c++/111357] [11/12/13/14 Regression] __integer_pack fails to work with values of dependent type convertible to integers in noexcept context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:557a858f2ead4ae8b64b157d7fd33830a81646d5 commit r14-3992-g557a858f2ead4ae8b64b157d7fd33830a81646d5 Author: Jonathan Wakely Date: Thu Sep 14 09:18:34 2023 +0100 libstdc++: Add testcase for std::make_integer_sequence bug [PR111357] The compiler bug has been fixed on trunk, but this adds a regression test for the library component. libstdc++-v3/ChangeLog: PR c++/111357 * testsuite/20_util/integer_sequence/pr111357.cc: New test.
[Bug target/111418] New: ICE with the CVE-2023-4039 patches applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418 Bug ID: 111418 Summary: ICE with the CVE-2023-4039 patches applied Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ross at burtonini dot com CC: Martin.Jansa at gmail dot com, rsandifo at gcc dot gnu.org Target Milestone: --- Target: aarch64 After integrating the -fstack-protector fixes in CVE-2023-4039 to gcc 13.2.0, a proprietary codebase is causing an ICE. error: unrecognizable insn: 2923 | } | ^ (insn 416 286 290 17 (parallel [ (set (mem/c:SI (plus:DI (reg/f:DI 29 x29) (const_int -260 [0xfefc])) [1 redacted.pixel_format+0 S4 A32]) (const_int 0 [0])) (set (mem/c:SI (plus:DI (reg/f:DI 29 x29) (const_int -256 [0xff00])) [1 redacted.pixel_value+0 S4 A128]) (reg/v:SI 22 x22 [orig:141 color ] [141])) ]) "TOPDIR/BUILD/work/redacted/redacted/redacted/git/redacted.c":2903:45 -1 (expr_list:REG_DEAD (reg/v:SI 22 x22 [orig:141 color ] [141]) (nil))) during RTL pass: cprop_hardreg TOPDIR/BUILD/work/redacted/redacted/redacted/git/redacted.c:2923:1: internal compiler error: in extract_insn, at recog.cc:2791 0x191624a internal_error(char const*, ...) ???:0 0x6bee26 fancy_abort(char const*, int, char const*) ???:0 0x697469 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ???:0 0x697485 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ???:0 0xbef198 extract_constrain_insn(rtx_insn*) ???:0 Copying Martin Jansa who reported this originally and is working on a minimal reproducer.
[Bug c/111417] New: Incorrect optimization when linker-generated symbols are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111417
Bug ID: 111417
Summary: Incorrect optimization when linker-generated symbols
are used
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cz.finn.cz at gmail dot com
Target Milestone: ---
Initial conditions are as follows:
1. In our linker script, we define a new symbol:
.mram2_data (NOLOAD):
{ ... } > MRAM2
MRAM2_region_size = LENGTH(MRAM2);
2. In our C code, we declare this symbol as follows:
extern U8 MRAM2_region_size[];
3. Under certain conditions, the value of the symbol is zero - as can be
observed in the .map file:
0xMRAM2_region_size = LENGTH
(MRAM2)
4. In our C code we have a function:
static void mramDeviceTest(U16 * memory, U32 size, const char * desc)
{
if((memory != NULL) && (size != 0u))
{
(void) rtos_kprintf(RTOS_LOGLEVEL_APP_INFO, "%s (%u @ %p) - test passed",
desc, size, memory);
}
else
{
(void) rtos_kprintf(RTOS_LOGLEVEL_APP_INFO, "%s (%u @ %p) - test skipped",
desc, size, memory);
}
}
5. This function is called as follows:
mramDeviceTest((U16 *) MRAM2_region_start, (uintptr_t) MRAM2_region_size,
"MRAM2");
Expected behaviour: since the argument 'size' equals to zero, one would expect,
that the function will print something like "MRAM2 (0 @ 6800) - test
skipped".
Real (erroneous) behaviour: the function is optimized in a strange way and
prints "MRAM2 (0 @ 6800) - test passed", i.e. the optimizer supposes that
'size' is zero although in reality it obviously isn't.
Work around: not to define the argument as 'U8 size' but as 'volatile U8 size'.
Code compiled with version 7.2.1 works as expected, code compiled with versions
10.3.1 and 12.2.0 fails.
Target architecture: ARM-R5, big endian
CFLAGS=-mcpu=cortex-r5 -mfloat-abi=hard -mfpu=vfpv3-d16 -mbig-endian -mthumb
-mthumb-interwork -Wall -Wundef -fomit-frame-pointer -ffast-math -g -Wa,-a,-ad
-fno-strict-aliasing -MD -O2 -falign-functions=8 -Wimplicit-fallthrough=3
-fno-exceptions -fno-unwind-tables -std=gnu99
-Werror=incompatible-pointer-types
LDFLAGS=-mcpu=cortex-r5 -mfloat-abi=hard -mfpu=vfpv3-d16 -mbig-endian -mthumb
-mthumb-interwork -g -nostartfiles
-Wl,-Map,dist/release/output.map,-T,project/project_gcc.ld,-n
-Wl,--no-wchar-size-warning,--cref -Wl,--gc-sections -O2 -falign-functions=8
-mbe32
[Bug translation/111416] New: [Armv7/v8 Mixing Bug]: 64-bit Sequentially Consistent Load can be Reordered before Store of RMW when v7 and v7 Implementations are Mixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111416
Bug ID: 111416
Summary: [Armv7/v8 Mixing Bug]: 64-bit Sequentially Consistent
Load can be Reordered before Store of RMW when v7 and
v7 Implementations are Mixed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: luke.geeson at cs dot ucl.ac.uk
Target Milestone: ---
Consider the following litmus test that has buggy behaviour:
```
C test
{ int64_t x = 0; int64_t y = 0 }
P0 (_Atomic int64_t *x, _Atomic int64_t *y) {
atomic_fetch_add_explicit(x,1,memory_order_seq_cst);
int32_t r0 = atomic_load_explicit(y,memory_order_seq_cst);
}
void P1 (_Atomic int64_t *x, _Atomic int64_t *y) {
atomic_store_explicit(y,1,memory_order_seq_cst);
int32_t r0 = atomic_load_explicit(x,memory_order_seq_cst);
}
exists P0:r0 = 0 /\ P1:r0 = 0
```
where 'P0:r0 = 0' means thread P0, local variable r0 has value 0
When simulating this test under the C/C++ model from its initial state, the
outcome of execution in the exists clause is forbidden by the source model. The
allowed outcomes are:
```
{ P0:r0=0; P1:r0=1; }
{ P0:r0=1; P1:r0=0; }
{ P0:r0=1; P1:r0=1; }
```
When compiling P1, to target armv7-a cortex-a53
(https://godbolt.org/z/efGnsa19G) using clang trunk, compiling the fetch_add on
P0 to target a cortex-a53 using clang trunk (`ldaexd;add;stlexd` loop), and the
load on P0 to target a cortex-a15 (`ldrd;dmb`) using GCC trunk for cortex-a15.
The compiled program has the following outcomes when simulated under the
aarch32 model:
```
{ P0:r0=0; P1:r0=0; } <--- Forbidden by source model, bug!
{ P0:r0=0; P1:r0=1; }
{ P0:r0=1; P1:r0=0; }
{ P0:r0=1; P1:r0=1; }
```
which is due to the fact the LDRD on P0 can be reordered befofre the stlexd on
P0 since there is no dmb barrier to prevent the reordering.
Since there is no acquire load on armv7, we propose to fix the bug by adding a
fence before the ldrd:
```
dmb ish; ldrd; dmb ish
```
Which prevents the buggy outcome under the aarch32 memory model.
I have validated this bug whilst discussing with Wilco from Arm's compiler
teams.
This bug would not have been caught in normal execution, but only when multiple
implementations are mixed together.
[Bug c++/111415] New: False positive array-bounds warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111415
Bug ID: 111415
Summary: False positive array-bounds warning with -O3
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daiw at gmx dot net
Target Milestone: ---
Using g++ (GCC) 13.2.0,
the following minimal example:
std::vector foo(const std::vector& a)
{
if (a.size() < 2)
{
return a;
}
return a;
}
int main()
{
foo(std::vector({1}));
}
Produces a warning when trying to compile like so:
g++ -Wall -O3 main.cpp
Output:
In file included from /usr/local/include/c++/13.2.0/vector:62,
from main.cpp:1:
In static member function 'static _Up* std::__copy_move<_IsMove, true,
std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp = const
int; _Up = int; bool _IsMove = false]',
inlined from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove =
false; _II = const int*; _OI = int*]' at
/usr/local/include/c++/13.2.0/bits/stl_algobase.h:506:30,
inlined from '_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove =
false; _II = const int*; _OI = int*]' at
/usr/local/include/c++/13.2.0/bits/stl_algobase.h:533:42,
inlined from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
false; _II = __gnu_cxx::__normal_iterator >; _OI =
int*]' at /usr/local/include/c++/13.2.0/bits/stl_algobase.h:540:31,
inlined from '_OI std::copy(_II, _II, _OI) [with _II =
__gnu_cxx::__normal_iterator >; _OI = int*]' at
/usr/local/include/c++/13.2.0/bits/stl_algobase.h:633:7,
inlined from 'static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator >; _ForwardIterator = int*]' at
/usr/local/include/c++/13.2.0/bits/stl_uninitialized.h:147:27,
inlined from '_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator =
__gnu_cxx::__normal_iterator >; _ForwardIterator =
int*]' at /usr/local/include/c++/13.2.0/bits/stl_uninitialized.h:185:15,
inlined from '_ForwardIterator std::__uninitialized_copy_a(_InputIterator,
_InputIterator, _ForwardIterator, allocator<_Tp>&) [with _InputIterator =
__gnu_cxx::__normal_iterator >; _ForwardIterator =
int*; _Tp = int]' at
/usr/local/include/c++/13.2.0/bits/stl_uninitialized.h:373:37,
inlined from 'std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp,
_Alloc>&) [with _Tp = int; _Alloc = std::allocator]' at
/usr/local/include/c++/13.2.0/bits/stl_vector.h:603:31,
inlined from 'std::vector foo(const std::vector&)' at
main.cpp:7:16:
/usr/local/include/c++/13.2.0/bits/stl_algobase.h:437:30: warning: 'void*
__builtin_memmove(void*, const void*, long unsigned int)' forming offset 4 is
out of the bounds [0, 4] [-Warray-bounds=]
437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
| ~^~~
[Bug driver/86030] specs file processing does not create response files for input directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86030 --- Comment #15 from John Soo --- Just for some context on what limit is hit: under man sysconf you will find a description of ARG_MAX (https://www.man7.org/linux/man-pages/man3/sysconf.3.html) > ARG_MAX - _SC_ARG_MAX > The maximum length of the arguments to the exec(3) family > of functions. Must not be less than _POSIX_ARG_MAX > (4096). Exceeding ARG_MAX will result in E2BIG (https://man7.org/linux/man-pages/man3/errno.3.html). > E2BIG Argument list too long (POSIX.1-2001).
[Bug c/111405] Problem with incorrect optimizion for "constexpr" function with possible overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111405 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- I'm really amazed that in 2023 there are still textbooks teaching everyone to invoke undefined behavior, even such a famous one. And how's this related to constexpr?!
[Bug tree-optimization/111414] [14 Regression] ICE in verify_gimple failed since r14-3719-gb34f3736356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414 Richard Biener changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Summary|ICE in verify_gimple failed |[14 Regression] ICE in |since r14-3719-gb34f3736356 |verify_gimple failed since ||r14-3719-gb34f3736356 Target Milestone|--- |14.0
[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 --- Comment #11 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9ea74d235c7e7816b996a17c61288f02ef767985 commit r14-3982-g9ea74d235c7e7816b996a17c61288f02ef767985 Author: Richard Biener Date: Thu Sep 14 09:31:23 2023 +0200 tree-optimization/111294 - better DCE after forwprop The following adds more aggressive DCE to forwprop to clean up dead stmts when folding a stmt leaves some operands unused. The patch uses simple_dce_from_worklist for this purpose, queueing original operands before substitution and folding, but only if we folded the stmt. This removes one dead stmt biasing threading costs in a later pass but it doesn't resolve the optimization issue in the PR yet. PR tree-optimization/111294 * tree-ssa-forwprop.cc (pass_forwprop::execute): Track operands that eventually become dead and use simple_dce_from_worklist to remove their definitions if they did so. * gcc.dg/tree-ssa/evrp10.c: Adjust. * gcc.dg/tree-ssa/evrp6.c: Likewise. * gcc.dg/tree-ssa/forwprop-31.c: Likewise. * gcc.dg/tree-ssa/neg-cast-3.c: Likewise.
[Bug tree-optimization/111414] New: ICE in verify_gimple failed since r14-3719-gb34f3736356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111414
Bug ID: 111414
Summary: ICE in verify_gimple failed since
r14-3719-gb34f3736356
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
Target Milestone: ---
gcc at -O3 crashes on the following testcase.
Bisected to r14-3719-gb34f3736356
Compiler explorer: https://godbolt.org/z/xeh66znqd
$ cat a.c
int a, b, c, d, e, f, g;
int h(int i) { return b >= 2 ?: i >> b; }
void j() {
int k;
int *l =
for (; d; d++) {
g = h(0 != j);
f = g >> a;
k = f << 7;
e = k > 5 ? k : 0;
*l ^= e;
}
}
int main() {}
$
$ gcc -O2 a.c
a.c: In function 'j':
a.c:3:6: error: non-vector operands in vector comparison
3 | void j() {
| ^
int
int
mask__21.44_181 = a.4_1 == 0;
during GIMPLE pass: vect
a,c:3:6: internal compiler error: verify_gimple failed
0x2206f8e internal_error(char const*, ...)
???:0
0x1129df9 verify_gimple_in_cfg(function*, bool, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug ipa/111283] [14 Regression] gnat profilebootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 --- Comment #8 from Franz Sirl --- I see a similar profiledbootstrap failing with x86_64-linux-gnu: /home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-x86_64-suse-linux/./prev-gcc/xg++ -B/home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-x86_64-suse-linux/./prev-gcc/ -B/usr/x86_64-suse-linux/b in/ -nostdinc++ -B/home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs -B/home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-x86_64-s use-linux/prev-x86_64-suse-linux/libstdc++-v3/libsupc++/.libs -I/home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/x86_64-suse-linux -I/home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include -I/home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/libstdc++-v3/libsupc++ -L/hom e/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs -L/home/fsirl/rpmbuild/BUILD/gcc-14.0.0+gitr14+3924/obj-x86_64-suse-linux/prev-x86_64- suse-linux/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables - U_FORTIFY_SOURCE -fprofile-use -fprofile-reproducible=parallel-runs -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-for mat-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -Ic-family -I../../gcc -I.. /../gcc/c-family -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libcody -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace -o c-family/c-attribs.o -MT c-family/c-attribs.o -MMD -MP -MF c-family/.deps/c-attribs.TPo ../../gcc/c-family/c-attribs.cc ../../gcc/c-family/c-attribs.cc: In function ??tree_node* handle_noclone_attribute(tree_node**, tree, tree, int, bool*)??: ../../gcc/c-family/c-attribs.cc:1369:1: error: probability of edge 3->4 not initialized 1369 | handle_noclone_attribute (tree *node, tree name, | ^~~~ during IPA pass: inline ../../gcc/c-family/c-attribs.cc:1369:1: internal compiler error: verify_flow_info failed 0xa92b3e verify_flow_info() ../../gcc/cfghooks.cc:287 0xfde04c checking_verify_flow_info() ../../gcc/cfghooks.h:214 0xfde04c cleanup_tree_cfg_noloop ../../gcc/tree-cfgcleanup.cc:1154 0xfde04c cleanup_tree_cfg(unsigned int) ../../gcc/tree-cfgcleanup.cc:1205 0xe7b25c execute_function_todo ../../gcc/passes.cc:2057 0xe7b70e execute_todo ../../gcc/passes.cc:2142 0xe7e16f execute_one_ipa_transform_pass ../../gcc/passes.cc:2336 0xe7e16f execute_all_ipa_transforms(bool) ../../gcc/passes.cc:2396 0xacde5d cgraph_node::expand() ../../gcc/cgraphunit.cc:1834 0xacde5d cgraph_node::expand() ../../gcc/cgraphunit.cc:1794 0xacecec expand_all_functions ../../gcc/cgraphunit.cc:2000 0xacecec symbol_table::compile() ../../gcc/cgraphunit.cc:2398 0xad2197 symbol_table::compile() ../../gcc/cgraphunit.cc:2311 0xad2197 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.cc:2583 Please submit a full bug report, with preprocessed source (by using -freport-bug). I'm attaching the compressed -freport-bug output, but I didn't manage to reproduce the bug with it (probably related to the gcda file).
[Bug ipa/111283] [14 Regression] gnat profilebootstrap broken on trunk 20230902 on 32bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283 Franz Sirl changed: What|Removed |Added CC||sirl at gcc dot gnu.org --- Comment #7 from Franz Sirl --- Created attachment 55901 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55901=edit Output of -freport-bug
[Bug libgomp/111413] New: libgomp >= 13 segfault on loading if environ is NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111413 Bug ID: 111413 Summary: libgomp >= 13 segfault on loading if environ is NULL Product: gcc Version: og13 (devel/omp/gcc-13) Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: silvio at traversaro dot it CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 55900 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55900=edit Example to reproduce the issue, compile with gcc -ldl test_gomp_segfault.c -o test_gomp_segfault Since release 13, it seems that libgomp fails on loading in the environ global variable is NULL, for example if clearenv (https://man7.org/linux/man-pages/man3/clearenv.3.html) was called before a dlopen. The problem seems in https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgomp/env.c;hb=73a0d3bf895b5c322676178a51ac0d68cf603953#l2227, where `environ` is dereferenced without first checking if it is NULL. A minimal reproducer is attached to the issue, that can be compiled and run as: gcc -ldl test_gomp_segfault.c -o test_gomp_segfault ./test_gomp_segfault
[Bug other/111406] libiberty build produces errors with CC=clang, unsupported option '-print-multi-os-directory'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111406 --- Comment #3 from Richard Biener --- These are only used in the install targets which when bootstrapped will have used GCC from earlier stages. When building cross compilers we require GCC as host compiler. So I think this isn't an issue unless you try to build libiberty stand-alone or as part of binutils and also install it? The sourceware bugzilla instance also doesn't have a libiberty component, so tracking it here is possibly good enough but as said above you'll not hit it in practice?
[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #41 from richard.sandiford at arm dot com ---
"juzhe.zhong at rivai dot ai" writes:
> I try this following code to set ELSE_VALUE:
>
> static tree
> riscv_preferred_else_value (unsigned ifn, tree vectype, unsigned int nops,
> tree *ops)
> {
> if (riscv_v_ext_mode_p (TYPE_MODE (vectype)))
> {
> // return build_zero_cst (size_type_node);
> return get_or_create_ssa_default_def (cfun, create_tmp_var (vectype));
> }
>
> return default_preferred_else_value (ifn, vectype, nops, ops);
> }
>
> It generate the GIMPLE IR ELSE VALUE is an uninitialized value:
>
> vector([128,128]) signed char D.2821;
> vector([128,128]) signed char _72(D);
> vect_patt_42.12_73 = .COND_LEN_MOD ({ -1, ... }, vect__3.8_67, vect__6.11_71,
> _72(D), _82, 0);
>
> Then "_72" is expanded into RTL as:
>
> (reg:RVVM8QI 136 [ D.2821 ])
>
> I try to use SSA_NAME_IS_DEFAULT_DEF to check whether this operand is
> the undef value since:
>
> (gdb) p ops[4]->u->reg->attrs->decl->base.default_def_flag
> $7 = 0
>
> It's false that I can't recognize it as "undefine" value.
IMO it's expand_fn_using_insn that should be recognising the default def,
not the target. It can then use a SCRATCH rtx as the operand (but see
my previous comment for more about that).
[Bug target/111412] New: [release/gcc13 bug]RISC-V:ICE in phase 6 of vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111412 Bug ID: 111412 Summary: [release/gcc13 bug]RISC-V:ICE in phase 6 of vsetvl pass Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: xuli1 at eswincomputing dot com Target Milestone: --- Created attachment 55899 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55899=edit testcase Compile the code using -march=rv64gcv -mabi=lp64d -O2: test: beq a0,zero,.L2 lui a5,%hi(.LC0) flw fa4,%lo(.LC0)(a5) fmv.s.x fa5,zero li a3,1 vfmv.v.fv1,fa4 --> The vsetvl instruction was not set before this,causing Illegal instruction (core dumped) .L5: sllia5,a3,32 srlia5,a5,32 vsetvli a5,a5,e32,m8,ta,mu beq a5,zero,.L3 mv a4,a3 . Solution: vsetvl pass has been refactored in gcc14, and the optimization process is more reasonable than gcc13. This problem does not exist in gcc14. Phase 6 of gcc13 is an optimization patch. Due to lack of consideration, there will be some hidden bugs, so we decided to remove phase 6. Although the generated code will be redundant,the program is correct.
[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #40 from JuzheZhong ---
I try this following code to set ELSE_VALUE:
static tree
riscv_preferred_else_value (unsigned ifn, tree vectype, unsigned int nops,
tree *ops)
{
if (riscv_v_ext_mode_p (TYPE_MODE (vectype)))
{
// return build_zero_cst (size_type_node);
return get_or_create_ssa_default_def (cfun, create_tmp_var (vectype));
}
return default_preferred_else_value (ifn, vectype, nops, ops);
}
It generate the GIMPLE IR ELSE VALUE is an uninitialized value:
vector([128,128]) signed char D.2821;
vector([128,128]) signed char _72(D);
vect_patt_42.12_73 = .COND_LEN_MOD ({ -1, ... }, vect__3.8_67, vect__6.11_71,
_72(D), _82, 0);
Then "_72" is expanded into RTL as:
(reg:RVVM8QI 136 [ D.2821 ])
I try to use SSA_NAME_IS_DEFAULT_DEF to check whether this operand is
the undef value since:
(gdb) p ops[4]->u->reg->attrs->decl->base.default_def_flag
$7 = 0
It's false that I can't recognize it as "undefine" value.
[Bug middle-end/111395] RISC-V Vector Fortran: ICE in get_avl_or_vl_reg (vsetvl pass)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111395 --- Comment #1 from CVS Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:53ad1bd520759580b9a5cc590a81a1a30b9e2e28 commit r14-3979-g53ad1bd520759580b9a5cc590a81a1a30b9e2e28 Author: Juzhe-Zhong Date: Thu Sep 14 15:52:13 2023 +0800 RISC-V: Fix ICE in get_avl_or_vl_reg update v1 -> v2: Add available fortran compiler check in rvv-fortran.exp. This patch fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111395 ICE update v2 -> v3: Remove redundant format. PR target/111395 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (avl_info::operator==): Fix ICE. (vector_insn_info::global_merge): Ditto. (vector_insn_info::get_avl_or_vl_reg): Ditto. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/fortran/pr111395.f90: New test. * gcc.target/riscv/rvv/rvv-fortran.exp: New test.
[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294
--- Comment #10 from Richard Biener ---
But this stmt isn't the issue, BB7 is
[local count: 118111600]:
# _31 = PHI
_4 = (unsigned char) _31;
_6 = (int) a.8_28;
j_22 = (short int) _4;
_33 = _31 & 255;
if (_33 > 11)
and that does have one more stmt. It's
if (a.8_28 != 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 40157944]:
[local count: 118111600]:
# _31 = PHI
_4 = (unsigned char) _31;
_6 = (int) a.8_28;
j_22 = (short int) _4;
_33 = _31 & 255;
if (_33 > 11)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 59055800]:
[local count: 118111600]:
# iftmp.11_27 = PHI
so what the cost model fails to see is that j_22 and _4 are only live
on one path to BB9.
It's that odd code again I attempted to remove at some point:
/* PHIs in the path will create degenerate PHIS in the
copied path which will then get propagated away, so
looking at just the duplicate path the PHIs would
seem unimportant.
But those PHIs, because they're assignments to objects
typically with lives that exist outside the thread path,
will tend to generate PHIs (or at least new PHI arguments)
at points where we leave the thread path and rejoin
the original blocks. So we do want to account for them.
We ignore virtual PHIs. We also ignore cases where BB
has a single incoming edge. That's the most common
degenerate PHI we'll see here. Finally we ignore PHIs
that are associated with the value we're tracking as
that object likely dies. */
if (EDGE_COUNT (bb->succs) > 1 && EDGE_COUNT (bb->preds) > 1)
{
for (gphi_iterator gsip = gsi_start_phis (bb);
!gsi_end_p (gsip);
gsi_next ())
{
gphi *phi = gsip.phi ();
tree dst = gimple_phi_result (phi);
/* Note that if both NAME and DST are anonymous
SSA_NAMEs, then we do not have enough information
to consider them associated. */
if (dst != name
&& name
&& TREE_CODE (name) == SSA_NAME
&& (SSA_NAME_VAR (dst) != SSA_NAME_VAR (name)
|| !SSA_NAME_VAR (dst))
&& !virtual_operand_p (dst))
++m_n_insns;
}
}
there's also a missed canonicalization I think:
_4 = (unsigned char) _31;
_6 = (int) a.8_28;
j_22 = (short int) _4;
_33 = _31 & 255;
we canonicalize (int)(unsigned char) _31 to _31 & 255 but we fail to
do the same for (short)(unsigned char) _31 or rather we fail to
anticipate that (short)_33 could be used for j_22, eliding _4.
Maybe costing "lowparts" as zero would be useful here.
[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 --- Comment #9 from Richard Biener --- Created attachment 55898 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55898=edit alternative patch for simple_dce_from_worklist
[Bug tree-optimization/111294] [14 Regression] Missed Dead Code Elimination since r14-573-g69f1a8af45d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111294 --- Comment #8 from Richard Biener --- (In reply to Andrew Pinski from comment #7) > Created attachment 55892 [details] > version of using simple_dce_from_worklist in forwprop > > This is a version of using simple_dce_from_worklist in forwprop I had tried > at one point, but I don't remember why I did finish up this patch. That wouldn't catch the case in question. The issue is when we simplify _32 = (char) _31; - _4 = (unsigned char) _32; + _4 = (unsigned char) _31; we don't realize _32 becomes unused. I think it might be enough to add all original SSA uses of a stmt we fold to the DCE worklist if we simplified it (and also before substituting from the fwprop lattice?). I think it doesn't work to look at orig_stmt operands before we do update_stmt on the new stmt. Sth like the attached works though.
[Bug debug/111409] Invalid .debug_macro.dwo macro information for split DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409 --- Comment #1 from Omar Sandoval --- Patch sent: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630242.html
[Bug middle-end/111401] Middle-end: Missed optimization of MASK_LEN_FOLD_LEFT_PLUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401 --- Comment #5 from rguenther at suse dot de --- On Wed, 13 Sep 2023, rdapp at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401 > > --- Comment #3 from Robin Dapp --- > Several other things came up, so I'm just going to post the latest status here > without having revised or tested it. Going to try fixing it and testing > tomorrow. I think what's important to do is make sure targets without masking are still getting the cond-reduction code generation (but with the signed-zero issue fixed). Using a cond_add is probably better than the vec_cond + add even for the not fold-left reduction case.
[Bug middle-end/111401] Middle-end: Missed optimization of MASK_LEN_FOLD_LEFT_PLUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
--- Comment #4 from rguenther at suse dot de ---
On Wed, 13 Sep 2023, rdapp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
>
> Robin Dapp changed:
>
>What|Removed |Added
>
> CC||rdapp at gcc dot gnu.org
>
> --- Comment #2 from Robin Dapp ---
> I played around with this a bit. Emitting a COND_LEN in if-convert is easy:
>
> _ifc__35 = .COND_ADD (_23, init_20, _8, init_20);
>
> However, during reduction handling we rely on the reduction being a gimple
> assign and binary operation, though so I needed to fix some places and indices
> as well as the proper mask.
>
> What complicates things a bit is that we assume that "init_20" (i.e. the
> reduction def) occurs once when we have it twice in the COND_ADD. I just
> special cased that for now. Is this the proper thing to do?
I think so - we should ignore a use in the else value when the other
use is in that same stmt.
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index 23c6e8259e7..e99add3cf16 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@ -3672,7 +3672,7 @@ vect_analyze_loop (class loop *loop, vec_info_shared
> *shared)
> static bool
> fold_left_reduction_fn (code_helper code, internal_fn *reduc_fn)
> {
> - if (code == PLUS_EXPR)
> + if (code == PLUS_EXPR || code == IFN_COND_ADD)
> {
>*reduc_fn = IFN_FOLD_LEFT_PLUS;
>return true;
> @@ -4106,8 +4106,11 @@ vect_is_simple_reduction (loop_vec_info loop_info,
> stmt_vec_info phi_info,
>return NULL;
> }
>
> - nphi_def_loop_uses++;
> - phi_use_stmt = use_stmt;
> + if (use_stmt != phi_use_stmt)
> + {
> + nphi_def_loop_uses++;
> + phi_use_stmt = use_stmt;
> + }
>
> @@ -7440,6 +7457,9 @@ vectorizable_reduction (loop_vec_info loop_vinfo,
>if (i == STMT_VINFO_REDUC_IDX (stmt_info))
> continue;
>
> + if (op.ops[i] == op.ops[STMT_VINFO_REDUC_IDX (stmt_info)])
> + continue;
> +
>
> Apart from that I think what's mainly missing is making the added code nicer.
> Going to attach a tentative patch later.
>
>
[Bug target/111372] libgcc: RISCV C++ exception handling stack usage grew in 13.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111372 --- Comment #5 from Kito Cheng --- > Ok, but it's better to have configure option or something else just > for toolchains that definitely do not use vector extension I can understand that there would be such a demand in the embedded world, but that's not critical issue, so this won't get high priority to most RISC-V GCC developer, it would be appreciate if you could send a patch for that.
