Re: ifcvt.c and STORE_FLAG_VALUE

[Michael Meissner <meissner at cygnus dot com>]

On Thu, May 04, 2000 at 05:53:50PM +0100, John Vickers wrote:
> Philippe De Muyter wrote:
> > 
> > Bootstrapping on m68k-motorola-sysv yields also the following failure:
> > 
> > cc -c  -DIN_GCC    -g   -DHAVE_CONFIG_H    -I. -I/gcc -I/gcc/config -I/gcc/../include /gcc/ifcvt.c
> > "/gcc/ifcvt.c", line 519: illegal lhs of assignment operator
> > "/gcc/ifcvt.c", line 557: illegal lhs of assignment operator
> > "/gcc/ifcvt.c", line 640: illegal lhs of assignment operator
> > 
> > That happens with -STORE_FLAG_VALUE when STORE_FLAG_VALUE is defined as -1
> 
> > I thought to define it as (-1), but as it it tested in preprocessor
> > expressions for equality with -1, I did not dare to do that.
> 
> Sorry if I'm being dense, but the brackets in the macro definition
> don't look like a courageous step to me.
> 
> Presumably you agree that normally we should have the brackets
> in the definition, rather than hacking the point of use, but you
> perhaps know of a preprocessor where this would break ?

I definately think that STORE_FLAG_VALUE should be defined as (-1) in the m68k
as a matter of prinicipal.  I did misread the original article, and thought
that the reason the original test had to be that way was because they were
depending on two or more #define's of STORE_FLAG_VALUE and they had to be
textually the same, and there was some problem in changing the other one.  No
preprocessor that I'm aware of since the original Reiser rewrite in V7 has had
trouble with () in expressions other than casts, which aren't supported.  If
they do, then other parts of the compiler will not be able to be compiled.

So I would amend my last posting to say change the m68k definition.

-- 
Michael Meissner, Cygnus Solutions, a Red Hat company.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482