🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

🏠 Home 📰 News 🗂️ Usenet Search 🔑 Login 📝 Register
Thread View: comp.sys.acorn.tech
10 messages
[T] Back to Threads [V] Tree View [G] Group Articles
10 total messages Started by Edouard Poor Thu, 01 Oct 1992 03:39
Bug found in v4 of Acorn C compiler
#453
Author: Edouard Poor
Date: Thu, 01 Oct 1992 03:39
89 lines
3786 bytes 
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
Re: Bug found in v4 of Acorn C compiler
#454
Author: mcg
Date: Thu, 01 Oct 1992 07:35
41 lines
1991 bytes 
> 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
> 


 Major Flame Start {

UG! 

Harrumph... I suspected the optimiser was on..... 

It makes debugging/tracing ARRAYS (matricies) and other such variables a 
MAJOR BUMMER. (i.e after an array as been through a function, one gets results 
1.9876735664 E+238.....)

I compiled a proglet (a numerical analysis using (vectorial) Lax-Wendroff 
F-D scheme) on the VAX with optimize on and got similar results to debugging 
on the Archie [ made a hell of a difference when I turned the optimiser off!] 

I also suspect this may be the reason the flaming debugger on the Arc changes 
the program enviroment; stuffing the &^^$$#$@#'ing results!

} Major Flame End.

From Martin Glanvill		(mcg@waikato.ac.nz)

Dept. Maths 							      @@@@@/|@
University of Waikato						      @@@@/ |@
Hamilton							      @@@/__|@
New Zealand							      @@/   |@
								      @@@@@@@@

----------------****=====| A quote to make your day |======****-----------------
Any philosophy that can be put in a nutshell belongs there.
                                        -- Sydney J. Harris
-------------------------------------------------------------------------------
Re: Bug found in v4 of Acorn C compiler
#456
Author: Philip Hazel
Date: Thu, 01 Oct 1992 09:20
28 lines
1672 bytes 
In article <1992Oct1.033932.22482@cs.aukuni.ac.nz>, epoo1@cs.aukuni.ac.nz (Edouard Poor) writes:
|> 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...)

[stuff deleted]

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

[...]

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

This is not a bug. There is nothing in the ANSI standard which requires
function calls in an expression of this type to be evaluated in a given order.
The compiler is perfectly entitled to evaluate the second call to fgetByte
before the first one.

[Some operators *do* force an evaluation order, among them the logical
operators || and &&, so that expressions like  (a == NULL || *a == 0) make
sense.]

--
Internet: P.Hazel@ucs.cam.ac.uk       University Computing Service,
JANET:    P.Hazel@uk.ac.cam.ucs       Computer Laboratory, Pembroke St,
Phone:    +44 223 334714              Cambridge CB2 3QG, England.
Re: Bug found in v4 of Acorn C compiler
#458
Author: Richard Earnshaw
Date: Thu, 01 Oct 1992 09:35
18 lines
1210 bytes 
>    value = ( ( ( ( WORD ) fgetByte() ) << 8 ) | fgetByte() );
>  The variable 'value' appeared to be getting the two bytes around the wrong
>  way...

There is *nothing* in the C specification which defines the order in which the
calls to fgetByte() should be executed; indead the specification says quite
explicitly that such behaviour is *Implementation dependent*.  This is Not a
bug: if you wish to enforce a specific order you must code the calls as 
seperate statements.

Richard
-----------------------------------------------------------------------
Richard Earnshaw
University of Cambridge Computer Laboratory
Pembroke Street
Cambridge
CB2 3QG
+44 223 334650
Re: Bug found in v4 of Acorn C compiler
#457
Author: Edward Nevill
Date: Thu, 01 Oct 1992 09:39
8 lines
685 bytes 
In article <1992Oct1.033932.22482@cs.aukuni.ac.nz> epoo1@cs.aukuni.ac.nz (Edouard Poor) writes:

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

The order of evaluation is not guaranteed in ANSI C. This is a bug in your
program, not the compiler.

