There have been a few cases with GCC where something wouldn't run
right, and upgrading to a newer version of the compiler fixed the
problem, that I suspect indicated a bug in the compiler, but that
doesn't exactly qualify as "finding" the bug, and I can't prove it
wasn't bad code.

That still doesn't change the 99.9% rule that the bug is in your
code, even if the segfault occurs deep within the library code.
(That situation usually means you either passed bogus parameters,
e.g. fprintf(NULL, ...) or you've been abusing malloc()ed memory.)

I have found bugs in many compilers and assemblers.  For compilers
it was mostly buggy optimization, and in most such cases a call to
a dummy procedure solved it.  But it could be worse, like that
compiler that for some constructs would generate Vax code for a
68000.  And that assembler that generated the wrong opcode for a
particular instruction.  The latter was probably due to a typo in
a table.  The former was due to the heritage of the compiler.  The
compiler was based on a Vax compiler and almost everywhere the
code generation section had been adapted, but some places were
forgotten.

if (gettype(p)=PASSENGER) {
  /* ... */

What the compiler produced was identical to:

if (gettype(p), PASSENGER) {
  /* ... */

int foo(int a,int b) {}
int main(void) {
foo(printf("left\n"),printf("right\n"));
return 0;}

output: right
        left

C51 is a compiler for the Intel 8051 processor family. Those
processors have 2 different RAM areas called DATA and XDATA (external
data). DATA has 8 bit addresses (so it's limited to 256 bytes) and
XDATA has 16 bit addresses (up to 64k bytes). Program code is stored
somewhere else, and there's a few other ways of addressing memory, but
that's not important here.

Since the different memory areas are addressed using different machine
instructions, C51 supplies two different types of pointers - generic
and memory specific. The memory specific pointers are one or two bytes
and can only point to one type of memory (the type is determined by
how they are declared). The generic pointers are declare just like in
standard C and can point to any type of memory. This is accomplished
by using three bytes to store the pointer. The first byte (called the
MSPACE byte) stores a code that gives the type of memory, and the next
two bytes give the address (if it points to DATA, only one of these
two bytes is used).

The problem is how it converts pointers from memory specific to
generic, and how NULL is defined. NULL is a generic pointer with all
bits 0. To converting from a XDATA pointer to a generic pointer, the
two address bytes are copied directly across and the MSPACE byte is
set to 1 (the code for XDATA). A null XDATA pointer, then, is
converted to something that does not have all bits 0, and *does not
compare equal to NULL.*

I discovered this problem when I tried to malloc way more memory than
was actually available, and it appeared to succeed. I was using
generic pointers (trying to stay as portable as possible), but malloc
and friends return XDATA pointers (even though the compiler
documentation claims they return generic pointers). The null XDATA
pointer returned from malloc was being converted to a
null-but-not-NULL generic pointer.

Luckily the source for malloc and friends is included, so I made a
simple change to the return type (in the source and in stdlib.h) and
fixed the immediate problem. Unfortunately this is just a symptom of a
larger problem. Fortunately it seems unlikely to show up very often.

The version of C51 I use is not the most recent version, so it's
possible this has been addressed in the most recent one.

This, of course, is /why/ 99.9% of "compiler bugs" are not really
compiler bugs at all - people misunderstand the language without
realising it, and blame the compiler for getting it right!

Sensible way:

#include <stdio.h>

int foo(int a,int b)
{
  return 0;

#include <stdio.h>
int foo(int a){}int main(void){foo(
(printf("left\n"),printf("right\n")
));return 0;}

There are no comma operators in the call to `foo` above. The argument-
separating comma in an argument list is just punctuation, not a use
of the comma-operator.

[Since the comma-operator discards the value of its left operand, it's
just as well ...]

/* BEGIN aname.c */

#include <stdio.h>

int main(void)
{
    char array_name[1 + sizeof(char (*)[])] = {1};

    if (*array_name + sizeof &array_name == sizeof array_name)
        puts("\nThis may be a conforming compiler.\n");
    else
        puts("\nThis is not a conforming compiler.\n");
    puts(
        "char array_name[1 + sizeof(char (*)[])] = {1};\n\n"
        "sizeof(char (*)[]) should equal sizeof(&array_name)\n"
        );
    printf(
        "sizeof(char (*)[]) is %lu\n"
        "sizeof(&array_name) is %lu\n"
        "sizeof(array_name) is %lu\n",
        (long unsigned)sizeof(char (*)[]),
        (long unsigned)sizeof(&array_name),
        (long unsigned)sizeof(array_name)
        );
    return 0;