Re: [Gcc4cli-devel] Running CLI code on Linux/SPARC64

[Gabriele S. <gab...@gm...>]

 Hi Erven,

2010/3/8 Erven Rohou <erv...@in...>:
> Hello everybody,
>
> I understand that we assume 32-bit pointers.
> But about endianness: I remember that we generate initializers for both, and a
> small run-time check to pick the right one. What are the cases where we have
> problems?

One (composed) word: bit-fields. And unfortunately not only the
bit-fields which you can find in regular C/C++ but also the ones that
GCC happily generates under many conditions. Here's one example:

struct foo
{
  short a;
  short b;
}

bool bar(struct foo*f)
{
  if (foo->a == 1 && foo->b == 2)
    return 1;
  else
    return 0;
}

GCC will turn the comparison into a BIT_FIELD_REF (or whatever it's
called now, there have been some changes there) that loads both the
16-bit integers as a single 32-bit integer and compares it with a
specifically tailored integer value. Unfortunately that value will be
different depending on the target endianness. When I was working on
that part of the project I tried disabling that specific optimization
only to find out that it was done both during the gimplification pass
and in the front-end (!) so it was impossible to remove it. I believe
that there were plans to move those optimizations in a better place
but I haven't followed the mailing-lists recently so I have no idea if
they actually did it. If they didn't, it is impossible to work around
that problem and that taints our code with the endian type we have
chosen at GCC build-time.

 Gabriele