Edward (enevill@acorn.co.uk)
Re: Bug found in v4 of Acorn C compiler
#459
Author: Harry Meekings
Date: Thu, 01 Oct 1992 11:07
37 lines
1895 bytes 
In article <1992Oct1.033932.22482@cs.aukuni.ac.nz> epoo1@cs.aukuni.ac.nz (Edouard Poor) writes:

>
>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() );
>
> ....
>
>One genuine bug.
>

Indeed so, but in the program not in the compiler.  The order of evaluation
of subexpressions is unspecified (except where there's a sequence point as with
operators such as &&).  This, by the way, is explicitly stated in K&R 1, not
an invention of ANSI.  It so happens that the Acorn compiler in this case
chooses to evaluate the right-hand call of fgetByte before the left-hand
one, for reasons which have nothing to do with the optimiser.  You have been
given one of the two values you ambiguously asked for, and can't very well
complain.

With regard to dhrystone figures, you seem to live in a different world from
the rest of us.  The ground rules for dhrystone are:
 *  - Separate compilation
 *  - No procedure merging
 *  - Otherwise, compiler optimizations are allowed but should be indicated
 *  - Default results are those without register declarations
No 'use default options' there, and indeed looking at the set of reported
dhrystone times, I don't see any which don't use at least -O; many use exotic
-O sub-options

Harry Meekings

I speak for myself alone, etc etc.
Re: Bug found in v4 of Acorn C compiler
#461
Author: Andy Duplain
Date: Thu, 01 Oct 1992 17:16
42 lines
2252 bytes 
In article <1992Oct1.033932.22482@cs.aukuni.ac.nz> epoo1@cs.aukuni.ac.nz (Edouard Poor) writes:
>
>    value = ( ( ( ( WORD ) fgetByte() ) << 8 ) | fgetByte() );

	The following text is an extract from "Harbison and Steele, 3rd
	edition, page 207":
	
	"In general, the compiler can rearrange the order in which an
	expression is evaluated.  The rearrangement may consist of evaluating
	only the arguments of a function call, or the two operands of a
	binary operator, in some particular order other than the obvious
	left-to-right order.  The binary operators +, *, &, ^ and | are
	assumed to be completely associative and commutative, and the
	compiler is permitted to exploit this assumption".
	
>One genuine bug.

	Wrong.

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

	Wrong.

>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
>	       
	The Microsoft C compiler has "some" optimisations on by default
	(you may turn all optimisation on, or all off, from the command line).
	I _guess_ it may be to do with debugging information; the GNU C
	compiler is capable to generating optmised code _with_ source level
	debugging information, while others mutually exclude '-O' and '-g'...
	maybe Acorn C v4 can do both, like gcc ? 
	Anyway, why is it a problem ?  compile time ?
	
-- 
Andy Duplain, BT Customer Systems, Brighton, UK.            duplain@rtf.bt.co.uk
#define	DISCLAIMER      My views and opinions are my own, and not my company's
Re: Bug found in v4 of Acorn C compiler
#463
Author: Andrew P.Mell
Date: Fri, 02 Oct 1992 00:35
12 lines
950 bytes 
In article <1992Oct1.193543.11168@waikato.ac.nz> mcg@waikato.ac.nz writes:

>
>Harrumph... I suspected the optimiser was on..... 
>
>I compiled a proglet (a numerical analysis using (vectorial) Lax-Wendroff 
>F-D scheme) on the VAX with optimize on and got similar results to debugging 
>on the Archie [ made a hell of a difference when I turned the optimiser off!] 
>
Eh? I was under the impression that cc -g disabled the optimiser?

A
Re: Bug found in v4 of Acorn C compiler
#464
Author: Andrew P.Mell
Date: Fri, 02 Oct 1992 00:42
76 lines
3113 bytes 
Talking of bugs in Cv4, Help! I'm stuck on this one....

!DDT repeatedly address exceptions on me, I've tracked this down to
probably being Acorn C v4.00 generating incorrect debug info
(specifically the line number info)

Look at the output of decaof -g for one of my program modules.

How do I get around this apparent bug in Cv4?

Andy


** Identification

Norcroft RISC OS ARM C vsn 4.00 [May  3 1991]

** Header

AOF file type: Relocatable object code
AOF VSN:   150
No of areas:     5
No of symbols: 534


