--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12
06:50 ---
This is actually not a target issue, it can be shown on ppc also and other
targets including x86.
doing (f1*f2)^2^2 will be the best every where as it is only three instructions
and it would take the
same
type -a gcc gives /usr/bin/gcc
As for gnat, did a 'dpkg -L gnat|grep gcc' and the only entry that I found
(except the .../i486-linux/2.8.1 dir) was /usr/bin/gnatgcc
_
Express yourself instantly with MSN Messenger! Download today it's
LAST_UPDATED: Sat Dec 18 22:04:21 UTC 2004
Native configuration is mipsel-linux (remake)
=== gpc tests ===
Running target any
FAIL: adam3i.pas
FAIL: adam3j.pas
FAIL: adam3o.pas
FAIL: adam3p.pas
FAIL: assumptions.pas
FAIL: binrdwt.pas
FAIL: bitfields.pas
FAIL: chris4.pas
FAIL: ch
LAST_UPDATED: Tue Jan 11 00:09:12 UTC 2005
=== acats tests ===
FAIL: a26007a
FAIL: ad8011a
FAIL: c23003a
FAIL: c23003b
FAIL: c23003g
FAIL: c23003i
FAIL: c32001e
FAIL: c34002a
FAIL: c35502d
FAIL: c35502f
FAIL: c35503d
FAIL: c35503f
FAIL: c3a0004
FAIL: c43
LAST_UPDATED: Sat Dec 18 22:04:21 UTC 2004
Native configuration is arm-unknown-linux-gnu
=== libffi tests ===
Running target unix
FAIL: libffi.call/closure_fn0.c (test for excess errors)
WARNING: libffi.call/closure_fn0.c compilation failed to produce executable
FAIL: libffi.cal
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
--- Additional Comments From wilson at tuliptree dot org 2005-01-11 21:05
---
Subject: Re: [3.3/3.4 regression] [ia64] Extra '.restore
sp' in tail call
On Mon, 2005-01-10 at 23:07, steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot
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
--
What|Removed |Added
CC|wilson at specifixinc dot |
|com |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
---
* Alex Papadopoulos:
> Here is the output as requested :
> lrwxrwxrwx 1 root root16 2005-01-10 22:55 /usr/bin/gcc ->
> /usr/bin/gcc-3.3
> -rwxr-xr-x 1 root root 85196 2005-01-08 15:55 /usr/bin/gcc-3.3
> -rwxr-xr-x 1 root root 61000 2004-09-18 19:08 /usr/bin/gnatgcc
What does "type -a gcc"
--- Additional Comments From gdr at integrable-solutions dot net
2005-01-11 19:46 ---
Subject: Re: [3.3/3.4/4.0 regression] [ia64] Extra '.restore sp' in tail call
"wilson at specifixinc dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [3.3/3.4/4.0 regression] [ia64] Extra
|
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
Accepted:
gcc-snapshot_20050110-1.diff.gz
to pool/main/g/gcc-snapshot/gcc-snapshot_20050110-1.diff.gz
gcc-snapshot_20050110-1.dsc
to pool/main/g/gcc-snapshot/gcc-snapshot_20050110-1.dsc
gcc-snapshot_20050110-1_i386.deb
to pool/main/g/gcc-snapshot/gcc-snapshot_20050110-1_i386.deb
gcc-snapshot
gcc-snapshot_20050110-1_i386.changes uploaded successfully to localhost
along with the files:
gcc-snapshot_20050110-1.dsc
gcc-snapshot_20050110.orig.tar.gz
gcc-snapshot_20050110-1.diff.gz
gcc-snapshot_20050110-1_i386.deb
Greetings,
Your Debian queue daemon
--
To UNSUBSCRIBE, em
24 matches
Mail list logo
