asm inline

asm inline

[Samuel Rydh]

I just noticed that gcc 3.1 doesn't like the following:

static __inline__ void st_le32( ulong *addr, ulong val )
{
        __asm__ __volatile__( "stwbrx %1,0,%2"
				: "=m" (*addr)
				: "r" (val), "r" (addr) );
}

The compiler misses the fact that *addr is modified and will happily
turn the following

	st_le32( &b, 1UL << i );
	testing( b )

into something like

	addi	r31,r1,28
	...
	lwz	r3,28(r1)	; loading b
	stwbrx	r9,0,r31
	bl	testing

The real world example looked like this:

    int i,b;
    for( i=0; i<=30; i++ ) {
        st_le32( &b, 1UL<<i );
        printf("dbg:  %d %08lx b=%08lx\n", i, pic.reg[r_flag], b );
        if( pic.reg[r_flag] & b )
            break;
    }

Adding "memory" to the clobber list seems to be the only way to make
gcc do the right thing :-(.

/Samuel


Btw. I'm using gcc 3.1 cross compiled for x86.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Gabriel Paubert]

On Fri, 29 Nov 2002, Samuel Rydh wrote:

>
> I just noticed that gcc 3.1 doesn't like the following:
>
> static __inline__ void st_le32( ulong *addr, ulong val )
> {
>         __asm__ __volatile__( "stwbrx %1,0,%2"
> 				: "=m" (*addr)
> 				: "r" (val), "r" (addr) );
> }

How is "addr" declared ? This may be an aliasing problem. Does adding
-fno-strict-aliasing to the options help ? Or changing the "=m" to "+m" as
an incorrect, but less penalizing than a memory clobber, bandaid. Or
declaring addr as pointer to volatile ?

If nothing helps and it still happens with the recently released
gcc-3.2.1, submit a bug report to the GCC lists. I'd love to test it right
now but I'm upgrading all my systems to Debian Woody, not without trouble,
especially keyboard (spanish layout) and input layer related.

>
> The compiler misses the fact that *addr is modified and will happily
> turn the following
>
> 	st_le32( &b, 1UL << i );
> 	testing( b )
>
> into something like
>
> 	addi	r31,r1,28
> 	...
> 	lwz	r3,28(r1)	; loading b
> 	stwbrx	r9,0,r31
> 	bl	testing
>
> The real world example looked like this:
>
>     int i,b;
>     for( i=0; i<=30; i++ ) {
>         st_le32( &b, 1UL<<i );
>         printf("dbg:  %d %08lx b=%08lx\n", i, pic.reg[r_flag], b );
>         if( pic.reg[r_flag] & b )
>             break;
>     }
>
> Adding "memory" to the clobber list seems to be the only way to make
> gcc do the right thing :-(.

A "memory" clobber is such an optimization killer that it is not
acceptable in this situation (actually I consider a memory clober hardly
ever acceptable). I see that your example involves local variables, does
it also happen in the non-automatic case ?

	Regards,
	Gabriel


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Samuel Rydh]

On Fri, Nov 29, 2002 at 05:21:50PM +0100, Gabriel Paubert wrote:
> On Fri, 29 Nov 2002, Samuel Rydh wrote:
> How is "addr" declared ? This may be an aliasing problem. Does adding
> -fno-strict-aliasing to the options help ? Or changing the "=m" to "+m" as
> an incorrect, but less penalizing than a memory clobber, bandaid. Or
> declaring addr as pointer to volatile ?

Turning of aliasing did indeed solve the problem. As did changing
unsigned long to int.

> > Adding "memory" to the clobber list seems to be the only way to make
> > gcc do the right thing :-(.
>
> A "memory" clobber is such an optimization killer that it is not
> acceptable in this situation (actually I consider a memory clober hardly
> ever acceptable).

Agreed. A "memory" clobber is definitely suboptimal.

> I see that your example involves local variables, does
> it also happen in the non-automatic case ?

It happens in the non-automatic case too. I'll try the
latest gcc version later.

/Samuel


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Franz Sirl]

At 18:49 29.11.2002, Samuel Rydh wrote:
> > I see that your example involves local variables, does
> > it also happen in the non-automatic case ?
>
>It happens in the non-automatic case too. I'll try the
>latest gcc version later.

Can you please post a compilable code fragment that still shows the bug for
you? Or add -save-temps to the CFLAGS and send me the resulting
preprocessed .i file. I seem to remember a platform independent bug in 3.1
with memory constraints, but it maybe something totally different...

Ah, and don't forget to tell me all the CFLAGS necessary to trigger the bug.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Samuel Rydh]

On Mon, Dec 02, 2002 at 12:17:42PM +0100, Franz Sirl wrote:
>
> At 18:49 29.11.2002, Samuel Rydh wrote:
> >> I see that your example involves local variables, does
> >> it also happen in the non-automatic case ?
> >
> >It happens in the non-automatic case too. I'll try the
> >latest gcc version later.
>
> Can you please post a compilable code fragment that still shows the bug for
> you? Or add -save-temps to the CFLAGS and send me the resulting
> preprocessed .i file. I seem to remember a platform independent bug in 3.1
> with memory constraints, but it maybe something totally different...
>
> Ah, and don't forget to tell me all the CFLAGS necessary to trigger the bug.
>

Sure, here is a stand alone program that triggers the problem:

----------------------------------------------------------------

#include <stdio.h>
typedef unsigned long ulong;

static __inline__ void st_le32( ulong volatile *addr, ulong val )
{
        __asm__ ("stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)  );
}

int
main( int argc, char **argv )
{
        int b;
        st_le32( (ulong*)&b, 0 );
        testing( b );
        return 0;
}

int
testing( int x )
{
}

----------------------------------------------------------------

With CFLAGS='-O2', the assembly output becomes:

00000000 <main>:
   0:   94 21 ff f0     stwu    r1,-16(r1)
   4:   7c 08 02 a6     mflr    r0
   8:   80 61 00 08     lwz     r3,8(r1)
   c:   39 21 00 08     addi    r9,r1,8
  10:   90 01 00 14     stw     r0,20(r1)
  14:   38 00 00 00     li      r0,0
  18:   7c 00 4d 2c     stwbrx  r0,r0,r9
  1c:   4c c6 31 82     crclr   4*cr1+eq
  20:   48 00 00 01     bl      20 <main+0x20>
  24:   80 01 00 14     lwz     r0,20(r1)
  28:   38 60 00 00     li      r3,0
  2c:   38 21 00 10     addi    r1,r1,16
  30:   7c 08 03 a6     mtlr    r0
  34:   4e 80 00 20     blr

(unrelated: Does anyone understand why the compiler clears cr4.eq?)

The compiler does the right thing if -fno-strict-aliasing is used or
if 'int b' is replaced by 'ulong b'.

Adding volatile after asm also fixes things (but I did not see
this effect in the unsimplified example).

/Samuel


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Andreas Schwab]

Samuel Rydh <samuel@ibrium.se> writes:

|> Sure, here is a stand alone program that triggers the problem:
|>
|> ----------------------------------------------------------------
|>
|> #include <stdio.h>
|> typedef unsigned long ulong;
|>
|> static __inline__ void st_le32( ulong volatile *addr, ulong val )
|> {
|>         __asm__ ("stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr)  );
|> }
|>
|> int
|> main( int argc, char **argv )
|> {
|>         int b;
|>         st_le32( (ulong*)&b, 0 );
|>         testing( b );

This violates the aliasing rules.  The compiler is free to assume that
st_le32 does not modify b, because you are invoking undefined behaviour.

Andreas.

--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Kevin B. Hendricks]

Hi,

I thought strict-aliasing was only turned on at -O3?
It was that way in the past.  Did this change for gcc-3.2.X?

There seems to be an enormous amount of code that is not strict-aliasing
safe (in the JDK, in OpenOffice.org, etc).

Is there any warning flag that can be enabled to help find these cases (the
OOo source base is simply huge)?

My only choise now is to add -fno-strict-aliasing even with the -O2 flags
which I did not think I needed.

Kevin

On December 2, 2002 08:35, Andreas Schwab wrote:
> Samuel Rydh <samuel@ibrium.se> writes:
> |> Sure, here is a stand alone program that triggers the problem:
> |>
> |> ----------------------------------------------------------------
> |>
> |> #include <stdio.h>
> |> typedef unsigned long ulong;
> |>
> |> static __inline__ void st_le32( ulong volatile *addr, ulong val )
> |> {
> |>         __asm__ ("stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r"
> |> (addr)  ); }
> |>
> |> int
> |> main( int argc, char **argv )
> |> {
> |>         int b;
> |>         st_le32( (ulong*)&b, 0 );
> |>         testing( b );
>
> This violates the aliasing rules.  The compiler is free to assume that
> st_le32 does not modify b, because you are invoking undefined behaviour.
>
> Andreas.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Andreas Schwab]

"Kevin B. Hendricks" <kevin.hendricks@sympatico.ca> writes:

|> Hi,
|>
|> I thought strict-aliasing was only turned on at -O3?
|> It was that way in the past.  Did this change for gcc-3.2.X?

Yes, strict aliasing is now the default.

|> There seems to be an enormous amount of code that is not strict-aliasing
|> safe (in the JDK, in OpenOffice.org, etc).

Well, they have always walked on thin ice...

|> Is there any warning flag that can be enabled to help find these cases (the
|> OOo source base is simply huge)?

gcc 3.3 implements such a warning, but it may give many false positives.

Andreas.

--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Kevin B. Hendricks]

Hi,

> |> Is there any warning flag that can be enabled to help find these
> |> cases (the OOo source base is simply huge)?
>
> gcc 3.3 implements such a warning, but it may give many false positives.

Any chance we can get this flag backported so that it appears in gcc 3.2.2?

False positives are a whole lot better than code that quietly does the an
unexpected thing.

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Franz Sirl]

