On Mon, 2005-01-24 at 12:04 -0500, Branden Robinson wrote:
> After discussing this with Keith Packard on IRC, I'm going to apply this
> patch with a guard on it:
>
> #if defined(__GNUC__) && defined(__arm__)
>
> Everyone seems to find the patch esthetically abhorrent, but it also
> appears to be
[I am not subscribed to -arm; please keep the bug number in your followups
if you'd like me to see them.]
On Tue, Jan 11, 2005 at 11:03:59PM +, Phil Blundell wrote:
> On Tue, 2005-01-11 at 12:37 -0500, Branden Robinson wrote:
> > Here are his remarks, recast a bit from IRC-speak into something
[I am not subscribed to debian-arm.]
On Tue, Jan 11, 2005 at 11:03:59PM +, Phil Blundell wrote:
> On Tue, 2005-01-11 at 12:37 -0500, Branden Robinson wrote:
> > Here are his remarks, recast a bit from IRC-speak into something more
> > conventional.
> >
> > GCC on ARM is doing something diff
Keith Packard wrote on 12 Jan 2005 00:03:31 +0100:
> No, Xlib assumes that the alignment of the struct or union is the alignment
> of the most restrictive element in that struct or union. Before ANSI C
> (note, not C99, but the original ANSI C which postdates Xlib), this was the
> way C worked.
Keith Packard wrote:
>
> Around 23 o'clock on Jan 11, Thiemo Seufer wrote:
>
> > Exactly. xlib seems to use the sum of the size of the primitives in an
> > element instead of the size of the first element.
>
> No, Xlib assumes that the alignment of the struct or union is the alignment
> of the m
On Tue, 2005-01-11 at 12:37 -0500, Branden Robinson wrote:
> Here are his remarks, recast a bit from IRC-speak into something more
> conventional.
>
> GCC on ARM is doing something different from every other C compiler I've
> seen. It may not deviate from what the C specification allows, but
Around 23 o'clock on Jan 11, Thiemo Seufer wrote:
> Exactly. xlib seems to use the sum of the size of the primitives in an
> element instead of the size of the first element.
No, Xlib assumes that the alignment of the struct or union is the alignment
of the most restrictive element in that struc
Jim Gettys wrote:
[snip]
> > >From a slightly outdated C99 draft, about the definition of arrays
> > and structures:
> >
> >[#19] Any number of derived types can be constructed from
> >the object, function, and incomplete types, as follows:
> >
> > -- An array type
On Tue, 2005-01-11 at 22:36 +0100, Thiemo Seufer wrote:
> Jim Gettys wrote:
> [snip]
> > > Strictly speaking, the ARM impementation of gcc is allowed to behave
> > > that way by the C standard. Not exercising this degree of freedom may
> > > be desireable to keep broken code working, but I'll leave
Jim Gettys wrote:
[snip]
> > Strictly speaking, the ARM impementation of gcc is allowed to behave
> > that way by the C standard. Not exercising this degree of freedom may
> > be desireable to keep broken code working, but I'll leave it to the
> > ARM people to weigh the tradeoff.
>
> Are you sure
On Tue, 2005-01-11 at 21:36 +0100, Thiemo Seufer wrote:
> Jim Gettys wrote:
> [snip]
> > > Well, and deliberate ABI changes are frowned upon by toolchain people.
> > > To me (without having looked further than the bug report) this seems to
> > > be an implementation bug in xlib, which appears to as
Jim Gettys wrote:
[snip]
> > Well, and deliberate ABI changes are frowned upon by toolchain people.
> > To me (without having looked further than the bug report) this seems to
> > be an implementation bug in xlib, which appears to assume some magic
> > number as element granularity in the array ins
On Tue, 2005-01-11 at 19:56 +0100, Thiemo Seufer wrote:
> Jim Gettys wrote:
> [snip]
> > This isn't saying we wouldn't add such a patch to X, though patches for
> > a particular compiler on a particular architecture do get frowned on
> > quite a lot: I just suspect ARM would find more code "just wo
Jim Gettys wrote:
[snip]
> This isn't saying we wouldn't add such a patch to X, though patches for
> a particular compiler on a particular architecture do get frowned on
> quite a lot: I just suspect ARM would find more code "just worked" if
> GCC behaved like other compilers in this case, and ARM
> Here are his remarks, recast a bit from IRC-speak into something more
> conventional.
>
> GCC on ARM is doing something different from every other C compiler I've
> seen. It may not deviate from what the C specification allows, but it
> appears to deviate from common practice. The ARM f
[I am not subscribed to debian-arm; please be sure that you retain at least
"[EMAIL PROTECTED]" in your replies.]
On Mon, Jan 03, 2005 at 12:38:12AM +0100, Nicolas George wrote:
> I would almost sayt it is the opposite of an ABI change. The exact
> description of this problem is that the Xlib head
16 matches
Mail list logo
