[Bug c/111128] New: ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28
Bug ID: 28
Summary: ICE: tree check: expected class 'type', have
'exceptional' (error_mark) in
useless_type_conversion_p, at gimple-expr.cc:85
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
gcc at -O2/3 crashes on the following test case.
Bisected to r14-2987-g1a599caab8
Compiler explorer: https://godbolt.org/z/dxT134o4d
$ cat a.c
int a, b, c, e, g;
short *d;
unsigned char f;
int h() {
f &= g;
for (; b; b++) {
a = 2;
for (; a; a--)
c = 0;
if (c)
continue;
e = (unsigned short)*d >> f;
}
}
int main() {}
$
$ gcc -O2 a.c
during GIMPLE pass: vect
a.c: In function ‘h’:
a.c:4:5: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
4 | int h() {
| ^
0x2185dae internal_error(char const*, ...)
???:0
0x89cd86 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0x1109f71 verify_gimple_in_cfg(function*, bool, bool)
???: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 debug/111080] [11/12/13/14 Regression] restrict qualifier causes extra debug info to happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:fb6d61299159275246052c72c6e3666b36d5b333 commit r13-7750-gfb6d61299159275246052c72c6e3666b36d5b333 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 debug/111080] [11/12 Regression] restrict qualifier causes extra debug info to happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080 Richard Biener changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12 Regression] restrict |restrict qualifier causes |qualifier causes extra |extra debug info to happen |debug info to happen Known to fail||13.2.0 Known to work||13.2.1, 14.0 --- Comment #6 from Richard Biener --- Fixed on trunk and for GCC 13.3 sofar.
[Bug tree-optimization/69489] missed vectorization for boolean loop, missed if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||13.1.0 --- Comment #21 from Andrew Pinski --- Looks like this was fixed in GCC 13. IR in GCC 13: ``` pretmp_55 = *_54; _33 = _3 != 0; _35 = pretmp_55 != 0; _42 = (long int) _35; _40 = pretmp_55 == 0; _39 = _33 & _40; _ifc__11 = _39 ? 1 : 0; _26 = ntf_29 + _ifc__11; _ifc__12 = _33 ? 0 : _42; ``` IR in GCC 12: ``` pretmp_55 = *_54; _35 = pretmp_55 != 0; _42 = (long int) _35; _32 = _3 != 0; _41 = pretmp_55 == 0; _40 = _32 & _41; _ifc__11 = _40 ? 1 : 0; _26 = ntf_33 + _ifc__11; _ifc__12 = _3 != 0 ? 0 : _42; ``` I don't know if the changing of `_3 != 0` into `_33` fixed the issue or something else.
[Bug c++/111123] Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23 --- Comment #3 from Richard Biener --- Adding [[gnu::noinline]] to Camera::Camera will never warn.
[Bug tree-optimization/111128] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||ice-on-valid-code Summary|ICE: tree check: expected |[14 Regression] ICE: tree |class 'type', have |check: expected class |'exceptional' (error_mark) |'type', have 'exceptional' |in |(error_mark) in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.cc:85|at gimple-expr.cc:85
[Bug tree-optimization/111109] [13/14 Regression] wrong code for some fp comparisons (after r13-4620-g4d9db4bdd458)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=09 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:4aa14ec7d5b25722e4d02c29c8c1e22dcc5a4915 commit r14-3433-g4aa14ec7d5b25722e4d02c29c8c1e22dcc5a4915 Author: Andrew Pinski Date: Wed Aug 23 16:46:10 2023 + MATCH: [PR09] Fix bit_ior(cond,cond) when comparisons are fp The patterns that were added in r13-4620-g4d9db4bdd458, missed that (a > b) and (a <= b) are not inverse of each other for floating point comparisons (if NaNs are supported). Even though there was a check for intergal types, it was only for the result of the cond rather for the type of what is being compared. The fix is to check to see if cmp and icmp are inverse of each other by using the invert_tree_comparison function. OK for trunk and GCC 13 branch? Bootstrapped and tested on x86_64-linux-gnu with no regressions. I added the testcase to execute/ieee as it requires support for NAN. PR tree-optimization/09 gcc/ChangeLog: * match.pd (ior(cond,cond), ior(vec_cond,vec_cond)): Add check to make sure cmp and icmp are inverse. gcc/testsuite/ChangeLog: * gcc.c-torture/execute/ieee/fp-cmp-cond-1.c: New test.
[Bug tree-optimization/111109] [13/14 Regression] wrong code for some fp comparisons (after r13-4620-g4d9db4bdd458)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=09 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:15d855788ba26e9be028507c7d985bb6af1934f3 commit r13-7751-g15d855788ba26e9be028507c7d985bb6af1934f3 Author: Andrew Pinski Date: Wed Aug 23 16:46:10 2023 + MATCH: [PR09] Fix bit_ior(cond,cond) when comparisons are fp The patterns that were added in r13-4620-g4d9db4bdd458, missed that (a > b) and (a <= b) are not inverse of each other for floating point comparisons (if NaNs are supported). Even though there was a check for intergal types, it was only for the result of the cond rather for the type of what is being compared. The fix is to check to see if cmp and icmp are inverse of each other by using the invert_tree_comparison function. OK for trunk and GCC 13 branch? Bootstrapped and tested on x86_64-linux-gnu with no regressions. I added the testcase to execute/ieee as it requires support for NAN. PR tree-optimization/09 gcc/ChangeLog: * match.pd (ior(cond,cond), ior(vec_cond,vec_cond)): Add check to make sure cmp and icmp are inverse. gcc/testsuite/ChangeLog: * gcc.c-torture/execute/ieee/fp-cmp-cond-1.c: New test. (cherry picked from commit 4aa14ec7d5b25722e4d02c29c8c1e22dcc5a4915)
[Bug tree-optimization/111109] [13/14 Regression] wrong code for some fp comparisons (after r13-4620-g4d9db4bdd458)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=09 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Andrew Pinski --- Fixed.
[Bug c++/111123] Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23
Richard Biener changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Blocks||24639
--- Comment #4 from Richard Biener ---
The interesting thing is that enabling the middle-end diagnostic to trigger
shows we emit duplicate diagnostics:
struct Camera {
float clip_area;
float border = 10.f;
[[gnu::noinline]] Camera() : clip_area(border) { }
};
Camera foo()
{
Camera c;
return c;
}
emits
t.C: In constructor 'Camera::Camera()':
t.C:4:44: warning: member 'Camera::border' is used uninitialized
[-Wuninitialized]
4 | [[gnu::noinline]] Camera() : clip_area(border) { }
|^~
t.C: In constructor 'Camera::Camera()':
t.C:4:44: warning: '*this.Camera::border' is used uninitialized
[-Wuninitialize]
4 | [[gnu::noinline]] Camera() : clip_area(border) { }
|^~
the first is from the C++ FE find_uninit_fields diagnostic which for some
reason doesn't work for the testcase in the description, possibly
the initializer list(?) isn't handled? The early uninit IL is
:
MEM[(struct __as_base &)this_6(D)] ={v} {CLOBBER};
_1 = &this_6(D)->clip_area;
std::allocator::allocator (&D.26049);
_2 = this_6(D)->border;
D.26047[0].x = _2;
_3 = this_6(D)->border;
D.26047[0].y = _3;
D.27007._M_array = &D.26047;
D.27007._M_len = 1;
std::vector::vector (_1, D.27007, &D.26049);
the call to std::allocator::allocator is thought to clobber
*this and thus possibly initialize 'border' here.
I'm testing a middle-end fix here - Marek, can you see whether it's possible
to detect this in the frontend? The middle-end will require optimization.
The duplicate diagnostic might also be interesting to look at, but that
might already be reported separately?
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||testsuite-fail Summary|tree-ssa.exp and vect.exp |[14 Regression] |failures after commit |tree-ssa.exp and vect.exp |r14-3281-g99b5921bfc8f91|failures after commit ||r14-3281-g99b5921bfc8f91
[Bug c++/110342] [C++26] P2361R6 - Unevaluated strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110342 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #3 from Jiang An --- It seems that the paper also makes the GNU assembly syntax conforming. Should we make some other changes?
[Bug tree-optimization/49795] vectorization of conditional code happens only on local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49795 --- Comment #7 from Andrew Pinski --- (In reply to vincenzo Innocente from comment #6) loop1, loop2, and loop4 all vectorize now at -O3. loop3 can vectorize with -O3 -fno-trapping-math (it can also be vectorize at -O3 on x86_64 with -march=skylake-avx512 or on aarch64 with SVE enabled). I almost want to say there is not much to do here. also about comment #0, the vectorizer does happen for -mavx2. So maybe this is enough these days ...
[Bug tree-optimization/111128] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2023-08-24 --- Comment #1 from Richard Biener --- Confirmed. patt_17 = MIN_EXPR <_50, 15>; and _50 is released. Hmm, probably caused by r14-2987-g1a599caab86464, I'd have to check how we handle those "dead" invariant pattern stmts we emit on the entry.
[Bug tree-optimization/111128] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28 --- Comment #2 from Richard Biener --- I have a fix.
[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2023-08-24
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
For gcc.dg/tree-ssa/slsr-11.c we vectorize the reduction to
[local count: 1073741824]:
_15 = {s_5(D), s_5(D)};
vect_a3_11.3_16 = _15 * { 6, 4 };
vect__3.4_17 = (vector(2) long int) vect_a3_11.3_16;
a1_6 = s_5(D) * 2;
_18 = VIEW_CONVERT_EXPR(vect__3.4_17);
_19 = .REDUC_PLUS (_18);
_20 = (unsigned long) a1_6;
_21 = (unsigned long) c_7(D);
_29 = _21 * 2;
_31 = _19 + _29;
_30 = _20 + _21;
_27 = _30 + _31;
_28 = (long int) _27;
return _28;
note: Cost model analysis for part in loop 0:
Vector cost: 9
Scalar cost: 9
doesn't look profitable. I think there's something off with the scalar
accounting, I'll have a look there.
[Bug pch/47857] Pragma once warning when compiling PCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857 Eric Gallager changed: What|Removed |Added Last reconfirmed||2023-08-24 Ever confirmed|0 |1 CC||egallager at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #9 from Eric Gallager --- Confirming via bug 89808
[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25
--- Comment #2 from Richard Biener ---
For gcc.dg/vect/bb-slp-29.c we are now vectorizing
#pragma GCC novector
for (i = 0; i < N/2; i++)
{
if (dst[i] != A * src[i] + B * src[i+1])
abort ();
}
in particular the multiplication and the addition (but not the load which
had predictive commoning applied). When cost modeling is enabled this
vectorization is not deemed profitable (but the vect testsuite runs with
-fno-vect-cost-model).
I wonder if we want to excempt basic blocks within loops marked with novector
from BB vectorization.
[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25
--- Comment #3 from Richard Biener ---
gcc.dg/vect/pr53773.c is interesting - we vectorize the function to
[local count: 118111600]:
_20 = {integral_4(D), decimal_5(D)};
if (power_ten_6(D) > 0)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 955630224]:
# power_ten_19 = PHI
# vect_integral_15.4_1 = PHI
vect_integral_9.5_12 = vect_integral_15.4_1 * { 10, 10 };
power_ten_11 = power_ten_19 + -1;
if (power_ten_11 != 0)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 118111600]:
# vect_integral_16.7_21 = PHI
_22 = VIEW_CONVERT_EXPR(vect_integral_16.7_21);
_23 = .REDUC_PLUS (_22); [tail call]
_24 = (int) _23;
return _24;
where loop vectorization fails because
/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/vect/pr53773.c:9:20: note:
Analyze phi: integral_15 = PHI
/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/vect/pr53773.c:9:20: missed:
Peeling for epilogue is not supported for nonlinear induction except neg when
iteration count is unknown.
/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/vect/pr53773.c:9:20: missed: not
vectorized: can't create required epilog loop
loop vectorization doesn't try SLP here because we only SLP reduction groups,
not induction groups.
So I think this vectorization is quite nice, possibly even better than
the loop vectorization we expect. generated code:
foo:
.LFB0:
.cfi_startproc
fmovs31, w0
ins v31.s[1], w1
cmp w2, 0
ble .L2
moviv30.2s, 0xa
.p2align 3,,7
.L3:
mul v31.2s, v31.2s, v30.2s
subsw2, w2, #1
bne .L3
.L2:
addpv31.2s, v31.2s, v31.2s
fmovw0, s31
ret
the path for power_ten == 0 is of course sub-optimal. Note it's again
determined not profitable with costing (we do not try to weight stmts
based on profile, thus in-loop stmts cost the same as out-of-loop stmts).
I'm going to adjust the testcase, disabling BB vectorization.
[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:308e716266787f84ba4a47546317dae83be8901c commit r14-3436-g308e716266787f84ba4a47546317dae83be8901c Author: Richard Biener Date: Thu Aug 24 10:55:06 2023 +0200 testsuite/25 - disable BB vectorization for the test The test is for loop vectorization producing non-canonical multiplications. We can now BB vectorize the whole function when the target supports .REDUC_PLUS for V2SImode but we don't have a dejagnu selector for that. Disable BB vectorization like we disabled epilogue vectorization. PR testsuite/25 * gcc.dg/vect/pr53773.c: Disable BB vectorization.
[Bug tree-optimization/111128] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:7b67cab154d4b5ec2a6bb62755da31cefbe63536 commit r14-3437-g7b67cab154d4b5ec2a6bb62755da31cefbe63536 Author: Richard Biener Date: Thu Aug 24 10:00:20 2023 +0200 tree-optimization/28 - fix shift pattern recog The following fixes placement of shift operand sanitization with MIN when the original shift operand was external but the actual one is not. PR tree-optimization/28 * tree-vect-patterns.cc (vect_recog_over_widening_pattern): Emit external shift operand inline if we promoted it with another pattern stmt. * gcc.dg/torture/pr28.c: New testcase.
[Bug tree-optimization/111128] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Blocks||110838 --- Comment #4 from Richard Biener --- Fixed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110838 [Bug 110838] [14 Regression] wrong code on x365-3.5, -O3, sign extraction
[Bug tree-optimization/110838] [14 Regression] wrong code on x365-3.5, -O3, sign extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110838 Bug 110838 depends on bug 28, which changed state. Bug 28 Summary: [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/108412] RISC-V: Negative optimization of GCSE && LOOP INVARIANTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108412 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org --- Comment #3 from Robin Dapp --- I played around a bit with the scheduling model and the pressure-aware scheduling. -fsched-pressure alone does not seem to help because the problem is indeed the latency of vector load and store. The scheduler will try to keep dependent loads and stores apart (for the number of cycles specified), and then, after realizing there is nothing to put in between, lump everything together at the end of the sequence. That's a well known but unfortunate property of scheduling. Will need to think of something but not resolved for now.
[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e80f7c13f64e10c6a3354c5d6b42da60b21ed0b8 commit r14-3440-ge80f7c13f64e10c6a3354c5d6b42da60b21ed0b8 Author: Richard Biener Date: Thu Aug 24 10:30:12 2023 +0200 tree-optimization/25 - properly cost BB reduction remain stmt handling We assume that all root stmts which compose the total reduction chain are vectorized but fail to account for the cost of adding back the scalar defs we are not vectorizing. The following rectifies this, fixing the gcc.dg/tree-ssa/slsr-11.c FAIL on aarch64. PR tree-optimization/25 * tree-vect-slp.cc (vectorizable_bb_reduc_epilogue): Account for the remain_defs processing.
[Bug tree-optimization/111115] Failure to vectorize conditional grouped store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a1558e9ad856938f165f838733955b331ebbec09 commit r14-3441-ga1558e9ad856938f165f838733955b331ebbec09 Author: Richard Biener Date: Wed Aug 23 14:28:26 2023 +0200 tree-optimization/15 - SLP of masked stores The following adds the capability to do SLP on .MASK_STORE, I do not plan to add interleaving support. PR tree-optimization/15 gcc/ * tree-vectorizer.h (vect_slp_child_index_for_operand): New. * tree-vect-data-refs.cc (can_group_stmts_p): Also group .MASK_STORE. * tree-vect-slp.cc (arg3_arg2_map): New. (vect_get_operand_map): Handle IFN_MASK_STORE. (vect_slp_child_index_for_operand): New function. (vect_build_slp_tree_1): Handle statements with no LHS, masked store ifns. (vect_remove_slp_scalar_calls): Likewise. * tree-vect-stmts.cc (vect_check_store_rhs): Lookup the SLP child corresponding to the ifn value index. (vectorizable_store): Likewise for the mask index. Support masked stores. (vectorizable_load): Lookup the SLP child corresponding to the ifn mask index. gcc/testsuite/ * lib/target-supports.exp (check_effective_target_vect_masked_store): Supported with check_avx_available. * gcc.dg/vect/slp-mask-store-1.c: New testcase.
[Bug tree-optimization/111115] Failure to vectorize conditional grouped store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed for GCC 14.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 15, which changed state. Bug 15 Summary: Failure to vectorize conditional grouped store https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/110702] [12/13 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110702
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:5ca9aea695396266b7eb7d2a065e6f2e9546047e
commit r13-7752-g5ca9aea695396266b7eb7d2a065e6f2e9546047e
Author: Richard Biener
Date: Thu Aug 3 13:11:12 2023 +0200
tree-optimization/110702 - avoid zero-based memory references in IVOPTs
Sometimes IVOPTs chooses a weird induction variable which downstream
leads to issues. Most of the times we can fend those off during costing
by rejecting the candidate but it looks like the address description
costing synthesizes is different from what we end up generating so
the following fixes things up at code generation time. Specifically
we avoid the create_mem_ref_raw fallback which uses a literal zero
address base with the actual base in index2. For the case in question
we have the address
type = unsigned long
offset = 0
elements = {
[0] = &e * -3,
[1] = (sizetype) a.9_30 * 232,
[2] = ivtmp.28_44 * 4
}
from which we code generate the problematical
_3 = MEM[(long int *)0B + ivtmp.36_9 + ivtmp.28_44 * 4];
which references the object at address zero. The patch below
recognizes the fallback after the fact and transforms the
TARGET_MEM_REF memory reference into a LEA for which this form
isn't problematic:
_24 = &MEM[(long int *)0B + ivtmp.36_34 + ivtmp.28_44 * 4];
_3 = *_24;
hereby avoiding the correctness issue. We'd later conclude the
program terminates at the null pointer dereference and make the
function pure, miscompling the main function of the testcase.
PR tree-optimization/110702
* tree-ssa-loop-ivopts.cc (rewrite_use_address): When
we created a NULL pointer based access rewrite that to
a LEA.
* gcc.dg/torture/pr110702.c: New testcase.
(cherry picked from commit 13dfb01e5c30c3bd09333ac79d6ff96a617fea67)
[Bug tree-optimization/111070] [14 Regregression] ./gcc.target/tic6x/abi-align-1.c on x86_64 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111070 --- Comment #7 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ad42dcf501e41713047cf6c47cbb1dd9f01088a4 commit r13-7755-gad42dcf501e41713047cf6c47cbb1dd9f01088a4 Author: Richard Biener Date: Mon Aug 21 09:01:00 2023 +0200 tree-optimization/111070 - fix ICE with recent ifcombine fix We now got test coverage for non-SSA name bits so the following amends the SSA_NAME_OCCURS_IN_ABNORMAL_PHI checks. PR tree-optimization/111070 * tree-ssa-ifcombine.cc (ifcombine_ifandif): Check we have an SSA name before checking SSA_NAME_OCCURS_IN_ABNORMAL_PHI. * gcc.dg/pr111070.c: New testcase. (cherry picked from commit 966b0a96523fb7adbf498ac71df5e033c70dc546)
[Bug tree-optimization/111039] [11/12/13 Regression] Unable to coalesce ssa_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111039 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:e150cbf591759af10f3d57acbe0eb381aafa00de commit r13-7754-ge150cbf591759af10f3d57acbe0eb381aafa00de Author: Richard Biener Date: Thu Aug 17 13:10:14 2023 +0200 tree-optimization/111039 - abnormals and bit test merging The following guards the bit test merging code in if-combine against the appearance of SSA names used in abnormal PHIs. PR tree-optimization/111039 * tree-ssa-ifcombine.cc (ifcombine_ifandif): Check for SSA_NAME_OCCURS_IN_ABNORMAL_PHI. * gcc.dg/pr111039.c: New testcase. (cherry picked from commit 482551a79a3d3f107f6239679ee74655cfe8707e)
[Bug c++/111019] [12/13 Regression] Optimizer incorrectly assumes variable is not changed while change happens through another pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019 --- Comment #13 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:c1b5514124ab7a8aceec1ae4a82d2149fc687ecf commit r13-7753-gc1b5514124ab7a8aceec1ae4a82d2149fc687ecf Author: Richard Biener Date: Thu Aug 17 15:21:33 2023 +0200 tree-optimization/111019 - invariant motion and aliasing The following fixes a bad choice in representing things to the alias oracle by LIM which while correct in pieces is inconsistent with itself. When canonicalizing a ref to a bare deref instead of leaving the base object and the extracted offset the same and just substituting an alternate ref the following replaces the base and the offset as well, avoiding the confusion that otherwise will arise in aliasing_matching_component_refs_p. PR tree-optimization/111019 * tree-ssa-loop-im.cc (gather_mem_refs_stmt): When canonicalizing also scrap base and offset in case the ref is indirect. * g++.dg/torture/pr111019.C: New testcase. (cherry picked from commit 745ec2135aabfbe2c0fb7780309837d17e8986d4)
[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:43da77a4f1636280c4259402c9c2c543e6ec6c0b commit r14-3444-g43da77a4f1636280c4259402c9c2c543e6ec6c0b Author: Richard Biener Date: Thu Aug 24 11:10:43 2023 +0200 tree-optimization/25 - avoid BB vectorization in novector loops When a loop is marked with #pragma GCC novector the following makes sure to also skip BB vectorization for contained blocks. That avoids gcc.dg/vect/bb-slp-29.c failing on aarch64 because of extra BB vectorization therein. I'm not specifically dealing with sub-loops of novector loops, the desired semantics isn't documented. PR tree-optimization/25 * tree-vect-slp.cc (vect_slp_function): Split at novector loop entry, do not push blocks in novector loops.
[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Should be all fixed now.
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 Jakub Jelinek changed: What|Removed |Added Attachment #55780|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek --- Created attachment 55785 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55785&action=edit gcc14-pr110348.patch Full untested patch.
[Bug libstdc++/111129] New: std::regex incorrectly matches quantifiers with plus appended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29
Bug ID: 29
Summary: std::regex incorrectly matches quantifiers with plus
appended
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at octaforge dot org
Target Milestone: ---
Example code:
```
#include
#include
#include
int main(void) {
std::smatch matches;
auto re = std::regex(R"(a++)", std::regex::icase);
std::string inp = "aaa";
std::regex_search(inp, matches, re);
for (auto &match: matches) {
printf("%s\n", match.str().data());
}
}
```
With libstdc++, this does not crash, and outputs 'aaa'.
This gives people a false idea that libstdc++ implements possessive quantifiers
(see e.g. https://github.com/wwmm/easyeffects/pull/2536) despite the
documentation or code having no references to any such extension (and the C++
standard likewise not mentioning it). You can verify that the semantics are not
possessive by changing the pattern to 'a++a', which should with possessive
semantics not match anything, but with libstdc++ it's an identical match as
before.
With libc++, this correctly fails with: libc++abi: terminating due to uncaught
exception of type std::__1::regex_error: One of *?+{ was not preceded by a
valid regular expression.
[Bug middle-end/111017] [12/13/14 Regression][OpenMP] Wrong code with non-rectangular loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111017 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:d4648a00df7a6950f7e1d12743e17a8583af0e5f commit r13-7756-gd4648a00df7a6950f7e1d12743e17a8583af0e5f Author: Tobias Burnus Date: Sat Aug 19 07:49:06 2023 +0200 omp-expand.cc: Fix wrong code with non-rectangular loop nest [PR111017] Before commit r12-5295-g47de0b56ee455e, all gimple_build_cond in expand_omp_for_* were inserted with gsi_insert_before (gsi_p, cond_stmt, GSI_SAME_STMT); except the one dealing with the multiplicative factor that was gsi_insert_after (gsi, cond_stmt, GSI_CONTINUE_LINKING); That commit for PR103208 fixed the issue of some missing regimplify of operands of GIMPLE_CONDs by moving the condition handling to the new function expand_omp_build_cond. While that function has an 'bool after = false' argument to switch between the two variants. However, all callers ommited this argument. This commit reinstates the prior behavior by passing 'true' for the factor != 0 condition, fixing the included testcase. PR middle-end/111017 gcc/ * omp-expand.cc (expand_omp_for_init_vars): Pass after=true to expand_omp_build_cond for 'factor != 0' condition, resulting in pre-r12-5295-g47de0b56ee455e code for the gimple insert. libgomp/ * testsuite/libgomp.c-c++-common/non-rect-loop-1.c: New test. (cherry picked from commit 1dc65003b66e5a97200f454eeddcccfce34416b3)
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348
--- Comment #5 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #3)
> I wonder if the paper wording isn't incorrect, or at least comparing the
> clang++
> implementation vs. the paper gives some differences.
>
> One (minor) is that they emit errors when the size () and/or data () members
> aren't constexpr, while the paper as voted in only requires that
> "- the expression M.size() is implicitly convertible to std::size_t, and
> - the expression M.data() is implicitly convertible to ”pointer to const
> char”."
> unless the static assertion fails. The WIP patch doesn't do that, only
> effectively diagnoses it during constant evaluation of those when the static
> assertion fails.
I agree with your WIP patch. The requirements for data() and size() to be
constant expressions are in p11 (11.2) which only apply if the static
assertions fails.
> More important, they have in the testcase something similar to what I filed
> in PR22, but let's use what works also in GCC:
> struct T {
> const char *d = init ();
> constexpr int size () const { return 2; }
> constexpr const char *data () const { return d; }
> constexpr const char *init () const { return new char[2] { 'o', 'k' }; }
> constexpr ~T () { delete[] d; }
> };
> constexpr int a = T{}.size (); // Ok, a = 2
> constexpr int b = T{}.data ()[0]; // Ok, b = 'o'
> constexpr const char *c = T{}.data (); // Not constant expression, because
> it returns
> // address from new which is later in the dtor deleted.
> static_assert (false, T{}); // Valid?
Interesting one. The call to .data() occurs before the destructor, so I would
naively expect it to be valid. I think it should be equivalent to:
constexpr int i = (T{}.data(), 0);
The data() pointer is valid during the lifetime of the T prvalue. I would
expect that a failed static assertion creates some kind of scope for the
constant expression M, and evaluation of the data() string occurs before the
destruction of any objects created in that scope.
> I don't know how std::format if constexpr (is it?) or string_view etc. work,
std::format isn't a constexpr function. The "with this proposal" example in
P2741R3 doesn't actually work with that proposal, it would require changes to
std::format that haven't been proposed for the standard.
> do they
> need M.data () not be actual constant expression and only M.data ()[0]
> through M.data ()[M.size () - 1] constant expressions?
string_view doesn't require a data() function in any way, constexpr or not. It
just takes a pointer and optional length.
> In the patch I can
> surely try to constant expr evaluate M.data () quietly and if it isn't
> constant expression, just use a slower way which will ask for each character
> individually. More important question is what is the intention for the
> standard...
I think it has to be a constant expression, the slower fallback shouldn't be
needed IMHO.
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628 --- Comment #8 from Jan Hubicka --- patch posted https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628231.html
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > I agree with your WIP patch. The requirements for data() and size() to be > constant expressions are in p11 (11.2) which only apply if the static > assertions fails. In other words, I think the paper is clear and clang is wrong here. Although arguably what clang does is more useful. I'm not sure why you'd want to use a non-constexpr size() or data() that only compiles as long as the static assertion passes. It means you won't find out that your user-generated message can't actually be printed until you run on a target where the assertion fails. I suppose there could be a case where those functions are only constexpr sometimes, and that happens to coincide with exactly the conditions where the assertion fails. That seems unlikely though. It seems more likely that you would use an assertion to terminate compilation when your code is *missing* features, not make it fail only when features are present. The wording voted into the draft also seems counter to the design expressed in the paper that says "The message-producing expression is intended to be always instantiated, but only evaluated if the assertion failed." Does instantiating it require it to be a valid constant expression, even if not evaluated?
[Bug c/111130] New: ice & tree check fail in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30
Bug ID: 30
Summary: ice & tree check fail in useless_type_conversion_p, at
gimple-expr.cc:85
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
This C code:
g_61, func_100_p_104;
short g_135_3_2_2;
func_100(unsigned char p_101) {
int __trans_tmp_1;
for (; g_61; g_61 -= 1)
if (func_100_p_104) {
unsigned short left = __trans_tmp_1 = left >> p_101;
g_135_3_2_2 |= __trans_tmp_1;
}
}
with recent trunk gcc and compiler flag -O3, does this:
$ ~/gcc/results/bin/gcc -c -w -O3 bug949.c
during GIMPLE pass: vect
bug949.c: In function ‘func_100’:
bug949.c:3:1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
3 | func_100(unsigned char p_101) {
| ^~~~
0x117c1c9 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../trunk.year/gcc/tree.cc:8948
0xa7b615 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../trunk.year/gcc/tree.h:3700
0xa7b615 useless_type_conversion_p(tree_node*, tree_node*)
../../trunk.year/gcc/gimple-expr.cc:85
The bug first seems to occur sometime between g:4a0633d4d499cf97
and g:abf953042ace4717, some 27 commits.
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #6) > Although arguably what clang does is more useful. I'm not sure why you'd > want to use a non-constexpr size() or data() that only compiles as long as > the static assertion passes. It means you won't find out that your > user-generated message can't actually be printed until you run on a target > where the assertion fails. In the general case, the user-generated string might only be a constant expression for some inputs, which is why it's unevaluated unless the assertion fails. And the member functions being non-constexpr is only one of many ways in which those functions could fail to be usable in constant expressions. So just checking for constexpr members isn't sufficient to avoid the problem of a message that can never be printed.
[Bug libstdc++/111129] std::regex incorrectly matches quantifiers with plus appended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-24 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed. There is no such extension in libstdc++, this is just a bug.
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 --- Comment #8 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #6) > (In reply to Jonathan Wakely from comment #5) > > I agree with your WIP patch. The requirements for data() and size() to be > > constant expressions are in p11 (11.2) which only apply if the static > > assertions fails. > > In other words, I think the paper is clear and clang is wrong here. > > Although arguably what clang does is more useful. I'm not sure why you'd > want to use a non-constexpr size() or data() that only compiles as long as > the static assertion passes. It means you won't find out that your > user-generated message can't actually be printed until you run on a target > where the assertion fails. Sure, if the standard is changed such that size() and data() must be constexpr, it would be nice to check it. Without full evaluation one can't guarantee it will be a constant expression and there could be tons of other reasons why it isn't constant expression (say it returns some class and conversion operator isn't constexpr, or it throws, or has asm and many other reasons). For the M.data () not being a constant expression, it depends on the exact wording as well. Either the standard could drop the requirement that it is a core constant expression altogether, then e.g. nothing will require that (M.data (), 0) is constant expression when M.size () is 0. Or it could say that (M.data (), 0) is an integer constant expression, then one can verify that, and then quietly try if M.data () is a constant expression; if it is, it can grab the message from it using say GCC's c_getstr if it works. If it isn't, it would need to evaluate it character by character. BTW, there is a third difference between my latest patch and clang++ implementation. They reject static_assert (false, "foo"_myd); which I have in the testcase. IMHO "foo"_myd doesn't match the syntactic requirements of unevaluated-string as the https://eel.is/c++draft/dcl.pre#10 wording says, because unevaluated-string non-terminal is string-literal with some extra rules, while user-defined-literal is some other non-terminal. And as I've tried to show in the testcase, a constexpr operator "" can return something on which .size () / .data () can be called and can satisfy the requirements.
[Bug tree-optimization/111131] New: SLP of gathers incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31 Bug ID: 31 Summary: SLP of gathers incomplete Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- SLP of gathers relies on vect_recog_gather_scatter_pattern but for example x86 still uses the decl based target hook. There's also open-coded gather/scatter support which isn't handled by SLP either. The "correct" way is probably to use vect_check_gather_scatter at SLP build time. This can for example be seen when trying to vectorize gcc.dg/vect/tsvc/vect-tsvc-vag.c with single-lane SLP, but gcc.dg/vect/vect-gather-*.c also FAIL without vect_gather_load_ifn.
[Bug libstdc++/110944] std::variant & optional GDB representation is too verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110944 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:701ce3c723623af13597c05df09a049c57c52fc0 commit r14-3451-g701ce3c723623af13597c05df09a049c57c52fc0 Author: Jonathan Wakely Date: Tue Aug 22 14:26:51 2023 +0100 libstdc++: Declutter std::optional and std:variant pretty printers [PR110944] As the PR says, including the template arguments in the GDB output of these class templates can result in very long names, especially for std::variant. You can use 'whatis' or other GDB commands to get details of the type, we don't need to include it in the value. We could consider including the type if it's not too long, but I think consistency is better (and we already omit the template arguments for std::vector and other class templates). libstdc++-v3/ChangeLog: PR libstdc++/110944 * python/libstdcxx/v6/printers.py (StdExpOptionalPrinter): Do not show template arguments. (StdVariantPrinter): Likewise. * testsuite/libstdc++-prettyprinters/compat.cc: Adjust expected output. * testsuite/libstdc++-prettyprinters/cxx17.cc: Likewise. * testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.
[Bug libstdc++/110944] std::variant & optional GDB representation is too verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110944 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Fixed on trunk, thanks for the suggestion.
[Bug libstdc++/111102] illegal pointer arithmetic invoked by std::format("L{:65536}",1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=02 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:dd4bdb9eea436bf06f175d8dbfc2190377455be4 commit r14-3457-gdd4bdb9eea436bf06f175d8dbfc2190377455be4 Author: Paul Dreik Date: Thu Aug 24 11:43:43 2023 +0100 libstdc++: fix illegal pointer arithmetic in format [PR02] When parsing a format string, the width is parsed into an unsigned short but the result is not checked in the case the format string is not a char string (such as a wide string). In case the parse fails, a null pointer is returned which is used for pointer arithmetic which is undefined behaviour. Signed-off-by: Paul Dreik libstdc++-v3/ChangeLog: PR libstdc++/02 * include/std/format (__format::__parse_integer): Check for non-null pointer.
[Bug libstdc++/111102] illegal pointer arithmetic invoked by std::format("L{:65536}",1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=02 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7564fe98657ad5ede34bd08f5279778fa8698865 commit r14-3458-g7564fe98657ad5ede34bd08f5279778fa8698865 Author: Paul Dreik Date: Thu Aug 24 11:43:43 2023 +0100 libstdc++: Add test for illegal pointer arithmetic in format [PR02] libstdc++-v3/ChangeLog: PR libstdc++/02 * testsuite/std/format/string.cc: Check wide character format strings with out-of-range widths.
[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19 --- Comment #1 from Richard Biener --- See https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577577.html for the attempt to move x86 to the internal-fn representation
[Bug c++/111132] New: Function redeclaration in local scope breaks constant expression evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32
Bug ID: 32
Summary: Function redeclaration in local scope breaks constant
expression evaluation
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program
constexpr bool bar(void) {
return true;
}
constexpr bool foo() {
constexpr bool bar(void);
return bar();
}
static_assert( foo() );
is accepted in Clang, but not in GCC, which prints
error: non-constant condition for static assertion
10 | static_assert( foo() );
|~~~^~
:10:19: in 'constexpr' expansion of 'foo()'
:7:15: error: 'constexpr bool bar()' used before its definition
7 | return bar();
|~~~^~
Online demo: https://godbolt.org/z/3PvoEx61x
[Bug target/97807] ICE in output_move_double, at config/arm/arm.c:19689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97807 --- Comment #4 from Richard Earnshaw --- I can reproduce this, but only with -mfloat-abi=soft.
[Bug tree-optimization/111133] New: SLP of scatters not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33
Bug ID: 33
Summary: SLP of scatters not implemented
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
There is no scatter support for (single-lane) SLP. For example
#define N 16
void __attribute__((noipa))
f (float *restrict y, float *restrict x, int *restrict indices)
{
for (int i = 0; i < N; ++i)
{
x[indices[i * 2]] = y[i * 2] + 1;
x[indices[i * 2 + 1]] = y[i * 2 + 1] + 2;
}
}
doesn't vectorize. Note this is also due to
t.c:6:21: note: === vect_analyze_data_ref_dependences ===
t.c:8:25: missed: possible alias involving gather/scatter between *_10 and
*_20
t.c:6:21: missed: bad data dependence.
but with SLP scatters guarantee left-to-right commit so that shouldn't
be an issue there and also shows why SLP is even required for this
to vectorize.
[Bug c++/111123] Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:abf915193fbf725bb359e6936e10dcc282eb94cc commit r14-3460-gabf915193fbf725bb359e6936e10dcc282eb94cc Author: Richard Biener Date: Thu Aug 24 09:32:54 2023 +0200 tree-optimization/23 - indirect clobbers thrown away too early The testcase in the PR shows that late uninit diagnostic relies on indirect clobbers in CTORs but we throw those away in the fab pass which is too early. The reasoning was they were supposed to keep SSA names live but that's no longer the case since DCE doesn't treat them as keeping SSA uses live. The following instead removes them before out-of-SSA coalescing which is the thing that's still affected by them. PR tree-optimization/23 * tree-ssa-ccp.cc (pass_fold_builtins::execute): Do not remove indirect clobbers here ... * tree-outof-ssa.cc (rewrite_out_of_ssa): ... but here. (remove_indirect_clobbers): New function. * g++.dg/warn/Wuninitialized-pr23-1.C: New testcase.
[Bug c++/111123] Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #6 from Richard Biener --- middle-end part are fixed, so with optimization we should diagnose this more consistently now. Leaving open for -O0 and the C++ FE issue.
[Bug c/111130] ice & tree check fail in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- duplicate of PR28?
[Bug middle-end/111134] New: Sections for static data declared in functions with section attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34
Bug ID: 34
Summary: Sections for static data declared in functions with
section attribute
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: manuelhohmann at online dot de
Target Milestone: ---
Using the section attribute, functions can be placed in specific sections.
However, this only places the code in the named section. However, static
variables, static constants and string literals are not affected by this.
Example:
void __attribute__ ((section ".my.text")) testfunc(void)
{
static char data[] = {0, 1, 2, 3};
static const char rodata[] = {4, 5, 6, 7};
puts("test");
}
This will place data in .data, rodata in .rodata and "test" in .rodata.strM.N
(where M and N is related to alignment). The function code itself is in
.my.text.
For the two arrays, one can change the section:
void __attribute__ ((section ".my.text")) testfunc(void)
{
static char __attribute__ ((section ".my.data")) data[] = {0, 1, 2, 3};
static const char __attribute__ ((section ".my.rodata")) rodata[] = {4, 5,
6, 7};
puts("test");
}
This will place them in .my.data and .my.rodata, respectively. However, there
does not seem to be a possibility to do this with string literals. One could
define them as constant char arrays as a workaround. Also there does not seem
to be a possibility to change the section of all static data items in a
function at once.
Would it be possible to allow such functionality e.g. by introducing function
attributes such as
data_section
rodata_section
string_section
which change the names of the sections, but otherwise retain their attributes
(such as mergeable, string for the string literals)? Or / and e.g. a function
attribute along the lines of
__attribute__ ((section_prefix ".my"))
that will prefix all section names (.text, .data, .rodata, .rodata.strM.N) with
the given string for the function and its associated data?
---
Rationale / example use: For certain environments, such as embedded code or
operating system kernels, a boot loader will load a single executable into
memory, containing both initialization and permanent code. Placing
initialization code into a separate section allows to free the occupied memory
once initialization is completed and the code is no longer used. It would be
helpful if along with a function's code also all of its associated data could
be assigned a custom section.
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 David Edelsohn changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #7 from David Edelsohn --- The new testcases in the testsuite for this PR are failing. Is anyone working on these new failures? Is this being tracked in this PR or a new PR for the failures?
[Bug rtl-optimization/110034] The first popped allcono doesn't take precedence over later popped in ira coloring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110034 --- Comment #4 from Vladimir Makarov --- Thank you for providing the test case. To be honest I don't see why assigning to hr3 to r134 is better. Currently we have the following assignments: hr9->r134; hr3->r173; hr3->r124 and the related preferences: cp11:a18(r134)<->a29(r173)@125:shuffle pref3:a29(r173)<-hr3@2000 pref4:a0(r124)<-hr3@125 This removes cost 2000 (pref3) and cost 125 (pref4) and adds cost 125 (cp11). The profit is 2000 If we started with r173, we would have the following assignments: hr3->r173; hr3->r134; ->r124 This would remove cost 2000 (pref3) and cost 125 (cp11) and add cost 125 (pref). The profit would be the same 2000. Choice of heuristics is very time consuming. I spent a lot of time to try and benchmark numerous ones. I clearly remember that introduction of pseudo threads for colorable busket gave visible performance improvement. Currently we assign pseudos from a thread with the biggest frequency first (r173 and r134) and a pseudo (r134) with the biggest frequency first from the same thread. I think it is logical. Also it is always possible to find a test (not this case) where heuristics give some undesirable results. RA is NP-complete task even in the simplest formulation. We can not get the optimal solution for reasonable time. Still I am open to change any heuristic if somebody can show that it improves performance for some credible benchmark (I prefer SPEC2007) on major GCC targets.
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 Jose E. Marchesi changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Last reconfirmed||2023-08-24 Resolution|FIXED |--- --- Comment #8 from Jose E. Marchesi --- I am on it.
[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 Bug 44209 depends on bug 106537, which changed state. Bug 106537 Summary: GCC doesn't support -W[no-]compare-distinct-pointer-types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug c/39589] make -Wmissing-field-initializers=2 work with "designated initializers" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589 Peter Frost changed: What|Removed |Added CC||mail at pfrost dot me --- Comment #14 from Peter Frost --- Created attachment 55786 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55786&action=edit Proposed patch I had a quick go at implementing this as I also wanted this warning. This implements a `-Wmissing-field-initializers=2` warning for uninitialized designated initializers FYI, this is the first time I've worked on the GCC codebase, so I have no idea if this follow best practices etc. But it seems to work if anyone wanted to try it out Thanks, Peter
[Bug middle-end/111134] Sections for static data declared in functions with section attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- I doubt this will be implemented. The whole "data" associated with a function is not exactly true as these functions could be inlined somewhere else. So unless you have a checker (which the linux kernel kinda does but it has so many exceptions in its rules), you are not going to able to do what you want.
[Bug libstdc++/110357] [C++26] P2592R3 Hashing support for std::chrono value classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110357 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-08-24 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug libstdc++/110354] [C++26] P2587R3 to_string or not to_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110354 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Implemented in r14-3299-gaeed687f4e08f1
[Bug libstdc++/110339] Implement C++26 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339 Bug 110339 depends on bug 110354, which changed state. Bug 110354 Summary: [C++26] P2587R3 to_string or not to_string https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110354 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/111135] New: Add ECF_MALLOC for BUILT_IN_GOMP_ALLOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35 Bug ID: 35 Summary: Add ECF_MALLOC for BUILT_IN_GOMP_ALLOC Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- The Fortran side is all in gcc/fortran/f95-lang.cc It seems as if ECF_MALLOC should be added to ATTR_ALLOC_WARN_UNUSED_RESULT_SIZE_2_NOTHROW_LIST to match both builtin-attrs.def; that macro is used for: BUILT_IN_ALIGNED_ALLOC BUILT_IN_GOMP_ALLOC (I find the builtin-attrs.def file not very readable.) I do note that f95-lang.cc has: DECL_IS_MALLOC (builtin_decl_explicit (BUILT_IN_CALLOC)) = 1; while builtins.def uses ATTR_MALLOC_WARN_UNUSED_RESULT_SIZE_1_2_NOTHROW_LEAF_LIST for it. Thus, setting DECL_IS_MALLOC for GOMP_ALLOC explicitly would work as well (ALIGNED_ALLOC is not (yet) used in the Fortran FE.) BTW: The ECF_MALLOC causes DECL_IS_MALLOC to be set via tree.cc's set_call_expr_flags.
[Bug libstdc++/88322] Implement C++20 library features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |14.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- All done on trunk (but still considered experimental for now)
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:5ef89c5c2f52a2c47fd26845d1f73e20b9081fc9 commit r14-3462-g5ef89c5c2f52a2c47fd26845d1f73e20b9081fc9 Author: David Malcolm Date: Thu Aug 24 10:24:38 2023 -0400 analyzer: handle symbolic bindings in scan_for_null_terminator [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * region-model.cc (iterable_cluster::iterable_cluster): Add symbolic binding keys to m_symbolic_bindings. (iterable_cluster::has_symbolic_bindings_p): New. (iterable_cluster::m_symbolic_bindings): New field. (region_model::scan_for_null_terminator): Treat clusters with symbolic bindings as having unknown strlen. gcc/testsuite/ChangeLog: PR analyzer/105899 * gcc.dg/analyzer/sprintf-1.c: Include "analyzer-decls.h". (test_strlen_1): New. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #6 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:0ae07a7203dd24f90e49d025046e61ef90a9fd18 commit r14-3463-g0ae07a7203dd24f90e49d025046e61ef90a9fd18 Author: David Malcolm Date: Thu Aug 24 10:24:38 2023 -0400 analyzer: reimplement kf_strcpy [PR105899] This patch reimplements the analyzer's implementation of strcpy using the region_model::scan_for_null_terminator infrastructure, so that e.g. it can complain about out-of-bounds reads/writes, unterminated strings, etc. gcc/analyzer/ChangeLog: PR analyzer/105899 * kf.cc (kf_strcpy::impl_call_pre): Reimplement using check_for_null_terminated_string_arg. * region-model.cc (region_model::get_store_bytes): Shortcut reading all of a string_region. (region_model::scan_for_null_terminator): Use get_store_value for the bytes rather than "unknown" when returning an unknown length. (region_model::write_bytes): New. * region-model.h (region_model::write_bytes): New decl. gcc/testsuite/ChangeLog: PR analyzer/105899 * gcc.dg/analyzer/out-of-bounds-diagram-16.c: New test. * gcc.dg/analyzer/strcpy-1.c: Add test coverage. * gcc.dg/analyzer/strcpy-3.c: Likewise. * gcc.dg/analyzer/strcpy-4.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #7 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:603bdf906af6d42ce0dabee86efc1e0aec0f1900 commit r14-3464-g603bdf906af6d42ce0dabee86efc1e0aec0f1900 Author: David Malcolm Date: Thu Aug 24 10:24:38 2023 -0400 analyzer: eliminate region_model::get_string_size [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * region-model.cc (region_model::get_string_size): Delete both. * region-model.h (region_model::get_string_size): Delete both decls. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #8 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:d99d73c77d1e9cca5938134b4e6e068945cf50b1 commit r14-3466-gd99d73c77d1e9cca5938134b4e6e068945cf50b1 Author: David Malcolm Date: Thu Aug 24 10:24:39 2023 -0400 analyzer: handle strlen(INIT_VAL(STRING_REG)) [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * region-model.cc (fragment::has_null_terminator): Move STRING_CST handling to fragment::string_cst_has_null_terminator; also use it to handle INIT_VAL(STRING_REG). (fragment::string_cst_has_null_terminator): New, from above. gcc/testsuite/ChangeLog: PR analyzer/105899 * gcc.dg/analyzer/strcpy-3.c (test_2): New. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #10 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:2bad0eeb5573e52c4b7b51546ecffcb17f46eda3 commit r14-3468-g2bad0eeb5573e52c4b7b51546ecffcb17f46eda3 Author: David Malcolm Date: Thu Aug 24 10:24:40 2023 -0400 analyzer: handle strlen(BITS_WITHIN) [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * region-model.cc (fragment::has_null_terminator): Handle SK_BITS_WITHIN. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #9 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:46cb27e56f36f23cb277f8a5beae05235af05768 commit r14-3467-g46cb27e56f36f23cb277f8a5beae05235af05768 Author: David Malcolm Date: Thu Aug 24 10:24:40 2023 -0400 analyzer: handle INIT_VAL(ELEMENT_REG(STRING_REG), CONSTANT_SVAL) [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * region-model-manager.cc (region_model_manager::get_or_create_initial_value): Simplify INIT_VAL(ELEMENT_REG(STRING_REG), CONSTANT_SVAL) to CONSTANT_SVAL(STRING[N]). Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #11 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:bbdc0e0d0042ae16aa4d09ceb52c71e746d9139d commit r14-3469-gbbdc0e0d0042ae16aa4d09ceb52c71e746d9139d Author: David Malcolm Date: Thu Aug 24 10:24:40 2023 -0400 analyzer: implement kf_strcat [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * call-details.cc (call_details::check_for_null_terminated_string_arg): Split into overloads, one taking just an arg_idx, the other a new "include_terminator" param. * call-details.h: Likewise. * kf.cc (class kf_strcat): New. (kf_strcpy::impl_call_pre): Update for change to check_for_null_terminated_string_arg. (register_known_functions): Register kf_strcat. * region-model.cc (region_model::check_for_null_terminated_string_arg): Split into overloads, one taking just an arg_idx, the other a new "include_terminator" param. When returning an svalue, handle "include_terminator" being false by subtracting one. * region-model.h (region_model::check_for_null_terminated_string_arg): Split into overloads, one taking just an arg_idx, the other a new "include_terminator" param. gcc/ChangeLog: PR analyzer/105899 * doc/invoke.texi (Static Analyzer Options): Add "strcat" to the list of functions known to the analyzer. gcc/testsuite/ChangeLog: PR analyzer/105899 * gcc.dg/analyzer/strcat-1.c: New test. Signed-off-by: David Malcolm
[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096 --- Comment #8 from Richard Earnshaw --- (In reply to Thomas Koenig from comment #7) > Would it make sense to document this somewhere? Or did I just miss it? :-) Possibly, but I've no idea where. It's too target-specific to put under the generic documentation for -fomit-frame-pointer and I don't think there's a section in the manual that really documents the target-specific behaviours of generic options.
[Bug tree-optimization/111136] New: ICE in RISC-V test case since r14-3441-ga1558e9ad85693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
Bug ID: 36
Summary: ICE in RISC-V test case since r14-3441-ga1558e9ad85693
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rdapp at gcc dot gnu.org
Target Milestone: ---
Target: riscv
The following RISC-V test case ICEs since r14-3441-ga1558e9ad85693
(mask_gather_load-11.c)
#define uint8_t unsigned char
void
foo (uint8_t *restrict y, uint8_t *restrict x,
uint8_t *index,
uint8_t *cond)
{
for (int i = 0; i < 100; ++i)
{
if (cond[i * 2])
y[i * 2] = x[index[i * 2]] + 1;
if (cond[i * 2 + 1])
y[i * 2 + 1] = x[index[i * 2 + 1]] + 2;
}
}
I compiled with
build/gcc/cc1 -march=rv64gcv -mabi=lp64 -O3
--param=riscv-autovec-preference=scalable mask_gather_load-11.c
mask_gather_load-11.c: In function 'foo':
mask_gather_load-11.c:9:1: internal compiler error: in
get_group_load_store_type, at tree-vect-stmts.cc:2121
9 | foo (uint8_t *restrict y, uint8_t *restrict x,
| ^~~
0x9e2fad get_group_load_store_type
../../gcc/tree-vect-stmts.cc:2121
0x9e2fad get_load_store_type
../../gcc/tree-vect-stmts.cc:2451
0x1ff7221 vectorizable_store
../../gcc/tree-vect-stmts.cc:8309
[...]
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628 --- Comment #9 from Hans-Peter Nilsson --- (In reply to Jan Hubicka from comment #8) > patch posted > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628231.html Yay! I stand ready to revert my ugly cover-up. I'll even give the posted patch a spin for cris-elf!
[Bug middle-end/111134] Sections for static data declared in functions with section attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34 --- Comment #2 from Manuel Hohmann --- (In reply to Andrew Pinski from comment #1) I see. I did not think about the possibility of inlining functions. Could you elaborate how this would affect the proposed goal? Naively I would assume that the code gets inlined, but would still reference the same variables / constants / string literals in their respective .data / .rodata sections, and so one could rename those sections nevertheless.
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 --- Comment #9 from CVS Commits --- The master branch has been updated by Jose E. Marchesi : https://gcc.gnu.org/g:721f7e2c4e5eed645593258624dd91e6c39f3bd2 commit r14-3470-g721f7e2c4e5eed645593258624dd91e6c39f3bd2 Author: Jose E. Marchesi Date: Thu Aug 24 17:10:52 2023 +0200 Fix tests for PR 106537. This patch fixes the tests for PR 106537 (support for -W[no]-compare-distinct-pointer-types) which were expecting the warning when checking for equality/inequality of void pointers with non-function pointers. gcc/testsuite/ChangeLog: PR c/106537 * gcc.c-torture/compile/pr106537-1.c: Comparing void pointers to non-function pointers is legit. * gcc.c-torture/compile/pr106537-2.c: Likewise.
[Bug libstdc++/111129] std::regex incorrectly matches quantifiers with plus appended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29
Jonathan Wakely changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #2 from Jonathan Wakely ---
This changed with r0-127716-g053eb1f31ede72
* include/bits/regex_compiler.h (_Comipler<>::_M_quantifier()):
Fix parse error of multiple consecutive quantifiers like "a**".
* include/bits/regex_compiler.tcc (_Comipler<>::_M_quantifier()):
Likewise.
* testsuite/28_regex/basic_regex/multiple_quantifiers.cc: New.
That added the following tests:
regex re1("a++");
regex re2("(a+)+");
The second one is fine, but the first is invalid. The "a**" case mentioned in
the commit message is invalid too.
I don't know why Tim wanted to accept the first one. ECMAscript and POSIX don't
accept it. My GNU grep does, but I think that's just a bug in glibc's regcomp:
https://sourceware.org/bugzilla/show_bug.cgi?id=20095
[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25 --- Comment #8 from Thiago Jung Bauermann --- Confirmed. All the failures I reported are fixed in trunk. Thank you!
[Bug middle-end/110973] 9% 444.namd regression between g:c2a447d840476dbd (2023-08-03 18:47) and g:73da34a538ddc2ad (2023-08-09 20:17)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110973 Martin Jambor changed: What|Removed |Added CC||fkastl at suse dot cz, ||jamborm at gcc dot gnu.org --- Comment #3 from Martin Jambor --- There was also a 7.7% regression on zen3 with generic march (these measurements are without LTO): https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=466.120.0
[Bug c/111137] New: Wrong code at -O2/3 since r12-1000-g6924b5e6bd3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
Bug ID: 37
Summary: Wrong code at -O2/3 since r12-1000-g6924b5e6bd3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
gcc at -O2/3 produces the wrong code.
Bisected to r12-1000-g6924b5e6bd3
Compiler explorer: https://godbolt.org/z/9fo5dxxhf
$ cat a.c
int printf(const char *, ...);
char a;
int b[3][8];
int c, e = 1, f, g;
short d;
int main() {
for (; e >= 0; e--) {
d = 1;
for (; d >= 0; d--) {
c = 0;
for (; c <= 1; c++) {
b[0][d * 2 + c + 1] = 0;
g = a <= '7';
b[g - 1 + d][c] ^= 1;
}
}
}
printf("%d\n", b[0][1]);
}
$
$ gcc -O0 a.c && ./a.out
1
$ gcc -O2 a.c && ./a.out
0
$
[Bug c/39589] make -Wmissing-field-initializers=2 work with "designated initializers" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589 Manuel López-Ibáñez changed: What|Removed |Added Keywords||patch --- Comment #15 from Manuel López-Ibáñez --- (In reply to Peter Frost from comment #14) > FYI, this is the first time I've worked on the GCC codebase, so I have no > idea if this follow best practices etc. But it seems to work if anyone > wanted to try it out In a nutshell: 1. You need to add some tests that show everything works as expected. 2. You need to run the testsuite 3. You need to submit the patch to gcc-patches. More details: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
[Bug libstdc++/111138] New: views::zip_transform is underconstrained for empty range pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38
Bug ID: 38
Summary: views::zip_transform is underconstrained for empty
range pack
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
int main() {
std::views::zip_transform(0); // hard error in libstdc++
}
https://godbolt.org/z/PYWovhdT4
[Bug tree-optimization/111137] [12/13/14 Regression] Wrong code at -O2/3 since r12-1000-g6924b5e6bd3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37 Andrew Pinski changed: What|Removed |Added Summary|Wrong code at -O2/3 since |[12/13/14 Regression] Wrong |r12-1000-g6924b5e6bd3 |code at -O2/3 since ||r12-1000-g6924b5e6bd3 Target Milestone|--- |12.4 Component|c |tree-optimization
[Bug target/111139] New: RISC-V: improve scalar constants cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39
Bug ID: 39
Summary: RISC-V: improve scalar constants cost model
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vineetg at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com, kito.cheng at gmail dot com,
palmer at dabbelt dot com
Target Milestone: ---
The current const cost determination in riscv_rtx_costs () and its children
such as riscv_const_insns () needs improvements.
1. There's some likely inaccuracies with various heuristics.
2. Those heuristics are distributed in a bunch of places and better be
consolidated.
3. We need to make const cost cpu/uarch tunable as hardware widgets like macro
fusions could ammortize multi-insn const costs.
Some of the heuristics to cleanup/revisit:
1a. riscv_rtx_cost() returns 1 insn even if riscv_const_insns () returns > 1.
case CONST:
if ((cost = riscv_const_insns (x)) > 0)
{
if (cost == 1 && outer_code == SET)
*total = COSTS_N_INSNS (1);
else if (outer_code == SET || GET_MODE (x) == VOIDmode)
*total = COSTS_N_INSNS (1);
}
1b. riscv_const_insns () caps the const cost to 4 even if it higher with intent
to force const pool. RV backend in general no longer favors const pools for
large constants since 2e886eef7f2b5a ("RISC-V: Produce better code with complex
constants [PR95632] [PR106602]"). This heuristic needs to be revisited.
1c. riscv_split_integer_cost () adds 2 to initial cost computed.
[Bug target/111139] RISC-V: improve scalar constants cost model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39 palmer at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-08-24 Ever confirmed|0 |1 CC||palmer at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from palmer at gcc dot gnu.org --- I think maybe Jeff said he was going to look at this? IMO even just a refactoring here would be great, like Vineet is pointing out it's become a bit of a mess. Also: Edwin is refactoring the rest of the types.
[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #11 from Paul Thomas --- (In reply to G. Steinmetz from comment #5) > A simplification might be : > > > $ cat z1.f90 > program p >type t > integer, allocatable :: a >end type >type t2 > type(t) :: b >end type >type t3 > type(t2) :: c >end type > contains >function g(x) > class(t2) :: x > type(t) :: g(2) >end >function f(x) > class(t3) :: x > type(t) :: f(2) > f = g(x%c) >end > end > > > $ gfortran-10-20191215 -c z1.f90 > gimplification failed: > &parm.14
[Bug tree-optimization/111137] [11/12/13/14 Regression] Wrong code at -O2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail||11.1.0
Summary|[12/13/14 Regression] Wrong |[11/12/13/14 Regression]
|code at -O2/3 since |Wrong code at -O2/3
|r12-1000-g6924b5e6bd3 |
Known to work||10.5.0
Last reconfirmed||2023-08-24
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Reduced a little further:
```
int b[3][8];
short d;
volatile int t = 1;
int main() {
int g = t;
for (int e = 1; e >= 0; e--) {
d = 1;
for (; d >= 0; d--) {
b[0][d * 2 + 1] = 0;
b[g - 1 + d][0] ^= 1;
b[0][d * 2 + 2] = 0;
b[g - 1 + d][1] ^= 1;
}
}
if (b[0][1] != 1)
__builtin_abort();
}
```
Note this fails with GCC 11.1.0 with `-O2 -ftree-vectorize` but passes with
`-O3` .
[Bug c++/111132] [11/12/13/14 Regression] Function redeclaration in local scope breaks constant expression evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32 Andrew Pinski changed: What|Removed |Added Known to work||8.5.0 Known to fail||9.1.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||needs-bisection Summary|Function redeclaration in |[11/12/13/14 Regression] |local scope breaks constant |Function redeclaration in |expression evaluation |local scope breaks constant ||expression evaluation Last reconfirmed||2023-08-24 --- Comment #1 from Andrew Pinski --- Confirmed. This used to mostly worked in GCC 8.5.0 and before. In GCC 8.5.0 and before GCC would produce a bogus warning but the static_assert would worked. :7:20: warning: inline function 'constexpr bool bar()' used but never defined constexpr bool bar(void); ^~~
[Bug c++/111140] New: wrong error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40
Bug ID: 40
Summary: wrong error message
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
% cat test.cpp
static void S__f (auto ...) { }
struct S
{
static void f (auto ...) { }
};
int main ()
{
S__f (1, { });
S::f (1, { });
}
% g++ -std=c++20 test.cpp
test.cpp: In function 'int main()':
test.cpp:10:8: error: too many arguments to function 'void S__f(auto:1 ...)
[with auto:1 = {}]'
10 | S__f (1, { });
| ~^~~~
test.cpp:1:13: note: declared here
1 | static void S__f (auto ...) { }
| ^~~~
test.cpp:11:8: error: no matching function for call to 'S::f(int,
)'
11 | S::f (1, { });
| ~^~~~
test.cpp:5:15: note: candidate: 'static void S::f(auto:2 ...) [with auto:2 =
{}]'
5 | static void f (auto ...) { }
| ^
test.cpp:5:15: note: candidate expects 0 arguments, 2 provided
These error messages are just misleading. The functions accept any number of
arguments. The actual problem is that no type can be deduced for "{ }". (Of
course, it's easy to see here, but in more complex situations with multiple
overloads, it makes it really hard to understand what the problem is.)
Also strange: S__f and S::f are practically the same, yet the error message is
differently worded (though the meaning is very close).
[Bug c++/111140] wrong error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-24 Ever confirmed|0 |1
[Bug c++/111140] wrong error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2023-08-24 00:00:00 |
--- Comment #1 from Andrew Pinski ---
Note you don't need to use C++20 features to get the bad error message.
Testcase:
```
#include
template
static void S__f (T...) { }
struct S
{
template
static void f (T ...) { }
};
int main ()
{
S__f (1, { });
S::f (1, { });
}
```
The error message changed between GCC 4.6 and GCC 4.7 though.
GCC 4.6 produced:
```
: In function 'int main()':
:13:15: error: no matching function for call to 'S__f(int,
)'
:13:15: note: candidate is:
:3:13: note: template void S__f(T ...)
:14:15: error: no matching function for call to 'S::f(int,
)'
:14:15: note: candidate is:
:8:15: note: template static void S::f(T ...)
```
While GCC 4.7 produces the error message we know today:
```
: In function 'int main()':
:13:15: error: too many arguments to function 'void S__f(T ...) [with T
= {}]'
:3:13: note: declared here
:14:15: error: no matching function for call to 'S::f(int,
)'
:14:15: note: candidate is:
:8:15: note: static void S::f(T ...) [with T = {}]
:8:15: note: candidate expects 0 arguments, 2 provided
```
[Bug c++/111132] [11/12/13/14 Regression] Function redeclaration in local scope breaks constant expression evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32 Patrick Palka changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Patrick Palka --- The error started with with r9-6136-g43574e4ff2afd4
[Bug bootstrap/111141] New: Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41 Bug ID: 41 Summary: Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: etienne_lorrain at yahoo dot fr Target Milestone: --- On Ubuntu 22.04.3 LTS,Compiling gcc-13.2.0 by: wget https://ftp.gnu.org/gnu/gcc/gcc-13.2.0/gcc-13.2.0.tar.xz tar xf gcc-13.2.0.tar.xz cd gcc-13.2.0/ ./contrib/download_prerequisites cd .. mkdir gcc_build cd gcc_build ../../gcc-13.2.0/configure --enable-languages=c,c++,fortran time make -j 32 Fails with: In file included from /usr/include/bits/errno.h:26, from /usr/include/errno.h:28, from ../../../../gcc-13.2.0/libgcc/../gcc/tsystem.h:93, from ../../../../gcc-13.2.0/libgcc/generic-morestack.c:32: /usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or directory 1 | #include | ^ compilation terminated. make[5]: *** [../../../../gcc-13.2.0/libgcc/shared-object.mk:14: generic-morestack.o] Error 1 make[5]: Leaving directory '/home/etienne/aaa/gcc_build/x86_64-pc-linux-gnu/32/libgcc' make[4]: *** [Makefile:1214: multi-do] Error 1 make[4]: Leaving directory '/home/etienne/aaa/gcc_build/x86_64-pc-linux-gnu/libgcc' make[3]: *** [Makefile:127: all-multi] Error 2 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory '/home/etienne/aaa/gcc_build/x86_64-pc-linux-gnu/libgcc' make[2]: *** [Makefile:24671: all-stage1-target-libgcc] Error 2 make[2]: Leaving directory '/home/etienne/aaa/gcc_build' make[1]: *** [Makefile:30190: stage1-bubble] Error 2 make[1]: Leaving directory '/home/etienne/aaa/gcc_build' make: *** [Makefile:1088: all] Error 2 real1m7.737s user8m1.657s sys 1m2.220s Host compiler being: $ /usr/bin/gcc --version gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 We do have on host a file: /usr/include/asm-generic/errno.h At some point the "-generic" part was modified by default creating a link "asm -> asm-target", but I am not sure now that 64 bits compiler been able to compile 32 bits, the -generic has or not changed meaning... In short I am not sure that is a GCC bug or a Ubuntu bug...
[Bug rtl-optimization/111142] New: [14 regression] ICE in get_group_load_store_type, at tree-vect-stmts.cc:2121 (AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42 Bug ID: 42 Summary: [14 regression] ICE in get_group_load_store_type, at tree-vect-stmts.cc:2121 (AVX512) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: manuel.lauss at googlemail dot com Target Milestone: --- Created attachment 55787 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55787&action=edit compressed unreduced testcase gcc version 14.0.0 20230824 (experimental) 721f7e2c4e5eed645593258624dd91e6c39f3bd2 g++ -m32 -O2 -march=znver4 -c gcc-14-mesa-aco-ice.ii during GIMPLE pass: vect ../mesa-/src/amd/compiler/aco_insert_waitcnt.cpp: In function 'void aco::insert_wait_states(Program*)': ../mesa-/src/amd/compiler/aco_insert_waitcnt.cpp:1042:1: internal compiler error: in get_group_load_store_type, at tree-vect-stmts.cc:2121 can only trigger with "-march=znver4", does not trigger with avx2 only or -O1 or lower. Fails with the same error for x64-64, but the testcase is preprocessed for 32bit targets. Thank you! Manuel
[Bug rtl-optimization/111142] [14 regression] ICE in get_group_load_store_type, at tree-vect-stmts.cc:2121 (AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42
--- Comment #1 from Manuel Lauss ---
This is fairly new, something after 4aa14ec7d5b25722e4d02c29c8c1e22dcc5a4915
("MATCH: [PR09] Fix bit_ior(cond,cond) when comparisons are fp") may have
caused this, since I was able to build mesa just 12 hours ago.
[Bug rtl-optimization/111143] New: [missed optimization] unlikely code slows down diffutils x86-64 ASCII processing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43 Bug ID: 43 Summary: [missed optimization] unlikely code slows down diffutils x86-64 ASCII processing Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: eggert at cs dot ucla.edu Target Milestone: --- Created attachment 55788 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55788&action=edit source code illustrating the performance problem This bug report may be related to bug 110823 (also found for diffutils) but the symptoms differ somewhat so I am reporting it separately. I observed it with GCC 13.1.1 20230614 (Red Hat 13.1.1-4) on x86-64. While tuning GNU diffutils I noticed that its loops to process mostly-ASCII text were not compiled well by GCC on x86-64. For a stripped-down example of the problem, compile the attached program with: gcc -O2 -S code-mcel.c The result is in the attached file code-mcel.s. Its loop kernel assuming ASCII text (starting on line 44) looks like this: .L6: movsbq (%rbx), %rax testb %al, %al js .L4 addq%rax, %r12 movl$1, %eax .L5: addq%rax, %rbx cmpq%r13, %rbx jb .L6 The "movl $1, %eax" immediately followed by "addq %rax, %rbx" is poorly scheduled; the resulting dependency makes the code run quite a bit slower than it should. Replacing it with "addq $1, %rbx" and readjusting the surrounding code accordingly, as is done in the attached file code-mcel-opt.s, causes the benchmark to run 38% faster on my laptop's Intel i5-1335U. It seems that code that GCC knows is unlikely (because of __builtin_expect) is causing the kernel, which GCC knows is likely, to be poorly optimized.