At 15:37 02.12.2002, Kevin B. Hendricks wrote:

>Hi,
>
> > |> Is there any warning flag that can be enabled to help find these
> > |> cases (the OOo source base is simply huge)?
> >
> > gcc 3.3 implements such a warning, but it may give many false positives.
>
>Any chance we can get this flag backported so that it appears in gcc 3.2.2?
>
>False positives are a whole lot better than code that quietly does the an
>unexpected thing.

Well, are you sure OO is really affected? strict-aliasing is the default
since gcc-2.96 which means that everything since redhat-7.0 would be
affected on x86 for example. Also GCC has been very late to make this the
default at all, I think that Sun and MS compilers do this for years
already. I would be very surprised if a multiplatform project like OO still
contained reasonable amounts of aliasing-unsafe code.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Kevin B. Hendricks]

Hi,

The Sun JDK 1.3.X source is not strict aliasing safe and that has been
built on a number of platforms and compilers for a long time (I found that
out the hard way a year or two back).

Also OOo used gcc-2.95.4 for a long time (it never supported or used gcc
2.96) and still uses gcc-3.0.4 at -O1 and -O2 for its official binaries
and I do not belive that turns on strict-aliasing at all.

They will stick with gcc-3.0.4 for x86 binaries since they must maintain
c++ compatibilitiy with proprietary binary only components for StarOffice.

