[Bug tree-optimization/108406] Missed integer optimization on x86-64 unless -fwrapv is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108406
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||missed-optimization
Last reconfirmed||2023-01-16
--- Comment #1 from Richard Biener ---
Confirmed. With -fwrapv
/* y == XXX_MIN || x < y --> x <= y - 1 */
(simplify
(bit_ior:c (eq:s @1 min_value) (lt:cs @0 @1))
(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
&& TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
(le @0 (minus @1 { build_int_cst (TREE_TYPE (@1), 1); }
triggers. We could with !TYPE_OVERFLOW_WRAPS write the
subtraction in an unsigned type to make it well-defined.
[Bug target/108401] gcc defeats vector constant generation with intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-01-16
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #5 from Richard Biener ---
Confirmed. We expand from
return { 71777214294589695, 71777214294589695, 71777214294589695,
71777214294589695 };
where we could reduce the DImode broadcast to a HImode one (if that exists).
But sure, the x86 backend could implement the intrinsic suggested way to
generate this particular pattern.
I'll also note that -O0 produces quite bad code here.
[Bug target/108396] [12/13 Regression] PPCLE: vec_vsubcuq missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/108401] gcc defeats vector constant generation with intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #4 from Alexander Monakov --- (In reply to Hongtao.liu from comment #3) > > and gcc 12 generates a worse code: > > > > movabs rax, 71777214294589695 > > vmovq xmm1, rax > > vpbroadcastqymm0, xmm1 > > ret > > > > It's on purpose by edafb35bdadf309ebb9d1eddc5549f9e1ad49c09 since > microbenchmark shows moving from imm is faster than memory. But the bug is not asking you to reinstate loading from memory. The bug is asking you to notice that the result can be constructed via cmpeq+psrlw, which is even better than a broadcast (cmpeq with dst same as src is usually a dependency-breaking instruction that does not occupy an execution port).
[Bug c++/108414] template meta programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108414
--- Comment #2 from Евгений Лисицын ---
(In reply to Andrew Pinski from comment #1)
> > using nth_element_t = typename decltype([](const indexed > T>&){return std::type_identity{};}(make_indexer()))::type;
>
> There are some known issue with lambda inside a decltype which seems like
> might be causing issues here ...
interesting that 'typedef' and 'using' have different behavior
[Bug target/108240] [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 Kewen Lin changed: What|Removed |Added Summary|[13 Regression] ICE in |[13 Regression] Error |emit_library_call_value_1 |message missing since |at gcc/calls.cc:4181 since |r13-4894-gacc727cf02a144 |r13-4894-gacc727cf02a144|(then make concealed ICE ||exposed) URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-January ||/609492.html --- Comment #10 from Kewen Lin --- Put the ICE aside, the actual regression here is that for the given option set the expected error message below is missing: f951: Error: ‘-m64’ requires a PowerPC64 cpu But note that we only emit this error message when there is no explicit -m64. The ICE shows up with an explicit option -m64 given without r13-4894 also proves this (since otherwise we see error message first instead of ICE). So to fix the regression itself, we only need to consider the case without any explicit -m64, that's what the proposed patch aims to fix.
[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #9 from Kewen Lin --- I filed one new bug PR108415 for the ICE itself to avoid the confusion here. This ICE is not a regression, it's a latent bug, because: 1) Without the culprit commit r13-4894 (like using r13-4893 or reverting it), if we specify one more explicit option -m64, we can see the exactly same ICE. It's just concealed as we emit error first on Linux without -m64. (r13-4894 changed it not to emit error any more so no error to conceal then). 2) It's even nothing to do with powerpc64 handling, this ICE can be produced on ppc64 Linux with options "-m32 -mcpu=401 -mmodulo", so it's not 64 bit specific (so not powerpc64 handling related either). I put one comment about root cause of this ICE in PR108415.
[Bug c++/108414] template meta programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108414
Andrew Pinski changed:
What|Removed |Added
Keywords||c++-lambda, rejects-valid
--- Comment #1 from Andrew Pinski ---
> using nth_element_t = typename decltype([](const indexed T>&){return std::type_identity{};}(make_indexer()))::type;
There are some known issue with lambda inside a decltype which seems like might
be causing issues here ...
[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415 Kewen Lin changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-January ||/609724.html Ever confirmed|0 |1 Last reconfirmed||2023-01-16 Target Milestone|--- |13.0 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
[Bug target/108415] New: ICE in emit_library_call_value_1 at gcc/calls.cc:4181
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
Bug ID: 108415
Summary: ICE in emit_library_call_value_1 at gcc/calls.cc:4181
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, linkw at gcc dot gnu.org,
marxin at gcc dot gnu.org, segher at gcc dot gnu.org
Depends on: 108240
Target Milestone: ---
Target: powerpc
+++ This bug was initially created as a clone of Bug #108240 +++
For the case
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/minloc_string_1.f90,
with options:
-mmodulo -mcpu=401 -m64 (Linux and the default cpu power8)
Or options:
-m32 -mcpu=401 -mmodulo (Linux BE and the default cpu power8)
we can see the ICE which is exactly as that in PR108240.
This bug is separated from PR108240, as it's a latent bug, the ICE itself is
actually nothing to do with r13-4894 which rework powerpc64 handling.
The root cause is that -mcpu=401 implies soft float and -mmodulo implies
ISA_3_0_MASKS_SERVER
(VSX), they conflicts very much, but this check is too early:
if (!TARGET_HARD_FLOAT)
{
if (rs6000_isa_flags_explicit & OPTION_MASK_VSX)
msg = N_("%<-mvsx%> requires hardware floating point");
else
{
rs6000_isa_flags &= ~ OPTION_MASK_VSX;
rs6000_isa_flags_explicit |= OPTION_MASK_VSX;
}
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
[Bug 108240] [13 Regression] ICE in emit_library_call_value_1 at
gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
[Bug c++/108414] New: template meta programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108414 Bug ID: 108414 Summary: template meta programming Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amewo22370 at gmail dot com Target Milestone: --- Created attachment 54276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54276=edit archive with source code and preprocessed files gcc of version 12.2.0 and linux 5.15.83-1-lts I have attached the source code. If you compile test code with line 36 commented out and line 37 uncommented, then the compiler gives an error. But if you uncomment line 36 and comment out line 37, the compiler compiles the code without errors, but the result is incorrect. Description of the code: template alias 'template using nth_type_t;' must return type with index I, that contains in type list 'T'. Comilator commands: gcc -v -save-temps -std=c++20 -lstdc++ test_line36.cpp -o test_line36 gcc -v -save-temps -std=c++20 -lstdc++ test_line37.cpp -o test_line37 Also added attachments according to bug reporting instructions. Compilation error with 'gcc -v -save-temps -std=c++20 -lstdc++ test_line37.cpp -o test_line37': Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-o' 'test_line37' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE test_line37.cpp -mtune=generic -march=x86-64 -std=c++20 -fpch-preprocess -o test_line37.ii ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../include/c++/12.2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../include/c++/12.2.0/x86_64-pc-linux-gnu /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../include/c++/12.2.0/backward /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-o' 'test_line37' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/cc1plus -fpreprocessed test_line37.ii -quiet -dumpbase test_line37.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -std=c++20 -version -o test_line37.s GNU C++20 (GCC) version 12.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version isl-0.25-GMP warning: MPFR header version 4.1.0-p13 differs from library version 4.1.1-p1. warning: MPC header version 1.2.1 differs from library version 1.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++20 (GCC) version 12.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version isl-0.25-GMP warning: MPFR header version 4.1.0-p13 differs from library version 4.1.1-p1. warning: MPC header version 1.2.1 differs from library version 1.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 402ce889a414e2a3abbbe3146fa0a6cb test_line37.cpp: In substitution of ‘template using nth_type_t = typename nth_type::type [with long unsigned int I = 0; T = type_list]’: test_line37.cpp:49:36: required from here test_line37.cpp:41:7: error: no type named ‘type’ in ‘struct nth_type<0, type_list >’ 41 | using nth_type_t = typename nth_type::type; | ^~ test_line37.cpp: In substitution of ‘template using nth_type_t = typename nth_type::type [with long unsigned int I = 1; T = type_list]’: test_line37.cpp:50:36: required from here test_line37.cpp:41:7: error: no type named ‘type’ in ‘struct nth_type<1, type_list >’ test_line37.cpp: In substitution
[Bug target/108401] gcc defeats vector constant generation with intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #3 from Hongtao.liu --- > and gcc 12 generates a worse code: > > movabs rax, 71777214294589695 > vmovq xmm1, rax > vpbroadcastqymm0, xmm1 > ret > It's on purpose by edafb35bdadf309ebb9d1eddc5549f9e1ad49c09 since microbenchmark shows moving from imm is faster than memory. > In all cases, the compiler flags are: -O3 -march=haswell > > Code on godbolt.org: https://gcc.godbolt.org/z/sfT787PY9 > > I think the compiler should follow the code in intrinsics more closely since > despite the apparent equivalence, the choice of instructions can have > performance implications. The original code that is written by the developer > is better anyway, so it's not clear why the compiler is being so creative in > this case.
[Bug target/108401] gcc defeats vector constant generation with intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401 --- Comment #2 from Andrew Pinski --- r12-1958-gedafb35bdadf30 changed the behavior in GCC 12 to be better ... (see the commit message that it shows it is better than doing a memory load).
[Bug target/108401] gcc defeats vector constant generation with intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401 --- Comment #1 from Andrew Pinski --- >and gcc 12 generates a worse code: it is not worse really; depending on the how fast moving between the register sets is.
[Bug sanitizer/71611] UBSan shows type '' for anonymous named enum is not useful, should should show where the enum was defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71611 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-01-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||diagnostic Summary|UBSan shows type|UBSan shows type |'' for enums based |'' for anonymous |on long |named enum is not useful, ||should should show where ||the enum was defined --- Comment #4 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #1) > Would you prefer instead or ? Yes I would at least.
[Bug libstdc++/108413] copyrights for gcc 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108413 Andrew Pinski changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Andrew Pinski --- Hmm, the automated update copyright script missed libstdc++, I wonder if it missed other directories too
[Bug tree-optimization/104297] MIN_EXPR is not detected for a >= -__INT_MAX__ ? -__INT_MAX__ : a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104297 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-01-16 --- Comment #1 from Andrew Pinski --- a >= -__INT_MAX__ gets turn into: a != -__INT_MAX__ - 1 But we even get: int c = a == -2147483648 ? -2147483648 : -2147483647;
[Bug c++/108413] New: copyrights for gcc 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108413 Bug ID: 108413 Summary: copyrights for gcc 2023 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Copyrights information should be changed to 2023 https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/array Take this as example // Copyright (C) 2007-2022 Free Software Foundation, Inc. should be changed to: // Copyright (C) 2007-2023 Free Software Foundation, Inc.
[Bug c++/104282] Copy elision when initializing a base-class subobject with aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104282 --- Comment #7 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #4) > I think there's any existing bug about this, and it's an open issue in the > ABI PR 98995 .
[Bug rtl-optimization/108412] RISC-V: Negative optimization of GCSE && LOOP INVARIANTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108412 --- Comment #2 from Andrew Pinski --- -fsched-pressure is something definitely to look into for RISCV to improve pre-ra scheduling .
[Bug rtl-optimization/108412] Negative optimization of GCSE && LOOP INVARIANTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108412
--- Comment #1 from JuzheZhong ---
(In reply to JuzheZhong from comment #0)
> Consider such case:
> void f (void * restrict in, void * restrict out, int l, int n, int m)
> {
> int vl = 32;
> for (int i = 0; i < n; i++)
> {
> vint8mf8_t v1 = __riscv_vle8_v_i8mf8 (in + i + 1, vl);
> __riscv_vse8_v_i8mf8 (out + i + 1, v1, vl);
>
> vint8mf8_t v2 = __riscv_vle8_v_i8mf8 (in + i + 2, vl);
> __riscv_vse8_v_i8mf8 (out + i + 2, v2, vl);
>
> vint8mf8_t v3 = __riscv_vle8_v_i8mf8 (in + i + 3, vl);
> __riscv_vse8_v_i8mf8 (out + i + 3, v3, vl);
>
> vint8mf8_t v4 = __riscv_vle8_v_i8mf8 (in + i + 4, vl);
> __riscv_vse8_v_i8mf8 (out + i + 4, v4, vl);
>
> vint8mf8_t v5 = __riscv_vle8_v_i8mf8 (in + i + 5, vl);
> __riscv_vse8_v_i8mf8 (out + i + 5, v5, vl);
>
> vint8mf8_t v6 = __riscv_vle8_v_i8mf8 (in + i + 6, vl);
> __riscv_vse8_v_i8mf8 (out + i + 6, v6, vl);
>
> vint8mf8_t v7 = __riscv_vle8_v_i8mf8 (in + i + 7, vl);
> __riscv_vse8_v_i8mf8 (out + i + 7, v7, vl);
>
> vint8mf8_t v8 = __riscv_vle8_v_i8mf8 (in + i + 8, vl);
> __riscv_vse8_v_i8mf8 (out + i + 8, v8, vl);
>
> vint8mf8_t v9 = __riscv_vle8_v_i8mf8 (in + i + 9, vl);
> __riscv_vse8_v_i8mf8 (out + i + 9, v9, vl);
>
> vint8mf8_t v10 = __riscv_vle8_v_i8mf8 (in + i + 10, vl);
> __riscv_vse8_v_i8mf8 (out + i + 10, v10, vl);
>
> vint8mf8_t v11 = __riscv_vle8_v_i8mf8 (in + i + 11, vl);
> __riscv_vse8_v_i8mf8 (out + i + 11, v11, vl);
>
> vint8mf8_t v12 = __riscv_vle8_v_i8mf8 (in + i + 12, vl);
> __riscv_vse8_v_i8mf8 (out + i + 12, v12, vl);
>
> vint8mf8_t v13 = __riscv_vle8_v_i8mf8 (in + i + 13, vl);
> __riscv_vse8_v_i8mf8 (out + i + 13, v13, vl);
>
> vint8mf8_t v14 = __riscv_vle8_v_i8mf8 (in + i + 14, vl);
> __riscv_vse8_v_i8mf8 (out + i + 14, v14, vl);
> }
> }
>
> -O3 ASM:
> f:
> addisp,sp,-192
> sw a3,28(sp)
> ble a3,zero,.L1
> addia5,a0,1
> sw a5,76(sp)
> addia5,a1,1
> sw a5,80(sp)
> addia5,a0,2
> sw a5,84(sp)
> addia5,a1,2
> sw a5,88(sp)
> addia5,a0,3
> sw a5,92(sp)
> addia5,a1,3
> sw a5,96(sp)
> addia5,a0,4
> sw a5,100(sp)
> addia5,a1,4
> sw a5,104(sp)
> addia5,a0,5
> sw a5,108(sp)
> addia5,a1,5
> sw a5,112(sp)
> addia5,a0,6
> sw a5,116(sp)
> addia5,a1,6
> sw a5,120(sp)
> addia5,a0,7
> sw a5,124(sp)
> addia5,a1,7
> sw a5,128(sp)
> addia5,a0,8
> sw a5,132(sp)
> addia5,a1,8
> sw a5,136(sp)
> addia5,a0,9
> sw a5,140(sp)
> addia5,a1,9
> sw a5,32(sp)
> addia5,a0,10
> sw a5,36(sp)
> addia5,a1,10
> sw a5,40(sp)
> sw s0,188(sp)
> addia5,a0,11
> sw s1,184(sp)
> sw s2,180(sp)
> sw s3,176(sp)
> sw s4,172(sp)
> sw s5,168(sp)
> sw s6,164(sp)
> sw s7,160(sp)
> sw s8,156(sp)
> sw s9,152(sp)
> sw s10,148(sp)
> sw s11,144(sp)
> sw a5,44(sp)
> addia5,a1,11
> sw a5,48(sp)
> addia5,a0,12
> sw a5,52(sp)
> addia5,a1,12
> sw a5,56(sp)
> addia5,a0,13
> sw a5,60(sp)
> addia5,a1,13
> sw a5,64(sp)
> addia5,a0,14
> sw a5,68(sp)
> addia5,a1,14
> sw a5,72(sp)
> li a4,0
> li a5,32
> vsetvli zero,a5,e8,mf8,ta,ma
> .L3:
> lw a3,76(sp)
> lw t2,60(sp)
> add s11,a3,a4
> lw a3,80(sp)
> add t2,t2,a4
> add t0,a3,a4
> lw a3,84(sp)
> add s10,a3,a4
> lw a3,88(sp)
> add t6,a3,a4
> lw a3,92(sp)
> add s9,a3,a4
> lw a3,96(sp)
> add t5,a3,a4
> lw a3,100(sp)
> add s8,a3,a4
> lw a3,104(sp)
> add t4,a3,a4
> lw a3,108(sp)
> add s7,a3,a4
> lw a3,112(sp)
> add t3,a3,a4
> lw a3,116(sp)
> add s6,a3,a4
> lw a3,120(sp)
> add t1,a3,a4
> lw a3,124(sp)
> add s5,a3,a4
> lw a3,128(sp)
> add a7,a3,a4
> lw a3,132(sp)
> add s4,a3,a4
> lw a3,136(sp)
> add a6,a3,a4
> lw a3,140(sp)
> add s3,a3,a4
> lw a3,32(sp)
> add a0,a3,a4
> lw a3,36(sp)
> add s2,a3,a4
> lw a3,40(sp)
> add a1,a3,a4
> lw
[Bug c/108412] New: Negative optimization of GCSE && LOOP INVARIANTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108412
Bug ID: 108412
Summary: Negative optimization of GCSE && LOOP INVARIANTS
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
Consider such case:
void f (void * restrict in, void * restrict out, int l, int n, int m)
{
int vl = 32;
for (int i = 0; i < n; i++)
{
vint8mf8_t v1 = __riscv_vle8_v_i8mf8 (in + i + 1, vl);
__riscv_vse8_v_i8mf8 (out + i + 1, v1, vl);
vint8mf8_t v2 = __riscv_vle8_v_i8mf8 (in + i + 2, vl);
__riscv_vse8_v_i8mf8 (out + i + 2, v2, vl);
vint8mf8_t v3 = __riscv_vle8_v_i8mf8 (in + i + 3, vl);
__riscv_vse8_v_i8mf8 (out + i + 3, v3, vl);
vint8mf8_t v4 = __riscv_vle8_v_i8mf8 (in + i + 4, vl);
__riscv_vse8_v_i8mf8 (out + i + 4, v4, vl);
vint8mf8_t v5 = __riscv_vle8_v_i8mf8 (in + i + 5, vl);
__riscv_vse8_v_i8mf8 (out + i + 5, v5, vl);
vint8mf8_t v6 = __riscv_vle8_v_i8mf8 (in + i + 6, vl);
__riscv_vse8_v_i8mf8 (out + i + 6, v6, vl);
vint8mf8_t v7 = __riscv_vle8_v_i8mf8 (in + i + 7, vl);
__riscv_vse8_v_i8mf8 (out + i + 7, v7, vl);
vint8mf8_t v8 = __riscv_vle8_v_i8mf8 (in + i + 8, vl);
__riscv_vse8_v_i8mf8 (out + i + 8, v8, vl);
vint8mf8_t v9 = __riscv_vle8_v_i8mf8 (in + i + 9, vl);
__riscv_vse8_v_i8mf8 (out + i + 9, v9, vl);
vint8mf8_t v10 = __riscv_vle8_v_i8mf8 (in + i + 10, vl);
__riscv_vse8_v_i8mf8 (out + i + 10, v10, vl);
vint8mf8_t v11 = __riscv_vle8_v_i8mf8 (in + i + 11, vl);
__riscv_vse8_v_i8mf8 (out + i + 11, v11, vl);
vint8mf8_t v12 = __riscv_vle8_v_i8mf8 (in + i + 12, vl);
__riscv_vse8_v_i8mf8 (out + i + 12, v12, vl);
vint8mf8_t v13 = __riscv_vle8_v_i8mf8 (in + i + 13, vl);
__riscv_vse8_v_i8mf8 (out + i + 13, v13, vl);
vint8mf8_t v14 = __riscv_vle8_v_i8mf8 (in + i + 14, vl);
__riscv_vse8_v_i8mf8 (out + i + 14, v14, vl);
}
}
-O3 ASM:
f:
addisp,sp,-192
sw a3,28(sp)
ble a3,zero,.L1
addia5,a0,1
sw a5,76(sp)
addia5,a1,1
sw a5,80(sp)
addia5,a0,2
sw a5,84(sp)
addia5,a1,2
sw a5,88(sp)
addia5,a0,3
sw a5,92(sp)
addia5,a1,3
sw a5,96(sp)
addia5,a0,4
sw a5,100(sp)
addia5,a1,4
sw a5,104(sp)
addia5,a0,5
sw a5,108(sp)
addia5,a1,5
sw a5,112(sp)
addia5,a0,6
sw a5,116(sp)
addia5,a1,6
sw a5,120(sp)
addia5,a0,7
sw a5,124(sp)
addia5,a1,7
sw a5,128(sp)
addia5,a0,8
sw a5,132(sp)
addia5,a1,8
sw a5,136(sp)
addia5,a0,9
sw a5,140(sp)
addia5,a1,9
sw a5,32(sp)
addia5,a0,10
sw a5,36(sp)
addia5,a1,10
sw a5,40(sp)
sw s0,188(sp)
addia5,a0,11
sw s1,184(sp)
sw s2,180(sp)
sw s3,176(sp)
sw s4,172(sp)
sw s5,168(sp)
sw s6,164(sp)
sw s7,160(sp)
sw s8,156(sp)
sw s9,152(sp)
sw s10,148(sp)
sw s11,144(sp)
sw a5,44(sp)
addia5,a1,11
sw a5,48(sp)
addia5,a0,12
sw a5,52(sp)
addia5,a1,12
sw a5,56(sp)
addia5,a0,13
sw a5,60(sp)
addia5,a1,13
sw a5,64(sp)
addia5,a0,14
sw a5,68(sp)
addia5,a1,14
sw a5,72(sp)
li a4,0
li a5,32
vsetvli zero,a5,e8,mf8,ta,ma
.L3:
lw a3,76(sp)
lw t2,60(sp)
add s11,a3,a4
lw a3,80(sp)
add t2,t2,a4
add t0,a3,a4
lw a3,84(sp)
add s10,a3,a4
lw a3,88(sp)
add t6,a3,a4
lw a3,92(sp)
add s9,a3,a4
lw a3,96(sp)
add t5,a3,a4
lw a3,100(sp)
add s8,a3,a4
lw a3,104(sp)
add t4,a3,a4
lw a3,108(sp)
add s7,a3,a4
lw a3,112(sp)
add t3,a3,a4
lw a3,116(sp)
add s6,a3,a4
lw a3,120(sp)
add t1,a3,a4
lw a3,124(sp)
add s5,a3,a4
lw a3,128(sp)
add a7,a3,a4
lw a3,132(sp)
add s4,a3,a4
lw a3,136(sp)
add a6,a3,a4
lw a3,140(sp)
[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 --- Comment #7 from Jonathan Wakely --- (In reply to Matthijs Kooijman from comment #6) > Ah, IIUC your patch does not treat -fno-exceptions specially, but just adds > a shortcut for the nothrow new version to skip calling regular new version > if it has not been replaced. In a normal build, that saves throw/catch > overhead, and in a no-exceptions build that prevents the abort associated > with that throw. Clever! Right. > One corner case seems to be when the regular new version is replaced in a > no-exceptions build, but in that case that replacement has no way to signal > failure anyway, and if needed a user can just also replace the nothrow > version. If the regular version has been replaced, we have to call it (and handle possible exceptions) because we can't know what it does, so calling malloc directly would not be safe. So yes, users who want to replace new but don't want exceptions involved in the nothrow new path just need to replace both forms. That's true already today, and my patch wouldn't change it.
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279 --- Comment #16 from Michael_S --- (In reply to Jakub Jelinek from comment #15) > libquadmath is not needed nor useful on aarch64-linux, because long double > type there is already IEEE 754 quad. That's good to know. Thank you. If you are here I have one more somewhat related question: is IEEE binary128 arithmetic really not supported under ARMv7 or, like in the case above, it is supported, but not under one of common names (__float128/_Float128) ? And if it is not supported then why? If I had to peek one 32-bit architecture to support then it certainly would be ARMv7, the most used 32-bit architecture in the world that probably outsells the next one by order of magnitude.
[Bug modula2/108404] M2RTS_Halt fails with a segv (it should emit a diagnostic and exit).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108404
--- Comment #1 from Gaius Mulley ---
Ah the ARRAY OF CHAR is passed as: struct { char *contents; unsigned int high
}.
(Even if VAR or non VAR). The effect of non VAR is for the callee to take a
copy.
Essentially if RTco calls halt it should:
struct { char *contents, unsigned int high } file_aoc, desc_aoc, func_aoc ;
file_aoc.contents = __FILE__;
file_aoc.high = strlen (file_aoc.contents) -1; /* the last legal indice of the
array. */
/* same for desc_aoc, func_aoc. */
Halt (file_aoc, __LINE__, desc_aoc, func_aoc)
[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595 --- Comment #9 from Steve Kargl --- On Sun, Jan 15, 2023 at 08:07:16PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595 > > --- Comment #8 from Jerry DeLisle --- > I started to do some variations on the z1.f90 case: > > program p >complex, parameter :: x(0) = 2 x is a zero-sized array. program p complex, parameter :: x(0) = 2 print *, size(x) end program p
[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
--- Comment #8 from Jerry DeLisle ---
I started to do some variations on the z1.f90 case:
program p
complex, parameter :: x(0) = 2
!data x%im /3.0/
print *, x
end
Running this prints a blank line;
Looking at the -fdump-tree-original shows:
parm.1.span = 8;
parm.1.dtype = {.elem_len=8, .rank=1, .type=4};
parm.1.dim[0].lbound = 1;
parm.1.dim[0].ubound = 0;
parm.1.dim[0].stride = 1;
parm.1.data = (void *) [0];
parm.1.offset = -1;
Is it valid to have an ubound less than the lbound?
program p
complex, parameter :: x(1) = 2
!data x%im /3.0/
print *, x
end
The z2 case prints what is expected. It looks like we need to catch something
in the parameter declaration before the data statement so that it is not
garbage later.
.. to be continued ..
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279 --- Comment #15 from Jakub Jelinek --- libquadmath is not needed nor useful on aarch64-linux, because long double type there is already IEEE 754 quad.
[Bug tree-optimization/108402] False positive Wuninitialized with ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402 --- Comment #5 from Andrew Pinski --- (In reply to pefoley2 from comment #4) > Yeah, I had a lot of trouble getting creduce to do something sane with the > testcase that didn't wind up just deleting everything. You could compress it using either bzip or gzip (or xz). We are ok with the file being compressed if it goes over the attachment size limit. > It should also be reproducible via make O=um ARCH=um allyesconfig > drivers/spi/spi-stm32-qspi.o in a 6.1 linux kernel tree. from https://gcc.gnu.org/bugs/ (What we do not want): ``` The location (URL) of the package that failed to build (we won't download it, anyway, since you've already given us what we need to duplicate the bug, haven't you? :-) ```
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279 --- Comment #14 from Thomas Koenig --- Seems that libquadmath is not built on that particular Linux/CPU variant, for whatever reason. At last I cannot find any '*quadmath* files in the build directory. /proc/cpuinfo tells me that processor : 0 BogoMIPS: 48.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm ssbs sb paca pacg dcpodp flagm2 frint CPU implementer : 0x61 CPU architecture: 8 CPU variant : 0x1 CPU part: 0x022 CPU revision: 1 [...] and uname -a is Linux gcc103.fsffrance.org 6.0.0-rc5-asahi-1-gc62bd3fe430f #1 SMP Sun Sep 18 18:07:57 CEST 2022 aarch64 GNU/Linux So much for testing on Apple silicon.
[Bug d/108408] libphobos: Support building on *-*-cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108408
Corinna changed:
What|Removed |Added
CC||vinschen at redhat dot com
--- Comment #1 from Corinna ---
(In reply to nightstrike from comment #0)
> I should clarify that I'm unfamiliar with D, so what I'm putting here
Ditto, so I can only comment on the correctness of copying the
datastructures into D-land...
> [...]
> +struct __locale_t {
> +char[7][31 + 1] categories; // #define _LC_LAST 7, #define
> ENCODING_LEN 31
> +extern (C) int function(_reent*, char*, wchar, _mbstate_t*) wctomb;
> +extern (C) int function(_reent*, wchar*, const char*, size_t,
> _mbstate_t*) mbtowc;
> +int cjk_lang;
> +char* ctype_ptr;
> +lconv lconv_member; // name collision
> +// #ifndef __HAVE_LOCALE_INFO__ // FIXME: Which path is enabled on
> cygwin by default?
Cygwin has __HAVE_LOCALE_INFO__, so the else branch is required/
> +char[2] mb_cur_max;
> +char[31 + 1] ctype_codeset; // #define ENCODING_LEN 31
> +char[31 + 1] message_codeset; // #define ENCODING_LEN 31
> +// #else
> +// struct __lc_cats lc_cat[7]; // #define _LC_LAST 7
> +// #endif
> +}
> +
> +struct _Bigint {
> +_Bigint* _next;
> +int _k;
> +int _maxwds;
> +int _sign;
> +int _wds;
> +ulong[1] _x;
> +}
> +
> +struct _reent {
> +int _errno;
> +
> +__sFILE64* _stdin;
> +__sFILE64* _stdout;
> +__sFILE64* _stderr;
> +
> +int _inc;
> +char[25] _emergency; // #define _REENT_EMERGENCY_SIZE 25
> +
> +// #ifdef _REENT_BACKWARD_BINARY_COMPAT int _reserved_1;
_REENT_BACKWARD_BINARY_COMPAT is set on Cygwin because we must not change
size and layout of this structure. Other targets don't support dynamic
linking so they are interested in saving space more than sticking to
binary compat.
Does D fail to support a preprocessor and including header file? That
would make this so much more reader-friendly...
> +__locale_t* _locale;
> +// #ifdef _REENT_BACKWARD_BINARY_COMPAT int _reserved_0;
> +
> +extern (C) void function(_reent*) __cleanup;
> +
> +_Bigint* _p5s;
> +int _result_k;
> +_Bigint* _result;
> +_Bigint** _freelist;
> +
> +int _cvtlen;
> +char*_cvtbuf;
> +
> +union U {
> +struct {
> +// #ifdef _REENT_BACKWARD_BINARY_COMPAT unsigned int
> _reserved_2;
> +char* _strtok_last;
> +char[26] _asctime_buf; // #define _REENT_ASCTIME_SIZE 26
> +__tm _localtime_buf;
> +int _gamma_signgam;
> +ulong _rand_next; // __extension__ unsigned long long
> +_rand48 _r48;
> +_mbstate_t _mblen_state;
> +_mbstate_t _mbtowc_state;
> +_mbstate_t _wctomb_state;
> +char[8] _l64a_buf;
> +char[24] _signal_buf; // #define _REENT_SIGNAL_SIZE 24
> +int _getdate_err;
> +_mbstate_t _mbrlen_state;
> +_mbstate_t _mbrtowc_state;
> +_mbstate_t _mbsrtowcs_state;
> +_mbstate_t _wcrtomb_state;
> +_mbstate_t _wcsrtombs_state;
> +int _h_errno;
> +} // _reent;
> +// #ifdef _REENT_BACKWARD_BINARY_COMPAT
> +struct {
> +char*[30] _reserved_3; // unsigned
> +uint[30] _reserved_4;
> +} // _reserved_5;
> +// #endif
> +} // _new;
> +
> +// #ifdef _REENT_BACKWARD_BINARY_COMPAT struct _atexit *_reserved_6;
> +// #ifdef _REENT_BACKWARD_BINARY_COMPAT struct _atexit _reserved_7;
> +extern (C) void function(int)* _sig_func;
> +}
> +
> +struct __sFILE64 {
> +char* _p; // unsigned char
> +int _r;
> +int _w;
> +short _flags;
> +short _file;
> +__sbuf _bf;
> +int _lbfsize;
> +// ifdef _REENT_SMALL _reent* _data;
> +void* _cookie;
> +extern (C) int function(_reent*, void*, char*, int) _read;
> +extern (C) int function(_reent*, void*, const char*, int) _write;
> +extern (C) _fpos_t function(_reent*, void*, _fpos_t, int) _seek;
> +extern (C) int function(_reent*, void*) _close;
> +
> +__sbuf _ub;
> +char* _up; // unsigned char
> +int _ur;
> +
> +char[3] _ubuf; // unsigned char
> +char[1] _nbuf; // unsigned char
> +
> +__sbuf _lb;
> +
> +int _blksize;
> +int _flags2;
> +
> +_off64_t _offset;
> +extern (C) _fpos64_t function(_reent*, void*,
[Bug tree-optimization/92342] [10/11/12 Regression] a small missed transformation into x?b:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342 Roger Sayle changed: What|Removed |Added Summary|[10/11/12/13 Regression] a |[10/11/12 Regression] a |small missed transformation |small missed transformation |into x?b:0 |into x?b:0 Known to work||13.0 --- Comment #30 from Roger Sayle --- This has now been fixed on mainline (for GCC 13).
[Bug tree-optimization/71343] missed optimization (can't "prove" shift and multiplication equivalence)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71343 Roger Sayle changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |13.0 CC||roger at nextmovesoftware dot com Resolution|--- |FIXED --- Comment #5 from Roger Sayle --- This should now be fixed on mainline.
[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477 --- Comment #6 from Matthijs Kooijman --- Ah, IIUC your patch does not treat -fno-exceptions specially, but just adds a shortcut for the nothrow new version to skip calling regular new version if it has not been replaced. In a normal build, that saves throw/catch overhead, and in a no-exceptions build that prevents the abort associated with that throw. Clever! One corner case seems to be when the regular new version is replaced in a no-exceptions build, but in that case that replacement has no way to signal failure anyway, and if needed a user can just also replace the nothrow version. I can't comment on the details of the patch wrt aliases and preprocessor stuff, but the approach and the gist of the code looks ok to me.
[Bug tree-optimization/108402] False positive Wuninitialized with ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402 --- Comment #4 from pefoley2 at pefoley dot com --- Yeah, I had a lot of trouble getting creduce to do something sane with the testcase that didn't wind up just deleting everything. I wound up trying delta, which got me a smaller, but still enormous repo. It should also be reproducible via make O=um ARCH=um allyesconfig drivers/spi/spi-stm32-qspi.o in a 6.1 linux kernel tree.
[Bug tree-optimization/108402] False positive Wuninitialized with ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402 pefoley2 at pefoley dot com changed: What|Removed |Added Attachment #54271|0 |1 is obsolete|| --- Comment #3 from pefoley2 at pefoley dot com --- Created attachment 54275 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54275=edit Partially reduced testcase Testcase reduced via creduce/delta to the point that it fits in the attachment size.
[Bug libstdc++/108288] Deadlock when using -fno-elide-constructor + -D_GLIBCXX_DEBUG=1 + -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288 --- Comment #11 from CVS Commits --- The master branch has been updated by Francois Dumont : https://gcc.gnu.org/g:5c9833d878602de20043a5b74e4c6acd33d5fb3e commit r13-5180-g5c9833d878602de20043a5b74e4c6acd33d5fb3e Author: François Dumont Date: Mon Jan 9 18:48:30 2023 +0100 libstdc++: [_GLIBCXX_DEBUG] Complete deadlock fix on safe iterators [PR108288] Complete fix on all _Safe_iterator post-increment and post-decrement implementations and on _Safe_local_iterator. libstdc++-v3/ChangeLog: PR libstdc++/108288 * include/debug/safe_iterator.h (_Safe_iterator<>::operator++(int)): Extend deadlock fix to other iterator category. (_Safe_iterator<>::operator--(int)): Likewise. * include/debug/safe_local_iterator.h (_Safe_local_iterator<>::operator++(int)): Fix deadlock. * testsuite/util/debug/unordered_checks.h (invalid_local_iterator_pre_increment): New. (invalid_local_iterator_post_increment): New. * testsuite/23_containers/unordered_map/debug/invalid_local_iterator_post_increment_neg.cc: New test. * testsuite/23_containers/unordered_map/debug/invalid_local_iterator_pre_increment_neg.cc: New test.
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 --- Comment #31 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:844190af178c210a6aff6b7eb4dd8c6a49210ff9 commit r13-5179-g844190af178c210a6aff6b7eb4dd8c6a49210ff9 Author: Aldy Hernandez Date: Tue Jan 10 10:57:16 2023 +0100 [PR107608] [range-ops] Avoid folding into INF when flag_trapping_math. As discussed in the PR, for trapping math, do not fold overflowing operations into +-INF as doing so could elide a trap. There is a minor adjustment to known_isinf() where it was mistakenly returning true for an [infinity U NAN], whereas it should only return true when the range is exclusively +INF or -INF. This is benign, as there were no users of known_isinf up to now. Tested on x86-64 Linux. I also ran the glibc testsuite (git sources) on x86-64 and this patch fixes: -FAIL: math/test-double-lgamma -FAIL: math/test-double-log1p -FAIL: math/test-float-lgamma -FAIL: math/test-float-log1p -FAIL: math/test-float128-catan -FAIL: math/test-float128-catanh -FAIL: math/test-float128-lgamma -FAIL: math/test-float128-log -FAIL: math/test-float128-log1p -FAIL: math/test-float128-y0 -FAIL: math/test-float128-y1 -FAIL: math/test-float32-lgamma -FAIL: math/test-float32-log1p -FAIL: math/test-float32x-lgamma -FAIL: math/test-float32x-log1p -FAIL: math/test-float64-lgamma -FAIL: math/test-float64-log1p -FAIL: math/test-float64x-lgamma -FAIL: math/test-ldouble-lgamma PR tree-optimization/107608 gcc/ChangeLog: * range-op-float.cc (range_operator_float::fold_range): Avoid folding into INF when flag_trapping_math. * value-range.h (frange::known_isinf): Return false for possible NANs.
[Bug libgcc/108279] Improved speed for float128 routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279 --- Comment #13 from Thomas Koenig --- I tried compiling your tests on Apple silicon using Asahi Linux, but without success. A first step was rather easy; replacing __float128 by _Float128 was required. I then bootstrapped gcc on that machine and added the (private) include path for , and am now hitting missing __float128 in quadmath.h. Not sure how to proceed from here. The machine is gcc103.fsffrance.org, by the way, of the GCC compile farm.
[Bug libstdc++/108409] std::chrono::current_zone() doesn't work on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108409 --- Comment #6 from Jonathan Wakely --- https://learn.microsoft.com/en-gb/windows/win32/api/timezoneapi/nf-timezoneapi-getdynamictimezoneinformation?redirectedfrom=MSDN has the same problem. I guess this is why MSVC uses ICU for its std::chrono::tzdb implementation.
[Bug libstdc++/108409] std::chrono::current_zone() doesn't work on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108409 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > The current code doesn't work on Windows either. https://learn.microsoft.com/en-us/windows/win32/api/timezoneapi/nf-timezoneapi-gettimezoneinformation only gives us the abbreviated names of the standard and daylight zones, e.g. "EST" and "EDT". But those names are not unique and cannot be used to map to a time zone, as the C++ standard points out in [time.zone.info.sys] p6: "Abbreviations are not unique among the time_zones, and so one cannot reliably map abbreviations back to a time_zone and UTC offset."
[Bug libstdc++/108409] std::chrono::current_zone() doesn't work on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108409 --- Comment #4 from Jonathan Wakely --- The current code doesn't work on Windows either.
[Bug modula2/108121] Failing tests on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108121 --- Comment #5 from Gaius Mulley --- Created attachment 54274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54274=edit Bugfix for arraybool For what it is worth here is the bugfix for the bug exposed by arraybool.mod. Bootstrapped on x86_64 and ppcle64
[Bug modula2/108121] Failing tests on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108121 --- Comment #4 from Gaius Mulley --- I believe the bug exposed by arraybool.mod has been fixed. M2Quads BuildNot resulted in an uninitialized tokenpos.
[Bug target/108411] [13 Regression] ICEs in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||clyon at gcc dot gnu.org Target Milestone|--- |13.0 Last reconfirmed||2023-01-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug target/108411] New: [13 Regression] ICEs in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108411
Bug ID: 108411
Summary: [13 Regression] ICEs in aarch64_layout_arg
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
r13-5124-g6610daa1cfb75b72500c2
introduced some ICEs:
+FAIL: gcc.target/aarch64/sve/pcs/struct_3_128.c -march=armv8.2-a+sve (internal
compiler error: in aarch64_layout_arg, at config/aarch64/aarch64.cc:7696)
+FAIL: gcc.target/aarch64/sve/pcs/struct_3_128.c -march=armv8.2-a+sve (test for
excess errors)
+FAIL: gcc.target/aarch64/sve/pcs/struct_3_256.c -march=armv8.2-a+sve (internal
compiler error: in aarch64_layout_arg, at config/aarch64/aarch64.cc:7696)
+FAIL: gcc.target/aarch64/sve/pcs/struct_3_256.c -march=armv8.2-a+sve (test for
excess errors)
+FAIL: gcc.target/aarch64/sve/pcs/struct_3_512.c -march=armv8.2-a+sve (internal
compiler error: in aarch64_layout_arg, at config/aarch64/aarch64.cc:7696)
+FAIL: gcc.target/aarch64/sve/pcs/struct_3_512.c -march=armv8.2-a+sve (test for
excess errors)
as well as (with -fstack-protector-all)
+FAIL: g++.target/aarch64/bitfield-abi-warning-align16-O2.C
scan-assembler-times and\\tw0, w1, 1 10
+FAIL: g++.target/aarch64/bitfield-abi-warning-align32-O2.C
scan-assembler-times and\\tw0, w1, 1 10
+FAIL: g++.target/aarch64/bitfield-abi-warning-align8-O2.C scan-assembler-times
and\\tw0, w0, 1 11
+FAIL: g++.target/aarch64/bitfield-abi-warning-align8-O2.C scan-assembler-times
and\\tw0, w1, 1 18
regressions.
For the latter (can be seen e.g. when configured --enable-default-ssp or when
testing with RUNTESTFLAGS=--target_board=unix/-fstack-protector-all) I think
just adding explicit -fno-stack-protector to the test would be enough.
The former can be reduced e.g. to
typedef __SVInt32_t fixed_int32_t __attribute__ ((arm_sve_vector_bits (128)));
struct A { fixed_int32_t a[3] __attribute__((aligned((128 / 8) * 2))); };
void foo (struct A x) {}
with -march=armv8.2-a+sve -O -msve-vector-bits=128
I wonder if just the assertion shouldn't be dropped, user alignment can be
arbitrarily large.
[Bug tree-optimization/108398] tree-object-size trips up with pointer arithmetic if an intermediate result is an invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398 --- Comment #10 from Yann Droneaud --- (In reply to Jakub Jelinek from comment #8) > -fsanitize=undefined with no diagnostics doesn't mean code is UB free. This is a pity, it would have help users do diagnose the issue in their code.
