https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65810
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2015-04-20
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #4 from Alan Modra <amodra at gmail dot com> ---
Here's the bad code
0x00000fffb7f6c438 <write_float+3736>: addis r9,r2,-2
0x00000fffb7f6c43c <write_float+3740>: li r27,0
0x00000fffb7f6c440 <write_float+3744>: lfd f24,32760(r9)
0x00000fffb7f6c444 <write_float+3748>: lfd f25,-32768(r9)
It's from write_float.def:888
r *= 10;
so is supposed to be loading up 10.0L but instead gets a completely bogus low
double as seen in "d" below.
__gcc_qmul (a=1, b=0, c=10, d=-7.3968712249802237e+209)
So not something odd in libgfortran..
Hmm
p/x $r2
$31 = 0xfffb7fa1bd8
So, gcc emits toc sections with alignment of 8 bytes, which the linker
respects, leading to a toc pointer (r2) that can only be assumed to be 8 byte
aligned. This completely breaks rs6000.c:offsettable_ok_by_alignment.
My bug. Short term fix will be to limit offsettable_ok_by_alignment to 8 byte
alignment. Longer term, modify the linker to increase r2 alignment.
