[MPlayer-dev-eng] add -Wall to default CFLAGS

[Michael Niedermayer]

Hi

On Sat, May 05, 2007 at 11:13:51AM -0700, Trent Piepho wrote:
> On Sat, 5 May 2007, Michael Niedermayer wrote:
> > > static unsigned long long attribute_used __attribute__((aligned(8))) null_one = 0x0000ffff0000ffffULL;
> > > static unsigned long long attribute_used __attribute__((aligned(8))) one_null = 0xffff0000ffff0000ULL;
> > >
> > > I think I'll move this all back into standalone assembler anyway (to match
> > > rest of mpg123 code)...
> >
> > ive not followed this discussion but data accessed by asm should be
> > (u)intXX_t not int/long (long) later is _wrong_, long long could be
> > >64bit (yes i know this is not likely but still ...)
> 
> For values used in computing addresses, and not just pointers but an array
> index used in a scale-index-base addresst too, using 'long' will make code
> work on both ia32 and x86-64.
> 
> uint32_t result;
> uint32_t *base;
> long index;
> asm("mov (%1, %2, 4), %0" : "=r"(result) : "r"(base), "r"(index));
> 
> Since ia32 uses 32-bit pointers and x86-64 uses 64 bit, the pointer base
> will be a different size.  It's important that %2 match this size for the
> instuction to be valid.  If you use "int" or "uint32_t" for index, it will
> use a 32-bit register, and you get an invalid address like (%rax, %ebx, 4).
> I suppose the most correct type would be "intptr_t", but long works and gcc
> inline assembly is by it's nature non-portable.

intels c compiler supports gcc-asm too IIRC
so yes IMHO intptr_t would be correct and long just happens to work
that is long could easily be 32bit on x86-64 with some compiler ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070506/cdabb9ee/attachment.pgp>