Re: [MiNT] How serious is GCC "cast increases requiered alignment of target type" warning?

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On Wednesday 26 May 2010, Vincent Rivière wrote:
> Ole Loots wrote:
> > static inline uint32_t *
> > get_xy_loc(nsfb_t *nsfb, int x, int y)
> > {
> >         return (uint32_t *)(nsfb->ptr + (y * nsfb->linelen) + (x <<
> > 2)); }
> >
> > the line with "return ( ..." throws the warning.
>
> There are a lot of unknown information...
> The definition of types nsfb_t, uint32_t and nsfb->ptr are missing in
> your snippet.
> Also the fact get_xy_loc() is static inline may change the things...
>
> We would need to have the full source code to understand what happens.
> I think this warning is probably harmless and could be ignored until
> better understanding.

Not necessarily.   As Andreas mentioned, GCC may do optimizations based on
the assumption that the return value is a pointer to 32 bit values (longs)
that are properly aligned (as developer had told with that cast that they
are such).

Funny (hard to debug) results can follow from this if they aren't.  Although
you would be explicitly checking or doing alignment for the returned values,
GCC could be (validly) optimizing them away as redundant.  And you would
see the bug only when enabling optimization (without inline, you would see
it only at -O3 level).

That will leave one scratching head when doing just C-level debugging. 
You need to disassemble the code and to check the values of registers
where these variables are stored.  As if you add checks for non-aligned
values and print only those out, GCC could optimize that code also away
as can-never-happen/redundant.


At least one should verify that nsfb->ptr and what is being added to
it are correctly aligned (x<<2 obviously is).


	- Eero