Either way, I sent a query to the dev@openoffice.org list to see if anyone
can bring me up to date on any known strict-alising issues.

I have always used -fno-strict-aliasing for all the JDK and OOo binaries
since I was burned by it much earlier and could not find where exactly in
the code the optimization introduced a change.

So the only people who would have any empirical eveidence as to how strict
aliasing safe the OOo code would be are probably Redhat or Mandrake who
have incorporated OOo into their distributions with a later compiler (I
think Debian still uses gcc 2.95.X as their official compiler and I am not
sure what SuSE is using now but Olaf always used gcc 2.95.X for ppc 7.3)

The Apple gcc 3.1 compiler explicitly turns off  strict-aliasing according
to their man page.   So only if the Solaris Forte or the WIN compilers
catch it will those issues already have been fixed.

Kevin


On December 2, 2002 09:51, Franz Sirl wrote:
> At 15:37 02.12.2002, Kevin B. Hendricks wrote:
> >Hi,
> >
> > > |> Is there any warning flag that can be enabled to help find these
> > > |> cases (the OOo source base is simply huge)?
> > >
> > > gcc 3.3 implements such a warning, but it may give many false
> > > positives.
> >
> >Any chance we can get this flag backported so that it appears in gcc
> > 3.2.2?
> >
> >False positives are a whole lot better than code that quietly does the
> > an unexpected thing.
>
> Well, are you sure OO is really affected? strict-aliasing is the default
> since gcc-2.96 which means that everything since redhat-7.0 would be
> affected on x86 for example. Also GCC has been very late to make this
> the default at all, I think that Sun and MS compilers do this for years
> already. I would be very surprised if a multiplatform project like OO
> still contained reasonable amounts of aliasing-unsafe code.
>
> Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Kevin B. Hendricks]

