Author: Miguel A. Ballicora
Date: 20:35:20 12/09/01
Go up one level in this thread
On December 09, 2001 at 15:26:50, Dieter Buerssner wrote:
>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
My point is that thanks to the comparison (accidental at that time) between
programs compiled with different optimizations I found the problem. I can't say
that it was not my fault, but that practice helps to detect a problem.
>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)
I do that already if I need. However, in the case in question was one of
the macros that dealt with my BITBOARD which is a structure that I do not
use any kind of side effect. The only thing I did was to add the "do"
and "while (0)" and there was not more any differences between optimized
and not optimized code. It gave in both cases the right answer.
I do not remember which macro was it, but it was one like this:
typedef union {
BYTE rw[8]; /*row*/
UINT16 qu[4]; /*quarter*/
UINT32 hf[2]; /*half*/
} BITBOARD;
#define BB_TURNBITS_OFF(d,s) \
do { BITBOARD x = (s); \
(d).hf[0] &= ~(x).hf[0]; \
(d).hf[1] &= ~(x).hf[1]; \
} while (0)
I should I have documented the problem but I was sloppy.
Of course, the problem was not with the macro. It was with
the compound statement {}. The optimization did not make it to execute properly
I saw that replacing the macro manually.
I am busy with something else, but when I use djgpp again I will give
a shot to reproduce it.
Regards,
Miguel
>
>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.