http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29969
Oleg Endo <olegendo at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olegendo at gcc dot gnu.org --- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-07-15 18:43:59 UTC --- (In reply to comment #3) > (In reply to comment #2) > > This could be a disaster if floating point exceptions are enabled, as it > > would > > trigger an exception whenever some part of the block was an invalid floating > > point number. > > One would at least need to save/restore the floating point exception flags > > around such a block copy. > > If that is an issue is target specific. First, if all floating point loads > detect loading invalid floating point numbers, and sencond, if floating point > exceptions are used for the target in practical terms. > E.G. for the SH4 (at least SH4-100 / SH4-200), you get always a floating > point exception if the exception is enabled and it could happen for any > input data, so it is not very popular to enable it. Jörn, I know it's been a while since you worked on the SH port... According to SH4, SH4A and SH2A manuals these are the following exceptions that could be triggered by FMOV instructions: SH4 / SH4A: - Data TLB miss exception - Data protection violation exception - Initial page write exception - Data address error SH2A: - Address error ... plus the 'FPU disabled exception'. As far as I understand the manuals, FPU exceptions are only raised for FPU arithmetic, not for loads/stores. If this is true, using 64 bit fmov for block moves could be beneficial. Still, I'd not enable this by default but allow the user to turn it on with an -m option.