c++/4884 g++ 3.x problem with -fvolatile

Ashif S. Harji asharji@plg2.math.uwaterloo.ca
Sun Mar 24 18:18:00 GMT 2002


We posted a bug report a few months ago about an internal compiler error
that occurs with g++ when the -fvolatile flag is used.  For details, see:

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4884&database=gcc

After some preliminary investigation, we have narrowed down the problem to
a conflict between a couple of patches.  In order to get enough
information to resolve the problem, we are posting this message and
copying the authors of the two patches.  See:

http://gcc.gnu.org/ml/gcc-patches/2001-01/msg00069.html

http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01506.html


The problem that occurs is that the 'operator new' call is treated as a
static member call. The following code occurs towards the end of the
build_new_method_call function in the file cp/call.c,

      if (TREE_SIDE_EFFECTS (instance))
	call = build (COMPOUND_EXPR, TREE_TYPE (call), instance, call);

This results in the call being a COMPOUND_EXPR when the -fvolatile flag is
used.  However, when this call gets back to the build_new_1 funciton in
cp/init.c it fails on the following asserts:

  my_friendly_assert (TREE_CODE (alloc_call) == CALL_EXPR, 20000521);
  t = TREE_OPERAND (alloc_call, 0);
  my_friendly_assert (TREE_CODE (t) == ADDR_EXPR, 20000521);
  t = TREE_OPERAND (t, 0);
  my_friendly_assert (TREE_CODE (t) == FUNCTION_DECL, 20000521);

because it is assumed that the call is a CALL_EXPR, etc.

Furthermore, these asserts are assumed to be true later on when the
build_op_delete_call occurs:

      /* placement is a CALL_EXPR around an ADDR_EXPR around a function.  */

      /* Extract the function.  */
      argtypes = TREE_OPERAND (TREE_OPERAND (placement, 0), 0);


However, when the -fvolatile flag is not used, the call is a CALL_EXPR and
everything works fine.

Perhaps, the first question we need answered is whether it is valid for
the 'operator new' call to be a COMPOUND_EXPR when -fvolatile is used.

Any assitance would be appreciated.

thanks,
ashif.



More information about the Gcc-bugs mailing list