On 13 April 2006 13:37, Martin Hicks wrote: > On Thu, Apr 13, 2006 at 01:34:10PM +0800, Ching-Hua Chang wrote: >> We had ported gcc-3.4.2 to our own RISC, and meet a strange >> case in optimization level 3 (-O3). >> >> The compiler produce wrong assembly code in O3 and >> correct result if we add -fno-inline flag. >> >> It seems that there some problem in function in-lining. >> What can I do and what should I do to solve this problem ? > > I ran into a similar problem with function inlining on a x86->powerpc405 > cross compiler with gcc-3.4.5. As you say, when you explicitly forbid > inlining it works fine.
There's really no reason to assume it's the same bug. Inlining a function has /vast/ knock-on effects and can expose all sorts of bugs in function calling, sibcalls, CSE, etc. etc. etc; disabling inlining seems to 'cure' the bug but you can't deduce that inlining itself is the problem, it's just that with inlining you get greater complexity in the generated code, greater pressure on register allocation, and so more scope for things that haven't been properly stress-tested to fail. > I posted a couple weeks ago to the list, but never got any responses. > http://gcc.gnu.org/ml/gcc/2006-04/msg00054.html > > mh I'm afraid that's probably because your question was terribly vague. "Does the wrong thing", with no explanation, demonstration, or testcase, is not exactly anything anyone can help you with, so the answer to your question "Does anyone have any ideas what this bug is?" is "No, nobody could possibly guess from that little information", and the answer to "Is there an open bug?" is "Why don't you look in bugzilla yourself?" cheers, DaveK -- Can't think of a witty .sigline today....