Hi,

Here is what Sun's Hamburg developers wrote in reply...

> Hi Kevin,
>
> -fstrict-aliasing is in -O2 optimization since gcc-3.0.x. And no, our
> code is not strict alias safe. You'll get some problems, I know of at
> least one place in sc. I bet there are more.
>
> I recommend to use -O2 -fno-strict-aliasing. This is what Hamburg
> release engineering currently uses.
>
> If someone is able to identify all strict alias violating places I would
> be more than happy to propose that we change these (or add the
> -fno-strict-alias to just these files).
>
> Heiner

So it looks like Solaris and Win must not detect these issues already.
So a backport of the gcc 3.3 warning flag would certainly be a big help to
the OOo project as well.

Thanks,

Kevin



On December 2, 2002 09:51, Franz Sirl wrote:
> At 15:37 02.12.2002, Kevin B. Hendricks wrote:
> >Hi,
> >
> > > |> Is there any warning flag that can be enabled to help find these
> > > |> cases (the OOo source base is simply huge)?
> > >
> > > gcc 3.3 implements such a warning, but it may give many false
> > > positives.
> >
> >Any chance we can get this flag backported so that it appears in gcc
> > 3.2.2?
> >
> >False positives are a whole lot better than code that quietly does the
> > an unexpected thing.
>
> Well, are you sure OO is really affected? strict-aliasing is the default
> since gcc-2.96 which means that everything since redhat-7.0 would be
> affected on x86 for example. Also GCC has been very late to make this
> the default at all, I think that Sun and MS compilers do this for years
> already. I would be very surprised if a multiplatform project like OO
> still contained reasonable amounts of aliasing-unsafe code.
>
> Franz.
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Franz Sirl]

At 16:11 02.12.2002, Kevin B. Hendricks wrote:

>Hi,
>
>Here is what Sun's Hamburg developers wrote in reply...
>
> > Hi Kevin,
> >
> > -fstrict-aliasing is in -O2 optimization since gcc-3.0.x. And no, our
> > code is not strict alias safe. You'll get some problems, I know of at
> > least one place in sc. I bet there are more.
> >
> > I recommend to use -O2 -fno-strict-aliasing. This is what Hamburg
> > release engineering currently uses.
> >
> > If someone is able to identify all strict alias violating places I would
> > be more than happy to propose that we change these (or add the
> > -fno-strict-alias to just these files).
> >
> > Heiner
>
>So it looks like Solaris and Win must not detect these issues already.
>So a backport of the gcc 3.3 warning flag would certainly be a big help to
>the OOo project as well.

I see, but I think there is no chance that this is backported to an
official 3.2 release. Also 3.3 is only a few month away, so it makes no
real sense.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Kevin B. Hendricks]

Hi Franz,

> I see, but I think there is no chance that this is backported to an
> official 3.2 release. Also 3.3 is only a few month away, so it makes no
> real sense.

My guess is we will stick with gcc 3.2.X series since many distributions
will use that version as the basis for their next releases and not make
the move to gcc 3.3 since we also really need a stable C++ abi and the
constant changes to libstdc++.so versions is creating a bit of a support
nightmare.

