[Bug testsuite/109549] [14/15 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 --- Comment #21 from Stefan Schulze Frielinghaus --- Fixed for GCC 14 and 15 for s390.
[Bug testsuite/109549] [14/15 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 Stefan Schulze Frielinghaus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Stefan Schulze Frielinghaus --- Changing state to fixed. Feel free to reopen if this has to be fixed for a different target.
[Bug middle-end/85559] [meta-bug] Improve conditional move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85559 Bug 85559 depends on bug 109549, which changed state. Bug 109549 Summary: [14/15 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/115492] [15 Regression] wrong code at -O2/O3 since r15-204-g7c469a9fc78550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115492 --- Comment #6 from Richard Biener --- OK, so the issue is that we are entering ao_ref_init_from_vn_reference with valueized operands and vn_valueize assumes the input is available. It's quite awkward to force availability here because of how PRE is integrated with VN here. I'm going to simply revert the change.
[Bug tree-optimization/115256] [15 Regression] 502.gcc_r Run failed with '-march=native -Ofast -funroll-loops -flto' since r15-571-g1e0ae1f52741f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115256 Hongyu Wang changed: What|Removed |Added CC||hongyuw at gcc dot gnu.org --- Comment #4 from Hongyu Wang --- Part of the dump for create_preheaders before DSE -- [local count: 29277718]: # .MEM_153 = PHI <.MEM_161(4), .MEM_161(3)> # _15 = PHI <_17(4), 0(3)> # _120 = PHI <_19(4), 0(3)> if (_120 == 0) goto ; [45.64%] else goto ; [54.36%] [local count: 27536775]: # _66 = PHI <_15(6), _17(5)> # .MEM_125 = PHI <.MEM_153(6), .MEM_164(5)> _87 = (long unsigned int) _66; _88 = _87 * 4; _89 = _88 + 8; _110 = _89; # .MEM_167 = VDEF <.MEM_125> newmem_111 = malloc (_110); if (newmem_111 == 0B) goto ; [0.04%] else goto ; [99.96%] [local count: 11015]: # .MEM_168 = VDEF <.MEM_167> xmalloc_failed (_110); [local count: 27536775]: # .MEM_154 = PHI <.MEM_167(7), .MEM_168(8)> # .MEM_170 = VDEF <.MEM_154> MEM[(struct vec_prefix *)newmem_111].alloc = _66; # .MEM_171 = VDEF <.MEM_170> MEM[(struct vec_prefix *)newmem_111].num = 0; [local count: 39298950]: # _91 = PHI <0B(6), newmem_111(9)> # .MEM_152 = PHI <.MEM_153(6), .MEM_171(9)> # .MEM_174 = VDEF <.MEM_152> li.to_visit = _91; # VUSE <.MEM_174> _61 = cfun; # VUSE <.MEM_174> _62 = _61->x_current_loops; # VUSE <.MEM_174> _63 = _62->tree_root; [local count: 77159561]: # aloop_80 = PHI <_63(10), _108(26)> # .MEM_147 = PHI <.MEM_174(10), .MEM_90(26)> [local count: 701450557]: # aloop_64 = PHI # .MEM_148 = PHI <.MEM_147(11), .MEM_149(16)> # VUSE <.MEM_148> _65 = aloop_64->num; if (_65 > 0) goto ; [50.00%] else goto ; [50.00%] [local count: 350725279]: if (_91 != 0B) goto ; [70.00%] else goto ; [30.00%] [local count: 245507696]: _67 = &MEM[(struct VEC_int_heap *)_91].base; [local count: 350725279]: # _68 = PHI <0B(13), _67(14)> # VUSE <.MEM_148> _69 = _68->num; _70 = _69 + 1; # .MEM_179 = VDEF <.MEM_148> _68->num = _70; # .MEM_180 = VDEF <.MEM_179> MEM [(int *)_68].vec[_69] = _65; -- The problem is, for the malloced stores, MEM[(struct vec_prefix *)newmem_111].alloc = _66; MEM[(struct vec_prefix *)newmem_111].num = 0; These 2 stmts are marked as dead store and eliminated, but actually there was a use chain -- [local count: 39298950]: # _91 = PHI <0B(6), newmem_111(9)> # .MEM_152 = PHI <.MEM_153(6), .MEM_171(9)> # .MEM_174 = VDEF <.MEM_152> li.to_visit = _91; ... [local count: 350725279]: if (_91 != 0B) goto ; [70.00%] else goto ; [30.00%] [local count: 245507696]: _67 = &MEM[(struct VEC_int_heap *)_91].base; [local count: 350725279]: # _68 = PHI <0B(13), _67(14)> # VUSE <.MEM_148> _69 = _68->num; _70 = _69 + 1; # .MEM_179 = VDEF <.MEM_148> _68->num = _70; # .MEM_180 = VDEF <.MEM_179> MEM [(int *)_68].vec[_69] = _65; -- The source code ha
[Bug fortran/103112] ICE in gfc_get_descriptor_field for gfortran.dg/coarray_alloc_comp_4.f08 caf single since r7-5771-gde91486c745d5ff6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103112 --- Comment #4 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:db75a6657e9de6ee7effe46cd2626d9bb946f2e6 commit r15-1369-gdb75a6657e9de6ee7effe46cd2626d9bb946f2e6 Author: Andre Vehreschild Date: Tue Jun 11 15:24:55 2024 +0200 Fix ICE when compiling with -fcoarray=single, when derefing a non-array. PR fortran/96418 PR fortran/103112 gcc/fortran/ChangeLog: * trans.cc (gfc_deallocate_with_status): Check that object to deref is an array, before applying array deref. gcc/testsuite/ChangeLog: * gfortran.dg/coarray_alloc_comp_3.f08: Moved to... * gfortran.dg/coarray/alloc_comp_8.f90: ...here. Should be tested for both -fcoarray=single and lib, resp. * gfortran.dg/coarray_alloc_comp_4.f08: Fix program name.
[Bug fortran/96418] Test coarray_alloc_comp_4.f08 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96418 --- Comment #10 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:db75a6657e9de6ee7effe46cd2626d9bb946f2e6 commit r15-1369-gdb75a6657e9de6ee7effe46cd2626d9bb946f2e6 Author: Andre Vehreschild Date: Tue Jun 11 15:24:55 2024 +0200 Fix ICE when compiling with -fcoarray=single, when derefing a non-array. PR fortran/96418 PR fortran/103112 gcc/fortran/ChangeLog: * trans.cc (gfc_deallocate_with_status): Check that object to deref is an array, before applying array deref. gcc/testsuite/ChangeLog: * gfortran.dg/coarray_alloc_comp_3.f08: Moved to... * gfortran.dg/coarray/alloc_comp_8.f90: ...here. Should be tested for both -fcoarray=single and lib, resp. * gfortran.dg/coarray_alloc_comp_4.f08: Fix program name.
[Bug fortran/96418] Test coarray_alloc_comp_4.f08 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96418 Andre Vehreschild changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug target/115517] New: Fix regression after dropping uses of vcond{,u,eq}_optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115517
Bug ID: 115517
Summary: Fix regression after dropping uses of
vcond{,u,eq}_optab
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Depends on: 114189
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
> I'd appreciate testing, I do not expect fallout for x86 or arm/aarch64.
> > I know riscv doesn't implement any of the legacy optabs. But less
> > maintained vector targets might need adjustments.
> >
> At GCC14, I tried to remove these expanders in the x86 backend, and it
> regressed some testcases, mainly because of the optimizations we did
> in ix86_expand_{int,fp}_vcond.
> I've started testing your patch, it's possible that we still need to
> move the ix86_expand_{int,fp}_vcond optimizations to the
> middle-end(isel or match.pd)or add extra patterns to handle it at the
> rtl pas_combine.
These are new failures I got
g++: g++.target/i386/avx-pr54700-1.C scan-assembler-not vpcmpgt[bdq]
g++: g++.target/i386/avx-pr54700-1.C scan-assembler-times vblendvpd 4
g++: g++.target/i386/avx-pr54700-1.C scan-assembler-times vblendvps 4
g++: g++.target/i386/avx-pr54700-1.C scan-assembler-times vpblendvb 2
g++: g++.target/i386/avx2-pr54700-1.C scan-assembler-not vpcmpgt[bdq]
g++: g++.target/i386/avx2-pr54700-1.C scan-assembler-times vblendvpd 4
g++: g++.target/i386/avx2-pr54700-1.C scan-assembler-times vblendvps 4
g++: g++.target/i386/avx2-pr54700-1.C scan-assembler-times vpblendvb 2
g++: g++.target/i386/avx512fp16-vcondmn-minmax.C -std=gnu++14
g++scan-assembler-times vmaxph 3
g++: g++.target/i386/avx512fp16-vcondmn-minmax.C -std=gnu++14
g++scan-assembler-times vminph 3
g++: g++.target/i386/avx512fp16-vcondmn-minmax.C -std=gnu++17
g++scan-assembler-times vmaxph 3
g++: g++.target/i386/avx512fp16-vcondmn-minmax.C -std=gnu++17
g++scan-assembler-times vminph 3
g++: g++.target/i386/avx512fp16-vcondmn-minmax.C -std=gnu++20
g++scan-assembler-times vmaxph 3
g++: g++.target/i386/avx512fp16-vcondmn-minmax.C -std=gnu++20
g++scan-assembler-times vminph 3
g++: g++.target/i386/avx512fp16-vcondmn-minmax.C -std=gnu++98
g++scan-assembler-times vmaxph 3
g++: g++.target/i386/avx512fp16-vcondmn-minmax.C -std=gnu++98
g++scan-assembler-times vminph 3
g++: g++.target/i386/pr100637-1b.C -std=gnu++14 scan-assembler-times
g++pcmpeqb 2
g++: g++.target/i386/pr100637-1b.C -std=gnu++17 scan-assembler-times
g++pcmpeqb 2
g++: g++.target/i386/pr100637-1b.C -std=gnu++20 scan-assembler-times
g++pcmpeqb 2
g++: g++.target/i386/pr100637-1b.C -std=gnu++98 scan-assembler-times
g++pcmpeqb 2
g++: g++.target/i386/pr100637-1w.C -std=gnu++14 scan-assembler-times
g++pcmpeqw 2
g++: g++.target/i386/pr100637-1w.C -std=gnu++17 scan-assembler-times
g++pcmpeqw 2
g++: g++.target/i386/pr100637-1w.C -std=gnu++20 scan-assembler-times
g++pcmpeqw 2
g++: g++.target/i386/pr100637-1w.C -std=gnu++98 scan-assembler-times
g++pcmpeqw 2
g++: g++.target/i386/pr100738-1.C -std=gnu++14 scan-assembler-not
g++vpcmpeqd[ \\t]
g++: g++.target/i386/pr100738-1.C -std=gnu++14 scan-assembler-not
g++vpxor[ \\t]
g++: g++.target/i386/pr100738-1.C -std=gnu++14 scan-assembler-times
g++vblendvps[ \\t] 2
g++: g++.target/i386/pr100738-1.C -std=gnu++17 scan-assembler-not
g++vpcmpeqd[ \\t]
g++: g++.target/i386/pr100738-1.C -std=gnu++17 scan-assembler-not
g++vpxor[ \\t]
g++: g++.target/i386/pr100738-1.C -std=gnu++17 scan-assembler-times
g++vblendvps[ \\t] 2
g++: g++.target/i386/pr100738-1.C -std=gnu++20 scan-assembler-not
g++vpcmpeqd[ \\t]
g++: g++.target/i386/pr100738-1.C -std=gnu++20 scan-assembler-not
g++vpxor[ \\t]
g++: g++.target/i386/pr100738-1.C -std=gnu++20 scan-assembler-times
g++vblendvps[ \\t] 2
g++: g++.target/i386/pr100738-1.C -std=gnu++98 scan-assembler-not
g++vpcmpeqd[ \\t]
g++: g++.target/i386/pr100738-1.C -std=gnu++98 scan-assembler-not
g++vpxor[ \\t]
g++: g++.target/i386/pr100738-1.C -std=gnu++98 scan-assembler-times
g++vblendvps[ \\t] 2
g++: g++.target/i386/pr103861-1.C -std=gnu++14 scan-assembler-times
g++pcmpeqb 2
g++: g++.target/i386/pr103861-1.C -std=gnu++17 scan-assembler-times
g++pcmpeqb 2
g++: g++.target/i386/pr103861-1.C -std=gnu++20 scan-assembler-times
g++pcmpeqb 2
g++: g++.target/i386/pr103861-1.C -std=gnu++98 scan-assembler-times
g++pcmpeqb 2
g++: g++.target/i386/pr61747.C -std=gnu++14 scan-assembler-times max 4
g++: g++.target/i386/pr61747.C -std=gnu++14 scan-assembler-times min 4
g++: g++.target/i386/pr61747.C -std=gnu++17 scan-assembler-times max 4
g++: g++.target/i386/pr61747.C -std=gnu++17 scan-assembler-times min 4
g++: g++.target/i386/pr61747.C -std=gnu++20 scan-assembler-times max 4
g++: g++.ta
[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493
--- Comment #5 from Christophe Lyon ---
That's because such a configuration builds libs for A-profile (cortex-A*),
which are incompatible with M-profile (cortex-M*). (In addition I think you
have to use gnueabihf instead of gnueabi, IIRC --with-float=hard is not
sufficient).
You can't build an arm-linux-* toolchain for cortex-M.
So I suggest you build your toolchain with the flags I suggested in the
description:
with GCC configured with:
--disable-multilib --with-mode=thumb --with-arch=armv8.1-m.main+mve.fp+fp.dp
--with-float=hard --target=arm-eabi
It shouldn't be very long since multilibs are disabled.
Alternatively, you can try to use our ABE build script:
git clone https://git.linaro.org/toolchain/abe.git
cd abe
./configure
./abe.sh --build all --target arm-eabi --extraconfigdir config/master --disable
make_docs --set languages=c,c++,lto --set
gcc_override_configure=--disable-multilib --set
gcc_override_configure=--with-mode=thumb --set
gcc_override_configure=--with-arch=armv8.1-m.main+mve.fp+fp.dp --set
gcc_override_configure=--with-float=hard --check gcc --set
'target_board_options={-mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto}'
--qemu-cpu cortex-m55 --set runtestflags=execute.exp=pr94734.c
That will clone all repos (binutils-gdb, gcc, newlib, qemu), build the full
toolchain from scratch, and run the test.
[Bug target/115161] highway-1.0.7 miscompilation of _mm_cvttps_epi32(): invalid result assumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 --- Comment #28 from GCC Commits --- The master branch has been updated by Hu : https://gcc.gnu.org/g:b5d3ad256afdfd891d37d8fdb126d599f150e78b commit r15-1370-gb5d3ad256afdfd891d37d8fdb126d599f150e78b Author: Hu, Lin1 Date: Wed Jun 12 16:25:34 2024 +0800 i386: Refine all cvtt* instructions with UNSPEC instead of FIX/UNSIGNED_FIX. gcc/ChangeLog: PR target/115161 * config/i386/i386-builtin.def: Change CODE_FOR_* for cvtt*'s builtins. * config/i386/sse.md: (unspec_avx512fp16_fix _trunc2): Use UNSPEC instead of FIX/UNSIGNED_FIX. (unspec_avx512fp16_fix_trunc2): Ditto. (unspec_avx512fp16_fix_truncv2di2): Ditto. (unspec_avx512fp16_fix_trunc2): Ditto. (unspec_sse_cvttps2pi): Ditto. (unspec_sse_cvttss2si): Ditto. (unspec_fix_truncv16sfv16si2): Ditto. (unspec_fix_truncv8sfv8si2): Ditto. (unspec_fix_truncv4sfv4si2): Ditto. (unspec_sse2_cvttpd2pi): Ditto. (unspec_fixuns_truncv2dfv2si2): Ditto. (unspec_avx512f_vcvttss2usi): Ditto. (unspec_avx512f_vcvttsd2usi): Ditto. (unspec_sse2_cvttsd2si): Ditto. (unspec_fix_truncv8dfv8si2): Ditto. (*unspec_fixuns_truncv2dfv2si2): Ditto. (unspec_fixuns_truncv2dfv2si2_mask): Ditto. (unspec_fix_truncv4dfv4si2): Ditto. (unspec_fixuns_truncv4dfv4si2): Ditto. (unspec_fix _trunc2): Ditto. (unspec_fix _trunc2): Ditto. (unspec_avx512dq_fix_truncv2sfv2di2): Ditto. (unspec_fixuns_trunc2): Ditto. (unspec_sse2_cvttpd2dq): Ditto. gcc/testsuite/ChangeLog: PR target/115161 * gcc.target/i386/pr115161-1.c: New test.
[Bug tree-optimization/115494] [14/15 Regression] wrong code at -O{2,3} on x86_64-linux-gnu since r14-3485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494
--- Comment #8 from Richard Biener ---
ANTIC_IN[6] := { _5 (0005), _16 (0014), {bit_not_expr,_16} (0016),
{bit_ior_expr,_5,_19} (0017) }
ANTIC_IN[8] := { _5 (0005), _16 (0014), {bit_not_expr,_16} (0016),
{bit_ior_expr,_5,_17} (0017) }
ANTIC_IN[11] := { _5 (0005), _16 (0014), {bit_not_expr,_16} (0016),
{bit_ior_expr,_5,_24} (0017) }
merge 8 + 11:
ANTIC_IN[7] := { b.0_1 (0001), _5 (0005), _16 (0014), {bit_not_expr,_16}
(0016), {bit_ior_expr,_5,_17} (0017), {bit_ior_expr,_5,_24} (0017) }
merge 7 + 6:
ANTIC_IN[5] := { b.0_1 (0001), iftmp.2_9 (0008), {nop_expr,iftmp.2_9} (0005),
{bit_not_expr,_5} (0006), {nop_expr,b.0_1} (0014), {bit_not_expr,_16} (0016),
{bit_ior_expr,_5,_19} (0017), {bit_ior_expr,_5,_17} (0017),
{bit_ior_expr,_5,_24} (0017)
that's all OK. Note all exprs have the same value (0017) here. Then
we PHI-translate to where _5 == 0:
ANTIC_IN[14] := { b.0_1 (0001), {nop_expr,b.0_1} (0014), {bit_not_expr,_16}
(0016) }
which is OK, 0 | .. gets simplified to ~16
Then we PHI-translate to where _5 == 1:
ANTIC_IN[4] := { b.0_1 (0001), {nop_expr,b.0_1} (0014), {bit_not_expr,_16}
(0016), {bit_ior_expr,_17,1} (0027), {bit_ior_expr,_24,1} (0028) }
even that's OK, you see that we simplified just _5 | _19 to 1 (constants
are not tracked in the set, the translated _17 | _5 and _24 | _5 got
different value numbers).
But then:
Found partial redundancy for expression {bit_ior_expr,_5,_19} (0017)
...
Created phi prephitmp_29 = PHI <1(4), _28(14)>
in block 5 (0017)
see how we figured the redundancy for value 0017 (because _5 | _19
simplified to 1) and we use the same value for the PHI as for all of
the expressions.
That we now keep all PRE exprs didn't save us here. _19 _is_ the leader
for the expression as we translate it. The problem is the other
expressions for the same value do not translate the same.
This is probably a longer latent issue since we scrapped resetting
ranges which likely means since RPO VN. It's always a bit of luck
but I guess since we now track all expressions we have for a value
this got more robust in triggering. It of course also needs a suitable
simplification to manifest.
I have to think about this. Simplifying to sth like
if (flag)
a = 1;
if (b & 1 == b) // b [0,1]
x = a | b;
else
x = a | b;
return x;
should be possible.
[Bug target/115518] New: aarch64: Poor codegen for arm_neon_sve_bridge.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115518
Bug ID: 115518
Summary: aarch64: Poor codegen for arm_neon_sve_bridge.h
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: aarch64-sve
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
With PR115464 fixed, the following testcase:
#include
#include
#include
svuint16_t
convolve4_4_x (uint16x8x2_t permute_tbl, svuint16_t a)
{
return svset_neonq_u16 (a, permute_tbl.val[1]);
}
generates:
mov v0.16b, v1.16b
ptrue p3.h, vl8
sel z0.h, p3, z0.h, z2.h
ret
The move is redundant: we should be able to use z1.h as input to the sel
instead.
[Bug target/115397] [15 Regression] ICE 'during RTL pass: split1' on numpy-1.26.4 i686-linux '-fPIC -mavx512f' since r15-1100-gec985bc97a0157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115397 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Roger Sayle --- This issue should now be fixed on mainline. We now generate better code on i686 with -fPIC (for this case) than we did in GCC 14.
[Bug c++/115511] ICE on ambigous overload for _Float32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115511 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Untested fix below. I wasn't aware any targets would actually have float the same as double. C++23 says here: http://eel.is/c++draft/conv.rank#2.2 that double has higher rank than float http://eel.is/c++draft/conv.rank#2.5 and that extended type with same set of values as 2+ standard types has same rank as double. As I've only thought about the double same as long double case, I've only handled that case there. No testcase for testsuite, as this needs to be tested in avr/sh specific g++.target only and needs proper options/effective target macros to find out if that is really the float same as double configuration. Will defer testcases to the respective target maintainers. 2024-06-17 Jakub Jelinek PR target/111343 PR c++/115511 * typeck.cc (cp_compare_floating_point_conversion_ranks): If an extended floating point type mv1 has same set of values as more than one standard floating point type and mv2 is float, return 2. --- gcc/cp/typeck.cc.jj 2024-06-04 13:19:03.755604346 +0200 +++ gcc/cp/typeck.cc2024-06-17 10:32:02.063088961 +0200 @@ -393,6 +393,9 @@ cp_compare_floating_point_conversion_ran has higher rank. */ if (cnt > 1 && mv2 == long_double_type_node) return -2; + /* And similarly if t2 is float, t2 has lower rank. */ + if (cnt > 1 && mv2 == float_type_node) +return 2; /* Otherwise, they have equal rank, but extended types (other than std::bfloat16_t) have higher subrank. std::bfloat16_t shouldn't have equal rank to any standard
[Bug target/111343] [SH] Including in C++23 causes an ICE with -m4-single-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111343 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Untested fix below. I wasn't aware any targets would actually have float the same as double. C++23 says here: http://eel.is/c++draft/conv.rank#2.2 that double has higher rank than float http://eel.is/c++draft/conv.rank#2.5 and that extended type with same set of values as 2+ standard types has same rank as double. As I've only thought about the double same as long double case, I've only handled that case there. No testcase for testsuite, as this needs to be tested in avr/sh specific g++.target only and needs proper options/effective target macros to find out if that is really the float same as double configuration. Will defer testcases to the respective target maintainers. 2024-06-17 Jakub Jelinek PR target/111343 PR c++/115511 * typeck.cc (cp_compare_floating_point_conversion_ranks): If an extended floating point type mv1 has same set of values as more than one standard floating point type and mv2 is float, return 2. --- gcc/cp/typeck.cc.jj 2024-06-04 13:19:03.755604346 +0200 +++ gcc/cp/typeck.cc2024-06-17 10:32:02.063088961 +0200 @@ -393,6 +393,9 @@ cp_compare_floating_point_conversion_ran has higher rank. */ if (cnt > 1 && mv2 == long_double_type_node) return -2; + /* And similarly if t2 is float, t2 has lower rank. */ + if (cnt > 1 && mv2 == float_type_node) +return 2; /* Otherwise, they have equal rank, but extended types (other than std::bfloat16_t) have higher subrank. std::bfloat16_t shouldn't have equal rank to any standard
[Bug rtl-optimization/115021] [14 regression] unnecessary spill for vpternlog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115021 Roger Sayle changed: What|Removed |Added Summary|[14/15 regression] |[14 regression] unnecessary |unnecessary spill for |spill for vpternlog |vpternlog | Known to work||15.0 --- Comment #6 from Roger Sayle --- As reported by Hongtao, this is no longer visible on mainline, due to changes in AVX512 ternlog handling, but the underlying RA issue still exists and is visible on the GCC 14 branch.
[Bug libstdc++/115512] _Float32 overloads in cmath cause ICE for default AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115512 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Of course cmath needs to provide _Float32 overloads when _Float32 is supported. I've provided a fix for the other bug and this is IMNSHO a non-bug.
[Bug target/115519] New: s390 fallout from removing vcond{,u,eq} patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115519
Bug ID: 115519
Summary: s390 fallout from removing vcond{,u,eq} patterns
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at gcc dot gnu.org
Blocks: 114189
Target Milestone: ---
Target: s390*-*-*
When applying the patch from PR114189 testing reveals
gcc.target/s390/vector/vcond-shift.c scan-assembler-not vzero\t*
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrab\t%v.?,%v.?,7 6
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesraf\t%v.?,%v.?,31
6
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrah\t%v.?,%v.?,15
6
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrlb\t%v.?,%v.?,7 4
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrlf\t%v.?,%v.?,31
4
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrlh\t%v.?,%v.?,15
4
gcc.target/s390/zvector/autovec-long-double-signaling-ge.c scan-assembler
\\n\\twfkhexb\\t
gcc.target/s390/zvector/autovec-long-double-signaling-gt.c scan-assembler
\\n\\twfkhxb\\t
gcc.target/s390/zvector/autovec-long-double-signaling-le.c scan-assembler
\\n\\twfkhexb\\t
gcc.target/s390/zvector/autovec-long-double-signaling-lt.c scan-assembler
\\n\\twfkhxb\\t
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189
[Bug 114189] Target implements obsolete vcond{,u,eq} expanders
[Bug rtl-optimization/115506] Possible but missed "cmp" instruction merging (x86 & ARM, optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115506
--- Comment #2 from Uroš Bizjak ---
For the original testcase tree optimizers optimize to:
[local count: 114863530]:
_30 = _2 & 240;
if (_30 == 224)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 75809929]:
if (_30 <= 223)
goto ; [50.00%]
else
goto ; [50.00%]
and for /* NOTE 1 */ workaround:
[local count: 114863530]:
_30 = _2 & 240;
if (_30 == 224)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 75809929]:
if (_30 <= 224)
goto ; [50.00%]
else
goto ; [50.00%]
If the tree optimizer didn't over-optimize the original case and left:
[local count: 75809929]:
if (_30 < 224)
goto ; [50.00%]
else
goto ; [50.00%]
then RTL CSE2 pass would be able to merge:
(insn 31 30 32 4 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 111 [ _30 ])
(const_int -32 [0xffe0]))) "pr115506.c":11:8 9
{*cmpqi_1}
(nil))
and
(insn 36 33 37 5 (set (reg:CC 17 flags)
(compare:CC (reg:QI 111 [ _30 ])
(const_int -33 [0xffdf]))) "pr115506.c":14:15 9
{*cmpqi_1}
(expr_list:REG_DEAD (reg:QI 111 [ _30 ])
(nil)))
Is there a way to avoid the over-optimization with tree optimizers? RTL part
has no way to update the flags user during CSE2 pass:
(jump_insn 37 36 38 5 (set (pc)
(if_then_else (gtu (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref:DI 90)
(pc))) "pr115506.c":14:15 1130 {*jcc}
(expr_list:REG_DEAD (reg:CC 17 flags)
(int_list:REG_BR_PROB 536870916 (nil)))
[Bug c++/109739] bogus warning due to -Wmissing-field-initializers in C++20 with designated initializers on struct with empty base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109739 Matthias Kretz (Vir) changed: What|Removed |Added CC||mkretz at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Matthias Kretz (Vir) --- This was fixed in GCC 14 via 110064.
[Bug libstdc++/115512] _Float32 overloads in cmath cause ICE for default AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115512 --- Comment #2 from dv at vollmann dot ch --- On 6/17/24 10:59, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115512 > > Jakub Jelinek changed: > > What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #1 from Jakub Jelinek --- > Of course cmath needs to provide _Float32 overloads when _Float32 is > supported. > I've provided a fix for the other bug and this is IMNSHO a non-bug. I agree. I didn't know about _Float32 and thought it's just a typedef. But as a real type providing these overloads is fine.
[Bug rtl-optimization/115506] Possible but missed "cmp" instruction merging (x86 & ARM, optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115506
--- Comment #3 from Kang-Che Sung ---
I'm not sure if this helps, but the idea is to recognize three-way comparison
as a special case.
My code was originally written in this ordering:
```c
if (x < c) {
do_action_a();
} else if (x == c) {
do_action_b();
} else {
do_action_c();
}
```
But it should work no differently from this:
```c
if (x == c) {
do_action_b();
} else if (x < c) {
do_action_a();
} else {
do_action_c();
}
```
Or this:
```c
if (x == c) {
do_action_b();
} else if (x <= c) {
do_action_a();
} else {
do_action_c();
}
```
Or even this:
```c
if (x >= c) {
if (x == c) {
do_action_b();
} else {
do_action_c();
}
} else {
do_action_a();
}
```
[Bug c/115513] attribute nonstring could help with printf mistakes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115513
--- Comment #2 from Peter Eisentraut ---
(In reply to Xi Ruoyao from comment #1)
> But what should we do with something like `printf("%32s", pd->name);`?
Perhaps you mean
printf("%.32s", pd->name);
? (I don't think the minimum field width is relevant to this issue.) If so,
then yes, I think it would be good if this would be analyzed for correctness,
so that this incantation could be used for printing out these kinds of things.
(Better style might be `printf("%.*s", sizeof pd->name, pd->name);`.)
[Bug fortran/107294] Missed optimization: multiplying real with complex number in Fortran (only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107294 mjr19 at cam dot ac.uk changed: What|Removed |Added CC||mjr19 at cam dot ac.uk --- Comment #5 from mjr19 at cam dot ac.uk --- But 10.1.5.2.4 says "once the interpretation of a numeric intrinsic operation is established, the processor may evaluate any mathematically equivalent expression, provided that the integrity of parentheses is not violated." As cmplx(r)*z and cmplx(r*real(z),r*aimag(z)) are mathematically equivalent, is a Fortran compiler not permitted to make this optimisation (unless conforming to F90 or F95, for 10.1.5.2.4 was first introduced in F2003)? Furthermore, Fortran does not define how complex multiplication is to be performed, so relying on the precise details result when multiplying signed zeros or NaNs may be unwise.
[Bug c++/115511] ICE on ambigous overload for _Float32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115511 --- Comment #5 from dv at vollmann dot ch --- On 6/17/24 10:47, jakub at gcc dot gnu.org wrote: > --- Comment #4 from Jakub Jelinek --- > Untested fix below. I did a quick test for AVR and it worked :-) I'll now do a full build of libstdc++ and see how it works.\
[Bug c/115513] attribute nonstring could help with printf mistakes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115513
--- Comment #3 from Xi Ruoyao ---
(In reply to Peter Eisentraut from comment #2)
> (In reply to Xi Ruoyao from comment #1)
> > But what should we do with something like `printf("%32s", pd->name);`?
>
> Perhaps you mean
>
> printf("%.32s", pd->name);
Yes I mean "%.32s".
[Bug c++/115504] [14/15 Regression] Wrong decltype result for a captured reference inside lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115504 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords|needs-bisection | Priority|P3 |P2 Ever confirmed|0 |1 Last reconfirmed||2024-06-17 CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r14-5330-g705ab7927c81b77503d229513fac991106617766
[Bug c++/115501] [13/14/15 Regression] ICE: in build_call_a with dynamic_cast after invalid definition of __cxxabiv1::__dynamic_cast since r13-3299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115501 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Keywords|needs-bisection | Priority|P3 |P2 Summary|[13/14/15 Regression] ICE: |[13/14/15 Regression] ICE: |in build_call_a with|in build_call_a with |dynamic_cast after invalid |dynamic_cast after invalid |definition of |definition of |__cxxabiv1::__dynamic_cast |__cxxabiv1::__dynamic_cast ||since r13-3299 --- Comment #5 from Jakub Jelinek --- Confirming this started with r13-3299-gd6a488f243acfac4bdbbb0eefbee3ae916159cf5
[Bug c++/115520] New: Loop vectorization depends on variable names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115520
Bug ID: 115520
Summary: Loop vectorization depends on variable names
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: max.sagebaum at scicomp dot uni-kl.de
Target Milestone: ---
Created attachment 58447
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58447&action=edit
Reproducer
I asked this question on gcc-help and got the reply that this is probably a
bug.
(https://gcc.gnu.org/pipermail/gcc-help/2024-June/143496.html)
Compiler options: -O3 -std=c++20 -fopt-info-vec-missed
Version: 14.1 (Compiler Explorer)
Reproducer on Compiler Explorer: https://godbolt.org/z/YEPzfx3eT
With the above options this loop vectorizes:
```
struct match_return {
char* pos;
bool matched;
};
bool func_is_vectorized (char*& cur, context& ctx) {
match_return r {cur, true};
constexpr char str1[] =
"aa";
if (!(std::distance(r.pos, ctx.end) < 50)) {return false;}
for(int i = 0; i < 50; i += 1) {
if (str1[i] != r.pos[i]) { r.matched = false; }
}
if (r.matched) {
r.pos += 50;
}
return r.matched;
}
```
If I remove the match_return structure, then the loop no longer vectorizes. The
message is:
not vectorized: relevant phi not supported: matched_21 = PHI <_20(6),
1(5)>
The "new" code is:
```
bool func_is_also_not_vectorized (char*& cur, context& ctx) {
bool matched = true;
constexpr char str1[] =
"aa";
if (!(std::distance(cur, ctx.end) < 50)) {return false;}
for(int i = 0; i < 50; i += 1) {
if (str1[i] != cur[i]) { matched = false; }
}
if (matched) {
cur += 50;
}
return matched;
}
```
The interesting part is. If I only replace `r.matched` with `matched`
and introduce the proper variable. The vectorizer is already failing.
[Bug c++/115377] [11/12/13/14/15 Regression] Invalid typename with non nested-name-specifier accepted in specific contexts since r5-2683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115377 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Summary|[11/12/13/14/15 Regression] |[11/12/13/14/15 Regression] |Invalid typename with non |Invalid typename with non |nested-name-specifier |nested-name-specifier |accepted in specific|accepted in specific |contexts|contexts since r5-2683 --- Comment #3 from Jakub Jelinek --- This is accepted since r5-2683-g215acd2bae70e5ae9cbe68bdaa150a9215722310
[Bug tree-optimization/115347] [12/13/14/15 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115347 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression] |wrong code at -O3 on|wrong code at -O3 on |x86_64-linux-gnu|x86_64-linux-gnu since ||r12-2097 Priority|P3 |P2 Keywords|needs-bisection | CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r12-2097-g9f34b780b0461ec7b2b2defe96e44ab616ea2aa3
[Bug c++/115358] [13/14/15 Regression] template argument deduction/substitution failed in generic lambda function use of static constexpr array type whos initializer defines the size since r13-2540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115358 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | Summary|[13/14/15 Regression] |[13/14/15 Regression] |template argument |template argument |deduction/substitution |deduction/substitution |failed in generic lambda|failed in generic lambda |function use of static |function use of static |constexpr array type whos |constexpr array type whos |initializer defines the |initializer defines the |size|size since r13-2540 CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Started with r13-2540-g4db3cb781c355341fa041e6b5bbbfc495c6a0fdb
[Bug tree-optimization/115521] New: ICE at -O1 with "-fno-tree-ccp -fno-tree-dominator-opts" on x86_64-linux-gnu: in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521
Bug ID: 115521
Summary: ICE at -O1 with "-fno-tree-ccp
-fno-tree-dominator-opts" on x86_64-linux-gnu: in
extract_constrain_insn, at recog.cc:2713
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it doesn't reproduce with 13.* and
earlier.
Compiler Explorer: https://godbolt.org/z/qEb7fcaf1
The reduced test is still quite big, but it seems difficult to get it to be
much smaller.
[524] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240617 (experimental) (GCC)
[525] %
[525] % gcctk -O1 -fno-tree-ccp -fno-tree-dominator-opts -c -w small.c
small.c: In function ‘bi’:
small.c:188:1: error: insn does not satisfy its constraints:
188 | }
| ^
(insn 19 968 967 2 (parallel [
(set (strict_low_part (reg:QI 2 cx [orig:415 bj ] [415]))
(ior:QI (subreg:QI (zero_extract:HI (reg/v:HI 2 cx [orig:415 bj
] [415])
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)
(reg:QI 0 ax [orig:99 c.3_4 ] [99])))
(clobber (reg:CC 17 flags))
]) "small.c":21:7 656 {*iorqi_exthi_1_slp}
(nil))
during RTL pass: reload
small.c:188:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2713
0x84dde4 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-trunk/gcc/rtl-error.cc:108
0x84de10 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-trunk/gcc/rtl-error.cc:118
0x84c04a extract_constrain_insn(rtx_insn*)
../../gcc-trunk/gcc/recog.cc:2713
0xf6aca7 check_rtl
../../gcc-trunk/gcc/lra.cc:2189
0xf70131 lra(_IO_FILE*, int)
../../gcc-trunk/gcc/lra.cc:2610
0xf2044f do_reload
../../gcc-trunk/gcc/ira.cc:5973
0xf2044f execute
../../gcc-trunk/gcc/ira.cc:6161
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.
[526] %
[526] % cat small.c
typedef int a;
long b, c, ab, d, e, g, h, j, k, l, m, n, at;
a o, p, **q, r, aa, s, t, ac, ad, u, v, w, x, f;
unsigned ae, z, af;
short ag, ah, ai, aj, ak, al, am, an, ao, ap, aq, y, ar, as;
static char au, av;
static volatile short aw;
a *ax, *ay, *az, *ba;
a **bb, **bc;
int bd();
char be();
void bf();
short bg();
long bh();
a *bi() {
char bj[2];
char *bk = &bj[0];
int i = 0;
for (; i < 2; i++)
bj[i] = 0;
*bk = c | bj[1];
l = e = af = ac = 0;
short bl[16] = {c, an, c, ao, an, ai, ag, c, ag, c, f, f, ag};
char bm[] = {f, f, d, f, f, d, f}, bn = 0, bo = m && au;
aw;
if (b) {
int bp = 0, bq = 0, bs = o, bw = aj = an;
while (aw)
br:
v = aa = --am;
while (au)
ai = b = r = p = av;
as = s = c = 0;
az = bi();
b = f = be();
t = bd();
b = bg();
d = bg();
for (; b; ++at) {
a *d = &bq;
for (; i; i++)
for (; c; ad++)
c = e = b = bd();
f = bg();
ar = c = bg();
f = be();
*q = ba = bi();
}
an = c = av;
h = bh();
z = be();
d = bg();
e = i = be();
j = bh();
k = bh(++k);
v = be();
a *bt = &i, *bu = &bp;
b = bd();
e = bg();
d = bg();
f = be();
*bc = *bb = bi(&bs);
bv:
f = av;
f = bh();
y = bg();
n = bh();
{
short f = aw, bz = au;
aw;
--ab;
p = aw - av;
bx:
ag = aw - ag;
if (an || c && av) {
ag = aw ^ av;
goto by;
}
aw;
aw;
am = ai = au > &bz;
c = av;
bd();
if (av)
bd();
am = av;
bd();
}
an = aa = ag = e = bd();
char ca = b;
by:
c = bg();
d = bh();
e = bh();
e = bh();
g = bh();
x = bg();
an = al > &ca;
if (av)
i = 0;
for (; i; i++)
bd();
b = v = be();
*ba = b = bg();
c = p && bw;
if (bw)
an = p = bg();
d = bd();
e = bg();
ay = bi();
b = be();
c = bd();
b = be();
f = bg();
while (au)
[Bug libstdc++/115522] New: std::to_array no longer works for struct which is trivial but not default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115522
Bug ID: 115522
Summary: std::to_array no longer works for struct which is
trivial but not default constructible
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.klauer at gin dot de
Target Milestone: ---
Hi,
The following example used to compile successfully with gcc 13.2 or older, but
it no longer compiles in gcc 13.3 and 14.1:
#include
#include
struct range {
const int min, max;
};
static_assert(std::is_trivial_v);
static_assert(!std::is_default_constructible_v);
static_assert(std::is_copy_constructible_v);
auto my_array = std::to_array({{0, 0}});
Output from g++ 13.3.0 on x86_64-pc-linux-gnu, built with
"--enable-languages=c,c++ --prefix=/opt/gcc-13.3":
$ /opt/gcc-13.3/bin/g++ -std=c++20 e.cxx -c
In file included from e.cxx:1:
/opt/gcc-13.3/include/c++/13.3.0/array: In instantiation of ‘constexpr
std::array >::type, _Nm>
std::to_array(_Tp (&&)[_Nm]) [with _Tp = range; long unsigned int _Nm = 1;
typename remove_cv< >::type = range]’:
e.cxx:9:37: required from here
/opt/gcc-13.3/include/c++/13.3.0/array:460:44: error: use of deleted function
‘std::array::array()’
460 | array, _Nm> __arr;
|^
/opt/gcc-13.3/include/c++/13.3.0/array:94:12: note: ‘std::array::array()’ is implicitly deleted because the default definition would be
ill-formed:
94 | struct array
|^
/opt/gcc-13.3/include/c++/13.3.0/array:94:12: error: use of deleted function
‘range::range()’
e.cxx:3:8: note: ‘range::range()’ is implicitly deleted because the default
definition would be ill-formed:
3 | struct range {
|^
e.cxx:3:8: error: uninitialized const member in ‘struct range’
e.cxx:4:15: note: ‘const int range::min’ should be initialized
4 | const int min, max;
| ^~~
e.cxx:3:8: error: uninitialized const member in ‘struct range’
3 | struct range {
|^
e.cxx:4:20: note: ‘const int range::max’ should be initialized
4 | const int min, max;
|^~~
/opt/gcc-13.3/include/c++/13.3.0/array:465:39: error: use of deleted function
‘range& range::operator=(const range&)’
465 | __arr._M_elems[__i] = __a[__i];
| ^~
e.cxx:3:8: note: ‘range& range::operator=(const range&)’ is implicitly deleted
because the default definition would be ill-formed:
3 | struct range {
|^
e.cxx:3:8: error: non-static const member ‘const int range::min’, cannot use
default assignment operator
e.cxx:3:8: error: non-static const member ‘const int range::max’, cannot use
default assignment operator
It's not clear to me whether it should work in the first place, though it was
my understanding that std::to_array does not necessarily require a default
constructor, since it is closer to a move/copy operation.
[Bug libstdc++/115512] _Float32 overloads in cmath cause ICE for default AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115512 --- Comment #3 from dv at vollmann dot ch --- On 6/17/24 10:59, jakub at gcc dot gnu.org wrote: > --- Comment #1 from Jakub Jelinek --- > Of course cmath needs to provide _Float32 overloads when _Float32 is > supported. > I've provided a fix for the other bug and this is IMNSHO a non-bug. I've now built a libstdc++ with your fix and cmath compiles fine :-) So this indeed is a non-bug. Thanks!
[Bug libstdc++/115512] _Float32 overloads in cmath cause ICE for default AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115512 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jakub Jelinek --- .
[Bug target/115362] fixed_size_simd dot product recognition and sign of determinant not working for stdx::reduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115362 --- Comment #21 from Jon Daniel --- The generated assembler output of g++: vmaskmovps 40(%rsp), %xmm1, %xmm0 vmaskmovps 56(%rsp), %xmm1, %xmm2 vmulps %xmm2, %xmm0, %xmm0 Notice the lower memory address register is taken as the second source operand clang++: vmaskmovps 48(%rsp), %xmm0, %xmm2 vmaskmovps 32(%rsp), %xmm0, %xmm3 vmulps %xmm3, %xmm2, %xmm2 Notice the lower memory address register is taken as the first source operand
[Bug tree-optimization/115492] [15 Regression] wrong code at -O2/O3 since r15-204-g7c469a9fc78550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115492 --- Comment #7 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:95bfc6abf378a32e502dca0e2938f94d5b0ab094 commit r15-1374-g95bfc6abf378a32e502dca0e2938f94d5b0ab094 Author: Richard Biener Date: Mon Jun 17 09:23:25 2024 +0200 Testcase for PR115492 This adds a testcase for the PR fixed with reversal of r15-204-g7c469a9fc78550. PR tree-optimization/115492 * gcc.dg/torture/pr115492.c: New testcase.
[Bug tree-optimization/115508] [14/15 regression] ICE when building flac with -O2 -march=znver1 since r14-5603-g2b59e2b4dff421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508 --- Comment #14 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:65e72b95c63a5501cf1482f3814ae8c8e672bf06 commit r15-1375-g65e72b95c63a5501cf1482f3814ae8c8e672bf06 Author: Richard Biener Date: Mon Jun 17 14:36:56 2024 +0200 tree-optimization/115508 - fix ICE with SLP scheduling and extern vector When there's a permute after an extern vector we can run into a case that didn't consider the scheduled node being a permute which lacks a representative. PR tree-optimization/115508 * tree-vect-slp.cc (vect_schedule_slp_node): Guard check on representative. * gcc.target/i386/pr115508.c: New testcase.
[Bug libstdc++/37475] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475
--- Comment #14 from Kristian Spangsege
---
Is the underscore intended before `Guard` in `explicit _Guard(__c_locale) { }`
for the GLIBC <= 2.2 case?
Besides that, the full patch looks correct to me.
[Bug tree-optimization/115256] [15 Regression] 502.gcc_r Run failed with '-march=native -Ofast -funroll-loops -flto' since r15-571-g1e0ae1f52741f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115256 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #5 from Richard Biener --- Thanks for analyzing. Indeed older GCC had this sort of issue, so invalid.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 115256, which changed state. Bug 115256 Summary: [15 Regression] 502.gcc_r Run failed with '-march=native -Ofast -funroll-loops -flto' since r15-571-g1e0ae1f52741f7 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115256 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID
[Bug rtl-optimization/115523] New: [avr] Remove SFmode insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115523 Bug ID: 115523 Summary: [avr] Remove SFmode insns Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Created attachment 58448 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58448&action=edit sfmode.c: C test case There is currently the problem that subreg lowering is producing code that later passes cannot really digest: With avr-gcc v14.1: $ avr-gcc sfmode.c -Os -c -mmcu=atmega8 -dp -save-temps -dumpbase "" && avr-size sfmode.o textdata bss dec hex filename 160 0 0 160 a0 sfmode.o whereas with v8: textdata bss dec hex filename 40 0 0 40 28 sfmode.o
[Bug rtl-optimization/115521] ICE at -O1 with "-fno-tree-ccp -fno-tree-dominator-opts" on x86_64-linux-gnu: in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521 Uroš Bizjak changed: What|Removed |Added Keywords||ra Ever confirmed|0 |1 Component|target |rtl-optimization Last reconfirmed||2024-06-17 CC||vmakarov at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Uroš Bizjak --- This is the case of reload failure, trying to satisfy: (define_insn_and_split "*qi_ext_1_slp" [(set (strict_low_part (match_operand:QI 0 "register_operand" "+Q,&Q")) (any_logic:QI (subreg:QI (match_operator:SWI248 3 "extract_operator" [(match_operand 2 "int248_register_operand" "Q,Q") (const_int 8) (const_int 8)]) 0) (match_operand:QI 1 "nonimmediate_operand" "0,!qm"))) (clobber (reg:CC FLAGS_REG))] Cc added.
[Bug rtl-optimization/115523] [avr] Remove SFmode insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115523 --- Comment #1 from Georg-Johann Lay --- That bloat can be worked around by taking away the SFmode insns in avr.md.
[Bug rtl-optimization/115521] ICE at -O1 with "-fno-tree-ccp -fno-tree-dominator-opts" on x86_64-linux-gnu: in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521 --- Comment #2 from Uroš Bizjak --- Similar to PR114942.
[Bug target/115362] fixed_size_simd dot product recognition and sign of determinant not working for stdx::reduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115362 --- Comment #22 from Jon Daniel --- The generated assembler output snippet: g++: vdpps $113, 72(%rsp), 24(%rsp), %xmm3 vdpps $113, 72(%rsp), 24(%rsp), %xmm2 vsubss %xmm2, %xmm3, %xmm0 Notice the second dot product result as the first source operand clang++: vdpps $113, %xmm2, %xmm1, %xmm4 vdpps $113, %xmm0, %xmm1, %xmm1 vsubss %xmm4, %xmm0, %xmm0 Notice the first dot product result as the first source operand
[Bug target/115362] fixed_size_simd dot product recognition and sign of determinant not working for stdx::reduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115362 --- Comment #23 from Jon Daniel --- (In reply to Jon Daniel from comment #21) > The generated assembler output of > > g++: > vmaskmovps 40(%rsp), %xmm1, %xmm0 > vmaskmovps 56(%rsp), %xmm1, %xmm2 > vmulps %xmm2, %xmm0, %xmm0 > > Notice the lower memory address register is taken as the second source > operand > > clang++: > vmaskmovps 48(%rsp), %xmm0, %xmm2 > vmaskmovps 32(%rsp), %xmm0, %xmm3 > vmulps %xmm3, %xmm2, %xmm2 > > Notice the lower memory address register is taken as the first source operand Please delete "Comment 21" it is accidently posted wrong code and has nothing to do with the bug.
[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389 --- Comment #5 from GCC Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:c70eea0dba5f223d49c80cfb3e80e87b74330aac commit r15-1377-gc70eea0dba5f223d49c80cfb3e80e87b74330aac Author: Peter Bergner Date: Fri Jun 14 14:36:20 2024 -0500 rs6000: Compute rop_hash_save_offset for non-Altivec compiles [PR115389] We currently only compute the offset for the ROP hash save location in the stack frame for Altivec compiles. For non-Altivec compiles when we emit ROP mitigation instructions, we use a default offset of zero which corresponds to the backchain save location which will get clobbered on any call. The fix is to compute the ROP hash save location for all compiles. 2024-06-14 Peter Bergner gcc/ PR target/115389 * config/rs6000/rs6000-logue.cc (rs6000_stack_info): Compute rop_hash_save_offset for non-Altivec compiles. gcc/testsuite PR target/115389 * gcc.target/powerpc/pr115389.c: New test.
[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389 --- Comment #6 from Peter Bergner --- Fixed on trunk. I will let it burn-in on trunk for a couple of days before pushing the backports.
[Bug tree-optimization/115508] [14 regression] ICE when building flac with -O2 -march=znver1 since r14-5603-g2b59e2b4dff421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508 Richard Biener changed: What|Removed |Added Summary|[14/15 regression] ICE when |[14 regression] ICE when |building flac with -O2 |building flac with -O2 |-march=znver1 since |-march=znver1 since |r14-5603-g2b59e2b4dff421|r14-5603-g2b59e2b4dff421 Known to work||15.0 Priority|P3 |P2
[Bug tree-optimization/115492] [15 Regression] wrong code at -O2/O3 since r15-204-g7c469a9fc78550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115492 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Richard Biener --- I have reverted the change.
[Bug c/115290] [12/13/14/15 Regression] tree check fail in c_tree_printer, at c/c-objc-common.cc:330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115290 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 58449 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58449&action=edit gcc15-pr115290.patch Untested fix.
[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 --- Comment #6 from Richard Biener --- The cruical difference is: - _60 = BIT_FIELD_REF ; - _61 = BIT_FIELD_REF ; - _62 = MAX_EXPR <_61, _60>; - _63 = BIT_FIELD_REF ; - _64 = MAX_EXPR <_63, _62>; - _65 = BIT_FIELD_REF ; - _66 = MAX_EXPR <_65, _64>; - _67 = _66 == -1; - stmp_cstore_15.38_68 = _67 ? arr__I_lsm.26_4 : _66; + _58 = BIT_FIELD_REF ; + _59 = BIT_FIELD_REF ; + _60 = BIT_FIELD_REF ; + _61 = BIT_FIELD_REF ; + _62 = MAX_EXPR <_58, _59>; + _63 = MAX_EXPR <_62, _60>; + _64 = MAX_EXPR <_63, _61>; + _65 = _61 == -1; + stmp_cstore_15.38_66 = _65 ? arr__I_lsm.26_4 : _61; note how the compare against -1 uses the vector component rather the MAX reduced value.
[Bug target/115500] RISC-V: Performance regression on 1bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115500 --- Comment #7 from Jeffrey A. Law --- And to be clearer, if you look at the two assembly snippets: The problem is about 0: 814dsrlia0,a0,0x13 2: 8905andia0,a0,1 4: e501bneza0,c <.L3> vs 0: 02c51793sllia5,a0,0x2c 4: 0007c563bltza5,e <.L3> They're both using the same basic idioms (logical shifts and simple conditional branch), one just has an extra andi. The second one has a smaller data dependency critical path. So it's hard to see how the first would ever be better. More likely than not what's going on here is going to be something highly specific to the micro-architecture implementation of whatever chip you tested. So for example, some uarchs are particularly sensitive to code alignments. That could effect the little loop or the function call. To put this in perspective, I'm aware of a uarch that would show a double-digit performance delta due to a 2 instruction, 6 byte sequence moving across a particular boundary -- in a real world benchmark that executes nearly a trillion instructions. Point is you have to be *very* careful analyzing this stuff and sometimes things can be very surprising. So probably the next question is what did you use to test this and what do we know about its uarch and can we correlate what is public about that uarch to the behavior your seeing.
[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0 Priority|P3 |P1
[Bug target/115493] [15 regression] gcc.c-torture/execute/pr94734.c fails on MVE after r15-1054-g202a9c8fe7d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115493 --- Comment #7 from Richard Biener --- Created attachment 58450 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58450&action=edit patch I am testing I'm testing this (visually confirmed it fixes the observed issue).
[Bug c++/115524] New: Cygwin: Space character categorized as non-printable by std::ctype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115524
Bug ID: 115524
Summary: Cygwin: Space character categorized as non-printable
by std::ctype
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kristian.spangsege at gmail dot com
Target Milestone: ---
Created attachment 58451
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58451&action=edit
test.cpp Demonstrate the bug
On Cygwin, a space character is reported as non-printable by
`std::ctype` in the "C" locale (the only locale supported by
libstdc+++ on Cygwin). In other words, the following expression evaluates to
`false`:
ctype.is(std::ctype_base::print, ctype.widen(' '))
where `ctype` is obtained by `std::use_facet>(loc)` and
`loc` is the "C" locale.
It should have been evaluated to `true` because a space character is required
by the C++ standard to be categorized as printable (the defining distinction
between a printable and a graphical character is that space is printable but
not graphical).
Also, the space character is reported as printable by `std::iswprint(int ch)`.
So it seems like the problem is specific to `libstdc++`.
Also, the non-wide space character is reported as printable, i.e,
`std::use_facet>(loc)::is(std::ctype_base::print, ' ')` is
`true`.
Also, `ctype.is(std::ctype_base::print, ctype.widen(' '))` is `true` with
MinGW, with GCC on Linux, and with Visual Studio.
The problem can be demonstrated with the code below (attached as `test.cpp`) in
regular Cygwin (https://cygwin.com/install.html) using GCC 12.3.1 and in the
Cygwin environment of MSYS2 (https://www.msys2.org/) using GCC 13.2.0:
#include
#include
#include
#include
int main()
{
using facet_type = std::ctype;
std::locale loc;
const auto& ctype = std::use_facet(loc);
wchar_t ch = ctype.widen(' ');
std::cout << ctype.is(ctype.print, ch) << "\n";
std::cout << (std::iswprint(std::char_traits::to_int_type(ch)) !=
0) << "\n";
}
[Bug other/115525] New: Documentation: "sentinel" attribute should suggest "nullptr" instead of NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115525 Bug ID: 115525 Summary: Documentation: "sentinel" attribute should suggest "nullptr" instead of NULL Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: Explorer09 at gmail dot com Target Milestone: --- "sentinel" function attribute in GCC documentation: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-sentinel-function-attribute The section mentioned `NULL` for the null pointer. But for C and C++ this is a bad idea (read this as for why: https://ewontfix.com/11/) We are now in the era where "nullptr" is standardized in both C and C++, and so the documentation should suggest that instead, whenever possible. (For pre-C23 code, `(void *)0` may be used as an alternative to `nullptr`, but `NULL` (the constant) should be deprecated for use in function sentinels now.) I suggest changing the paragraph to the following: ``` This function attribute indicates that a call to the function is expected to have a null pointer as the sentinel. The attribute is only valid on variadic functions. If the optional position argument is specified to the attribute, the function expects the sentinel to be present at position counting backwards from the end of the argument list. If position is unspecified or 0, the sentinel is expected to be the last argument of the function call, that is, __attribute__ ((sentinel)) is equivalent to __attribute__ ((sentinel(0))) The attribute is automatically set with a position of 0 for the built-in functions execl and execlp. The built-in function execle has the attribute set with a position of 1. Starting with C++11 and C23, nullptr is the preferred keyword for passing a null pointer argument. For code that need to support older standards, a zero value with a pointer cast may be used as an alternative. The warnings for missing or incorrect sentinels are enabled with -Wformat. ```
[Bug c++/115283] [14 Regression] "used but never defined" with extern templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115283 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9583f781e17d4da881ee64db43af939402331413 commit r14-10318-g9583f781e17d4da881ee64db43af939402331413 Author: Patrick Palka Date: Wed Jun 12 20:05:05 2024 -0400 c++: visibility wrt concept-id as targ [PR115283] Like with alias templates, it seems we don't maintain visibility flags for concepts either, so min_vis_expr_r should ignore them for now. Otherwise after r14-6789 we may incorrectly give a function template that uses a concept-id in its signature internal linkage. PR c++/115283 gcc/cp/ChangeLog: * decl2.cc (min_vis_expr_r) : Ignore concepts. gcc/testsuite/ChangeLog: * g++.dg/template/linkage5.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit b1fe718cbe0c8883af89f52e0aad3ebf913683de)
[Bug c++/115239] [14 Regression] ICE: Segmentation fault with ambiguous function call in some cases (`const char*` vs `char` with `long` vs `unsigned`) since r14-6522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115239 --- Comment #6 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4df86402990e2f45e02a367f1734a22ebc041e98 commit r14-10319-g4df86402990e2f45e02a367f1734a22ebc041e98 Author: Patrick Palka Date: Thu Jun 13 10:02:43 2024 -0400 c++: ICE w/ ambig and non-strictly-viable cands [PR115239] Here during overload resolution we have two strictly viable ambiguous candidates #1 and #2, and two non-strictly viable candidates #3 and #4 which we hold on to ever since r14-6522. These latter candidates have an empty second arg conversion since the first arg conversion was deemed bad, and this trips up joust when called on #3 and #4 which assumes all arg conversions are there. We can fix this by making joust robust to empty arg conversions, but in this situation we shouldn't need to compare #3 and #4 at all given that we have a strictly viable candidate. To that end, this patch makes tourney shortcut considering non-strictly viable candidates upon encountering ambiguity between two strictly viable candidates (taking advantage of the fact that the candidates list is sorted according to viability via splice_viable). PR c++/115239 gcc/cp/ChangeLog: * call.cc (tourney): Don't consider a non-strictly viable candidate as the champ if there was ambiguity between two strictly viable candidates. gcc/testsuite/ChangeLog: * g++.dg/overload/error7.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit 7fed7e9bbc57d502e141e079a6be2706bdbd4560)
[Bug c++/99678] [concepts] requires-clause allows undeclared identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99678 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:20cda2e85c307096a3856f7f27215b8a28982fb6 commit r14-10320-g20cda2e85c307096a3856f7f27215b8a28982fb6 Author: Patrick Palka Date: Thu Jun 13 10:16:10 2024 -0400 c++: undeclared identifier in requires-clause [PR99678] Since the terms of a requires-clause are grammatically primary-expressions and not e.g. postfix-expressions, it seems we need to explicitly handle and diagnose the case where a term parses to a bare unresolved identifier, like cp_parser_postfix_expression does, since cp_parser_primary_expression leaves that up to its callers. Otherwise we incorrectly accept the first three requires-clauses below. Note that the only occurrences of primary-expression in the grammar are postfix-expression and constraint-logical-and-expression, so it's not too surprising that we need this special handling here. PR c++/99678 gcc/cp/ChangeLog: * parser.cc (cp_parser_constraint_primary_expression): Diagnose a bare unresolved unqualified-id. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires38.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit d387ecb2b2f44f33fd6a7c5ec7eadaf6dd70efc9)
[Bug c++/115283] [14 Regression] "used but never defined" with extern templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115283 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- Fixed for GCC 14.2, thanks for the bug report.
[Bug c++/115239] [14 Regression] ICE: Segmentation fault with ambiguous function call in some cases (`const char*` vs `char` with `long` vs `unsigned`) since r14-6522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115239 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Patrick Palka --- Fixed for GCC 14.2, thanks for the bug report.
[Bug c++/99678] [concepts] requires-clause allows undeclared identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99678 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- Fixed for GCC 14.2, thanks for the bug report.
[Bug fortran/107294] Missed optimization: multiplying real with complex number in Fortran (only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107294 --- Comment #6 from kargls at comcast dot net --- (In reply to mjr19 from comment #5) > But 10.1.5.2.4 says "once the interpretation of a numeric intrinsic > operation is established, the processor may evaluate any mathematically > equivalent expression, provided that the integrity of parentheses is not > violated." > > As cmplx(r)*z and cmplx(r*real(z),r*aimag(z)) are mathematically equivalent, > is a Fortran compiler not permitted to make this optimisation (unless > conforming to F90 or F95, for 10.1.5.2.4 was first introduced in F2003)? > > Furthermore, Fortran does not define how complex multiplication is to be > performed, so relying on the precise details result when multiplying signed > zeros or NaNs may be unwise. See comment #3. Type conversion occurs. If you want to get a possibly wrong answer fast, use either -Ofast or -ffast-math.
[Bug libstdc++/115522] [13/14/15 Regression] std::to_array no longer works for struct which is trivial but not default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115522 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Summary|std::to_array no longer |[13/14/15 Regression] |works for struct which is |std::to_array no longer |trivial but not default |works for struct which is |constructible |trivial but not default ||constructible Keywords||rejects-valid Status|UNCONFIRMED |NEW Known to work||12.3.0, 13.2.0 Ever confirmed|0 |1 Known to fail||13.3.0, 14.1.0 Target Milestone|--- |13.4 Last reconfirmed||2024-06-17 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug libstdc++/115522] [13/14/15 Regression] std::to_array no longer works for struct which is trivial but not default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115522 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=110167 --- Comment #2 from Andrew Pinski --- Looks like the check (that was added in r13-8421-g4c6bb36e88d5c8 / r14-1647-g960de5dd886572711ef86fa1e15e30d3810eccb9 ), constexpr (is_trivial_v<_Tp>) should be added on to, something like: constexpr (is_trivial_v<_Tp> && is_default_constructible_v<_Tp>) Or maybe more, I am not 100% sure.
[Bug target/114942] [14/15 Regression] ICE on valid code at -O1 with "-fno-tree-sra -fno-guess-branch-probability": in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942 --- Comment #7 from Andrew Pinski --- *** Bug 115521 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/115521] ICE at -O1 with "-fno-tree-ccp -fno-tree-dominator-opts" on x86_64-linux-gnu: in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup then. *** This bug has been marked as a duplicate of bug 114942 ***
[Bug rtl-optimization/115521] ICE at -O1 with "-fno-tree-ccp -fno-tree-dominator-opts" on x86_64-linux-gnu: in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521 --- Comment #4 from Zhendong Su --- (In reply to Andrew Pinski from comment #3) > Dup then. > > *** This bug has been marked as a duplicate of bug 114942 *** Similar, but perhaps not a dup as PR114942 doesn't reproduce on the trunk anymore.
[Bug tree-optimization/115520] Loop vectorization fails when bool variable instead of unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115520 Andrew Pinski changed: What|Removed |Added Summary|Loop vectorization fails|Loop vectorization fails |when not using a struct |when bool variable instead |sometimes |of unsigned char CC||pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- I have seen this one recorded too.
[Bug tree-optimization/115520] Loop vectorization fails when bool variable instead of unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115520 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-06-17 Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Note the reason why the struct case works is due to SRA "changing" bool type to unsigned char.
[Bug rtl-optimization/115521] ICE at -O1 with "-fno-tree-ccp -fno-tree-dominator-opts" on x86_64-linux-gnu: in extract_constrain_insn, at recog.cc:2713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115521 Andrew Pinski changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|NEW --- Comment #5 from Andrew Pinski --- (In reply to Zhendong Su from comment #4) > (In reply to Andrew Pinski from comment #3) > > Dup then. > > > > *** This bug has been marked as a duplicate of bug 114942 *** > > Similar, but perhaps not a dup as PR114942 doesn't reproduce on the trunk > anymore. Oh there was a change on the trunk which partly solved the issue but it looks like not all of the issue with the RA.
[Bug target/115518] aarch64: Poor codegen for arm_neon_sve_bridge.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115518 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-06-17 Severity|normal |enhancement Ever confirmed|0 |1 Keywords||missed-optimization CC||pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-06-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- .
[Bug libstdc++/37475] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37475 --- Comment #15 from Jonathan Wakely --- Oops, that's definitely not intended! Good catch, thanks.
[Bug target/115523] [avr] Remove SFmode insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115523 --- Comment #2 from Georg-Johann Lay --- Am 17.06.24 um 17:06 schrieb pinskia at gcc dot gnu.org: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115523 > > Andrew Pinski changed: > > What|Removed |Added > > CC||pinskia at gcc dot gnu.org >Component|rtl-optimization|target > This is an issue in the RTL passes, subreg-lowering vs. reg alloc. It's just the case that the backend can (partially) hack around it. Johann
[Bug libstdc++/115522] [13/14/15 Regression] std::to_array no longer works for struct which is trivial but not default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115522
--- Comment #3 from Jonathan Wakely ---
That shouldn't be needed, because a trivial class has to have a trivial default
constructor.
The problem is that we default-initialize the array, which requires the const
members to be initialized.
We also need to check for assignability, because trivial classes can have
deleted assignment operators (for some reason).
--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -434,7 +434,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
static_assert(is_constructible_v<_Tp, _Tp&>);
if constexpr (is_constructible_v<_Tp, _Tp&>)
{
- if constexpr (is_trivial_v<_Tp>)
+ if constexpr (is_trivial_v<_Tp> && is_default_constructible_v<_Tp>
+ && is_copy_assignable_v<_Tp>)
{
array, _Nm> __arr;
if (!__is_constant_evaluated() && _Nm != 0)
@@ -463,7 +464,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
static_assert(is_move_constructible_v<_Tp>);
if constexpr (is_move_constructible_v<_Tp>)
{
- if constexpr (is_trivial_v<_Tp>)
+ if constexpr (is_trivial_v<_Tp> && is_default_constructible_v<_Tp>
+ && is_move_assignable_v<_Tp>)
{
array, _Nm> __arr;
if (!__is_constant_evaluated() && _Nm != 0)
[Bug tree-optimization/115489] [12/13/14/15 regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:589 since r12-3278-g823685221de98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115489 Roger Sayle changed: What|Removed |Added Component|c |tree-optimization --- Comment #3 from Roger Sayle --- The call to gimplify_expr on line 651 of gimplify.cc (in internal_get_tmp_var) doesn't check its return value, which for this test case is GS_ERROR. It looks like internal_get_tmp_var's callers don't expect that it could ever fail, so it's unclear whether returning NULL_RTX or error_mark_node would be safe. One approach might be to record the original type of val (which gets turned into error_mark_node by the failing gimplify_expr call), then use this type to call make_ssa_name if things have gone wrong [an uninitialized SSA name may cause fewer downstream issues than an error_mark_node].
[Bug target/115408] regression between gcc 13.3.0 and 14.1.0 using -mips16 and -minterlink-mips16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115408 --- Comment #9 from gagan sidhu (broly) --- Created attachment 58452 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58452&action=edit curl failure this is not gd guysss :
[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include since r14-5836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
Lewis Hyatt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-06-17
Summary|[14/15 Regression] ICE when |[14/15 Regression] ICE when
|including a PCH via |including a PCH via
|compiler option -include|compiler option -include
||since r14-5836
--- Comment #7 from Lewis Hyatt ---
OK I see now. For the case of a PCH combined with -include it is a regression
in GCC 14 caused by r14-5836. I think any platform that does not make use of
the stdc-predef.h preinclude will be affected (including MinGW).
The assert added in r14-5836 should not be failing, but it is failing due to an
oversight in r14-2893. This was a new feature for GCC 14 that made #pragma work
during preprocessing, which required the creation of a parser object in
preprocess-only mode.
I will test this patch that should fix it:
=
diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index faaf9ee6350..a09a0518c52 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1296,8 +1296,8 @@ c_common_init (void)
if (flag_preprocess_only)
{
- c_finish_options ();
c_init_preprocess ();
+ c_finish_options ();
preprocess_file (parse_in);
return false;
}
=
The problem is that c_finish_options() will also include the first
command-line- specified include file. On glibc platforms, this is always the
stdc-predef.h preinclude and then things work. In the absence of a preinclude,
it will include the first file requested with -include. If that file triggers a
PCH load, then we hit the code path introduced in r14-5836; after the PCH is
loaded, we reinitialize the parser. But in this case we have not called
c_init_preprocess() yet, so when we do call it afterward, the parser already
exists and so the assert fails.
The above patch should make things right, I am testing it now and it should get
into GCC 14.2. You could add it to the list of MinGW-specific patches for
WinLibs and MSYS2 in the meantime too. It's preferable to commenting out the
assert, although that workaround probably does work fine at the moment as well.
[Bug c/86869] ICE when taking address of array member of __memx struct pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86869 Georg-Johann Lay changed: What|Removed |Added Target Milestone|14.0|14.1
[Bug rtl-optimization/115523] [avr] Remove SFmode insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115523 --- Comment #3 from Georg-Johann Lay --- Andrew, in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243#c2 you wrote that the issue is going to be fixed for RISC-V. You have a PR for that, and what's the state of it?
[Bug rtl-optimization/115523] [avr] Remove SFmode insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115523 --- Comment #4 from Andrew Pinski --- (In reply to Georg-Johann Lay from comment #3) > Andrew, in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243#c2 you wrote > that the issue is going to be fixed for RISC-V. You have a PR for that, and > what's the state of it? I am not 100% sure if this is the latest version of the patch set though, but it was posted to the gcc-patches@ list in late May: https://inbox.sourceware.org/gcc-patches/20240512225738.528917-2-juzhe.zh...@rivai.ai/
[Bug target/111343] [SH] Including in C++23 causes an ICE with -m4-single-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111343 --- Comment #4 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8584c98f370cd91647c184ce58141508ca478a12 commit r15-1380-g8584c98f370cd91647c184ce58141508ca478a12 Author: Jakub Jelinek Date: Mon Jun 17 18:53:21 2024 +0200 c++: Fix up floating point conversion rank comparison for _Float32 and float if float/double are same size [PR115511] On AVR and SH with some options sizeof (float) == sizeof (double) and the 2 types have the same set of values. http://eel.is/c++draft/conv.rank#2.2 for this says that double still has bigger rank than float and http://eel.is/c++draft/conv.rank#2.2 says that extended type with the same set of values as more than one standard floating point type shall have the same rank as double. I've implemented the latter rule as if (cnt > 1 && mv2 == long_double_type_node) return -2; with the _Float64/double/long double case having same mode case (various targets with -mlong-double-64) in mind. But never thought there are actually targets where float and double are the same, that needs handling too, if cnt > 1 (that is the extended type mv1 has same set of values as 2 or 3 of float/double/long double) and mv2 is float, we need to return 2, because mv1 in that case should have same rank as double and double has bigger rank than float. 2024-06-17 Jakub Jelinek PR target/111343 PR c++/115511 * typeck.cc (cp_compare_floating_point_conversion_ranks): If an extended floating point type mv1 has same set of values as more than one standard floating point type and mv2 is float, return 2. * g++.dg/cpp23/ext-floating18.C: New test.
[Bug c++/115511] ICE on ambigous overload for _Float32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115511 --- Comment #6 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8584c98f370cd91647c184ce58141508ca478a12 commit r15-1380-g8584c98f370cd91647c184ce58141508ca478a12 Author: Jakub Jelinek Date: Mon Jun 17 18:53:21 2024 +0200 c++: Fix up floating point conversion rank comparison for _Float32 and float if float/double are same size [PR115511] On AVR and SH with some options sizeof (float) == sizeof (double) and the 2 types have the same set of values. http://eel.is/c++draft/conv.rank#2.2 for this says that double still has bigger rank than float and http://eel.is/c++draft/conv.rank#2.2 says that extended type with the same set of values as more than one standard floating point type shall have the same rank as double. I've implemented the latter rule as if (cnt > 1 && mv2 == long_double_type_node) return -2; with the _Float64/double/long double case having same mode case (various targets with -mlong-double-64) in mind. But never thought there are actually targets where float and double are the same, that needs handling too, if cnt > 1 (that is the extended type mv1 has same set of values as 2 or 3 of float/double/long double) and mv2 is float, we need to return 2, because mv1 in that case should have same rank as double and double has bigger rank than float. 2024-06-17 Jakub Jelinek PR target/111343 PR c++/115511 * typeck.cc (cp_compare_floating_point_conversion_ranks): If an extended floating point type mv1 has same set of values as more than one standard floating point type and mv2 is float, return 2. * g++.dg/cpp23/ext-floating18.C: New test.
[Bug rtl-optimization/115523] [avr] Remove SFmode insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115523 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > I am not 100% sure if this is the latest version of the patch set though, > but it was posted to the gcc-patches@ list in late May: > https://inbox.sourceware.org/gcc-patches/20240512225738.528917-2-juzhe. > zh...@rivai.ai/ Oh this is just the analysis part, the actually code changing part has not been posted yet: > And we will enable register coalsece with subreg liveness tracking in the > followup patches.
[Bug middle-end/47081] Macro usage too clever for localization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47081 --- Comment #7 from Joseph S. Myers --- There no longer seems to be a function "fatal" with a parameter using the msgid naming convention that could be confused with the (non-translating) function called here, which explains why these messages were (correctly) not extracted for translation, but were at the time of this bug report. It seems such a function was removed from collect2 in commit 9e350e99cb9f93ea99216c9c2a40517111636116 (May 2011) and from lto-wrapper in commit ffb1f5ef12ce9d9994e850d87cbe4116a69d8d90 (June 2014).
[Bug target/111343] [SH] Including in C++23 causes an ICE with -m4-single-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111343 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5be6d9d2a9854c05f3c019deb9fe95eca7248140 commit r14-10321-g5be6d9d2a9854c05f3c019deb9fe95eca7248140 Author: Jakub Jelinek Date: Mon Jun 17 18:53:21 2024 +0200 c++: Fix up floating point conversion rank comparison for _Float32 and float if float/double are same size [PR115511] On AVR and SH with some options sizeof (float) == sizeof (double) and the 2 types have the same set of values. http://eel.is/c++draft/conv.rank#2.2 for this says that double still has bigger rank than float and http://eel.is/c++draft/conv.rank#2.2 says that extended type with the same set of values as more than one standard floating point type shall have the same rank as double. I've implemented the latter rule as if (cnt > 1 && mv2 == long_double_type_node) return -2; with the _Float64/double/long double case having same mode case (various targets with -mlong-double-64) in mind. But never thought there are actually targets where float and double are the same, that needs handling too, if cnt > 1 (that is the extended type mv1 has same set of values as 2 or 3 of float/double/long double) and mv2 is float, we need to return 2, because mv1 in that case should have same rank as double and double has bigger rank than float. 2024-06-17 Jakub Jelinek PR target/111343 PR c++/115511 * typeck.cc (cp_compare_floating_point_conversion_ranks): If an extended floating point type mv1 has same set of values as more than one standard floating point type and mv2 is float, return 2. * g++.dg/cpp23/ext-floating18.C: New test. (cherry picked from commit 8584c98f370cd91647c184ce58141508ca478a12)
[Bug c++/115511] ICE on ambigous overload for _Float32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115511 --- Comment #7 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5be6d9d2a9854c05f3c019deb9fe95eca7248140 commit r14-10321-g5be6d9d2a9854c05f3c019deb9fe95eca7248140 Author: Jakub Jelinek Date: Mon Jun 17 18:53:21 2024 +0200 c++: Fix up floating point conversion rank comparison for _Float32 and float if float/double are same size [PR115511] On AVR and SH with some options sizeof (float) == sizeof (double) and the 2 types have the same set of values. http://eel.is/c++draft/conv.rank#2.2 for this says that double still has bigger rank than float and http://eel.is/c++draft/conv.rank#2.2 says that extended type with the same set of values as more than one standard floating point type shall have the same rank as double. I've implemented the latter rule as if (cnt > 1 && mv2 == long_double_type_node) return -2; with the _Float64/double/long double case having same mode case (various targets with -mlong-double-64) in mind. But never thought there are actually targets where float and double are the same, that needs handling too, if cnt > 1 (that is the extended type mv1 has same set of values as 2 or 3 of float/double/long double) and mv2 is float, we need to return 2, because mv1 in that case should have same rank as double and double has bigger rank than float. 2024-06-17 Jakub Jelinek PR target/111343 PR c++/115511 * typeck.cc (cp_compare_floating_point_conversion_ranks): If an extended floating point type mv1 has same set of values as more than one standard floating point type and mv2 is float, return 2. * g++.dg/cpp23/ext-floating18.C: New test. (cherry picked from commit 8584c98f370cd91647c184ce58141508ca478a12)
[Bug c++/115511] ICE on ambigous overload for _Float32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115511 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6d0a0c547a6c8425d432129fc90869305fef7bc2 commit r13-8853-g6d0a0c547a6c8425d432129fc90869305fef7bc2 Author: Jakub Jelinek Date: Mon Jun 17 18:53:21 2024 +0200 c++: Fix up floating point conversion rank comparison for _Float32 and float if float/double are same size [PR115511] On AVR and SH with some options sizeof (float) == sizeof (double) and the 2 types have the same set of values. http://eel.is/c++draft/conv.rank#2.2 for this says that double still has bigger rank than float and http://eel.is/c++draft/conv.rank#2.2 says that extended type with the same set of values as more than one standard floating point type shall have the same rank as double. I've implemented the latter rule as if (cnt > 1 && mv2 == long_double_type_node) return -2; with the _Float64/double/long double case having same mode case (various targets with -mlong-double-64) in mind. But never thought there are actually targets where float and double are the same, that needs handling too, if cnt > 1 (that is the extended type mv1 has same set of values as 2 or 3 of float/double/long double) and mv2 is float, we need to return 2, because mv1 in that case should have same rank as double and double has bigger rank than float. 2024-06-17 Jakub Jelinek PR target/111343 PR c++/115511 * typeck.cc (cp_compare_floating_point_conversion_ranks): If an extended floating point type mv1 has same set of values as more than one standard floating point type and mv2 is float, return 2. * g++.dg/cpp23/ext-floating18.C: New test. (cherry picked from commit 8584c98f370cd91647c184ce58141508ca478a12)
[Bug target/111343] [SH] Including in C++23 causes an ICE with -m4-single-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111343 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6d0a0c547a6c8425d432129fc90869305fef7bc2 commit r13-8853-g6d0a0c547a6c8425d432129fc90869305fef7bc2 Author: Jakub Jelinek Date: Mon Jun 17 18:53:21 2024 +0200 c++: Fix up floating point conversion rank comparison for _Float32 and float if float/double are same size [PR115511] On AVR and SH with some options sizeof (float) == sizeof (double) and the 2 types have the same set of values. http://eel.is/c++draft/conv.rank#2.2 for this says that double still has bigger rank than float and http://eel.is/c++draft/conv.rank#2.2 says that extended type with the same set of values as more than one standard floating point type shall have the same rank as double. I've implemented the latter rule as if (cnt > 1 && mv2 == long_double_type_node) return -2; with the _Float64/double/long double case having same mode case (various targets with -mlong-double-64) in mind. But never thought there are actually targets where float and double are the same, that needs handling too, if cnt > 1 (that is the extended type mv1 has same set of values as 2 or 3 of float/double/long double) and mv2 is float, we need to return 2, because mv1 in that case should have same rank as double and double has bigger rank than float. 2024-06-17 Jakub Jelinek PR target/111343 PR c++/115511 * typeck.cc (cp_compare_floating_point_conversion_ranks): If an extended floating point type mv1 has same set of values as more than one standard floating point type and mv2 is float, return 2. * g++.dg/cpp23/ext-floating18.C: New test. (cherry picked from commit 8584c98f370cd91647c184ce58141508ca478a12)
[Bug c/115290] [12/13/14/15 Regression] tree check fail in c_tree_printer, at c/c-objc-common.cc:330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115290 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b63c7d92012f92e0517190cf263d29bbef8a06bf commit r15-1381-gb63c7d92012f92e0517190cf263d29bbef8a06bf Author: Jakub Jelinek Date: Mon Jun 17 19:24:05 2024 +0200 c-family: Fix -Warray-compare warning ICE [PR115290] The warning code uses %D to print the ARRAY_REF first operands. That works in the most common case where those operands are decls, but as can be seen on the following testcase, they can be other expressions with array type. Just changing %D to %E isn't enough, because then the diagnostics can suggest something like note: use '&(x) != 0 ? (int (*)[32])&a : (int (*)[32])&b[0] == &(y) != 0 ? (int (*)[32])&a : (int (*)[32])&b[0]' to compare the addresses which is a bad suggestion, the %E printing doesn't know that the warning code will want to add & before it and [0] after it. So, the following patch adds ()s around the operand as well, but does that only for non-decls, for decls keeps it as &arr[0] like before. 2024-06-17 Jakub Jelinek PR c/115290 * c-warn.cc (do_warn_array_compare): Use %E rather than %D for printing op0 and op1; if those operands aren't decls, also print parens around them. * c-c++-common/Warray-compare-3.c: New test.
[Bug c/115290] [12/13/14/15 Regression] tree check fail in c_tree_printer, at c/c-objc-common.cc:330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115290 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:922648759b034c356e7d5c1ae530bdb6f3d00c62 commit r14-10322-g922648759b034c356e7d5c1ae530bdb6f3d00c62 Author: Jakub Jelinek Date: Mon Jun 17 19:24:05 2024 +0200 c-family: Fix -Warray-compare warning ICE [PR115290] The warning code uses %D to print the ARRAY_REF first operands. That works in the most common case where those operands are decls, but as can be seen on the following testcase, they can be other expressions with array type. Just changing %D to %E isn't enough, because then the diagnostics can suggest something like note: use '&(x) != 0 ? (int (*)[32])&a : (int (*)[32])&b[0] == &(y) != 0 ? (int (*)[32])&a : (int (*)[32])&b[0]' to compare the addresses which is a bad suggestion, the %E printing doesn't know that the warning code will want to add & before it and [0] after it. So, the following patch adds ()s around the operand as well, but does that only for non-decls, for decls keeps it as &arr[0] like before. 2024-06-17 Jakub Jelinek PR c/115290 * c-warn.cc (do_warn_array_compare): Use %E rather than %D for printing op0 and op1; if those operands aren't decls, also print parens around them. * c-c++-common/Warray-compare-3.c: New test. (cherry picked from commit b63c7d92012f92e0517190cf263d29bbef8a06bf)
[Bug c/115290] [12/13/14/15 Regression] tree check fail in c_tree_printer, at c/c-objc-common.cc:330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115290 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:be14e6cf7f2dc23012dfced0a4aff0894fd6ff57 commit r13-8854-gbe14e6cf7f2dc23012dfced0a4aff0894fd6ff57 Author: Jakub Jelinek Date: Mon Jun 17 19:24:05 2024 +0200 c-family: Fix -Warray-compare warning ICE [PR115290] The warning code uses %D to print the ARRAY_REF first operands. That works in the most common case where those operands are decls, but as can be seen on the following testcase, they can be other expressions with array type. Just changing %D to %E isn't enough, because then the diagnostics can suggest something like note: use '&(x) != 0 ? (int (*)[32])&a : (int (*)[32])&b[0] == &(y) != 0 ? (int (*)[32])&a : (int (*)[32])&b[0]' to compare the addresses which is a bad suggestion, the %E printing doesn't know that the warning code will want to add & before it and [0] after it. So, the following patch adds ()s around the operand as well, but does that only for non-decls, for decls keeps it as &arr[0] like before. 2024-06-17 Jakub Jelinek PR c/115290 * c-warn.cc (do_warn_array_compare): Use %E rather than %D for printing op0 and op1; if those operands aren't decls, also print parens around them. * c-c++-common/Warray-compare-3.c: New test. (cherry picked from commit b63c7d92012f92e0517190cf263d29bbef8a06bf)
[Bug c/115290] [12 Regression] tree check fail in c_tree_printer, at c/c-objc-common.cc:330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115290 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12 Regression] tree check |tree check fail in |fail in c_tree_printer, at |c_tree_printer, at |c/c-objc-common.cc:330 |c/c-objc-common.cc:330 | --- Comment #6 from Jakub Jelinek --- Should be fixed for 13.4+/14.2+/15.1+ for now, 12 branch is frozen right now, so it will need to wait for 12.5.
[Bug tree-optimization/115520] Loop vectorization fails when bool variable instead of unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115520 --- Comment #3 from Max S. --- Ok, thanks for the hint with SRA. Know I know how to actually program it. I think the main problem is the warning/error message: > not vectorized: relevant phi not supported: matched_21 = PHI <_20(6), 1(5)> Is there some way to improve this?
[Bug target/115526] New: regression in 14: invalid assember emitted for alpha, "Error: duplicate !tlsgd!62"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
Bug ID: 115526
Summary: regression in 14: invalid assember emitted for alpha,
"Error: duplicate !tlsgd!62"
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dilfridge at gentoo dot org
Target Milestone: ---
Compiling Python 3.12.4 on Gentoo for alpha fails with the following message:
alpha-unknown-linux-gnu-gcc -c -fno-strict-overflow -Wsign-compare -mieee
-DNDEBUG -mieee -pipe -O2 -mcpu=ev4 -fwrapv -std=c11 -Wextra
-Wno-unused-parameter
-Wno-missing-field-initializers -Wstrict-prototypes
-Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal
-I. -I./Include -I/usr/include/ncursesw
-fPIC -DPy_BUILD_CORE -o Python/dtoa.o Python/dtoa.c
{standard input}: Assembler messages:
{standard input}:1773: Error: duplicate !tlsgd!62
make: *** [Makefile:2748: Python/dtoa.o] Error 1
This worked fine with gcc-13 and is now broken with
dilfridge-alpha / # gcc --version
gcc (Gentoo 14.1.1_p20240615 p2) 14.1.1 20240615
[...]
dilfridge-alpha / # as --version
GNU assembler (Gentoo 2.42 p3) 2.42.0
Preprocessed source and assembler source follow.
