Bug in Watcom Compiler.

Hi. We had an “interesting” debugging experience here yesterday. After
finally tracking the problem down, it appears to be a bug in the Watcom
C++ compiler (version 10.6), specifically the optimizer.

In a nutshell, if a C++ const is defined in terms of a C++ library
function, the right set of optimizations will cause it to not be
properly evaluated for use during run time. Specifically for us, we had
a constant defined as such:

static const double TWO_PI = (4.0 * atan(1.0));

It started to get interesting when this appeared to be zero in some
spots, but the expected 6.28… in others. We finally caught the
difference - the modules that were compiled optimized (-Otrex -5 -fp5)
thought the constant was zero, while the unoptimized modules had the
correct value. We stepped through the startup code in wd and found
that, apparently, the optimizer was working too effectively - it was
removing instructions that it shouldn’t.

Sample code to duplicate this problem is below; it’s very easy to do.
I’m also looking into reporting this to the Open Watcom project. I’m
just posting this in hopes that it might help someone else.

Josh Hamacher
FAAC Incorporated


Sample code for generating this error follows. It consists of the
makefile, three c++ files, and one header file. The output is as
follows:


make all_unopt
./bug
Module 1 thinks TWO_PI is 6.28319

Module 2 thinks TWO_PI is 6.28319

make all_opt
./bug
Module 1 thinks TWO_PI is 0

Module 2 thinks TWO_PI is 0

make mixed
./bug
Module 1 thinks TWO_PI is 6.28319

Module 2 thinks TWO_PI is 0

\

Makefile

CC=cc
CFLAGS_OPT=-Otrex -5 -fp5 -w4 -M
CFLAGS_UNOPT=-g -w4 -M

all_unopt:
${CC} ${CFLAGS_UNOPT} -c -o mod1.o mod1.cpp
${CC} ${CFLAGS_UNOPT} -c -o mod2.o mod2.cpp
${CC} ${CFLAGS_UNOPT} -c -o bug.o bug.cpp
${CC} ${CFLAGS_UNOPT} -o bug bug.o mod1.o mod2.o

all_opt:
${CC} ${CFLAGS_OPT} -c -o mod1.o mod1.cpp
${CC} ${CFLAGS_OPT} -c -o mod2.o mod2.cpp
${CC} ${CFLAGS_OPT} -c -o bug.o bug.cpp
${CC} ${CFLAGS_OPT} -o bug bug.o mod1.o mod2.o

mixed:
${CC} ${CFLAGS_UNOPT} -c -o mod1.o mod1.cpp
${CC} ${CFLAGS_OPT} -c -o mod2.o mod2.cpp
${CC} ${CFLAGS_UNOPT} -c -o bug.o bug.cpp
${CC} ${CFLAGS_UNOPT} -o bug bug.o mod1.o mod2.o

end Makefile

// constant.h
#ifndef CONSTANT_H_INCLUDED
#define CONSTANT_H_INCLUDED

#include <math.h>

static const double PI = (4.0 * atan(1.0));
static const double TWO_PI = (2.0 * PI);

#endif
// end constant.h

// bug.cpp
#include <iostream.h>

extern double GetTwoPi1(void);
extern double GetTwoPi2(void);

int main(int argc, char *argv)
{
cout << "Module 1 thinks TWO_PI is " << GetTwoPi1() << endl;
cout << "Module 2 thinks TWO_PI is " << GetTwoPi2() << endl;

return 0;
}
// end bug.cpp

// mod1.cpp
#include “constant.h”

double GetTwoPi1(void);

double GetTwoPi1(void)
{
return(TWO_PI);
}
// end mod1.cpp

// mod2.cpp
#include “constant.h”

double GetTwoPi2(void);

double GetTwoPi2(void)
{
return(TWO_PI);
}
// end mod2.cpp

“Josh Hamacher” <hamacher@faac.com> wrote in message
news:3ADEF484.1702069A@faac.com

Sample code to duplicate this problem is below; it’s very easy to do.
I’m also looking into reporting this to the Open Watcom project. I’m
just posting this in hopes that it might help someone else.

Noted Josh. Thank you very much.

I have tested this and it is a bug in 11.0c. Not good.

Stephen Howe [TeamSybase] and member of OpenWatcom development team

Hi Stephen:

Is the OpenWatcom project focused entirely on DOS versions or is work also
being done on the QNX4 Watcom? Do you know if there is any effort to bring
Watcom for QNX4 from 10.6 forward to 11.0?

Stephen Howe wrote:

“Josh Hamacher” <> hamacher@faac.com> > wrote in message
news:> 3ADEF484.1702069A@faac.com> …

Sample code to duplicate this problem is below; it’s very easy to do.
I’m also looking into reporting this to the Open Watcom project. I’m
just posting this in hopes that it might help someone else.

Noted Josh. Thank you very much.

I have tested this and it is a bug in 11.0c. Not good.

Stephen Howe [TeamSybase] and member of OpenWatcom development team

“Dean Douthat” <ddouthat@faac.com> wrote in message
news:3AE5BE07.87FB0F78@faac.com

