Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Compiler bug (OT)

Author: Dieter Buerssner

Date: 12:26:50 12/09/01

Go up one level in this thread


On December 09, 2001 at 12:33:51, Miguel A. Ballicora wrote:

>Also, running the same program compiled with and without optimizations.
>I found one problem with djgpp doing this. It was related with macros.
>IIRC, I had
>
>#define MYMACRO(x)  \
>{                   \
> something1(x);     \
> something2(x);     \
>}
>
>And produced different (wrong) code when it was compiled with optimizations.
>
>I fixed it doing
>
>#define MYMACRO(x)  \
>do {                \
> something1(x);     \
> something2(x);     \
>} while (0)
>
>I do not remember clearly, it might have been related to a bug I had, I don't
>know. The fact is that compiling with and without optimizations and doing
>the comparison alerted me of a problem.

I am of course not sure, but I would suspect a bug in your code here, especially
because the actual compiler won't see the macro anyway.
I have been using Gcc (including djgpp) compilers for over 10 years. While I
found some bugs, such a bug seems very unlikely. To make the macro safer, I
would suggest:

#define MYMACRO(x)  \
do {                \
 int y=(x); /* Or whatever the correct type is */ \
 something1(y);     \
 something2(y);     \
} while (0)

to make it work in cases like

  MYMACRO(function_with_sideeffect());

or

  MYMACRO(*array_pointer++);

But probably, you know already anyway :-)

Unfortunately, with some compilers, the do/while trick will give annoying
warnings ...

Standard C99 has inline, so perhaps after some time, we can forget about many
complicated/error prone macro tricks.

Regards,
Dieter




This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.