Re: [head tinderbox] failure on arm/arm

From: Alexander Kabaev <kabaev_at_gmail.com>
Date: Sun, 12 Nov 2006 13:21:05 -0500
On Sun, 12 Nov 2006 19:07:58 +0100
Giorgos Keramidas <keramida_at_freebsd.org> wrote:

> On 2006-11-12 20:14, Ruslan Ermilov <ru_at_freebsd.org> wrote:
> >On Sun, Nov 12, 2006 at 04:59:04PM +0000, Nicholas Clark wrote:
> >>On Sun, Nov 12, 2006 at 06:57:23PM +0300, Ruslan Ermilov wrote:
> >>> So your sizeof() argument, well...  I don't understand it and it
> >>> doesn't make things clearer at least to me.  I still believe this
> >>> is bug in GCC that the alignment requirement is so high for a
> >>> "struct foo { char x; }" (there's no real reason for this!).
> >>
> >> It is no bug in GCC. ANSI C gives extreme flexibility for the
> >> compiler to align (or pad) structures. The assumptions in the code
> >> you presented are not portable. The problem tends to be that ARM
> >> is the only common platform that does structure alignment this
> >> way, so tends to trip up a lot of code that has worked just fine
> >> in many other places.
> >>
> >> There is a lot more detail in
> >> http://netwinder.osuosl.org/users/b/brianbr/public_html/alignment.html
> >> including how gcc's __packed__ extention can be used to tell gcc
> >> to align structures in different ways.
> >
> > Thanks!  Item 2 at this URL has an answer to my question.
> 
> Perfect!
> 
> Now it's obvious why GCC prefers '4-byte accesses' on ARM.
> Nicholas, thank you so much :)
> 
  GCC expects 4-byte aligned structured on ARM but does not necessarily
have to. We can change the default at the expense of possible more
inefficient code generated and lost binary compatibility with other ARM
OSes out there. So this is trade off between unclear performance
penalty and an unspecified but certainly sizable number of other
landmines like this lurking on the code.

We should decide what evil we regard as lesser.

-- 
Alexander Kabaev

Received on Sun Nov 12 2006 - 17:21:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:02 UTC