From: antirez <antirez@invece.org>
To: Ingo Rohloff <rohloff@in.tum.de>
Cc: epic@scyld.com, linux-kernel@vger.kernel.org
Subject: Re: epic100.c, gcc-2.95.2 compiler bug!
Date: Fri, 7 Sep 2001 16:13:23 +0200 [thread overview]
Message-ID: <20010907161323.B31574@blu> (raw)
In-Reply-To: <20010903130404.B1064@lxmayr6.informatik.tu-muenchen.de> <20010907160159.C621@lxmayr6.informatik.tu-muenchen.de> <20010907160315.D621@lxmayr6.informatik.tu-muenchen.de>
In-Reply-To: <20010907160315.D621@lxmayr6.informatik.tu-muenchen.de>; from rohloff@in.tum.de on Fri, Sep 07, 2001 at 04:03:15PM +0200
On Fri, Sep 07, 2001 at 04:03:15PM +0200, Ingo Rohloff wrote:
> BEWARE: DON'T USE gcc-2.95.2!
> I compiled the linux-2.4.9 version with gcc-2.95.2.
> And I can _definitely_ confirm that epic100.c triggers a compiler
> bug. (I have the erronous assembler code on my harddisk if anyone is
> interested.)
The following seems a gcc 3.0 bug, not sure it was fixed in gcc 3.01.
See the assembly generated with -O3 for the following code:
--------------------------------------------------------------
inline static long QInt(double inval)
{
long *l;
char *c = (char*) &inval;
inval = 68719476991.99;
l = (long*) (c+2);
return *l;
}
int main(void)
{
printf("%lu\n", QInt(OFFENDING_VALUE));
return 0;
}
---------------------------------------------------------------
the above function is compiled as:
.file "test2.c"
.section .rodata
.LC0:
.string "%lu\n"
.text
.align 16
.globl main
.type main,@function
main:
pushl %ebp
movl %esp, %ebp
subl $48, %esp
* movl $16776561, -32(%ebp)
* movl -30(%ebp), %eax
* movl $1110441984, -28(%ebp)
pushl %eax
pushl $.LC0
call printf
addl $16, %esp
movl %ebp, %esp
xorl %eax, %eax
popl %ebp
ret
.Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 3.0"
Note the line I marked with "*".
The double var is 8 byte, it is loaded
moving two 32 bit words in the -32 and -28 offset.
Unfortunatelly with -O3 the "*l" value get
computed between the two 'movl', and not after
the second movl.
This code is really unsane anyway but this seems
a clear gcc 3.0 bug.
I hope that the gcc folks here may report the
problem if not already known.
I didn't tested it but maybe the same problem
exists with other 8 byte types like 'long long'.
regards,
antirez
next prev parent reply other threads:[~2001-09-07 14:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-03 11:04 epic100.c, SMC EtherPower II, SMC83c170/175 "EPIC" Ingo Rohloff
2001-09-07 14:01 ` Ingo Rohloff
2001-09-07 14:03 ` epic100.c, gcc-2.95.2 compiler bug! Ingo Rohloff
2001-09-07 14:13 ` antirez [this message]
2001-09-07 14:26 ` Jakub Jelinek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010907161323.B31574@blu \
--to=antirez@invece.org \
--cc=epic@scyld.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rohloff@in.tum.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).