Re: [PATCH] Fix driver handling of multiple -ftree-parallelize-loops=<n> options (PR driver/69805)

[Tom de Vries <Tom_deVries at mentor dot com>]

On 17/02/16 17:07, Sandra Loosemore wrote:
> On 02/17/2016 12:14 AM, Tom de Vries wrote:
> > Here's the documentation entry for the gt spec function (I forgot to add
> > it when introducing the function), using the new semantics.
> >
> > Copy-pasting from the resulting .info viewed in emacs for a
> > human-readable version:
> > ...
> >       'gt'
> >            The 'gt' (greater than) function takes one or more arguments.
> >            It returns either NULL or the empty string.  If it has one
> >            argument, it returns NULL.  If it has two arguments, it
> >            compares them: it returns the empty string if the first
> >            argument is greater than the second argument, otherwise it
> >            returns NULL.  If it has more than two arguments, it behaves
> >            as if only the last two arguments were passed.  It can be used
> >            f.i. as 'S' in a spec directive %{'S':'X'}: if 'S' is NULL,
> >            the empty string is substituted, and if 'S' is the empty
> >            string, 'X' is substituted.
> >
> >                 %:gt(%{fsome-option-value=*:%*} 1)
> > ...
> >
> > OK for stage4 trunk?
>
> I'm not an expert on spec strings....  but from a user perspective, what
> is the difference between "NULL" and "the empty string"?  The other spec
> escapes are documented in terms of pattern substitutions at the point
> where the escape appears in the spec string.

Hi Sandra,

yes, that's a good point.


I.

The first time we used this type of "NULL"/"empty string" distinction 
was for the sanitize spec function, introduced here ( 
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0016189f560b1dc86734d36826be891562da1c46;hp=e9d78f5ab2b5a1cc50cd20ca2da199f83258b153 
) in the ubsan branch, which was later merged to trunk at r202113 (patch 
submitted here: https://gcc.gnu.org/ml/gcc-patches/2013-07/msg00510.html ).

The commit adds this text to 'The Specs Language' bit in gcc.c:
...
 %{%:function(args):X}
         Call function named FUNCTION with args ARGS.  If the function
         returns non-NULL, then X is substituted, if it returns
         NULL, it isn't substituted.
...

I suppose we should document this behavior first in invoke.texi, and we 
could choose user-oriented names for the NULL/non-NULL distinction.


II.

Furthermore, the implementation seems to be inconsistent with the 
specification. If I modify greater_than_spec_func to return non-NULL, 
but not the empty string:
...
@@ -9800,7 +9803,7 @@ greater_than_spec_func
   gcc_assert (converted != argv[2]);

   if (arg > lim)
-    return "";
+    return "true";

   return NULL;
 }
...

I get:
...
$ gcc hello.c -O2 -ftree-parallelize-loops=2
gcc: fatal error: switch ‘true’ does not start with ‘-’
compilation terminated.
...

This (otherwise untested) patch fixes that:
...
@@ -6068,10 +6068,13 @@ handle_spec_function
   /* p now points to just past the end of the spec function
      expression.  */

   funcval = eval_spec_function (func, args);
-  if (funcval != NULL && do_spec_1 (funcval, 0, NULL) < 0)
-    p = NULL;
   if (retval_nonnull)
     *retval_nonnull = funcval != NULL;
+  else
+    {
+      if (funcval != NULL && do_spec_1 (funcval, 0, NULL) < 0)
+       p = NULL;
+    }

   free (func);
   free (args);
...


III.

So, a spec function can return:
a: NULL,
b: empty string, and
c: non-empty string.

In the context of evaluating a spec function as a condition, NULL 
designates false, empty string designates true and if we fix the problem 
mentioned at II then also non-empty string designates true, so:
- false (a)
- true (b, c)

In the context of evaluating a spec function for the resulting string, 
NULL means an empty string (AFAICT), just like an empty string, so we have:
- empty (a, b)
- non-empty (c)

I think that's going to be hard to explain to the user.

It seems originally ( 
https://gcc.gnu.org/ml/gcc-patches/2013-06/msg01100.html ) the 
empty/non-empty string distinction was proposed for the semantics of 
'%{%:function(args):X}'. Perhaps we should consider a rewrite using that 
distinction.

Thanks,
- Tom