🚀 go-pugleaf

I've found a bug in v4 of the Norcroft C compiler, and this time I've
managed to save the relevant code (unlike the first time I found a bug
in the compiler a few months ago--I mentioned it but had no real proof,
as I fixed the code before making a backup...)

The problem seems like it's similar, something being broken as far as
the compiler goes when it comes to two function calls it succession without
explicitly assigning their values to variables.

The first time this happened was like this:

temp = function();
if(temp > THINGLIMIT) 
    fixit();
printf("there are now %d things\n", function());

This is (from memory) what the code looked like, the fault being that the
printf gave the value in temp and not the new value that function() should
have returned (as fixit() had changed the relevant variables that function()
read).

The second time a bug reared its head (a few days ago) I was working with the
author of the HPACK multi-system archiver trying to get an Arc port going 
(along with TMOTA, who did a lot of the sys specific functions) but the
order-0 arith engine was broken (it was getting the first byte in the output
stream wrong).

I ended up debugging it via telephone with the author (not, perhaps, the
optimal method of debugging :-) and we narrowed it down to the following
function:

void startDecode( void )
    {
    /* Initialize the bit input routines.  Since this is dual-use code
       we can only read in 8 bits of a possible 16 */

    value = ( ( ( ( WORD ) fgetByte() ) << 8 ) | fgetByte() );

    inBuffer = fgetByte();
    inBitsToGo = 8;
    dataLen -= 3;                /* We've read in 3 bytes so far */

    low = 0;                    /* The full code range */
    high = 0xFFFF;
    }

The variable 'value' appeared to be getting the two bytes around the wrong
way...

The problem went away with the following, more explicit, coding:

void startDecode( void )
    {
    /* Initialize the bit input routines.  Since this is dual-use code
       we can only read in 8 bits of a possible 16 */

    value = ( ( ( WORD ) fgetByte() ) << 8 );
    value = value | fgetByte();

    inBuffer = fgetByte();
    inBitsToGo = 8;
    dataLen -= 3;                /* We've read in 3 bytes so far */

    low = 0;                    /* The full code range */
    high = 0xFFFF;
    }

One genuine bug.

I hope this helps anyone using the C compiler out there, and hopefully a
bugfix will be shortly available.

Out of interest, has anyone else had this sort of problem happen to them
before? I've had it happen twice in code I've been working on or associated
with, so I'm a little concerned about how easily the problem is invokable...
Hopefully it _has_ only happened twice to me and I don't have little logic bombs
waiting to go off :-)                      

(I suspect it's the optimisers fault myself...) 

Minor Flame Start {
Can anyone think of any good reason why the optimiser is permanantly ON in
the C compiler? Every other C compiler on the planet has the optimiser as an
optional command line flag... Is it really just to make the dhrystone results
look better (as the benchmark specifies that the compiler should be run in
it's default state--optimiser off for everyone else, but on for the Acorn one)
} Minor Flame End

Edouard