From: Gabriel Paubert <paubert@iram.es>
To: Josh Huber <huberj@wpi.edu>
Cc: Linux/PowerPC Devel List <linuxppc-dev@lists.linuxppc.org>
Subject: Re: gcc bug
Date: Fri, 31 Mar 2000 17:18:54 +0200 (METDST) [thread overview]
Message-ID: <Pine.HPX.4.10.10003311657580.13384-100000@gra-ux1.iram.es> (raw)
In-Reply-To: <20000331092707.C354@wpi.edu>
On Fri, 31 Mar 2000, Josh Huber wrote:
>
> Interesting gcc bug here...
No.
>
> in both cases this should print 0xDEADBEEF, but in the second case, garbage
> is printed.
>
> main()
> {
> unsigned long t1 = 32;
> unsigned long long t2 = 64;
>
> printf("%x\n", 1 ? 0xDEADBEEF : t1);
> printf("%x\n", 1 ? 0xDEADBEEF : t2);
> }
>
> as expected, the 1 ? ... operation is optimized away, but the compiler seems
> to screw things up ...
>
> working case:
> li 4,15
> crxor 6,6,6
> bl printf
>
> failure case:
> li 5,0
> li 6,15
> crxor 6,6,6
> bl printf
>
> in the failure case, r4 is not loaded with anything, so this is were the
> garbage probably comes from.
The compiler is right, it chooses to pass the parameter as a long long
because of promotion rules among the types of the two expressions of a ? :
operator.
But you have to tell printf that the variable is a long long for varargs
in the library functions to find it, so replace your last statement with
printf("%llx\n", 1 ? 0xDEADBEEF : t2) and it will work properly.
There have been various bugs in this area with GCC on PPC, in some cases
due to varargs problems and the ABI actually took some time to stabilize
and to be properly implemeted IIRC. But in this case the compiler is
right: if it is a long long it can only be passed in r3:r4, r5:r6, r7:r8,
r9:r10, or on the stack.
Think at what happens if you don't tell that the argument is a long long
and you have more arguments after that one, everything will be off. And
it's not an endian issue either, it will just give the impression to work
when this is the last parameter on most little endian machines but the bug
would stil be here. Little endian is great to hide bugs, it's basically
the only "advantage" it has, and I regard this as a fundamental flaw.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-03-31 15:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-31 14:27 gcc bug Josh Huber
2000-03-31 15:18 ` Gabriel Paubert [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-06-18 19:00 David Mosberger
1998-07-10 19:49 GCC bug ralf
1997-07-05 21:09 Ralf Baechle
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=Pine.HPX.4.10.10003311657580.13384-100000@gra-ux1.iram.es \
--to=paubert@iram.es \
--cc=huberj@wpi.edu \
--cc=linuxppc-dev@lists.linuxppc.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.