Rgiht now to support building on all of the different versions of gcc we
have to do the following:

 .IF "$(CCNUMVER)">="000300000001"

COMID=gcc3
COMNAME=gcc3

.IF "$(CCNUMVER)"=="000300000001"
LIBSTDCPP3="3.0.1"
SHORTSTDCPP3="3"
.ENDIF

.IF "$(CCNUMVER)"=="000300000002"
LIBSTDCPP3="3.0.2"
SHORTSTDCPP3="3"
.ENDIF

.IF "$(CCNUMVER)"=="000300000003"
LIBSTDCPP3="3.0.3"
SHORTSTDCPP3="3"
.ENDIF

.IF "$(CCNUMVER)"=="000300000004"
LIBSTDCPP3="3.0.4"
SHORTSTDCPP3="3"
.ENDIF

.IF "$(CCNUMVER)"=="000300010000"
LIBSTDCPP3="4.0.0"
SHORTSTDCPP3="4"
.ENDIF

.IF "$(CCNUMVER)"=="000300010001"
LIBSTDCPP3="4.0.1"
SHORTSTDCPP3="4"
.ENDIF

.IF "$(CCNUMVER)"=="000300020000"
LIBSTDCPP3="5.0.0"
SHORTSTDCPP3="5"
.ENDIF

.IF "$(CCNUMVER)"=="000300020001"
LIBSTDCPP3="5.0.1"
SHORTSTDCPP3="5"
.ENDIF

.ENDIF

Because mixing libstdc++ versions seems to result in exception handling
issues across shared libraries and many machines seem to have multiple
copies of libstdc++ in various places as well as multiple gcc versions
lying around.

Is the original patch that added this warning someplace I could find and
hopefully modify to use with gcc 3.2.X?

Thanks,

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Franz Sirl]

At 14:11 02.12.2002, Samuel Rydh wrote:
>(unrelated: Does anyone understand why the compiler clears cr4.eq?)

Because you didn't give a prototype for TESTING.

>The compiler does the right thing if -fno-strict-aliasing is used or
>if 'int b' is replaced by 'ulong b'.

Well, the compiler was right before and as Andreas said, you are wrong. In
C *(ulong*)&B and *&B are different unrelated objects and the compiler
optimizes accordingly.

>Adding volatile after asm also fixes things (but I did not see
>this effect in the unsimplified example).

Besides the fact that it's almost always right in low-level inline assembly
to use __asm__ __volatile__ (because without the __volatile__ the __asm__
maybe hoisted out of loops if the compiler thinks it's a loop invariant),
you are just lucky that the __volatile__ fixes it.

So either fixup your code (with unions or char pointers) to be C compliant
or accept the performance penalty of -fno-strict-aliasing.

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Samuel Rydh]

On Mon, Dec 02, 2002 at 04:12:27PM +0100, Franz Sirl wrote:
> >The compiler does the right thing if -fno-strict-aliasing is used or
> >if 'int b' is replaced by 'ulong b'.
>
> Well, the compiler was right before and as Andreas said, you are wrong. In
> C *(ulong*)&B and *&B are different unrelated objects and the compiler
> optimizes accordingly.

Indeed. A quick check of the ISO C99 standard revealed that the compiler is
allowed to distinguish between int and long even though they share the
same representation on a particular arch.

> Besides the fact that it's almost always right in low-level inline assembly
> to use __asm__ __volatile__ (because without the __volatile__ the __asm__
> maybe hoisted out of loops if the compiler thinks it's a loop invariant),

...which is desirable in this case. The st_le32 inline is just an efficient
way to flip the endian and is not supposted to have any undeclared
side effects (like touching hardware).

/Samuel


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Gabriel Paubert]

On Mon, 2 Dec 2002, Samuel Rydh wrote:

