https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117920
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|aoliva at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Summary|ICE: in |Duplication of
|maybe_record_trace_start, |-mstackrealign sequence
|at dwarf2cfi.cc:2591 with |breaks CFI
|-O2 |
|-fharden-conditional-branch |
|es -mstackrealign |
|--param=max-grow-copy-bb-in |
|sns=32 |
Status|ASSIGNED |NEW
--- Comment #2 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Not mine, actually. Conditional branch hardening seems to be accidental in
hitting a -mstackrealign bug.
The problem is that the stack is only realigned before a call, after some
conditionals, and because of the large param, the realigning insns end up
duplicated. The CFI logic doesn't like that: in the first visited copy that
sequence, r13 is pushed, and then we detect stack realignment and set
fde->stack_realign. When we hit the second copy, when we see the r13 push, we
already have fde->stack_realign set. Down the control flow, at the confluence
from both copies, we detect that the different paths have different information
about r13.
I'm not sure whether to prevent the duplication somehow, or make FDE detection
smarter so as to support it, and I'm afraid I don't have much of a clue on how
to go about either, so I'm leaving it to someone more familiar with it.
Hopefully my diagnosis will be of use.
