[Bug target/113059] [14 regression] fftw fails tests for -O3 -m32 -march=znver2 since r14-6210-ge44ed92dbbe9d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059 --- Comment #15 from Sam James --- at what point can we consider a revert for 14 and revisit for 15? there's a few things which keep cropping up and I don't want to be ignoring other regressions because I'm assuming it's the same as this
[Bug tree-optimization/113659] [14 Regression] ICE Segmentation fault since r14-8355-g02e683894942da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659 --- Comment #2 from Tamar Christina --- looks like get_virtual_phi returned NULL. but this loop shouldn't have vectorized. The submitted fix for PR113588 "fixes" it too by not allowing it to be vectorized. Such loops need to be handled differently in GCC 15 as we discussed before.
[Bug tree-optimization/113659] [14 Regression] ICE Segmentation fault since r14-8355-g02e683894942da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-01-30 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug tree-optimization/113659] [14 Regression] ICE Segmentation fault since r14-8355-g02e683894942da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659 --- Comment #1 from Richard Biener --- I will have a look.
[Bug tree-optimization/113659] [14 Regression] ICE Segmentation fault since r14-8355-g02e683894942da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659 Andrew Pinski changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org Target Milestone|--- |14.0
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #26 from Tamar Christina --- Ah great, just checking it wasn't left unattended :)
[Bug target/113095] [13 Regression] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113095 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.3 Known to work||14.0 Summary|RISC-V: movcc no longer |[13 Regression] RISC-V: |used for coremark crc |movcc no longer used for |functions with |coremark crc functions with |-mtune=sifive-7-series |-mtune=sifive-7-series Ever confirmed|0 |1 Last reconfirmed||2024-01-30 Status|UNCONFIRMED |NEW --- Comment #6 from Andrew Pinski --- .
[Bug target/113657] [14 Regression] ICE Segmentation fault with -mstrict-align and __arm_data512_t since r14-1187-gd6b756447cd58b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113657 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-30 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. 8229simplify_gen_subreg (TImode, operands[1], V8DImode, offset) (gdb) p debug_rtx(operands[1]) (mem:V8DI (reg/f:DI 0 x0 [101]) [1 *ptr_2(D)+0 S64 A64]) $4 = void (gdb) p offset $5 = 0 That is due to: /* V8DI mode. */ VECTOR_MODE_WITH_PREFIX (V, INT, DI, 8, 5); ADJUST_ALIGNMENT (V8DI, 8); So maybe for strict alignment, we need to loop using DImode instead of TImode and hope ldp/stp pass optimizes it back into load/store pairs ...
[Bug debug/113562] [14 Regression] FAIL: gcc.dg/guality/pr54796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562 --- Comment #4 from Richard Biener --- (In reply to Richard Biener from comment #3) > Just to put it somewhere I ran dwlocstat on cc1plus before/after the > offending change and it looks almost the same. We go from > > cov%samples cumul > 0..10 1280217/38% 1280217/38% > 11..20 55668/1%1335885/40% > 21..30 68004/2%1403889/42% > 31..40 70774/2%1474663/44% > 41..50 75554/2%1550217/46% > 51..60 91816/2%1642033/49% > 61..70 101139/3% 1743172/52% > 71..80 135281/4% 1878453/56% > 81..90 198470/5% 2076923/62% > 91..100 1233822/37% 3310745/100% > > to > > cov%samples cumul > 0..10 1280197/38% 1280197/38% > 11..20 55669/1%1335866/40% > 21..30 68014/2%1403880/42% > 31..40 70773/2%1474653/44% > 41..50 75542/2%1550195/46% > 51..60 91800/2%1641995/49% > 61..70 101133/3% 1743128/52% > 71..80 135259/4% 1878387/56% > 81..90 198496/5% 2076883/62% > 91..100 1233844/37% 3310727/100% And with up-to-date elfutils to avoid some DWARF5 issues cov%samples cumul 0..10 1280347/38% 1280347/38% 11..20 55720/1%1336067/40% 21..30 68040/2%1404107/42% 31..40 70805/2%1474912/44% 41..50 75585/2%1550497/46% 51..60 91850/2%1642347/49% 61..70 101224/3% 1743571/52% 71..80 135406/4% 1878977/56% 81..90 198509/5% 2077486/62% 91..100 1233880/37% 3311366/100% to cov%samples cumul 0..10 1280327/38% 1280327/38% 11..20 55721/1%1336048/40% 21..30 68050/2%1404098/42% 31..40 70804/2%1474902/44% 41..50 75573/2%1550475/46% 51..60 91834/2%1642309/49% 61..70 101218/3% 1743527/52% 71..80 135384/4% 1878911/56% 81..90 198535/5% 2077446/62% 91..100 1233902/37% 3311348/100%
[Bug target/113657] [14 Regression] ICE Segmentation fault with -mstrict-align and __arm_data512_t since r14-1187-gd6b756447cd58b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113657 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |14.0 Summary|[14 Regression] ICE |[14 Regression] ICE |Segmentation fault since|Segmentation fault with |r14-1187-gd6b756447cd58b|-mstrict-align and ||__arm_data512_t since ||r14-1187-gd6b756447cd58b
[Bug debug/113637] ICE: in as_a, at machmode.h:381 with extern function declaration and _BitInt() used as VLA size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113637 --- Comment #2 from Andrew Pinski --- && (INTEGRAL_TYPE_P (TREE_TYPE (loc)) || POINTER_TYPE_P (TREE_TYPE (loc))) && (GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (TREE_TYPE (loc))) <= DWARF2_ADDR_SIZE)) Maybe TYPE_PRECISION instead of `GET_MODE_SIZE (SCALAR_INT_TYPE_MODE`? Note this code was added by r7-6893-g680c60feb43035.
[Bug debug/113637] ICE: in as_a, at machmode.h:381 with extern function declaration and _BitInt() used as VLA size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113637 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-01-30 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug middle-end/113651] The GCC optimizer performs poorly on a very simple code snippet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113651 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement CC||pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > Whether this is better suited for GIMPLE or RTL if-conversion remains to be > seen. I suspect we could do something in isel. phiopt has something similar for casts already though too. I have some ideas on how we undo the conditional xor and then see if we do another phiopt if so don't put it back as conditional. And then in isel if we see `a ? x ^ CST : 0` do it as `x ^ (a ? CST : 0)` if the target has cmov but there needs to be some cost model; I am not sure how though. (I still wonder if x86's cmov has improved in recent years so that doing 2 cmov back to back still worse than a branch; LLVM seems not to care about doing cmov cost model and the performance there is ok).
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 Kewen Lin changed: What|Removed |Added Summary|Failed bootstrap on ppc |[14 regression] Failed |unrecognized opcode:|bootstrap on ppc |`lfiwzx' with -mcpu=7450|unrecognized opcode: ||`lfiwzx' with -mcpu=7450 --- Comment #12 from Kewen Lin --- (In reply to Sam James from comment #10) > (In reality, I think it is a regression, given: > a) it regresses non-release checking (which we sometimes use even for > released versions, it's opt-in though); But I assumed that non-release checking on old releases should also fail, from non-release vs. non-release, the behavior doesn't change. > b) it blocks further testing with GCC 14 > Sorry for that, put it back as you like. :) > but I understand the argument that if a release were made with it, it > wouldn't be the end of the world by itself and it only affects a specific > configuration.)
[Bug target/113656] [x86] ICE in simplify_const_unary_operation, at simplify-rtx.cc:1954 with new -mavx10.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656 --- Comment #3 from Haochen Jiang --- (In reply to Haochen Jiang from comment #2) > Actually it is caused by option -funsafe-math-optimizations but not > -mavx10.1. > > Before my commit, while using option: > > -frounding-math -O3 -mavx512fp16 -mavx512vl -funsafe-math-optimizations > > It will also report ICE. In GCC13.2, it won't, which means it is introduced > in GCC14. > > You got that bisect result since it is when avx10.1 first introduced. > -mavx10.1 will enable -mavx512fp16 and -mavx512vl. > > When we eliminate -funsafe-math-optimizations, it will be ok. > > Also if we are only using -mavx512vl, everything is ok. Seems like something > got disabled under -mavx512fp16. What I mean "disabled" here is actually not enabled while using -funsafe-math-optimizations with -mavx512fp16. > > Need more bisect with option: -frounding-math -O3 -mavx512fp16 -mavx512vl > -funsafe-math-optimizations to find out why.
[Bug target/113656] [x86] ICE in simplify_const_unary_operation, at simplify-rtx.cc:1954 with new -mavx10.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656 --- Comment #2 from Haochen Jiang --- Actually it is caused by option -funsafe-math-optimizations but not -mavx10.1. Before my commit, while using option: -frounding-math -O3 -mavx512fp16 -mavx512vl -funsafe-math-optimizations It will also report ICE. In GCC13.2, it won't, which means it is introduced in GCC14. You got that bisect result since it is when avx10.1 first introduced. -mavx10.1 will enable -mavx512fp16 and -mavx512vl. When we eliminate -funsafe-math-optimizations, it will be ok. Also if we are only using -mavx512vl, everything is ok. Seems like something got disabled under -mavx512fp16. Need more bisect with option: -frounding-math -O3 -mavx512fp16 -mavx512vl -funsafe-math-optimizations to find out why.
[Bug libstdc++/112551] Incompatibility of libstdc++ linked statically and -Bsymbolic-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112551 --- Comment #2 from Sam James --- Writeup about this: https://hacks.mozilla.org/2024/01/option-soup-the-subtle-pitfalls-of-combining-compiler-flags/.
[Bug target/113652] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #11 from Kewen Lin ---
In gcc, lfiwzx is guarded with TARGET_LFIWZX => TARGET_POPCNTD (ISA2.06), while
-mvsx will guarantee TARGET_POPCNTD (ISA_2_6_MASKS_SERVER) set, so it considers
lfiwzx is supported. IMHO the underlying philosophy is that having the
capability of vsx the supported ISA level is at least 2.06, lfiwzx is supported
from 2.06, so it's supported.
But binutils seems not to follow it:
{"xvadddp", XX3(60,96), XX3_MASK,PPCVSX,PPCVLE, {XT6,
XA6, XB6}},
{"lfiwzx", X(31,887), X_MASK, POWER7|PPCA2, 0, {FRT,
RA0, RB}},
Both are guarded with different masks and apparently PPCVSX doesn't enable
POWER7.
Hi Alan and Peter,
I wonder if assembler can enable POWER7 when PPCVSX gets enabled like what gcc
adopts now?
[Bug target/113652] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #10 from Sam James --- (In reality, I think it is a regression, given: a) it regresses non-release checking (which we sometimes use even for released versions, it's opt-in though); b) it blocks further testing with GCC 14 but I understand the argument that if a release were made with it, it wouldn't be the end of the world by itself and it only affects a specific configuration.)
[Bug target/113652] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 Kewen Lin changed: What|Removed |Added Summary|[14 regression] Failed |Failed bootstrap on ppc |bootstrap on ppc|unrecognized opcode: |unrecognized opcode:|`lfiwzx' with -mcpu=7450 |`lfiwzx' with -mcpu=7450| --- Comment #9 from Kewen Lin --- (In reply to Andrew Pinski from comment #8) > So t-float128 has this line: > # Build the emulator without ISA 3.0 hardware support. > FP128_CFLAGS_SW = -Wno-type-limits -mvsx -mfloat128 \ > ... > > Which gets added to some of the libgcc object files while compiling: > $(fp128_softfp_obj) : INTERNAL_CFLAGS += $(FP128_CFLAGS_SW) > $(fp128_ppc_obj) : INTERNAL_CFLAGS += $(FP128_CFLAGS_SW) > > > The problem is CFLAGS gets added also. It seems like passing -mvsx enables > some other instructions in GCC's code generation BUT does not enable it for > the assembler ... ah, just noticed that it's bootstrapping gcc. Stripping regression tag since I don't think it's actually a regression as comments above. I found that the libgcc_cv_powerpc_float128 checking can pass with -mcpu=7450 -mabi=altivec -mvsx -mfloat128, the assembler options are "-a32 -mppc -mvsx -maltivec -mbig" is actually the same as what are used for the case #c5 compiling. So it looks that -mvsx is supposed to tell assembler to recognize vsx instructions but somehow "lfiwzx" is not counted as vsx instruction. More specifically "xvadddp" is recognized by assembler with -mvsx while "lfiwzx" isn't. $ cat t1.s .machine "7450" lfiwzx 1,0,9 $ cat t2.s .machine "7450" xvadddp 34,34,35 $ as -a32 -mppc -mvsx t1.s -o t1.o t1.s: Assembler messages: t1.s:2: Error: unrecognized opcode: `lfiwzx' $ as -a32 -mppc -mvsx t2.s -o t2.o $ echo $? $ 0
[Bug ipa/113665] [11/12/13/14 regression] Regular for Loop results in Endless Loop with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665 --- Comment #4 from Andrew Pinski --- (In reply to Sam James from comment #3) > I will try bisect. Most likely r11-5094-gafa6adbd6c83ee or r11-4987-g602c6cfc79ce4a or r11-4986-ga1fdc16da34118 .
[Bug ipa/113665] [11/12/13/14 regression] Regular for Loop results in Endless Loop with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org Summary|Regular for Loop results in |[11/12/13/14 regression] |Endless Loop with -O2 |Regular for Loop results in ||Endless Loop with -O2 --- Comment #3 from Sam James --- I will try bisect.
[Bug analyzer/113654] [14 Regression] -Wanalyzer-allocation-size false positive seen on Linux kernel's drivers/gpu/drm/i915/display/intel_bios.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113654 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/113662] [13/14 Regression] Wrong code for std::sort with fancy pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Add -fno-ivopts also fixes the issue ... Note -fstack-reuse=none does NOT fix the issue so it is NOT the same as those.
[Bug target/113655] Cross compiling to mips64-elf fails because "MIPS_EXPLICIT_RELOCS was not declared" after r14-8386-g58af788d1d0825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||build
[Bug libstdc++/113663] [MinGW] std::filesystem::hard_link_count always returns 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- (In reply to Lennox Ho from comment #2) > Created attachment 57257 [details] > hard_link_count patch for Windows > > I've put together a patch (attached). https://gcc.gnu.org/contribute.html Patches in Bugzilla won't get a serious review.
[Bug c++/107594] ICE in module_state, at cp/module.cc:3810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107594 Nathaniel Shead changed: What|Removed |Added Target Milestone|--- |14.0 Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org CC||nshead at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Nathaniel Shead --- Fixed for GCC 14.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 107594, which changed state. Bug 107594 Summary: ICE in module_state, at cp/module.cc:3810 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107594 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/107594] ICE in module_state, at cp/module.cc:3810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107594 --- Comment #2 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:a88e08feb8367898e0562622517d33f95684a03d commit r14-8513-ga88e08feb8367898e0562622517d33f95684a03d Author: Nathaniel Shead Date: Sat Jan 27 22:46:44 2024 +1100 c++: Handle error header names in modules [PR107594] When there are no include paths while preprocessing a header-name token, an empty STRING_CST is returned. This patch ensures this is handled when attempting to create a module for this name. PR c++/107594 gcc/cp/ChangeLog: * module.cc (get_module): Bail on empty name. Signed-off-by: Nathaniel Shead
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #8 from Andrew Pinski --- So t-float128 has this line: # Build the emulator without ISA 3.0 hardware support. FP128_CFLAGS_SW = -Wno-type-limits -mvsx -mfloat128 \ ... Which gets added to some of the libgcc object files while compiling: $(fp128_softfp_obj) : INTERNAL_CFLAGS += $(FP128_CFLAGS_SW) $(fp128_ppc_obj) : INTERNAL_CFLAGS += $(FP128_CFLAGS_SW) The problem is CFLAGS gets added also. It seems like passing -mvsx enables some other instructions in GCC's code generation BUT does not enable it for the assembler ...
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #25 from Hongtao Liu --- (In reply to Tamar Christina from comment #24) > Just to avoid confusion, are you still working on this one Richi? I'm working on a patch to add a target hook as #c18 mentioned.
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #7 from Kewen Lin --- oops, I meant --enable-checking rather than --checking.
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #6 from Kewen Lin --- I think this is related to r10-580-ge154242724b084 and this failure is expected and a use error. With it applied, we don't always pass -many to assembler with CHECKING_P enabled. Actually compilers (gcc-13, gcc-12, gcc-11 or trunk) generate the same assembly, but because gcc-11/gcc-12/gcc-13 is built with --checking=release by default which doesn't set CHECKING_P while trunk is built with --checking=yes,extra by default which set CHECKING_P. So it causes the different behaviors so that further considered as regression unexpectedly. The issue should be gone if trunk gets released as gcc-14 or it's built with --checking=release. IMO Alan's commit aims to help to expose more and more such unexpected use cases and users can fix them in place. As #c3 "PowerPC 7450 (aka PowerPC G4) is only capable of -maltivec but not -mvsx", so it's unexpected to have -mcpu=7450 meanwhile having -mvsx, could you check where the -mvsx comes from and fix it instead? Thanks! btw, a workaround option is to add -Wa,-many to restore the previous behavior that passing -many to assembler.
[Bug target/113656] [x86] ICE in simplify_const_unary_operation, at simplify-rtx.cc:1954 with new -mavx10.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113656 --- Comment #1 from Haochen Jiang --- >From the first glance, it seems that the op here is wrongly interpreted. Investigating why.
[Bug c/113666] New: RISC-V: Cost model test regression due to recent middle-end loop vectorizer changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113666
Bug ID: 113666
Summary: RISC-V: Cost model test regression due to recent
middle-end loop vectorizer changes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
FAIL: gcc.dg/vect/costmodel/riscv/rvv/pr113281-1.c scan-assembler-not vset
FAIL: gcc.dg/vect/costmodel/riscv/rvv/pr113281-2.c scan-assembler-not vset
FAIL: gcc.dg/vect/costmodel/riscv/rvv/pr113281-5.c scan-assembler-not vset
unsigned char a;
int main() {
short b = a = 0;
for (; a != 19; a++)
if (a)
b = 32872 >> a;
if (b == 0)
return 0;
else
return 1;
}
-march=rv64gcv_zvl256b -mabi=lp64d -O3 -ftree-vectorize
We expect:
lui a5,%hi(a)
li a4,19
sb a4,%lo(a)(a5)
li a0,0
ret
However, we now have:
vsetvli a5,zero,e8,mf4,ta,ma
li a6,17
li a3,32768
vid.v v2
addiw a3,a3,104
vadd.vx v2,v2,a6
lui a1,%hi(a)
vsetvli zero,zero,e32,m1,ta,ma
li a0,19
vmv.v.x v1,a3
vzext.vf4 v3,v2
sb a0,%lo(a)(a1)
vsra.vv v1,v1,v3
vsetvli zero,zero,e16,mf2,ta,ma
vncvt.x.x.w v1,v1
vslidedown.vi v1,v1,1
vmv.x.s a0,v1
sneza0,a0
ret
I guess it is caused by this commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1a8261e047f7a2c2b0afb95716f7615cba718cd1
I don't known how to fix RISC-V backend cost model to recover back since
current
cost scalar_to_vec seems is already very high, it makes no sense to keep
raising
the cost of it.
[Bug c/112840] feature request: warn on incorrect tagged union value access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112840 --- Comment #3 from Matheus Afonso Martins Moreira --- (In reply to uecker from comment #2) > I would go for a more generic feature where one can specify some invariant / > condition that needs be true when a member of a struct / union is accessed. So the proposed solution is a guard(expr) attribute that causes the compiler to warn the developer if it can't statically determine that expr is true in the appropriate context. This would be great!! Much more flexible than the tag attribute I proposed. How can we make it happen? I've never hacked on GCC before.
[Bug ipa/113665] Regular for Loop results in Endless Loop with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |ipa Keywords||needs-bisection, ||needs-reduction Status|UNCONFIRMED |NEW Last reconfirmed||2024-01-30 Ever confirmed|0 |1 Target Milestone|--- |11.5 --- Comment #2 from Andrew Pinski --- Confirmed. The issue is IPA ICF figures out that bitfield<288>::test and bitfield<592>::test are the same but really they are not due to the size being different. /app/example.cpp:18:10: optimized: Semantic equality hit:bool bitfield::test(size_t) const [with long unsigned int S = 288]/60->bool bitfield::test(size_t) const [with long unsigned int S = 592]/61 /app/example.cpp:18:10: optimized: Assembler symbol names:_ZNK8bitfieldILm288EE4testEm.part.0/60->_ZNK8bitfieldILm592EE4testEm.part.0/61
[Bug libstdc++/97813] std::filesystem::equivalent returning incorrect results on MinGW due to symlinks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97813 --- Comment #5 from Lennox Ho --- Thanks for the insight. I think the only potential blocker would be CreateSymbolicLinkW requires at least Vista/WinSer2008. I'm not able to figure out MinGW (or at least mingw-w64)'s OS requirements. I might look into contributing a patch to enable Windows symlink support sometime in the future. In the meantime, I have a patch for std::filesytem::hard_link_count for Windows. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663 Thanks
[Bug libstdc++/113663] [MinGW] std::filesystem::hard_link_count always returns 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663 --- Comment #2 from Lennox Ho --- Created attachment 57257 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57257=edit hard_link_count patch for Windows I've put together a patch (attached).
[Bug c++/113665] Regular for Loop results in Endless Loop with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665 --- Comment #1 from Christoph Rüthing --- Note, that the volatile variables are just there to provide a minimal example and not have the entire loop optimized away. In the origian implementation I deduced this minimal example from, there was actually a useful implementation. But putting e.g. a std::cout at this place also solved the issue.
[Bug c++/113665] New: Regular for Loop results in Endless Loop with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665
Bug ID: 113665
Summary: Regular for Loop results in Endless Loop with -O2
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: christoph at muppetnet dot net
Target Milestone: ---
Compiling the example code below with GCC 11.4.0 (I actually encountered this
bug in all versions >= 11 which I tried but not in older ones) and -O2 (other
optimization levels seem to work) results in an endless loop and finally a
segmentation fault due to an out-of-bounds access.
We can clearly argue about issues in the implementation of the bitfield class
(it is based on a real implementation of such a class I encountered in existing
codebase) but the main problem here is that the simple for loop in bug() is
generated into an endless loop. I think regardless of how the test method is
implemented, this loop should always terminate correctly.
#include
#include
#include
#include
template
class bitfield
{
private:
using Element = uint8_t;
static constexpr uint32_t C = (S - 1u) / 8u;
private:
std::array m_Array;
public:
bool test(size_t i) const
{
if (i >= S){
return false;
}
const size_t index = static_cast(i) / 8u;
const Element bitmask = 1u << (i % 8u);
return (m_Array[index] & bitmask) != 0u;
}
};
void bug2(const bitfield<0x120u> )
{
if (!b.test(1u))
{
volatile int test = 1;
}
}
void bug(const bitfield<0x250u> )
{
for (uint16_t i = 0u; i < 0x250u; i++)
{
// this loop seems to not properly terminate
if (!b.test(i))
{
volatile int test = i;
}
}
}
int main()
{
bitfield<0x250u> b;
bug(b);
return 0;
}
Looking at the generated assembler code (in this example ARM64 generated in
godbolt.org, the same issue is also present on my x86-64 machine) we can see,
that the check for i < 0x250 is completely lost. Actually, at .L9 we do the
increment of the loop variable and then unconditionally jump back to .L10 for
the next iteration.
bug(bitfield<592ul> const&):
sub sp, sp, #16
mov w2, 0
mov w4, 1
.L10:
lsr w3, w2, 3
and w1, w2, 7
lsl w1, w4, w1
ldrbw3, [x0, w3, uxtw]
and w1, w1, w3
tst w1, 255
bne .L9
str w2, [sp, 12]
.L9:
add w2, w2, 1
b .L10
During testing of different variants of the code I encountered that there seem
to be different (but totally unexpected) ways to solve the issue:
- adding -fno-tree-vrp or -fno-guess-branch-probability
- deleting method bug2
- changing the type of i to size_t
[Bug tree-optimization/113664] False positive warnings with -fno-strict-overflow (-Warray-bounds, -Wstringop-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664 --- Comment #3 from Andrew Pinski --- https://github.com/python/cpython/issues/96821 is the issue to re-enable strict-overflow ...
[Bug tree-optimization/113664] False positive warnings with -fno-strict-overflow (-Warray-bounds, -Wstringop-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664 --- Comment #2 from Stefan Krah --- Thanks for the explanation! I agree that one should not rely on -fno-strict-overflow. In this case, my project is "vendored" in CPython and they compile everything with -fno-strict-overflow, so it's out of my control: https://github.com/python/cpython/issues/108562 mpdecimal itself does not need -fno-strict-overflow.
[Bug c++/113638] [13/14 Regression] Array bounds of variable templates are not correctly deduced from initializers since GCC13 inside a decltype/sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113638 --- Comment #6 from Patrick Palka --- Indeed, looks like we implement CWG408 since r158075.
[Bug tree-optimization/113664] False positive warnings with -fno-strict-overflow (-Warray-bounds, -Wstringop-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664
--- Comment #1 from Andrew Pinski ---
-fno-strict-overflow turns on -fwrapv-pointer which allows pointers to wrap
which means if s was non-null, then `s+1` can be still a null pointer ...
And then we go and prop null into dot and s is equal to null at that point. and
then we still generate the code for `*s++ = '.';` in
```
if (s == dot) {
*s++ = '.';
}
```
But it is `*NULL = '.';` due to that.
The warning is very sensitive to the ability to optimization away null pointer
checks in this case. Really `fno-strict-overflow` is normally to workaround
some "undefinedness" in the code and the code should be improved to be fixed.
Using -fwrapv instead also helps because now only signed integer overflows and
not also pointers ...
[Bug c/113664] New: False positive warnings with -fno-strict-overflow (-Warray-bounds, -Wstringop-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664
Bug ID: 113664
Summary: False positive warnings with -fno-strict-overflow
(-Warray-bounds, -Wstringop-overflow)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan at bytereef dot org
Target Milestone: ---
These false positives only occur in combination with fno-strict-overflow:
-Warray-bounds
foo.c
=
#include
static char *
f(char *s, int n, char *dot)
{
switch(n) {
case 1:
if (s == dot) {
*s++ = '.';
}
*s++ = '0'; /* fall-through (yes, really!) */
default:
if (s == dot) {
*s++ = '.';
}
}
*s = '\0';
return s;
}
char *
g(char *s)
{
return f(s, 1, NULL);
}
=
$ /home/skrah/gcc/bin/gcc -Wall -O3 -c foo.c
$ /home/skrah/gcc/bin/gcc -Wall -O3 -fno-strict-overflow -c foo.c
In function ‘f’,
inlined from ‘g’ at foo.c:25:10:
foo.c:11:10: warning: array subscript 0 is outside array bounds of ‘char[0]’
[-Warray-bounds=]
11 | *s++ = '0'; /* fall-through (yes, really!) */
| ~^
In function ‘g’:
cc1: note: source object is likely at address zero
=
-Wstringop-overflow
=
bar.c
=
#include
static char *
f(char *s, int n, char *dot)
{
switch(n) {
case 1:
if (s == dot) {
*s++ = '.';
}
*s++ = '0'; /* fall-through (yes, really!) */
default:
if (s == dot) {
*s++ = '.';
}
}
*s = '\0';
return s;
}
char *
g(char *s)
{
char sign = '+';
*s++ = sign;
return f(s, 1, NULL);
}
=
$ /home/skrah/gcc/bin/gcc -Wall -O3 -c bar.c
$ /home/skrah/gcc/bin/gcc -Wall -O3 -fno-strict-overflow -c bar.c
In function ‘f’,
inlined from ‘g’ at bar.c:28:12:
bar.c:11:10: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
11 | *s++ = '0'; /* fall-through (yes, really!) */
| ~^
In function ‘g’:
cc1: note: destination object is likely at address zero
Note that a very small change gives a very different warning.
[Bug c++/113638] [13/14 Regression] Array bounds of variable templates are not correctly deduced from initializers since GCC13 inside a decltype/sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113638
--- Comment #5 from Andrew Pinski ---
(In reply to Patrick Palka from comment #4)
> This seems to be the variable template version of
> https://cplusplus.github.io/CWG/issues/408.html, the resolution of which
> predated variable templates.
Note this works though (which I thought would be able the same, this is another
workaround):
```
template
struct X
{
static int s[];
};
template
int X::s[]={Is...};
static_assert(sizeof(X<1>::s) == sizeof(int) * 1, "");
```
[Bug c++/113658] GCC 14 has incomplete impl for declared feature "cxx_constexpr_string_builtins"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
--- Comment #4 from Daniel Berrange ---
(In reply to Jakub Jelinek from comment #3)
> Obviously using __has_builtin is much better than using the really badly
> designed __has_feature/__has_extension.
> That said, wcs{chr,cmp,len,ncmp} and wmem{chr,cmp} aren't builtins in gcc
> either, so I guess we shouldn't announce this "feature".
Yes, I'll change the code I found to use __has_builtin instead, so it'll work
with new & old GCC & CLang.
[Bug c++/113638] [13/14 Regression] Array bounds of variable templates are not correctly deduced from initializers since GCC13 inside a decltype/sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113638 --- Comment #4 from Patrick Palka --- This seems to be the variable template version of https://cplusplus.github.io/CWG/issues/408.html, the resolution of which predated variable templates.
[Bug c++/113658] GCC 14 has incomplete impl for declared feature "cxx_constexpr_string_builtins"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
Jakub Jelinek changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Obviously using __has_builtin is much better than using the really badly
designed __has_feature/__has_extension.
That said, wcs{chr,cmp,len,ncmp} and wmem{chr,cmp} aren't builtins in gcc
either, so I guess we shouldn't announce this "feature".
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #5 from Christopher Fore --- I've managed to get the args down to the following as well: gcc -mcpu=7450 -O0 -ftree-coalesce-vars -mvsx -c _kf_to_sd.i -mcpu=7450 seems to be (one of) the root causes along with -ftree-coalesce-vars. -mcpu=powerpc does not fail.
[Bug c/79459] Please add enable_if and diagnose_if attributes (from clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79459 corentinjabot at gmail dot com changed: What|Removed |Added CC||corentinjabot at gmail dot com --- Comment #2 from corentinjabot at gmail dot com --- This could be used to implement SFINAE friendly, warning free operators See https://github.com/llvm/llvm-project/pull/79465 https://godbolt.org/z/1xr9Wx38T
[Bug libstdc++/113386] [C++23] std::pair comparison operators should be transparent, but are not in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/97813] std::filesystem::equivalent returning incorrect results on MinGW due to symlinks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97813 --- Comment #4 from Jonathan Wakely --- For example, filesystem::is_symlink doesn't work on Windows, and create_symlink, and create_directory_symlink etc. etc. So we could make equivalent work, but that's just a small part of what's missing.
[Bug libstdc++/97813] std::filesystem::equivalent returning incorrect results on MinGW due to symlinks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97813 --- Comment #3 from Jonathan Wakely --- Nobody has even tried to implement symlink support, so I have no idea if there are any blocking issues. It's probably just a case of somebody doing the work.
[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607 --- Comment #18 from Robin Dapp --- Hehe no it doesn't make sense... I wrongly read a v2 as a v1. Please disregard the last message.
[Bug sanitizer/97696] ICE since ASAN_MARK does not handle poly_int sized varibales
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696 Rama Malladi changed: What|Removed |Added CC||rvmallad at amazon dot com --- Comment #2 from Rama Malladi --- Hi, Can this be actioned/ fixed? We had a related issue and would like this fixed. https://github.com/numpy/numpy/issues/25556 Thank you. Rama
[Bug debug/113394] ICE: 'verify_type' failed: type variant with 'TYPE_ALIAS_SET_KNOWN_P' with -fstrub=internal -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113394 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Last reconfirmed||2024-01-29 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Alexandre Oliva --- Mine
[Bug libstdc++/113663] [MinGW] std::filesystem::hard_link_count always returns 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663 --- Comment #1 from Lennox Ho --- Created attachment 57256 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57256=edit repro.cpp Added minimal repro
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #24 from Tamar Christina --- Just to avoid confusion, are you still working on this one Richi?
[Bug libstdc++/113663] New: [MinGW] std::filesystem::hard_link_count always returns 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663 Bug ID: 113663 Summary: [MinGW] std::filesystem::hard_link_count always returns 1 Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lennoxhoe at gmail dot com Target Milestone: --- Hello! std::filesystem::hard_link_count() appears to always return 1 when built with gcc-13.2.0 + mingw-w64ucrt-11.0.1-r3 on Windows 10 19045 Stepping through with a debugger, it looks like hard_link_count() queries Windows' _wstat64() for this information. The MSFT documentation claims this is the expected behaviour for non-NTFS volumes https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/14h5k7ff(v=vs.120) However, in my tests both the links are located on the same NTFS volume. Furthermore, GetFileInformationByHandle does return the correct result of 2. There appears to be some precedence in calling GetFileInformationByHandle as seen in std::filesystem::equivalent. Can hard_link_count() receive the same treatment? Thanks
[Bug tree-optimization/113467] [14 regression] libgcrypt-1.10.3 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-29 Ever confirmed|0 |1 --- Comment #27 from Tamar Christina --- So this loop shouldn't have been vectorized. It is indeed a dup of the same problem as in PR113588. The issue is that this loop contains a memory access to an unknown sized array in the BB containing the loop CFG latch. My initial patch here analyzed all loads but during review we thought that was too restrictive, that we only need to analyze the loads in blocks which contain an early exit and the loads reachable from the COND in the destination block. The reasoning was that if you were to pass all the early exits the loads in the final block would only be reached if you didn't take the exit. This is then the same as normal vectorization and the loads are safe to issue after the bounds check. What it doesn't take into account is that if you pick a different exit the latch then shifts as we discussed before. The reason Richi's change worked before is that it forced the loop back upright which then made the analysis correctly block it. The bug is a sneaky one, but essentially vect_analyze_data_ref_dependence needs to also keep in mind which exit is the main exit as determined by vec_init_loop_exit_info. In other words, it needs to use the vectorizer's chosen exit and not the loop infrastructure. Mine.
[Bug fortran/113338] [F2018] Valid Code Rejected, bind(C) procedure with pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113338 --- Comment #3 from anlauf at gcc dot gnu.org --- I just tried the example in comment#0 with ifort/ifx and noticed that it may be over-simplified: the contained procedure is internal and thus not visible to the external C code. The BIND attribute does not change that.
[Bug tree-optimization/113662] [13/14 Regression] Wrong code for std::sort with fancy pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662 --- Comment #3 from Andrew Pinski --- Add -fno-ivopts also fixes the issue ...
[Bug tree-optimization/113662] [13/14 Regression] Wrong code for std::sort with fancy pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662 --- Comment #2 from Viktor Ostashevskyi --- Adding --param=ranger-recompute-depth=1 or --param=ranger-recompute-depth=2 also fixes the issue. Higher values behave wrongly.
[Bug tree-optimization/113662] [13/14 Regression] Wrong code for std::sort with fancy pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.3 Component|c++ |tree-optimization
[Bug c++/113662] [13/14 Regression] Wrong code for std::sort with fancy pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Andrew Pinski --- One thing I noticed is both -fwrapv and -fno-strict-aliasing does not change the code generation.
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #4 from Christopher Fore --- Created attachment 57255 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57255=edit minimized preprocessed file Here's the minimized file (still errors)
[Bug c++/113544] [14 Regression] bogus incomplete type error with dependent data member in local class in generic lambda since r14-278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113544 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #3 from Jason Merrill --- Fixed.
[Bug libstdc++/97813] std::filesystem::equivalent returning incorrect results on MinGW due to symlinks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97813 Lennox Ho changed: What|Removed |Added CC||lennoxhoe at gmail dot com --- Comment #2 from Lennox Ho --- > We don't currently support symlinks on Windows. > There's a lot more than just equivalent that needs to change to support them. Hi Jonathan, can you elaborate on this? Is this a simple matter of nobody has bothered to implement this, or are there blocking issues?
[Bug c++/113544] [14 Regression] bogus incomplete type error with dependent data member in local class in generic lambda since r14-278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113544 --- Comment #2 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:77d3fb39c62558838c0e905df717903b5393dfc9 commit r14-8502-g77d3fb39c62558838c0e905df717903b5393dfc9 Author: Jason Merrill Date: Fri Jan 26 17:33:51 2024 -0500 c++: local class in generic lambda [PR113544] My earlier commit r14-278-gd60cbbfaa9a3ad was a start toward better handling of local classes in generic lambdas, but isn't actually useful by itself and breaks this testcase, so let's revert it for now. PR c++/113544 gcc/cp/ChangeLog: * pt.cc (instantiate_class_template): Don't partially instantiate. (tsubst_stmt): Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-nested3.C: New test.
[Bug c++/113662] New: [13/14 Regression] Wrong code for std::sort with fancy pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113662
Bug ID: 113662
Summary: [13/14 Regression] Wrong code for std::sort with fancy
pointer
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Hello,
For the following snippet compiled with "-O3 -std=c++20"
---
#include
#include
#include
#include
struct Foo
{
public:
uint32_t m1;
uint32_t m2;
uint8_t m3;
};
bool operator<(const Foo& lhs, const Foo& rhs)
{
return lhs.m1 < rhs.m1;
}
template
class MyAllocator
{
public:
using value_type = T;
using pointer = boost::interprocess::offset_ptr;
boost::interprocess::offset_ptr allocate( std::size_t n ) {
return boost::interprocess::offset_ptr(a.allocate(n));
}
void deallocate( boost::interprocess::offset_ptr p, std::size_t n ) {
a.deallocate(p.get(), n);
}
std::allocator a;
};
int main()
{
boost::container::vector> vec;
vec.emplace_back().m1 = 4748;
vec.emplace_back().m1 = 4687;
vec.emplace_back().m1 = 4717;
vec.emplace_back().m1 = 4779;
std::cout << "before: " << vec.size() << '\n';
for (const auto& x : vec)
std::cout << std::to_string(x.m1) << '\n';
std::sort(vec.begin(), vec.end());
std::cout << "after: " << vec.size() << '\n';
for (const auto& x : vec)
std::cout << std::to_string(x.m1) << '\n';
}
---
we receive the following output:
---
before: 4
4748
4687
4717
4779
after: 4
4687
4717
4717
4779
---
I've managed to bisect this issue to the following commit:
429a7a88438cc80e7c58d9f63d44838089899b12 is the first bad commit
commit 429a7a88438cc80e7c58d9f63d44838089899b12
Author: Andrew MacLeod
Date: Tue Mar 28 12:16:34 2023 -0400
Add recursive GORI recompuations with a depth limit.
PR tree-optimization/109154
gcc/
* gimple-range-gori.cc (gori_compute::may_recompute_p): Add depth
limit.
* gimple-range-gori.h (may_recompute_p): Add depth param.
* params.opt (ranger-recompute-depth): New param.
gcc/testsuite/
* gcc.dg/Walloca-13.c: Remove bogus warning that is now fixed.
gcc/gimple-range-gori.cc | 30 ++
gcc/gimple-range-gori.h | 4 ++--
gcc/params.opt| 5 +
gcc/testsuite/gcc.dg/Walloca-13.c | 2 +-
4 files changed, 30 insertions(+), 11 deletions(-)
I tried different versions of Boost to ensure that the problem is not coming
from offset_ptr. It looks like that it is possible to reproduce issue with "-O2
-ftree-partial-pre".
Everything works fine with std::vector or std::allocator.
I'd be glad to perform other tests if needed.
[Bug tree-optimization/113588] [14 Regression] The vectorizer is introducing out-of-bounds memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113588 Tamar Christina changed: What|Removed |Added CC||acoplan at gcc dot gnu.org --- Comment #5 from Tamar Christina --- *** Bug 113661 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/113661] [14 Regression] xalancbmk miscompiled on aarch64 since r14-7194-g6cb155a6cf3142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661 --- Comment #3 from Tamar Christina --- arg wrong one again. anyway, this is a duplicate *** This bug has been marked as a duplicate of bug 113588 ***
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 Tamar Christina changed: What|Removed |Added CC||acoplan at gcc dot gnu.org --- Comment #23 from Tamar Christina --- *** Bug 113661 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/113661] [14 Regression] xalancbmk miscompiled on aarch64 since r14-7194-g6cb155a6cf3142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661 --- Comment #2 from Tamar Christina --- *** This bug has been marked as a duplicate of bug 113576 ***
[Bug sanitizer/112644] [14 Regression] Some of the hwasan testcase fail after the recent merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112644 Tamar Christina changed: What|Removed |Added CC||acoplan at gcc dot gnu.org --- Comment #8 from Tamar Christina --- *** Bug 113661 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/113661] [14 Regression] xalancbmk miscompiled on aarch64 since r14-7194-g6cb155a6cf3142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Tamar Christina --- duplicate *** This bug has been marked as a duplicate of bug 112644 ***
[Bug tree-optimization/113661] New: [14 Regression] xalancbmk miscompiled on aarch64 since r14-7194-g6cb155a6cf3142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661 Bug ID: 113661 Summary: [14 Regression] xalancbmk miscompiled on aarch64 since r14-7194-g6cb155a6cf3142 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: acoplan at gcc dot gnu.org Target Milestone: --- xalancbmk (both from SPEC 2006 and SPEC 2017) seems to be miscompiled on aarch64 since r14-7194-g6cb155a6cf314232248a12bdd395ed4151ae5a28 i.e. commit 6cb155a6cf314232248a12bdd395ed4151ae5a28 (refs/bisect/bad) Author: Tamar Christina Date: Fri Jan 12 15:24:49 2024 + middle-end: make memory analysis for early break more deterministic [PR113135] I see: *** Miscompare of ref-t5.out with the options -Ofast -fomit-frame-pointer -mcpu=neoverse-v1 -flto=auto .
[Bug rtl-optimization/113660] New: ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fnon-call-exceptions -fharden-control-flow-redundancy on invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113660
Bug ID: 113660
Summary: ICE: verify_flow_info failed: missing REG_EH_REGION
note at the end of bb 2 with -fnon-call-exceptions
-fharden-control-flow-redundancy on invalid
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 57254
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57254=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -fnon-call-exceptions
-fharden-control-flow-redundancy testcase.c
testcase.c: In function 'foo':
testcase.c:5:3: error: impossible constraint in 'asm'
5 | __asm__ volatile("" : "=a"(i));
| ^~~
testcase.c:6:1: error: missing REG_EH_REGION note at the end of bb 2
6 | }
| ^
during RTL pass: into_cfglayout
testcase.c:6:1: internal compiler error: verify_flow_info failed
0xf904ae verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.cc:287
0x268381b checking_verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.h:214
0x268381b try_optimize_cfg
/repo/gcc-trunk/gcc/cfgcleanup.cc:2980
0x268381b cleanup_cfg(int)
/repo/gcc-trunk/gcc/cfgcleanup.cc:3143
0xfaaf8a execute
/repo/gcc-trunk/gcc/cfgrtl.cc:3713
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8487-20240129102032-gb338fdbc2b7-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8487-20240129102032-gb338fdbc2b7-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240129 (experimental) (GCC)
[Bug c/113653] Failure to diagnose use of (non-constant-expr) const objects in static initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653 --- Comment #6 from Rich Felker --- I'm aware of the allowance to accept "other forms". It's unfortunately underspecified (does the implementation need to be specific in what forms? document them per the normal rules for implementation-defined behavior? etc.) but indeed it exists. Regardless, at least -pedantic should diagnose this, because it's a big footgun for writing code that is not valid C, that only works with certain compilers that implement C++-like behavior in C. I would also be happy with a separate warning option controlling it, named something like like -Wextended-constant-expressions.
[Bug target/111677] [12/13 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #21 from Richard Sandiford ---
(In reply to Alex Coplan from comment #13)
> The problem seems to be this code in aarch64_process_components:
>
> while (regno != last_regno)
> {
> bool frame_related_p = aarch64_emit_cfi_for_reg_p (regno);
> machine_mode mode = aarch64_reg_save_mode (regno);
>
> rtx reg = gen_rtx_REG (mode, regno);
> poly_int64 offset = frame.reg_offset[regno];
> if (frame_pointer_needed)
> offset -= frame.bytes_below_hard_fp;
>
> rtx addr = plus_constant (Pmode, ptr_reg, offset);
> rtx mem = gen_frame_mem (mode, addr);
>
> which emits a TFmode mem with offset 512, which is out of range for TFmode
> (so we later ICE with an unrecognisable insn). Presumably this just needs
> tweaking to emit a new base anchor in the case of large offsets like this.
> It looks like the code in aarch64_save_callee_saves already does this.
We shouldn't emit new anchor registers here, since unlike in the prologue,
we don't have any guarantee that certain registers are free.
aarch64_get_separate_components is supposed to vet shrink-wrappable
offsets, but in this case the offset looks valid, since:
str q22, [sp, #512]
is a valid instruction. Perhaps the constraints are too narrow?
[Bug tree-optimization/113659] New: [14 Regression] ICE Segmentation fault since r14-8355-g02e683894942da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659
Bug ID: 113659
Summary: [14 Regression] ICE Segmentation fault since
r14-8355-g02e683894942da
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mjires at suse dot cz
CC: rguenther at suse dot de
Target Milestone: ---
Compiling reduced testcase g++.dg/torture/predcom-1.C results in ICE since
r14-8355-g02e683894942da. Reintroduced PR113442.
$ cat predcom-1.C
struct Foo {
int *ptr;
};
bool Baz(Foo first) {
while (first.ptr)
if (*first.ptr++)
return false;
}
$ g++ predcom-1.C -O3 -fno-tree-sra -mavx512bf16
predcom-1.C: In function ‘bool Baz(Foo)’:
predcom-1.C:8:1: warning: control reaches end of non-void function
[-Wreturn-type]
8 | }
| ^
during GIMPLE pass: vect
predcom-1.C:4:6: internal compiler error: Segmentation fault
4 | bool Baz(Foo first) {
| ^~~
0x1b06530 crash_signal
/home/mjires/git/GCC/master/gcc/toplev.cc:317
0x13c5e6a gimple_phi_result(gphi const*)
/home/mjires/git/GCC/master/gcc/gimple.h:4608
0x1e6a0a4 slpeel_tree_duplicate_loop_to_edge_cfg(loop*, edge_def*, loop*,
edge_def*, edge_def*, edge_def**, bool, vec*)
/home/mjires/git/GCC/master/gcc/tree-vect-loop-manip.cc:1713
0x1e6f49e vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool, tree_node**)
/home/mjires/git/GCC/master/gcc/tree-vect-loop-manip.cc:3395
0x1e597a8 vect_transform_loop(_loop_vec_info*, gimple*)
/home/mjires/git/GCC/master/gcc/tree-vect-loop.cc:11914
0x1eb23de vect_transform_loops
/home/mjires/git/GCC/master/gcc/tree-vectorizer.cc:1006
0x1eb2b3e try_vectorize_loop_1
/home/mjires/git/GCC/master/gcc/tree-vectorizer.cc:1152
0x1eb2c77 try_vectorize_loop
/home/mjires/git/GCC/master/gcc/tree-vectorizer.cc:1182
0x1eb2f3e execute
/home/mjires/git/GCC/master/gcc/tree-vectorizer.cc:1298
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --disable-bootstrap
--enable-languages=c,c++,fortran,lto --disable-multilib --disable-libsanitizer
--enable-checking : (reconfigured) /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --disable-bootstrap
--enable-languages=c,c++,fortran,lto --disable-multilib --disable-libsanitizer
--enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240129 (experimental) (GCC)
[Bug c/113653] Failure to diagnose use of (non-constant-expr) const objects in static initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Specifically https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960#c24 . See that comment. It explains on why this is not exactly invalid code.
[Bug c++/113658] GCC 14 has incomplete impl for declared feature "cxx_constexpr_string_builtins"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658 --- Comment #2 from Andrew Pinski --- Newer libc++ does the "correct" thing even: https://github.com/llvm/llvm-project/blob/430c1fd50d774dc30a9628bcf60ce243f74ff376/libcxx/include/__string/constexpr_c_functions.h#L121
[Bug c/113653] Failure to diagnose use of (non-constant-expr) const objects in static initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653 Rich Felker changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #4 from Rich Felker --- This is NOT a duplicate of the marked bug - that bug was complaining that invalid code didn't compile. This bug is that GCC accepts invalid code, even with -pedantic, with no diagnostic, making it impossible to catch invalid C. This bug bit me in the wild - I accepted code that should have been rejected as a constraint violation, and thereby made the project impossible to compile with other compilers for a couple releases. In standards-conforming and/or pedantic mode, the code should be rejected.
[Bug c++/113658] GCC 14 has incomplete impl for declared feature "cxx_constexpr_string_builtins"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658 --- Comment #1 from Andrew Pinski --- Hmm, Most other conditional uses of builtin use __has_builtins instead. Interesting one projection just conditionalized it on cxx_constexpr_string_builtins .
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 --- Comment #3 from Erhard F. --- (In reply to Christopher Fore from comment #0) > Created attachment 57251 [details] > original preprocessed file > > Steps to reproduce: > 1. Attempt to build GCC 14 (latest snapshot attempted is Gentoo's 20240128) > 2. Fails to assemble with: > /tmp/ccP8ev2f.s: Assembler messages: > /tmp/ccP8ev2f.s:85: Error: unrecognized opcode: `lfiwzx' > > Originally reported downstream at: https://bugs.gentoo.org/921621 > > Command to reproduce: > gcc -mcpu=7450 -O1 -mvsx -c _kf_to_sd.i I did the Gentoo downstream bugreport where I tried to build GCC 14 with GCC 11 + binutils 2.41. Building was done on a 32 bit partition on my Talos II via 'setarch ppc32 emerge -1 gcc'. As the PowerPC 7450 (aka PowerPC G4) is only capable of -maltivec but not -mvsx I only passed "-O2 -mcpu=7450 -mtune=7450" as CFLAGS. Still my GCC 14 build spills this "unrecognized opcode: `lfiwzx'" which is a Power ISA 2.06 (POWER 7) opcode. GCC 11 builds fine on the same system.
[Bug c++/113658] New: GCC 14 has incomplete impl for declared feature "cxx_constexpr_string_builtins"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
Bug ID: 113658
Summary: GCC 14 has incomplete impl for declared feature
"cxx_constexpr_string_builtins"
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: berrange at redhat dot com
Target Milestone: ---
In GCC 14 there was support for the Clang __has_feature() language extension
added by
commit 06280a906cb3dc80cf5e07cf3335b758848d488d
Author: Alex Coplan
Date: Fri Mar 17 16:30:51 2023 +
c-family: Implement __has_feature and __has_extension [PR60512]
This patch implements clang's __has_feature and __has_extension in GCC.
Currently the patch aims to implement all documented features (and some
undocumented ones) following the documentation at
https://clang.llvm.org/docs/LanguageExtensions.html with the exception
of the legacy features for C++ type traits.
One of the features declared as implemented is "cxx_constexpr_string_builtins"
which was documented by CLang as indicating support for built-ins for memchr,
memcmp, strchr, strcmp, strlen, strncmp, wcschr, wcscmp, wcslen, wcsncmp,
wmemchr, wmemcmp, and one extra special case for memchr.
Except GCC 14 does not provide built-ins for all those functions, so GCC is
claiming support for a feature it cannot fully support.
As a result code that was written against this CLang feature extension now gets
enabled with GCC 14 and then fails to build.
$ cat >> demo.cpp <
#ifndef __has_feature
#warning "no __has_feature"
#define __has_feature(a) 0
#endif
char *foo(const char *s, int c, size_t n) {
#if __has_feature(cxx_constexpr_string_builtins)
return __builtin_char_memchr(s, c, n);
#else
#warning "no __builtin_char_memchr"
return NULL;
#endif
}
EOF
$ g++ b.cpp
b.cpp: In function ‘char* foo(const char*, int, size_t)’:
b.cpp:10:12: error: ‘__builtin_char_memchr’ was not declared in this scope; did
you mean ‘__builtin_memchr’?
10 | return __builtin_char_memchr(s, c, n);
|^
|__builtin_memchr
gcc version 14.0.1 20240125 (Red Hat 14.0.1-0) (GCC)
[Bug c/113653] Failure to diagnose use of (non-constant-expr) const objects in static initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653 --- Comment #3 from Andrew Pinski --- Specifically https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960#c24 .
[Bug c/83222] [8 regression] Inconsistent "initializer element is not constant" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83222 Andrew Pinski changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #6 from Andrew Pinski --- *** Bug 113653 has been marked as a duplicate of this bug. ***
[Bug c/113653] Failure to diagnose use of (non-constant-expr) const objects in static initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113653 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- This was done on purpose, see PR 83222 (and PR 69960). *** This bug has been marked as a duplicate of bug 83222 ***
[Bug target/113655] Cross compiling to mips64-elf fails because "MIPS_EXPLICIT_RELOCS was not declared" after r14-8386-g58af788d1d0825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655 YunQiang Su changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from YunQiang Su --- I think that this problem has been resolved. If no, you can just reopen this report.
[Bug target/113655] Cross compiling to mips64-elf fails because "MIPS_EXPLICIT_RELOCS was not declared" after r14-8386-g58af788d1d0825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655 --- Comment #2 from GCC Commits --- The master branch has been updated by YunQiang Su : https://gcc.gnu.org/g:8e84b4fad149b9b9544c7b1fc61a45cf6139176e commit r14-8500-g8e84b4fad149b9b9544c7b1fc61a45cf6139176e Author: YunQiang Su Date: Tue Jan 30 00:26:28 2024 +0800 MIPS: Fix typo in gcc/configure.ac: gcc_cv_as_mips_explicit gcc_cv_as_mips_explicit should be gcc_cv_as_mips_explicit_relocs. This was introduced in commit 58af788d1d0825187def434c95cab35a690a31b0. gcc PR target/113655 * configure.ac: Fix typo gcc_cv_as_mips_explicit should be gcc_cv_as_mips_explicit_relocs. * configure: Regnerated.
[Bug target/113607] [14] RISC-V rv64gcv vector: Runtime mismatch at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #17 from Robin Dapp ---
Grasping for straws by blaming qemu ;)
At some point we do the vector shift
vsll.vv v1,v2,v2,v0.t
but the mask v0 is all zeros:
gdb:
b = {0 }
According to the mask-undisturbed policy set before
vsetvli zero,zero,e32,mf2,ta,mu
all elements should be unchanged. I'm seeing an all-zeros result in v1,
though.
v1 is used as 'j', is zero and therefore 'q' is not incremented and we don't
assign c = d causing the wrong result.
Before the shift I see v2 in gdb as:
w = {4294967295, 4294967295, 0, 0}
(That's also a bit dubious because we load 2 elements from 'g' of which only
one should be -1. This doesn't change the end result, though.)
After the shift gdb shows v1 as:
w = {0, 0, 0, 0},
when it should be w = {-1, -1, 0, 0}.
Does this make sense?
[Bug target/113655] Cross compiling to mips64-elf fails because "MIPS_EXPLICIT_RELOCS was not declared" after r14-8386-g58af788d1d0825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655 --- Comment #1 from YunQiang Su --- Thank for your report. It's due to a typo I will fix it now.
[Bug target/113657] New: [14 Regression] ICE Segmentation fault since r14-1187-gd6b756447cd58b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113657
Bug ID: 113657
Summary: [14 Regression] ICE Segmentation fault since
r14-1187-gd6b756447cd58b
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mjires at suse dot cz
CC: aoliva at gcc dot gnu.org
Target Milestone: ---
Compiling reduced testcase gcc.target/aarch64/pr113550.c results in ICE since
r14-1187-gd6b756447cd58b.
$ cat pr113550.c
#pragma GCC target "+ls64"
#pragma GCC aarch64 "arm_acle.h"
__arm_data512_t foo(__arm_data512_t* ptr) { return *ptr; }
$ aarch64-linux-gnu-gcc pr113550.c -mstrict-align
during RTL pass: split5
pr113550.c: In function ‘foo’:
pr113550.c:3:58: internal compiler error: Segmentation fault
3 | __arm_data512_t foo(__arm_data512_t* ptr) { return *ptr; }
| ^
0x178f9de crash_signal
/home/mjires/git/GCC/master/gcc/toplev.cc:317
0x16f7566 reg_overlap_mentioned_p(rtx_def const*, rtx_def const*)
/home/mjires/git/GCC/master/gcc/rtlanal.cc:1857
0x267687e gen_split_300(rtx_insn*, rtx_def**)
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-simd.md:8232
0x2a7ffb2 split_71
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-simd.md:8212
0x2a99edf split_131
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64.md:875
0x2a9dcf4 split_insns(rtx_def*, rtx_insn*)
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-sve.md:10993
0x117c8db try_split(rtx_def*, rtx_insn*, int)
/home/mjires/git/GCC/master/gcc/emit-rtl.cc:3941
0x16a3a44 split_insn
/home/mjires/git/GCC/master/gcc/recog.cc:3405
0x16a3ea6 split_all_insns_noflow()
/home/mjires/git/GCC/master/gcc/recog.cc:3567
0x16a5ee4 execute
/home/mjires/git/GCC/master/gcc/recog.cc:4641
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.1/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking : (reconfigured)
/home/mjires/git/GCC/master/configure --prefix=/home/mjires/built/master
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran
--disable-multilib --disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240129 (experimental) (GCC)
[Bug target/108933] [11/12/13 Regression] Missing rev16 detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933 Richard Earnshaw changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |Missing rev16 detection |Missing rev16 detection Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |Matthieu.Longo at arm dot com --- Comment #6 from Richard Earnshaw --- Fixed on trunk so far.
[Bug c++/113638] [13/14 Regression] Array bounds of variable templates are not correctly deduced from initializers since GCC13 inside a decltype/sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113638 Patrick Palka changed: What|Removed |Added Keywords|needs-bisection | CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Started with r13-2540-g4db3cb781c3553. If we remove the constexpr then it seems we never accepted the testcase, so this is only a regression for constexpr variable templates, but a proper fix will likely cover the non-constexpr case too.
[Bug target/108933] [11/12/13/14 Regression] Missing rev16 detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933 --- Comment #5 from GCC Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:bad991a1c5960e90c4686a9362a1258ef29e195b commit r14-8499-gbad991a1c5960e90c4686a9362a1258ef29e195b Author: Matthieu Longo Date: Mon Jan 29 15:54:35 2024 + arm: Add pattern for bswap + rotate -> rev16 [Bug 108933] The rev16 pattern was not recognised anymore as a change in the bswap tree pass was introducing a new GIMPLE form, not recognized by the assembly final transformation pass. Also, fix the output patterns for arm_rev16si_alt[12] to correctly handle the instructions being made conditional. More details in the PR. gcc/ChangeLog: PR target/108933 * config/arm/arm.md (arm_rev16si2): Convert to define_insn. Correct generated RTL. (arm_rev16si2_alt1): Correctly handle conditional execution. (arm_rev16si2_alt2): Likewise. gcc/testsuite/ChangeLog: PR target/108933 * gcc.target/arm/rev16.c: Moved to... * gcc.target/arm/rev16_1.c: ...here. * gcc.target/arm/rev16_2.c: New test to check that rev16 is emitted.