>
> On Mon, Dec 02, 2002 at 04:12:27PM +0100, Franz Sirl wrote:
> > >The compiler does the right thing if -fno-strict-aliasing is used or
> > >if 'int b' is replaced by 'ulong b'.
> >
> > Well, the compiler was right before and as Andreas said, you are wrong. In
> > C *(ulong*)&B and *&B are different unrelated objects and the compiler
> > optimizes accordingly.
>
> Indeed. A quick check of the ISO C99 standard revealed that the compiler is
> allowed to distinguish between int and long even though they share the
> same representation on a particular arch.
>
> > Besides the fact that it's almost always right in low-level inline assembly
> > to use __asm__ __volatile__ (because without the __volatile__ the __asm__
> > maybe hoisted out of loops if the compiler thinks it's a loop invariant),
>
> ...which is desirable in this case. The st_le32 inline is just an efficient
> way to flip the endian and is not supposted to have any undeclared
> side effects (like touching hardware).

Efficient?

That's a store followed by a load from the same location. This implies
stalls in the memory queues, besides that since you can't use any memory
addressing mode, you have to put the address in a register, for a total
of 3 instuctions.

Compare with (src byte order is 1234 from MSB to LSB):
					# dst byte order
	rotlwi	dst,src,8		# 2341
	rlwimi	dst,src,24,0xff000000	# 4341
	rlwimi	dst,src,24,0x0000ff00	# 4321

that's also 3 instructions, 3 clocks because they have the same
destination. But no stack slot, no MMU translation and cache access
delays, straight register to register operations which could easily be
interspersed with other operations.

The only problem is that GCC is unable to reduce a series of equivalent
assignments to this short sequence of instructions, or at least I was
unable to obtain this ideal code from the compiler, even after trying to
add recognizers for rlwimi in the md file. I got better code for many bit
mainpulations except when they happened to fall on byte boundaries,
probably because some earlier pass in GCC tried to perform a 'clever'
transform on the sequence.

	Gabriel


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Samuel Rydh]

On Mon, Dec 02, 2002 at 06:53:47PM +0100, Gabriel Paubert wrote:
> > ...which is desirable in this case. The st_le32 inline is just an efficient
> > way to flip the endian and is not supposted to have any undeclared
> > side effects (like touching hardware).
>
> Efficient?

Well the scenario I had in mind was

	int x = ld_le32( &le_struct.x );
	...
	do some ops on x
	...
	st_le32( &le_struct.x, x )

Hard to beat endian flipping load and store operations in
that context :-). But you are of course right that it is quite
inefficient if one operates on something already loaded into a
register.

/Samuel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Benjamin Herrenschmidt]

On Fri, 2002-11-29 at 17:08, Samuel Rydh wrote:
>
> I just noticed that gcc 3.1 doesn't like the following:

According to Franz Sirl, gcc 3.2.1 is one of the very first gcc's
to not need any special patch for known bugs for PPC32 :) I'd
suggest you try this one.

I couldn't reproduce that bug with debian sid's gcc 2.95.4, 3.0.4 and
3.2.1

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: asm inline

[Gabriel Paubert]

	Hi Ben,

On 29 Nov 2002, Benjamin Herrenschmidt wrote:

>
> On Fri, 2002-11-29 at 17:08, Samuel Rydh wrote:
> >
> > I just noticed that gcc 3.1 doesn't like the following:
>
> According to Franz Sirl, gcc 3.2.1 is one of the very first gcc's
> to not need any special patch for known bugs for PPC32 :) I'd
> suggest you try this one.
>
> I couldn't reproduce that bug with debian sid's gcc 2.95.4, 3.0.4 and
> 3.2.1

Sorry, I replied far too fast to Samuel just before leaving on Friday,
simply throwing in al the ideas that came through my head. My first guess
turned out not to be so bad since this was indeed an aliasing problem.

In any case Samuel's code is not even 64 bit clean, the parameters for
st_le32 should never be long (64 bit on PPC64 and other 64 bit archs) in
the first place, but IMO something like int, or even u32 or s32 to stress
that you are accessing a 32 bit quantity.

I'm not a language lawyer by any stretch of the imagination but I believe
that the compiler has the right to reorder the accesses in the
-fstrict-aliasing case.

This said different distributions may ship different default options for
the compiler, either by tweaking the source code or the default spec file
IIRC, so checking some Debian's versions without specifying which
compiler flags were in effect does not mean much.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/