[Bug tree-optimization/107717] [13 Regression] ICEs expanding permutes after g:dc95e1e9702f2f6367bbc108c8d01169be1b66d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107717 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug middle-end/107718] clang optimizes TSVC s317 a lot better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107718 --- Comment #1 from Richard Biener --- it seems to split the reduction, performing many 0.99 ** n in parallel which is stupid itself as those compute the same result ... I'd say the benchmark is stupid and with -ffast-math we could optimize it to pow (0.99, LEN_1D/2), aka const-fold the inner loop in final value replacement.
[Bug tree-optimization/107717] [13 Regression] ICEs expanding permutes after g:dc95e1e9702f2f6367bbc108c8d01169be1b66d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107717 --- Comment #2 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:cbe313060cdcf1d857d42a9e16a1a03e5ff89fff commit r13-4123-gcbe313060cdcf1d857d42a9e16a1a03e5ff89fff Author: Tamar Christina Date: Thu Nov 17 08:20:59 2022 + middle-end: ensure that VEC_PERM operands get lowered to the same SSA_NAME. [PR107717] At the moment when the VEC_PERMs generated by this match.pd rule is generated it creates two different SSA_NAMEs for the folded operand. Because of this it the permute switches from a single operand permute to a two operand permute and the target may no longer support a permute for this. This fixes it by ensuring we generate the same SSA_NAME for both operands. gcc/ChangeLog: PR tree-optimization/107717 * match.pd: Ensure same SSA_NAME. gcc/testsuite/ChangeLog: PR tree-optimization/107717 * gcc.target/aarch64/sve2/pr107717.c: New test.
[Bug tree-optimization/107717] [13 Regression] ICEs expanding permutes after g:dc95e1e9702f2f6367bbc108c8d01169be1b66d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107717 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tamar Christina --- Fixed
[Bug c++/107732] New: ICE in lower_bound, at value-range.h:350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
Bug ID: 107732
Summary: ICE in lower_bound, at value-range.h:350
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at al42and dot me
Target Milestone: ---
Created attachment 53916
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53916&action=edit
Preprocessed source (-freport-bug)
The following code (reduced example) triggers an ICE with a recent `master`
(96e4244ef3ccf4867ca4e37fbc6800e64ef30af6).
$ cat test.ii
extern "C" double sqrt(double);
double a, b, c;
void d() {
for (;;) {
c = __builtin_fabs(a);
sqrt(c);
if (a)
a = b;
}
}
$ /home/aland/gcc-trunk/bin/g++ -O2 -c test.ii
during GIMPLE pass: thread
test.ii: In function ‘void d()’:
test.ii:3:6: internal compiler error: in lower_bound, at value-range.h:350
3 | void d() {
| ^
0x9a92fc frange::lower_bound() const
../.././gcc/value-range.h:350
0x9a947d frange::lower_bound() const
../.././gcc/value-range.h:1127
0x9a947d foperator_abs::op1_range(frange&, tree_node*, frange const&, frange
const&, relation_trio) const
../.././gcc/range-op-float.cc:1413
0x211bc78 foperator_abs::op1_range(frange&, tree_node*, frange const&, frange
const&, relation_trio) const
../.././gcc/range-op-float.cc:1390
0x2002c25 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
../.././gcc/gimple-range-gori.cc:1095
0x2001913 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../.././gcc/gimple-range-gori.cc:692
0x2002c9f gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
../.././gcc/gimple-range-gori.cc:1150
0x2001913 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../.././gcc/gimple-range-gori.cc:692
0x2005742 gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
../.././gcc/gimple-range-gori.cc:1373
0x13d21fd path_range_query::compute_ranges_in_block(basic_block_def*)
../.././gcc/gimple-range-path.cc:454
0x13d28a2 path_range_query::compute_ranges(bitmap_head const*)
../.././gcc/gimple-range-path.cc:622
0x14569e9 back_threader::find_taken_edge_cond(vec const&, gcond*)
../.././gcc/tree-ssa-threadbackward.cc:324
0x1456b9e back_threader::maybe_register_path(back_threader_profitability&)
../.././gcc/tree-ssa-threadbackward.cc:248
0x1456ec8 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
../.././gcc/tree-ssa-threadbackward.cc:371
0x145737c back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
../.././gcc/tree-ssa-threadbackward.cc:479
0x145737c back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
../.././gcc/tree-ssa-threadbackward.cc:479
0x1457dbf back_threader::maybe_thread_block(basic_block_def*)
../.././gcc/tree-ssa-threadbackward.cc:551
0x1457e71 back_threader::thread_blocks()
../.././gcc/tree-ssa-threadbackward.cc:979
0x1457ed0 execute
../.././gcc/tree-ssa-threadbackward.cc:1081
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/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org, ||tnfchris at gcc dot gnu.org --- Comment #10 from Richard Biener --- Tamar, are the IFN_COMPLEX_FMA and IFN_COMPLEX_FMA_CONJ FP contracting operations as well?
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 --- Comment #10 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:822a0823c012b912f0108a4da257cd97cbcdb7a3 commit r13-4125-g822a0823c012b912f0108a4da257cd97cbcdb7a3 Author: Aldy Hernandez Date: Sat Nov 12 11:58:07 2022 +0100 [PR68097] Try to avoid recursing for floats in gimple_stmt_nonnegative_warnv_p. It irks me that a PR named "we should track ranges for floating-point hasn't been closed in this release. This is an attempt to do just that. As mentioned in the PR, even though we track ranges for floats, it has been suggested that avoiding recursing through SSA defs in gimple_assign_nonnegative_warnv_p is also a goal. This patch uses a global range query (no on-demand lookups, just global ranges and minimal folding) to determine if the range of a statement is known to be non-negative. PR tree-optimization/68097 gcc/ChangeLog: * gimple-fold.cc (gimple_stmt_nonnegative_warnv_p): Call range_of_stmt for floats.
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 68097, which changed state. Bug 68097 Summary: We should track ranges for floating-point values too https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/68097] We should track ranges for floating-point values too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Aldy Hernandez --- fixed
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #11 from Tamar Christina --- (In reply to Richard Biener from comment #10) > Tamar, are the IFN_COMPLEX_FMA and IFN_COMPLEX_FMA_CONJ FP contracting > operations as well? Yes, they have no intermediate rounding.
[Bug tree-optimization/107451] [11/12/13 Regression] Segmentation fault with vectorized code since r11-6434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #7 from Richard Biener ---
Apart from the permute issue that's maybe there the issue of the segfault is
failure to code generate the loads correctly to match the SLP analysis. We
generate loads as if we'd use a VF of 2 but use only the lower part but DCE /
simplification doesn't simplify
_64 = MEM [(const double *)ivtmp_66];
ivtmp_63 = ivtmp_66 + _75;
_62 = MEM [(const double *)ivtmp_63];
vect_cst__60 = {_64, _62};
vect__4.12_59 = VEC_PERM_EXPR ;
to, for example
_64 = MEM [(const double *)ivtmp_66];
ivtmp_63 = ivtmp_66 + _75;
vect_cst__60 = {_64, _64};
vect__4.12_59 = VEC_PERM_EXPR ;
(we now also allow VEC_PERM of _64, _64 directly with GCC 13, but the targets
need to be ready for this)
That's probably a latent issue in other cases as well. We'd either need to
disallow these kind of load permutations or make sure we only reference
the actually loaded DR group when filling the input vectors.
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #12 from Tamar Christina --- Note that the same IFN is used for integer MLA as well. We didn't split them apart.
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #13 from Richard Biener --- Created attachment 53917 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53917&action=edit patch I am testing OK, I'm testing the following then - can you see if that works for the complex fmas and if the aarch64 testsuite needs any adjustments? (-ffp-contract=fast is default)
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #14 from Tamar Christina --- (In reply to Richard Biener from comment #13) > Created attachment 53917 [details] > patch I am testing > > OK, I'm testing the following then - can you see if that works for the > complex fmas and if the aarch64 testsuite needs any adjustments? > (-ffp-contract=fast is default) Will do, this needs a check on the type no? SVE2 adds complex integer MLAs which should be fine (we didn't split the IFNs).
[Bug analyzer/107733] New: GCC - -Wanayzer-null-dereference false positive with wrong path note "(3) 'e' is NULL" and inconsistent behaviors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107733
Bug ID: 107733
Summary: GCC - -Wanayzer-null-dereference false positive with
wrong path note "(3) 'e' is NULL" and inconsistent
behaviors
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: geoffreydgr at icloud dot com
Target Milestone: ---
I got a false positive warning when compiling the following program with
`gcc(trunk) -fanalyzer -O0` in https://godbolt.org/z/YbeGcc5cd. After
deleting ` int *d = 0;`, the NPD disappears. I think it is ok for gcc to emit
this FP warning, but deleting the unrelated code ` int *d = 0;` should not
affect the result. And the path note `(3) 'e' is NULL` is wrong, this may
suggest some problems.
I have tried this with gcc 12, gcc 11, and gcc 10, and all of them have this
phenomenon.
Program:
```c
#include
void a( int* e) {
printf("NPD_FLAG\n");
if(e == 0){
int *d = 0;
*e = 1;
}
}
int main() {
int i =5;
a(&i);
}
```
Warning:
```bash
: In function 'a':
:6:12: warning: dereference of NULL 'e' [CWE-476]
[-Wanalyzer-null-dereference]
6 | *e = 1;
| ~~~^~~
'a': events 1-4
|
|4 | if(e == 0){
| | ^
| | |
| | (1) following 'true' branch (when 'e' is NULL)...
|5 |int *d = 0;
| | ~
| | |
| | (2) ...to here
| | (3) 'e' is NULL
|6 | *e = 1;
| | ~~
| ||
| |(4) dereference of NULL 'e'
|
```
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #15 from Alexander Monakov ---
I'm confused about the first hunk in the attached patch:
--- a/gcc/tree-vect-slp-patterns.cc
+++ b/gcc/tree-vect-slp-patterns.cc
@@ -1035,8 +1035,10 @@ complex_mul_pattern::matches (complex_operation_t op,
auto_vec left_op, right_op;
slp_tree add0 = NULL;
- /* Check if we may be a multiply add. */
+ /* Check if we may be a multiply add. It's only valid to form FMAs
+ with -ffp-contract=fast. */
if (!mul0
+ && flag_fp_contract_mode != FP_CONTRACT_FAST
&& vect_match_expression_p (l0node[0], PLUS_EXPR))
{
auto vals = SLP_TREE_CHILDREN (l0node[0]);
Shouldn't it be ' == FP_CONTRACT_FAST' rather than '!='? It seems we are
checking that a match is found and contracting across statement boundaries is
allowed.
[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633 Arthur Cohen changed: What|Removed |Added CC||cohenarthur.dev at gmail dot com --- Comment #8 from Arthur Cohen --- Hi there, The problem has been fixed and our bootstrap build is green again :) this will be fixed in the v4 of patches that I will send soon. Sorry for the frustration caused!
[Bug c++/101747] Two-argument version of attribute malloc does not perform overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101747 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #2 from Rainer Orth --- I've recently run into what seems to be the same issue, cf. GDB PR build/29791 for details: all of gdbsupport fails to compile with gcc 12.2.0 on Solaris like this: In file included from /usr/include/sys/time.h:448, from ../gnulib/import/sys/time.h:39, from /usr/include/sys/select.h:27, from ../gnulib/import/sys/select.h:36, from /usr/include/sys/types.h:665, from ../gnulib/import/sys/types.h:39, from ../gnulib/import/stdio.h:58, from /vol/src/gnu/gdb/hg/master/dist/gdbsupport/common-defs.h:86, from /vol/src/gnu/gdb/hg/master/dist/gdbsupport/ptid.cc:20: ../gnulib/config.h:1693:72: error: ‘malloc’ attribute argument 1 is ambiguous 1693 | # define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f, i))) | ^ ../gnulib/config.h:1693:72: note: use a cast to the expected type to disambiguate ../gnulib/config.h:1693:72: error: ‘malloc’ attribute argument 1 is ambiguous The preprocessed testcase (not reduced) is attached to that PR: https://sourceware.org/bugzilla/show_bug.cgi?id=29791 Unfortunately, nobody has been able to determine yet where exactly the ambiguity lies, and unlike other cases, g++ doesn't show that. Any suggestions on how to proceed?
[Bug libstdc++/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 --- Comment #7 from Tamar Christina --- (In reply to Andrew Pinski from comment #5) > Can you try right before r13-3707-g4e4e3ffd10f53e and right afterwards? > > I would have assumed, the exception would not happen really. Sadly doesn't seem to be it. I'll script a bisect.
[Bug libstdc++/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 --- Comment #8 from Florian Weimer --- (In reply to Tamar Christina from comment #4) > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-fde.c:111 > #6 __register_frame_info (begin=, ob=0x48cfe8 ) at > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-fde.c:150 > #7 0x00400798 in frame_dummy () at > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361 > #8 0x00400f90 in __libc_csu_init () at > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361 > #9 0x00400a78 in __libc_start_main () at > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361 > #10 0x00400688 in _start () at > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361 Looks like a build with USE_EH_FRAME_REGISTRY. Unless you have configured with --explicit-exception-frame-registration=yes, it may mean that USE_PT_GNU_EH_FRAME was not detected correctly.
[Bug sanitizer/103930] asan intercepts fail if target library is only loaded (indirectly) through dlopen (e.g. plugin)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103930
Jan Engelhardt changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #1 from Jan Engelhardt ---
gcc version 12.2.1 20221020 [revision 0aaef83351473e8f4eb774f8f999bbe87a4866d7]
(SUSE Linux)
Thread 5 "a.out" hit Breakpoint 2, __interceptor_crypt (key=0x60207050 "",
salt=0x60b15800 "") at
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:9981
9981INTERCEPTOR(char *, crypt, char *key, char *salt) {
(gdb) n
9983 COMMON_INTERCEPTOR_ENTER(ctx, crypt, key, salt);
(gdb)
9984 COMMON_INTERCEPTOR_READ_RANGE(ctx, key, internal_strlen(key) + 1);
(gdb)
9985 COMMON_INTERCEPTOR_READ_RANGE(ctx, salt, internal_strlen(salt) + 1);
(gdb)
9986 char *res = REAL(crypt)(key, salt);
(gdb) disas
…
=> 0x77862cdd <+125>: lea-0x28(%rbp),%rsp
0x77862ce1 <+129>: mov%r12,%rsi
0x77862ce4 <+132>: mov%rbx,%rdi
0x77862ce7 <+135>: pop%rbx
0x77862ce8 <+136>: pop%r12
0x77862cea <+138>: pop%r13
0x77862cec <+140>: pop%r14
0x77862cee <+142>: pop%r15
0x77862cf0 <+144>: pop%rbp
0x77862cf1 <+145>: jmp*0xeade1(%rip)# 0x7794dad8
<_ZN14__interception10real_cryptE>
…
(gdb) p _ZN14__interception10real_cryptE
$1 = (crypt_type) 0x0
[Bug libstdc++/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 --- Comment #9 from Tamar Christina --- (In reply to Florian Weimer from comment #8) > (In reply to Tamar Christina from comment #4) > > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-fde.c:111 > > #6 __register_frame_info (begin=, ob=0x48cfe8 ) at > > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-fde.c:150 > > #7 0x00400798 in frame_dummy () at > > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361 > > #8 0x00400f90 in __libc_csu_init () at > > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361 > > #9 0x00400a78 in __libc_start_main () at > > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361 > > #10 0x00400688 in _start () at > > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-btree.h:361 > > Looks like a build with USE_EH_FRAME_REGISTRY. Unless you have configured > with --explicit-exception-frame-registration=yes, it may mean that > USE_PT_GNU_EH_FRAME was not detected correctly. No, it's just made using default configure flags, no extra options.
[Bug sanitizer/103930] asan intercepts fail if target library is only loaded (indirectly) through dlopen (e.g. plugin)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103930 --- Comment #2 from Jan Engelhardt --- Subissue a) "the crash output is completely useless" seems to have been addressed in the past already; I observe in gcc 12 that Found plugin run function: 0x7fecaa0e01a0 AddressSanitizer:DEADLYSIGNAL = ==75097==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x bp 0x7ffccfe3f0b0 sp 0x7ffccfe3f0a8 T0) ==75097==Hint: pc points to the zero page. ==75097==The signal is caused by a READ memory access. ==75097==Hint: address points to the zero page. #0 0x0 () #1 0x4010ea in main main.c:10 #2 0x7feca982c5af in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 (But yeah, I remember a time when calling null pointer functions often meant no usable stack trace, even in gdb. Not sure what that was about.)
[Bug c/107734] New: valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734 Bug ID: 107734 Summary: valgrind error for gcc/testsuite/cc.target/i386/pr46051.c Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I just built a valgrind version of today's gcc trunk. When compiling source code file gcc.target/i386/pr46051.c, I got the following: $ ~/gcc/results.20221117.valgrind/bin/gcc -c -O2 ./gcc.target/i386/pr46051.c ==639651== Conditional jump or move depends on uninitialised value(s) ==639651==at 0x11DFAE7: bitmap_set_bit (sbitmap.h:137) ==639651==by 0x11DFAE7: gimple_simplify_122(gimple_match_op*, gimple**, tree _node* (*)(tree_node*), tree_node*, tree_node**, tree_code) (gimple-match.cc:489 33) ==639651==by 0x1154189: gimple_simplify_MULT_EXPR(gimple_match_op*, gimple** , tree_node* (*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*) ( gimple-match.cc:131594) ==639651==by 0x10771D1: gimple_resimplify2(gimple**, gimple_match_op*, tree_ node* (*)(tree_node*)) (gimple-match-head.cc:323)
[Bug c++/107138] [12/13 regression] std::variant triggers false-positive 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138 Marco Clemencic changed: What|Removed |Added CC||marco.clemencic at gmail dot com --- Comment #3 from Marco Clemencic --- Created attachment 53918 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53918&action=edit another example of false uninitialized warning
[Bug c/107734] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734 --- Comment #1 from David Binderman --- The valgrind problem doesn't seem to occur with git hash 05432288d4e56055, dated 20221113, so the bug is recent. I used git hash 2b2f2ee49a33419f for today's build.
[Bug c++/107138] [12/13 regression] std::variant triggers false-positive 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
--- Comment #4 from Marco Clemencic ---
I have a similar problem with this chunk of code:
```
#include
#include
#include
#include
#include
struct Wrapper {
using Map = std::map;
using Value = std::variant;
Wrapper(Value v) : data{std::move(v)} {}
Value data;
};
auto f() {
Wrapper::Map r;
return std::make_unique(std::move(r)); // <- warning here
// return std::make_unique(r); // <- no warning
// return Wrapper(std::move(r)); // <- no warning
}
```
but the uninitialized variable is coming from std::unique_ptr.
As in the original report it works with gcc 11.3, but it fails with gcc12.2 and
trunk (in my case already with -O1), see https://godbolt.org/z/bfo9vsEPc
I attached the .ii produced by my test case.
[Bug c++/107138] [12/13 regression] std::variant triggers false-positive 'may be used uninitialized' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138 --- Comment #5 from Marco Clemencic --- I forgot to mention that I compiled with the options: g++ -c -Wmaybe-uninitialized -O1 -v -save-temps test.cpp
[Bug c/107734] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734 --- Comment #2 from David Binderman --- git blame says dc95e1e970 (Hongyu Wang 2022-01-17 13:01:51 +0800 8292)if (!bitmap_set_bit (seen, sel[i].to_constant ()))
[Bug c/107734] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734 --- Comment #3 from David Binderman --- Another test case: ./gcc.target/i386/pr53366-2.c ==41== Conditional jump or move depends on uninitialised value(s) ==41==at 0x11DFAE7: bitmap_set_bit (sbitmap.h:137) ==41==by 0x11DFAE7: gimple_simplify_122(gimple_match_op*, gimple**, tree_node* (*)(tree_node*), tree_node*, tree_node**, tree_code) (gimple-match.cc:48933)
[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #16 from Richard Biener ---
(In reply to Alexander Monakov from comment #15)
> I'm confused about the first hunk in the attached patch:
>
> --- a/gcc/tree-vect-slp-patterns.cc
> +++ b/gcc/tree-vect-slp-patterns.cc
> @@ -1035,8 +1035,10 @@ complex_mul_pattern::matches (complex_operation_t op,
>auto_vec left_op, right_op;
>slp_tree add0 = NULL;
>
> - /* Check if we may be a multiply add. */
> + /* Check if we may be a multiply add. It's only valid to form FMAs
> + with -ffp-contract=fast. */
>if (!mul0
> + && flag_fp_contract_mode != FP_CONTRACT_FAST
>&& vect_match_expression_p (l0node[0], PLUS_EXPR))
> {
>auto vals = SLP_TREE_CHILDREN (l0node[0]);
>
>
> Shouldn't it be ' == FP_CONTRACT_FAST' rather than '!='? It seems we are
> checking that a match is found and contracting across statement boundaries
> is allowed.
whoops yes, I'll fix and add a check for the type.
[Bug c++/105278] -Wliteral-range vs -Wfloat-equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278 --- Comment #7 from Eric Gallager --- (In reply to Andrew Pinski from comment #6) > I don't think clang implements -Wfloat-equal at all, at least they didn't at > the last time I looked a few years back. I just checked their diagnostics reference page and it says that they do: https://clang.llvm.org/docs/DiagnosticsReference.html#wfloat-equal
[Bug c/107734] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734 --- Comment #4 from David Binderman --- A third: ./gcc.target/i386/pr61403.c ==749959== Conditional jump or move depends on uninitialised value(s) ==749959==at 0x11DFAE7: bitmap_set_bit (sbitmap.h:137) ==749959==by 0x11DFAE7: gimple_simplify_122(gimple_match_op*, gimple**, tree_node* (*)(tree_node*), tree_node*, tree_node**, tree_code) (gimple-match.cc:48933)
[Bug target/107604] FAIL: gcc.target/aarch64/aapcs64/test_dfp_17.c execution, -O0 fails on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604 --- Comment #2 from Christophe Lyon --- Confirmed. In test_dfp_17.c we have: ARG(_Decimal64, 11.0dd, D0) DOTS ANON(struct z, a, D1) ANON(struct z, b, STACK) ANON(int , 5, W0) ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ LAST_ANON(_Decimal64, 0.5dd, STACK+40) Execution fails on aarch64_be for argument: ANON(_Decimal32, f1, STACK+32) in main() we generate: str s0, [sp, 32]// 19 [c=4 l=4] *movsd_aarch64/7 for aarch64 and str s0, [sp, 36]// 19 [c=4 l=4] *movsd_aarch64/7 for aarch64_be Alignment for the last argument (_Decimal64) still seems OK, at sp+40.
[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #16 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #15)
> On Wed, 16 Nov 2022, amacleod at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
> >
> > Andrew Macleod changed:
> >
> >What|Removed |Added
> >
> > Status|NEW |ASSIGNED
> >Assignee|unassigned at gcc dot gnu.org |amacleod at redhat
> > dot com
> >
> > --- Comment #14 from Andrew Macleod ---
> > Created attachment 53910 [details]
> > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53910&action=edit
> > patch to fix the problem
> >
> > This patch fixes the PR, but exposes issues in other passes. They introduce
> > undefined behaviour by hoisting POINTER_PLUS expressions into blocks in
> > which
> > the operand is not known to be non-null. (See PR 107709)
> > Until this can be audited fully, we put this patch on hold.
>
> In fact the patch doesnt 'exploit the fact that the result of
> pointer addition can not be nullptr' but it exploits that if
> ptr + CST is performed then 'ptr' cannot be nullptr(?)
>
GCC already exploits the title of the PR, when the code represents it with that
situation.
The only case we don't get is if the code is reordered slightly as the testcase
in comment 4:
bool f(int* a)
{
bool x = a == nullptr;
a += 10;
return x;
}
That testcase requires this patch.
> That is, it assumes that there is a zero sized object at nullptr and
> thus the pointer increment to outside (but not one after it) invokes UB.
>
> That's much more aggressive than optimizing
>
> ptr + 4 != nullptr
>
> to true and I'm not sure the reasoning follows. I think at 'nullptr'
> there is _no_ object and thus the restriction to pointer addition
> doesn't apply at all - if a pointer does not refer to an object then
> the rule that increment to outside of the object invokes UB doesn't
> apply.
It implements comment 11, and comment 12 confirmed that 11 was accurate.
(1)
>> X + Y would be non-null if either X or Y is known to be non-null.
so if Y is non-zero, X + Y is non-zero.
(2)
>> If we know that X + Y is non-null via some mechanism (for example the result
>> was dereferenced), then we know that X and Y are non-null.
X + Y is non-null based on (2)
Going back to the code generated for this:
x_2 = a_1(D) == 0B;
a_3 = a_1(D) + 40;
return x_2;
The only way to to return 1 with this sequence is for a_3 = a_1(D) + 40 to
determine that a_1 is non-zero after this statement... which is what this patch
does.
It then reapplies this knowledge as a recomputation of x_2 based on this
knowledge after the defintion of a_3.
So yes, this is much more aggressive. I suppose in theory we could close this
PR and open a new one to cover the more aggressive version.
[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #17 from rguenther at suse dot de ---
On Thu, 17 Nov 2022, amacleod at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
>
> --- Comment #16 from Andrew Macleod ---
> (In reply to rguent...@suse.de from comment #15)
> > On Wed, 16 Nov 2022, amacleod at redhat dot com wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
> > >
> > > Andrew Macleod changed:
> > >
> > >What|Removed |Added
> > >
> > > Status|NEW |ASSIGNED
> > >Assignee|unassigned at gcc dot gnu.org |amacleod at
> > > redhat dot com
> > >
> > > --- Comment #14 from Andrew Macleod ---
> > > Created attachment 53910 [details]
> > > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53910&action=edit
> > > patch to fix the problem
> > >
> > > This patch fixes the PR, but exposes issues in other passes. They
> > > introduce
> > > undefined behaviour by hoisting POINTER_PLUS expressions into blocks in
> > > which
> > > the operand is not known to be non-null. (See PR 107709)
> > > Until this can be audited fully, we put this patch on hold.
> >
> > In fact the patch doesnt 'exploit the fact that the result of
> > pointer addition can not be nullptr' but it exploits that if
> > ptr + CST is performed then 'ptr' cannot be nullptr(?)
> >
>
> GCC already exploits the title of the PR, when the code represents it with
> that
> situation.
> The only case we don't get is if the code is reordered slightly as the
> testcase
> in comment 4:
>
> bool f(int* a)
> {
> bool x = a == nullptr;
> a += 10;
> return x;
> }
>
> That testcase requires this patch.
>
>
> > That is, it assumes that there is a zero sized object at nullptr and
> > thus the pointer increment to outside (but not one after it) invokes UB.
> >
> > That's much more aggressive than optimizing
> >
> > ptr + 4 != nullptr
> >
> > to true and I'm not sure the reasoning follows. I think at 'nullptr'
> > there is _no_ object and thus the restriction to pointer addition
> > doesn't apply at all - if a pointer does not refer to an object then
> > the rule that increment to outside of the object invokes UB doesn't
> > apply.
>
> It implements comment 11, and comment 12 confirmed that 11 was accurate.
>
> (1)
> >> X + Y would be non-null if either X or Y is known to be non-null.
> so if Y is non-zero, X + Y is non-zero.
> (2)
> >> If we know that X + Y is non-null via some mechanism (for example the
> >> result was dereferenced), then we know that X and Y are non-null.
> X + Y is non-null based on (2)
But (2) is IMHO false for 'nullptr + 4', we know from (1) that the result
is not nullptr but we don't know that _both_ are not null. I don't see
how computing 'nullptr + 4' invokes UB. Hmm, one might read that
into C17/6.5.6/8 "If both the pointer operand and the result point to
elements of the same array object, or one past the last element of an
array object, the evaluation shall not produce an overflow; otherwise,
the behavior is undefined" - here nullptr and nullptr + 4 do not
point to elements of the same array object (nullptr doesn't point to
any object), so 'otherwise' applies and the behavior is undefined?
[Bug tree-optimization/107451] [11/12/13 Regression] Segmentation fault with vectorized code since r11-6434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #8 from Richard Biener ---
Peeling for gaps also isn't a good fix here. One could envision a case with
even three iterations ahead load with
for(i = 0; i < n; i++) {
dot[0] += x[ix] * y[ix] ;
dot[1] += x[ix] * y[ix] ;
dot[2] += x[ix] * y[ix] ;
dot[3] += x[ix] * y[ix] ;
ix += inc_x ;
}
or similar. The root cause is how we generate code for VMAT_STRIDED_SLP
where we first generate loads to fill a contiguous output vector but only
then create the permute using the pieces that are actually necessary.
We could simply fail if 'nloads' is bigger than 'vf', or cap 'nloads' and
fail if we the cannot generate the permutation.
When we force VMAT_ELEMENTWISE the very same issue arises but later
optimization will eliminate the unnecessary loads, avoiding the problem:
_62 = *ivtmp_64;
_61 = MEM[(const double *)ivtmp_64 + 8B];
ivtmp_60 = ivtmp_64 + _75;
_59 = *ivtmp_60;
_58 = MEM[(const double *)ivtmp_60 + 8B];
ivtmp_57 = ivtmp_60 + _75;
vect_cst__48 = {_62, _61, _59, _58};
vect__4.12_47 = VEC_PERM_EXPR ;
that just becomes
_62 = MEM[(const double *)ivtmp_64];
_61 = MEM[(const double *)ivtmp_64 + 8B];
ivtmp_60 = ivtmp_64 + _75;
vect__4.12_47 = {_61, _62, _61, _62};
with cost modeling and VMAT_ELEMENTWISE we fall back to SSE vectorization
which works fine.
I fear the proper fix is to integrate load emission with
vect_transform_slp_perm_load somehow, we shouldn't rely on followup
simplifications to fix what the vectorizer emits here.
Since we have no fallback detecting the situation and avoiding it completely
would mean to not vectorize the code (with AVX).
[Bug tree-optimization/107451] [11/12/13 Regression] Segmentation fault with vectorized code since r11-6434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #9 from bartoldeman at users dot sourceforge.net ---
I ended up using -mprefer-vector-width=128 as a workaround myself (via
__attribute__((target("prefer-vector-width=128", so there is still some AVX
vectorization.
[Bug tree-optimization/107451] [11/12/13 Regression] Segmentation fault with vectorized code since r11-6434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #10 from Richard Biener ---
Interestingly the following variant of the testcase falls back to
VMAT_ELEMENTWISE but does have the same problem there fixed up by later
folding, but it will segfault when using -O2 -mavx2 -fno-vect-cost-model
-fdisable-tree-vrp2 -fdisable-free-forwprop4 which then keeps the bogus
_62 = *ivtmp_64;
_61 = MEM[(const double *)ivtmp_64 + 8B];
ivtmp_60 = ivtmp_64 + _65;
_59 = *ivtmp_60;
_58 = MEM[(const double *)ivtmp_60 + 8B];
ivtmp_57 = ivtmp_60 + _65;
vect_cst__56 = {_62, _61, _59, _58};
vect__4.7_55 = VEC_PERM_EXPR ;
that problem should be present even before the r11-6434 change. In fact
this segfaults on the GCC 10 branch with just -O2 -ftree-loop-vectorize -mavx2
generating the same load/permute as trunk for the reduction (so there's some
half-way "fix" on the later branches). Also broken with GCC 9.5.
static void __attribute__((noipa))
setdot(int n, const double *x, int inc_x, const double *y, double * __restrict
dot)
{
int i, ix = 0;
for(i = 0; i < n; i++) {
dot[i*4+0] = x[ix] * y[ix] ;
dot[i*4+1] = x[ix+1] * y[ix+1] ;
dot[i*4+2] = x[ix] * y[ix+1] ;
dot[i*4+3] = x[ix+1] * y[ix] ;
ix += inc_x ;
}
}
int main(void)
{
double x[2] = {0, 0}, y[2] = {0, 0};
double dot[4];
setdot(1, x, 4096*4096, y, dot);
return 0;
}
[Bug libstdc++/107735] New: Inconsistent error messages for std::array out of bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735
Bug ID: 107735
Summary: Inconsistent error messages for std::array out of
bound
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrzej at rpi dot pl
Target Milestone: ---
Created attachment 53919
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53919&action=edit
Preprocessed file
The second and third lines of following code produce different `out of bound`
compile errors, one pointing to the original line, the other pointing to a line
inside standard library that is trying to access internal (non-std::) array
constexpr std::array array = {1, 2, 3};
constexpr int v1 = array[3];
constexpr int v2 = array[4];
Compilation line:
`g++-12 a-minimal_example.ii`
Compiler output:
minimal_example.cpp:6:27: error: array subscript value ‘3’ is outside the
bounds of array type ‘std::__array_traits::_Type’ {aka ‘const int [3]’}
6 | constexpr int v1 = array[3];
| ^
In file included from minimal_example.cpp:1:
minimal_example.cpp:9:27: in ‘constexpr’ expansion of ‘array.std::array::operator[](4)’
/usr/include/c++/12/array:219:25: in ‘constexpr’ expansion of
‘std::__array_traits::_S_ref(((const std::array*)this)->std::array::_M_elems, __n)’
/usr/include/c++/12/array:61:36: error: array subscript value ‘4’ is outside
the bounds of array type ‘std::__array_traits::_Type’ {aka ‘const int
[3]’}
61 | { return const_cast<_Tp&>(__t[__n]); }
| ~~~^
GCC version:
gcc-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0
System version:
Linux 5.15.0-52-generic #58-Ubuntu SMP x86_64
GCC build options:
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.1.0-2ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
[Bug c++/107732] ICE in lower_bound, at value-range.h:350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732 Aldy Hernandez changed: What|Removed |Added Last reconfirmed||2022-11-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||aldyh at gcc dot gnu.org
[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from Marek Polacek --- Fixed then.
[Bug tree-optimization/90134] ICE in duplicate_eh_regions_1, at except.c:557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90134 --- Comment #4 from Arseny Solokha --- (In reply to Andrew Pinski from comment #3) > This code is all undefined anyways . Yes, but what about unmodified tests from libstdc++? I occasionally hit this ICE on them too, as shown in comment 2. I've just got it w/ g++-13 -O1 -ftree-parallelize-loops=2 -fno-lifetime-dse -fnon-call-exceptions --param max-early-inliner-iterations=0 -Ilibstdc++-v3/testsuite/util -c libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc which triggers on the same code from include/g++-v13/bits/stl_uninitialized.h
[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #18 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #17)
> On Thu, 17 Nov 2022, amacleod at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
> >
> > --- Comment #16 from Andrew Macleod ---
> > (In reply to rguent...@suse.de from comment #15)
> > > On Wed, 16 Nov 2022, amacleod at redhat dot com wrote:
> > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
> > > >
> > > > Andrew Macleod changed:
> > > >
> > > >What|Removed |Added
> > > >
> > > > Status|NEW |ASSIGNED
> > > >Assignee|unassigned at gcc dot gnu.org |amacleod at
> > > > redhat dot com
> > > >
> > > > --- Comment #14 from Andrew Macleod ---
> > > > Created attachment 53910 [details]
> > > > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53910&action=edit
> > > > patch to fix the problem
> > > >
> > > > This patch fixes the PR, but exposes issues in other passes. They
> > > > introduce
> > > > undefined behaviour by hoisting POINTER_PLUS expressions into blocks in
> > > > which
> > > > the operand is not known to be non-null. (See PR 107709)
> > > > Until this can be audited fully, we put this patch on hold.
> > >
> > > In fact the patch doesnt 'exploit the fact that the result of
> > > pointer addition can not be nullptr' but it exploits that if
> > > ptr + CST is performed then 'ptr' cannot be nullptr(?)
> > >
> >
> > GCC already exploits the title of the PR, when the code represents it with
> > that
> > situation.
> > The only case we don't get is if the code is reordered slightly as the
> > testcase
> > in comment 4:
> >
> > bool f(int* a)
> > {
> > bool x = a == nullptr;
> > a += 10;
> > return x;
> > }
> >
> > That testcase requires this patch.
> >
> >
> > > That is, it assumes that there is a zero sized object at nullptr and
> > > thus the pointer increment to outside (but not one after it) invokes UB.
> > >
> > > That's much more aggressive than optimizing
> > >
> > > ptr + 4 != nullptr
> > >
> > > to true and I'm not sure the reasoning follows. I think at 'nullptr'
> > > there is _no_ object and thus the restriction to pointer addition
> > > doesn't apply at all - if a pointer does not refer to an object then
> > > the rule that increment to outside of the object invokes UB doesn't
> > > apply.
> >
> > It implements comment 11, and comment 12 confirmed that 11 was accurate.
> >
> > (1)
> > >> X + Y would be non-null if either X or Y is known to be non-null.
> > so if Y is non-zero, X + Y is non-zero.
> > (2)
> > >> If we know that X + Y is non-null via some mechanism (for example the
> > >> result was dereferenced), then we know that X and Y are non-null.
> > X + Y is non-null based on (2)
>
> But (2) is IMHO false for 'nullptr + 4', we know from (1) that the result
> is not nullptr but we don't know that _both_ are not null. I don't see
> how computing 'nullptr + 4' invokes UB. Hmm, one might read that
> into C17/6.5.6/8 "If both the pointer operand and the result point to
> elements of the same array object, or one past the last element of an
> array object, the evaluation shall not produce an overflow; otherwise,
> the behavior is undefined" - here nullptr and nullptr + 4 do not
> point to elements of the same array object (nullptr doesn't point to
> any object), so 'otherwise' applies and the behavior is undefined?
FWIW, that would be my take... NULL + anything would be UB. Assuming of
course 0 is not an addressable value.
[Bug c++/107732] ICE in lower_bound, at value-range.h:350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732 --- Comment #1 from Aldy Hernandez --- Created attachment 53920 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53920&action=edit untested [PR tree-optimization/107732] [range-ops] Handle attempt to abs() negatives. The threader is creating a scenario where we are trying to solve: [NEGATIVES] = abs(x) While solving this we have an intermediate value of UNDEFINED because we have no positive numbers. But then we try to union the negative pair to the final result by querying the bounds. Since neither UNDEFINED nor NAN have bounds, they need to be specially handled.
[Bug c++/107732] ICE in lower_bound, at value-range.h:350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732 --- Comment #2 from Andrey Alekseenko --- @Aldy Hernandez, thank you. Can confirm that your patch fully resolves the issue for me.
[Bug c++/107732] ICE in lower_bound, at value-range.h:350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732 --- Comment #3 from Aldy Hernandez --- (In reply to Andrey Alekseenko from comment #2) > @Aldy Hernandez, thank you. Can confirm that your patch fully resolves the > issue for me. No problem. Thank your for reporting and for reducing. It makes my life easier.
[Bug c++/107735] Inconsistent error messages for std::array out of bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-11-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|libstdc++ |c++ --- Comment #1 from Jonathan Wakely --- Libstdc++ doesn't print those errors, this is component=c++
[Bug target/107604] FAIL: gcc.target/aarch64/aapcs64/test_dfp_17.c execution, -O0 fails on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604 --- Comment #3 from Christophe Lyon --- and patching test_dfp_17.c like so: - ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */ + ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */ makes it pass on aarch64_be
[Bug target/107714] MVE: Invalid addressing mode generated for VLD2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107714 Stam Markianos-Wright changed: What|Removed |Added Last reconfirmed||2022-11-17 --- Comment #3 from Stam Markianos-Wright --- Thanks for finding this! Confirmed the `vld2` bug on latest trunk -- my guess would be either a GCC backend or a gas bug (I'm not familiar with these instructions). For the `vmulq` issue I'll reply under the other thread, but I believe that very soon we'll be able to put that down as "already fixed", so we can keep this thread for `vld2` only.
[Bug target/107515] MVE: Generic functions do not accept _Float16 scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515 Stam Markianos-Wright changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Stam Markianos-Wright --- (In reply to Kevin Bracey from comment #2) > I've just spotted another apparent generic selection problem in my > reproducer for bug 107714 - should I create a new issue for it? Our patch series has gone up to the mailing list! For _Float16 see: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606587.html For `vmuq` this: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606575.html works on my side, so if it gets merged and works for your case, too, then I guess we don't have to worry about a new bug report :)
[Bug c/107734] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #5 from David Binderman ---
I have reduced one of the test cases downto this code:
float val1f[][2], val2f[][2], chkf[][2];
foof_i;
foof() {
int j;
foof_i = 0;
for (; foof_i < 8; foof_i++) {
float tmp = val1f[foof_i][j] * val2f[foof_i][j];
j = 0;
for (; j < 2; j++)
chkf[foof_i][j] = tmp;
}
}
[Bug c/107734] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734 --- Comment #6 from David Binderman --- I am trying a bisect with git hash b4fca4fc70dc76cf.
[Bug analyzer/107711] [13 Regression] ICE with "-fanalyzer -Wunused-macros" since r13-4073-gd8aba860b34203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711 --- Comment #11 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:f9ed1d24ee46f5ca759c35a1f51fa163d7529ea6 commit r13-4130-gf9ed1d24ee46f5ca759c35a1f51fa163d7529ea6 Author: David Malcolm Date: Thu Nov 17 12:34:56 2022 -0500 c, analyzer: fix ICE with -fanalyzer and -Wunused-macros [PR107711] PR analyzer/107711 reports an ICE since r13-4073-gd8aba860b34203 with the combination of -fanalyzer and -Wunused-macros. The issue is that in c_translation_unit::consider_macro's call to cpp_create_reader I was passing "ident_hash" for use by the the new reader, but that takes ownership of that hash_table, so that ident_hash erroneously gets freed when c_translation_unit::consider_macro calls cpp_destroy, leading to a use-after-free in -Wunused-macros, where: (gdb) p pfile->hash_table->pfile == pfile $23 = false and it's instead pointing at the freed reader from consider_macro, leading to a use-after-free ICE. Fixed thusly. gcc/c/ChangeLog: PR analyzer/107711 * c-parser.cc (ana::c_translation_unit::consider_macro): Pass NULL to cpp_create_reader, rather than ident_hash, so that the new reader gets its own hash table. gcc/testsuite/ChangeLog: PR analyzer/107711 * gcc.dg/analyzer/named-constants-Wunused-macros.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/107711] [13 Regression] ICE with "-fanalyzer -Wunused-macros" since r13-4073-gd8aba860b34203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711 David Malcolm changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #12 from David Malcolm --- Should be fixed by the above patch.
[Bug middle-end/107734] [13 Regression] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
Andrew Pinski changed:
What|Removed |Added
Summary|valgrind error for |[13 Regression] valgrind
|gcc/testsuite/cc.target/i38 |error for
|6/pr46051.c |gcc/testsuite/cc.target/i38
||6/pr46051.c
Target Milestone|--- |13.0
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Keywords||ice-checking,
||ice-on-valid-code
Last reconfirmed||2022-11-17
Component|c |middle-end
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #7 from Andrew Pinski ---
I have the obvious patch.
diff --git a/gcc/match.pd b/gcc/match.pd
index 5aba1653b80..a4d1386fd9f 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -8288,6 +8288,8 @@ and,
if (sel.encoding ().encoded_full_vector_p ())
{
auto_sbitmap seen (nelts);
+ bitmap_clear (seen);
+
unsigned HOST_WIDE_INT count = 0, i;
for (i = 0; i < nelts; i++)
[Bug c++/107732] ICE in lower_bound, at value-range.h:350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732 --- Comment #4 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:4e306222f442f8d4c6fc6da997ab756a5e43e36e commit r13-4131-g4e306222f442f8d4c6fc6da997ab756a5e43e36e Author: Aldy Hernandez Date: Thu Nov 17 16:47:17 2022 +0100 [PR tree-optimization/107732] [range-ops] Handle attempt to abs() negatives. The threader is creating a scenario where we are trying to solve: [NEGATIVES] = abs(x) While solving this we have an intermediate value of UNDEFINED because we have no positive numbers. But then we try to union the negative pair to the final result by querying the bounds. Since neither UNDEFINED nor NAN have bounds, they need to be specially handled. PR tree-optimization/107732 gcc/ChangeLog: * range-op-float.cc (foperator_abs::op1_range): Early exit when result is undefined. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr107732.c: New test.
[Bug c++/107732] ICE in lower_bound, at value-range.h:350
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Aldy Hernandez --- fixed
[Bug middle-end/107734] [13 Regression] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:ee892832ea19b21a3420ef042e582204fac852a2 commit r13-4132-gee892832ea19b21a3420ef042e582204fac852a2 Author: Andrew Pinski Date: Thu Nov 17 17:48:00 2022 + Fix PR 107734: valgrind errors with sbitmap in match.pd sbitmap is a simple bitmap and the memory allocated is not cleared on creation; you have to clear it or set it to all ones before using it. This is unlike bitmap which is a sparse bitmap and the entries are cleared as created. The code added in r13-4044-gdc95e1e9702f2f missed that. This patch fixes that mistake. Committed as obvious after a bootstrap and test on x86_64-linux-gnu. gcc/ChangeLog: PR middle-end/107734 * match.pd (perm + vector op pattern): Clear the sbitmap before use.
[Bug middle-end/107734] [13 Regression] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Andrew Pinski --- Fixed.
[Bug c++/105278] -Wliteral-range vs -Wfloat-equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278
--- Comment #8 from Andrew Pinski ---
So clang emits one or the other warning for the code but not both.
You can defect the warning in clang by doing:
```
extern void g( int);
void f(float a)
{
double b = a;
if (b == 0.1234)
g( 1);
}
```
LLVM actually opimizes away the comparison while GCC does not.
[Bug c/107736] New: call to a function, generated by inline asm, is off by one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
Bug ID: 107736
Summary: call to a function, generated by inline asm, is off by
one byte
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: miladfarca at gmail dot com
Target Milestone: ---
Tested on Arm64, PPC64 and s390x with gcc 12.
```
const char num = 0;
void call();
asm( ".globl call\n"
".type call, %function \n"
".hidden call \n"
"call: \n"
// Just return.
"ret\n");
int main(){
call();
return 0;
}
```
TL;DR:
The instruction generated for `call();` is jumping to the address of `num` and
causing a crash as `num` is not an instruction, seems to be an alignment issue?
Details:
- This doesn't happen on x64 and call is made to the correct address. It also
does not happen with clang on either platforms (tested with version 6.0).
- gcc is putting "call" into .rodata section of memory including on x64. Not
sure if this is a separate bug or intentional. clang is putting it under
".text" as expected.
- gcc is incorrectly assuming `&num` is the address of `call` and jumping to it
which is off by 1 byte.
- Workarounds include adding either ".text \n" or ".align 8" to the inline asm,
tho call should be made to the correct address even without them?
[Bug middle-end/107737] New: seemly looking off code in gimplify_call_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737 Bug ID: 107737 Summary: seemly looking off code in gimplify_call_expr Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- The code has: ``` location_t loc = EXPR_LOCATION (*expr_p); gcc_assert (TREE_CODE (*expr_p) == CALL_EXPR); /* For reliable diagnostics during inlining, it is necessary that every call_expr be annotated with file and line. */ if (! EXPR_HAS_LOCATION (*expr_p)) SET_EXPR_LOCATION (*expr_p, input_location); USE(loc) below ``` This seems wrong for the location. I don't know if the SET_EXPR_LOCATION is dead code or not but this does seem wrong.
[Bug c/107736] call to a function, generated by inline asm, is off by one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Keywords||inline-asm Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- >- Workarounds include adding either ".text \n" or ".align 8" to the inline >asm, tho call should be made to the correct address even without them? That is NOT a workaround but the correct fix to the toplevel inline-asm. Toplevel inline-asm will be emitted without any knowledge of the current section. It could even be inside the data section or even worse the debugging info section. There is no knowledge of the current alignment in there either.
[Bug c/107736] call to a function, generated by inline asm, is off by one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736 --- Comment #2 from mfarca --- > Toplevel inline-asm will be emitted without any knowledge of the current > section. So this is a limitation of gcc I guess? as clang does have the knowledge on which is which. The main issue still persists as call is made to the wrong address.
[Bug c/107738] New: Top-level inline-asm is not well documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107738 Bug ID: 107738 Summary: Top-level inline-asm is not well documented Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: documentation, inline-asm Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- There is only one reference to the top-level inline-asm in the whole user manual: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Basic-Asm.html#Basic-Asm There should be a section here talking about common mistakes using top-level inline-asm including but not limited to: * assuming the section and alignment where the top-level inline-asm will be emitted to ** Give examples on how to do push/pop section or using previous_section *** make a mention this is depdent on the assembler being used * assuming the order (reference also -fno-toplevel-reorder option) compared to functions * Give examples of other types of top-level inline-asm usage * Make a mention of a limitation dealing with them and LTO and the reason why you should avoid them and use other ways of doing the same thing instead
[Bug fortran/99884] Double spaces in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99884 --- Comment #2 from CVS Commits --- The master branch has been updated by Bernhard Reutner-Fischer : https://gcc.gnu.org/g:19be89d79ee149e812ccc6027956cefb7f3e1016 commit r13-4133-g19be89d79ee149e812ccc6027956cefb7f3e1016 Author: Bernhard Reutner-Fischer Date: Sun Oct 31 13:57:46 2021 +0100 Fortran: Remove double spaces in open() warning [PR99884] gcc/fortran/ChangeLog: PR fortran/99884 * io.cc (check_open_constraints): Remove double spaces.
[Bug c/107736] call to a function, generated by inline asm, is off by one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107738 --- Comment #3 from Andrew Pinski --- >So this is a limitation of gcc I guess? I suspect it just accidently works for clang/LLVM. The section at the time was a text section when clang emits the assembler (most likely it assumes it is the first thing in the file) You could define a global symbol there in the top-level inline-asm and think it should work as a read-write symbol but it does not; there is no way clang would know that was what you think it should do. Note I filed PR 107738 for some of the more common mistakes of top-level inline-asm
[Bug middle-end/107734] [13 Regression] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734 --- Comment #10 from David Binderman --- (In reply to Andrew Pinski from comment #9) > Fixed. Thanks for that. Would it ok to manually check all uses of sbitmap, to make sure they initialise bits appropriately, or would it be better to define a constructor which sets the internal bitmap data to something sensible ?
[Bug c/107736] call to a function, generated by inline asm, is off by one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736 --- Comment #4 from mfarca --- Thanks for creating the issue for improving documentation. Could you then clarify if call to the incorrect address is a bug or not? instructions are allowed to be under `.rodata` section as this section is still executable and works fine on x64, more on this: https://stackoverflow.com/a/44938843
[Bug c/107738] Top-level inline-asm is not well documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107738 --- Comment #1 from Andrew Pinski --- I know there are other related bugs where people mess up the top-level inline-asm too but I can't find them right now.
[Bug c/107736] call to a function, generated by inline asm, is off by one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736 --- Comment #5 from Andrew Pinski --- (In reply to mfarca from comment #4) > Thanks for creating the issue for improving documentation. > > Could you then clarify if call to the incorrect address is a bug or not? > instructions are allowed to be under `.rodata` section as this section is > still executable and works fine on x64, more on this: > https://stackoverflow.com/a/44938843 x64 does not have an alignment requirement for instructions while the other targets do. That is all. x64 does not have an alignment requirement because the instructions are all different sizes including some single byte instructions. This is an ISA difference really and not really a GCC question at this point.
[Bug middle-end/107734] [13 Regression] valgrind error for gcc/testsuite/cc.target/i386/pr46051.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734 --- Comment #11 from Andrew Pinski --- (In reply to David Binderman from comment #10) > (In reply to Andrew Pinski from comment #9) > > Fixed. > > Thanks for that. > > Would it ok to manually check all uses of sbitmap, to make sure they > initialise bits appropriately, or would it be better to define a constructor > which sets > the internal bitmap data to something sensible ? I suspect most are done correctly either having bitmap_clear or bitmap_ones right after the creation of the sbitmap (I looked at a few when I was writing this patch). Someone could go and audit all of them but I am working on other things at this point really.
[Bug c/106764] [12/13 Regression] ICE on invalid code in tree check: expected function_type or method_type, have error_mark in gimplify_call_expr, at gimplify.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106764 --- Comment #3 from Andrew Pinski --- At the point where the CALL_EXPR is built: Breakpoint 5, build_function_call_vec (loc=258624, arg_loc=..., function=, params=0x0, origtypes=0x0, orig_fundecl=) at /home/apinski/src/upstream-gcc/gcc/gcc/c/c-typeck.cc:3250 3250 fntype = TREE_TYPE (function); function is: (gdb) p debug_tree(function) QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7726e9d8 pointer_to_this > unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x773e5930> used public static unsigned read DI defer-output t.c:1:3 size unit-size align:64 warn_if_not_align:0> And the type is fine. And then the code in duplicate_decls goes and replaces the type to be error_mark_node. And then we don't check for error_mark_node later on during gimplification. Trying to figure out the best place to put the check for error_mark_node now. Note while looking into the gimplification code, I found some odd looking code dealing with the location so I filed PR 107737.
[Bug bootstrap/107739] New: --enable-languages= duplicates yield odd error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107739 Bug ID: 107739 Summary: --enable-languages= duplicates yield odd error Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: aldot at gcc dot gnu.org Target Milestone: --- Mere cosmetics, but the error is contradicting it's own hint in a confusing way. $ ../../src/gcc-13.mine/configure --enable-languages=c++,lto,lto configure: error: The following requested languages could not be built: lto Supported languages are: c,c,c++,fortran,go,lto,objc,obj-c++ or other dups like $ ../../src/gcc-13.mine/configure --enable-languages=c++,c++,lto configure: error: The following requested languages could not be built: c++ Supported languages are: c,c,c++,fortran,go,lto,objc,obj-c++ I'm not sure why duplicates are not ignored silently.
[Bug c/106764] [12/13 Regression] ICE on invalid code in tree check: expected function_type or method_type, have error_mark in gimplify_call_expr, at gimplify.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106764 --- Comment #4 from Andrew Pinski --- Actually the fix is just check the return value of gimplify_expr to make sure it was not GS_ERROR. diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc index f06ce3cc77a..9b74f957308 100644 --- a/gcc/gimplify.cc +++ b/gcc/gimplify.cc @@ -3709,6 +3709,9 @@ gimplify_call_expr (tree *expr_p, gimple_seq *pre_p, bool want_value) ret = gimplify_expr (&CALL_EXPR_FN (*expr_p), pre_p, NULL, is_gimple_call_addr, fb_rvalue); + if (ret == GS_ERROR) +return GS_ERROR; + nargs = call_expr_nargs (*expr_p); /* Get argument types for verification. */
[Bug middle-end/107307] [12/13 Regression] ICE tree check: expected class 'type', have 'exceptional' (error_mark) in canonicalize_component_ref, at gimplify.cc:2923 since r12-3278-g823685221de986af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107307
--- Comment #2 from Andrew Pinski ---
Simple fix:
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index f06ce3cc77a..bd772c15bec 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3319,7 +3319,9 @@ gimplify_compound_lval (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p,
}
/* If the outermost expression is a COMPONENT_REF, canonicalize its type.
*/
- if ((fallback & fb_rvalue) && TREE_CODE (*expr_p) == COMPONENT_REF)
+ if (ret != GS_ERROR
+ && (fallback & fb_rvalue)
+ && TREE_CODE (*expr_p) == COMPONENT_REF)
{
canonicalize_component_ref (expr_p);
}
I am going to submit this and PR 106764 together.
[Bug middle-end/107307] [12/13 Regression] ICE tree check: expected class 'type', have 'exceptional' (error_mark) in canonicalize_component_ref, at gimplify.cc:2923 since r12-3278-g823685221de986af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107307 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106765 --- Comment #3 from Andrew Pinski --- Actually the patch which works better: diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc index f06ce3cc77a..c62a966e918 100644 --- a/gcc/gimplify.cc +++ b/gcc/gimplify.cc @@ -3272,6 +3272,8 @@ gimplify_compound_lval (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p, tret = gimplify_expr (p, pre_p, post_p, is_gimple_min_lval, fallback | fb_lvalue); ret = MIN (ret, tret); + if (ret == GS_ERROR) +return GS_ERROR; /* Step 2a: if we have component references we do not support on registers then make sure the base isn't a register. Of course Also fixes PR 106765.
[Bug tree-optimization/107740] New: if-to-switch conversion happens for simple predicate function when compiled with gcc but not with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740
Bug ID: 107740
Summary: if-to-switch conversion happens for simple predicate
function when compiled with gcc but not with g++
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
For the following testcase, the ||'s are converted into a switch statement when
compiling with gcc but not with g++ (despite only minor differences in their
GENERIC trees) and ultimately leads to seemingly worse codegen when compiling
with g++ vs gcc:
$ cat is_whitespace.c
int
is_whitespace (char c)
{
return (c == ' '
|| c == '\n'
|| c == '\r'
|| c == '\t');
}
$ gcc -fdump-tree-{original,iftoswitch}=/dev/stdout -O2 is_whitespace.C
;; Function is_whitespace (null)
;; enabled by -tree-original
{
return (c == 32 || c == 10) || (c == 13 || c == 9);
}
;; Function is_whitespace (is_whitespace, funcdef_no=0, decl_uid=2735,
cgraph_uid=1, symbol_order=0)
;; Canonical GIMPLE case clusters: 9-10 13 32
;; BT can be built: BT:9-32
Removing basic block 3
Expanded into a new gimple STMT: switch (c_8(D)) [INV], case 9:
[INV], case 10: [INV], case 13: [INV], case 32: [INV]>
int is_whitespace (char c)
{
_Bool _1;
_Bool _2;
_Bool _3;
int iftmp.0_7;
:
_1 = c_8(D) == 32;
_2 = c_8(D) == 10;
_3 = _1 | _2;
switch (c_8(D)) [INV], case 9: [INV], case 10:
[INV], case 13: [INV], case 32: [INV]>
:
:
:
# iftmp.0_7 = PHI <1(3), 0(2)>
:
return iftmp.0_7;
}
$ g++ -fdump-tree-{original,iftoswitch}=/dev/stdout -O2 is_whitespace.C
;; Function int is_whitespace(char) (null)
;; enabled by -tree-original
return = (int) ((c == 32 || c == 10) || (c == 13 || c == 9));
;; Function is_whitespace (_Z13is_whitespacec, funcdef_no=0, decl_uid=2757,
cgraph_uid=1, symbol_order=0)
int is_whitespace (char c)
{
bool _1;
bool _2;
bool _3;
bool _4;
bool _5;
bool _6;
bool iftmp.0_7;
int _11;
:
_1 = c_8(D) == 32;
_2 = c_8(D) == 10;
_3 = _1 | _2;
if (_3 != 0)
goto ; [INV]
else
goto ; [INV]
:
_4 = c_8(D) == 13;
_5 = c_8(D) == 9;
_6 = _4 | _5;
:
# iftmp.0_7 = PHI <1(2), _6(3)>
_11 = (int) iftmp.0_7;
return _11;
}
[Bug c/107705] [12/13 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in ix86_function_type_abi, at config/i386/i386.cc:1529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107705 --- Comment #2 from Andrew Pinski --- diff --git a/gcc/function.cc b/gcc/function.cc index 361aa5f7ed1..9c8773bbc59 100644 --- a/gcc/function.cc +++ b/gcc/function.cc @@ -2090,6 +2090,9 @@ aggregate_value_p (const_tree exp, const_tree fntype) if (VOID_TYPE_P (type)) return 0; + if (error_operand_p (fntype)) +return 0; + /* If a record should be passed the same as its first (and only) member don't pass it as an aggregate. */ if (TREE_CODE (type) == RECORD_TYPE && TYPE_TRANSPARENT_AGGR (type))
[Bug tree-optimization/107740] if-to-switch conversion happens for simple predicate function when compiled with gcc but not with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- There might be already another bug about this specific case (code) even.
[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #9) > Something like the following rejects NULL when there is no interface: Submitted: https://gcc.gnu.org/pipermail/fortran/2022-November/058531.html
[Bug tree-optimization/107740] [12/13 Regression] if-to-switch conversion happens for simple predicate function when compiled with gcc but not with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |12.3 Last reconfirmed||2022-11-17 Status|UNCONFIRMED |NEW Summary|if-to-switch conversion |[12/13 Regression] |happens for simple |if-to-switch conversion |predicate function when |happens for simple |compiled with gcc but not |predicate function when |with g++|compiled with gcc but not ||with g++ --- Comment #2 from Andrew Pinski --- The difference is PHI-OPT: For C++ we have: _4 = c_8(D) == 13; _5 = c_8(D) == 9; _6 = _4 | _5; if (_6 != 0) goto ; [INV] else goto ; [INV] : : # iftmp.0_7 = PHI <1(4), 0(3)> Which phi-opt1 changes to: _4 = c_8(D) == 13; _5 = c_8(D) == 9; _6 = _4 | _5; : # iftmp.0_7 = PHI <1(2), _6(3)> (note type is bool) But for C we have: if (_6 != 0) goto ; [INV] else goto ; [INV] : : # iftmp.0_7 = PHI <1(4), 0(3)> (note the type is int) phi-opt1 is the "early phi-opt" which tries not to do it here. Also this is a regression from GCC 11.3.0. There has been improvements to phi-opt and there was slight IR change due to cleanup cfg after cddce1 which allowed phi-opt to do the change here. Note PHI-OPT is not at fault really but if-to-switch not handling the slightly different IR really.
[Bug tree-optimization/107740] [12/13 Regression] if-to-switch conversion happens for simple predicate function when compiled with gcc but not with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740 --- Comment #3 from Andrew Pinski --- >phi-opt1 is the "early phi-opt" which tries not to do it here. Let me expand on that, it tries not to insert a cast here to do the conversion from bool to int.
[Bug target/101985] vec_cpsgn parameter order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985 Mark Abraham changed: What|Removed |Added CC||mark.j.abraham at gmail dot com --- Comment #11 from Mark Abraham --- Also discovered in the SIMD compatibility layer for GROMACS https://gitlab.com/gromacs/gromacs/-/issues/4661
[Bug fortran/107595] ICE in ix86_push_argument, at config/i386/i386.cc:4335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- Slight reduction of the testcase: program p type t integer, pointer :: b end type ! type(t) :: x = t(null()) ! OK type(t)x /t(null())/ ! ICE if (associated (x%b)) stop end Comparing the -fdump-fortran-original for both variants: @@ -15,7 +15,7 @@ result: associated symtree: 'null'|| symbol: 'null' type spec : (INTEGER 4) -attributes: (PROCEDURE INTRINSIC-PROC FUNCTION IMPLICIT-TYPE ARRAY-OUTER-DEPENDENCY) +attributes: (PROCEDURE FUNCTION IMPLICIT-TYPE ARRAY-OUTER-DEPENDENCY) result: null symtree: 'p' || symbol: 'p' type spec : (UNKNOWN 0) @@ -27,8 +27,8 @@ result: t symtree: 'x' || symbol: 'x' type spec : (DERIVED t) -attributes: (VARIABLE IMPLICIT-SAVE) -value: t(NULL()) +attributes: (VARIABLE DATA) +value: t(null[()]) code: IF _gfortran_associated[[((p:x % b) ((arg not-present)))]] Are we just missing the resolution of NULL() in the failing case early enough?
[Bug c++/107735] Inconsistent error messages for std::array out of bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735 --- Comment #2 from Andrew Pinski --- I wonder if this is because doing constexpr const int *v1 = &array[3]; is valid and well defined. Even clang gives two different error messages: :3:21: error: constexpr variable 'v1' must be initialized by a constant expression constexpr const int v1 = array[3]; ^ :3:26: note: read of dereferenced one-past-the-end pointer is not allowed in a constant expression constexpr const int v1 = array[3]; ^ :4:15: error: constexpr variable 'v2' must be initialized by a constant expression constexpr int v2 = array[4]; ^ /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/13.0.0/../../../../include/c++/13.0.0/array:213:9: note: cannot refer to element 4 of array of 3 elements in a constant expression return _M_elems[__n]; ^ :4:20: note: in call to '&array->operator[](4)' constexpr int v2 = array[4]; ^ CUT I do think clang's note of one-past-the-end gives more of a hint of why the error message is different though. And I do think GCC could add that note.
[Bug bootstrap/107739] --enable-languages= duplicates yield odd error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107739 --- Comment #1 from Andrew Pinski --- I thought this was fixed at one point.
[Bug middle-end/107737] seemly looking off code in gimplify_call_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=40435 Last reconfirmed||2022-11-17 Keywords||internal-improvement Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- r0-94701-gdb3927fb49c9 (for PR 40435) added the "loc = EXPR_LOCATION (*expr_p);" before setting of the location. The original code of gimplify_call_expr (when it was merged in from the tree-ssa branch) had the setting of the location if it was not set. I think for GCC 14, I am going to try to see if setting of the location is really still needed (that is going to change it to an assert and run a full bootstrap/test including Ada).
[Bug middle-end/107737] seemly looking off code in gimplify_call_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/104066] "constinit extern long (*const f) ();" doesn't compile: gcc thinks "constinit" applies to return value, not to function pointer itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:7b3b2f50953c5143d4b14b59d322d8a793f411dd commit r13-4135-g7b3b2f50953c5143d4b14b59d322d8a793f411dd Author: Marek Polacek Date: Thu Nov 17 11:59:29 2022 -0500 c++: constinit on pointer to function [PR104066] [dcl.constinit]: "The constinit specifier shall be applied only to a declaration of a variable with static or thread storage duration." Thus, this ought to be OK: constinit void (*p)() = nullptr; but the error message I introduced when implementing constinit was not looking at funcdecl_p, so the code above was rejected. Fixed thus. I'm checking constinit_p first because I think that's far more likely to be false than funcdecl_p. PR c++/104066 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Check funcdecl_p before complaining about constinit. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constinit18.C: New test.
[Bug c++/104066] "constinit extern long (*const f) ();" doesn't compile: gcc thinks "constinit" applies to return value, not to function pointer itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:14faa5f585f6025df1e04c8c8b34340ff5e4d494 commit r12-8916-g14faa5f585f6025df1e04c8c8b34340ff5e4d494 Author: Marek Polacek Date: Thu Nov 17 11:59:29 2022 -0500 c++: constinit on pointer to function [PR104066] [dcl.constinit]: "The constinit specifier shall be applied only to a declaration of a variable with static or thread storage duration." Thus, this ought to be OK: constinit void (*p)() = nullptr; but the error message I introduced when implementing constinit was not looking at funcdecl_p, so the code above was rejected. Fixed thus. I'm checking constinit_p first because I think that's far more likely to be false than funcdecl_p. PR c++/104066 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Check funcdecl_p before complaining about constinit. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constinit18.C: New test. (cherry picked from commit 7b3b2f50953c5143d4b14b59d322d8a793f411dd)
[Bug c++/104066] "constinit extern long (*const f) ();" doesn't compile: gcc thinks "constinit" applies to return value, not to function pointer itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:90824f6c57e1ac7b94c558b4c99721b412df75ef commit r11-10381-g90824f6c57e1ac7b94c558b4c99721b412df75ef Author: Marek Polacek Date: Thu Nov 17 11:59:29 2022 -0500 c++: constinit on pointer to function [PR104066] [dcl.constinit]: "The constinit specifier shall be applied only to a declaration of a variable with static or thread storage duration." Thus, this ought to be OK: constinit void (*p)() = nullptr; but the error message I introduced when implementing constinit was not looking at funcdecl_p, so the code above was rejected. Fixed thus. I'm checking constinit_p first because I think that's far more likely to be false than funcdecl_p. PR c++/104066 gcc/cp/ChangeLog: * decl.c (grokdeclarator): Check funcdecl_p before complaining about constinit. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constinit18.C: New test. (cherry picked from commit 7b3b2f50953c5143d4b14b59d322d8a793f411dd)
[Bug c++/107735] Inconsistent error messages for std::array out of bound due to taking the address of one-past-the-end is valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735 --- Comment #3 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #2) > I wonder if this is because doing > constexpr const int *v1 = &array[3]; > > is valid and well defined. It's not, but &array.data()[3] is. I agree that's probably the reason for the different diagnostics.
[Bug c++/104066] "constinit extern long (*const f) ();" doesn't compile: gcc thinks "constinit" applies to return value, not to function pointer itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:b9b78b4de3c7dcc6868c4af831b2d213fda21b04 commit r10-11087-gb9b78b4de3c7dcc6868c4af831b2d213fda21b04 Author: Marek Polacek Date: Thu Nov 17 11:59:29 2022 -0500 c++: constinit on pointer to function [PR104066] [dcl.constinit]: "The constinit specifier shall be applied only to a declaration of a variable with static or thread storage duration." Thus, this ought to be OK: constinit void (*p)() = nullptr; but the error message I introduced when implementing constinit was not looking at funcdecl_p, so the code above was rejected. Fixed thus. I'm checking constinit_p first because I think that's far more likely to be false than funcdecl_p. PR c++/104066 gcc/cp/ChangeLog: * decl.c (grokdeclarator): Check funcdecl_p before complaining about constinit. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constinit18.C: New test. (cherry picked from commit 7b3b2f50953c5143d4b14b59d322d8a793f411dd)
[Bug c++/104066] "constinit extern long (*const f) ();" doesn't compile: gcc thinks "constinit" applies to return value, not to function pointer itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed everywhere.
[Bug c++/107735] Inconsistent error messages for std::array out of bound due to taking the address of one-past-the-end is valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735 --- Comment #4 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #3) > (In reply to Andrew Pinski from comment #2) > > I wonder if this is because doing > > constexpr const int *v1 = &array[3]; > > > > is valid and well defined. > > It's not, but &array.data()[3] is. > > I agree that's probably the reason for the different diagnostics. Interesting because both GCC and clang accept "constexpr const int *v1 = &array[3];" though.
[Bug c++/104066] "constinit extern long (*const f) ();" doesn't compile: gcc thinks "constinit" applies to return value, not to function pointer itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5 Known to fail||10.4.0, 11.3.0, 12.2.0 Known to work||10.4.1, 11.3.1, 12.2.1, ||13.0
[Bug c++/107741] New: Missed member variable name in mangling of externally visible lambdas used in inline initialization of static members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741
Bug ID: 107741
Summary: Missed member variable name in mangling of externally
visible lambdas used in inline initialization of
static members
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
Target Milestone: ---
https://godbolt.org/z/7514cTh5o
```
struct A {
static constexpr auto x = [] {
return 1;
};
};
template
struct B {
static constexpr auto x = [] {
return 1;
};
};
template
struct C {
static int x;
};
void side_effect();
template
int C::x = (side_effect(), [] { return 1; }());
template int C::x;
void f() {
A::x();
B::x();
}
```
GCC produces these manglings:
```
A::{lambda()#1}::operator()() const
_ZNK1AUlvE_clEv
B::{lambda()#3}::operator()() const
_ZNK1BIiEUlvE1_clEv
C::x::{lambda()#1}::operator()() const
_ZNK1CIiE1xMUlvE_clEv
```
I believe in the first two cases, the member variable scope ("::x") is missing.
Oh, and it looks like the lambda numbering is off - B's lambda is 1 within its
scope (either the type or the member) - so I guess that needs to be fixed
too/scoping the numbering to within the member along with the mangling having
that scoping.
[Bug c++/107741] Missed member variable name in mangling of externally visible lambdas used in inline initialization of static members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741 --- Comment #1 from David Blaikie --- Oh, some context - discovered while investigating a related clang bug: https://github.com/llvm/llvm-project/issues/58819 - so don't check clang for an example of what's right here, it has different bugs, though I've sent a fix for that for review.
