[Bug modula2/112946] Assignment of string to enumeration or set crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112946
Gaius Mulley changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #6 from Gaius Mulley ---
MODULE badexpression3 ;
TYPE
enums = (red, blue, green) ;
set = SET OF enums ;
VAR
setvar : set;
enumvar: enums;
BEGIN
setvar := set {red, blue} ;
setvar := setvar + green ;(* Should detect an error here. *)
IF NOT (green IN setvar)
THEN
HALT
END
END badexpression3.
successfully compiles - and it should detect an error at "setvar + green".
M2GenGCC.mod:FoldBinary (and FoldUnary) need the same treatment as FoldBecomes
in the original patch.
[Bug target/113042] popcount of 8bits and 128bits can be improved for !TARGET_CSSC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113042 --- Comment #2 from Andrew Pinski --- Blah, adding popcountti2 does not work as the middle-end (in fold_builtin_bit_query) splits it into 2 __builtin_popcountll already ...
[Bug target/103781] generic/cortex-a53 cost model for SLP for aarch64 is good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103781 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- I know that the generic cost model has changed on the trunk but I am not sure this one is fixed ...
[Bug target/113043] New: ICE: in emit_move_insn, at expr.cc:4246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113043
Bug ID: 113043
Summary: ICE: in emit_move_insn, at expr.cc:4246
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/erY5Mrrso
***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/202311291030/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/202311291030/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/202311291030
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231129 (experimental) (GCC)
git version: 99fa0bfd63d97825c4221dcd3123940f1d0e6291
***
Program:
$ cat mutant.c
struct a {
long b
};
__attribute__((interrupt)) void c(struct a *d) { 1 != d->b; }
***
Command Lines:
$ gcc -mx32 -mgeneral-regs-only -maddress-mode=long -fsanitize=undefined
mutant.c
mutant.c:3:1: warning: no semicolon at end of struct or union
3 | };
| ^
during RTL pass: expand
mutant.c: In function ‘c’:
mutant.c:4:56: internal compiler error: in emit_move_insn, at expr.cc:4246
4 | __attribute__((interrupt)) void c(struct a *d) { 1 != d->b; }
| ~^~~
0x774d50 emit_move_insn(rtx_def*, rtx_def*)
../../gcc/gcc/expr.cc:4246
0xaddfec expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.cc:4011
0xaddfec expand_gimple_stmt
../../gcc/gcc/cfgexpand.cc:4045
0xadec97 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.cc:6101
0xae08f6 execute
../../gcc/gcc/cfgexpand.cc:6836
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/96461] [SVE] Use the HISTCNT instruction for simple histogram loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96461 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2023-12-16 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/113031] [14 Regression] ICE in cxx_fold_indirect_ref_1 starting with r14-6508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113031 --- Comment #4 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:39f9c426f58448d6df340cdccd84e05721a20921 commit r14-6619-g39f9c426f58448d6df340cdccd84e05721a20921 Author: Nathaniel Shead Date: Sat Dec 16 10:59:03 2023 +1100 c++: Fix unchecked use of CLASSTYPE_AS_BASE [PR113031] My previous commit (naively) assumed that a TREE_CODE of RECORD_TYPE or UNION_TYPE was sufficient for optype to be considered a "class type". However, this does not account for e.g. template type parameters of record or union type. This patch corrects to check for CLASS_TYPE_P before checking for as-base conversion. PR c++/113031 gcc/cp/ChangeLog: * constexpr.cc (cxx_fold_indirect_ref_1): Check for CLASS_TYPE before using CLASSTYPE_AS_BASE. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/pr113031.C: New test. Signed-off-by: Nathaniel Shead
[Bug target/113034] Miscompilation of __m128 ne comparison on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113034 --- Comment #1 from Jiajie Chen --- As pointed out by @lrzlin, the expected output should be: ``` 1 -1 0 ```
[Bug target/113042] popcount of 8bits and 128bits can be improved for !TARGET_CSSC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113042 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-12-16 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Will submit the patch early next week.
[Bug target/113042] New: popcount of 8bits and 128bits can be improved for !TARGET_CSSC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113042
Bug ID: 113042
Summary: popcount of 8bits and 128bits can be improved for
!TARGET_CSSC
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Take:
```
unsigned h8 (const unsigned char *restrict a) {
return __builtin_popcountg (a[0]);
}
unsigned __int128 h128 (const unsigned __int128 *restrict a) {
return __builtin_popcountg (a[0]);
}
```
Currently h8 produces:
```
ldr b31, [x0]
cnt v31.8b, v31.8b
addvb31, v31.8b
fmovw0, s31
ret
```
But the addv is not needed here and we could instead just get:
```
ldr b31, [x0]
cnt v31.8b, v31.8b
smovw0, v31.b[0]
ret
```
For h128, there are two cnt:
```
ldp d30, d31, [x0]
mov x1, 0
cnt v30.8b, v30.8b
cnt v31.8b, v31.8b
addvb30, v30.8b
addvb31, v31.8b
fmovx2, d30
fmovx0, d31
add x0, x2, x0
ret
```
But we could do instead:
```
ldr q30, [x0]
mov x1, 0
cnt v30.16b, v30.16b
addvb30, v31.16b
fmovx0, d30
ret
```
Basically we need to implement popcountqi2 and popcountti2 patterns.
Note for TARGET_CSSC, Using the scalar cnt will still be better I suspect so I
won't enable these patterns for that.
[Bug c++/113041] New: misleading diagnostic for variable of non-literal type in constexpr function in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113041
Bug ID: 113041
Summary: misleading diagnostic for variable of non-literal type
in constexpr function in C++20 mode
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
Here f() is not constexpr in C++20 (but is in C++23 after P2242R3) due to
the local variable a of non-literal type A, so the testcase is invalid:
struct A { ~A(); };
void g();
template
constexpr int f() {
if (__builtin_is_constant_evaluated())
return 42;
g();
A a;
}
constexpr int n = f();
But our diagnostic incorrectly blames the call to the non-constexpr g() for
f() being non-constexpr, rather than the variable a:
constexpr-nonliteral.C:13:25: error: ‘constexpr int f() [with T = int]’ called
in a constant expression
13 | constexpr int n = f();
| ~~^~
constexpr-nonliteral.C:6:15: note: ‘constexpr int f() [with T = int]’ is not
usable as a ‘constexpr’ function because:
6 | constexpr int f() {
| ^
constexpr-nonliteral.C:9:4: error: call to non-‘constexpr’ function ‘void g()’
9 | g();
| ~^~
constexpr-nonliteral.C:3:6: note: ‘void g()’ declared here
3 | void g();
| ^
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 98792, which changed state. Bug 98792 Summary: Fail to use SHRN instructions for narrowing shift on aarch64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98792 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/98792] Fail to use SHRN instructions for narrowing shift on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98792 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- It was fixed in GCC 12 by one of the following commits: r12-7142-g83d7e720cd1d07 r12-7141-gbce43c0493f65d r12-7140-g4057266ce5afc1 r12-7138-gaeef5c57f161ad
[Bug target/113039] [14 Regression] -fcf-protection -fcf-protection=branch doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039 --- Comment #2 from H.J. Lu --- (In reply to H.J. Lu from comment #1) > This may be caused by r14-2692-g1c6231c05bdcca This commit changes the behavior of -fcf-protection -fcf-protection=branch. Workaround is to use -fcf-protection -fcf-protection=none -fcf-protection=branch.
[Bug target/113039] [14 Regression] -fcf-protection -fcf-protection=branch doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039 H.J. Lu changed: What|Removed |Added Last reconfirmed||2023-12-16 Ever confirmed|0 |1 Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW --- Comment #1 from H.J. Lu --- This may be caused by r14-2692-g1c6231c05bdcca
[Bug target/113040] New: [14 Regression] libmvec test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113040 Bug ID: 113040 Summary: [14 Regression] libmvec test failures Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com Target Milestone: --- Target: x86-64 When GCC 14 (r14-6607-g082835836cf763) to build and test glibc on x86-64, I got FAIL: math/test-float-libmvec-sincosf-avx2 FAIL: math/test-float-libmvec-sincosf-avx512f Program received signal SIGSEGV, Segmentation fault. _ZGVdN8vvv_sincosf_avx2 () at ../sysdeps/x86_64/fpu/multiarch/svml_s_sincosf8_core_avx2.S:305 305 movl %r9d, (%r10) (gdb) and Program received signal SIGSEGV, Segmentation fault. 0x5547e976 in _ZGVeN16vvv_sincosf_skx () at ../sysdeps/x86_64/fpu/multiarch/svml_s_sincosf16_core_avx512.S:741 741 WRAPPER_AVX512_vvv_vl4l4 _ZGVeN16vl4l4_sincosf_skx (gdb)
[Bug target/113039] New: [14 Regression] -fcf-protection -fcf-protection=branch doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039 Bug ID: 113039 Summary: [14 Regression] -fcf-protection -fcf-protection=branch doesn't work Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com Target Milestone: --- Target: x86-64 [hjl@gnu-cfl-3 pr85334]$ touch x.c [hjl@gnu-cfl-3 pr85334]$ /export/build/gnu/tools-build/gcc-gitlab-debug/release/usr/gcc-14.0.0-x86-64/bin/gcc -c -fcf-protection -fcf-protection=branch x.c [hjl@gnu-cfl-3 pr85334]$ readelf -n x.o Displaying notes found in: .note.gnu.property OwnerData sizeDescription GNU 0x0010 NT_GNU_PROPERTY_TYPE_0 Properties: x86 feature: IBT, SHSTK GNU 0x0020 NT_GNU_PROPERTY_TYPE_0 Properties: x86 ISA used: x86 feature used: x86 [hjl@gnu-cfl-3 pr85334]$ -fcf-protection=branch should override -fcf-protection.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #34 from Jerry DeLisle --- If not resolved, feel free to reopen.
[Bug sanitizer/112727] [11/12/13 Regression] UBSAN creates GIMPLE path with uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112727 --- Comment #11 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2b8f9636c1b19fff7723995f2d58d41f3d30c46d commit r12-10056-g2b8f9636c1b19fff7723995f2d58d41f3d30c46d Author: Jakub Jelinek Date: Fri Dec 8 20:56:48 2023 +0100 c++: Unshare folded SAVE_EXPR arguments during cp_fold [PR112727] The following testcase is miscompiled because two ubsan instrumentations run into each other. The first one is the shift instrumentation. Before the C++ FE calls it, it wraps the 2 shift arguments with cp_save_expr, so that side-effects in them aren't evaluated multiple times. And, ubsan_instrument_shift itself uses unshare_expr on any uses of the operands to make sure further modifications in them don't affect other copies of them (the only not unshared ones are the one the caller then uses for the actual operation after the instrumentation, which means there is no tree sharing). Now, if there are side-effects in the first operand like say function call, cp_save_expr wraps it into a SAVE_EXPR, and ubsan_instrument_shift in this mode emits something like if (..., SAVE_EXPR , SAVE_EXPR > const) __ubsan_handle_shift_out_of_bounds (..., SAVE_EXPR , ...); and caller adds SAVE_EXPR << SAVE_EXPR after it in a COMPOUND_EXPR. So far so good. If there are no side-effects and cp_save_expr doesn't create SAVE_EXPR, everything is ok as well because of the unshare_expr. We have if (..., SAVE_EXPR > const) __ubsan_handle_shift_out_of_bounds (..., ptr->something[i], ...); and ptr->something[i] << SAVE_EXPR where ptr->something[i] is unshared. In the testcase below, the !x->s[j] ? 1 : 0 expression is wrapped initially into a SAVE_EXPR though, and unshare_expr doesn't unshare SAVE_EXPRs nor anything used in them for obvious reasons, so we end up with: if (..., SAVE_EXPR (x)->s[j] ? 1 : 0>, SAVE_EXPR > const) __ubsan_handle_shift_out_of_bounds (..., SAVE_EXPR (x)->s[j] ? 1 : 0>, ...); and SAVE_EXPR (x)->s[j] ? 1 : 0> << SAVE_EXPR So far good as well. But later during cp_fold of the SAVE_EXPR we find out that VIEW_CONVERT_EXPR(x)->s[j] ? 0 : 1 is actually invariant (has TREE_READONLY set) and so cp_fold simplifies the above to if (..., SAVE_EXPR > const) __ubsan_handle_shift_out_of_bounds (..., (bool) VIEW_CONVERT_EXPR(x)->s[j] ? 0 : 1, ...); and ((bool) VIEW_CONVERT_EXPR(x)->s[j] ? 0 : 1) << SAVE_EXPR with the s[j] ARRAY_REFs and other expressions shared in between the two uses (and obviously the expression optimized away from the COMPOUND_EXPR in the if condition. Then comes another ubsan instrumentation at genericization time, this time to instrument the ARRAY_REFs with strict bounds checking, and replaces the s[j] in there with s[.UBSAN_BOUNDS (0B, SAVE_EXPR, 8), SAVE_EXPR] As the trees are shared, it does that just once though. And as the if body is gimplified first, the SAVE_EXPR is evaluated inside of the if body and when it is used again after the if, it uses a potentially uninitialized value of j.1 (always uninitialized if the shift count isn't out of bounds). The following patch fixes that by unshare_expr unsharing the folded argument of a SAVE_EXPR if we've folded the SAVE_EXPR into an invariant and it is used more than once. 2023-12-08 Jakub Jelinek PR sanitizer/112727 * cp-gimplify.cc (cp_fold): If SAVE_EXPR has been previously folded, unshare_expr what is returned. * c-c++-common/ubsan/pr112727.c: New test. (cherry picked from commit 6ddaf06e375e1c15dcda338697ab6ea457e6f497)
[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733
--- Comment #17 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:4bf040fcd23aaa7d8c4873d1170776ab117bc213
commit r12-10055-g4bf040fcd23aaa7d8c4873d1170776ab117bc213
Author: Jakub Jelinek
Date: Wed Nov 29 12:26:50 2023 +0100
fold-const: Fix up multiple_of_p [PR112733]
We ICE on the following testcase when wi::multiple_of_p is called on
widest_int 1 and -128 with UNSIGNED. I still need to work on the
actual wide-int.cc issue, the latest patch attached to the PR regressed
bitint-{38,39}.c, so will need to debug that, but there is a clear bug
on the fold-const.cc side as well - widest_int is a signed representation
by definition, using UNSIGNED with it certainly doesn't match what was
intended, because -128 as the second operand effectively means unsigned
131072 bit 0xf80 integer, not the signed char -128
that appeared in the source.
In the INTEGER_CST case a few lines above this we already use
case INTEGER_CST:
if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom))
return false;
return wi::multiple_of_p (wi::to_widest (top), wi::to_widest
(bottom),
SIGNED);
so I think using SIGNED with widest_int is best there (compared to the
other choices in the PR).
2023-11-29 Jakub Jelinek
PR middle-end/112733
* fold-const.cc (multiple_of_p): Pass SIGNED rather than
UNSIGNED for wi::multiple_of_p on widest_int arguments.
* gcc.dg/pr112733.c: New test.
(cherry picked from commit 5c95bf945c632925efba86dd5dceccdb9da8884c)
[Bug target/112816] [11/12 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816 --- Comment #13 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0246a37ebdef4ffc863fe4c56e812c0614026e02 commit r12-10052-g0246a37ebdef4ffc863fe4c56e812c0614026e02 Author: Jakub Jelinek Date: Mon Dec 4 09:00:18 2023 +0100 i386: Fix up signbit2 expander [PR112816] The following testcase ICEs, because the signbit2 expander uses an explicit SUBREG in the pattern around match_operand with register_operand predicate. If we are unlucky enough that expansion tries to expand it with some SUBREG as operands[1], we have two nested SUBREGs in the IL, which is not valid and causes ICE later. 2023-12-04 Jakub Jelinek PR target/112816 * config/i386/sse.md (signbit2): Force operands[1] into a REG. * gcc.target/i386/sse2-pr112816.c: New test. (cherry picked from commit 994d6dc64435d6b7c50accca9941ee7decd92a22)
[Bug target/112845] [11/12 Regression] ICE: in extract_insn, at recog.cc:2804 with -Os -fcf-protection -c since r8-3504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112845 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:87d013f7c877f944adbbaa4e94244baf990cb9f2 commit r12-10054-g87d013f7c877f944adbbaa4e94244baf990cb9f2 Author: Jakub Jelinek Date: Tue Dec 5 13:17:57 2023 +0100 i386: Fix -fcf-protection -Os ICE due to movabsq peephole2 [PR112845] The following testcase ICEs in the movabsq $(i32 << shift), r64 peephole2 I've added a while back to use smaller code than movabsq if possible. If i32 is 0xfa1e0ff3 and shift is not divisible by 8, then it creates an invalid insn (as 0xfa1e0ff3 CONST_INT is not allowed as x86_64_immediate_operand nor x86_64_zext_immediate_operand), the peephole2 even triggers on it again and again (this time with shift 0) until it gives up. The following patch fixes that. As ix86_endbr_immediate_operand needs a CONST_INT and it is hopefully rare, I chose to use FAIL rather than handling it in the condition (where I'd probably need to call ctz_hwi again etc.). 2023-12-05 Jakub Jelinek PR target/112845 * config/i386/i386.md (movabsq $(i32 << shift), r64 peephole2): FAIL if the new immediate is ix86_endbr_immediate_operand. (cherry picked from commit e0786ca9a18c50ad08c40936b228e325193664b8)
[Bug target/112837] [12 Regression] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx plus) in ix86_elim_entry_set_got, at config/i386/i386.cc:8612 with -fcompare-elim -fpie -fprofile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112837 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d02372f39dc6506a4ff88a7f01fb5570a82606c0 commit r12-10053-gd02372f39dc6506a4ff88a7f01fb5570a82606c0 Author: Jakub Jelinek Date: Mon Dec 4 09:01:09 2023 +0100 i386: Fix rtl checking ICE in ix86_elim_entry_set_got [PR112837] The following testcase ICEs with RTL checking, because it sets if XINT (SET_SRC (set), 1) is UNSPEC_SET_GOT without checking if SET_SRC (set) is actually an UNSPEC, so any time we see any other insn with PARALLEL and a SET in it which is not an UNSPEC we ICE during RTL checking or access there some other union member as if it was an rt_int. The rest is just small cleanup. 2023-12-04 Jakub Jelinek PR target/112837 * config/i386/i386.cc (ix86_elim_entry_set_got): Before checking for UNSPEC_SET_GOT check that SET_SRC is UNSPEC. Use SET_SRC and SET_DEST macros instead of XEXP, rename vec variable to set. * gcc.dg/pr112837.c: New test. (cherry picked from commit 4586d7d0a92e9b60d0c01043e0ae262b1e06f337)
[Bug c/112339] ICE with clang::no_sanitize and -fsanitize=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112339 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:029b826f62d2d193e93539749a534b9a13ade728 commit r12-10048-g029b826f62d2d193e93539749a534b9a13ade728 Author: Jakub Jelinek Date: Thu Nov 9 09:05:54 2023 +0100 attribs: Fix ICE with -Wno-attributes= [PR112339] The following testcase ICEs, because with -Wno-attributes=foo::no_sanitize (but generally any other non-gnu namespace and some gnu well known attribute name within that other namespace) the FEs don't really parse attribute arguments of such attribute, but lookup_attribute_spec is non-NULL with NULL handler and such attributes are added to DECL_ATTRIBUTES or TYPE_ATTRIBUTES and then when e.g. middle-end does lookup_attribute on a particular attribute and expects the attribute to mean something and/or have a particular verified arguments, it can crash when seeing the foreign attribute in there instead. The following patch fixes that by never adding ignored attributes to DECL_ATTRIBUTES/TYPE_ATTRIBUTES, previously that was the case just for attributes in ignored namespace (where lookup_attribute_space returned NULL). We don't really know anything about those attributes, so shouldn't pretend we know something about them, especially when the arguments are error_mark_node or NULL instead of something that would have been parsed. And it would be really weird if we normally ignore say [[clang::unused]] attribute, but when people use -Wno-attributes=clang::unused we actually treated it as gnu::unused. All the user asked for is suppress warnings about that attribute being unknown. The first hunk is just playing safe, I'm worried people could -Wno-attributes=gnu:: and get various crashes with known GNU attributes not being actually parsed and recorded (or worse e.g. when we tweak standard attributes into GNU attributes and we wouldn't add those). The -Wno-attributes= documentation says that it suppresses warning about unknown attributes, so I think -Wno-attributes=gnu:: should prevent warning about say [[gnu::foobarbaz]] attribute, but not about [[gnu::unused]] because the latter is a known attribute. The routine would return true for any scoped attribute in the ignored namespace, with the change it ignores only unknown attributes in ignored namespace, known ones in there will be ignored only if they have max_length of -2 (e.g.. with -Wno-attributes=gnu:: -Wno-attributes=gnu::foobarbaz). 2023-11-09 Jakub Jelinek PR c/112339 * attribs.cc (attribute_ignored_p): Only return true for attr_namespace_ignored_p if as is NULL. (decl_attributes): Never add ignored attributes. * c-c++-common/ubsan/Wno-attributes-1.c: New test. (cherry picked from commit 533241c6c60bc7c9f7dc47a94e94b5eed1b370e6)
[Bug c++/112795] [C++>=14] ICE pragma GCC unroll (n) cxx_eval_constant_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112795 --- Comment #11 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f1761303c77219281c22ab50b4a9ce65920c4023 commit r12-10051-gf1761303c77219281c22ab50b4a9ce65920c4023 Author: Jakub Jelinek Date: Mon Dec 4 08:59:15 2023 +0100 c++: #pragma GCC unroll C++ fixes [PR112795] foo in the unroll-5.C testcase ICEs because cp_parser_pragma_unroll during parsing calls maybe_constant_value unconditionally, which is fine if !processing_template_decl, but can ICE otherwise. While just calling fold_non_dependent_expr there instead could be enough to fix the ICE (and I guess the right thing to do for backports if any), I don't see a reason why we couldn't handle a dependent #pragma GCC unroll argument as well, the unrolling isn't done in the FE and all the middle-end cares about is that ANNOTATE_EXPR has a 1..65534 last operand when it is annot_expr_unroll_kind. So, the following patch changes all the unsigned short unroll arguments to tree unroll (and thus avoids the tree -> unsigned short -> tree conversions), does the type and value checking during parsing only if the argument isn't dependent and repeats it during instantiation. 2023-12-04 Jakub Jelinek PR c++/112795 gcc/cp/ * parser.cc (cp_parser_pragma_unroll): Use fold_non_dependent_expr instead of maybe_constant_value. gcc/testsuite/ * g++.dg/ext/unroll-5.C: New test. (cherry picked from commit b6c78feea08c36e5754818c6a3d7536b3f8913dc)
[Bug target/111408] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-2866-ge68a31549d9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111408
--- Comment #8 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9cb9cecdb582b44b04e9c49532ddf0065b5c3612
commit r12-10050-g9cb9cecdb582b44b04e9c49532ddf0065b5c3612
Author: Jakub Jelinek
Date: Sat Nov 25 10:31:55 2023 +0100
i386: Fix up *jcc_bt*_mask{,_1} [PR111408]
The following testcase is miscompiled in GCC 14 because the
*jcc_bt_mask and *jcc_bt_mask_1 patterns have just
one argument in (match_operator 0 "bt_comparison_operator" [...])
but as bt_comparison_operator is eq,ne, we need two.
The md readers don't warn about it, after all, some checks can
be done in the predicate rather than specified explicitly, and the
behavior is that anything is accepted as the second argument.
I went through all other i386.md match_operator uses and all others
looked right (extract_operator using 3 operands, all others 2).
I think we'll want to fix this at different spots in older releases
because I think the bug was introduced already in 2008, though most
likely just latent.
2023-11-25 Jakub Jelinek
PR target/111408
* config/i386/i386.md (*jcc_bt_mask): Add (const_int 0) as
expected second operand of bt_comparison_operator.
* gcc.c-torture/execute/pr111408.c: New test.
(cherry picked from commit 9866c98e1015d98b8fc346d7cf73a0070cce5f69)
[Bug tree-optimization/111967] [12 Regression] during GIMPLE pass: evrp ICE: in operator[], at vec.h:910 with -O2 -fno-tree-forwprop -fdump-tree-evrp-all since r12-4694
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111967 --- Comment #8 from GCC Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:327713d54122ab5635f3c385aecf113e5afe190c commit r12-10049-g327713d54122ab5635f3c385aecf113e5afe190c Author: Jakub Jelinek Date: Mon Nov 13 08:47:41 2023 +0100 gimple-range-cache: Fix ICEs when dumping details [PR111967] The following testcase ICEs when dumping details. When m_ssa_ranges vector is created, it is safe_grow_cleared (num_ssa_names), but when when some new SSA_NAME is added, we strangely grow it to num_ssa_names + 1 instead and later on the 3 argument dump method iterates from 1 to m_ssa_ranges.length () - 1 and uses ssa_name (x) on each; but because set_bb_range grew it one too much, ssa_name (m_ssa_ranges.length () - 1) might be after the end of the ssanames vector and ICE. The fix grows the vector consistently only to num_ssa_names, doesn't waste time checking m_ssa_ranges[0] because there is no ssa_names (0), it is always NULL, before using ssa_name (x) checks if we'll need it at all (we check later if m_ssa_ranges[x] is non-NULL, so we might check it earlier as well) and also in the last loop iterates until m_ssa_ranges.length () rather than num_ssa_names, I don't see a reason for the inconsistency and in theory some SSA_NAME could be added without set_bb_range called for it and the vector could be shorter than the ssanames vector. To actually fix the ICE, either the first hunk or the last 2 hunks would be enough, but I think it doesn't hurt to change all the spots. 2023-11-13 Jakub Jelinek PR tree-optimization/111967 * gimple-range-cache.cc (block_range_cache::set_bb_range): Grow m_ssa_ranges to num_ssa_names rather than num_ssa_names + 1. (block_range_cache::dump): Iterate from 1 rather than 0. Don't use ssa_name (x) unless m_ssa_ranges[x] is non-NULL. Iterate to m_ssa_ranges.length () rather than num_ssa_names. * gcc.dg/tree-ssa/pr111967.c: New test. (cherry picked from commit 5a0c302d2d721b9650c1e354695dbba87364c334)
[Bug tree-optimization/110731] [11/12 Regression] Wrong-code because of wide-int division since r5-424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110731
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9a93c334865af18ce2fd50cd77a9e90939f3c231
commit r12-10046-g9a93c334865af18ce2fd50cd77a9e90939f3c231
Author: Jakub Jelinek
Date: Wed Jul 19 13:48:53 2023 +0200
wide-int: Fix up wi::divmod_internal [PR110731]
As the following testcase shows, wi::divmod_internal doesn't handle
correctly signed division with precision > 64 when the dividend (and likely
divisor as well) is the type's minimum and the precision isn't divisible
by 64.
A few lines above what the patch hunk changes is:
/* Make the divisor and dividend positive and remember what we
did. */
if (sgn == SIGNED)
{
if (wi::neg_p (dividend))
{
neg_dividend = -dividend;
dividend = neg_dividend;
dividend_neg = true;
}
if (wi::neg_p (divisor))
{
neg_divisor = -divisor;
divisor = neg_divisor;
divisor_neg = true;
}
}
i.e. we negate negative dividend or divisor and remember those.
But, after we do that, when unpacking those values into b_dividend and
b_divisor we need to always treat the wide_ints as UNSIGNED,
because divmod_internal_2 performs an unsigned division only.
Now, if precision <= 64, we don't reach here at all, earlier code
handles it. If dividend or divisor aren't the most negative values,
the negation clears their most significant bit, so it doesn't really
matter if we unpack SIGNED or UNSIGNED. And if precision is multiple
of HOST_BITS_PER_WIDE_INT, there is no difference in behavior, while
-0x8000 negates to
-0x8000 the unpacking of it as SIGNED
or UNSIGNED works the same.
In the testcase, we have signed precision 119 and the dividend is
val = { 0, 0xffc0 }, len = 2, precision = 119
both before and after negation.
Divisor is
val = { 2 }, len = 1, precision = 119
But we really want to divide 0x40 by 2
unsigned and then negate at the end.
If it is unsigned precision 119 division
0x40 by 2
dividend is
val = { 0, 0xffc0 }, len = 2, precision = 119
but as we unpack it UNSIGNED, it is unpacked into
0, 0, 0, 0x0040
The following patch fixes it by always using UNSIGNED unpacking
because we've already negated negative values at that point if
sgn == SIGNED and so most negative constants should be treated as
positive.
2023-07-19 Jakub Jelinek
PR tree-optimization/110731
* wide-int.cc (wi::divmod_internal): Always unpack dividend and
divisor as UNSIGNED regardless of sgn.
* gcc.dg/pr110731.c: New test.
(cherry picked from commit ece799607c841676f4e00c2fea98bbec6976da3f)
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 86970, which changed state. Bug 86970 Summary: Rejected constexpr expression involving lambdas and inheritance, "use of this in a constant expression" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86970 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/86970] Rejected constexpr expression involving lambdas and inheritance, "use of this in a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86970 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |10.0 CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- Fixed with -std=c++17 since r10-3661-g8e007055dd1374 apparently.
[Bug other/113038] New: [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113038 Bug ID: 113038 Summary: [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:fe54b57728c09ab0389e2bb3f079d5210566199d, r14-6569-gfe54b57728c09a FAIL: g++.dg/modules/hello-1 -std=c++2b execute FAIL: g++.dg/modules/hello-1_b.C -std=c++2b (test for excess errors) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++13/../../xg++ -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++13/../../ /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/modules/hello-1_b.C -fdiagnostics-plain-output -nostdinc++ -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++2b -pedantic-errors -Wno-long-long -fmodules-ts -S -o hello-1_b.s^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/locale_classes.tcc: In instantiation of 'const _Facet* std::__try_use_facet@hello(const locale@hello&) [with _Facet = ctype@hello]':^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/locale_classes.tcc:200:59: required from 'const _Facet& std::use_facet@hello(const locale@hello&) [with _Facet = ctype@hello]'^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets_nonio.tcc:1573:63: required from '_InIter std::__cxx11::time_get@hello<_CharT, _InIter>::do_get(iter_type, iter_type, std::ios_base&, std::ios_base::iostate&, tm*, char, char) const [with _CharT = char; _InIter = std::istreambuf_iterator >; iter_type = std::istreambuf_iterator >; std::ios_base::iostate = std::ios_base::iostate]'^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets_nonio.tcc:1567:5: required from here^M : warning: new declaration 'void* __cxxabiv1::__dynamic_cast(const void*, const __class_type_info*, const __class_type_info*, long int)' ambiguates built-in declaration 'void* __cxxabiv1::__dynamic_cast@hello(const void*, const __class_type_info@hello*, const __class_type_info@hello*, long int)' [-Wbuiltin-declaration-mismatch]^M FAIL: g++.dg/modules/hello-1_b.C -std=c++2b (test for excess errors) Excess errors: : warning: new declaration 'void* __cxxabiv1::__dynamic_cast(const void*, const __class_type_info*, const __class_type_info*, long int)' ambiguates built-in declaration 'void* __cxxabiv1::__dynamic_cast@hello(const void*, const __class_type_info@hello*, const __class_type_info@hello*, long int)' [-Wbuiltin-declaration-mismatch] commit fe54b57728c09ab0389e2bb3f079d5210566199d (HEAD) Author: Jonathan Wakely Date: Thu Dec 14 23:23:34 2023 + libstdc++: Implement C++23 header [PR107760]
[Bug fortran/97592] [11/12/13/14 Regression] Incorrectly set pointer remapping with array pointer argument to CONTIGUOUS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97592
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.org
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> It looks like argument association is confused here.
> (The F2018 reference is 15.5.2.3 and 15.5.2.4).
>
> The following patch appears to fix the testcase:
>
> diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
> index 06713f24f95..c7fb4633ab1 100644
> --- a/gcc/fortran/trans-expr.cc
> +++ b/gcc/fortran/trans-expr.cc
> @@ -6854,7 +6854,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
> INTENT_IN, fsym->attr.pointer);
> }
> else if (fsym && fsym->attr.contiguous
> - && !gfc_is_simply_contiguous (e, false, true)
> + && gfc_is_not_contiguous (e)
>&& gfc_expr_is_variable (e))
> {
> gfc_conv_subref_array_arg (, e, nodesc_arg,
>
> but unfortunately regresses on gfortran.dg/bind-c-contiguous-3.f90 :-(
This works:
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index b2463a28748..7bc6d72decc 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -7124,7 +7125,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
INTENT_IN, fsym->attr.pointer);
}
else if (fsym && fsym->attr.contiguous
- && !gfc_is_simply_contiguous (e, false, true)
+ && (fsym->attr.target
+ ? gfc_is_not_contiguous (e)
+ : !gfc_is_simply_contiguous (e, false, true))
&& gfc_expr_is_variable (e))
{
gfc_conv_subref_array_arg (, e, nodesc_arg,
[Bug target/112896] RISC-V: gcc.dg/pr30957-1.c run failure when rv64gcv_zvl1024b_zvfh_zfh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112896
Edwin Lu changed:
What|Removed |Added
CC||ewlu at rivosinc dot com
--- Comment #1 from Edwin Lu ---
(In reply to Li Pan from comment #0)
> The gcc.dg/pr30957-1.c test case is failed in RISC-V backend when build with
> below options.
>
> -march=rv64gcv_zvl1024b_zvfh_zfh -mabi=lp64d -O2 -mcmodel=medlow
> --param=riscv-autovec-preference=fixed-vlmax -funroll-loops
> -fassociative-math -fno-trapping-math -fno-signed-zeros
> -fvariable-expansion-in-unroller -fdump-rtl-expand-details -lm
> gcc/testsuite/gcc.dg/pr30957-1.c -o test.elf
>
> The test gcc/testsuite/gcc.dg/pr30957-1.c may be similar as below.
>
> float __attribute__((noinline))
> foo (float d, int n)
> {
> unsigned i;
> float accum = d;
>
> for (i = 0; i < n; i++)
> accum += d;
>
> return accum;
> }
>
> int
> main ()
> {
> /* When compiling standard compliant we expect foo to return -0.0. But the
> variable expansion during unrolling optimization (for this testcase
> enabled
> by non-compliant -fassociative-math) instantiates copy(s) of the
> accumulator which it initializes with +0.0. Hence we expect that foo
> returns +0.0. */
> if (__builtin_copysignf (1.0, foo (0.0 / -5.0, 10)) != 1.0)
> abort ();
> exit (0);
> }
>
> Have an initial investigation that RISC-V backend always get LPT_NONE when
> unroll_loops, as the step of loop will be dynamic after vectorizing, and get
> the simple loop flag as false, then the pass unroll_loops will do nothing
> for non simple loop.
>
> We may need further investigation for this case.
Our postcommit ci recently identified the testcase aborts on several other
configurations now.
Additional targets (linux and newlib):
- rv64gcv
- rv64 Vector Crypto
- rv64 RVA23U64 Profile
Logs and testsuite report can be found
https://github.com/patrick-rivos/gcc-postcommit-ci/issues/290
[Bug target/105733] riscv: Poor codegen for large stack frames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733 Vineet Gupta changed: What|Removed |Added CC||vineetg at gcc dot gnu.org --- Comment #4 from Vineet Gupta --- There has been good improvements in gcc codegen specially with commit below. commit 6619b3d4c15cd754798b1048c67f3806bbcc2e6d Author: Jivan Hakobyan Date: Wed Aug 23 14:10:30 2023 -0600 Improve quality of code from LRA register elimination This is primarily Jivan's work, I'm mostly responsible for the write-up and coordinating with Vlad on a few questions. On targets with limitations on immediates usable in arithmetic instructions, LRA's register elimination phase can construct fairly poor code. Tip W/o commit 6619b3d4c| With 6619b3d4c | foo: | foo: li t0,-4096 | li t0,-4096 addit0,t0,2032 | addit0,t0,2032 li a5,0 | li a4,0 | add sp,sp,t0 | add sp,sp,t0 add a4,a4,a5 | add a5,a4,sp | add a5,a5,a0 add a5,a5,a0 | li t0,4096 | li t0,4096 sb zero,0(a5) | sb zero,0(a5) addit0,t0,-2032 | addit0,t0,-2032 add sp,sp,t0 | add sp,sp,t0 jr ra | jr ra We still have the weird LUI 4096 based constant construction. I have a patch to avoid 4096 for certain ranges [-4096,-2049] or [2048,4094] (cribbed from llvm). e.g. 2064 = 2047 + 17 and we could potentially "spread" the 2 parts over 2 adds to SP, avoiding the LUI. However if a const costs more than 1 insn, gcc wants to force it in a register rather than split the add operation into 2 adds with the split constants. expand_binop expand_binop_directly avoid_expensive_constant /* X is to be used in mode MODE as operand OPN to BINOPTAB. If we're optimizing, and if the operand is a constant that costs more than 1 instruction, force the constant into a register and return that register. Return X otherwise. UNSIGNEDP says whether X is unsigned. */
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #33 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #32) > commit a1f0d227481fe143f8c15b3f268e2d5964a3c90a (HEAD -> master, > origin/master, origin/HEAD) > Author: Jerry DeLisle > Date: Fri Dec 15 13:05:18 2023 -0800 > > fortran: Update degree trigs documentation. > > This is only some cleanup. > > gcc/fortran/ChangeLog: > > PR fortran/112783 > > * intrinsic.texi: Fix where no COMPLEX allowed. > * invoke.texi: Clarify -fdev-math. > > I fat fingered the PR number, sigh. You can always --amend before pushing.
[Bug target/110201] RISC-V: __builtin_riscv_sm4ks and __builtin_riscv_sm4ed produce invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110201 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Jeffrey A. Law --- Should (finally) be fixed on the trunk.
[Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 Lewis Hyatt changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Decembe ||r/639467.html --- Comment #4 from Lewis Hyatt --- I submitted the simple patch to resolve the ICE here: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639467.html
[Bug target/110201] RISC-V: __builtin_riscv_sm4ks and __builtin_riscv_sm4ed produce invalid assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110201 --- Comment #8 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:082835836cf763e74ed2fdf9645ac4f1f94d6d4f commit r14-6607-g082835836cf763e74ed2fdf9645ac4f1f94d6d4f Author: Jeff Law Date: Fri Dec 15 14:19:25 2023 -0700 Re: [PATCH] RISC-V: fix scalar crypto patterns A handful of the scalar crypto instructions are supposed to take a constant integer argument 0..3 inclusive and one should accept 0..10. A suitable constraint was created and used for this purpose (D03 and DsA), but the operand's predicate is "register_operand". That's just wrong. This patch adds a new predicates "const_0_3_operand" and "const_0_10_operand" and fixes the relevant insns to use the appropriate predicate. It drops the now unnecessary constraints. The testsuite was broken in a way that made it consistent with the compiler, so the tests passed, when they really should have been issuing errors all along. This patch adjusts the existing tests so that they all expect a diagnostic on the invalid operand usage (including out of range constants). It adds new tests with proper constants, testing the extremes of valid values. PR target/110201 gcc/ * config/riscv/constraints.md (D03, DsA): Remove unused constraints. * config/riscv/predicates.md (const_0_3_operand): New predicate. (const_0_10_operand): Likewise. * config/riscv/crypto.md (riscv_aes32dsi): Use new predicate. Drop unnecessary constraint. (riscv_aes32dsmi, riscv_aes64im, riscv_aes32esi): Likewise. (riscv_aes32esmi, *riscv__si): Likewise. (riscv__di_extend, riscv__si): Likewise. gcc/testsuite * gcc.target/riscv/zknd32.c: Verify diagnostics are issued for invalid builtin arguments. * gcc.target/riscv/zknd64.c: Likewise. * gcc.target/riscv/zkne32.c: Likewise. * gcc.target/riscv/zkne64.c: Likewise. * gcc.target/riscv/zksed32.c: Likewise. * gcc.target/riscv/zksed64.c: Likewise. * gcc.target/riscv/zknd32-2.c: New test * gcc.target/riscv/zknd64-2.c: Likewise. * gcc.target/riscv/zkne32-2.c: Likewise. * gcc.target/riscv/zkne64-2.c: Likewise. * gcc.target/riscv/zksed32-2.c: Likewise. * gcc.target/riscv/zksed64-2.c: Likewise. Co-authored-by: Liao Shihua
[Bug ipa/112783] core dump on libxo when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- (In reply to GCC Commits from comment #7) > The master branch has been updated by Jerry DeLisle : > > https://gcc.gnu.org/g:a1f0d227481fe143f8c15b3f268e2d5964a3c90a > > commit r14-6606-ga1f0d227481fe143f8c15b3f268e2d5964a3c90a > Author: Jerry DeLisle > Date: Fri Dec 15 13:05:18 2023 -0800 > > fortran: Update degree trigs documentation. > > This is only some cleanup. > > gcc/fortran/ChangeLog: > > PR fortran/112783 > > * intrinsic.texi: Fix where no COMPLEX allowed. > * invoke.texi: Clarify -fdev-math. Typoe the PR number. Ignore should be 112873
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #32 from Jerry DeLisle --- commit a1f0d227481fe143f8c15b3f268e2d5964a3c90a (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Fri Dec 15 13:05:18 2023 -0800 fortran: Update degree trigs documentation. This is only some cleanup. gcc/fortran/ChangeLog: PR fortran/112783 * intrinsic.texi: Fix where no COMPLEX allowed. * invoke.texi: Clarify -fdev-math. I fat fingered the PR number, sigh.
[Bug ipa/112783] core dump on libxo when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 --- Comment #7 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:a1f0d227481fe143f8c15b3f268e2d5964a3c90a commit r14-6606-ga1f0d227481fe143f8c15b3f268e2d5964a3c90a Author: Jerry DeLisle Date: Fri Dec 15 13:05:18 2023 -0800 fortran: Update degree trigs documentation. This is only some cleanup. gcc/fortran/ChangeLog: PR fortran/112783 * intrinsic.texi: Fix where no COMPLEX allowed. * invoke.texi: Clarify -fdev-math.
[Bug analyzer/112792] -Wanalyzer-out-of-bounds false positives seen on Linux kernel with certain unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112792 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-12-15 --- Comment #1 from David Malcolm --- Am testing a fix.
[Bug target/112944] AVR: Support .rodata in Flash for Devices with FLMAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944 Georg-Johann Lay changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-12-15 Status|UNCONFIRMED |ASSIGNED
[Bug target/112918] [m68k] [LRA] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918 --- Comment #12 from Vladimir Makarov --- I've been working on the PR this week. The problem for this case is in that for subreg reload LRA can not narrow reg class more from ALL_REGS to GENERAL_REGS and then to data regs or address regs. The patch will be ready today but I am going to test it well and submit it on Monday as it changes a sensitive part of LRA and might be risky.
[Bug target/109796] 548.exchange2_r compiled with -O2 -flto regressed by 5% on aarch64 between r14-135-gd06e9264b0192c and r14-192-g636e2273aec555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109796 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Looks like this has been resolved.
[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 109796, which changed state. Bug 109796 Summary: 548.exchange2_r compiled with -O2 -flto regressed by 5% on aarch64 between r14-135-gd06e9264b0192c and r14-192-g636e2273aec555 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109796 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/113021] [constexpr] gcc rejects initializing struct containing vector during constant evaluation depending if the struct also contains other member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113021 --- Comment #4 from Andrew Pinski --- Looks like it is the uninitialized field pointer which is causing the issues. Looks like GCC does not currently fully support that for const variables inside a constexpr/consteval . The linked PRs are about string but I think the same issue shows up.
[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113009 Edwin Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Edwin Lu --- (In reply to JuzheZhong from comment #5) > I don't see this dump FAIL in the trunk now. > > Could you confirm it ? Ran 1000 times on r14-6596-g7d7a480eedf and don't see it anymore. Thanks!
[Bug ada/113037] New: GNAT BUG DETECTED when instantiating generic package with Type_Invariant on a type derived from a generic type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113037 Bug ID: 113037 Summary: GNAT BUG DETECTED when instantiating generic package with Type_Invariant on a type derived from a generic type Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: saulius.grazulis at bti dot vu.lt CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 56890 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56890=edit A Minimal Working Example, for 'gnatchop' When a generic package with a Type_Invariant on a declared type is instantiated, a GNAT BUG DETECTED box is triggered: + gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/saulius/install/gcc/gcc-13.2.0-git-master-d1647917006/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/home/saulius/install/gcc/gcc-13.2.0-git-master-d1647917006 --enable-languages=c,c++,ada,fortran --disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20231214 (experimental) (GCC) + uname -a Linux tasmanijos-velnias 5.4.0-167-generic #184-Ubuntu SMP Tue Oct 31 09:21:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux + lsb_release -a No LSB modules are available. Distributor ID: Linuxmint Description:Linux Mint 20.1 Release:20.1 Codename: ulyssa + gnatmake extended_euklidean_gen gcc -c extended_euklidean_gen.adb +===GNAT BUG DETECTED==+ | 14.0.0 20231214 (experimental) (x86_64-pc-linux-gnu) Assert_Failure exp_util.adb:3693| | Error detected at extended_euklidean_generic.ads:15:4 [extended_euklidean_gen.adb:12:4]| | Compiling extended_euklidean_gen.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). extended_euklidean_gen.adb extended_euklidean_generic.ads compilation abandoned gnatmake: "extended_euklidean_gen.adb" compilation error $ cat extended_euklidean_gen.adb pragma Ada_2022; with Ada.Numerics.Big_Numbers.Big_Integers; use Ada.Numerics.Big_Numbers.Big_Integers; with Extended_Euklidean_Generic; procedure Extended_Euklidean_Gen is type Number is new Big_Integer; package Extended_Euklidean is new Extended_Euklidean_Generic (Number, 0, 1); begin null; end Extended_Euklidean_Gen; $ cat extended_euklidean_generic.ads generic type Number is private; Zero : Number; Unity : Number; with function "-" (A, B : Number) return Number is <>; with function ">" (A, B : Number) return Boolean is <>; package Extended_Euklidean_Generic is type Positive_Number is new Number with Type_Invariant => Number (Positive_Number) > Zero; procedure GCD ( A, B : in Positive_Number; -- original numbers D: out Positive_Number; -- GCD of the two numbers A and B M, N : out Number -- Bézout coefficients: A * M + B * N = D ); end Extended_Euklidean_Generic; $ cat extended_euklidean_generic.adb package body Extended_Euklidean_Generic is -- Test implementaion of the Extended Euclidean Algorithm. -- URL: https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm procedure GCD ( A, B : in Positive_Number; -- original numbers D: out Positive_Number; -- GCD of the two numbers A and B M, N : out Number -- Bézout coefficients: A * M + B * N = D ) is P : Number := Unity; -- X = P*A + Q*B at any point Q : Number := Zero; S : Number := Zero; -- Y = S*A + T*B at any point T : Number := Unity; X : Positive_Number := A; Y : Positive_Number := B; begin while X /= Y loop if X > Y then X := X - Y; P := P - S; Q := Q - T; else Y := Y - X; S := S - P; T := T - Q; end if; end loop; D := X; M := P; N := Q; -- The naive computation of the N value can overflow: -- N := (X - P*A) / B; pragma
[Bug ada/113036] New: GNAT BUG DETECTED ICE box triggered by a default value that is a nested iterated aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113036 Bug ID: 113036 Summary: GNAT BUG DETECTED ICE box triggered by a default value that is a nested iterated aggregate Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: saulius.grazulis at bti dot vu.lt CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 56889 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56889=edit A Minimal Working Example When a discriminated record type has an 2D array a as a component, and a default initialization value with nested iterated arrays is provided, a GNAT BUG DETECTED box is triggered: + gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/saulius/install/gcc/gcc-13.2.0-git-master-d1647917006/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/home/saulius/install/gcc/gcc-13.2.0-git-master-d1647917006 --enable-languages=c,c++,ada,fortran --disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20231214 (experimental) (GCC) + uname -a Linux tasmanijos-velnias 5.4.0-167-generic #184-Ubuntu SMP Tue Oct 31 09:21:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux + lsb_release -a No LSB modules are available. Distributor ID: Linuxmint Description:Linux Mint 20.1 Release:20.1 Codename: ulyssa + gnatmake pm_type_default_not_ok.adb gcc -c pm_type_default_not_ok.adb +===GNAT BUG DETECTED==+ | 14.0.0 20231214 (experimental) (x86_64-pc-linux-gnu) Assert_Failure failed precondition from sinfo-nodes.ads:3628| | Error detected at pm_type_default_not_ok.adb:9:4 | | Compiling pm_type_default_not_ok.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). pm_type_default_not_ok.adb compilation abandoned gnatmake: "pm_type_default_not_ok.adb" compilation error $ cat pm_type_default_not_ok.adb pragma Ada_2022; procedure PM_Type_Default_Not_OK is type One_Or_Zero is range 0 .. 1; type Permutation_Matrix_Array is array (Positive range <>, Positive range <>) of One_Or_Zero; type Permutation_Matrix (N : Positive) is record A : Permutation_Matrix_Array (1 .. N, 1 .. N) := (for I in 1 .. N => (for J in 1 .. N => 0)); end record; begin null; end; Not nesting the value, (e.g. having (others => 0)), or using the same iterated expression in an assignment (as opposed to initialization) works OK.
[Bug target/113035] New: RISC-V: -mtune=sifive-7-series additional dump failures found with bitmanip, zicond, and vector targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113035 Bug ID: 113035 Summary: RISC-V: -mtune=sifive-7-series additional dump failures found with bitmanip, zicond, and vector targets Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ewlu at rivosinc dot com Target Milestone: --- Created attachment 56888 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56888=edit testsuite failures for rv64 bitmanip and vector as of r14-6557-g767e2674875 I was testing different cpu/tunes for cleaning up the scheduler and saw that there are significant differences in testsuite results between using mtune=rocket (default) and mtune=sifive-7-series. Most notably, there are many failures in gcc.target/riscv/rvv/vsetvl, gcc.target/riscv/zicond-primitiveSemantics_compare_*.c, and some with zbb and zbs. Full log output included in attachment Configuration: riscv-sim/-march=rv64gc_zba_zbb_zbc_zbs/-mabi=lp64d/-mtune=sifive-7-series/-mcpu=sifive-u74/-mcmodel=medlow riscv-sim/-march=rv64gcv/-mabi=lp64d/-mtune=sifive-7-series/-mcpu=sifive-u74/-mcmodel=medlow
[Bug tree-optimization/54742] Switch elimination in FSM loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/113034] New: Miscompilation of __m128 ne comparison on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113034
Bug ID: 113034
Summary: Miscompilation of __m128 ne comparison on LoongArch
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: c at jia dot je
Target Milestone: ---
Compile and run the following code:
```
#include
#include
__m128i unord_vec(__m128 a, __m128 b) { return (a != a) | (b != b); }
int unord_float(float a, float b) { return (a != a) | (b != b); }
int main() {
float nan = 0.0 / 0.0; // nan
__m128 nan_vec = {nan, nan};
int res_float = unord_float(nan, nan);
__m128i res_vec = unord_vec(nan_vec, nan_vec);
printf("%d %ld %ld\n", res_float, res_vec[0], res_vec[1]);
return 0;
}
```
Compile commands: `gcc-14 -mlsx test.c -O -o test`. GCC version is 14.0.0
202231203 snapshot.
It does the `unordered` comparison between two floats. The expected output:
```
1 1 1
```
Actual output:
```
1 0 0
```
Reading the assembly, the `unord_vec` is implemented wrongly as `vfcmp.cne.s`:
```
unord_vec:
.LFB538 = .
.cfi_startproc
vinsgr2vr.d $vr0,$r4,0
vinsgr2vr.d $vr0,$r5,1
vinsgr2vr.d $vr1,$r6,0
vinsgr2vr.d $vr1,$r7,1
vfcmp.cne.s $vr0,$vr0,$vr0
vfcmp.cne.s $vr1,$vr1,$vr1
vor.v $vr0,$vr0,$vr1
vpickve2gr.du $r4,$vr0,0
vpickve2gr.du $r5,$vr0,1
jr $r1
.cfi_endproc
```
Whereas `unord_float` is correctly implemented as `fcmp.cune.s`:
```
unord_float:
.LFB539 = .
.cfi_startproc
addi.w $r4,$r0,1 # 0x1
fcmp.cune.s $fcc0,$f0,$f0
bcnez $fcc0,.L3
or $r4,$r0,$r0
.L3:
addi.w $r12,$r0,1 # 0x1
fcmp.cune.s $fcc1,$f1,$f1
bcnez $fcc1,.L4
or $r12,$r0,$r0
.L4:
or $r4,$r4,$r12
andi$r4,$r4,1
jr $r1
.cfi_endproc
```
So there is a mismatch on the `unordered` case. Besides, these functions can be
optimized to use `vfcmp.cun.s` and `fcmp.cun.s`.
[Bug c++/113032] RISCV linker relaxation leaves redundant addi (from load immediate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113032 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- The linker is part of the GNU binutils project, please report this issue to them instead; https://sourceware.org/bugzilla .
[Bug c++/83417] Pointer-to-member template parameter with auto member type dependent container type does not work (C++17)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83417
waffl3x changed:
What|Removed |Added
CC||waffl3x at protonmail dot com
--- Comment #5 from waffl3x ---
https://godbolt.org/z/Kxco7c5Es
Still not working in trunk, was it ever decided on whether or not this
is well-formed?
```
template struct C {};
template
void zoink(C) { }
struct S { int _m; };
void go() { zoink(C<::_m>{}); }
```
https://godbolt.org/z/ohG9ra5en
This is the workaround I would use, it has better ergonomics anyway. I
believe we should decide on whether this truly is a bug or not and if
not just simply close it.
Credit to Tsche for pointing this case out to me.
[Bug target/113033] New: GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113033
Bug ID: 113033
Summary: GCC 14 (20231203 snapshot) ICE when building LSX
vector rotate code on LoongArch
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: c at jia dot je
Target Milestone: ---
Source code:
```
#include
v2u64 test(v2u64 a, int imm) {
return (a << (imm & 63)) | (a >> (64 - (imm & 63)));
}
```
Command line to reproduce:
```
gcc-14 -mlsx -c test.c
```
Error message:
```
test.c: In function ‘test’:
test.c:5:1: error: unrecognizable insn:
5 | }
| ^
(insn 16 15 17 2 (set (reg:DI 92)
(and:DI (neg:DI (reg:DI 80 [ _1 ]))
(const_int 63 [0x3f]))) "test.c":4:28 -1
(nil))
during RTL pass: vregs
test.c:5:1: internal compiler error: in extract_insn, at recog.cc:2804
0x591d419f internal_error(char const*, ...)
???:0
0x577b4d87 fancy_abort(char const*, int, char const*)
???:0
0x577998bb _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x577998ef _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
???:0
0x580704f7 extract_insn(rtx_insn*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/113032] New: RISCV linker relaxation leaves redundant addi (from load immediate)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113032 Bug ID: 113032 Summary: RISCV linker relaxation leaves redundant addi (from load immediate) Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iwfinlay at gmail dot com Target Milestone: --- Created attachment 56887 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56887=edit Source files and save-temps for ELF build In the ELF image for RISCV 32-bit, the lower 12-bit parts of a load immediate are zero but not removed. Hence, it appears as a 'mv' in the objdump of the program ELF. 20010064 <_Z6globalv>: 20010064: 8537lui a0,0x8 20010068: 00050513mv a0,a0 <-- (1) 2001006c: 8067ret 20010070 <_Z4initv>: 20010070: 87b7lui a5,0x8 20010074: 00078793mv a5,a5 <-- (2) 20010078: 3e700713li a4,999 2001007c: 00e7a223sw a4,4(a5) # 8004 <__global_pointer$+0xf804> 20010080: 0ea00713li a4,234 20010084: 00e7a423sw a4,8(a5) 20010088: 8067ret 2001008c <_Z5pcnt0v>: 2001008c: 87b7lui a5,0x8 20010090: 00078793mv a5,a5 <-- (3) 20010094: 0047a703lw a4,4(a5) # 8004 <__global_pointer$+0xf804> 20010098: 60271713cpopa4,a4 The command line is: riscv64-unknown-elf-g++ --save-temps -march=rv32imv_zbb_zbs -mabi=ilp32 -O3 -Wall -Wextra -o relax.elf main.cpp test.cpp startup.cpp -fno-builtin -static -fno-common -mcmodel=medlow -nostdlib -T link.ld The behavior is the same if I drop -fno-builtin -fno-common -mcmodel (just need to provide memset). I'm attaching a tar-file for the above. I reviewed 91713 but concluded that it's different. I also filed yesterday. I apologize for wasting reviewer time. It's the same test case but I'm now including the main to show overall optimization. Thanks for the previous feedback.
[Bug modula2/112946] Assignment of string to enumeration or set crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112946 --- Comment #5 from gaiusmod2 at gmail dot com --- many thanks for the bug report - all fixed in gcc master branch.
[Bug modula2/112946] Assignment of string to enumeration or set crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112946 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Gaius Mulley --- Closing now the patch has been applied.
[Bug modula2/112946] Assignment of string to enumeration or set crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112946 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:7d7a480eedf0a195318d0fce2c9c57acae43ec9d commit r14-6596-g7d7a480eedf0a195318d0fce2c9c57acae43ec9d Author: Gaius Mulley Date: Fri Dec 15 15:26:48 2023 + PR modula2/112946 ICE assignment of string to enumeration or set This patch introduces type checking during FoldBecomes and also adds set/string/enum checking to the type checker. FoldBecomes has been re-written, tidied up and re-factored. gcc/m2/ChangeLog: PR modula2/112946 * gm2-compiler/M2Check.mod (checkConstMeta): New procedure function. (checkConstEquivalence): New procedure function. (doCheckPair): Add call to checkConstEquivalence. * gm2-compiler/M2GenGCC.mod (ResolveConstantExpressions): Call FoldBecomes with reduced parameters. (FoldBecomes): Re-write. (TryDeclareConst): New procedure. (RemoveQuads): New procedure. (DeclaredOperandsBecomes): New procedure function. (TypeCheckBecomes): New procedure function. (PerformFoldBecomes): New procedure. * gm2-compiler/M2Range.mod (FoldAssignment): Call AssignmentTypeCompatible to check des expr compatibility. * gm2-compiler/M2SymInit.mod (CheckReadBeforeInitQuad): Remove parameter lst. (FilterCheckReadBeforeInitQuad): Remove parameter lst. (CheckReadBeforeInitFirstBasicBlock): Remove parameter lst. Call FilterCheckReadBeforeInitQuad without lst. gcc/testsuite/ChangeLog: PR modula2/112946 * gm2/iso/fail/badassignment.mod: New test. * gm2/iso/fail/badexpression.mod: New test. * gm2/iso/fail/badexpression2.mod: New test. Signed-off-by: Gaius Mulley
[Bug modula2/112946] Assignment of string to enumeration or set crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112946 --- Comment #2 from Gaius Mulley --- Created attachment 56886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56886=edit Proposed fix Here is the proposed fix.
[Bug c++/70435] section attribute of a function template is not honored.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70435 --- Comment #9 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ea7bebff7cc5a5eb780a6ca646cb77cad1b625d6 commit r14-6595-gea7bebff7cc5a5eb780a6ca646cb77cad1b625d6 Author: Patrick Palka Date: Fri Dec 15 10:03:31 2023 -0500 c++: section attribute on templates [PR70435, PR88061] The section attribute currently has no effect on templates because the call to set_decl_section_name only happens at parse time (on the dependent decl) and not also at instantiation time. This patch fixes this by propagating the section name from the template to the instantiation. PR c++/70435 PR c++/88061 gcc/cp/ChangeLog: * pt.cc (tsubst_function_decl): Propagate DECL_SECTION_NAME via set_decl_section_name. (tsubst_decl) : Likewise. gcc/testsuite/ChangeLog: * g++.dg/ext/attr-section1.C: New test. * g++.dg/ext/attr-section1a.C: New test. * g++.dg/ext/attr-section2.C: New test. * g++.dg/ext/attr-section2a.C: New test. * g++.dg/ext/attr-section2b.C: New test.
[Bug c++/88061] section attributes of variable templates are ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88061 --- Comment #9 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ea7bebff7cc5a5eb780a6ca646cb77cad1b625d6 commit r14-6595-gea7bebff7cc5a5eb780a6ca646cb77cad1b625d6 Author: Patrick Palka Date: Fri Dec 15 10:03:31 2023 -0500 c++: section attribute on templates [PR70435, PR88061] The section attribute currently has no effect on templates because the call to set_decl_section_name only happens at parse time (on the dependent decl) and not also at instantiation time. This patch fixes this by propagating the section name from the template to the instantiation. PR c++/70435 PR c++/88061 gcc/cp/ChangeLog: * pt.cc (tsubst_function_decl): Propagate DECL_SECTION_NAME via set_decl_section_name. (tsubst_decl) : Likewise. gcc/testsuite/ChangeLog: * g++.dg/ext/attr-section1.C: New test. * g++.dg/ext/attr-section1a.C: New test. * g++.dg/ext/attr-section2.C: New test. * g++.dg/ext/attr-section2a.C: New test. * g++.dg/ext/attr-section2b.C: New test.
[Bug c++/109715] abi_tag attribute is not applied to variable templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109715 --- Comment #1 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:46984fa259436ad50afb50a46a0a16e83bdf7172 commit r14-6594-g46984fa259436ad50afb50a46a0a16e83bdf7172 Author: Patrick Palka Date: Fri Dec 15 10:03:26 2023 -0500 c++: abi_tag attribute on templates [PR109715] We need to look through TEMPLATE_DECL when looking up the abi_tag attribute (as with other function/variable declaration attributes). PR c++/109715 gcc/cp/ChangeLog: * mangle.cc (get_abi_tags): Strip TEMPLATE_DECL before looking up the abi_tag attribute. gcc/testsuite/ChangeLog: * g++.dg/abi/abi-tag25.C: New test. * g++.dg/abi/abi-tag25a.C: New test.
[Bug c/44179] warn about sizeof(char) and sizeof('x')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
--- Comment #3 from Zack Weinberg ---
It's come to my attention that people fairly often write `sizeof('x')` (or some
other character constant), _expecting_ it to evaluate as `sizeof(char)`. But
this is only true in C++. In C, `sizeof('x')` evaluates as `sizeof(int)`.
See
http://codesearch.debian.net/search?q=filetype%3Ac+%5Cbsizeof%5Cs*%5C%28%5Cs*%27=0
for many examples.
It's probably more important to warn about this than about `sizeof(char)`
itself.
[Bug sanitizer/112727] [11/12/13 Regression] UBSAN creates GIMPLE path with uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112727 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a982b9cb690a163434f1ac5a0901548b594205f2 commit r13-8160-ga982b9cb690a163434f1ac5a0901548b594205f2 Author: Jakub Jelinek Date: Fri Dec 8 20:56:48 2023 +0100 c++: Unshare folded SAVE_EXPR arguments during cp_fold [PR112727] The following testcase is miscompiled because two ubsan instrumentations run into each other. The first one is the shift instrumentation. Before the C++ FE calls it, it wraps the 2 shift arguments with cp_save_expr, so that side-effects in them aren't evaluated multiple times. And, ubsan_instrument_shift itself uses unshare_expr on any uses of the operands to make sure further modifications in them don't affect other copies of them (the only not unshared ones are the one the caller then uses for the actual operation after the instrumentation, which means there is no tree sharing). Now, if there are side-effects in the first operand like say function call, cp_save_expr wraps it into a SAVE_EXPR, and ubsan_instrument_shift in this mode emits something like if (..., SAVE_EXPR , SAVE_EXPR > const) __ubsan_handle_shift_out_of_bounds (..., SAVE_EXPR , ...); and caller adds SAVE_EXPR << SAVE_EXPR after it in a COMPOUND_EXPR. So far so good. If there are no side-effects and cp_save_expr doesn't create SAVE_EXPR, everything is ok as well because of the unshare_expr. We have if (..., SAVE_EXPR > const) __ubsan_handle_shift_out_of_bounds (..., ptr->something[i], ...); and ptr->something[i] << SAVE_EXPR where ptr->something[i] is unshared. In the testcase below, the !x->s[j] ? 1 : 0 expression is wrapped initially into a SAVE_EXPR though, and unshare_expr doesn't unshare SAVE_EXPRs nor anything used in them for obvious reasons, so we end up with: if (..., SAVE_EXPR (x)->s[j] ? 1 : 0>, SAVE_EXPR > const) __ubsan_handle_shift_out_of_bounds (..., SAVE_EXPR (x)->s[j] ? 1 : 0>, ...); and SAVE_EXPR (x)->s[j] ? 1 : 0> << SAVE_EXPR So far good as well. But later during cp_fold of the SAVE_EXPR we find out that VIEW_CONVERT_EXPR(x)->s[j] ? 0 : 1 is actually invariant (has TREE_READONLY set) and so cp_fold simplifies the above to if (..., SAVE_EXPR > const) __ubsan_handle_shift_out_of_bounds (..., (bool) VIEW_CONVERT_EXPR(x)->s[j] ? 0 : 1, ...); and ((bool) VIEW_CONVERT_EXPR(x)->s[j] ? 0 : 1) << SAVE_EXPR with the s[j] ARRAY_REFs and other expressions shared in between the two uses (and obviously the expression optimized away from the COMPOUND_EXPR in the if condition. Then comes another ubsan instrumentation at genericization time, this time to instrument the ARRAY_REFs with strict bounds checking, and replaces the s[j] in there with s[.UBSAN_BOUNDS (0B, SAVE_EXPR, 8), SAVE_EXPR] As the trees are shared, it does that just once though. And as the if body is gimplified first, the SAVE_EXPR is evaluated inside of the if body and when it is used again after the if, it uses a potentially uninitialized value of j.1 (always uninitialized if the shift count isn't out of bounds). The following patch fixes that by unshare_expr unsharing the folded argument of a SAVE_EXPR if we've folded the SAVE_EXPR into an invariant and it is used more than once. 2023-12-08 Jakub Jelinek PR sanitizer/112727 * cp-gimplify.cc (cp_fold): If SAVE_EXPR has been previously folded, unshare_expr what is returned. * c-c++-common/ubsan/pr112727.c: New test. (cherry picked from commit 6ddaf06e375e1c15dcda338697ab6ea457e6f497)
[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733
--- Comment #16 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:8c0ea9320ce4d2381ebf043cd20a0afce88da880
commit r13-8159-g8c0ea9320ce4d2381ebf043cd20a0afce88da880
Author: Jakub Jelinek
Date: Wed Nov 29 12:26:50 2023 +0100
fold-const: Fix up multiple_of_p [PR112733]
We ICE on the following testcase when wi::multiple_of_p is called on
widest_int 1 and -128 with UNSIGNED. I still need to work on the
actual wide-int.cc issue, the latest patch attached to the PR regressed
bitint-{38,39}.c, so will need to debug that, but there is a clear bug
on the fold-const.cc side as well - widest_int is a signed representation
by definition, using UNSIGNED with it certainly doesn't match what was
intended, because -128 as the second operand effectively means unsigned
131072 bit 0xf80 integer, not the signed char -128
that appeared in the source.
In the INTEGER_CST case a few lines above this we already use
case INTEGER_CST:
if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom))
return false;
return wi::multiple_of_p (wi::to_widest (top), wi::to_widest
(bottom),
SIGNED);
so I think using SIGNED with widest_int is best there (compared to the
other choices in the PR).
2023-11-29 Jakub Jelinek
PR middle-end/112733
* fold-const.cc (multiple_of_p): Pass SIGNED rather than
UNSIGNED for wi::multiple_of_p on widest_int arguments.
* gcc.dg/pr112733.c: New test.
(cherry picked from commit 5c95bf945c632925efba86dd5dceccdb9da8884c)
[Bug tree-optimization/107699] [12/13/14 Regression] False positive -Warray-bounds, non-existent offset reported by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #13 from Richard Biener ---
(In reply to Carlos Galvez from comment #11)
> Consider this more realistic example:
>
> https://godbolt.org/z/jbbqbe8d9
>
> The compiler has all the information available to ensure that
> getCount().get() is smaller than 3, as enforced by the class invariant which
> is visible to the compiler. Class invariants help us not having to check
> things all the time. For example gsl::not_null allows us to not have to
> check for nullptr on every use.
This doesn't really change anything as the compiler doesn't see the
CTOR invoked or that 'x' isn't changed before being returned.
I think we want to somehow prevent the diagnostic on the library side.
This particular case is
/// This is a helper function for the sort routine.
template
_GLIBCXX20_CONSTEXPR
void
__final_insertion_sort(_RandomAccessIterator __first,
_RandomAccessIterator __last, _Compare __comp)
{
if (__last - __first > int(_S_threshold))
{
std::__insertion_sort(__first, __first + int(_S_threshold), __comp);
std::__unguarded_insertion_sort(__first + int(_S_threshold), __last,
__comp);
}
else
std::__insertion_sort(__first, __last, __comp);
where we diagnose __first + int(_S_threshold) when that's visibly out-of-bounds
but __last - __first isn't constant. I'm not exactly sure how
(I'm also not sure why we do the above thing, handling the first elements
separate from the rest...)?
[Bug tree-optimization/113013] [12/13/14 regression] ICE in fold_convert_loc with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113013 --- Comment #6 from Siddhesh Poyarekar --- Sorry I misread the reproducer as void *reallocarray(void) __attribute__((__alloc_size__(1))); Your fix looks fine to me, thanks.
[Bug c++/113031] [14 Regression] ICE in cxx_fold_indirect_ref_1 starting with r14-6508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113031 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-12-15 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- That was quick, thanks!
[Bug c++/113031] [14 Regression] ICE in cxx_fold_indirect_ref_1 starting with r14-6508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113031
--- Comment #2 from Nathaniel Shead ---
Reduced to:
template class variant;
template
auto __variant_cast(_Tp __rhs) { return static_cast&&>(__rhs);
}
template
struct _Move_assign_base : _Types {
void operator=(_Move_assign_base __rhs) { __variant_cast<_Types>(__rhs); }
};
template
struct variant : _Move_assign_base<_Types> {
void emplace() {
variant __tmp;
*this = __tmp;
}
};
struct _Undefined_class {
struct _Nocopy_types {
void (_Undefined_class::*_M_member_pointer)();
};
struct function : _Nocopy_types {
struct optional {
void test03() {
variant v;
v.emplace();
}
};
};
};
The following patch seems to fix the immediate problem (but not yet fully
regtested):
diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index e1b2d27fc36..051f73fb73f 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -5709,7 +5709,8 @@ cxx_fold_indirect_ref_1 (const constexpr_ctx *ctx,
location_t loc, tree type,
}
/* Handle conversion to "as base" type. */
- if (CLASSTYPE_AS_BASE (optype) == type)
+ if (CLASS_TYPE_P (optype)
+ && CLASSTYPE_AS_BASE (optype) == type)
return op;
/* Handle conversion to an empty base class, which is represented with a
[Bug tree-optimization/107986] [12/13/14 Regression] Bogus -Warray-bounds diagnostic with std::sort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986 --- Comment #11 from Richard Biener --- We now diagnose std::__insertion_sort.isra (, [(void *) + 64B]); the reason is still the same, failure to compute a range for 'qa' which we fail to SCEV analyze. There's a duplicate bug about this.
[Bug tree-optimization/99919] [11/12/13/14 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2021-11-30 00:00:00 |2023-12-15
CC||jamborm at gcc dot gnu.org
--- Comment #10 from Richard Biener ---
This is also a missed SRA optimization. SRA produces
b$i_16 = b.i;
b$j_17 = b.j;
b.i = b$i_16;
b.j = b$j_17;
_1 = VIEW_CONVERT_EXPR(b);
_2 = _1 & 1;
...
b.i = b$i_16;
b.j = b$j_15;
_4 = VIEW_CONVERT_EXPR(b);
_5 = _4 & 2;
which is sub-optimal - for some reason it chooses to create replacements
for i and j instead of a unsigned char replacement for the whole
aggregate driven by the V_C_E access
access { base = (2771)'b', offset = 0, size = 8, expr = b, type = struct B,
reverse = 0, grp_read = 1, grp_write = 0, grp_assignment_read = 1,
grp_assignment_write = 0, grp_scalar_read = 0, grp_scalar_write = 0,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 0,
grp_unscalarizable_region = 0, grp_unscalarized_data = 1, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 0, grp_to_be_debug_replaced = 0}
is also odd because the access type is really 'unsigned char'? That seems
to be because
/* We need to dive through V_C_Es in order to get the size of its parameter
and not the result type. Ada produces such statements. We are also
capable of handling the topmost V_C_E but not any of those buried in other
handled components. */
if (TREE_CODE (expr) == VIEW_CONVERT_EXPR)
expr = TREE_OPERAND (expr, 0);
but I couldn't easily convince it to do sth here (and dumps turn out
empty as for reasoning of disqualification).
[Bug tree-optimization/113013] [12/13/14 regression] ICE in fold_convert_loc with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113013 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 56885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56885=edit gcc14-pr113013.patch I don't see how FEs could do anything, especially on declarations like this where the argument types aren't specified. For attributes like this, it is generally responsibility of the function using those to use it only if they are sane, and after all, even the tree-object-size.cc code does that (e.g. verify that such argument exists at all). Just doesn't check that it is convertible to sizetype.
[Bug debug/111080] [11/12 Regression] restrict qualifier causes extra debug info to happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:5c3ab44771d0524140cf2ce5de594fcf7fefcd6f commit r12-10044-g5c3ab44771d0524140cf2ce5de594fcf7fefcd6f Author: Richard Biener Date: Mon Aug 21 10:34:30 2023 +0200 debug/111080 - avoid outputting debug info for unused restrict qualified type The following applies some maintainance with respect to type qualifiers and kinds added by later DWARF standards to prune_unused_types_walk. The particular case in the bug is not handling (thus marking required) all restrict qualified type DIEs. I've found more DW_TAG_*_type that are unhandled, looked up the DWARF docs and added them as well based on common sense. PR debug/111080 * dwarf2out.cc (prune_unused_types_walk): Handle DW_TAG_restrict_type, DW_TAG_shared_type, DW_TAG_atomic_type, DW_TAG_immutable_type, DW_TAG_coarray_type, DW_TAG_unspecified_type and DW_TAG_dynamic_type as to only output them when referenced. * gcc.dg/debug/dwarf2/pr111080.c: New testcase. (cherry picked from commit bd2c4d6d8fffd5a6dae5217d6076cc4190bab13d)
[Bug tree-optimization/111137] [11/12 Regression] Wrong code at -O2/3 since r12-1000-g6924b5e6bd3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e35556c61bdeb9f41b4111fffb423a705232ab9c commit r12-10043-ge35556c61bdeb9f41b4111fffb423a705232ab9c Author: Richard Biener Date: Fri Aug 25 13:37:30 2023 +0200 tree-optimization/37 - dependence checking for SLP The following fixes a mistake with SLP dependence checking. When checking whether we can hoist loads to the first load place we special-case stores of the same instance considering them sunk to the last store place. But we fail to consider that stores from other SLP instances are sunk in a similar way. This leads us to miss the dependence between (A) and (B) in b[0][1] = 0; (A) ... _6 = b[_5 /* 0 */][0]; (B') _7 = _6 ^ 1; b[_5 /* 0 */][0] = _7; b[0][2] = 0; (A') _10 = b[_5 /* 0 */][1]; (B) _11 = _10 ^ 1; b[_5 /* 0 */][1] = _11; where the zeroing stores are sunk to (A') and the loads hoisted to (B'). The following fixes this, treating grouped stores from other instances similar to stores from our own instance. The difference is - and this is more conservative than necessary - that we don't know which stores of a group are in which SLP instance (though I believe either all of the grouped stores will be in a single SLP instance or in none at the moment), so we don't know which stores are sunk where. We simply assume they are all sunk to the last store we run into. Likewise we do not take into account that an SLP instance might be cancelled (or a grouped store not actually belong to any instance). PR tree-optimization/37 * tree-vect-data-refs.cc (vect_slp_analyze_load_dependences): Properly handle grouped stores from other SLP instances. * gcc.dg/torture/pr37.c: New testcase. (cherry picked from commit 845ee9c7107956845e487cb123fa581d9c70ea1b)
[Bug middle-end/111253] [11/12 Regression] Dodgy pointer name (*_42 = PHI ...) in -Wfree-nonheap-object diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111253 --- Comment #8 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e26608db3c2b2644decca5f49dab1e6846a9d1b0 commit r12-10041-ge26608db3c2b2644decca5f49dab1e6846a9d1b0 Author: Richard Biener Date: Thu Aug 31 13:53:21 2023 +0200 middle-end/111253 - partly revert r11-6508-gabb1b6058c09a7 The following keeps dumping SSA def stmt RHS during diagnostic reporting only for gimple_assign_single_p defs which means memory loads. This avoids diagnostics containing PHI nodes like warning: 'realloc' called on pointer '*_42 = PHI .t_mem_caches' with nonzero offset 40 instead getting back the previous behavior: warning: 'realloc' called on pointer '*.t_mem_caches' with nonzero offset 40 PR middle-end/111253 gcc/c-family/ * c-pretty-print.cc (c_pretty_printer::primary_expression): Only dump gimple_assign_single_p SSA def RHS. gcc/testsuite/ * gcc.dg/Wfree-nonheap-object-7.c: New testcase. (cherry picked from commit e3ece7684b02c47d2b259899cf8009d6bdcccaf3)
[Bug tree-optimization/113026] Bogus -Wstringop-overflow warning on simple memcpy type loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026 --- Comment #4 from avieira at gcc dot gnu.org --- Drive by comments as it's been a while since I looked at this. I'm also surprised we didn't adjust the bounds. But why do we only subtract VF? Like you say, if there's no loop around edge, can't we guarantee the epilogue will only need to iterate at most VF-1? This is assuming we didn't take an early exit, if we do then we can't assume anything as the iterations 'reset'.
[Bug c++/113031] [14 Regression] ICE in cxx_fold_indirect_ref_1 starting with r14-6508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113031 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |14.0
[Bug ipa/111613] [12/13/14 Regression] Bit field stores can be incorrectly optimized away when -fstore-merging is in effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111613 Richard Biener changed: What|Removed |Added Priority|P1 |P2 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Richard Biener --- Yours.
[Bug tree-optimization/112994] [12/13/14 Regression] Missed optimization for redundancy computation elimination because pattern is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112994 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|12.4|14.0 --- Comment #10 from Jakub Jelinek --- Fixed for 14+. This is a new optimization, the old simplification is not broken, just another optimization means it doesn't trigger anymore.
[Bug tree-optimization/112941] during GIMPLE pass: bitintlower ICE: in handle_operand_addr, at gimple-lower-bitint.cc:2126 (gimple-lower-bitint.cc:2134) at -O with _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941
--- Comment #6 from Jakub Jelinek ---
And another testcase which ICEs:
unsigned _BitInt(495) f1 (signed _BitInt(381) x) { unsigned _BitInt(539) y = x;
return y; }
unsigned _BitInt(495) f2 (unsigned _BitInt(381) x) { unsigned _BitInt(539) y =
x; return y; }
unsigned _BitInt(495) f3 (signed _BitInt(381) x) { _BitInt(539) y = x; return
y; }
unsigned _BitInt(495) f4 (unsigned _BitInt(381) x) { _BitInt(539) y = x; return
y; }
_BitInt(495) f5 (signed _BitInt(381) x) { unsigned _BitInt(539) y = x; return
y; }
_BitInt(495) f6 (unsigned _BitInt(381) x) { unsigned _BitInt(539) y = x; return
y; }
_BitInt(495) f7 (signed _BitInt(381) x) { _BitInt(539) y = x; return y; }
_BitInt(495) f8 (unsigned _BitInt(381) x) { _BitInt(539) y = x; return y; }
unsigned _BitInt(495) f9 (signed _BitInt(381) x) { return (unsigned
_BitInt(539)) x; }
unsigned _BitInt(495) f10 (unsigned _BitInt(381) x) { return (unsigned
_BitInt(539)) x; }
unsigned _BitInt(495) f11 (signed _BitInt(381) x) { return (_BitInt(539)) x; }
unsigned _BitInt(495) f12 (unsigned _BitInt(381) x) { return (_BitInt(539)) x;
}
_BitInt(495) f13 (signed _BitInt(381) x) { return (unsigned _BitInt(539)) x; }
_BitInt(495) f14 (unsigned _BitInt(381) x) { return (unsigned _BitInt(539)) x;
}
_BitInt(495) f15 (signed _BitInt(381) x) { return (_BitInt(539)) x; }
_BitInt(495) f16 (unsigned _BitInt(381) x) { return (_BitInt(539)) x; }
[Bug libstdc++/107857] recursive_mutex misses destructor if non-function call initialization is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107857 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > See also https://stackoverflow.com/a/77515095/981959 And my comment there: This seems like a bug in winpthreads. The INITIALIZER macro should not exist if destroying the mutex requires a function call. Either you need a function call to create it and destroy it, or you use the initializer macro and don't need to do anything to destroy it.
[Bug libstdc++/107857] recursive_mutex misses destructor if non-function call initialization is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107857 --- Comment #2 from Jonathan Wakely --- See also https://stackoverflow.com/a/77515095/981959
[Bug target/113022] GCN offloading bricked by "amdgcn: Work around XNACK register allocation problem"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113022 --- Comment #1 from Andrew Stubbs --- This is what I get for trying to get this done before vacation. :( Yes, there's probably something in mkoffload that has to match the default change from -mxnack=any to -mxnack=off on the older ISAs.
[Bug tree-optimization/111917] [11 Regression] ICE in as_a, at is-a.h:255 since GCC-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111917 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||11.4.1 Known to fail||11.4.0 --- Comment #12 from Richard Biener --- Fixed.
[Bug tree-optimization/111614] [11 Regression] ICE at -O2: verify_gimple failed since r14-2282-gf703d2fd3f0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111614 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed.
[Bug tree-optimization/110116] [12/13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110116 Bug 110116 depends on bug 111614, which changed state. Bug 111614 Summary: [11 Regression] ICE at -O2: verify_gimple failed since r14-2282-gf703d2fd3f0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111614 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/111614] [11 Regression] ICE at -O2: verify_gimple failed since r14-2282-gf703d2fd3f0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111614 Richard Biener changed: What|Removed |Added Known to work||11.4.1 Status|ASSIGNED|WAITING Known to fail||11.4.0 --- Comment #8 from Richard Biener --- Fixed.
[Bug tree-optimization/111764] [11 Regression] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764 Richard Biener changed: What|Removed |Added Known to fail||11.4.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||11.4.1 --- Comment #12 from Richard Biener --- Fixed.
[Bug middle-end/111818] [11 Regression] ICE with __builtin_memcpy with volatile and constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111818 Richard Biener changed: What|Removed |Added Known to fail||11.4.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to work||11.4.1 --- Comment #8 from Richard Biener --- Fixed.
[Bug tree-optimization/110182] [11 Regression] Vector(2) cast from double to float and back and subtraction seems to produce incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110182 Richard Biener changed: What|Removed |Added Known to fail||11.4.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||11.4.1 --- Comment #8 from Richard Biener --- commit 40aa486160620d4270c9d6e22c49823f552c Author: Richard Biener Date: Fri Jun 9 09:29:09 2023 +0200 middle-end/110182 - TYPE_PRECISION on VECTOR_TYPE causes wrong-code When folding two conversions in a row we use TYPE_PRECISION but that's invalid for VECTOR_TYPE. The following fixes this by using element_precision instead. * match.pd (two conversions in a row): Use element_precision to DTRT for VECTOR_TYPE. (cherry picked from commit 3e12669a0eb968cfcbe9242b382fd8020935edf8)
[Bug c++/110295] [11 Regression] ICE in dwarf2out_finish with local class with inherited operator delete in a templated function and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295 Richard Biener changed: What|Removed |Added Known to fail||11.4.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||11.4.1 --- Comment #10 from Richard Biener --- Fixed.
[Bug tree-optimization/110298] [11 Regression] ICE at -Os on x86_64-linux-gnu since r10-840
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to fail||11.4.0 Known to work||11.4.1 --- Comment #10 from Richard Biener --- Fixed.
[Bug tree-optimization/111917] [11 Regression] ICE in as_a, at is-a.h:255 since GCC-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111917 --- Comment #11 from GCC Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ec8d0c33211c5e92c220483d6fe9f0a2391d2d6d commit r11-11145-gec8d0c33211c5e92c220483d6fe9f0a2391d2d6d Author: Richard Biener Date: Mon Oct 23 11:25:17 2023 +0200 tree-optimization/111917 - bougs IL after guard hoisting The unswitching code to hoist guards inserts conditions in wrong places. The following fixes this, simplifying code. PR tree-optimization/111917 * tree-ssa-loop-unswitch.c (hoist_guard): Always insert new conditional after last stmt. * gcc.dg/torture/pr111917.c: New testcase. (cherry picked from commit d96bd4aade170fcd86f5f09b68b770dde798e631)
[Bug tree-optimization/111614] [11 Regression] ICE at -O2: verify_gimple failed since r14-2282-gf703d2fd3f0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111614 --- Comment #7 from GCC Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:03b5888abc9fe9a81df77125a8d4975ab8695c8c commit r11-11144-g03b5888abc9fe9a81df77125a8d4975ab8695c8c Author: Richard Biener Date: Thu Sep 28 09:41:30 2023 +0200 tree-optimization/111614 - missing convert in undistribute_bitref_for_vector The following adjusts a flawed guard for converting the first vector of the sum we create in undistribute_bitref_for_vector. PR tree-optimization/111614 * tree-ssa-reassoc.c (undistribute_bitref_for_vector): Properly convert the first vector when required. * gcc.dg/torture/pr111614.c: New testcase. (cherry picked from commit 88d79b9b03eccf39921d13c2cbd1acc50aeda126)
[Bug tree-optimization/111764] [11 Regression] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111764 --- Comment #11 from GCC Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:7473b2742aa1637d14a64505e855aa09452536b1 commit r11-11143-g7473b2742aa1637d14a64505e855aa09452536b1 Author: Richard Biener Date: Thu Oct 12 09:09:46 2023 +0200 tree-optimization/111764 - wrong reduction vectorization The following removes a misguided attempt to allow x + x in a reduction path, also allowing x * x which isn't valid. x + x actually never arrives this way but instead is canonicalized to 2 * x. This makes reduction path handling consistent with how we handle the single-stmt reduction case. PR tree-optimization/111764 * tree-vect-loop.c (check_reduction_path): Remove the attempt to allow x + x via special-casing of assigns. * gcc.dg/vect/pr111764.c: New testcase. (cherry picked from commit 05f98310b54da95e468d799f4a910174320cccbb)
[Bug middle-end/111818] [11 Regression] ICE with __builtin_memcpy with volatile and constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111818 --- Comment #7 from GCC Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:45c296f2d81f6259e268e07707b4aa87dffba20a commit r11-11142-g45c296f2d81f6259e268e07707b4aa87dffba20a Author: Richard Biener Date: Mon Oct 16 12:50:46 2023 +0200 middle-end/111818 - failed DECL_NOT_GIMPLE_REG_P setting of volatile The following addresses a missed DECL_NOT_GIMPLE_REG_P setting of a volatile declared parameter which causes inlining to substitute a constant parameter into a context where its address is required. The main issue is in update_address_taken which clears DECL_NOT_GIMPLE_REG_P from the parameter but fails to rewrite it because is_gimple_reg returns false for volatiles. The following changes maybe_optimize_var to make the 1:1 correspondence between clearing DECL_NOT_GIMPLE_REG_P of a register typed decl and actually rewriting it to SSA. PR middle-end/111818 * tree-ssa.c (maybe_optimize_var): When clearing DECL_NOT_GIMPLE_REG_P always rewrite into SSA. * gcc.dg/torture/pr111818.c: New testcase. (cherry picked from commit ce55521bcd149fdc431f1d78e706b66d470210ae)
[Bug c++/110295] [11 Regression] ICE in dwarf2out_finish with local class with inherited operator delete in a templated function and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295 --- Comment #9 from GCC Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:01f088741bec84f8fa86f87fdb73db07d5febb0a commit r11-11140-g01f088741bec84f8fa86f87fdb73db07d5febb0a Author: Richard Biener Date: Mon Jun 19 09:23:16 2023 +0200 debug/110295 - mixed up early/late debug for member DIEs When we process a scope typedef during early debug creation and we have already created a DIE for the type when the decl is TYPE_DECL_IS_STUB and this DIE is still in limbo we end up just re-parenting that type DIE instead of properly creating a DIE for the decl, eventually picking up the now completed type and creating DIEs for the members. Instead this is currently defered to the second time we come here, when we annotate the DIEs with locations late where now the type DIE is no longer in limbo and we fall through doing the job for the decl. The following makes sure we perform the necessary early tasks for this by continuing with the decl DIE creation after setting a parent for the limbo type DIE. PR debug/110295 * dwarf2out.c (process_scope_var): Continue processing the decl after setting a parent in case the existing DIE was in limbo. * g++.dg/debug/pr110295.C: New testcase. (cherry picked from commit 963f87f8a65ec82f503ac4334a3da83b0a8a43b2)
[Bug tree-optimization/110298] [11 Regression] ICE at -Os on x86_64-linux-gnu since r10-840
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110298 --- Comment #9 from GCC Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:0e332ee568739448a9439c7074d2a29badba60f2 commit r11-11141-g0e332ee568739448a9439c7074d2a29badba60f2 Author: Richard Biener Date: Mon Jun 19 09:52:45 2023 +0200 tree-optimization/110298 - CFG cleanup and stale nb_iterations When unrolling we eventually kill nb_iterations info since it may refer to removed SSA names. But we do this only after cleaning up the CFG which in turn can end up accessing it. Fixed by swapping the two. PR tree-optimization/110298 * tree-ssa-loop-ivcanon.c (tree_unroll_loops_completely): Clear number of iterations info before cleaning up the CFG. * gcc.dg/torture/pr110298.c: New testcase. (cherry picked from commit 916add3bf6e46467e4391e358b11ecfbc4daa275)
[Bug libstdc++/107857] recursive_mutex misses destructor if non-function call initialization is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107857
--- Comment #1 from Jonathan Wakely ---
Could you please run this and paste the output here?
#include
#include
#include
#include
#include
unsigned long
muh_handles()
{
unsigned long n = 0;
if (GetProcessHandleCount(GetCurrentProcess(), ))
return n;
throw;
}
int main()
{
int start, end;
start = muh_handles();
{
std::mutex m;
m.lock();
m.unlock();
}
end = muh_handles();
std::cout << "Handles leaked by std::mutex: " << (end - start) << std::endl;
start = end;
{
std::recursive_mutex m;
m.lock();
m.unlock();
}
end = muh_handles();
std::cout << "Handles leaked by std::recursive_mutex: " << (end - start) <<
std::endl;
start = end;
{
std::timed_mutex m;
m.lock();
m.unlock();
}
end = muh_handles();
std::cout << "Handles leaked by std::timed_mutex: " << (end - start) <<
std::endl;
start = end;
{
std::recursive_timed_mutex m;
m.lock();
m.unlock();
}
end = muh_handles();
std::cout << "Handles leaked by std::recursive_timed_mutex: " << (end -
start) << std::endl;
start = end;
{
std::shared_mutex m;
m.lock();
m.unlock();
}
end = muh_handles();
std::cout << "Handles leaked by std::shared_mutex: " << (end - start) <<
std::endl;
start = end;
{
std::shared_timed_mutex m;
m.lock();
m.unlock();
}
end = muh_handles();
std::cout << "Handles leaked by std::shared_timed_mutex: " << (end - start)
<< std::endl;
start = end;
{
std::mutex m;
std::unique_lock l(m);
std::condition_variable cv;
cv.wait_for(l, std::chrono::seconds(0));
}
end = muh_handles();
std::cout << "Handles leaked by std::condition_variable: " << (end - start)
<< std::endl;
}
I tried to check it on Wine, but the Windows function isn't implemented:
012c:fixme:process:NtQueryInformationProcess ProcessHandleCount
(0x,0x7e2ffdfc,0x0004,(nil)) stub
