Where to report c compiler bug?

[Pablo Walters]

The bug only appears when compiling -O2 or -O3. It runs
perfectly if optimization is off.

C source:

Code: Select all

#include "stdio.h"

typedef struct poly {
    struct poly *next;
    int v0;
    int v1;
    int v2;
} poly;

int main(int argc, char **argv)
{
    poly *span, *active;

    span = (poly *)&active;
    span->next = 0;
    while(span->next) {
        fprintf(stderr,"will not print but needed for bug\n");
        span = span->next;
    }
    span->next = (poly *)20;

    fprintf(stderr,"active value is %d\n", (int)span->next);
    fprintf(stderr,"active value is %d\n", (int)active);
}

Makefile:

Code: Select all

all:
        cc bug.c -o bug 
        cc bug.c -o bug02 -O2 
        cc bug.c -o bug03 -O3 

[PeterO]

The bug only appears when compiling -O2 or -O3. It runs
perfectly if optimization is off.

It looks like you don't understand pointers in C....

span = (poly *)&active; <------ This makes no sense at all. "&active" is a pointer to a pointer, casting it to a pointer is wrong.

Your cast is masking the problem, if your code was correct you shouldn't need that cast, and without it the compiler complains....

bug1.c:14:14: warning: assignment from incompatible pointer type [enabled by default]
span = &active;


The compiler warns you about some other things as well....

Code: Select all

gcc -Wall -Wextra -o bug bug.c
bug.c: In function ‘main’:
bug.c:22:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 fprintf(stderr,"active value is %d\n", (int)span->next);
                                        ^
bug.c:23:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
 fprintf(stderr,"active value is %d\n", (int)active);
                                        ^
bug.c:10:14: warning: unused parameter ‘argc’ [-Wunused-parameter]
 int main(int argc, char **argv)
              ^
bug.c:10:27: warning: unused parameter ‘argv’ [-Wunused-parameter]
 int main(int argc, char **argv)
                           ^
bug.c:24:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

You should aim for a clean compile before publishing your code and pointing the finger at the compiler !

PeterO

[Pablo Walters]

You're right - this is some sketchy C that I used to use in the old days.

I'll avoid this construct in future.

[jamesh]

You're right - this is some sketchy C that I used to use in the old days.

I'll avoid this construct in future.

Nothing wrong with the 'construct'. Just needs to be sued correctly. Pointers take some time to become accustomed to.

[PeterO]

You're right - this is some sketchy C that I used to use in the old days.

I'll avoid this construct in future.

Nothing wrong with the 'construct'.

Oh yes there is It leaves a pointer to a poly pointing at a pointer to a poly. Memory corruption is almost certain to follow !

PeterO

[jahboater]

You should aim for a clean compile before publishing your code and pointing the finger at the compiler !

Yes, and more, you should have a full understanding of what counts as undefined behaviour, the "as if" rule, and so on.

A long time ago I filed a bug because, in something like "if( n == 5 || n == 6 )" the second test was executed first, even though the language has always guaranteed left to right evaluation. I was wrong. (the as-if rule ignores execution time)

[jahboater]

And this is too horrible to discuss:

Code: Select all

span->next = (poly *)20;

[PeterO]

And this is too horrible to discuss:

I thought it best to try and tackle one thing at a time
PeterO

[Paeryn]

The error, apart from being bad code shows why violating the strict-aliasing rule seems to break optimising compilers. Programmers have promised the compiler something and then gone and done something different and wonder why it breaks when the compiler stuck to the rules.

Code: Select all

$ gcc -o bug bug.c -Wstrict-alias=2
bug.c: In function ‘main’:
bug.c:14:5: warning: dereferencing type-punned pointer might break strict-aliasing rules [-Wstrict-aliasing]
     span = (poly *)&active;
     ^

Those strict-aliasing rules say that span (a pointer to a poly) can't actually point to the memory containg active (a pointer to a poly), it is expected to point to a poly. The compiler is free to assume that writing to span->next doesn't alter active in any way and so it can used pre-computed values when printing active rather than having to waste time reading it.
By using the cast you told the compiler that you knew what you were doing and took on responsibility for any breakages it caused. Clearly you didn't.

[Pablo Walters]

Thanks for this explanation - appreciate it. I was just surprised that

my C code did not work on Raspoberry PI.

This is from a polygon scan converter I've used for 20 years without

any problem on SGI, PC, OSX, iOS and Android.


I agree this is a very very bad way to write C. Always happy to learn

something new!

[jamesh]

You're right - this is some sketchy C that I used to use in the old days.

I'll avoid this construct in future.

Nothing wrong with the 'construct'.

Oh yes there is It leaves a pointer to a poly pointing at a pointer to a poly. Memory corruption is almost certain to follow !

PeterO

I wasn't talking about the implementation, but the general concept of pointers and pointers to pointers, clearly the code is incorrect!

[jamesh]

Thanks for this explanation - appreciate it. I was just surprised that

my C code did not work on Raspoberry PI.

This is from a polygon scan converter I've used for 20 years without

any problem on SGI, PC, OSX, iOS and Android.


I agree this is a very very bad way to write C. Always happy to learn

something new!

Difficult to see how that code ever worked tbh, it's very wrong.

[jahboater]

Thanks for this explanation - appreciate it. I was just surprised that

my C code did not work on Raspoberry PI.

This is from a polygon scan converter I've used for 20 years without

any problem on SGI, PC, OSX, iOS and Android.

You could try clang/LLVM (sudo apt install clang) for interest.
But as others have said, its best to fix (rewrite) the code.
Its bound to fail sooner or later with modern compilers and advanced optimization techniques.

Given a widely used, reliable compiler, such as GCC, if your code breaks when you try different optimization flags, then you can be sure its a bug in your code, not the compiler.

Never ignore compiler warnings. I would add -Wconversion to the list.
It wont help if there is a cast, but the need for the cast should ring alarm bells "(poly*)20" for example.
Compile cleanly with:

Code: Select all

-Wall -Wextra -Wconversion