https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #80 from Oleg Endo <olegendo at gcc dot gnu.org> --- (In reply to Alexander Klepikov from comment #79) > > I mean that if a user run GCC with -O1 and we don't do SH specific loop move > invariants pass at -O1, a user could look at binary (or at .S file) and find > that not all invariants are moved out of the loops, because library > addresses are hoisted after split1 pass. That would confuse a user even if > RTL dump is generated, and he can decide that it's a bug into loop2 pass. I > suggest to generate sh_loop dumps if RTL dump is requested and place there a > message that sh_loop hoisting is not done due to optimization level setting. I don't think users would get surprised or anything by lack of certain optimization. There is no official set of guaranteed optimizations performed at a particular -O level. It's OK to output a message into the RTL dump of course. But everything else seems a bit overthinking the issue. Actually the hoisting might not be always done. E.g. when register pressure in a loop is high, it might be better to not hoist the function address and keep it inside of the loop to reduce register pressure. But I'm not sure the loop optimization passes are smart enough to do that (yet). > > I checked several cases and they are because ld cannot link little endian > binary. When I run failed command taken from log file, it always fails for > linking little endian binary. But sometimes logs say that executing of > little endian binary is successful. I'm at a loss - how is that even > possible? Ugh, sounds weird. Sometimes a particular binutils version is also no good. Have you tried using an older binutils? Maybe it's more stable?
