[Bug fortran/80440] New: Slow compile when USEing modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80440
Bug ID: 80440
Summary: Slow compile when USEing modules
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: abensonca at gmail dot com
Target Milestone: ---
Compile times for code that makes extensive USEs of modules seems to be very
slow in some cases. I've been doing some investigation of the cause of this
with the hope that I can maybe figure out some way to speed things up.
For example, I have a smallish file - 700 lines of code, which takes around 3
minutes to compile with a recent build of gfortran. Profiling f951 with
valgrind I find that 63% of that time is spent in find_symtree_for_symbol(),
which (if I understand correctly) is searching for a node in the symtree that
already references some symbol being imported from a module.
find_symtree_for_symbol() gets called directly 245,658 times in compiling this
source file (and calls itself recursively almost 19 billion times!).
find_symtree_for_symbol() is just stepping through a binary branching tree
looking for a reference to a given symbol, but (again, if I understood
correctly), it can't use the usual bbt search approach because the tree is not
ordered by the symbol name, so the search is O(n) rather than O(log n).
If I ignore my ignorance of why the ordered tree isn't used here and go ahead
and search it using the symbol name (ignoring case which seems to differ
between the symbol name and the name of the symtree node) then I certainly get
a substantial speed-up (the file I mentioned now compiles in 40s), and nothing
seems to break. I ran the gfortan test suite which shows two FAILs:
gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/graphite/pr68279.f90 -
O (internal compiler error)
gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/graphite/pr68279.f90 -
O (test for excess errors)
but those show up when I run the test suite without any change to module.c
anyway.
The patch I used is:
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 6d3860e..f28a7b7 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -4286,22 +4286,25 @@ mio_symbol (gfc_symbol *sym)
static gfc_symtree *
find_symtree_for_symbol (gfc_symtree *st, gfc_symbol *sym)
{
- gfc_symtree *s = NULL;
-
- if (st == NULL)
-return s;
-
- s = find_symtree_for_symbol (st->right, sym);
- if (s != NULL)
-return s;
- s = find_symtree_for_symbol (st->left, sym);
- if (s != NULL)
-return s;
+ int c;
+
+ while (st != NULL)
+{
+ c = strcasecmp(sym->name, st->name);
+ if ( c == 0 )
+ {
+ if ( !check_unique_name (st->name))
+ {
+ return st;
+ } else {
+ return NULL;
+ }
+ }
- if (st->n.sym == sym && !check_unique_name (st->name))
-return st;
+ st = (c < 0) ? st->left : st->right;
+}
- return s;
+ return NULL;
}
[Bug c++/80439] New: __attribute__((target("xxx"))) not applied to lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80439
Bug ID: 80439
Summary: __attribute__((target("xxx"))) not applied to lambdas
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Testcase (see also https://godbolt.org/g/H2xjNc for GCC and Clang build):
#include
#include
__attribute__((target("sse4.2")))
unsigned aeshash(const uint8_t *p, size_t len, unsigned seed)
{
const auto l = [](unsigned data) {
__m128i m = _mm_insert_epi32(_mm_setzero_si128(), data, 1);
return _mm_extract_epi32(m, 1);
};
return l(seed);
}
In the testcase above, if the source is compiled with base options for x86
(either 32- or 64-bit mode), GCC fails to compile with error:
/usr/lib/gcc/x86_64-linux-gnu/6.3.0/include/smmintrin.h:447:1: error: inlining
failed in call to always_inline 'int _mm_extract_epi32(__m128i, int)': target
specific option mismatch
_mm_extract_epi32 (__m128i __X, const int __N)
^
:9:38: note: called from here
return _mm_extract_epi32(m, 1);
^
Clang compiles the above just fine.
The compilation works if I add __attribute__((target("sse4.2"))) to the lambda.
[Bug fortran/80121] Memory leak with derived-type intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80121
--- Comment #4 from janus at gcc dot gnu.org ---
Producing a dump via -fdump-tree-original shows what's going on in the case of
comment #3, namely: 'e' is being deallocated before being passed to 's1':
if ((struct t1[0:] * restrict) e.data != 0B)
{
__builtin_free ((void *) e.data);
(struct t1[0:] * restrict) e.data = 0B;
}
s1 ();
That is correct so far. However, what is missing is the deallocation of e's
components. Those are only auto-deallocated at the end of the subroutine
'leak'.
[Bug middle-end/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 --- Comment #15 from Martin Sebor --- I've raised bug 80437 for the suggested change to the notation of the warning(s).
[Bug other/80437] large decimal numbers in diagnostics are hard to read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80437 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
[Bug other/80437] New: large decimal numbers in diagnostics are hard to read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80437
Bug ID: 80437
Summary: large decimal numbers in diagnostics are hard to read
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Consider the warning printed for the test case in bug 79929, comment #4:
#include
#include
char * foo(char *c, int len)
{
char *p, *n;
n = malloc(len + 5);
p = c + 5;
memmove (c, n, p-c);
if (p < c)
memset (n + 5, 32, c-p);
return n;
}
$ gcc -Wall -O -c bug.c
bug.c: In function 'foo':
bug.c:11:5: warning: 'memset': specified size 18446744073709551611 exceeds
maximum object size 9223372036854775807 [-Wstringop-overflow=]
memset (n + 5, 32, c-p);
As is evident from the discussion in that bug (and some others), it's hard to
see what the large values correspond to in the source code or how they are
computed. The same problem exists in all diagnostics that print large values,
including (but not limited to) -Walloca-larger-than, -Walloc-size-larger-than,
-Wlarger-than, and -Wformat-overflow, and in any such warnings yet to be added.
One suggestion that's come is to use a hexadecimal notation for such values
(see bug 79929, comment 12). That would result in printing the following
instead:
bug.c:11:5: warning: 'memset': specified size 0xfffb exceeds
maximum object size 0x [-Wstringop-overflow=]
I'm not sure that this a significant improvement. Those already familiar with
the -Wstringop-overflow warning will likely understand what 0x
in this context means but only because we know the maximum object size limit
(i.e., PTRDIFF_MAX) and realize that all printed values are in the [PTRDIFF_MAX
+ 1, SIZE_MAX] range and thus always consist of 16 hex digits. Someone who's
seen the warning for the first time will either have to guess or count the f's.
This is even more likely for the specified size (such as 0xfffb).
In cases where a much lower limit is specified by the user (e.g., via
-Walloca-larger-than) it's even less clear how to interpret a number in any
base.
I think it's possible to do better. One approach is to print very large values
in terms of well-known constants such as SIZE_MAX or PTRDIFF_MAX. For
instance, instead of printing 18446744073709551611 (i.e., -5) print SIZE_MAX -
4. Another solution might be to print sizes as signed (though that won't help
in the case of the user-specified limit).
Since the problem of how best to present large decimal numbers is general and
applies to all diagnostics, including warnings, errors, and notes, a change to
how these numbers are presented should be brought up for a wider discussion
before it's implemented consistently, for all diagnostics.
[Bug fortran/80121] Memory leak with derived-type intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80121 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||janus at gcc dot gnu.org Summary|Memory leak when allocating |Memory leak with |a component derived type in |derived-type intent(out) |a recursive subroutine |argument |(gfortran) | --- Comment #3 from janus at gcc dot gnu.org --- Here is a reduced/modified test case (without recursion): PROGRAM p IMPLICIT NONE TYPE t1 INTEGER, ALLOCATABLE :: i(:) END TYPE call leak CONTAINS SUBROUTINE s1(e) TYPE(t1), ALLOCATABLE, INTENT(OUT) :: e(:) ALLOCATE( e(1) ) ALLOCATE( e(1)%i(2) ) END SUBROUTINE SUBROUTINE leak TYPE(t1), ALLOCATABLE :: e(:) CALL s1(e) CALL s1(e) END SUBROUTINE END PROGRAM
[Bug fortran/79685] [5/6/7 Regression] ICE on valid code in gfc_match_structur_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79685 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Known to fail||4.7.4, 5.4.1, 6.3.0 --- Comment #3 from janus at gcc dot gnu.org --- Slightly reduced test case: module omega_color implicit none type omega_color_factor integer :: i end type end module module foo use omega_color, OCF => omega_color_factor implicit none type(OCF) :: table_color_factors data table_color_factors / OCF(1) / end module
[Bug middle-end/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 --- Comment #14 from Markus Trippelsdorf --- (In reply to Martin Sebor from comment #13) > That said, it's possible that the warning could be made clearer if it used > some other notation instead of printing very large positive decimal numbers. > I'm not sure that printing hex numbers instead is the right solution though. > The following doesn't seem much clearer to me: > > Warning: ‘__builtin_memset’: specified size 0xfffb exceeds > maximum object size 7fff [-Wstringop-overflow=] It is not my intention to derail the discussion, but hex numbers are much clearer. One immediately sees that 0x7FFF is ULLONG_MAX/2.
[Bug middle-end/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 --- Comment #13 from Martin Sebor --- > Apparently the problem comes from the fact that len(yerrmsg) is not known at > compile time, but I don't understand why the warning use nonsensical numbers. The numbers that are printed are the values or their ranges that GCC computes for the arguments and what GCC uses as the maximum: 9223372036854775807 (or PTRDIFF_MAX) in LP64. Memset takes a size_t argument so negative values passed to it are printed as very large positive numbers. In both instances of the warning for the Fortran test case, 4294967291 (in ILP32) and 18446744073709551611 (LP64) is the same as -5. On x86_64 where the warning triggers with -O2, the excessive memset is introduced during constant propagation (-fdump-tree-ccp1=/dev/stdout). The .ccp1 dump shows this: _32 = _yerrmsg_19(D) + 5; ... _10 = (unsigned long) _32; _11 = (unsigned long) _yerrmsg_19(D); if (_10 < _11) <<< can never be true goto ; [0.00%] else goto ; [0.00%] [0.00%]: _12 = (unsigned long) _yerrmsg_19(D); _13 = (unsigned long) _32; _15 = (sizetype) _32; _16 = yerrmsg_25(D) + _15; __builtin_memset (_16, 32, 18446744073709551611); The result of yerrmsg + 5 (_10) can never be less than the yerrmsg pointer itself (_11) so the test (_10 < _11) above can never succeed. The test shows up in the first dump so, as Jeff already noted in comment #2, it's introduced by the Fortran front end. I don't enough about Fortran to guess why the test is introduced but it should be clear that the problem is not that the warning is behaving incorrectly or printing nonsensical numbers but rather either that a test that cannot be true is inserted to begin with, or that it's not eliminated. That said, it's possible that the warning could be made clearer if it used some other notation instead of printing very large positive decimal numbers. I'm not sure that printing hex numbers instead is the right solution though. The following doesn't seem much clearer to me: Warning: ‘__builtin_memset’: specified size 0xfffb exceeds maximum object size 7fff [-Wstringop-overflow=] In any event, the particular notation used by the warning is orthogonal to this problem.
[Bug middle-end/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #12 from Markus Trippelsdorf --- (In reply to Dominique d'Humieres from comment #11) > On x86_64-apple-darwin16 I see the warning > > Warning: '__builtin_memset': specified size 18446744073709551611 exceeds > maximum object size 9223372036854775807 [-Wstringop-overflow=] > > for -Os and -O2 and above. I don't understand why this case is not detected > with the -Wcharacter-truncation flag: the length of "bug: " // yerrmsg is > the len(yerrmsg)+5, thus will be truncated when assigned to yerrmsg. > > Apparently the problem comes from the fact that len(yerrmsg) is not known at > compile time, but I don't understand why the warning use nonsensical numbers. I agree that these huge decimal numbers look ridiculous. At the very least they should be printed as hex numbers.
[Bug target/15492] floating-point arguments are loaded too early to x87 stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15492 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Uroš Bizjak --- Fixed.
[Bug rtl-optimization/55952] x86 FPU, unnecessary fxch instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55952 --- Comment #2 from Uroš Bizjak --- Latest trunk gcc generates: flds4(%esp) fldz fucomip %st(1), %st fstp%st(0) fld1 fchs fld1 fcmovnbe%st(1), %st fstp%st(1) ret
[Bug target/15492] floating-point arguments are loaded too early to x87 stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15492
--- Comment #13 from Uroš Bizjak ---
Recent gcc generates:
testcase from Comment #0:
double test (double a, double b)
{
return a*a + b*b;
}
fldl4(%esp)
fmul%st(0), %st
fldl12(%esp)
fmul%st(0), %st
faddp %st, %st(1)
ret
first testcase from Comment #3:
double test1 (double a, int x, double b, int y, double c)
{
return sin (c) + tan (b) * sqrt (a) + x * fabs (b) + y;
}
fldl28(%esp)
fsin
fldl16(%esp)
fptan
fstp%st(0)
fldl4(%esp)
fsqrt
fldl16(%esp)
fabs
fimull 12(%esp)
fiaddl 24(%esp)
faddp %st, %st(3)
fmulp %st, %st(1)
faddp %st, %st(1)
ret
second testcase from comment #3:
double test1 (double y, double x)
{
return atan2(x, y);
}
fldl12(%esp)
fldl4(%esp)
fpatan
ret
[Bug middle-end/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 --- Comment #11 from Dominique d'Humieres --- On x86_64-apple-darwin16 I see the warning Warning: '__builtin_memset': specified size 18446744073709551611 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] for -Os and -O2 and above. I don't understand why this case is not detected with the -Wcharacter-truncation flag: the length of "bug: " // yerrmsg is the len(yerrmsg)+5, thus will be truncated when assigned to yerrmsg. Apparently the problem comes from the fact that len(yerrmsg) is not known at compile time, but I don't understand why the warning use nonsensical numbers.
[Bug fortran/80361] [5/6/7 Regression] [OOP] bogus recursive call to nonrecursive procedure with -fcheck=recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[5/6/7 Regression] bogus|[5/6/7 Regression] [OOP] |recursive call to |bogus recursive call to |nonrecursive procedure with |nonrecursive procedure with |-fcheck=recursion |-fcheck=recursion --- Comment #22 from janus at gcc dot gnu.org --- Fixed on trunk with r246934. Backports pending ...
[Bug fortran/80392] [5/6/7 Regression] [OOP] ICE with allocatable polymorphic function result in a procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80392 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > Regtesting now ... Regtest completed successfully ...
[Bug fortran/80392] [5/6/7 Regression] [OOP] ICE with allocatable polymorphic function result in a procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80392
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #3 from janus at gcc dot gnu.org ---
We already have a check to prevent this kind of infinite recursion (as shown in
comment #1) in gfc_get_derived_type, however it is apparently only working for
TYPEs, but not for CLASSes. This patch should fix it (and makes comment #0 and
comment #2 compile fine with trunk):
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c (revision 246933)
+++ gcc/fortran/trans-types.c (working copy)
@@ -2617,9 +2617,10 @@ gfc_get_derived_type (gfc_symbol * derived, int co
the same as derived, by forcing the procedure pointer component to
be built as if the explicit interface does not exist. */
if (c->attr.proc_pointer
- && ((c->ts.type != BT_DERIVED && c->ts.type != BT_CLASS)
- || (c->ts.u.derived
- && !gfc_compare_derived_types (derived, c->ts.u.derived
+ && (c->ts.type != BT_DERIVED || (c->ts.u.derived
+ && !gfc_compare_derived_types (derived, c->ts.u.derived)))
+ && (c->ts.type != BT_CLASS || (CLASS_DATA (c)->ts.u.derived
+ && !gfc_compare_derived_types (derived, CLASS_DATA
(c)->ts.u.derived
field_type = gfc_get_ppc_type (c);
else if (c->attr.proc_pointer && derived->backend_decl)
{
Regtesting now ...
[Bug fortran/80291] [OOP] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:6662
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80291 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to snowfed from comment #7) > In the slightly reduced version of the test case cell is not allocated when > reaching associate structure. Maybe, allocate(cell) is worth being added. > For example, when I compile the example with ifort and run it I get SIGSEGV. True. The example was only intended as a minimal reproducer for the ICE, without doing anything reasonable at runtime ...
[Bug gcov-profile/80435] Expose __gcov_flush to allow developers to dump coverage numbers on demand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80435 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-15 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Thanks for report, I'll take a look.
[Bug debug/80436] [7 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80436 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-15 Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf --- (In reply to Markus Trippelsdorf from comment #1) > Started with r44392. r244392 even.
[Bug debug/80436] [7 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80436 --- Comment #1 from Markus Trippelsdorf --- Started with r44392.
[Bug debug/80436] New: [7 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80436
Bug ID: 80436
Summary: [7 Regression] -fcompare-debug failure
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
markus@x4 tmp % cat df-problems.ii
void fn1(...);
void fn2(int, int, int);
struct {
int elt1;
int bits;
} * a;
int b, d;
int fn3(unsigned *p1) {
if (0)
next_bit:
return 1;
while (1) {
if (b)
if (a->bits)
goto next_bit;
*p1 = b;
if (a->elt1)
return 0;
a = 0;
}
}
enum {} * c;
void fn4() {
int e, m(d);
for (; e < m; e++) {
if (e < 0)
fn2(0, 0, c[e]);
unsigned f;
for (; fn3();)
fn1(f);
}
}
markus@x4 tmp % g++ --save-temps -fcompare-debug -c -O3 df-problems.ii
g++: error: df-problems.ii: -fcompare-debug failure
markus@x4 tmp % diff -u df-problems.gkd df-problems.gk.gkd
--- df-problems.gkd 2017-04-15 08:35:08.338387771 +0200
+++ df-problems.gk.gkd 2017-04-15 08:35:08.388386688 +0200
@@ -236,7 +236,7 @@
(code_label # 0 0 4 36 (nil) [2 uses])
(note # 0 0 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn:TI # 0 0 4 (parallel [
-(set (reg:DI 1 dx [orig:118 a_lsm.16 ] [118])
+(set (reg:DI 1 dx [orig:117 a_lsm.16 ] [117])
(const_int 0 [0]))
(clobber (reg:CC 17 flags))
]) "df-problems.ii":16# {*movdi_xor}
@@ -246,7 +246,7 @@
(compare:CCZ (reg:SI 2 cx [orig:126 b.0_59 ] [126])
(const_int 0 [0])))# {*cmpsi_ccno_1}
(nil))
-(insn # 0 0 4 (set (reg/f:DI 0 ax [orig:113 a_lsm.15 ] [113])
+(insn # 0 0 4 (set (reg/f:DI 0 ax [orig:112 a_lsm.15 ] [112])
(mem/f/c:DI (symbol_ref:DI ("a") [flags 0x2] ) [ a+0 S8
A64]))# {*movdi_internal}
(nil))
(jump_insn:TI # 0 0 4 (set (pc)
@@ -265,12 +265,12 @@
(barrier # 0 0)
(code_label # 0 0 6 60 (nil) [1 uses])
(note # 0 0 [bb 6] NOTE_INSN_BASIC_BLOCK)
-(insn:TI # 0 0 6 (set (reg:QI 1 dx [orig:118 a_lsm.16 ] [118])
+(insn:TI # 0 0 6 (set (reg:QI 1 dx [orig:117 a_lsm.16 ] [117])
(const_int 1 [0x1])) "df-problems.ii":17# {*movqi_internal}
(expr_list:REG_EQUAL (const_int 1 [0x1])
(nil)))
(insn # 0 0 6 (parallel [
-(set (reg/f:DI 0 ax [orig:113 a_lsm.15 ] [113])
+(set (reg/f:DI 0 ax [orig:112 a_lsm.15 ] [112])
(const_int 0 [0]))
(clobber (reg:CC 17 flags))
]) "df-problems.ii":19# {*movdi_xor}
@@ -279,7 +279,7 @@
(code_label # 0 0 7 33 (nil) [1 uses])
(note # 0 0 [bb 7] NOTE_INSN_BASIC_BLOCK)
(insn:TI # 0 0 7 (set (reg:SI 37 r8)
-(mem:SI (reg/f:DI 0 ax [orig:113 a_lsm.15 ] [113]) [
a_lsm.15_80->elt1+0 S4 A32])) "df-problems.ii":17# {*movsi_internal}
+(mem:SI (reg/f:DI 0 ax [orig:112 a_lsm.15 ] [112]) [
a_lsm.15_80->elt1+0 S4 A32])) "df-problems.ii":17# {*movsi_internal}
(nil))
(insn:TI # 0 0 7 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 37 r8)
...
