Re: gcc bug

Re: gcc bug

[David Mosberger]

>>>>> On Tue, 17 Jun 2003 18:30:48 -0700, Umut Aymakoglu <umuta@us.ibm.com> said:

  Umut> Hi -
  Umut> Below is a small repro which shows the bug and the output that I get. Is
  Umut> this a known bug? Any help will be appreciated.

  Umut> The version of glibc :  glibc-2/2/4-32.3

The linux-ia64 list is not really the right place for reporting GCC
bugs.  Please see:

	http://gcc.gnu.org/bugs.html

for how to report GCC bugs.

You didn't mention what compiler you were using.  I tried your test
program quickly with gcc 3.2.3 and it worked fine for me.

	--david

gcc bug

[Josh Huber]

Interesting gcc bug here...

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.

This is a greatly simplified version of an actual piece of code (obviously,
as the code above is silly :)

Josh

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: gcc bug

[Gabriel Paubert]

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/

GCC bug

[ralf]

Alex,

I fixed a stupid GCC bug.  As a result the package f2c, flex and ncurses-4
will have to be rebuilt using the new GCC or building new programs using
the libraries provided by these packages may not be possible any longer.

I'll send you an updated gcc package asap.

  Ralf

GCC bug

[Ralf Baechle]

Hi,

the most current GCC package installs the header file assert.h although
it shouldn't.  The problem is that the GCC version of assert.h will
not include <gnu/stubs.h> but autoconf generated configure scripts
rely on that.  If you ever wondered why loading programs caused warnings
like 'the function lchown is not implemented and will always fail', this
is caused by the wrong assert.h.

Quick fix: rm <prefix>/<target>/include/assert.h, for example.
rm /usr/local/mipsel-linux/include/assert.h.  Note that this applies
to both native and crosscompilers.  None of them will install the
assert.h file in /usr/include/.

  Ralf