This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/13634] [3.3 regression] ICE in emit_move_insn_1
- From: "rosbacke at nada dot kth dot se" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 10 Jan 2004 19:00:45 -0000
- Subject: [Bug target/13634] [3.3 regression] ICE in emit_move_insn_1
- References: <20040109180730.13634.rosbacke@nada.kth.se>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From rosbacke at nada dot kth dot se 2004-01-10 19:00 -------
Good to see that the ICE got removed by the patch. But I'm afraid this might
lead us to cover the bug rather than fixing. I don't know much off gcc internals
but I can give you some notes from my work to create the second test case.
It seemed to be rather sensitive to acually perfoming floating point divisions.
For example replacing '1./3.' with '0.33' would remove the ICE. changing '* p /
3' to '* p * 3' would remove the ICE. Also replacing 'pow( 1./ 3. )' with
'pow(1/3)' would remove the ICE.
Also it seemed important that 'while(i<6) ++i;' occured between 'p = ...' and
the return statement. Placing 'while(i<6) ++i;' above the assignment to p would
also remove the ICE.
>From these totally unscientific observations I would guess that we would have a
problem somewhere in the code that handles division of floating point numbers
with -ffast-math.
Maybe worth having a look at?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13634