[Bug target/113871] psrlq is not used for PERM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
--- Comment #2 from Andrew Pinski ---
Note `PERM<{0},a,{1,2,3,4}>` should be handled too, that means defining
`vec_shl_` patterns too.
[Bug target/113872] New: PERM<{0},a,{3,4,5,6}> is not producing SHL (for little-endian) and USHR for big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113872
Bug ID: 113872
Summary: PERM<{0},a,{3,4,5,6}> is not producing SHL (for
little-endian) and USHR for big-endian
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Take:
```
#define vect64 __attribute__((vector_size(8)))
void f(vect64 unsigned short *a)
{
*a = __builtin_shufflevector((vect64 unsigned short){0},*a, 3,4,5,6);
}
```
This should produce:
```
ldr d31, [x0]
shl d31, d31, 16
str d31, [x0]
```
For little-endian
I suspect this is just a missing `vec_shl_M` pattern.
[Bug target/113871] psrlq is not used for PERM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/81393 --- Comment #1 from Andrew Pinski --- Note LLVM is not able to handle this for aarch64; file https://github.com/llvm/llvm-project/issues/81393 for that.
[Bug target/113871] New: psrlq is not used for PERM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
Bug ID: 113871
Summary: psrlq is not used for PERM
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
Take:
```
#define vect64 __attribute__((vector_size(8)))
void f(vect64unsigned short *a)
{
*a = __builtin_shufflevector(*a,(vect64 unsigned short){0}, 1,2,3, 4);
}
```
This should just produce:
```
movq (%rdi), %xmm0
psrlq $16, %xmm0, %xmm0
movq %xmm0, (%rdi)
retq
```
But instead we get:
```
movzwl 6(%rdi), %eax
movzwl 4(%rdi), %edx
salq$16, %rax
orq %rdx, %rax
movzwl 2(%rdi), %edx
salq$16, %rax
orq %rdx, %rax
movq%rax, (%rdi)
ret
```
With AVX enabled we get slightly better:
```
f:
.LFB0:
.cfi_startproc
vmovq (%rdi), %xmm0
vpxor %xmm1, %xmm1, %xmm1
vpshufb .LC1(%rip), %xmm1, %xmm1
vpshufb .LC0(%rip), %xmm0, %xmm0
vpor%xmm1, %xmm0, %xmm0
vmovq %xmm0, (%rdi)
ret
```
Note LLVM is able to catch this for x86_64 (for aarch64, GCC is able to use
`ushr d31, d31, 16` while LLVM does not).
I suspect vec_shr_ pattern is missing and once it is added, it will just
work.
[Bug target/113870] Add V2HF support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113870 Andrew Pinski changed: What|Removed |Added Depends on||113869 --- Comment #1 from Andrew Pinski --- Oh this depends on PR 113869 for the V4HF->V4SF pattern too :). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113869 [Bug 113869] V4HF->V4SF pattern seems to be missing
[Bug target/113870] New: Add V2HF support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113870
Bug ID: 113870
Summary: Add V2HF support
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Take:
```
void f( _Float16 * __restrict a, float * __restrict b)
{
b[0] = a[0];
b[1] = a[1];
}
```
We should produce:
```
ldr s0, [x0]
fcvtl v0.4s, v0.4h
str d0, [x1]
ret
```
But this requires V2HF support. I am not 100% sure if this is worth adding.
Adding V2HI and V4QI is worth it though (I have a patch for that).
There are not enough benchmarks that use _Float16 to say if it is worth it or
not.
[Bug target/113869] New: V4HF->V4SF pattern seems to be missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113869
Bug ID: 113869
Summary: V4HF->V4SF pattern seems to be missing
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Take:
```
void f( _Float16 * __restrict a, float * __restrict b)
{
b[0] = a[0];
b[1] = a[1];
b[2] = a[2];
b[3] = a[3];
b+=4;a+=4;
#if 0
b[0] = a[0];
b[1] = a[1];
b[2] = a[2];
b[3] = a[3];
#endif
}
```
The pattern that converts V4HF to V4SF seems be to missing and we don't SLP the
above. We able to handle V8HF to V8SF which does:
```
fcvtl v30.4s, v31.4h
fcvtl2 v31.4s, v31.8h
```
But the first fcvtl is exactly what we want for V4HF->V4SF.
[Bug tree-optimization/113863] [14 Regression] ICE verify_ssa failed with -O3 -msse4.1 since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113863 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-10 Target||aarch64 x86_64 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. Also ICEs at -O3 for aarch64.
[Bug tree-optimization/113863] [14 Regression] ICE verify_ssa failed with -O3 -msse4.1 since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113863 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code CC||pinskia at gcc dot gnu.org Target Milestone|--- |14.0
[Bug ada/113868] New: error: expression function must be enclosed in parentheses.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113868 Bug ID: 113868 Summary: error: expression function must be enclosed in parentheses. Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: p.p11 at orange dot fr CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 57383 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57383=edit Reproducer. $ gcc -c -gnat2022 -gnatl 2020/test_20200521_expr.adb GNAT 13.2.0 1. procedure Test_20200521_expr is 2. 3.type Real is digits 8; 4.type Point is tagged record 5. X, Y : Real := 0.0; 6.end record; 7. 8.--Section_4.3.4_Paragraph_30 9.function Translate (P : Point'Class; X, Y : Real) return Point'Class is 10. (P with delta X => P.X + X, | >>> error: expression function must be enclosed in parentheses 11. Y => P.Y + Y); 12. 13. begin 14.null; 15. end; It is weird as this code comes from AARM 2022 Section_4.3.4_Paragraph_30. See full source code in attachement.
[Bug target/105980] [11 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #13 from Francois-Xavier Coudert --- The new test fails on darwin, with an ICE. Reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111342
[Bug target/111342] ICE for g++.target/i386/pr105980.C on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111342 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-10 Ever confirmed|0 |1
[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 --- Comment #5 from Tobias Burnus --- The runtime issue is now PR113867.
[Bug middle-end/113867] [14 Regression][OpenMP] Wrong code with mapping pointers in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 --- Comment #1 from Tobias Burnus --- Created attachment 57382 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57382=edit Fortran testcase, kind of, as pointer + pointee mapping cannot be split (working) For completeness, a Fortran testcase. (This Testcase works on GCC 13 and mainline.) As in Fortran, 'map(ptr, dt%ptr)' will always attempt to map the pointer and the pointer, it is not possible to split map(s2.p[:N]) // map the pointee map(s2.p, s2.p[:0]) // map the pointer and try pointer attachment as in C/C++. And using 'map(s.p)' will prevent a later inner 'map(s.a,...)' as 's' is already partially mapped. Hence, the aux 'ptr' is used, but that kind of defeats the purpose of this testcase.
[Bug middle-end/113867] New: [14 Regression][OpenMP] Wrong code with mapping pointers in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 Bug ID: 113867 Summary: [14 Regression][OpenMP] Wrong code with mapping pointers in structs Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openmp, wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 57381 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57381=edit Testcase, compile with 'gcc -fopenmp' and run with an offload device Split off from PR113724 which mainly about an ICE. The attached programs work with GCC 13 but fails with mainline. (Requires actual offloading; tried here with nvptx.) Probably due to Julian's mapping patches. With mainline, it fails for 'g()' when executing omp target data map(tofrom: s2.p[:100]) (i.e. GOMP_target_data_ext → gomp_copy_host2dev → gomp_device_copy) with libgomp: cuMemGetAddressRange_v2 error: named symbol not found libgomp: Copying of host object [0x118c500..0x118c690) to dev object [0x7f7e721cae00..0x7f7e721caf90) failed It works using a separate target enter/exit data (i.e. for 'f()'). The mainline dump shows: map(struct:s2 [len: 1]) map(alloc:s2.p [len: 0]) map(tofrom:*_2 [len: 400]) map(attach:s2.p [bias: 0]) I somehow hadn't expected the map(struct:s2 [len: 1]) map(alloc:s2.p [len: 0]) which might or might not be the issue. As it works with 'f()' (i.e. enter/exit data), it might be a red herring (or not).
[Bug fortran/113866] ice in generic_simplify_COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866 kargl at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-02-10 Ever confirmed|0 |1 Priority|P3 |P4 Status|UNCONFIRMED |NEW CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Reduced testcase. module bindcchar contains subroutine bindc_optional(c1, c3) bind(c) character(*), optional :: c1, c3(100) print *, c1(1:3), c3(5)(1:3) end subroutine subroutine not_bindc_optional(c1, c3) character(*), optional :: c1, c3(100) call bindc_optional(c1, c3) end subroutine end module Note, the OPTIONAL attribute is required to cause the ICE. Note, -Wall generates a few warnings. Perhaps, these should be errors. % gfcx -c -Wall fr.f90 fr.f90:5:34: 5 | subroutine bindc_optional(c1, c3) bind(c) | 1 Warning: Variable ‘c1’ at (1) is a dummy argument of the BIND(C) procedure ‘bindc_optional’ but may not be C interoperable [-Wc-binding-type] fr.f90:5:38: 5 | subroutine bindc_optional(c1, c3) bind(c) | 1 Warning: Variable ‘c3’ at (1) is a dummy argument of the BIND(C) procedure ‘bindc_optional’ but may not be C interoperable [-Wc-binding-type] fr.f90:12:36: 12 | call bindc_optional(c1, c3) |1
[Bug fortran/113866] New: ice in generic_simplify_COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866 Bug ID: 113866 Summary: ice in generic_simplify_COND_EXPR Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57380 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57380=edit F90 source code For this F90 source code file: ./Lower/HLFIR/bindc-assumed-length.f90 from the flang testsuite at https://github.com/llvm/llvm-project/tree/main/flang/test when compiled by recent gfortran, does this: est $ ~/gcc/results.20240210.asan.ubsan/bin/gfortran -c -w ./Lower/HLFIR/bindc-assumed-length.f90 ./Lower/HLFIR/bindc-assumed-length.f90:39:29: 39 | call bindc_optional(c1, c3) | 1 internal compiler error: Segmentation fault 0xf57d79 crash_signal(int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317 0x17bdf2f generic_simplify_COND_EXPR(unsigned int, tree_code, tree_node*, tree_node*, tree_node*, tree_node*) /home/dcb38/gcc/working/gcc/generic-match-4.cc:0 0xaecbf8 fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*, tree_node*) Here is a valgrind version of the same gfortran providing some clues: test $ ~/gcc/results.20240210.valgrind/bin/gfortran -c -w ./Lower/HLFIR/bindc-assumed-length.f90 ==3757741== Invalid read of size 2 ==3757741==at 0x17793EF: generic_simplify_COND_EXPR(unsigned int, tree_code, tree_node*, tree_node*, tree_node*, tree_node*) (generic-match-4.cc:10061) ==3757741==by 0xB082BB: fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*, tree_node*) (fold-const.cc:13144)
[Bug fortran/113846] ice in fold_convert_loc, at fold-const.cc:2757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113846 --- Comment #2 from David Binderman --- >From the same flang test suite, the following files seem to crash in the same routine: ./Lower/HLFIR/structure-constructor.f90 ./Lower/HLFIR/convert-mbox-to-value.f90 ./Lower/polymorphic-temp.f90 ./Lower/structure-constructors-alloc-comp.f90 It might be worth making sure any fix for this bug also fixes these four.
[Bug rust/113865] New: FAIL: rust/execute/torture/issue-2187.rs -O0 output pattern test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113865 Bug ID: 113865 Summary: FAIL: rust/execute/torture/issue-2187.rs -O0 output pattern test Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org Target Milestone: --- spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/rust/../../gccrs -B/home/dave/gnu/gcc/objdir64/gcc/testsuite/rust/../../ /home/dave/gnu/gcc/gcc/g cc/testsuite/rust/execute/torture/issue-2187.rs -fdiagnostics-plain-output -frus t-incomplete-and-experimental-compiler-do-not-use -O0 -lm -o ./issue-2187.exe PASS: rust/execute/torture/issue-2187.rs -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:.:/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gc c/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs Execution timeout is: 300 spawn [open ...] L1 L2 PASS: rust/execute/torture/issue-2187.rs -O0 execution test FAIL: rust/execute/torture/issue-2187.rs -O0 output pattern test Output was: L1 L2 Should match: L1 L2 L3 L4
[Bug rust/113864] New: FAIL: rust/debug/chartype.rs scan-assembler 0x10[ \t][^\n\r]* DW_AT_encoding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113864 Bug ID: 113864 Summary: FAIL: rust/debug/chartype.rs scan-assembler 0x10[ \t][^\n\r]* DW_AT_encoding Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org Target Milestone: --- spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/rust/../../gccrs -B/home/dave/gnu/gcc/objdir64/gcc/testsuite/rust/../../ /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/debug/chartype.rs -fdiagnostics-plain-output -frust-incomplete-and-experimental-compiler-do-not-use -w -gdwarf-4 -dA -fno-ident -S -o chartype.s PASS: rust/debug/chartype.rs (test for excess errors) FAIL: rust/debug/chartype.rs scan-assembler 0x10[ \t][^\n\r]* DW_AT_encoding Have following in .s file: .uleb128 0x6; (DIE (0x1e0) DW_TAG_base_type) .byte 0x4 ; DW_AT_byte_size .byte 0x8 ; DW_AT_encoding
[Bug rust/113473] rust/compile/iterators1.rs etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113473 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-10 CC||danglin at gcc dot gnu.org Ever confirmed|0 |1 Target|sparc-sun-solaris2.11 |sparc-sun-solaris2.11 ||hppa64-hp-hpux11.11 --- Comment #1 from John David Anglin --- Same on hppa64-hp-hpux11.11.
[Bug rust/113472] rust/compile/issue-1446.rs FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113472 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-10 CC||danglin at gcc dot gnu.org Target|sparc-sun-solaris2.11 |sparc-sun-solaris2.11 ||hppa64-hp-hpux11.11 Ever confirmed|0 |1 --- Comment #1 from John David Anglin --- Same on hppa64-hp-hpux11.11.
[Bug target/113847] [14 Regression] 10% slowdown of 462.libquantum on AMD Ryzen 7700X and Ryzen 7900X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847 Filip Kastl changed: What|Removed |Added Keywords|needs-bisection | CC||rguenth at gcc dot gnu.org --- Comment #1 from Filip Kastl --- Bisected to g:724b64304ff5c8ac08a913509afd6fde38d7b767 (I did the bisection on Ryzen 7900X)
[Bug rust/107700] Several testsuite failures on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107700 --- Comment #2 from John David Anglin --- Regarding const-issue1440.rs and issue-1432.rs, here are the errors on hppa64-hp-hpux11.11: FAIL: rust/compile/const-issue1440.rs (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/compile/const-issue1440.rs:56:55: error: mismatched types, expected 'u8' but got '()' [E0308] /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/compile/const-issue1440.rs:56:55: error: mismatched types, expected 'u16' but got '()' [E0308] /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/compile/const-issue1440.rs:56:55: error: mismatched types, expected 'u32' but got '()' [E0308] /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/compile/const-issue1440.rs:56:55: error: mismatched types, expected 'u64' but got '()' [E0308] /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/compile/const-issue1440.rs:56:55: error: mismatched types, expected 'u128' but got '()' [E0308] /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/compile/const-issue1440.rs:56:55: error: mismatched types, expected 'usize' but got '()' [E0308] FAIL: rust/compile/torture/issue-1432.rs -O0 (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/compile/torture/issue-1432.rs:60:55: error: mismatched types, expected 'u8' but got '()' [E0308] /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/compile/torture/issue-1432.rs:60:55: error: mismatched types, expected 'u16' but got '()' [E0308] /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/compile/torture/issue-1432.rs:60:55: error: mismatched types, expected 'u32' but got '()' [E0308] /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/compile/torture/issue-1432.rs:60:55: error: mismatched types, expected 'u64' but got '()' [E0308] /home/dave/gnu/gcc/gcc/gcc/testsuite/rust/compile/torture/issue-1432.rs:60:55: error: mismatched types, expected 'usize' but got '()' [E0308]
[Bug rust/107700] Several testsuite failures on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107700 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org Build|sparc*-sun-solaris2.11 |sparc*-sun-solaris2.11 ||hppa64-hp-hpux11.11 Last reconfirmed||2024-02-10 Host|sparc*-sun-solaris2.11 |sparc*-sun-solaris2.11 ||hppa64-hp-hpux11.11 Status|UNCONFIRMED |NEW Target|sparc*-sun-solaris2.11 |sparc*-sun-solaris2.11 ||hppa64-hp-hpux11.11 Ever confirmed|0 |1 --- Comment #1 from John David Anglin --- const-issue1440.rs and issue-1432.rs fail in same way as Solaris/SPARC. builtin_macros1.rs execution fails at -O0: FAIL: rust/execute/torture/builtin_macros1.rs -O0 execution test At -O1 and above, execution tests pass but pattern tests fail: PASS: rust/execute/torture/builtin_macros1.rs -O1 execution test FAIL: rust/execute/torture/builtin_macros1.rs -O1 output pattern test Output was: <80> Should match: rust/execute/torture/builtin_macros1.rs^M* loop-condition-eval.rs does not fail on hppa64-hp-hpux11.11.
[Bug libstdc++/113792] error: '__size_t' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792 John David Anglin changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from John David Anglin --- Problem disappeared after updating to revision r14-8898-g2bb45562202.
[Bug c++/112436] SFINAE-unfriendly error on throwing pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112436 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug libfortran/110651] libgfortran.spec links twice with libgcc spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651 --- Comment #5 from Iain Sandoe --- AFAICT, this was fixed on trunk by r14-6721-gd31c54c7da7661 (which seems to have a reference to the PR so not sure why it did not show up here). I think we need this on any open branch which we want to work with macOS14+.
[Bug c++/113789] [13/14 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789 --- Comment #7 from Marek Polacek --- The ICE was fixed by r14-8903-g3a3e0f1b46a3ad. But I'm not done here yet.
[Bug target/112864] Many libphobos tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112864 Iain Sandoe changed: What|Removed |Added Summary|[14 regression] Many|Many libphobos tests FAIL |libphobos tests FAIL on |on macOS 12+ |macOS 12+ | --- Comment #4 from Iain Sandoe --- this is fixed on trunk, but still evaluating whether it's needed for macOS13/14 on older branches - (almost certainly for macOS14 + Xcode 15.1+)
[Bug target/112863] Many obj-c++ tests FAIL on macOS 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863 Iain Sandoe changed: What|Removed |Added Summary|[14 regression] Many|Many obj-c++ tests FAIL on |obj-c++ tests FAIL on macOS |macOS 14 |14 | --- Comment #9 from Iain Sandoe --- this is fixed on trunk, but still evaluating whether it's needed for macOS13/14 on older branches - (almost certainly for macOS14 + Xcode 15+).
[Bug target/112862] gfortran.dg coarray tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862 Iain Sandoe changed: What|Removed |Added Summary|[14 regression] gfortran.dg |gfortran.dg coarray tests |coarray tests FAIL on macOS |FAIL on macOS 12+ |12+ | --- Comment #15 from Iain Sandoe --- this is fixed on trunk, but still evaluating whether it's needed for macOS13/14 on older branches - so leaving open for now.
[Bug target/112861] Most gdc tests FAIL on macOS 12+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861 Iain Sandoe changed: What|Removed |Added Summary|[14 regression] Most gdc|Most gdc tests FAIL on |tests FAIL on macOS 12+ |macOS 12+ --- Comment #6 from Iain Sandoe --- this is fixed on trunk, but still evaluating whether it's needed for macOS13/14 on older branches - so leaving open for now.
[Bug c++/113853] implicit move in throw in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113853 Arthur O'Dwyer changed: What|Removed |Added CC||arthur.j.odwyer at gmail dot com --- Comment #1 from Arthur O'Dwyer --- (Sorry, not sure where's the best place to put this comment. Maybe nowhere. ;)) You probably know this already, but just in case anyone's not on the same page yet: https://eel.is/c++draft/except.throw#5 > When the thrown object is a class object, the constructor selected for the > copy-initialization *as well as the constructor selected for a > copy-initialization considering the thrown object as an lvalue* shall be > non-deleted and accessible, even if the copy/move operation is elided. That paragraph is lurking in the background every time we talk about GCC's handling of move-only exception objects. However, my impression is that the paragraph is ignorable from the vendor's point of view: - Even on paper, this "shall" is talking only about the runtime behavior "when an exception _is_ thrown," so it doesn't change anything about the well-formedness of _unevaluated_ throw-expressions. - GCC+Clang _probably could_ conformingly decide that it should be ill-formed to `throw x` when `x` is move-only; but that would break a lot of users, so pragmatically they can't do that. GCC+Clang need a consistent theory of what it means to throw a move-only type, and the theory can't possibly be "it's ill-formed" (because that would break users), so the theory must agree with Marek's test case: `throw t` ought to be well-formed in C++20-and-later (by wording introduced to C++20 in P1155 a.k.a. P1825). IOW, this bug and test case are *not* invalidated by [except.throw]/5. That's all. :)
[Bug middle-end/113734] [14 regression] libarchive miscompiled (fails libarchive_test_read_format_rar5_extra_field_version test) since r14-8768-g85094e2aa6dba7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734 --- Comment #12 from Sam James --- Created attachment 57379 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57379=edit test.c Here's an initial stab at a standalone testcase. I'm going to try reduce it now.
[Bug fortran/113845] ice in gfc_get_array_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113845 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #5) > I'm wondering if we need to worry about other actual > arguments. I note > > subroutine test_adjustl(x) > character(*) :: x(100) >x = adjustl(x) > call bar(x) > end subroutine > > does not cause problems. Playing around with variants, the common cause of the ICE seems: 1) assumed-length character dummy with rank > 0 e.g. these declarations fail too: character(*) :: x(*) character(*), allocatable :: x(:) but not: character(:), allocatable :: x(:) 2) any reference that is not a substring e.g. call bar(adjustl(x)) call bar(adjustl(x(1:1))) call bar(adjustl(x(:))) call bar(adjustl(x(:)(:))) but not call bar(adjustl(x(:)(1:len(x ! <- this is OK Quite obviously the attached patch is only a band-aid to prevent the infinite recursion, not a real solution...
[Bug target/113679] long long minus double with gcc -m32 produces different results than other compilers or gcc -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679 --- Comment #13 from Дилян Палаузов --- For clang being buggy from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679#c11 I filled https://github.com/llvm/llvm-project/issues/81358 .
[Bug c++/113854] the expression 'is_invocable_v ... evaluated to 'false'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113854 --- Comment #3 from Jonathan Wakely --- *unintended symptom deep inside a template
[Bug c++/113854] the expression 'is_invocable_v ... evaluated to 'false'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113854 --- Comment #2 from Jonathan Wakely --- And those are not library internals, they're the public concepts defined in the standard. You can look them up to see what they mean, but the problem boils down to what's shown at the end: your predicate can't be used with that argument type. I think that's actually a more accurate description of the problem than telling you that a deleted copy constructor can't be used. We've just been conditioned by years of bad errors to know what it means. But really what you're trying to do is call a function, not copy a unique_ptr. The concept error tells you what part of the API is not satisfied. The second error tells you about a symptom, not the cause, and leaves to to infer the cause: it's trying to copy a move only object because the lambda requires a copy. There are plenty of cases where being told which concept failed is much clearer than being told about some unintended symptom feel inside a template. The existence of counterexamples doesn't mean concepts aren't an improvement.
[Bug c++/113854] the expression 'is_invocable_v ... evaluated to 'false'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113854 --- Comment #1 from Jonathan Wakely --- Anybody who promised concepts will always result in better errors was lying or misinformed. They have the potential to help, but it takes real effort to make it happen. ranges::find_if is constrained to require the function to be callable with those argument types, and that fails here. I'm not sure how we can do better. If is_invocable is false, all we know is it's false. We can't poke at the definition of is_invocable to see why. A __builtin_is_invocable could _maybe_ capture more detail about the failure which could then be recalled and displayed if there's a compilation failure due to is_invocable not being satisfied (something which would be much more difficult for enable_if-based constraints, but plausible with concepts, maybe). I'm this specific case it's true that the error for std::find_if happens to be quite clear, but I'm the general case it's better to be told "this function requires is_invocable_v and you didn't satisfy that" then to get errors deep inside an instantiation stack.
[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #5 from Jakub Jelinek --- Comment on attachment 57378 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57378 patch under test s/jumpl/jmpl/
[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #4 from Iain Sandoe --- Created attachment 57378 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57378=edit patch under test This implements the common case for an i386 trampoline (and, in this respect, matches the expectations for x86_64 and aarch64). -- to explain the "common case" comment. We still have work to do to generalise the heap trampoline implementation; Several platforms have multiple trampoline implementations that can depend on optimisations or protections. At present, I considered: (1) - having the heap trampoline impl just deal with managing the storage. -- one would call a builtin to obtain a writeable trampoline area -- one would then use the inline existing trampoline impl to populate that -- one would then call to the heap management to apply conditions to make the written trampoline executable (since most security models do not allow writable+executable at the same time). -- although this model re-uses the existing trampoline in-line code-gen, I'm not in favour of it (a) it means two calls to libgcc_s for each case + (b) the inline code-gen is replicated which appears pointless code bloat since we have failed to avoid an out of line function call already. (2) - having the caller of __gcc_heap_trampoline_created () pass sufficient information for that function to alter the flavour of trampoline as needed. ( i) - we could add an extra argument to communicate this information (it could be as simple as an enum, probably). (ii) - We could re-use the third argument (which is a pointer to a pointer) to pass in a pointer to the data (or nullptr, for 'default' perhaps) -- in either case we need a new target hook that returns the relevant enum (or other target-private data) to be passed to __gcc_heap_trampoline_created(). (3) - perhaps using the existing in-line codegen into a scratch space and passing that to __gcc_heap_trampoline_created () -- not keen on this because: (a) the same comment about in-line code + out of line call. (b) if the trampoline uses relative branches (like the i386 common case) then those need to be relocated, which then means that the __gcc_heap_trampoline_created routine would have to match the relevant patterns and do the relocation. so, at the moment, (2) is my favoured approach - but more thinking might being other ideas.
[Bug c++/107126] -Wc++20-compat should complain about template-id in out of class definition for destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Marek Polacek --- Should be fixed.
[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Marek Polacek --- Should be all fixed now.
[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455 --- Comment #7 from newbie-02 --- > (and GCC doesn't implement the FENV_DEC_ROUND pragma to set a constant > rounding mode in a particular scope) here we are leaving my level of knowledge about internals. Let me formulate from a user / programmers perspective: Wanted is 'decimal compatible math'. Which is to some degree announced and partly fulfilled with _Decimalxxx datatypes. Shortcomings are: - requires libdfp ( hard to find and tricky to use ), or other library. - even with that there are situations where the rounding mode isn't respected, thus no system of reliable human compatible math. Could and should - IMHO - be improved by implementing something in gcc which accounts users wish 'ties away' in all situations. Can't say if that is a 'pragma' or what else. The essential point is to offer a well-rounded system / environment that relieves programmers and users from being constantly surprised by deviations. And thus set's them free from always and anytime having to check for it. Too big a wish? ( code - compiler - libraries - math shouldn't play Larry Laffer )
[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:cff174fabd6c980c09aee95db1d9d5c22421761f
commit r14-8915-gcff174fabd6c980c09aee95db1d9d5c22421761f
Author: Marek Polacek
Date: Fri Feb 2 14:53:01 2024 -0500
c++: DR2237, cdtor and template-id tweaks [PR107126]
Since my r11-532 changes to implement DR2237, for this test:
template
struct S {
S();
};
in C++20 we emit the ugly:
q.C:3:8: error: expected unqualified-id before ')' token
3 | S();
which doesn't explain what the problem is. This patch improves that
diagnostic, reduces the error to a pedwarn, and adds a -Wc++20-compat
diagnostic. We now say:
q.C:3:7: warning: template-id not allowed for constructor in C++20
[-Wtemplate-id-cdtor]
3 | S();
q.C:3:7: note: remove the '< >'
This patch also fixes
where the C++20 diagnostic was missing altogether: The problem was that I
checked
for CPP_TEMPLATE_ID too early, at a point at which cp_parser_template_id
may not
have been called yet. So let's check for it at the end of the function,
after
the tentative parse and rollback.
-Wc++20-compat triggered in libitm/; I sent a patch for that.
DR 2237
PR c++/107126
PR c++/97202
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): In C++20 or with
-Wc++20-compat,
turn on -Wtemplate-id-cdtor.
* c.opt (Wtemplate-id-cdtor): New.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_unqualified_id): Downgrade the DR2237 error
to
a pedwarn.
(cp_parser_constructor_declarator_p): Likewise.
gcc/ChangeLog:
* doc/invoke.texi: Document -Wtemplate-id-cdtor.
gcc/testsuite/ChangeLog:
* g++.dg/DRs/dr2237.C: Adjust dg-error.
* g++.dg/parse/constructor2.C: Likewise.
* g++.dg/template/error34.C: Likewise.
* g++.old-deja/g++.pt/ctor2.C: Likewise.
* g++.dg/DRs/dr2237-2.C: New test.
* g++.dg/DRs/dr2237-3.C: New test.
* g++.dg/DRs/dr2237-4.C: New test.
* g++.dg/DRs/dr2237-5.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-1.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-2.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-3.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-4.C: New test.
[Bug c++/107126] -Wc++20-compat should complain about template-id in out of class definition for destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:cff174fabd6c980c09aee95db1d9d5c22421761f
commit r14-8915-gcff174fabd6c980c09aee95db1d9d5c22421761f
Author: Marek Polacek
Date: Fri Feb 2 14:53:01 2024 -0500
c++: DR2237, cdtor and template-id tweaks [PR107126]
Since my r11-532 changes to implement DR2237, for this test:
template
struct S {
S();
};
in C++20 we emit the ugly:
q.C:3:8: error: expected unqualified-id before ')' token
3 | S();
which doesn't explain what the problem is. This patch improves that
diagnostic, reduces the error to a pedwarn, and adds a -Wc++20-compat
diagnostic. We now say:
q.C:3:7: warning: template-id not allowed for constructor in C++20
[-Wtemplate-id-cdtor]
3 | S();
q.C:3:7: note: remove the '< >'
This patch also fixes
where the C++20 diagnostic was missing altogether: The problem was that I
checked
for CPP_TEMPLATE_ID too early, at a point at which cp_parser_template_id
may not
have been called yet. So let's check for it at the end of the function,
after
the tentative parse and rollback.
-Wc++20-compat triggered in libitm/; I sent a patch for that.
DR 2237
PR c++/107126
PR c++/97202
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): In C++20 or with
-Wc++20-compat,
turn on -Wtemplate-id-cdtor.
* c.opt (Wtemplate-id-cdtor): New.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_unqualified_id): Downgrade the DR2237 error
to
a pedwarn.
(cp_parser_constructor_declarator_p): Likewise.
gcc/ChangeLog:
* doc/invoke.texi: Document -Wtemplate-id-cdtor.
gcc/testsuite/ChangeLog:
* g++.dg/DRs/dr2237.C: Adjust dg-error.
* g++.dg/parse/constructor2.C: Likewise.
* g++.dg/template/error34.C: Likewise.
* g++.old-deja/g++.pt/ctor2.C: Likewise.
* g++.dg/DRs/dr2237-2.C: New test.
* g++.dg/DRs/dr2237-3.C: New test.
* g++.dg/DRs/dr2237-4.C: New test.
* g++.dg/DRs/dr2237-5.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-1.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-2.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-3.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-4.C: New test.
[Bug tree-optimization/113863] New: [14 Regression] ICE verify_ssa failed with -O3 -msse4.1 since r14-8768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113863
Bug ID: 113863
Summary: [14 Regression] ICE verify_ssa failed with -O3
-msse4.1 since r14-8768
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat sort.cc
void test_sort_helper(int *);
int test_sort_driver_driver_real_last;
void test_sort_driver_driver(int start, int *e, int *f) {
for (int *l = e; l > f;) {
*--l = start;
if (f == l)
test_sort_helper(_sort_driver_driver_real_last);
if (start)
test_sort_driver_driver(start - 1, e, f);
}
}
$ gcc -O3 -msse4.1 sort.ii
sort.ii: In function ‘void test_sort_driver_driver(int, int*, int*)’:
sort.ii:3:6: error: definition in block 167 does not dominate use in block 166
3 | void test_sort_driver_driver(int start, int *e, int *f) {
| ^~~
[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 --- Comment #4 from Tobias Burnus --- Created attachment 57377 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57377=edit Fixes the ICE – might paper over a real issue; doesn't fix the run-time issue → TODO + 'data'-issue in PR comment 4 The patch fixes the issue #pragma omp target data map(S1.p[:N],S1.p,S1.a,S1.b) This gets split into the groups (reverse order!) 'S1.b' (i = 0), 'S1.a' (i = 1), 'S1.p' (i = 3) and 'S1.p[:N]' (i = 4; map + attach). In omp_build_struct_sibling_lists the collecting and reordering happens but for 'S1.p' there should be an 'alloc' not a 'tofrom' - such 'S1.p' has grp->deleted and the attach code will add the 'alloc' code. Until i = 2, everything is fine: *(*group[2])->deleted == true *(*group[2])->grp_start == (*group[2])->grp_end and this encloses 'map(tofrom:S1.p [len: 8])' – which should be removed in favor of a later (i = 3) added 'map(alloc:S1.p [len: 8])'. In principle, everything looks fine, until i =3 calls omp_accumulate_sibling_list, which in turn calls: continue_at = cl ? omp_siblist_move_concat_nodes_after (cl, tail_chain, grp_start_p, grp_end, sc) : omp_siblist_move_nodes_after (grp_start_p, grp_end, sc); where 'cl' != NULL_TREE. After the call, 'tail_chain' alias 'list_p' looks fine - except for the tailing 'map(tofrom:S1.p [len: 8])'. In principle, 'groups' is no longer touched - except for the the 'grp->deleted' handling, which fails (deletes the wrong stuff) because grp_begin points to the wrong tree. Solution: Do the OMP_CLAUSE_DECL nullifying earlier such that messing around with groups won't cause issues. TODO: We should really find out WHY i=2's grp_begin gets updated. If it happens just for previously processed grp items, that's fine - but what will happen if it also affects a still to be processed item? - If that indeed happens, everything will be messed up again! * * * The testcase shows another issue: target data map(to: S2.p[:N]) gets mapped as: map(struct:S2 [len: 1]) map(alloc:S2.p [len: 0]) map(tofrom:*_14 [len: 400])map(attach:S2.p [bias: 0]) before: map(tofrom:*_14 [len: 400]) map(attach:S2.p [bias: 0] The problem of the former is of course that 'S' is already partially mapped and that an alloc of length 0 will then fail already in 'target data' for the attach:S2.p as 0 bytes aren't sufficient for a pointer attachment. This applies both to target data and target, except that for 'target', 'S' might appear implicitly - while for 'data' it can only appear explicitly or not at all.
[Bug middle-end/110754] assume create spurious load for volatile variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110754 --- Comment #9 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:39920447f876128ff7942a9cd931021800865894 commit r14-8910-g39920447f876128ff7942a9cd931021800865894 Author: Jakub Jelinek Date: Sat Feb 10 11:28:00 2024 +0100 gimple-low: Fix up handling of volatile automatic vars in assume attribute [PR110754] As the following testcases show, the gimple-low outlining of assume magic functions handled volatile automatic vars (including parameters/results) like non-volatile ones except it copied volatile to the new PARM_DECL, which has the undesirable effect that a load from the volatile var is passed to IFN_ASSUME and so there is a side-effect there even when side-effects of the assume attribute shouldn't be evaluated. The following patch fixes that by passing address of the volatile variables/parameters/results instead and doing loads or stores from it or to it where it was originally accessed in the assume attribute expression. 2024-02-10 Jakub Jelinek PR middle-end/110754 * gimple-low.cc (assumption_copy_decl): For TREE_THIS_VOLATILE decls create PARM_DECL with pointer to original type, set TREE_READONLY and keep TREE_THIS_VOLATILE, TREE_ADDRESSABLE, DECL_NOT_GIMPLE_REG_P and DECL_BY_REFERENCE cleared. (adjust_assumption_stmt_op): For remapped TREE_THIS_VOLATILE decls wrap PARM_DECL into a simple TREE_THIS_NO_TRAP MEM_REF. (lower_assumption): For TREE_THIS_VOLATILE vars pass ADDR_EXPR of the var as argument. * gcc.dg/attr-assume-6.c: New test. * g++.dg/cpp23/attr-assume12.C: New test.
[Bug ada/113862] New: error: "others" choice not allowed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113862 Bug ID: 113862 Summary: error: "others" choice not allowed here Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: p.p11 at orange dot fr CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 57376 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57376=edit Reproducer. $ gcc -c -gnatl test34b.adb GNAT 13.2.0 Compiling: test34b.adb 1. procedure Test34b is 2. 3.type NTCT is new Natural; 4.TBD_Error, Not_Valid_Error : exception; 5.function Is_Valid (P : NTCT) return Boolean is (False); 6.Param : NTCT; 7.type Some_Tagged is tagged null record; 8.type A_Tagged is new Some_Tagged with record Comp : Character; end record; 9.type Some_Array is array (Positive range <>) of NTCT; 10.function Func (Val : Integer) return Natural is (0); 11. 12.--Section_11_3_Paragraph_2a 13.Pre : Boolean := (if not Is_Valid(Param) then raise Not_Valid_Error); 14.A : A_Tagged := (Some_Tagged'(raise TBD_Error) with Comp => 'A'); 15.B : Some_Array := (1, 2, 3, others => raise Not_Valid_Error); | >>> error: "others" choice not allowed here >>> error: qualify the aggregate with a constrained subtype to provide bounds for it 16.C : Natural:= Func (Val => raise TBD_Error); 17.D : A_Tagged := ((raise TBD_Error) with Comp => 'A'); 18. 19. begin 20.null; 21. end; It is weird as this code comes from AARM 2022 Section_11_3_Paragraph_2a. See full source code in attachement.
[Bug tree-optimization/109885] gcc does not generate movmskps and testps instructions (clang does)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109885
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
CC||pinskia at gcc dot gnu.org
Blocks||53947
--- Comment #3 from Andrew Pinski ---
What is even funnier on the LLVM side is if we have:
```
void f(unsigned int * __restrict a, unsigned int * __restrict b)
{
unsigned int t = 0;
t += (a[0] == b[0]);
t += (a[1] == b[1])<<1;
t += (a[2] == b[2])<<2;
t += (a[3] == b[3])<<3;
*a = t;
}
```
LLVM can produce movmskps for x86_64 but then does do a similar trick that it
did for the sum for aarch64.
Note GCC does not handle reductions that well for SLP either.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
