[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Feb 4 11:24:00 GMT 2016


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #13)
> Seems get_ref_base_and_extent already has code for some cases of the
> flexible array members, but it has apparently some dead code in it that
> wasn't really meant to be dead (hint, this check is after a while (1) {
> switch (TREE_CODE (exp)) { ... } exp = TREE_OPERAND (exp, 0); } loop, thus
> break inside of the switch does not terminate the loop and the only way to
> get out of the loop is then goto done;, but that bypasses the stmt):
> 
> --- gcc/tree-dfa.c.jj	2016-01-21 08:58:44.000000000 +0100
> +++ gcc/tree-dfa.c	2016-02-04 11:18:40.061621702 +0100
> @@ -588,6 +588,7 @@ get_ref_base_and_extent (tree exp, HOST_
>        exp = TREE_OPERAND (exp, 0);
>      }
>  
> + done:
>    /* We need to deal with variable arrays ending structures.  */
>    if (seen_variable_array_ref
>        && maxsize != -1
> @@ -597,7 +598,6 @@ get_ref_base_and_extent (tree exp, HOST_
>  	      == wi::to_offset (TYPE_SIZE (TREE_TYPE (exp))))))
>      maxsize = -1;
>  
> - done:
>    if (!wi::fits_shwi_p (bitsize) || wi::neg_p (bitsize))
>      {
>        *poffset = 0;
> 
> But I guess even this doesn't help, while it will help poor man's flexible
> array members in C/C++,

get_ref_base_and_extent is supposed to properly detect trailing arrays in
case the size cannot be adjusted by the underlying decls size.  You don't
mention which goto done you think is broken here, the only relvant one is
that from the [TARGET_]MEM_REF case which sets maxsize to -1 itself.

I don't remember what the seen_variable_array_ref case after the while (1)
loop body was for.

Care to build a C testcase that goes wrong and that your patch would fix?

> in this Fortran case the problem is that there is
> COMMON /FMCOM/ X(1)
> in this TU, while
> COMMON /FMCOM / X(1000000)
> in some other TU, and get_ref_base_and_extent caps maxsize at DECL_SIZE -
> bit_offset (which is generally right, but Fortran COMMON is just weird).
> So, perhaps we want some flag on the Fortran COMMON decls that would be set
> on COMMON that ends with an array and would tell get_ref_base_and_extent
> (and other spots?) that accesses can be beyond end of the decl?

We certainly don't want to do that, it will pessimize all code that wants
max_size != -1 for commons.


More information about the Gcc-bugs mailing list