[Bug rtl-optimization/112494] ICE in ix86_cc_mode, at config/i386/i386.cc:16477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
--- Comment #3 from Andrew Pinski ---
I almost want to say this is a bug in the x86 back-end where it pushes the
flags onto the stack.
That is:
(insn 11 8 12 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg:DI 17 flags))
"/opt/compiler-explorer/gcc-trunk-20231112/lib/gcc/x86_64-linux-gnu/14.0.0/include/ia32intrin.h":262:10
70 {*pushfldi2}
(expr_list:REG_DEAD (reg:DI 17 flags)
(nil)))
(insn 12 11 20 2 (set (reg:DI 102)
(mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0 S8 A8]))
"/opt/compiler-explorer/gcc-trunk-20231112/lib/gcc/x86_64-linux-gnu/14.0.0/include/ia32intrin.h":262:10
66 {*popdi1}
(expr_list:REG_UNUSED (reg:DI 102)
(nil)))
(insn 20 12 21 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:DI 98 [ flags1D.40416 ])
(const_int 0 [0]))) "/app/example.cpp":14:15 8 {*cmpdi_ccno_1}
(expr_list:REG_EQUAL (compare:CCZ (const_int 215 [0xd7])
(const_int 0 [0]))
(expr_list:REG_DEAD (reg/v:DI 98 [ flags1D.40416 ])
(nil
Maybe it should be represented as:
(set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(unspec (reg:CC 17 flags) GET_EFLAGS))
Likewise for poping:
(set (reg:DI 17 flags)
(mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0 S8 A8]))
(nil)
Should really be:
(set (reg:CC 17 flags)
(unspec:CC (mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0 S8 A8]))
SET_EFLAGS))
[Bug target/112470] [11/12/13/14 regression] [AARCH64] stack-protector vulnerability fixing solution impact code size and performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470 --- Comment #4 from Sam James --- (In reply to John Dong from comment #3) > ping ? You posted the bug after the close of business on Friday (end of the week) and the next week is just starting now on Monday. Europe is waking up now and the US hasn't yet. Please wait.
[Bug tree-optimization/111967] [12/13 Regression] during GIMPLE pass: evrp ICE: in operator[], at vec.h:910 with -O2 -fno-tree-forwprop -fdump-tree-evrp-all since r12-4694
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111967 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14 Regression] |[12/13 Regression] during |during GIMPLE pass: evrp|GIMPLE pass: evrp ICE: in |ICE: in operator[], at |operator[], at vec.h:910 |vec.h:910 with -O2 |with -O2 -fno-tree-forwprop |-fno-tree-forwprop |-fdump-tree-evrp-all since |-fdump-tree-evrp-all since |r12-4694 |r12-4694| --- Comment #5 from Jakub Jelinek --- Fixed on the trunk for now.
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 Tamar Christina changed: What|Removed |Added CC|tamar.christina at arm dot com | --- Comment #15 from Tamar Christina --- removing duplicate mail
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 Xi Ruoyao changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|xry111 at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #14 from Xi Ruoyao --- I've pushed the obvious fix for now (as the wrong-code issue is causing wide-spreading test failures). Leaving the ticket open for the missed-optimization.
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 --- Comment #13 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:7ba7529ee3974667a8e68d089b606ac2fb159415 commit r14-5377-g7ba7529ee3974667a8e68d089b606ac2fb159415 Author: Xi Ruoyao Date: Sun Nov 12 14:16:20 2023 + Fix (fcopysign x, NEGATIVE_CONST) -> (fneg (fabs x)) simplification [PR112483] (fcopysign x, NEGATIVE_CONST) can be simplified to (fneg (fabs x)), but a logic error in the code caused it mistakenly simplified to (fneg x) instead. gcc/ChangeLog: PR rtl-optimization/112483 * simplify-rtx.cc (simplify_binary_operation_1) : Fix the simplification of (fcopysign x, NEGATIVE_CONST).
[Bug tree-optimization/111967] [12/13/14 Regression] during GIMPLE pass: evrp ICE: in operator[], at vec.h:910 with -O2 -fno-tree-forwprop -fdump-tree-evrp-all since r12-4694
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111967 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5a0c302d2d721b9650c1e354695dbba87364c334 commit r14-5376-g5a0c302d2d721b9650c1e354695dbba87364c334 Author: Jakub Jelinek Date: Mon Nov 13 08:47:41 2023 +0100 gimple-range-cache: Fix ICEs when dumping details [PR111967] The following testcase ICEs when dumping details. When m_ssa_ranges vector is created, it is safe_grow_cleared (num_ssa_names), but when when some new SSA_NAME is added, we strangely grow it to num_ssa_names + 1 instead and later on the 3 argument dump method iterates from 1 to m_ssa_ranges.length () - 1 and uses ssa_name (x) on each; but because set_bb_range grew it one too much, ssa_name (m_ssa_ranges.length () - 1) might be after the end of the ssanames vector and ICE. The fix grows the vector consistently only to num_ssa_names, doesn't waste time checking m_ssa_ranges[0] because there is no ssa_names (0), it is always NULL, before using ssa_name (x) checks if we'll need it at all (we check later if m_ssa_ranges[x] is non-NULL, so we might check it earlier as well) and also in the last loop iterates until m_ssa_ranges.length () rather than num_ssa_names, I don't see a reason for the inconsistency and in theory some SSA_NAME could be added without set_bb_range called for it and the vector could be shorter than the ssanames vector. To actually fix the ICE, either the first hunk or the last 2 hunks would be enough, but I think it doesn't hurt to change all the spots. 2023-11-13 Jakub Jelinek PR tree-optimization/111967 * gimple-range-cache.cc (block_range_cache::set_bb_range): Grow m_ssa_ranges to num_ssa_names rather than num_ssa_names + 1. (block_range_cache::dump): Iterate from 1 rather than 0. Don't use ssa_name (x) unless m_ssa_ranges[x] is non-NULL. Iterate to m_ssa_ranges.length () rather than num_ssa_names. * gcc.dg/tree-ssa/pr111967.c: New test.
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 --- Comment #12 from Andrew Pinski --- What about this patch: ``` diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc index 69d87579d9c..f3745d86aea 100644 --- a/gcc/simplify-rtx.cc +++ b/gcc/simplify-rtx.cc @@ -4392,7 +4392,7 @@ simplify_ashift: real_convert (, mode, CONST_DOUBLE_REAL_VALUE (trueop1)); rtx tmp = simplify_gen_unary (ABS, mode, op0, mode); if (REAL_VALUE_NEGATIVE (f1)) - tmp = simplify_gen_unary (NEG, mode, op0, mode); + tmp = simplify_unary_operation (NEG, mode, tmp, mode); return tmp; } if (GET_CODE (op0) == NEG || GET_CODE (op0) == ABS) ``` We only generate NEG if it simplifies from the ABS. Most likely due to constants.
[Bug target/112470] [11/12/13/14 regression] [AARCH64] stack-protector vulnerability fixing solution impact code size and performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470 --- Comment #3 from John Dong --- (In reply to John Dong from comment #0) > Hi, after the CVE-2023-4039 patch is installed, the code size and > performance are affected after stack protection is enabled. > Refer to https://godbolt.org/z/7dWeYd5Kb > After analyzing the patch, I think we can add the following modification > solution: For functions that need to dynamically apply for stackframe, we > can change the stack distribution of local variables, in other cases, the > original stack distribution will be retained. > > diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc > index 800a8b0e110..342bab89281 100644 > --- a/gcc/config/aarch64/aarch64.cc > +++ b/gcc/config/aarch64/aarch64.cc > @@ -8538,7 +8538,7 @@ aarch64_save_regs_above_locals_p () > it would be possible for a carefully sized smash attack to change > the saved registers (particularly LR and FP) without reaching the > canary. */ > - return crtl->stack_protect_guard; > + return crtl->stack_protect_guard && cfun->calls_alloca; > } > > /* Mark the registers that need to be saved by the callee and calculate > > > Please let me know if you have any comments ping ?
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 Xi Ruoyao changed: What|Removed |Added Keywords||missed-optimization --- Comment #11 from Xi Ruoyao --- As we've discussed via gcc-patches, the (fcopysign x, NEG_CONST) -> (fneg (fabs x)) conversion seems a de-optimization.
[Bug modula2/112506] gm2 test failures on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
--- Comment #1 from Francois-Xavier Coudert ---
The stack trace for the "expecting a DefImp symbol" error is the following:
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
* frame #0: 0x00010004a240
cc1gm2`::M2Emit_InternalError(message_="expecting a DefImp symbol",
_message_high=25) at M2Emit.c:97:8
frame #1: 0x00010004be0c
cc1gm2`::M2Error_InternalError(message_=, _message_high=25) at
M2Error.c:2605:24
frame #2: 0x0001000a9543 cc1gm2`::SymbolTable_IsDefinitionForC(Sym=165)
at SymbolTable.c:16397:31
frame #3: 0x000100047676 cc1gm2`::M2Comp_compile(void *) at
M2Comp.c:1114:43
frame #4: 0x0001000475db cc1gm2`::M2Comp_compile(void *) at
M2Comp.c:1189:28
frame #5: 0x000100047246 cc1gm2`::M2Comp_compile(void *) [inlined]
Compile(s=0x637079c0) at M2Comp.c:427:11
frame #6: 0x000100047246
cc1gm2`::M2Comp_compile(filename=) at M2Comp.c:1540:11
frame #7: 0x000163e1 cc1gm2`::gm2_langhook_parse_file() at
gm2-lang.cc:803:26
frame #8: 0x00016393 cc1gm2`::gm2_langhook_parse_file() at
gm2-lang.cc:810:25
frame #9: 0x000101476d04 cc1gm2`::compile_file() at toplev.cc:446:25
frame #10: 0x000101db1d06 cc1gm2`toplev::main(int, char**) at
toplev.cc:2129:24
frame #11: 0x000101dc13c0 cc1gm2
The trace for the other one is:
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x0001000692b0 cc1gm2`::M2MetaError_MetaErrorT1(tok=3628,
m_="module {%1Ea} has a corresponding DEFINITION MODULE but no IMPLEMENTATION
keyword in the main module", _m_high=100, s=155) at M2MetaError.c:3471:1
frame #1: 0x00010009823d
cc1gm2`::P1SymBuild_P1StartBuildProgramModule() at P1SymBuild.c:633:31
frame #2: 0x0001000e5b43 cc1gm2`::P1Build_CompilationUnit() [inlined]
ProgramModule(stopset0=1, stopset1=0, stopset2=0) at P1Build.c:3038:40
frame #3: 0x0001000e5b10 cc1gm2`::P1Build_CompilationUnit() [inlined]
ImplementationOrProgramModule(stopset0=1, stopset1=0, stopset2=0) at
P1Build.c:3143:21
frame #4: 0x0001000e5b10 cc1gm2`::P1Build_CompilationUnit() [inlined]
FileUnit(stopset0=1, stopset1=0, stopset2=0) at P1Build.c:2993:37
frame #5: 0x0001000e51e0 cc1gm2`::P1Build_CompilationUnit() at
P1Build.c:6664:12
frame #6: 0x000100047c59 cc1gm2`::M2Comp_compile(void *) at
M2Comp.c:1258:46
frame #7: 0x000100047bd8 cc1gm2`::M2Comp_compile(void *) [inlined]
Compile(s=0x6370a1c0) at M2Comp.c:433:11
frame #8: 0x000100047246
cc1gm2`::M2Comp_compile(filename=) at M2Comp.c:1540:11
frame #9: 0x000163e1 cc1gm2`::gm2_langhook_parse_file() at
gm2-lang.cc:803:26
frame #10: 0x00016393 cc1gm2`::gm2_langhook_parse_file() at
gm2-lang.cc:810:25
frame #11: 0x000101476d04 cc1gm2`::compile_file() at toplev.cc:446:25
frame #12: 0x000101db1d06 cc1gm2`toplev::main(int, char**) at
toplev.cc:2129:24
frame #13: 0x000101dc13c0 cc1gm2
[Bug modula2/112506] gm2 test failures on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506 Francois-Xavier Coudert changed: What|Removed |Added Host||x86_64-apple-darwin21 Target||x86_64-apple-darwin21 Last reconfirmed||2023-11-13 Status|UNCONFIRMED |NEW Known to fail||14.0 Keywords||testsuite-fail Build||x86_64-apple-darwin21 Ever confirmed|0 |1
[Bug modula2/112506] New: gm2 test failures on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112506
Bug ID: 112506
Summary: gm2 test failures on x86_64-apple-darwin21
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
Target Milestone: ---
Recent test results show ~100 test failures on Darwin (see for example
https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800694.html):
=== gm2 Summary ===
# of expected passes12740
# of unexpected failures60
# of unresolved testcases 48
They seem to belong to two different series:
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-g } timeout=10 (internal compiler error: expecting a DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -g } timeout=10
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-O } timeout=10 (internal compiler error: expecting a DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -O } timeout=10
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-O -g } timeout=10 (internal compiler error: expecting a DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -O -g } timeout=10
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-Os } timeout=10 (internal compiler error: expecting a DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -Os } timeout=10
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-O3 -fomit-frame-pointer } timeout=10 (internal compiler error: expecting a
DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -O3 -fomit-frame-pointer } timeout=10
FAIL: gm2/link/externalscaffold/pass/hello.mod compilation, {additional_flags=
-O3 -fomit-frame-pointer -finline-functions } timeout=10 (internal compiler
error: expecting a DefImp symbol)
UNRESOLVED: gm2/link/externalscaffold/pass/hello.mod execution,
{additional_flags= -O3 -fomit-frame-pointer -finline-functions } timeout=10
fails with: "cc1gm2: internal compiler error: expecting a DefImp symbol"
and
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -g }
timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -g }
timeout=10
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -O }
timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -O }
timeout=10
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -O -g }
timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -O -g }
timeout=10
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -Os }
timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -Os }
timeout=10
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -O3
-fomit-frame-pointer } timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -O3
-fomit-frame-pointer } timeout=10
FAIL: gm2/pim/run/pass/builtins.mod compilation, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=10
UNRESOLVED: gm2/pim/run/pass/builtins.mod execution, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -g }
timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -g }
timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -O }
timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -O }
timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -O -g }
timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -O -g }
timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -Os }
timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -Os }
timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -O3
-fomit-frame-pointer } timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -O3
-fomit-frame-pointer } timeout=10
FAIL: gm2/pim/run/pass/convert1.mod compilation, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=10
UNRESOLVED: gm2/pim/run/pass/convert1.mod execution, {additional_flags= -O3
-fomit-frame-pointer -finline-functions } timeout=10
FAIL: gm2/pim/run/pass/longint1.mod compilation, {additional_flags= -g }
timeout=10
UNRESOLVED: gm2/pim/run/pass/longint1.mod execution, {additional_flags= -g }
timeout=10
FAIL: gm2/pim/run/pass/longint1.mod
[Bug tree-optimization/112468] [14 Regression] Missed phi-opt after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112468 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Tamar Christina --- testing patch
[Bug c/112504] ICE in operand_equal_p, at fold-const.cc:3313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112504 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-11-13 Ever confirmed|0 |1 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed. The C++ front-end fixes this by wrapping the call of foo with a TARGET_EXPR.
[Bug target/112476] Unrecognizable insn with -O2 -march=la464 on loongarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112476 Xi Ruoyao changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #7 from Xi Ruoyao --- Fixed for trunk.
[Bug c/112504] gcc: 14: internal compiler error: in operand_equal_p, at fold-const.cc:3313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112504 --- Comment #1 from Andrew Pinski --- ICE checking because this checking is only enabled if checking is enabled: 3313gcc_checking_assert (!(flags & OEP_ADDRESS_OF));
[Bug target/112476] Unrecognizable insn with -O2 -march=la464 on loongarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112476 --- Comment #6 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:b88500e0bc1e9e3a396ba764f9b701d22a76818f commit r14-5374-gb88500e0bc1e9e3a396ba764f9b701d22a76818f Author: Xi Ruoyao Date: Sun Nov 12 00:55:13 2023 +0800 LoongArch: Use simplify_gen_subreg instead of gen_rtx_SUBREG in loongarch_expand_vec_cond_mask_expr [PR112476] GCC internal says: 'subreg's of 'subreg's are not supported. Using 'simplify_gen_subreg' is the recommended way to avoid this problem. Unfortunately loongarch_expand_vec_cond_mask_expr might create nested subreg under certain circumstances, causing an ICE. Use simplify_gen_subreg as the internal document suggests. gcc/ChangeLog: PR target/112476 * config/loongarch/loongarch.cc (loongarch_expand_vec_cond_mask_expr): Call simplify_gen_subreg instead of gen_rtx_SUBREG. gcc/testsuite/ChangeLog: PR target/112476 * gcc.target/loongarch/pr112476-1.c: New test. * gcc.target/loongarch/pr112476-2.c: New test.
[Bug tree-optimization/112505] [12/13/14 Regression] internal compiler error: in build_vector_from_val, at tree.cc:2104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112505 Andrew Pinski changed: What|Removed |Added Blocks||53947 --- Comment #2 from Andrew Pinski --- Looks like 11.x was not able to vectorize the loop. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/112505] [12/13/14 Regression] internal compiler error: in build_vector_from_val, at tree.cc:2104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112505
Andrew Pinski changed:
What|Removed |Added
Known to work||11.1.0, 11.4.0
Keywords||ice-on-valid-code,
||needs-bisection
Ever confirmed|0 |1
Known to fail||12.1.0
Target Milestone|--- |12.4
Summary|GCC: 14: internal compiler |[12/13/14 Regression]
|error: in |internal compiler error: in
|build_vector_from_val, at |build_vector_from_val, at
|tree.cc:2104|tree.cc:2104
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-11-13
Component|c |tree-optimization
--- Comment #1 from Andrew Pinski ---
Simplier testcase:
```
short int w9;
struct T {
short a : 14;
int b;
};
struct T v;
void zc() {
for(int i = 0; i < 4; i ++)
w9 *= v.b ? v.a-- < 0 : 0;
}
```
Just compiler at `-O3 -fno-vect-cost-model`
_30;
vector(4) unsigned short _31;
...
_31 = {_60, _59, _2, _30};
_52 = (vector(4) signed short) _31;
[Bug c/112505] New: GCC: 14: internal compiler error: in build_vector_from_val, at tree.cc:2104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112505
Bug ID: 112505
Summary: GCC: 14: internal compiler error: in
build_vector_from_val, at tree.cc:2104
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: ---
Compiler Explorer: https://gcc.godbolt.org/z/nTjnh73xj
The crash triggering program (compile with `gcc-14 -O3`):
```
short int w9;
struct T {
short a : 14;
int b;
};
struct T v;
void __attribute__((simd)) zc() {
w9 *= v.b ? v.a-- < 0 : 0;
}
```
The crash output:
```
during GIMPLE pass: vect
: In function 'zc.simdclone.0':
:7:28: internal compiler error: in build_vector_from_val, at
tree.cc:2104
7 | void __attribute__((simd)) zc() {
|^~
0x238b15e internal_error(char const*, ...)
???:0
0xa11270 fancy_abort(char const*, int, char const*)
???:0
0x13ee023 vectorizable_induction(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp_tree*, vec*)
???:0
0x2115bf8 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
???:0
0x13fedc0 vect_transform_loop(_loop_vec_info*, gimple*)
???: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 c/112504] New: gcc: 14: internal compiler error: in operand_equal_p, at fold-const.cc:3313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112504
Bug ID: 112504
Summary: gcc: 14: internal compiler error: in operand_equal_p,
at fold-const.cc:3313
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: ---
Compiler Explorer: https://gcc.godbolt.org/z/YdETsKzeb
When compiling this program with `gcc-14 -O0`, gcc crashes:
```
struct s {
char c[1];
};
extern struct s foo(void);
void bar(void) {
foo().c == foo().c;
}
```
The crash output:
```
: In function 'bar':
:6:3: internal compiler error: in operand_equal_p, at
fold-const.cc:3313
6 | foo().c == foo().c;
| ^~~
0x238b15e internal_error(char const*, ...)
???:0
0xa11270 fancy_abort(char const*, int, char const*)
???:0
0xd0bd67 operand_compare::operand_equal_p(tree_node const*, tree_node const*,
unsigned int)
???:0
0xd0b6e4 operand_compare::operand_equal_p(tree_node const*, tree_node const*,
unsigned int)
???:0
0xd25837 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
???:0
0xd45c84 fold(tree_node*)
???:0
0xac0aef c_fully_fold(tree_node*, bool, bool*, bool)
???:0
0xa574e3 c_process_expr_stmt(unsigned int, tree_node*)
???:0
0xa57711 c_finish_expr_stmt(unsigned int, tree_node*)
???:0
0xabd40d c_parse_file()
???:0
0xb30909 c_common_parse_file()
???: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 c/112502] GCC: 14: internal compiler error: in get_predictor_value, at predict.cc:2695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112502 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 110852. *** This bug has been marked as a duplicate of bug 110852 ***
[Bug tree-optimization/110852] [14 Regression] ICE: in get_predictor_value, at predict.cc:2695 with -O -fno-tree-fre and __builtin_expect() since r14-2219-geab57b825bcc35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110852 Andrew Pinski changed: What|Removed |Added CC||141242068 at smail dot nju.edu.cn --- Comment #4 from Andrew Pinski --- *** Bug 112502 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/110422] asm goto vs SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110422
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-13
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Better testcase from the dup:
```
struct T { int x; };
int foo(void) {
struct T v;
asm goto("" : "+r"(v.x) : : : lab);
return 0;
lab:
return -5;
}
```
Confirmed.
[Bug c/112503] GCC: 14: internal compiler error: Segmentation fault at gsi_start_edge(edge_def*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112503 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 110422. *** This bug has been marked as a duplicate of bug 110422 ***
[Bug tree-optimization/110422] asm goto vs SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110422 Andrew Pinski changed: What|Removed |Added CC||141242068 at smail dot nju.edu.cn --- Comment #1 from Andrew Pinski --- *** Bug 112503 has been marked as a duplicate of this bug. ***
[Bug c/112503] New: GCC: 14: internal compiler error: Segmentation fault at gsi_start_edge(edge_def*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112503
Bug ID: 112503
Summary: GCC: 14: internal compiler error: Segmentation fault
at gsi_start_edge(edge_def*)
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: ---
Compiler Explorer: https://gcc.godbolt.org/z/erEvbYYKc
When compiling this program with `gcc-14 -O1`, gcc crashes:
```
struct T { int x; };
int foo(void) {
struct T v;
asm goto("" : "+r"(v.x) : : : lab);
return 0;
lab:
return -5;
}
```
The crash output:
```
during GIMPLE pass: esra
: In function 'foo':
:8:1: internal compiler error: Segmentation fault
8 | }
| ^
0x238b15e internal_error(char const*, ...)
???:0
0xd7cb34 gsi_start_edge(edge_def*)
???: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 c/112502] New: GCC: 14: internal compiler error: in get_predictor_value, at predict.cc:2695
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112502
Bug ID: 112502
Summary: GCC: 14: internal compiler error: in
get_predictor_value, at predict.cc:2695
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: ---
Compiler Explorer: https://gcc.godbolt.org/z/WP94TWqj5
When compiling this program with `gcc-14 -O1`, gcc crashes:
```
int global;
void foo(int a, short b) {
if (__builtin_expect_with_probability(a, 1, -2.0f) >
__builtin_expect_with_probability(b, 0, 0.8f))
global++;
}
```
Based on the diagnostic error messages, the cause of the crash appears to be
the invalid argument `-2.0f` passed into the
`__builtin_expect_with_probability` function. But after removing the `if`, as
this program, the crash disappears:
```
int global;
void foo(int a, short b) {
__builtin_expect_with_probability(a, 1, -2.0f) >
__builtin_expect_with_probability(b, 0, 0.8f);
global++;
}
```
The crash output:
```
: In function 'foo':
:4:7: error: probability '-2.0e+0' is outside the range [0.0, 1.0]
4 | if (__builtin_expect_with_probability(a, 1, -2.0f) >
| ^~
during GIMPLE pass: profile_estimate
:7:1: internal compiler error: in get_predictor_value, at
predict.cc:2695
7 | }
| ^
0x238b15e internal_error(char const*, ...)
???:0
0xa11270 fancy_abort(char const*, int, char const*)
???:0
0x1019629 tree_estimate_probability(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 tree-optimization/68110] __builtin_sub_overflow unsigned performance issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68110 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Andrew Pinski --- Mine to finish up later on.
[Bug middle-end/112501] ICE in extract_insn, at recog.cc:2804 with __builtin_speculation_safe_value with short type on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112501
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-13
Ever confirmed|0 |1
Summary|GCC: 14: internal compiler |ICE in extract_insn, at
|error: in extract_insn, at |recog.cc:2804 with
|recog.cc:2804 |__builtin_speculation_safe_
||value with short type on
||x86_64
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed, shorter better testcase:
```
int main() {
short t = -2;
if (__builtin_speculation_safe_value(t) != -2)
__builtin_abort();
return 0;
}
```
The `0xfffe` should have been sign extended since all const_int are signed
extended from the original type.
[Bug c/112501] New: GCC: 14: internal compiler error: in extract_insn, at recog.cc:2804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112501
Bug ID: 112501
Summary: GCC: 14: internal compiler error: in extract_insn, at
recog.cc:2804
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: ---
Compiler Explorer: https://gcc.godbolt.org/z/65TGaK86r
When compiling this program with `gcc-14 -O1`, gcc crashes:
```
short b;
int main() {
if (b + 2) __builtin_abort();
if (__builtin_speculation_safe_value(b) != 2)
__builtin_abort();
return 0;
}
```
A interesting finding: after replacing `b + 2` by `b` in the first if-stmt's
condition expr, this crash disappears, though it seems the root cause ought to
be the second if-stmt.
The crash output:
```
: In function 'main':
:8:1: error: unrecognizable insn:
8 | }
| ^
(insn 15 14 16 5 (set (reg:HI 99 [ _4 ])
(const_int 65534 [0xfffe])) "":5:7 -1
(nil))
during RTL pass: vregs
:8:1: internal compiler error: in extract_insn, at recog.cc:2804
0x238b15e internal_error(char const*, ...)
???:0
0xa11270 fancy_abort(char const*, int, char const*)
???:0
0x827c80 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x827ca2 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???: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 middle-end/112499] [11/12/13/14 Regression] ICE in output_operand: invalid expression as operand with addition of 2 differences of address of labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112499 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-11-13 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug middle-end/112499] [11/12/13/14 Regression] ICE in output_operand: invalid expression as operand with addition of 2 differences of address of labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112499 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5 Known to fail||5.3.0, 5.5.0, 6.1.0 Known to work||4.9.4, 5.2.0 Component|c |middle-end Summary|GCC: 14: internal compiler |[11/12/13/14 Regression] |error: output_operand: |ICE in output_operand: |invalid expression as |invalid expression as |operand |operand with addition of 2 ||differences of address of ||labels Keywords||ice-on-invalid-code
[Bug c/112500] New: GCC: 14: internal compiler error: in expand_asm_stmt, at cfgexpand.cc:3419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112500
Bug ID: 112500
Summary: GCC: 14: internal compiler error: in expand_asm_stmt,
at cfgexpand.cc:3419
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: ---
Compiler Explorer: https://gcc.godbolt.org/z/PbTj4Gq3r
When compiling this program with `gcc-14 -O0`, gcc crashes:
```
void f(char *a, unsigned int l) {
asm volatile("" ::"m"((char (*)[l])a--));
}
```
The crash output:
```
during RTL pass: expand
: In function 'f':
:2:3: internal compiler error: in expand_asm_stmt, at cfgexpand.cc:3419
2 | asm volatile("" ::"m"((char (*)[l])a--));
| ^~~
0x238b15e internal_error(char const*, ...)
???:0
0xa11270 fancy_abort(char const*, int, char const*)
???: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 c/112499] New: GCC: 14: internal compiler error: output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112499
Bug ID: 112499
Summary: GCC: 14: internal compiler error: output_operand:
invalid expression as operand
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: ---
Compiler Explorer: https://gcc.godbolt.org/z/MdacfWqhr
When attempting to compile this program with `gcc-14 -O1`, gcc crashes:
```
#include
int f(void) {
static uintptr_t a = ((char *)& - (char *)&) +
((char *)& - (char *)&);
l1:
l2:
l3:
return a;
}
```
If removing the qualifier `static`, then this crash disappears.
The crash output:
```
:10:1: internal compiler error: output_operand: invalid expression as
operand
10 | }
| ^
0x238b15e internal_error(char const*, ...)
???:0
0xd01147 output_operand_lossage(char const*, ...)
???:0
0xd01c71 output_addr_const(_IO_FILE*, rtx_def*)
???:0
0xd01a53 output_addr_const(_IO_FILE*, rtx_def*)
???:0
0xd01ae5 output_addr_const(_IO_FILE*, rtx_def*)
???:0
0x14cec92 assemble_integer_with_op(char const*, rtx_def*)
???:0
0x14cecf1 default_assemble_integer(rtx_def*, unsigned int, int)
???:0
0x14ced7f assemble_integer(rtx_def*, unsigned int, unsigned int, int)
???:0
0x14e1cae assemble_variable(tree_node*, int, int, int)
???:0
0x14e62ae symbol_table::output_variables()
???:0
0xc027bb symbol_table::finalize_compilation_unit()
???: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 tree-optimization/112468] [14 Regression] Missed phi-opt after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112468 Hans-Peter Nilsson changed: What|Removed |Added Target|moxie-elf |moxie-elf, cris-elf, ||s390x-linux-gnu, ||m68k-linux-gnu, pru-elf CC||hp at gcc dot gnu.org --- Comment #6 from Hans-Peter Nilsson --- This commit caused test-suite regressions not just for moxie-elf but for several other targets; also cris-elf and according to gcc-testresults posts: s390x-ibm-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800481.html m68k-unknown-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800547.html pru-unknown-elf https://gcc.gnu.org/pipermail/gcc-testresults/2023-November/800569.html And it's not just gcc.dg/tree-ssa/phi-opt-24.c scan-tree-dump-not phiopt2 "if", but: Running /x/gcc/gcc/testsuite/gcc.dg/dg.exp ... [...] FAIL: gcc.dg/pr55152-2.c scan-tree-dump-times optimized ".COPYSIGN" 1 FAIL: gcc.dg/pr55152-2.c scan-tree-dump-times optimized "ABS_EXPR" 1 Running /x/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ... FAIL: gcc.dg/tree-ssa/abs-4.c scan-tree-dump-times optimized "= ABS_EXPR" 1 FAIL: gcc.dg/tree-ssa/abs-4.c scan-tree-dump-times optimized "= -" 1 FAIL: gcc.dg/tree-ssa/abs-4.c scan-tree-dump-times optimized "= .COPYSIGN" 2 FAIL: gcc.dg/tree-ssa/backprop-6.c scan-tree-dump-times backprop "Deleting[^\\n]* = -" 4 FAIL: gcc.dg/tree-ssa/backprop-6.c scan-tree-dump-times backprop "Deleting[^\\n]* = \\.COPYSIGN" 2 FAIL: gcc.dg/tree-ssa/backprop-6.c scan-tree-dump-times backprop "Deleting[^\\n]* = ABS_EXPR <" 1 FAIL: gcc.dg/tree-ssa/copy-headers-8.c scan-tree-dump-times ch2 "Conditional combines static and invariant" 1 FAIL: gcc.dg/tree-ssa/copy-headers-8.c scan-tree-dump-times ch2 "Will duplicate bb" 2 FAIL: gcc.dg/tree-ssa/copy-sign-2.c scan-tree-dump-times optimized "ABS" 1 FAIL: gcc.dg/tree-ssa/copy-sign-2.c scan-tree-dump-times optimized ".COPYSIGN" 1 FAIL: gcc.dg/tree-ssa/phi-opt-24.c scan-tree-dump-not phiopt2 "if" Summarily: gcc.sum gcc.dg/pr55152-2.c gcc.sum gcc.dg/tree-ssa/abs-4.c gcc.sum gcc.dg/tree-ssa/backprop-6.c gcc.sum gcc.dg/tree-ssa/copy-sign-2.c gcc.sum gcc.dg/tree-ssa/phi-opt-24.c
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #43 from Jeffrey A. Law --- I would expect allowing larger offsets before reload to be a significant problem. The core issue is integer memory operations allow 14 bits while FP only allows 5. During reloading we don't know if any given memory reference is FP or integer. xmpyu plays a role here too since it's going to require FP registers in integer modes. But what I don't understand is why f-m-o fails to push the offset into the memory reference -- it should be conditional on the insn being recognized. And since it's after reload we know if we're doing an FP or integer load.
[Bug c++/112490] infinite meta error in reverse_iterator::iterator>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99599 --- Comment #2 from Andrew Pinski --- Also see PR 99599 .
[Bug c++/112490] infinite meta error in reverse_iterator::iterator>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490 --- Comment #1 from Andrew Pinski --- Well clang does not implement CWG2369 resolution. Which GCC implemented in r11-2774 . So it might be that is the reason why GCC rejects it and clang does not.
[Bug target/111926] RISC-V: Use vsetvl insn replace csrr vlenb insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111926 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity after undefined decl defining a `thread_local auto` and weakref/alias attribute had been used before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 Andrew Pinski changed: What|Removed |Added Summary|ICE internal compiler |ICE internal compiler |error: in |error: in |discriminator_for_local_ent |discriminator_for_local_ent |ity, at cp/mangle.cc:2065 |ity after undefined decl ||defining a `thread_local ||auto` and weakref/alias ||attribute had been used ||before --- Comment #9 from Andrew Pinski --- note alias attribute also causes the ICE.
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |NEW Keywords|needs-reduction | --- Comment #8 from Andrew Pinski --- Confirmed. Note the difference between my build and the others is due to: # if __GLIBC_PREREQ(2, 34) // Since glibc 2.34 all pthreads functions are usable without linking to // libpthread. # define _GLIBCXX_GTHREAD_USE_WEAK 0 # endif That is I have a newer glibc which causes __weakref__ not to be needed/used here. So next time please attach the preprocessed source when running into a bug in the front-end, because different versions of glibc might produce different preprocessed sources and not able to reproduce the issue.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #42 from John David Anglin --- The problem is we are limiting displacements to five bits in pa_legitimate_address_p. The comment is somewhat confusing but we may have reload issues if we allow 14-bit displacements before reload completes. Testing a patch to see if we can allow 14-bit displacements before reload.
[Bug c++/112498] std::is_convertible::value returns false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112498 --- Comment #2 from Ingo Josopait --- Yes, you are right. It is confusing, though. Maybe the warning message should mention that it is actually invalid code. It looked more like a suggestion to me.
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 --- Comment #7 from Andrew Pinski --- Created attachment 56566 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56566=edit Reduced testcase
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 --- Comment #6 from Andrew Pinski --- Created attachment 56565 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56565=edit unreduced testcase Ok, with this preprocessed source I am able to reproduce it locally. I have not looked into what is the difference on why I could reproduce it with the headers I have.
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 --- Comment #5 from Andrew Pinski --- I tried `--param ggc-min-expand=0 --param ggc-min-heapsize=0` and it still does not ICE. The exact command line I tried: ``` [apinski@xeond2 upstream-gcc-match]$ ~/upstream-gcc-match/bin/gcc t.cc -DICE -g -g0 -Wall -pthread -O3 --param ggc-min-expand=0 --param ggc-min-heapsize=0 ``` One difference between my build and godbolt is I don't use `--enable-libstdcxx-debug ` .
[Bug c++/111934] ICE internal compiler error: in discriminator_for_local_entity, at cp/mangle.cc:2065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111934 --- Comment #4 from Andrew Pinski --- This is interesting, I cannot reproduce it locally with r14-5371-g93e92b2e5d6866 . but with the version in godbolt I could (r14-5368-ge0787da263322f).
[Bug target/111874] Missed mask_fold_left_plus with AVX512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111874 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-11-12 Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- .
[Bug tree-optimization/112404] [14 Regression] 521.wrf_r fails to build with internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112404 Andrew Pinski changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 111859 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/111859] 521.wrf_r build failure with -O2 -march=cascadelake --param vect-partial-vector-usage=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111859 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 112404 ***
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg) since r14-2526-g8911879415d6c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 --- Comment #12 from Roger Sayle --- Patch proposed (actually two alternatives proposed) at https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636203.html
[Bug middle-end/111817] ICE in expand_asm_stmt with invalid characters in inline-asm output operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111817 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |NEW Summary|GCC: 14: internal compiler |ICE in expand_asm_stmt with |error: in expand_asm_stmt, |invalid characters in |at cfgexpand.cc:3389|inline-asm output operands --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug web/108473] bugzilla see also should support gitlab.com URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #2 from Sam James --- You may want to pick up the patches we use in Gentoo: * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=5c1d751f03ddca21442fc782da0fb21dd178c372 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=711d93ef417796e29586dee53135a049f79f84a1 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=fb1b1c796b1fb13ab52bb4ff45952598c7e2ca03 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=6a60bc33530f416429d09a47fbcc565a0e20ff93 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=abfbdfc45c71af6a14bcc4cd5354044cfca14add * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=51ae055728e7c266e8d192c8bfd836af17eda288 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=3b91727edf3a546f3407d37f4ce5859e8e5609bc * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=87914943d5b70a9623e06f9a615d4e974ffa5764 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=ca51ed9196a30be1a2b03b8b650a28c5f2479c9c * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=f6eaf5c9752dc8beaf0329e235a36b6d24324467 * https://gitweb.gentoo.org/fork/bugzilla.git/commit/?id=96f022bb6218b164f38a0a01764a9aee17e36154 This adds a bunch of common bug trackers and code review sites like phabricator, gerrit, gitlab, etc.
[Bug web/108473] bugzilla see also should support gitlab.com URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |NEW --- Comment #6 from Andrew Pinski --- Confirmed. bt32_setb2, bt32v_setb, bt32v_setb2 are the only ones done for 64bit.
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg) since r14-2526-g8911879415d6c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 --- Comment #11 from Sam James --- (In reply to Roger Sayle from comment #10) > > I'm testing a patch. Did you get anywhere in the end?
[Bug target/107671] i386: Missed optimization: use of bt in bit test pattern (using -O2 -mtune=core2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/112385] `(2 >> a) ^ (5 >> a)` is not optimized to `7 >> a` is 2 and 5 differ in signedness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112385 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- Mine, I will handle this.
[Bug c++/112498] std::is_convertible::value returns false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112498
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
Component|libstdc++ |c++
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=111842
--- Comment #1 from Andrew Pinski ---
No.
```
_Float16 f(float a)
{
return a;
}
```
is invalid C++23 code.
:3:10: warning: converting to '_Float16' from 'float' with greater
conversion rank
Maybe we should add this to the FAQ because we get a question about implicit
conversion from _Float16 to float a few times now.
See
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1467r4.html#implicit
Which is the C++ paper which adds the extended floating point types and GCC
implements it full. Just as an extension allows the conversion (with a warning)
but since we cannot have different behavior for sfinae and concepts with
-pedantic/-pedantic-errors std::is_convertible needs to return false.
[Bug libstdc++/112498] New: std::is_convertible::value returns false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112498
Bug ID: 112498
Summary: std::is_convertible::value returns
false
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: josopait at goopax dot com
Target Milestone: ---
If I am not mistaken, this should succeed:
#include
int main()
{
static_assert(std::is_convertible::value); // ok
static_assert(std::is_convertible::value); // fails
}
[Bug c/111811] [14 Regression] ICE with vector float bitfield after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #2 from Andrew Pinski ---
But we should also be rejecting:
```
struct A {
__attribute__((__vector_size__(4))) int d : 1;
};
struct A b = {0};
```
Which we currently accepts before and ICE now.
Note for the float case, we could in theory change:
```
/* Detect invalid bit-field type. */
if (TREE_CODE (*type) != INTEGER_TYPE
&& TREE_CODE (*type) != BOOLEAN_TYPE
&& TREE_CODE (*type) != ENUMERAL_TYPE
&& TREE_CODE (*type) != BITINT_TYPE)
{
error_at (loc, "bit-field %qs has invalid type", name);
*type = unsigned_type_node;
}
```
to use error_mark_node instead of unsigned_type_node here and that would fix
the ICE for the original testcase but not the above testcase.
[Bug c/111811] [14 Regression] ICE with vector float bitfield after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-11-12
Summary|ICE with vector float |[14 Regression] ICE with
|bitfield after error|vector float bitfield after
||error
CC||pinskia at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Target Milestone|--- |14.0
--- Comment #1 from Andrew Pinski ---
Confirmed.
if (TREE_CODE (field) == FIELD_DECL
&& DECL_INITIAL (field)
&& TREE_TYPE (field) != error_mark_node)
{
unsigned HOST_WIDE_INT width
= tree_to_uhwi (DECL_INITIAL (field));
tree type = TREE_TYPE (field);
if (width != TYPE_PRECISION (type)) <--- Crash
{
Obvious introduced by the TYPE_PRECISION change to ICE on vector types:
r14-2150-gfe48f2651334bc
[Bug tree-optimization/112472] (trunc)copysign((extend)x, CST) is not optimized to just copysign(x, CST')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112472 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2023-11-12 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Mine.
[Bug target/103959] float64x1_t not using fmov to generate some float values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103959 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Mine.
[Bug tree-optimization/110405] missing nonzerobits on branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110405
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-12
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
Another testcase:
```
void h(unsigned long);
void
f (unsigned long i)
{
if ((i & 7) != 6) __builtin_unreachable();
if(i & 1)
h(0);
}
```
Note LLVM is able to optimize both cases.
Note for the above testcase we get for the range:
# RANGE [irange] long unsigned int [6, 18446744073709551614]
Notice how the value/mask is not there even though we should be able to get it
from the IR.
[Bug tree-optimization/110262] `t < 0 ? 1 : min(t, 1)` is not simplified down to just `t != 0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110262 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104296 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-11-12 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- So basically: min(t, 1) -> `t != 0` if we know at this point t is nonnegative ... and that is how it gets simplified.
[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100165 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100165 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- Mine, I will handle this. Most likely for GCC 15 though.
[Bug libstdc++/111638] GLIBCXX_MAYBE_UNDERSCORED_FUNCS autoconf macro doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111638 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- Fixed for gcc 14.
[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100165 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-11-12 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Currently the trunk produces: ``` foo: ins v0.d[1], xzr ret foo1: moviv31.4s, 0 zip1v0.2d, v0.2d, v31.2d ret foo2: ins v0.d[1], xzr ret ``` Which is better than 10.x but still not using fmov.
[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100165 --- Comment #2 from Andrew Pinski --- Created attachment 56564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56564=edit Full testcase
[Bug c/112431] RISC-V GCC-15 feature: Support register overlap on widen RVV instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug middle-end/112403] `s+ (a?-1:1)` and `a?s-1:s+1` produce two different code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112403 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/112399] RISC-V: Missed AVL propagation for complicate reduction case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112399 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |14.0
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||wrong-code
[Bug tree-optimization/112450] RVV vectorization ICE in vect_get_loop_mask, at tree-vect-loop.cc:11037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112450 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug target/112433] RISC-V GCC-15 feature: Split register allocation into RVV and non-RVV, and make vsetvl PASS run between them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112433 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug rtl-optimization/112494] ICE in ix86_cc_mode, at config/i386/i386.cc:16477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494 --- Comment #2 from Andrew Pinski --- It has failed since __writeeflags/__readeflags was added in 4.9.0.
[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819 --- Comment #5 from anlauf at gcc dot gnu.org --- Created attachment 56563 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56563=edit Partial testsuite fixes This patch contains obvious fixes to 3 testcases, except for assumed_rank_9.f90, which is more severe, as it violates ! F2018:15.5.2.5 Allocatable and pointer dummy variables ! ! The actual argument shall be polymorphic if and only if the associated ! dummy argument is polymorphic, and either both the actual and dummy ! arguments shall be unlimited polymorphic, or the declared type of the ! actual argument shall be the same as the declared type of the dummy ! argument. ! ! F2023:15.5.2.6 has the same text which is detected (mostly) by NAG and Intel. We need to detect and diagnose violations of the above.
[Bug rtl-optimization/112494] GCC: 14: internal compiler error: in ix86_cc_mode, at config/i386/i386.cc:16477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112494
Uroš Bizjak changed:
What|Removed |Added
Last reconfirmed||2023-11-12
Ever confirmed|0 |1
Component|target |rtl-optimization
Status|UNCONFIRMED |NEW
--- Comment #1 from Uroš Bizjak ---
Combine pass is trying to combine:
Trying 5 -> 8:
5: r98:DI=0xd7
8: flags:CCZ=cmp(r98:DI,0)
REG_EQUAL cmp(0xd7,0)
where:
(insn 5 2 6 2 (set (reg/v:DI 98 [ flags ])
(const_int 215 [0xd7])) "pr112494.c":10:26 84 {*movdi_internal}
(nil))
(insn 8 7 11 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:DI 98 [ flags ])
(const_int 0 [0]))) "pr112494.c":12:9 8 {*cmpdi_ccno_1}
(expr_list:REG_EQUAL (compare:CCZ (const_int 215 [0xd7])
(const_int 0 [0]))
(nil)))
and calls ix86_cc_mode with:
Breakpoint 1, ix86_cc_mode (code=code@entry=SET, op0=0x7fffe3e37680,
op1=0x7fffea209490)
code = SET will trigger gcc_unreachable() at the end of the ix86_cc_mode
function.
Confirmed as a generic RTL optimization problem.
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 Xi Ruoyao changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |xry111 at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Novembe ||r/636200.html --- Comment #10 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #8) > (In reply to Tamar Christina from comment #7) > > Yeah, that fold-rtx code is bogus. It's a latent bug. > > > > Optimizing copysign(x, -y) to neg(x) is just wrong. > > > > Will you be sending a patch Xi or do you want me to? > > Yes, I'm running a regression test now and I'll send the patch after it > finishes. https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636200.html
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 --- Comment #9 from Xi Ruoyao --- *** Bug 112484 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/112484] [14 Regression] 26_numerics/random/{poisson_distribution,negative_binomial_distribution}/operators/values.cc fails on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112484 Xi Ruoyao changed: What|Removed |Added Resolution|--- |DUPLICATE Component|target |rtl-optimization Status|UNCONFIRMED |RESOLVED --- Comment #1 from Xi Ruoyao --- The fix for PR112483 also fixes this. I didn't expect that... *** This bug has been marked as a duplicate of bug 112483 ***
[Bug target/110790] [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110790 --- Comment #9 from Uroš Bizjak --- (In reply to Andrew Pinski from comment #8) > I need some code generation help for gcc.target/i386/pr110790-2.c, I have a > patch where we now generate: > ``` > movq(%rdi,%rax,8), %rax > shrq%cl, %rax > andl$1, %eax > ``` > > instead of previously: > ``` > movq(%rdi,%rax,8), %rax > btq %rsi, %rax > setc%al > movzbl %al, %eax > ``` > > I suspect the sequence that contains shrq/and is better but I am 100% sure. > We still get btq when used with a conditional too. The new sequence is better. It does not create a partial reg write (setc needs a clearing XOR in fron of CC-setting instruction).
[Bug target/110790] [14 Regression] gcc -m32 generates invalid bit test code on gmp-6.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110790 --- Comment #8 from Andrew Pinski --- I need some code generation help for gcc.target/i386/pr110790-2.c, I have a patch where we now generate: ``` movq(%rdi,%rax,8), %rax shrq%cl, %rax andl$1, %eax ``` instead of previously: ``` movq(%rdi,%rax,8), %rax btq %rsi, %rax setc%al movzbl %al, %eax ``` I suspect the sequence that contains shrq/and is better but I am 100% sure. We still get btq when used with a conditional too.
[Bug ipa/112487] [11/12/13/14 Regression] ICE in setup_one_parameter with conflicting types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112487 Andrew Pinski changed: What|Removed |Added Known to work||9.5.0 Summary|[14 Regression] internal|[11/12/13/14 Regression] |compiler error: in |ICE in setup_one_parameter |setup_one_parameter, at |with conflicting types |tree-inline.cc:3565 | Status|UNCONFIRMED |NEW Target Milestone|14.0|11.5 Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Known to fail||10.1.0, 11.1.0, 13.2.0 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 --- Comment #8 from Xi Ruoyao --- (In reply to Tamar Christina from comment #7) > Yeah, that fold-rtx code is bogus. It's a latent bug. > > Optimizing copysign(x, -y) to neg(x) is just wrong. > > Will you be sending a patch Xi or do you want me to? Yes, I'm running a regression test now and I'll send the patch after it finishes.
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #7 from Tamar Christina --- Yeah, that fold-rtx code is bogus. It's a latent bug. Optimizing copysign(x, -y) to neg(x) is just wrong. Will you be sending a patch Xi or do you want me to?
[Bug ipa/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-11-12 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug ipa/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488 Andrew Pinski changed: What|Removed |Added Known to work||13.2.0 Summary|GCC: 14: internal compiler |[14 Regression] ICE in |error: in make_ssa_name_fn, |make_ssa_name_fn with VLA |at tree-ssanames.cc:354 |inside type and inlining Known to fail||14.0 Target Milestone|--- |14.0
[Bug tree-optimization/109689] [14 Regression] ICE at -O1 with "-ftree-vectorize": in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 since r14-301-gf2d6beb7a4ddf1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109689 Andrew Pinski changed: What|Removed |Added CC||141242068 at smail dot nju.edu.cn --- Comment #12 from Andrew Pinski --- *** Bug 112489 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/112489] GCC: 14: internal compiler error: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112489 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 109689. *** This bug has been marked as a duplicate of bug 109689 ***
[Bug rtl-optimization/110390] ICE on valid code on x86_64-linux-gnu with sel-scheduling: in av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.cc:3609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390 --- Comment #4 from Andrew Pinski --- (In reply to Thomas Koenig from comment #3) > Fixed by r14-3414-g0cfc9c953d0221: That almost definitely just made the issue go latent.
[Bug rtl-optimization/112483] [14 Regression] gfortran.dg/ieee/ieee_2.f90 fails on loongarch64-linux-gnu at -O1 or above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112483
Thomas Schwinge changed:
What|Removed |Added
Target|loongarch64-linux-gnu |loongarch64-linux-gnu
||powerpc64le-linux-gnu
CC||tschwinge at gcc dot gnu.org
--- Comment #6 from Thomas Schwinge ---
(In reply to Xi Ruoyao from comment #5)
> In simplify_binary_operation_1, simplify-rtx.cc:
>
> case COPYSIGN:
> if (rtx_equal_p (trueop0, trueop1) && ! side_effects_p (op0))
> return op0;
> if (CONST_DOUBLE_AS_FLOAT_P (trueop1))
> {
> REAL_VALUE_TYPE f1;
> real_convert (, mode, CONST_DOUBLE_REAL_VALUE (trueop1));
> rtx tmp = simplify_gen_unary (ABS, mode, op0, mode);
> if (REAL_VALUE_NEGATIVE (f1))
> tmp = simplify_gen_unary (NEG, mode, op0, mode);
> ^^^
> return tmp;
> }
>
> shouldn't the "op0" with caret be "tmp" instead??
I have no knowledge at all about that code, but your suggested change appears
legit, and I do confirm that it does fix the following powerpc64le-linux-gnu
regressions:
@@ -169421,7 +169467,7 @@ PASS: gcc.target/powerpc/p8vector-fp.c
scan-assembler xsdivdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsdivsp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsmuldp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsmulsp
[-PASS:-]{+FAIL:+} gcc.target/powerpc/p8vector-fp.c scan-assembler xsnabsdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xsnegdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xssqrtdp
PASS: gcc.target/powerpc/p8vector-fp.c scan-assembler xssqrtsp
PASS: gfortran.dg/ieee/ieee_2.f90 -O0 (test for excess errors)
PASS: gfortran.dg/ieee/ieee_2.f90 -O0 execution test
PASS: gfortran.dg/ieee/ieee_2.f90 -O1 (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/ieee/ieee_2.f90 -O1 execution test
PASS: gfortran.dg/ieee/ieee_2.f90 -O2 (test for excess errors)
PASS: gfortran.dg/ieee/ieee_2.f90 -O2 execution test
PASS: gfortran.dg/ieee/ieee_2.f90 -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions (test for excess errors)
@@ -63715,7 +63751,7 @@ PASS: gfortran.dg/ieee/ieee_2.f90 -O3
-fomit-frame-pointer -funroll-loops -fpe
PASS: gfortran.dg/ieee/ieee_2.f90 -O3 -g (test for excess errors)
PASS: gfortran.dg/ieee/ieee_2.f90 -O3 -g execution test
PASS: gfortran.dg/ieee/ieee_2.f90 -Os (test for excess errors)
[-PASS:-]{+FAIL:+} gfortran.dg/ieee/ieee_2.f90 -Os execution test
[Bug rtl-optimization/110390] ICE on valid code on x86_64-linux-gnu with sel-scheduling: in av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.cc:3609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390 --- Comment #3 from Thomas Koenig --- Fixed by r14-3414-g0cfc9c953d0221: 0cfc9c953d0221ec3971a25e6509ebe1041f142e is the first new commit commit 0cfc9c953d0221ec3971a25e6509ebe1041f142e Author: Andrew MacLeod Date: Thu Aug 17 12:34:59 2023 -0400 Phi analyzer - Initialize with range instead of a tree. Rangers PHI analyzer currently only allows a single initializer to a group. This patch changes that to use an inialization range, which is cumulative of all integer constants, plus a single symbolic value. There is no other change to group functionality. This patch also changes the way PHI groups are printed so they show up in the listing as they are encountered, rather than as a list at the end. It was more difficult to see what was going on previously.
[Bug bootstrap/112497] [14 Regression] Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497 Xi Ruoyao changed: What|Removed |Added Target Milestone|--- |14.0
[Bug bootstrap/112497] [14 Regression] Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497 Xi Ruoyao changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Xi Ruoyao --- The problematic commit reverted at r14-5371. I've tested the reversion locally, so marking this fixed.
[Bug bootstrap/112497] [14 Regression] Bootstrap comparison failure: gcc/analyzer/constraint-manager.o differs on loongarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112497 --- Comment #5 from Jeffrey A. Law --- This failure means the stage1 and stage2 compilers generated different code for the same input. So when I need to debug this I usually start by first getting that source code. Based in the title of this bugzilla you're going to want the .ii file for constraint-manager as built by either the stage1 or stage2 compiler. Then I feed that into the stage1 and stage2 compiler with the same optimization options to verify that they indeed generate different code. Sometimes that doesn't work when the issue is debug insns, but that's where I start. Once I have confirmed the two compilers generate different code, then I try to isolate where/why. This can often be done by looking a debug dumps to narrow things down to a pass that's behaving differently. Alternately you can replace objects in the stage2 compiler with those from the stage1 compiler to narrow it down to a single .o that causes the compiler's behavior to diverge. Then it's usually a matter going into the debugger and understanding why the given pass is behaving differently. It's a long, painful process. *Sometimes* you can just build the stage1 compiler and run the testsuite and see if there are new failures on your target. It doesn't always generate something useful, but when it does it's often faster than the process I mentioned above.
