Experimental Physics and
Industrial Control System

"Singleton, SJ (Steve)" <[email protected]> · Fri, 19 Nov 2004 08:41:55 -0000

Andrew

>From my tests, the problem arises as a result of compiling for a PPC-based
IOC using: 

1. The compiler supplied by Windriver to build on a Solaris host for Tornado
2.2.1, i.e. vxWorks 5.5.1,
2. The gcc 2.9.6 compiler provided by Dave Thompson to build on a Linux host
for the same target.

It does not arise as a result of compiling for a PPC-based IOC using:

1. The compiler supplied by Windriver to build on a Solaris host for Tornado
2.0.2, i.e. vxWorks 5.4.2,
2. The gcc 2.7.2 compiler provided by Dave Thompson to build on a Linux host
for the same target.

We do not use 68K on Diamond so I cannot comment on compilers for that
processor.

Regards
Steve
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Andrew Johnson
Sent: 18 November 2004 17:25
To: Thompson, David H.
Cc: EPICS tech-talk
Subject: Re: calc and calcout records in EPICS 3.14.6

Thompson, David H. wrote:
> Question:
> Are you saying that this problem exists in the gcc 2.7.2 compiler AND
> the 2.9.6 (vxWorks 5.5.x) compiler for both the 68K and PPC?

I understood that what WRS shiped for Tornado 2.x was a mixture of two 
compilers - the C front end from gcc-2.7.2 (to retain backwards 
compatibility of the object files with earlier versions of vxWorks), and 
the C++ front end from EGCS (to get updated C++ support).

This optimizer problem has only been noticed on the 68K target, and not 
just in compiler versions built from the GCC sources you provide - my 
official WRS Tornado 2.0.2 compiler does exactly the same thing.

I confirmed Ron Sliuter's report about the code generated for 
epicsThreadSleepQuantum(), which is actually a very simple routine. 
Here's the complete test file that generates the error:

========================================================================

#include <vxWorks.h>
#include <stdio.h>
#include <sysLib.h>

#ifdef __cplusplus
#define EXPORT extern "C"
#else
#define EXPORT
#endif

EXPORT double bug();

/* Tornado compilers for 68k have an optimizer bug at -O1 and above; the
  * code generated for bug() is incorrect.  The vxWorksBrokenCompilerTest
  * routine tests for that bug, and must appear above the code it calls or
  * or the optimizer may inline epicsThreadSleepQuantum() */
EXPORT int vxWorksBrokenCompilerTest()
{
     double tick = bug();
     double one = tick * (double) sysClkRateGet();
     int ok = (one > 0.999) && (one < 1.001);
     printf("%s: bug() = %f\n", ok  ? "Ok" : "BROKEN", tick);
     return ok;
}

EXPORT double bug()
{
     double HZ = (double) sysClkRateGet();
     return 1.0 / HZ;
}

========================================================================

This is the code I get for the bug() routine using -O3:

                         bug:
ada916  4856                     PEA         (A6)
ada918  2c4f                     MOVEA .L    A7,A6
ada91a  61ff ff54 57fc           BSR         sysClkRateGet
ada920  203c 3ff0 0000           MOVE  .L    #0x3ff00000,D0
ada926  7200                     MOVEQ       #0,D1
ada928  2f01                     MOVE  .L    D1,-(A7)
ada92a  2f00                     MOVE  .L    D0,-(A7)
ada92c  f21f 5444                FDMOVE.D    (A7)+,F0
ada930  f200 4064                FDDIV .L    D0,F0
ada934  f227 7400                FMOVE .D    F0,-(A7)
ada938  201f                     MOVE  .L    (A7)+,D0
ada93a  221f                     MOVE  .L    (A7)+,D1
ada93c  4e5e                     UNLK        A6
ada93e  4e75                     RTS

Note how in the 4th instruction above, the value from the call to 
sysClkRateGet() which was returned in D0 gets trashed by the constant 1.0 
value being pushed onto the stack.

Using -O0, the code generated is this:
                         bug:
adbfbe  4e56 fff8                LINK  .W    A6,#0xfff8
adbfc2  61ff ff54 4154           BSR         sysClkRateGet
adbfc8  f200 40c4                FDMOVE.L    D0,F1
adbfcc  f22e 7480 fff8           FMOVE .D    F1,(0xfff8,A6)
adbfd2  f23a 5444 ffe0           FDMOVE.D    (0xffe0,PC),F0
adbfd8  f22e 5464 fff8           FDDIV .D    (0xfff8,A6),F0
adbfde  f227 7400                FMOVE .D    F0,-(A7)
adbfe2  201f                     MOVE  .L    (A7)+,D0
adbfe4  221f                     MOVE  .L    (A7)+,D1
adbfe6  6000 0002                BRA         0x00adbfea
adbfea  4e5e                     UNLK        A6
adbfec  4e75                     RTS

> And are
> you also saying that the c++ compiler is not affected?  Have you tested
> this or have experience that confirms this?

I thought that was the case, but I was wrong; the identical code gets 
generated whether I build the source file as C or C++ (and I know it's 
getting compiled as C++ code because I had to add the export "C" macro). 
Therefor I'm going to have to turn off the optimizer for C++ code as well. 
  This is very bad news for R3.14 on 68K until we get a compiler fix...

- Andrew
-- 
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System