Re: Was: Debug optimized code; Now: How many compiler bugs have you seen?

On Wed, 24 Sep 2008 12:46:15 -0400, Chris F Clark
<cfc@shell01.TheWorld.com> wrote:


>So, I wonder, how many of you have experienced real compiler bugs,
>that you could verify was the compilers fault and not just "mysterious
>behavior" that could be fixed by changing the optimizer/debugger
>level?


I seen a quite a few actual compiler bugs over the years. Many were
not optimization sensitive, but some were and some depended on which
CPU of a family was targeted.


Some bugs I just stumbled on by accident, but I've written a lot of
real time code and embedded code for a number of architectures -
including DSPs - so I've worked with odd-ball compilers and pushed
compilers to the breaking point.


A few of the fun things I've encountered:


    VisualC/C++:
    - in the 16-bit v1.5 compiler I found a bug in huge (32-bit)
        pointer access. When accessing a structure through a
        huge pointer, if a 32-bit integer field lay across a paragraph
        (16-byte) boundary, the compiler would fetch bytes up to
        the boundary and then wrap around and fetch the remaining bytes
        from the start of the paragraph.


    GCC on 68K (circa v2.4.5)
    - compiling C++, code that accessed a field of an anonymous
        structure would cause a bus error when run on a 68040 if
        compiled for the 040, but would work if compiled for 030
        or 020.


    Sun C Compiler (circa 1989, Sun 3/60)
    - if you had a struct or union containing a signed bitfield,
        incrementing the value so that it overflowed and became
        negative could trash the following field. This only happened
        at high optimization levels.


    Prime Pascal (circa 1986)
    - if the numeric labels of a case statement were sparsely
        distributed, the compiler would generate a kind of binary
        search through them. But if the labels were "too sparse", the
        search code would never match the last label.


    ADI VisualDSP++ (C/C++ compiler)
    - despite being v4, this was a new compiler for the 21xx and
        21xxx chip families. I used it on the 21060. if you wrote
        something like "j = ++i; ++i;" with both expressions on the
        same source line and you compiled for maximum speed, j would
        get the unincremented value of i. The code would work properly
        if you separated the expressions onto two lines or lowered the
        optimization level.




I've seen a lot of easy to trip over bugs like the ADI one above in
various DSP compilers I've used. Most of them were due I think to
hastily written language extensions and code generators for new chips.


George

Return to the comp.compilers page.
Search the comp.compilers archives again.