* Martin Michlmayr [EMAIL PROTECTED] [2008-01-21 18:33]:
This address looks highly suspicious as it is not aligned while the type
is a (void*).
On ARM unaligned access are not guaranteed to work and actually
depends on the CPU. On some of them it works as on i386, while usually
you
On Wed, Jan 02, 2008 at 10:09:39AM -0500, Camm Maguire wrote:
Package: gcc-4.2
Version: 4.2.2-4
Severity: important
/tmp/foo.c:
=
#include stdio.h
#include alloca.h
#include stdarg.h
#define object void *
int
* Camm Maguire [EMAIL PROTECTED] [2008-01-02 16:55]:
Is EABI the old arm, or the new? Couldn't this make a difference?
EABI is the new ABI.
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
* Camm Maguire [EMAIL PROTECTED] [2008-01-02 16:55]:
Is EABI the old arm, or the new? Couldn't this make a difference?
I can reproduce the problem with the old ABI (i.e. the current port in
Debian). I'll open a bug report with GCC.
--
Martin Michlmayr
http://www.cyrius.com/
--
To
Greetings!
Martin Michlmayr [EMAIL PROTECTED] writes:
* Camm Maguire [EMAIL PROTECTED] [2008-01-02 16:55]:
Is EABI the old arm, or the new? Couldn't this make a difference?
I can reproduce the problem with the old ABI (i.e. the current port in
Debian). I'll open a bug report with GCC.
On Thu, 2008-01-03 at 17:44 -0500, Camm Maguire wrote:
Greetings!
Martin Michlmayr [EMAIL PROTECTED] writes:
* Camm Maguire [EMAIL PROTECTED] [2008-01-02 16:55]:
Is EABI the old arm, or the new? Couldn't this make a difference?
I can reproduce the problem with the old ABI (i.e.
* Camm Maguire [EMAIL PROTECTED] [2008-01-03 17:44]:
Are we going to have two arm ports, or is the old one going away for
lenny?
arm will be in lenny but it'll probably go away in the next release or
the one after the next.
armel will hopefully be in lenny, but it's not even part of unstable
Package: gcc-4.2
Version: 4.2.2-4
Severity: important
/tmp/foo.c:
=
#include stdio.h
#include alloca.h
#include stdarg.h
#define object void *
int VFUN_NARGS;
void *alloca_val;
struct cons {
object c_cdr;
object
I just tried foo.c on up-to-date arm-sid and armel-sid systems, both
under qemu and on real hardware and I cannot reproduce the problem;
all succeed the same way, for example:
[EMAIL PROTECTED]:~$ /usr/bin/gcc-4.2 foo.c
[EMAIL PROTECTED]:~$ ./a.out
0xbe92ec84
0x1
0x2
0x3
[EMAIL PROTECTED]:~$ gcc
Herbert, do you think you could take a quick long at this bug report
before I forward it upstream to the GCC folks?
* Camm Maguire [EMAIL PROTECTED] [2008-01-02 10:09]:
Package: gcc-4.2
Version: 4.2.2-4
Severity: important
/tmp/foo.c:
On Wed, 2008-01-02 at 20:02 +0100, Martin Michlmayr wrote:
Herbert, do you think you could take a quick long at this bug report
before I forward it upstream to the GCC folks?
well, I couldn't reproduce that on a Debian EABI system with
ii gcc 4:4.2.2-1
Greetings!
May I add that eliminating this code resolved the issue present in
http://buildd.debian.org/fetch.cgi?pkg=gclcvsver=2.7.0-82arch=armstamp=1198067608file=log
as shown in
http://buildd.debian.org/fetch.cgi?pkg=gclcvsver=2.7.0-83arch=armstamp=1199286999file=log
Is EABI the old arm, or
Greetings!
Martin Guy [EMAIL PROTECTED] writes:
I just tried foo.c on up-to-date arm-sid and armel-sid systems, both
under qemu and on real hardware and I cannot reproduce the problem;
all succeed the same way, for example:
[EMAIL PROTECTED]:~$ /usr/bin/gcc-4.2 foo.c
[EMAIL PROTECTED]:~$
* Herbert Valerio Riedel [EMAIL PROTECTED] [2008-01-02 22:13]:
well, I couldn't reproduce that on a Debian EABI system with
ii gcc 4:4.2.2-1 The GNU C compiler
ii libc6 2.7-5 GNU C Library:
Shared
14 matches
Mail list logo
