On 13 April 2006 20:04, Martin Hicks wrote:
> On Thu, Apr 13, 2006 at 07:32:39PM +0100, Dave Korn wrote:
>> On 13 April 2006 13:37, Martin Hicks wrote:
>>
>>> 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
>>
rks,
you can then compare the old and new compilers to see how the do
things differently and what you need to backport to fix the problem.
It seems that there some problem in function in-lining.
What can I do and what should I do to solve this problem?
There is a process called debugging t
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
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 c
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.
I posted a c
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
