Re: problem building a GCJ-friendly GNU Crypto

[Roger Sayle <roger at eyesopen dot com>]

On 20 Sep 2003, Gabriel Dos Reis wrote:
> Geoff Keating <geoffk@geoffk.org> writes:
> | Roger Sayle <roger@eyesopen.com> writes:
> |
> | > I'm currently working on a patch to add an -fevaluation-order command
> | > line option to GCC, that sets a flag_evaluation_order variable that
> | > can be checked during constant folding to preserve left-to-right
> | > evaluation order of binary expressions.  This can then be enabled by
> | > default by the java front-end, which should help make libbackend.a
> | > more java friendly.
> |
> | Although I agree that it'd be better if the constant folder didn't do
> | things that break Java, I don't see why we need an extra command-line
> | flag for this.  GCC already has way too many command-line flags, and
> | this one seems to add particularly little value.
>
> seconded.  The backend should just know that it is evaluating bits
> from Java.  No?

Hi Geoff and Gaby,

I've just made a fairly disturbing discovery that I think may affect
your decisions on whether -fevaluation-order would be a generally useful
command line option.  It turns out that a lot of C/C++ code in general
circulation inappropriately depends upon left-to-right evaluation order
of binary operands.  Although the language standards explicitly state
that this evaluation order is unspecified/undefined, and may vary from
C compiler implementation to C compiler implementation, many packages
contain code such as "f(2) + g(3)" and silently require that "f" is
called before "g".

One such package is GCC itself!


The following patch to expr.c tweaks expand_operands to reverse the
order in which we expand the operands of binary arithmetic operations
and comparison operators.  In portable standards conformant C code it
should have no effect, but in GCC it breaks bootstrap on i686-pc-linux-gnu
almost immediately in stage3, i.e. the compiler is miscompiled.

Index: expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.585
diff -c -3 -p -r1.585 expr.c
*** expr.c	18 Sep 2003 15:05:53 -0000	1.585
--- expr.c	19 Sep 2003 13:39:36 -0000
*************** find_placeholder (tree exp, tree *plist)
*** 6535,6541 ****
     MODIFIER argument is as documented by expand_expr.  */

  static void
! expand_operands (tree exp0, tree exp1, rtx target, rtx *op0, rtx *op1,
  		 enum expand_modifier modifier)
  {
    if (! safe_from_p (target, exp1, 1))
--- 6535,6541 ----
     MODIFIER argument is as documented by expand_expr.  */

  static void
! expand_operands (tree exp1, tree exp0, rtx target, rtx *op1, rtx *op0,
  		 enum expand_modifier modifier)
  {
    if (! safe_from_p (target, exp1, 1))



I first tried the above patch while trying to trace the cause of
a bootstrap failure in a patch I'm developing that implements
Sethi-Ullman numbering to reduce register pressure and code size.

It turns out that operand ordering assumptions may also be responsible
for the current bootstrap failure of hppa64-hp-hpux11.11 as reported
in PR bootstrap/12358.  Although the code in tree_swap_operands_p
should be safe for C/C++ operator semantics, it does seem to be
triggering several obscure failures.


Note, that the two failures above that are caused by changing
evaluation order in different parts of GCC, might not even
reflect non-conformant source code.  Until these failures are
fully analyzed it might be an unrelated bug in GCC triggered
purely by generating RTL in a different order.



My current plan is, for the time being, to tweak tree_swap_operands_p to
only reorder constants, to fix the immediate bootstrap and java failures.
This will give me time to track down the evaluation order dependences
within GCC (for some platforms atleast).  Then finally I'd argue that
when these optimizations are reintroduced that we guard them by the
proposed -fevaluation-order command line option, so that legacy C code
(such as GCC 3.3) can still be compiled without problems.

In conclusion, I think it might be useful to allow user level control
over flag_evaluation_order, even though the primary use will be to
set the default to false for C-family languages and true for Java.


Gaby, Geoff, thoughts?

Roger
--