Compiler bugs....
Foxy Emma Jane
time it is a problem with your code. I was just wondering
how often bugs are found in compilers. Has anyone here
found a bug in a compiler? Are there more bugs in free open
development compilers than in commercial products?
fej
Gordon Burditt
Yes, I've found bugs in compilers (bad code generation). In
commercial ones, mostly. More in runtime libraries (of both
commercial and free compilers). Not too many recently, though.
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.)
Gordon L. Burditt
Martin Dickopp
> I was just wondering how often bugs are found in compilers.
You can have a look at the GCC bug tracking system to find out how
many/how often bugs are found in that particular compiler collection.
> Has anyone here found a bug in a compiler?
Yes, several times. I once found a very obscure bug in a proprietary
Unix compiler which caused bad code to be generated if you chose a
particular (valid) variable name.
> Are there more bugs in free open development compilers than in
> commercial products?
I'd say there are more bugs in proprietary compilers than in
(commercial or non-commercial) free compilers. At least I have
encountered more bugs in the former. Of course, it is the nature
of proprietary software that you cannot know how many/what bugs
there are. :-)
Martin
Dik T. Winter
> >I know when you have a bug in your program, 99.9% of the
> >time it is a problem with your code. I was just wondering
> >how often bugs are found in compilers. Has anyone here
> >found a bug in a compiler? Are there more bugs in free open
> >development compilers than in commercial products?
>
> Yes, I've found bugs in compilers (bad code generation). In
> commercial ones, mostly. More in runtime libraries (of both
> commercial and free compilers). Not too many recently, though.
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.
But recent compilers are better than older compilers.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Joona I Palaste
I once found a bug in a freeware compiler for the Amiga system.
The compiler was actually quite happily compiling this piece of code:
if (gettype(p)=PASSENGER) {
/* ... */
}
where gettype() is a function (a regular function, not a macro)
taking an argument of the same type as p and returning int, and
PASSENGER was a macro #defined to be 3.
What the compiler produced was identical to:
if (gettype(p), PASSENGER) {
/* ... */
}
but it should have stopped at a syntax error or constraint
violation or something.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Bad things only happen to scoundrels."
- Moominmamma
Giannis Georgalis
btw. I Noticed that gcc 2.95.X on gnu/linux systems, evaluates the
arguments of a function from right-to-left eg.
int foo(int a,int b) {}
int main(void) {
foo(printf("left\n"),printf("right\n"));
return 0;}
output: right
left
while, gcc 3.x from left to right. Could this be a bug, provided that
the comma operator is meant to parse from left to right?
--
M-x signature-mode
remove all "-" and "%"s to reply
nrk
umm... I don't think that the argument list really counts as a case of
the comma operator. IIRC, there is no guarantee provided by the
language for the order in which function arguments are evaluated except
that they will all be evaluated before the call is made.
-nrk.
Csaba
from foxyem...@yahoo.com (Foxy Emma Jane). Hmmm, doesn't sound like A,
doesn't sound like I. Must be a human:
It is trivially easy to make MSVC end with an internal compiler error :-(
(with C++ code, I have to admit). I think those count as bugs.
--
A .sig ! A .sig ! My kingdom for a .sig !
Kevin Goodsell
wrote:
I found something that would probably be considered a bug in the Keil
C51 compiler recently. It's kind of interesting, so I'll describe it,
but I'll try to keep it brief (and I'll probably simplify a bit).
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.
-Kevin
Kalle Olavi Niemitalo
> I found something that would probably be considered a bug in the Keil
> C51 compiler recently.
One version of that compiler was lured into optimizing x/y to y/x
when the variables happened to be in convenient registers.
Richard Heathfield
>
> Giannis Georgalis wrote:
> > foxyem...@yahoo.com (Foxy Emma Jane) writes:
> >
> >
> >>I know when you have a bug in your program, 99.9% of the
> >>time it is a problem with your code. I was just wondering
> >>how often bugs are found in compilers. Has anyone here
> >>found a bug in a compiler? Are there more bugs in free open
> >>development compilers than in commercial products?
> >>
> >>fej
> >>
> >
> > btw. I Noticed that gcc 2.95.X on gnu/linux systems, evaluates the
> > arguments of a function from right-to-left eg.
> >
> > int foo(int a,int b) {}
> > int main(void) {
> > foo(printf("left\n"),printf("right\n"));
> > return 0;}
> >
> > output: right
> > left
> >
> > while, gcc 3.x from left to right. Could this be a bug, provided that
> > the comma operator is meant to parse from left to right?
> >
>
> umm... I don't think that the argument list really counts as a case of
> the comma operator.
You are correct, and he is wrong. In that context, it's a comma
*separator*.
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!
> IIRC, there is no guarantee provided by the
> language for the order in which function arguments are evaluated except
> that they will all be evaluated before the call is made.
Quite right. You can force evaluation either the sensible way (by
settling the argument values yourself before calling the function), or
the silly way (using parentheses):
Sensible way:
#include <stdio.h>
int foo(int a,int b)
{
return 0;
}
int main(void)
{
int a = printf("left\n");
int b = printf("right\n");
foo(a, b);
return 0;
}
Silly way:
#include <stdio.h>
int foo(int a){}int main(void){foo(
(printf("left\n"),printf("right\n")
));return 0;}
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
ke...@hplb.hpl.hp.com
Giannis Georgalis <j-g%e-o-r%g-a%l@u-o%c.g-r> writes:
>
> btw. I Noticed that gcc 2.95.X on gnu/linux systems, evaluates the
> arguments of a function from right-to-left eg.
>
> int foo(int a,int b) {}
> int main(void) {
> foo(printf("left\n"),printf("right\n"));
> return 0;}
>
> output: right
> left
>
> while, gcc 3.x from left to right. Could this be a bug, provided that
> the comma operator is meant to parse from left to right?
(parsing isn't the issue; order-of-execution is)
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 ...]
--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
pete
aname.c exposes a bug found both in Borland Turbo C and MSVC.
/* 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;
}
/* END aname.c */
--
pete