This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add -funknown-commons to work around PR/69368 (and others) in SPEC2006
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Alan Lawrence <alan dot lawrence at arm dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 19 Feb 2016 18:52:59 +0100
- Subject: Re: [PATCH] Add -funknown-commons to work around PR/69368 (and others) in SPEC2006
- Authentication-results: sourceware.org; auth=none
- References: <1455903754-12572-1-git-send-email-alan dot lawrence at arm dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Feb 19, 2016 at 05:42:34PM +0000, Alan Lawrence wrote:
> This relates to FORTRAN code where different modules give different sizes to the
> same array in a COMMON block (contrary to the fortran language specification).
> SPEC have refused to patch the source code
> (https://www.spec.org/cpu2006/Docs/faq.html#Run.05).
>
> Hence, this patch provides a Fortran-specific option -funknown-commons that
> marks such arrays as having unknown size - that is, NULL_TREE for both
> TYPE_SIZE and max value of TYPE_DOMAIN. DECL_SIZE is preserved for e.g. output
> in varasm.c.
>
> On AArch64, it fixes the 416.gamess issue, and allows compiling 416.gamess
> without the -fno-aggressive-loop-optimizations previously required (numerous
> other PRs relating to 416.gamess).
>
> I had to fix up a couple of places to deal with null TYPE_SIZE but in most cases
I think it is wrong to touch TYPE_SIZE/TYPE_SIZE_UNIT, IMHO it is much better just
to ignore DECL_SIZE/DECL_SIZE_UNIT in the selected few places
(get_ref_base_and_extent, the tree-ssa-loop-niters.c analysis) if the switch
is on, for selected decls (aggregates with flexible array members and other
similar trailing arrays, arrays themselves; all only if DECL_COMMON).
> a test for such was already present. (omp-low.c had too many so I gave up: in
> practice I think it's OK to just not use the new flag at the same time as
> -fopenmp).
That will just be an endless source of bugreports when people will report ICEs
with -funknown-commons -fopenmp (or -fopenacc, or -fcilkplus, or
-ftree-parallelize-loops, ...). For OpenMP the TYPE_SIZE* is essential, if
you privatize variables, you need to know how big variable to allocate etc.
Jakub