** Area C$$debug, Alignment 4, Size 50200 (0xc418), 1386 relocations
        Attributes: Data: Read only: Debugging tables

00000000 --- Section
00000002 Length = 40
00000004 Language: C
00000005 Flags: line number info, local variable info
00000007 Debugging table version: 1
00000008 Code address 0x00000000 (Relocation offset 0x00000008)
0000000c Data address 0x00000000 (Relocation offset 0x0000000c)
00000010 Code size = 0x0000f7a4
00000014 Data size = 0x000011cc
00000018 File info offset = 0x0000af90 (AREA offset 0x0000af90)
0000001c Section size = 50200
00000020 Section name: "c.term"
00000028 --- Type

.. etc..

0000c398 Line 7060, statement 1 at code address 0x0000f792
0000c39a Line 7061, statement 1 at code address 0x0000f7a2
0000c39c Line 7062, statement 1 at code address 0x0000f7aa
0000c39e Line 7063, statement 1 at code address 0x0000f7b2
0000c3a0 Line 7064, statement 1 at code address 0x0000f7be
0000c3a2 Line 7065, statement 1 at code address 0x0000f7ca

..etc...

0000c3a4 Fragment 3 (size = 19661112)
0000c3a8 First line = 19661112
0000c3ac Last line = 19661104
0000c3b0 Code address 0x01100230 (Relocation offset 0x0000c3b0)
0000c3b4 Code size 0x03e70000
0000c3b8 Line 19661112, statement 1 at code address 0x01100230
0000c3ba Line 19661112, statement 2 at code address 0x01100234
0000c3c0 Line 19661136, statement 1 at code address 0x01100234
0000c3c6 Line 19661136, statement 2 at code address 0x01106a3c

...etc...

00012932 Line 29139522, statement 10 at code address 0x017d6c8d
00012938 Line 29139522, statement 11 at code address 0x017d6c8d
0001293e Line 29139522, statement 12 at code address 0x017d6c8d
00012944 Line 29139522, statement 13 at code address 0x017d6c8d
0001294a Line 29139522, statement 14 at code address 0x017d6c8d
00012950 Line 29139522, statement 15 at code address 0x017d6c8d

I seriously doubt my program has 29139522 lines, and more than 10
statements per line. I've tried fiddling the source around, rearranging
it etc. but to no avail, please tell me whats wrong, its driving me mad!
Re: Bug found in v4 of Acorn C compiler
#465
Author: Edouard Poor
Date: Fri, 02 Oct 1992 04:26
42 lines
2512 bytes 
In <7581@armltd.uucp> hmeekings@armltd.co.uk (Harry Meekings) writes:
>In article <1992Oct1.033932.22482@cs.aukuni.ac.nz> epoo1@cs.aukuni.ac.nz (Edouard Poor) writes:
>>
>>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() );
>>
>> ....
>>
>>One genuine bug.
>>
>Indeed so, but in the program not in the compiler.  The order of evaluation
>of subexpressions is unspecified (except where there's a sequence point as with
>operators such as &&).  This, by the way, is explicitly stated in K&R 1, not
>an invention of ANSI.  It so happens that the Acorn compiler in this case
>chooses to evaluate the right-hand call of fgetByte before the left-hand
>one, for reasons which have nothing to do with the optimiser.  You have been
>given one of the two values you ambiguously asked for, and can't very well
>complain.

Ahhh, I am sorry. I was sort of relying on the author of the codes appraisal
of what the compiler did to his source. He has since said that if one takes
the ANSI spec pedantically, then yes, you cannot reply on the ordering of
evaluation even when it comes to external function calls.

Makes me feel like a bit of a grumbo though :-\

That part of the HPACK source has, however, compiled on every other platform
and compiler its been ported too (= many). I am aware that ANSI-compliant
does no nessessarily == portable as there is a fair amount of detail left
up to the implementation. Maybe the documentation should point out the
more obvious departures from what the newer C programmer might expect? (I
am at least careful about post and pre increments etc...)

I shall now gracefully withdraw from the field declaring that a bug has
been found in the ANSI spec and therefore no-one around here can be
landed with responsability for the code not working... :-)

Edouard.
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads