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