https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Bug ID: 66790
Summary: Invalid uninitialized register handling in REE
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: derodat at adacore dot com
Target Milestone: ---
The reproducer I'm about to attach[1] seems to trigger a code generation issue
at least on x86_64-linux:
$ gnatmake -q p -O3 -gnatn
$ ./p
raised PROGRAM_ERROR : p.adb:9 explicit raise
The bottom line is that when Success is False in Q.Get (q.adb, around line 40)
its value is clobbered during return. If we build with -fno-ree, we can see in
the assembly code (near the return point for q__get) the following sequence:
movzwl (%rax), %epb
...
somelabel:
...
movzwl %bp, %ebp
...
salq $16, %rax
orq %rbp, %rax
However, without the -fno-ree switch the instruction:
movzwl %bp, %ebp
is merged with its definition (the first movzwl instruction) by the REE pass.
This is wrong since the definition does _not_ dominate this zero-extension: the
first movzwl instruction can be by-passed through "somelabel".
I started to investigate this issue: the REE pass is currently not aware of
this by-pass code path because it is reached by no proper definition (it brings
an uninitialized %rbp register to the zero-extension). This happens in
ree.c:get_defs; in our case (insn=second movzwl, reg=BP) DF_REF_CHAIN contains
only one definition: the movzwl instruction.
Given the "somelabel" code path, I would rather expect DF_REF_CHAIN to hold a
NULL reference to materialize the lack of initialization in one path. I found
the DF_LR_IN/DF_LR_OUT macros from df.h: they provide information about
uninitialized variables but the associated comment says they should not be used
("This intolerance should eventually be fixed."). Besides, they provide a
basic-block-level information whereas we are rather interested in
instruction-level information in REE.
I was thinking that REE may not be the only optimization pass needing this kind
of information but I found no other one, so I'm not sure how this ought to be
handled. Can anybody confirm my intuition about the NULL reference in
DF_REF_CHAIN? I'm willing to implement it but I prefer first to be sure this is
the right approach.
Thanks in advance!
[1] It's in Ada. I tried to translate it into C but any change in register
allocation makes the issue disappear...
