The following is evaluated incorrectly with gnatprep 3.4.6 # if not VAR_TRUE or VAR_TRUE then ans := Good; # else ans := Wrong; # end if; Using command: gnatprep -r -DVAR_TRUE=true thing.in thing.out generates following results --! # if not VAR_TRUE or VAR_TRUE then --! ans := Good; --! # else ans := Wrong; --! # end if; An earlier version(3.3.3) of gnatprep produced correct results.
This is fixed in SVN trunk: ==============Error messages for input file: thing.in 1. # if not VAR_TRUE or VAR_TRUE then | >>> mixing "not" and "or" is not allowed, parentheses are required 5 lines: 1 error
Subject: RE: gnatprep evaluating "not" operator at incorrect precidence Sorry, I had assumed gnatprep would follow the same rules of precidence as the ADA RM requires. I had not known this not mixing of "not" and "and" or "or" rule was established.(operation changed someplace between 3.3.3 and 3.4.1) On the version included with gcc-3.3.3 the gnatprep tool performs the evaluation for "not" operator / keyword acording to the ADA RM precidence. The GNAT RM on gcc.gnu.org doesn't precicely indicate one way or other how/when "not" should be evaluated. I'll "patch" the gcc-3.4.6 version of gnatprep for our internal use until the 2000+ lines(approx 400 source files) not currently following the NEW rule are modified. Thank You for the info. Ron Pucul -- Old/tired sftwr. eng. here @ L3 Link. > -----Original Message----- > From: sam at gcc dot gnu dot org [mailto:gcc-bugzilla@gcc.gnu.org] > Sent: Thursday, December 13, 2007 7:40 AM > To: Pucul, Ronald E. @ Link > Subject: [Bug ada/34446] gnatprep evaluating "not" operator > at incorrect precidence > > > > ------- Comment #1 from sam at gcc dot gnu dot org > 2007-12-13 13:39 ------- This is fixed in SVN trunk: > > ==============Error messages for input file: thing.in > 1. # if not VAR_TRUE or VAR_TRUE then > | > >>> mixing "not" and "or" is not allowed, parentheses > are required > > 5 lines: 1 error > > > -- > > sam at gcc dot gnu dot org changed: > > What |Removed |Added > -------------------------------------------------------------- > -------------- > Status|UNCONFIRMED |RESOLVED > Resolution| |FIXED > Target Milestone|--- |4.3.0 > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34446 > > ------- You are receiving this mail because: ------- You are > on the CC list for the bug, or are watching someone who is. > You reported the bug, or are watching the reporter. >
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
re-opened pending additional comments.
Subject: Bug 34446 Author: charlet Date: Wed May 28 15:55:41 2008 New Revision: 136111 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136111 Log: 2008-05-28 Vincent Celier <celier@adacore.com> PR ada/34446 * gnat_ugn.texi: Document restriction introduced on 2007-04-20 in preprocessing expressions Modified: trunk/gcc/ada/gnat_ugn.texi
Documentation has been updated, so closing.