This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, fortran] PR43851 Add _gfortran_error_stop_numeric
- From: Tobias Burnus <burnus at net-b dot de>
- To: Jerry DeLisle <jvdelisle at verizon dot net>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 19 May 2010 12:09:09 +0200
- Subject: Re: [patch, fortran] PR43851 Add _gfortran_error_stop_numeric
- References: <4BF33FF5.8070607@verizon.net>
On 05/19/2010 03:33 AM, Jerry DeLisle wrote:
> I hope this is the final on this patch. This patch avoids breaking
> ABI by creating two new functions stop_numeric_f2008 and
> pause_numeric_f2008 along with the error_stop_numeric. This allows
> the STOP and PAUSE statements to accept constant expressions and not
> use a value of -1 to signal an empty statement. Existing stop_numeric
> and pause_numeric are untouched.
>
> Regression tested on x86-64. OK for trunk? Test case below.
Side note: You are actually not using the symbol versioning but handle
the version incompatibility by a new function name (which is fine as it
also works on systems where no symbol versioning is available). Thus, so
far we have never really used version numbering ... ;-)
To the patch:
C850 (R857) The scalar-int-constant-expr shall be of default kind.
You do not check for this constraint; with -std=f2008 a standard conform
compiler has to reject it. One could allow it as GNU extension. Does it
work (by fold_convert) with -fdefault-integer-8 ?
Additionally, I think one should also check that the character
expression is of character(kind=1) type ("R857 stop-code is
scalar-default-char-constant-expr ...") as kind=4 is not handled.
The check:
+ if (e != NULL && e->expr_type != EXPR_CONSTANT)
+ {
+ gfc_error ("STOP code at %L must be a constant expression", &e->where);
Looks wrong: The standard also allows, e.g., EXPR_OP. I think, it is
better to use gfc_is_constant_expr; but even better: Replace
gfc_match_expr by gfc_match_init_expr.
The EXPR_CONSTANT check is not bad, however, as you could use it in a
-std=f2003 check to reject non-literals; maybe one can also use
expr->symtree->n.sym->attr.flavor == FL_PARAMETER to reject parameters
as well.
Otherwise, the patch looks fine.
Tobias