[LLVMdev] Target backend not converting char* to struct properly.

Stephen McGruer stephen.mcgruer at gmail.com
Fri Oct 12 13:17:26 PDT 2012


If you could point me towards the correct location in the standard I would
appreciate that - I didn't realize it wasn't acceptable to turn
pointer-data to structs. My example is reduced from the EEMBC benchmarks
where I ran into the problem, so I may have reduced it too far by accident
(but I'm fairly sure they do not use __attribute__ or similar).

Adding a __attribute__((aligned(...))) to my example did help, so thank you
for that! Now to determine what to do about EEMBC...

Thanks,
Stephen

On 12 October 2012 21:01, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Fri, Oct 12, 2012 at 10:43 AM, Stephen McGruer
> <stephen.mcgruer at gmail.com> wrote:
> > I'm having trouble getting my backend to properly treat the situation
> where
> > a char* is converted into a struct, i.e. something like:
> >
> > char* pointer_representation = ...;
> > MyStruct* my_struct = (MyStruct*) pointer_representation;
> > my_struct->an_int_field = 5;
> >
> > When this occurs, LLVM seems to fold the struct and char* into one
> assembly
> > 'object', which is perfectly fine. However, it also keeps the
> 1-alignment of
> > the char array, which is not ok, as then the assignment (store) to the
> > 'an_int_field' gets converted into a 4-byte aligned store instruction -
> > which of course fails when run.
> >
> > My test case can be seen at http://pastebin.com/zPTi2GRW. Does anyone
> know
> > what I might need to do in my backend to make this work properly -
> perhaps
> > correct the definition of my 'store' instructions, or set a data-layout
> for
> > a struct type somewhere?
>
> Your code has undefined behavior; you're just getting lucky if it
> works anywhere.  (I can look up the standard reference if you're
> interested.)  Try __attribute((aligned)) on the array.
>
> -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121012/3b5742ee/attachment.html>


More information about the llvm-dev mailing list