[Bug target/108185] [RISC-V]RVV assemble not set vsetvli correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #2 from Kito Cheng --- It seems right to me? ``` $ riscv64-unknown-elf-gcc pr108185.c -march=rv64gcv -mabi=lp64d -O3 -S -o - .file "pr108185.c" .option nopic .attribute arch, "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0_v1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0" .attribute unaligned_access, 0 .attribute stack_align, 16 .text .align 1 .globl foo5_3 .type foo5_3, @function foo5_3: csrrt0,vlenb sllit1,t0,1 csrra5,vlenb sub sp,sp,t1 sllia3,a5,1 add a3,a3,sp vl1re8.vv25,0(a0) # Load value from *(vint8m1_t*)in sub a5,a3,a5 vs1r.v v25,0(a1) # Store value to *(vint8m1_t*)out vs1r.v v25,0(a5) # Store value to stack, although it's unused. addia4,a1,800 csrrt0,vlenb sllit1,t0,1 vsetvli a5,zero,e8,m1,ta,ma # Right vsetvli for vsm.v vsm.v v25,0(a4) add sp,sp,t1 jr ra .size foo5_3, .-foo5_3 .ident "GCC: (g44b22ab81cf) 13.0.0 20221229 (experimental)" ```
[Bug analyzer/108251] New: false positive: null dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251 Bug ID: 108251 Summary: false positive: null dereference Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: chipitsine at gmail dot com Target Milestone: --- repro steps: git clone https://github.com/haproxy/haproxy cd haproxy export CC=/home/ilia/gcc/gcc-home/bin/gcc make TARGET=linux-glibc USE_OPENSSL=1 DEBUG_CFLAGS="-fanalyzer" this finding is wrong ``` src/ssl_sample.c:502:34: warning: dereference of NULL '0' [CWE-476] [-Wanalyzer-null-dereference] 502 | smp->data.u.sint = ((conn->flags & CO_FL_EARLY_DATA) && | ^~~ 'smp_fetch_ssl_fc_has_early': events 1-3 | | 491 | if (!ssl) | |^ | || | |(1) following 'false' branch (when 'ssl' is non-NULL)... |.. | 494 | smp->flags = 0; | | ~~ | || | |(2) ...to here |.. | 502 | smp->data.u.sint = ((conn->flags & CO_FL_EARLY_DATA) && | | ~~~ | | | | | (3) dereference of NULL '' | ``` if conn is null, we'll return here (two lines above): ``` ssl = ssl_sock_get_ssl_object(conn); if (!ssl) return 0; ``` detailed review: https://github.com/haproxy/haproxy/issues/1745#issuecomment-1367200781
[Bug analyzer/108252] New: false positive: leak detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108252
Bug ID: 108252
Summary: false positive: leak detection
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: chipitsine at gmail dot com
Target Milestone: ---
repro steps
git clone https://github.com/haproxy/haproxy
cd haproxy
export CC=/home/ilia/gcc/gcc-home/bin/gcc
make TARGET=linux-glibc USE_OPENSSL=1 DEBUG_CFLAGS="-fanalyzer"
detection
```
src/cfgparse-ssl.c: In function ‘ssl_parse_global_ciphers’:
src/cfgparse-ssl.c:264:17: warning: leak of ‘strdup(args[1])’ [CWE-401]
[-Wanalyzer-malloc-leak]
264 | *target = strdup(args[1]);
| ^
‘ssl_parse_global_ciphers’: events 1-6
|
| 255 | if (too_many_args(1, args, err, NULL))
| |^
| ||
| |(1) following ‘false’ branch...
|..
| 258 | if (*(args[1]) == 0) {
| |~ ~
| || |
| || (2) ...to here
| |(3) following ‘false’ branch...
|..
| 263 | free(*target);
| | ~
| | |
| | (4) ...to here
| 264 | *target = strdup(args[1]);
| | ~
| | | |
| | | (5) allocated here
| | (6) ‘strdup(args[1])’ leaks here; was allocated at
(5)
|
```
is wrong
detailed review:
https://github.com/haproxy/haproxy/issues/1745#issuecomment-1367207339
[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235
John David Anglin changed:
What|Removed |Added
CC||jwakely.gcc at gmail dot com
--- Comment #1 from John David Anglin ---
bash-5.1$ find . -name '*.o'|xargs /opt/gnu64/bin/nm -AC|grep atomic
./src/c++98/pool_allocator.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/mt_allocator.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/ios_failure.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/ios_init.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/locale_init.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/locale.o: U __gnu_cxx::__atomic_add(int volatile*,
int)
./src/c++98/localename.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/stdexcept.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++98/messages_members_cow.o: U
__gnu_cxx::__atomic_add(int volatile*, int)
./src/c++11/cow-stdexcept.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/ios-inst.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/cow-locale_init.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/cow-shim_facets.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/cxx11-shim_facets.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/cow-string-inst.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++11/cow-wstring-inst.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++17/fs_dir.o: U __gnu_cxx::__atomic_add(int volatile*,
int)
./src/c++17/fs_ops.o: U __gnu_cxx::__atomic_add(int volatile*,
int)
./src/c++17/cow-fs_dir.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++17/cow-fs_ops.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++17/cow-fs_path.o: U __gnu_cxx::__atomic_add(int
volatile*, int)
./src/c++20/tzdb.o: U __gnu_cxx::__atomic_add(int volatile*,
int)
./src/c++20/tzdb.o: t void
std::__atomic_notify_address(int const*, bool) [clone .isra.0]
./src/c++20/tzdb.o: W void std::__atomic_wait_address_v::wait(int, std::memory_order) const::{lambda()#1}>(int
const*, int, std::__atomic_base::wait(int, std::memory_order)
const::{lambda()#1})
./src/c++20/tzdb.o: U __atomic_compare_exchange_4
./src/c++20/tzdb.o: U __atomic_compare_exchange_8
./src/c++20/tzdb.o: U __atomic_exchange_8
./src/c++20/tzdb.o: U __atomic_fetch_add_4
./src/c++20/tzdb.o: U __atomic_fetch_add_8
./src/c++20/tzdb.o: U __atomic_fetch_sub_8
[...]
I believe the direct use of the above atomic symbols was introduced in the
following change:
commit 9fc61d45fa15fdd3b084d30998ecda164af33e95
Author: Jonathan Wakely
Date: Thu Dec 22 00:37:54 2022 +
libstdc++: Implement C++20 time zone support in
I have the following patch to work around PR 108228:
diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 2a4e213d3d9..92752242096 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -64,8 +64,8 @@ namespace __gnu_cxx
#else
[[gnu::weak]] const char* zoneinfo_dir_override();
-#ifdef __APPLE__
- // Need a weak definition for Mach-O.
+#if defined(__APPLE__) || defined(__hpux__)
+ // Need a weak definition for Mach-O and HP-UX.
[[gnu::weak]] const char* zoneinfo_dir_override()
{ return _GLIBCXX_ZONEINFO_DIR; }
#endif
[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235 --- Comment #2 from John David Anglin --- Looks like ./libstdc++-v3/config/cpu/hppa/atomicity.h needs updating to provide undefined routines.
[Bug ipa/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250 --- Comment #7 from Arsen Arsenović --- Created attachment 54165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54165&action=edit hang-testing script With the attached script, I singled out utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenDAGPatterns.cpp.o. For context, bisect-maybe-broken-2022-12-28-hangs is a build directory that contains files built with the "bad" gcc version (in this instance, GCC: (Gentoo 12.2.1, commit a3fbfc1027e9edcd14bb290b5702504d80d9e8fe) 12.2.1 20221227), which causes tblgen to run for longer than one minute and then get timed out (whereas it normally exits within five seconds). I also find it quite odd that -fdump-ipa-all didn't cause the build to reproduce before the revert. I can definitely see a bunch of IPA-pass dump files in the build directory
[Bug ipa/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250 --- Comment #8 from Arsen Arsenović --- Created attachment 54166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54166&action=edit xz'd preprocessed CodeGenDagPatterns.cpp Cmdline: [220/231] /usr/bin/g++-12 -DGTEST_HAS_RTTI=0 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/root/llvm-project/bisect-maybe-broken/utils/TableGen -I/root/llvm-project/llvm/utils/TableGen -I/root/llvm-project/bisect-maybe-broken/include -I/root/llvm-project/llvm/include -O2 -mcpu=powerpc -mtune=powerpc -pipe -ggdb -D_GLIBCXX_ASSERTIONS=1 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -O2 -g -DNDEBUG -fno-exceptions -fno-rtti -std=c++17 -save-temps=cwd -MD -MT utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenDAGPatterns.cpp.o -MF utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenDAGPatterns.cpp.o.d -o utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenDAGPatterns.cpp.o -c /root/llvm-project/llvm/utils/TableGen/CodeGenDAGPatterns.cpp This is preprocessed by the version with a revert, so the produced assembly does work, but I have doubts that this matters (copying in the compile from the bad case and linking against these files still acts like the bad case).
[Bug tree-optimization/108253] New: [13 Regression] ICE in set_nonzero_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108253
Bug ID: 108253
Summary: [13 Regression] ICE in set_nonzero_bits
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
Created attachment 54167
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54167&action=edit
Testcase
I'm assuming this is a regression as I suspect the abseil-cpp package was
around and built during the f36/f37 gcc-12 cycle.
g++ -O2
./absl/strings/CMakeFiles/absl_cord_ring_reader_test.dir/cord_ring_reader_test.cc.ii
during GIMPLE pass: dom
/builddir/build/BUILD/abseil-cpp-20220623.1/absl/strings/cord_ring_reader_test.cc:
In member function 'virtual void
absl::lts_20220623::cord_internal::{anonymous}::CordRingReaderTest_DefaultInstance_Test::TestBody()':
/builddir/build/BUILD/abseil-cpp-20220623.1/absl/strings/cord_ring_reader_test.cc:58:1:
internal compiler error: in set_nonzero_bits, at tree-ssanames.cc:464
58 | TEST(CordRingReaderTest, DefaultInstance) {
| ^~~
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source.
See for instructions.
I haven't reduced or debugged this at all. It could well land on me as it's
failing in DOM. It could also well land on Aldy/Andrew since I suspect it's
touching ranger from inside DOM.
[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108253 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Keywords||ice-on-valid-code
[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108253 --- Comment #1 from Andrew Pinski --- Reducing ...
[Bug preprocessor/108244] [13 Regression] `pragma GCC diagnostic` and -E -fdirectives-only causes the preprocessor to become confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108244 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #6 from Lewis Hyatt --- I am taking a look.
[Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235 --- Comment #3 from John David Anglin --- Created attachment 54168 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54168&action=edit Preprocessed source for tzdb.cc See atomic routines needed by tzdb.
[Bug preprocessor/108244] [13 Regression] `pragma GCC diagnostic` and -E -fdirectives-only causes the preprocessor to become confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108244
--- Comment #7 from Lewis Hyatt ---
The testcases mentioned so far in this PR (the original report, and the
reduction in Comment 5) started failing in r13-1544, because that revision
added #pragma GCC diagnostic to the set of pragmas that are registered in
preprocess-only mode, including in -fdirectives-only. But the same issue has
existed always it seems for other pragmas similarly registered; for instance
this testcase fails since gcc 9 and before:
=
$ cat t2.cpp
#pragma message "hello"
#ifdef t
#endif
$ gcc-9 -E -fdirectives-only t2.cpp > /dev/null
t2.cpp:1:9: warning: extra tokens at end of #ifdef directive
1 | #pragma message "hello"
| ^
=
I think with -fdirectives-only, #pragma is not meant to be registered or
processed.
The below patch fixes all testcases mentioned so far:
===
diff --git a/gcc/c-family/c-pragma.cc b/gcc/c-family/c-pragma.cc
index 142a46441ac..e9bcd1869d0 100644
--- a/gcc/c-family/c-pragma.cc
+++ b/gcc/c-family/c-pragma.cc
@@ -1647,7 +1647,8 @@ c_register_pragma_1 (const char *space, const char *name,
if (flag_preprocess_only)
{
- if (!(allow_expansion || ihandler.early_handler.handler_1arg))
+ if (cpp_get_options (parse_in)->directives_only
+ || !(allow_expansion || ihandler.early_handler.handler_1arg))
return;
pragma_pp_data pp_data;
However it doesn't fix an analogous one using "#pragma omp" even though it
suppresses the registration of the pragma there too. I will track that down and
follow up with a complete patch.
[Bug middle-end/101671] bogus -Warray-bounds on an unreachable switch case with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101671 --- Comment #4 from Andrew Pinski --- Hmm, the xfail was removed with r12-4526-gd8edfadfc7a979 . Was this fixed then?
[Bug tree-optimization/101923] std::function's move ctor is slower than the copy one for empty source objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101923 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0
[Bug middle-end/100793] ICE: in expand_assignment, at expr.c:5363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100793
Roger Sayle changed:
What|Removed |Added
Last reconfirmed||2022-12-29
Ever confirmed|0 |1
Keywords|error-recovery, |ice-on-valid-code
|ice-on-invalid-code |
Status|UNCONFIRMED |NEW
CC||roger at nextmovesoftware dot
com
--- Comment #1 from Roger Sayle ---
A slight variation on the original, reveals that this issue is slightly more
serious than it first appears.
void f4() {
int a;
register int __attribute__((vector_size(16))) b __asm("xmm1");
b[a] = a;
asm("" : "+v"(b));
}
ICEs without issuing any error/warning at -O2 (so not an error recovery issue),
but also compiles fine if "-mavx2" is specified (so is valid for some
architectures). This is related to PR middle-end/80162, indeed the test case
testsuite/c-c++-common/pr80162-2.c ICEs if compiled without -mavx2.
Variable index addressing of a vector register can be implemented, without
hardware support, by spilling the register to memory, but the problematic
assert insist that this ARRAY_REF is indexed by a CONST_INT.
[Bug testsuite/108152] gcc.dg/pr71558.c fails for LLP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108152
nightstrike changed:
What|Removed |Added
CC||10walls at gmail dot com
--- Comment #3 from nightstrike ---
(In reply to Andrew Pinski from comment #1)
> { dg-options "" }
So just to be pedantic (pun intended!), the options currently in use are:
-fdiagnostics-plain-output -ansi -pedantic-errors
If we use dg-options "", both -ansi and -pedantic-errors are removed.
-fdiagnostics-plain-output stays. Is this ok?
[Bug c/97398] Enhancement request: Warning when multiply assigning to same struct field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97398 Eric Gallager changed: What|Removed |Added Blocks||89180, 87403 --- Comment #4 from Eric Gallager --- (In reply to Ulrich Windl from comment #3) > (In reply to Eric Gallager from comment #2) > > would this go under one of the existing -Wunused flags, or a new one? > > I think it's a case of being an unused value set to a variable in general, > but more specifically it's setting a value more than once before possibly > being used (which is the case in my code). SO IMHO the question is whether > setting a variable more than once without being read in between is a special > case of setting a variable value without using it. Hm... guess I'll put this under both the "Wunused" and "new-warning" meta-bugs, and then let whoever implements it decide where it fits better... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 [Bug 89180] [meta-bug] bogus/missing -Wunused warnings
[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595 --- Comment #6 from CVS Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:cdc6bf44eec295805ae29a8aaddafd111de01c8e commit r13-4934-gcdc6bf44eec295805ae29a8aaddafd111de01c8e Author: Steve Kargl Date: Mon Dec 26 14:07:04 2022 -0800 Modify checks to avoid referencing NULL pointer. Update test cases with error messages that changed as a result. gcc/fortran/ChangeLog: PR fortran/102595 * decl.cc (attr_decl1): Guard against NULL pointer. * parse.cc (match_deferred_characteristics): Include BT_CLASS in check for derived being undefined. gcc/testsuite/ChangeLog: PR fortran/102595 * gfortran.dg/class_result_4.f90: Update error message check. * gfortran.dg/pr85779_3.f90: Update error message check.
[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108253 --- Comment #2 from Andrew Pinski --- Created attachment 54169 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54169&action=edit Reduced testcase This is as reduced testcase as I can get it. I tried to get back from some non-undefined behavior too. Note I also tried to inline a few things manually but that causes the failure to go away too.
[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108253 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-30 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- I suspect it is trying to set the nonzero bits for: _19 = &_15->data_; >From the assert: if (reinterpret_cast(ring_->data_) % 4 != 0) __builtin_abort(); But I could be wrong ...
[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108253
--- Comment #4 from Andrew Pinski ---
Full backtrace:
during GIMPLE pass: dom
t.cc: In function ‘void TestBody()’:
t.cc:46:1: internal compiler error: in set_nonzero_bits, at
tree-ssanames.cc:464
46 | TestBody() {
| ^~~~
0x8f0a06 set_nonzero_bits(tree_node*,
generic_wide_int > const&)
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssanames.cc:464
0x14c8f23 maybe_set_nonzero_bits(edge_def*, tree_node*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vrp.cc:2456
0x1330c3b
dom_opt_dom_walker::set_global_ranges_from_unreachable_edges(basic_block_def*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-dom.cc:1383
0x1332586 dom_opt_dom_walker::before_dom_children(basic_block_def*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-dom.cc:1652
0x1f80d1e dom_walker::walk(basic_block_def*)
/home/apinski/src/upstream-gcc-git/gcc/gcc/domwalk.cc:311
0x1333251 execute
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-dom.cc:939
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
