gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gm2 rejecting a constant statement as variable


From: Gaius Mulley
Subject: Re: gm2 rejecting a constant statement as variable
Date: Tue, 02 Apr 2024 11:27:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Alice Osako <alicetrillianosako@gmail.com> writes:

> If I am understanding this correctly, what you are saying is that a
> boolean expression operating on two named/computed scalar constants is
> not considered a constant expression?

currently this is the case (and a bug).

> Since the operands are constants (named or otherwise), I would have
> expected that normal constant folding would reduce the expression to a
> constant value up front, just as it would with an arithmetical
> operator expression. Am I misunderstanding something?

no - you're right it is a bug!

> I had thought that GCC applied constant folding in a pre-optimization
> stage performed on the AST, before intermediate code generation, but
> perhaps I was wrong. I don't really know the internals of GCC, so I
> assume that I misunderstood that.
>
> Now, curiously enough, with the latest build for the compiler, the lines
>
> CONST
>   BitsInUse =
>     ORD(AddressableBits > MaxBits) * MaxBits +
>     ORD(AddressableBits <= MaxBits) * AddressableBits;
>
> Still give the error:
>
> src/imp/Hash.mod:35:13: error: In implementation module ‘Hash’: in
> assignment, cannot assign a variable to a constant ‘BitsInUse’
>    35 |   BitsInUse =
>       |             ^
> src/imp/Hash.mod:35:3: error: designator ‘BitsInUse’ is declared as a CONST
>    35 |   BitsInUse =
>
> However, it works exactly as expected if written as:
>
> CONST
>   BitsInUse = ORD(AddressableBits > MaxBits) * MaxBits +
>               ORD(AddressableBits <= MaxBits) * AddressableBits;
>
> Aside from the question of why this contradicts your earlier
> explanation, the problem of treating a constant assignment with a
> newline immediately after the equals sign as if there were a variable
> in the expression still persists, and seems to be independent of the
> constants issue.

ah sorry - a misunderstanding I think - I split the bug you reported
into two sub bugs (to keep the patches small):

  (i)  gm2 did not identify variables inside a constant sub expression
       (but merely reported the whole expression was not constant).
  (ii) const relop expressions do not generate and present constants
       internally to gcc.

The push yesterday addressed (i) and I'll move onto (ii) today :-)

regards,
Gaius



reply via email to

[Prev in Thread] Current Thread [Next in Thread]