[Bug target/106545] New: peephole.md seems like it should not exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106545 Bug ID: 106545 Summary: peephole.md seems like it should not exist Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv There is one peephole2 in there for: Simplify (unsigned long)(unsigned int)a << const But that should really be handled in generic code in simplify-rtx/combine already. If it is not, then it should be added.
[Bug target/106544] New: riscv_print_operand does not check to see if the operands are valid to do INTVAL on them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106544 Bug ID: 106544 Summary: riscv_print_operand does not check to see if the operands are valid to do INTVAL on them Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-checking, ice-on-invalid-code, inline-asm Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv riscv_print_operand currently does not check to see if CONST_INT_P is true on the operand before calling INTVAL on it. This can cause an ICE with RTL checking and inline-asm with these used. See aarch64_print_operand in config/aarch64/aarch64.cc for an examples on how to fix this.
[Bug target/106543] New: *sge_ uses operand 2 but there is no operand 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106543 Bug ID: 106543 Summary: *sge_ uses operand 2 but there is no operand 2 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv This is definitely broken: (define_insn "*sge_" [(set (match_operand:GPR 0 "register_operand" "=r") (any_ge:GPR (match_operand:X 1 "register_operand" " r") (const_int 1)))] "" "slt%i2\t%0,zero,%1" [(set_attr "type" "slt") (set_attr "mode" "")]) %i2 is not valid here as there is no operand[2] .
[Bug c++/106542] -O2 sign-extended uint32 to uint64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106542 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- The code is undefined as the subtraction is done in the int type. You either need to use -fwrapv or cast to an unsigned type before doing the subtraction.
[Bug c++/106542] -O2 sign-extended uint32 to uint64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106542 wuz73 at hotmail dot com changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #2 from wuz73 at hotmail dot com --- (In reply to Andrew Pinski from comment #1) > The code is undefined and can be detected with -fsanitize=undefined: > > /app/example.cpp:15:14: runtime error: signed integer overflow: 2086724600 - > -1610499096 cannot be represented in type 'int' I'm only interested in the lower 32 bits, hence the unsigned(d).
[Bug c++/106542] -O2 sign-extended uint32 to uint64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106542 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- The code is undefined and can be detected with -fsanitize=undefined: /app/example.cpp:15:14: runtime error: signed integer overflow: 2086724600 - -1610499096 cannot be represented in type 'int'
[Bug tree-optimization/99536] unexplained warning on "uninitialized value" in std::normal_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536 wuz73 at hotmail dot com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from wuz73 at hotmail dot com --- Great. I think this can be closed now.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 99536, which changed state. Bug 99536 Summary: unexplained warning on "uninitialized value" in std::normal_distribution https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99536 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/106542] New: -O2 sign-extended uint32 to uint64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106542
Bug ID: 106542
Summary: -O2 sign-extended uint32 to uint64
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wuz73 at hotmail dot com
Target Milestone: ---
#include
unsigned Msb(uint64_t x) { return 63 - __builtin_clzl(x); }
template
void f(T r, T p)
{
if (p > r)
{
auto d = p - r;
unsigned k = Msb(sizeof(T) == 4 ? unsigned(d) : d);
std::cout << sizeof(T) << " k=" << k << "\n";
}
}
int main()
{
int data[] = {-1610499096,2086724600};
f(data[0],data[1]);
}
When compiled with "g++ -O2" the output is "4 k=63". Apparently before calling
Msb(), g++ sign-extended unsigned(d). static_cast(d) yields the same
result. However, "g++ -O0" is correct (k=31), so are earlier versions of g++
such as 4.8.5 and 5.3.1.
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Blocks||44209 --- Comment #3 from Eric Gallager --- This is an example of bug 44209 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 [Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options
[Bug analyzer/105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887 Bug 105887 depends on bug 105947, which changed state. Bug 105947 Summary: RFE: -fanalyzer should complain about jumps through NULL function pointers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105947 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/105947] RFE: -fanalyzer should complain about jumps through NULL function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105947 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Should be implemented for GCC 13 by the above patch.
[Bug analyzer/105947] RFE: -fanalyzer should complain about jumps through NULL function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105947 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:e1a9168153d2bf12695844a9ca9f9fc1de8d1ddf commit r13-1979-ge1a9168153d2bf12695844a9ca9f9fc1de8d1ddf Author: David Malcolm Date: Fri Aug 5 19:45:41 2022 -0400 New warning: -Wanalyzer-jump-through-null [PR105947] This patch adds a new warning to -fanalyzer for jumps through NULL function pointers. gcc/analyzer/ChangeLog: PR analyzer/105947 * analyzer.opt (Wanalyzer-jump-through-null): New option. * engine.cc (class jump_through_null): New. (exploded_graph::process_node): Complain about jumps through NULL function pointers. gcc/ChangeLog: PR analyzer/105947 * doc/invoke.texi: Add -Wanalyzer-jump-through-null. gcc/testsuite/ChangeLog: PR analyzer/105947 * gcc.dg/analyzer/function-ptr-5.c: New test. Signed-off-by: David Malcolm
[Bug c++/106541] New: Missing -Wuninitialized on self initialization if external code is called earlier in the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106541
Bug ID: 106541
Summary: Missing -Wuninitialized on self initialization if
external code is called earlier in the function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
struct my_class {
int data[4];
};
void fn1();
void fn2()
{
my_class local = local;
}
void fn3()
{
fn1();
my_class local = local;
}
Compile with g++ -Wall.
Expected: Two warnings. Or maybe zero, if this is not considered a use.
Actual: Former complains, latter does not. That extra function call should not
affect the warning count.
https://godbolt.org/z/vhdnq1Ec1
[Bug tree-optimization/106513] [10/11/12/13 Regression] bswap pass misses that >>56 for signed types can be replicate the sign bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106513
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail||4.5.3, 4.6.4
Summary|bswap is incorrectly|[10/11/12/13 Regression]
|generated |bswap pass misses that >>56
||for signed types can be
||replicate the sign bit
Known to work||4.4.7
Target Milestone|--- |10.5
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-08-05
--- Comment #3 from Andrew Pinski ---
Confirmed.
Better testcase (without the questionable undefined behavior):
typedef long long int int64_t;
__attribute__((noinline)) int64_t
swap64 (int64_t n)
{
return (((n & (((int64_t) 0xff) )) << 56) |
((n & (((int64_t) 0xff) << 8)) << 40) |
((n & (((int64_t) 0xff) << 16)) << 24) |
((n & (((int64_t) 0xff) << 24)) << 8) |
((n & (((int64_t) 0xff) << 32)) >> 8) |
((n & (((int64_t) 0xff) << 40)) >> 24) |
((n & (((int64_t) 0xff) << 48)) >> 40) |
((n & ((int64_t)(0xffull << 56))) >> 56));
}
int main (void)
{
volatile int64_t n = 0x8000l;
if (swap64(n) != 0xff80l)
__builtin_abort ();
return 0;
}
[Bug c++/106520] 2+ index expressions in build_op_subscript are incorrectly interpreted as comma expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106520 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2022-08-05 --- Comment #1 from Andrew Pinski --- clang diagnostic is better: :15:4: error: no viable overloaded operator[] for type 'A' a[b, 2]; ~^ :4:8: note: candidate function not viable: no known conversion from 'B' to 'unsigned int' for 1st argument void operator[](unsigned, unsigned); ^ :3:8: note: candidate function not viable: requires 1 argument, but 2 were provided void operator[](unsigned); ^ Though it does not do the warning except for C++20.
[Bug lto/106540] New: [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6076
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106540
Bug ID: 106540
Summary: [13 Regression] lto -g ICE in
dwarf2out_register_external_die at dwarf2out.cc:6076
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
CC: marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
It's a very similar form of https://gcc.gnu.org/PR106334 where nix-2.10.3
package enabled -flto recently and started ICEing gcc.
This time I got the following 3-file reproducer:
// $ cat eval.hh
struct Value {
auto listItems() {
struct ListIterable {
typedef int *iterator;
iterator _begin, _end;
iterator begin() { return _begin; }
iterator end() { return _end; }
};
return ListIterable{};
}
};
// $ cat eval-cache.cc
#include "eval.hh"
void AttrCursorgetListOfStrings(Value & v) {
for (auto elem : v.listItems())
;
}
// $ cat eval.cc
#include "eval.hh"
template auto enumerate(T) {
struct iterator {
int iter;
bool operator!=(iterator) { return iter; }
void operator++() {}
auto operator*() { return 0; }
};
struct iterable_wrapper {
auto begin() { return iterator{}; }
auto end() { return iterator{}; }
};
return iterable_wrapper{};
}
void coerceToString(Value & v) {
for (auto elem : enumerate(v.listItems()))
;
}
Crashing:
$ g++ -O0 -flto -flto-partition=none -g1 -fPIC -I. -Wall -o eval.o -c eval.cc
eval.cc: In function 'void coerceToString(Value&)':
eval.cc:16:13: warning: unused variable 'elem' [-Wunused-variable]
16 | for (auto elem : enumerate(v.listItems()))
| ^~~~
$ g++ -O0 -flto -flto-partition=none -g1 -fPIC -I. -Wall -o eval-cache.o -c
eval-cache.cc
eval-cache.cc: In function 'void AttrCursorgetListOfStrings(Value&)':
eval-cache.cc:4:13: warning: unused variable 'elem' [-Wunused-variable]
4 | for (auto elem : v.listItems())
| ^~~~
$ g++ -O0 -flto -flto-partition=none -g1 -fPIC -I. -Wall -o libbug.so -shared
eval-cache.o eval.o
lto1: internal compiler error: in dwarf2out_register_external_die, at
dwarf2out.cc:6076
0xa093ff dwarf2out_register_external_die
../../gcc-13-20220731/gcc/dwarf2out.cc:6076
0x90743d lto_read_decls
../../gcc-13-20220731/gcc/lto/lto-common.cc:1952
0x908193 lto_file_finalize
../../gcc-13-20220731/gcc/lto/lto-common.cc:2271
0x908193 lto_create_files_from_ids
../../gcc-13-20220731/gcc/lto/lto-common.cc:2281
0x908193 lto_file_read
../../gcc-13-20220731/gcc/lto/lto-common.cc:2336
0x908193 read_cgraph_and_symbols(unsigned int, char const**)
../../gcc-13-20220731/gcc/lto/lto-common.cc:2784
0x8f0132 lto_main()
../../gcc-13-20220731/gcc/lto/lto.cc:626
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug analyzer/106539] New: -fanalyzer doesn't consider that realloc could shrink the buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106539
Bug ID: 106539
Summary: -fanalyzer doesn't consider that realloc could shrink
the buffer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
realloc's success_with_move::update_model uses the new size of the buffer when
copying the contents of the old buffer, rather the minimum of the old and new
sizes - I hadn't thought of the "shrinks the buffer" case.
Consider:
#include
void *test (void)
{
void **p = (void **)malloc (sizeof (void *) * 2);
if (!p)
return NULL;
p[0] = malloc(10);
p[1] = malloc(20); /* will be leaked if p is shrunk (e.g. during a move) */
void *q = realloc (p, sizeof (void *));
if (!q)
return p;
return q;
}
-fanalyzer probably ought to complain about a leak of p[1] after p is shrunk,
but doesn't at the moment.
[Bug libstdc++/65230] pretty-print inconsistent output for similar objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230 --- Comment #9 from Ulrich Drepper --- Created attachment 53419 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53419&action=edit diff -y of current and proposed output To compare the results more easily.
[Bug libstdc++/65230] pretty-print inconsistent output for similar objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230 Ulrich Drepper changed: What|Removed |Added Attachment #53410|0 |1 is obsolete|| --- Comment #8 from Ulrich Drepper --- Created attachment 53418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53418&action=edit Update pretty printers for all? containers I spent some more time on this and should now have covered all the containers. The changes for the other containers are in line with what the previous patch produced. The output should now be as consistent as possible across all containers. Along the line some bugs have been fixed, too. To illustrate the change I'll also attach to this bug a diff -y output of the current and the proposed code.
[Bug c++/66290] wrong location for -Wunused-macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290 --- Comment #8 from Lewis Hyatt --- (In reply to Lewis Hyatt from comment #7) > The wrong location is fixed for GCC 13. Shall I leave the PR open for now, > since there was also the issue of getting a caret pointing to the name of > macro, rather than just a diagnostic for the whole line? I can look into > that too. Patch to improve the range information on the diagnostic submitted for review here: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599397.html I think if that gets applied then we could close this one.
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 --- Comment #2 from Jose E. Marchesi --- (In reply to Andrew Pinski from comment #1) > > This option is used in the kernel source tree for some BPF programs. > > Why not fix the sources? Seems not hard to add a cast or two. That's what I would recommend. But since LLVM supports that switch it becomes difficult to convince people to not use it in case they are already using it. Sent a proposal patch in: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599393.html
[Bug c++/106538] New: Reject-valid: Substitution failure causes error with unsatisfied constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106538 Bug ID: 106538 Summary: Reject-valid: Substitution failure causes error with unsatisfied constraint Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dv at vollmann dot ch Target Milestone: --- Created attachment 53417 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53417&action=edit Example program that produces the error If in the attached program ADD_CONSTRAINED_OVERLOAD is defined, the tag_invoke for connect_t is instantiated. This instantiation fails for a number of reasons so GCC should continue with the next overload. However in this case GCC rejects the code claiming the contrained is not satisfied (which is correct, but shouldn't cause a reject).
[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic --- Comment #1 from Andrew Pinski --- > This option is used in the kernel source tree for some BPF programs. Why not fix the sources? Seems not hard to add a cast or two.
[Bug c/106535] GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535 --- Comment #3 from Gabriel Ravier --- Considering the comment appears to be from 1993 (see commit d9fc6069c69564ce7fecd9ca0ce1bbe0b3c130ef), it having become wrong since then doesn't seem particularly surprising :p
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Tamar Christina --- Fixed now.
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #10 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:1878ab3650d8c646a4db364df388adaec2a29870 commit r13-1975-g1878ab3650d8c646a4db364df388adaec2a29870 Author: Tamar Christina Date: Fri Aug 5 14:53:28 2022 +0100 middle-end: Guard value_replacement and store_elim from seeing diamonds. This excludes value_replacement and store_elim from diamonds as they don't handle the form properly. gcc/ChangeLog: PR middle-end/106534 * tree-ssa-phiopt.cc (tree_ssa_phiopt_worker): Guard the value_replacement and store_elim from diamonds.
[Bug tree-optimization/106322] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322 --- Comment #15 from Mathieu Malaterre --- (In reply to Mathieu Malaterre from comment #11) > (In reply to Uroš Bizjak from comment #10) > > The reason the test fails with gcc-12 is that gcc-12 enabled > > auto-vectorisation for -O2. > > I can make the symptoms go away by doing: `-O2 -fno-tree-vectorize`. Since > this affects also arm5 and powerpc, it seems the bug is somewhere in the > shared 32bits code (bug does not affects 64bits arch for some reason). The above is incorrect, since the symptoms are also going away on mips64el and ppc64.
[Bug c/106537] New: GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537
Bug ID: 106537
Summary: GCC doesn't support
-W[no-]compare-distinct-pointer-types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jose.marchesi at oracle dot com
Target Milestone: ---
GCC emits pedwarns unconditionally when comparing pointers of different types,
for example:
int xdp_context (struct xdp_md *xdp)
{
void *data = (void *)(long)xdp->data;
__u32 *metadata = (void *)(long)xdp->data_meta;
__u32 ret;
if (metadata + 1 > data)
return 0;
return 1;
}
/home/jemarch/foo.c: In function ‘xdp_context’:
/home/jemarch/foo.c:15:20: warning: comparison of distinct pointer types
lacks a cast
15 | if (metadata + 1 > data)
|^
LLVM supports an option -W[no-]compare-distinct-pointer-types that can be used
in order to enable or disable the emission of such warnings. It is enabled by
default.
This option is used in the kernel source tree for some BPF programs.
I already got a patch for this.
[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514 --- Comment #4 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:47964e766270f349f5b171bcd68ff7c1e60d85d8 commit r13-1973-g47964e766270f349f5b171bcd68ff7c1e60d85d8 Author: Aldy Hernandez Date: Fri Aug 5 08:04:10 2022 +0200 Inline unsupported_range constructor. An unsupported_range temporary is instantiated in every Value_Range for completeness sake and should be mostly a NOP. However, it's showing up in the callgrind stats, because it's not inline. This fixes the oversight. PR tree-optimization/106514 gcc/ChangeLog: * value-range.cc (unsupported_range::unsupported_range): Move... * value-range.h (unsupported_range::unsupported_range): ...here. (unsupported_range::set_undefined): New.
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #9 from Tamar Christina --- (In reply to Tamar Christina from comment #6) > (In reply to rguent...@suse.de from comment #5) > > On Fri, 5 Aug 2022, burnus at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 > > > > > > --- Comment #4 from Tobias Burnus --- > > > Seems as if the ICE is fixed for that file by reverting the following > > > commit: > > > > > > commit r13-1963-gc832ec4c3ec4853ad89ff3b0dbf6e9454e75e8cc > > > middle-end: Fix phi-ssa assertion triggers. [PR106519] > > > > As hinted in the e-mail exchange the earlier two transforms might need > > guarding with !diamond_p since IIRC only minmax is capable of dealing > > with it? > > Yes, Though I didn't find any failing cases so I didn't guard store elim. > value_replacement is a weird one as it looks like it's already looking for > some kind of diamond form. I can guard both to be safe, but that's > essentially doing a blind change if I can't reproduce this locally. This does seem to fix it, so bootstrapping now and will put up a patch once done.
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Last reconfirmed||2022-08-05 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #8 from Tamar Christina --- (In reply to Tobias Burnus from comment #7) > (In reply to Tamar Christina from comment #3) > > Thanks for the repro, could you tell me what target I need to use or what > > configure options to build amdgcn-amdhsa? > > See > https://gcc.gnu.org/wiki/Offloading#How_to_build_an_offloading-enabled_GCC > for some guidance. (But that's more for building a full compiler and more > than you need.) > > I think you just need to know: --target=amdgcn-amdhsa Thanks! Able to reproduce it now!
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #7 from Tobias Burnus --- (In reply to Tamar Christina from comment #3) > Thanks for the repro, could you tell me what target I need to use or what > configure options to build amdgcn-amdhsa? See https://gcc.gnu.org/wiki/Offloading#How_to_build_an_offloading-enabled_GCC for some guidance. (But that's more for building a full compiler and more than you need.) I think you just need to know: --target=amdgcn-amdhsa
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #6 from Tamar Christina --- (In reply to rguent...@suse.de from comment #5) > On Fri, 5 Aug 2022, burnus at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 > > > > --- Comment #4 from Tobias Burnus --- > > Seems as if the ICE is fixed for that file by reverting the following > > commit: > > > > commit r13-1963-gc832ec4c3ec4853ad89ff3b0dbf6e9454e75e8cc > > middle-end: Fix phi-ssa assertion triggers. [PR106519] > > As hinted in the e-mail exchange the earlier two transforms might need > guarding with !diamond_p since IIRC only minmax is capable of dealing > with it? Yes, Though I didn't find any failing cases so I didn't guard store elim. value_replacement is a weird one as it looks like it's already looking for some kind of diamond form. I can guard both to be safe, but that's essentially doing a blind change if I can't reproduce this locally.
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #5 from rguenther at suse dot de --- On Fri, 5 Aug 2022, burnus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 > > --- Comment #4 from Tobias Burnus --- > Seems as if the ICE is fixed for that file by reverting the following commit: > > commit r13-1963-gc832ec4c3ec4853ad89ff3b0dbf6e9454e75e8cc > middle-end: Fix phi-ssa assertion triggers. [PR106519] As hinted in the e-mail exchange the earlier two transforms might need guarding with !diamond_p since IIRC only minmax is capable of dealing with it?
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #4 from Tobias Burnus --- Seems as if the ICE is fixed for that file by reverting the following commit: commit r13-1963-gc832ec4c3ec4853ad89ff3b0dbf6e9454e75e8cc middle-end: Fix phi-ssa assertion triggers. [PR106519]
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #3 from Tamar Christina --- Thanks for the repro, could you tell me what target I need to use or what configure options to build amdgcn-amdhsa?
[Bug middle-end/105762] [12/13 Regression] -Warray-bounds false positives for integer-to-pointer casts since r12-2132-ga110855667782dac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105762
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #4 from Ivan Sorokin ---
Perhaps the warning message could be improved? The warning is saying about
arrays but there are no arrays in the original code.
I think it would be great if the warning said something about
{invalid/wild/cast from int} pointer. English is not my strong suit, perhaps
something like this:
warning: dereferencing wild pointer '(int*)1ul' is undefined
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 --- Comment #2 from Tobias Burnus --- Created attachment 53416 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53416&action=edit Reduced testcase - fails with cc1 -O2 inp.i Reduced inputfile attached. Full code has the full ICE output: src/gcc-mainline/libgfortran/io/unit.c: In function 'get_gfc_unit': gcc-mainline/libgfortran/io/unit.c:326:1: error: definition in block 18 does not dominate use in block 19 326 | get_gfc_unit (int n, int do_create) | ^~~~ for SSA_NAME: p_47 in statement: p_30 = PHI PHI argument p_47 for PHI node p_30 = PHI during GIMPLE pass: phiopt gcc-mainline/libgfortran/io/unit.c:326:1: internal compiler error: verify_ssa failed 0x11699ff verify_ssa(bool, bool) gcc-mainline/gcc/tree-ssa.cc:1211 0xe4e6dd execute_function_todo gcc-mainline/gcc/passes.cc:2098 0xe4eb7b execute_todo gcc-mainline/gcc/passes.cc:2145
[Bug target/106536] New: P9: gcc does not detect setb pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106536
Bug ID: 106536
Summary: P9: gcc does not detect setb pattern
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
int compare2(unsigned long long a, unsigned long long b)
{
return (a > b ? 1 : (a < b ? -1 : 0));
}
Output:
_Z8compare2yy:
cmpld 0,3,4
bgt 0,.L5
mfcr 3,128
rlwinm 3,3,1,1
neg 3,3
blr
.L5:
li 3,1
blr
.long 0
.byte 0,9,0,0,0,0,0,0
clang generates:
_Z8compare2yy: # @_Z8compare2yy
cmpld 3, 4
setb 3, 0
extsw 3, 3
blr
.long 0
.quad 0
[Bug c/106535] GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2022-08-05
--- Comment #2 from Jonathan Wakely ---
Looks like this comment is not correct:
/* Compound expressions can only occur here if -Wpedantic or
-pedantic-errors is specified. In the later case, we always want
an error. In the former case, we simply want a warning. */
if (require_constant && pedantic
&& TREE_CODE (inside_init) == COMPOUND_EXPR)
{
inside_init
= valid_compound_expr_initializer (inside_init,
TREE_TYPE (inside_init));
if (inside_init == error_mark_node)
error_init (init_loc, "initializer element is not constant");
else
pedwarn_init (init_loc, OPT_Wpedantic,
"initializer element is not constant");
if (flag_pedantic_errors)
inside_init = error_mark_node;
}
else if (require_constant
&& !initializer_constant_valid_p (inside_init,
TREE_TYPE (inside_init)))
{
error_init (init_loc, "initializer element is not constant");
inside_init = error_mark_node;
}
else if (require_constant && !maybe_const)
pedwarn_init (init_loc, OPT_Wpedantic,
"initializer element is not a constant expression");
Without -pedantic the first condition is false, so it takes the second branch
which uses error_init. With -pedantic the first branch is taken, and it uses
pedwarn_init which is only a warning unless you use -pedantic-errors.
[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed for GCC 13.
[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:36bc2a8f24f9c8f6eb2c579d520d7fc73a113ae1 commit r13-1972-g36bc2a8f24f9c8f6eb2c579d520d7fc73a113ae1 Author: Richard Biener Date: Fri Aug 5 10:40:18 2022 +0200 tree-optimization/106533 - loop distribution of inner loop of nest Loop distribution currently gives up if the outer loop of a loop nest it analyzes contains a stmt with side-effects instead of continuing to analyze the innermost loop. The following fixes that by continuing anyway. PR tree-optimization/106533 * tree-loop-distribution.cc (loop_distribution::execute): Continue analyzing the inner loops when find_seed_stmts_for_distribution fails. * gcc.dg/tree-ssa/ldist-39.c: New testcase.
[Bug c/106535] GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535 Gabriel Ravier changed: What|Removed |Added Keywords||accepts-invalid, ||rejects-valid --- Comment #1 from Gabriel Ravier --- (PS: I'm not sure whether it's intended that it should be rejected under -pedantic or accepted without any options, so I've used both of the keywords)
[Bug c/106535] New: GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106535 Bug ID: 106535 Summary: GCC doesn't reject non-constant initializer if -pedantic is specified but does so in any other circumstances Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gabravier at gmail dot com Target Milestone: --- int f = (0, 0); Compiled without any options: :1:9: error: initializer element is not constant 1 | int f = (0, 0); | ^ Compiled with -pedantic: :1:9: warning: initializer element is not constant [-Wpedantic] 1 | int f = (0, 0); | ^ It seems rather odd that adding -pedantic transforms an error into a warning...
[Bug target/106529] existence of sincos is assumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106529 --- Comment #7 from Jonathan Wakely --- (In reply to Thomas Klausner from comment #4) > a) there is no conflict since there is no builtin or otherwise sincos() > function > b) it is not declared in math.h As it says, it's a built-in function automatically recognized by GCC, which is documented here: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html With -std=c17 instead of the -std=gnu17 default that doesn't happen. The warning is correct, GCC gives that special handling. You can use -fno-builtin-sincos to disable the handling for this particular function, but maybe that should be the default on NetBSD. > the linker warning is correct though :) Error, not warning :)
[Bug middle-end/106534] [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||tnfchris at gcc dot gnu.org Target Milestone|--- |13.0 --- Comment #1 from Richard Biener --- Can you please attach preprocessed source so it can be reproduced with a cc1 cross from x86_64?
[Bug middle-end/106534] New: [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106534 Bug ID: 106534 Summary: [13 Regression][gcn] ICE 'verify_ssa failed' / 'error: definition in block 18 does not dominate use in block 19' during libgfortran bootstrap Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: ams at gcc dot gnu.org Target Milestone: --- Target: amdgcn-amdhsa Build of amdgcn-amdhsa (as offloading compiler for/on x86_64-gnu-linux) fails to build as follows. It did bootstrap successfully a few days back (like Aug 2 or 3): src/gcc-mainline/libgfortran/io/unit.c: In function 'get_gfc_unit': src/gcc-mainline/libgfortran/io/unit.c:326:1: error: definition in block 18 does not dominate use in block 19 326 | get_gfc_unit (int n, int do_create) | ^~~~ for SSA_NAME: p_47 in statement: p_30 = PHI PHI argument p_47 for PHI node p_30 = PHI during GIMPLE pass: phiopt /scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/libgfortran/io/unit.c:326:1: internal compiler error: verify_ssa failed
[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Keywords||missed-optimization
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-08-05
--- Comment #4 from Richard Biener ---
The code should iterate and eventually distribute inner loops of perfect loop
nests. In fact for
void bar (int *a, int * __restrict b)
{
for (int k = 0; k < 10; k++)
for (int j = 0; j < 10; ++j)
a[j] = b[j];
}
I do see
> ./cc1 -quiet t.c -O2 -fopt-info
t.c:4:23: optimized: Loop 2 distributed: split to 0 loops and 1 library calls.
the issue is likely that
void bar (int *a, int * __restrict b)
{
for (int k = 0; k < 10; k++)
{
for (int j = 0; j < 10; ++j)
a[j] = b[j];
__builtin_printf ("Foo!");
}
}
causes distribution to fail early in find_seed_stmts_for_distribution and
that's taken as fatal error. I have a fix.
[Bug c++/104493] OpenMP offload map cannot handle const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104493 Tobias Burnus changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-08-05 Status|UNCONFIRMED |ASSIGNED --- Comment #5 from Tobias Burnus --- Submitted mainline patch, (still) pending review: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598918.html
[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533
--- Comment #3 from Vineet Gupta ---
FWIW this was seen with riscv64 build of gcc, but same tree behavior seen with
aarch64 gcc 12.1.
For single copy-loop src, final output is inline copy loop
-->8--
[local count: 1063004409]:
# j_131 = PHI
# ivtmp_135 = PHI
_10 = a[j_131];
c[j_131] = _10;
j_92 = j_131 + 1;
ivtmp_88 = ivtmp_135 - 1;
if (ivtmp_88 != 0)
goto ; [99.00%]
else
goto ; [1.00%]
.L74:
// ../stream-4-loop.c:315: c[j] = a[j];
ldr q0, [x27, x0] // MEM [(double *)&a +
ivtmp.224_247 * 1], MEM [(double *)&a + ivtmp.224_247 * 1]
str q0, [x19, x0] // MEM [(double *)&a +
ivtmp.224_247 * 1], MEM [(double *)&c + ivtmp.224_247 * 1]
add x0, x0, 16 // ivtmp.224, ivtmp.224,
cmp x0, x28 // ivtmp.224, tmp291
bne .L74
-->8--
While for multi-loop src we see
-->8--
MEM [(char * {ref-all})&c] = MEM [(char * {ref-all})&a];
bl memcpy
-->8--
[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533 --- Comment #2 from Vineet Gupta --- Original stream benchmark [1] at https://github.com/jeffhammond/STREAM
[Bug tree-optimization/106533] loop distribution not distributing inner loop (to memcpy) when perfect loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533 Vineet Gupta changed: What|Removed |Added CC||vineetg at rivosinc dot com --- Comment #1 from Vineet Gupta --- I'm not familiar with actual algorithm of loop distribution, but I debugged and found the point of divergence. loop_distribution::execute() loops thru loops_list (cfun, LI_ONLY_INNERMOST). The copy loop 7 (in both the builds) is processed but prepare_perfect_loop_nest() returns different values For single copy src loop, it deduces "perfect nesting" and returns outer loop 3. This essentially skips any further distribution of loop 7. For multi-loop src build, prepare_perfect_loop_nest() exits early as outer->inner == loop fails (outer loop 3 has inner pointing to scaling loop 10, the last loop inside it, not 7 which is first). This causes further logic to eventually distribute it to 0 loop and memcpy. I'm not sure if this is a bug or intended, hence this report.
[Bug tree-optimization/106533] New: loop distribution not distributing inner loop (to memcpy) when perfect loop nest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106533
Bug ID: 106533
Summary: loop distribution not distributing inner loop (to
memcpy) when perfect loop nest
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vineetg at rivosinc dot com
Target Milestone: ---
Created attachment 53415
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53415&action=edit
test case
When tinkering with a slightly modified version of stream benchmark [1]
observed that Loop distribution is not distributing a nested copy loop into "0
loop and 1 libcall (memcpy)".
This is with test built with -O2, mainline gcc, as of June 14, 2022: commit
6abe341558ab
Actual test is attached but the loops look like following. Loop 7 (copy) is
distributed to memcpy in general case - but not if benchmark built with #define
COPYONLY (which elides loops 8,9,10 from compilation).
-->8---
for (j=0; j<1000; j++) {// 1
a[j] = 1.0;
b[j] = 2.0;
c[j] = 0.0;
}
for (j = 0; j < 1000; j++) // 2
a[j] = 2.0E0 * a[j];
for (k=0; k<10; k++)// 3
{
for (j=0; j<1000; j++) c[j] = a[j]; // 7
#ifndef COPYONLY
for (j=0; j<1000; j++) b[j] = scalar*c[j]; // 8
for (j=0; j<1000; j++) c[j] = a[j]+b[j];// 9
for (j=0; j<1000; j++) a[j] = b[j]+scalar*c[j]; // 10
#endif
}
for (k=1; k<10; k++)
for (j=0; j<4; j++) // 6
avgtime[j] = avgtime[j] + times[j][k];
..
for (j=0; j<4; j++) // 5
avgtime[j] = avgtime[j]/(double)(NTIMES-1);
..
-->8---
