[Bug ada/34446] gnatprep evaluating "not" operator at incorrect precidence

["bdavis at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #3 from bdavis at gcc dot gnu dot org  2007-12-14 23:13 -------
not sure i would call this one 'resolved'.

the gnat users manual does not document any such restriction:

----------------------------------------------------------------------

In this example, expression is defined by the following grammar:
      expression ::=  <symbol>
      expression ::=  <symbol> = "<value>"
      expression ::=  <symbol> = <symbol>
      expression ::=  <symbol> ?Defined
Chapter 16: Preprocessing Using gnatprep           193
     expression ::= not expression
     expression ::= expression and expression
     expression ::= expression or expression
     expression ::= expression and then expression
     expression ::= expression or else expression
     expression ::= ( expression )
-------------------------------------------------------------
since NOT VAR_TRUE is an EXPRESSION and an
expression can be an EXPRESSION or VAR_TRUE, it sure seems like it
should work as described.

the change that declares this an error is this one:

Revision 125441 - (view) (download) - [select for diffs]
Modified Wed Jun 6 10:40:36 2007 UTC (6 months, 1 week ago) by charlet
File length: 46257 byte(s)
Diff to previous 118249 (colored)

2007-04-20  Vincent Celier  <celier@adacore.com>

        * prep.ads, prep.adb (Expression): New Boolean parameter Complemented,
        defaulted to False.
        In the "not" case, recursive call with Complemented set to True.
        Do not allow "or" or "and" operators when Complemented is True.



i did not find any discussion on this on gcc-patches during april (but it was a
busy month, could have missed it).

i think this is a valid bug.  if gnatprep is supposed to have this limit, it
should be expressed in the users manual.  if it is not, then the code should be
changed to work as expected.

the request is very reasonable, and it used to work that way.  backwards
compatibility is important.  some would call this a regression.

regards,
bud davis


-- 

bdavis at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.0                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34446