https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81733
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|x86_64-apple-darwin11.4.2 |x86_64-apple-darwin11.4.2,
| |x86_64-apple-darwin10.8
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-09-26
CC| |dominiq at lps dot ens.fr
Ever confirmed|0 |1
--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
This might be a DUP of 82092 - or, at least, the remaining errors on D10 are
I don't believe it's in any way related to 57438 - even tho that also
manifested as a 0-length FDE.
===
AFAICS, this is caused by the system tools (at least at that generation / D10
generation) getting confused about where local labels belong in relation to
atom boundaries.
so something like
... switch to cold section
COLDB0:
... switch to hot section
....
....
... switch to cold section
__some_label:
...
...
COLDE0:
xxxxxxx
associates the COLDB0 with the atom *before* the one starting with
"__some_label:"
but the FDE computation is expecting to see it as the same address as
"__some_label:"
if one manually changes it to
... switch to cold section
__some_label:
COLDB0:
then it all works.
I suppose newer tools are catering for this better (and also dealing [better?]
with coincident addresses since the modern linker supports aliases).
.. needs some more investigation as to why it's not failing with newer
toolchains (make sure that's not just something being hidden by the switch to
allow aliasing).
=====
I have/had some patches to improve the output of labels for hot/cold switching
(reduced the number of section switches and output the start labels lazily) ..
but they don't rebase to trunk, so need some work.
