lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cannot build lilypond 2.6.3 on powerpc


From: Thomas Bushnell BSG
Subject: Re: cannot build lilypond 2.6.3 on powerpc
Date: Sat, 15 Oct 2005 14:42:01 -0700
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> Thomas Bushnell BSG wrote:
>> Thomas Bushnell BSG <address@hidden> writes:
>>
>>>Ah, I have found the problem.  The Debian package builds gf2pbm with
>>>optimization on (-O2).  gf2pbm misbehaves when compiled with
>>>optimization, and works fine when compiled without.
>> More specifically, failure happens with:
>> -fschedule-insns -fstrict-aliasing -O
>> But not with: -O or either of those -f optimizations alone.
>
> there are some dodgy pointer casts in gf2pbm, specifically,
>
> gf2pbm.c: In functie $-1òøread_GF_charòù:
> gf2pbm.c:305: let op: initialization from incompatible pointer type
>
>       BMUNIT  *cp, *basep, *maxp;
>       char    **basep_cpp = &basep;
>
> GCC4 has become much more agressive with considering cast pointers as 
> unaliased by definition, so I would suspect this one.

Yep, I've narrowed it down to that one too (I didn't think the warning
at first should matter)!

If I change the declaration to "BMUNIT **basep_cpp", that of course
shuts up the warning.

And--it causes the failure to happen whether optimization is on or
not!

The problem is almost certainly the type punning of the basep_cpp
variable and the creepy pointer arithmetic being done with what it
points to.  When the declaration is fixed to shup up the warning, the
result is that the same thing happens as when the compiler assumed
there was no aliasing, and that's that the pointer arithmetic is
multiplied by the wrong things.

It would of course help if there were comments! :) :)

I'm attempting a fix now.

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]