Adjust volatile handling of the operand scanner

The GIMPLE SSA operand scanner handles COMPONENT_REFs that are
not marked TREE_THIS_VOLATILE but have a TREE_THIS_VOLATILE
FIELD_DECL as volatile.  That's inconsistent in how TREE_THIS_VOLATILE
testing on GENERIC refs works which requires operand zero of
component references to mirror TREE_THIS_VOLATILE to the ref
so that testing TREE_THIS_VOLATILE on the outermost reference
is enough to determine the volatileness.

The following patch thus removes FIELD_DECL scanning from
the GIMPLE SSA operand scanner, possibly leaving fewer stmts
marked as gimple_has_volatile_ops.

It shows we miss at least one case in the fortran frontend, though
there's a suspicious amount of COMPONENT_REF creation compared
to little setting of TREE_THIS_VOLATILE.  This fixes the FAIL
of gfortran.dg/volatile11.f90 that would otherwise occur.

Visually inspecting fortran/ reveals a bunch of likely to fix
cases but I don't know the constraints of 'volatile' uses in
the fortran language to assess whether some of these are not
necessary.

2021-08-09  Richard Biener  <rguenther@suse.de>

gcc/
	* tree-ssa-operands.c (operands_scanner::get_expr_operands):
	Do not look at COMPONENT_REF FIELD_DECLs TREE_THIS_VOLATILE
	to determine has_volatile_ops.

gcc/fortran/
	* trans-common.c (create_common): Set TREE_THIS_VOLATILE on the
	COMPONENT_REF if the field is volatile.

0 files changed, 0 insertions, 0 deletions