Is the OpenWatcom project focused entirely on DOS versions or is work also
being done on the QNX4 Watcom?

The focus at the moment is extremely narrow. Right now our attention is just
to get 11.0c out of door. 11.0c is just a bug fix to 11.0b, nothing more.
11.0c is just for DOS, 32-bit DOS, 16-bit Windows, Win32, 16-bit OS/2,
32-bit OS/2 & Novell.
After 11.0c is out, attention shifts to open sourcing what is there.

Do you know if there is any effort to bring
Watcom for QNX4 from 10.6 forward to 11.0?

AFAIK, no effort at present but I could be wrong. But as explained above, no
real effort has been expended on open sourcing. 11.0c has been the sole
attention of the OpenWatcom development team, for now. The best person to
answer that is Kendall Bennett. I know that he has got good connections with
QNX Software Systems. My big worry, myself, is causing a diplomatic faux
pas. I don’t want to put my foot in the wrong place. I would certainly like
to see the benefits of version 11.0: new style C++ casts, RTTI, explicit,
mutable keyword support, slightly better template support etc be available
to those using Watcom C/C++ for QNX. It would great if this branch of Watcom
compilers was brought back in so that as we move towards better compliance
with the ISO C 99 standard and ISO C++ 98 standard, it automatically
benefits. But not without the approval and blessing of QNX Software Systems.

Stephen Howe [TeamSybase]

Stephen Howe wrote:

“Dean Douthat” <> ddouthat@faac.com> > wrote in message
news:> 3AE5BE07.87FB0F78@faac.com> …

Is the OpenWatcom project focused entirely on DOS versions or is work also
being done on the QNX4 Watcom?

The focus at the moment is extremely narrow. Right now our attention is just
to get 11.0c out of door. 11.0c is just a bug fix to 11.0b, nothing more.
11.0c is just for DOS, 32-bit DOS, 16-bit Windows, Win32, 16-bit OS/2,
32-bit OS/2 & Novell.
After 11.0c is out, attention shifts to open sourcing what is there.

Do you know if there is any effort to bring
Watcom for QNX4 from 10.6 forward to 11.0?

AFAIK, no effort at present but I could be wrong. But as explained above, no
real effort has been expended on open sourcing. 11.0c has been the sole
attention of the OpenWatcom development team, for now. The best person to
answer that is Kendall Bennett. I know that he has got good connections with
QNX Software Systems. My big worry, myself, is causing a diplomatic faux
pas. I don’t want to put my foot in the wrong place. I would certainly like
to see the benefits of version 11.0: new style C++ casts, RTTI, explicit,
mutable keyword support, slightly better template support etc be available
to those using Watcom C/C++ for QNX. It would great if this branch of Watcom
compilers was brought back in so that as we move towards better compliance
with the ISO C 99 standard and ISO C++ 98 standard, it automatically
benefits. But not without the approval and blessing of QNX Software Systems.

Any comment from QSSL people who might be lurking herein? Some of us still have
many fielded QNX4 systems doing yeoman work. They need upgrading, new features
and the occasional bug fix so a more up-to-date compiler would be a big help.

Stephen Howe [TeamSybase]

I know this is slightly off-topic, but what’s the best way of reporting
bugs in 10.6 to the Open Watcom project? I got a bugzilla account, but
that really only seemed to be for reporting problems in the 11.0 series
compilers. I don’t anticipate finding any more problems (after all, it
is a pretty rare occasion when the compiler is actually at fault, as
opposed to the numerous occasions when we blame it :slight_smile: ), but I am
curious what the ‘official’ method is. Thanks.

Josh

“Josh Hamacher” <hamacher@faac.com> wrote in message
news:3AEF1891.4135D082@faac.com

I know this is slightly off-topic, but what’s the best way of reporting
bugs in 10.6 to the Open Watcom project?

For what reason?

I am assuming that the reason you want to do this is because you want to see
bugs in 10.6 fixed. Sure, I would like to see that as well :slight_smile:. But on that,
let me say, nothing to do with 10.6 will ever be fixed by the OpenWatcom
team. We do not have the codebase from Sybase and we never will. Only 11.0c
will be open sourced, 10.6 will never be. I am sorry :frowning:

The only possible value I see this having is is if it turns out that the
same bug exists in 11.0c. But personally, I think it would be better waiting
a bit. 11.0c will be out shortly, download that and see if the bug has gone.
If not, report on 11.0c, if it has, then great!!!

I got a bugzilla account, but
that really only seemed to be for reporting problems in the 11.0 series
compilers.

That is right. Why report bugs on 10.6, 10.5, 10.0, 9.5 etc ???

I don’t anticipate finding any more problems (after all, it
is a pretty rare occasion when the compiler is actually at fault, as
opposed to the numerous occasions when we blame it > :slight_smile: > ), but I am
curious what the ‘official’ method is. Thanks.

Well the official method is reporting via Bugzilla :slight_smile:. It should work. I
will check this.

10.6 was a very good release of the compiler, better than 10.5 and the
original 10.0. There are a few bugs but they are not obvious.

Hope this helps

Stephen Howe [TeamSybase]