Hi, Thomas! > > Unfortunately, even with that in place, I'm getting ICEs in LTO > streaming (that is, the test cases specifying -flto GCC's testsuite), > and also for trivial OpenACC code with -fopenacc, both for Fortran and > C code. This was fixed yesterday with exception of LTO which was not tested.
> As you said yourself (but what is of course totally fine at this early > development stage), the code is not yet mature: there are TODOs for > missing error checking, catching invalid usage of directives by users, > generally robustness, and so on. We shall address these as we continue > working on this. Sure, it's true. > A bit more "trivia": changes to contrib/gcc_update are missing for the > generated files in liboacc, and these should be using the same Autoconf > and Automake versions as the rest of GCC is. It will be fixed soon. > For gcc/tree.def and gcc/gimple.def I agree it makes sense to have > codes specific to OpenACC instead of, for example, shoehorning > OACC_PARALLEL into the existing OMP_PARALLEL (and then adding a flag to > it whether it is an OpenACC or OpenMP parallel statement...). The only > concept I can think of where it'd make sense to even there re-use the > existing OpenMP codes would be if there was a distinct "context" inside > which it's clear whether OMP_PARALLEL means an OpenACC or OpenMP > parallel construct. But that's probably more complex than simply > having separate codes. But, we can re-use > gcc/gimple.h:gimple_statement_omp as basis for OpenACC codes, avoiding > gcc/gimple.h:gimple_statement_acc, > gcc/gsstruct.def:gimple_statement_acc. There is a problem with this approach: gimple_statement_omp is based on gimple_statement_base, but we need gimple_statement_with_memory_ops_base for gimple_statement_acc. > > The new gcc/diagnose-gotos.c should probably re-use/be merged with the > existing omp-low.c:pass_diagnose_omp_blocks from which it duplicates. Sure, it's planned. > Your loop analysis and parallelization for OpenACC kernels constructs > seems to be based on tree-parloops.c code, which should also be > properly shared instead of duplicating it. > > In gcc/tree-inline.c:estimate_num_insns there is OpenACC cost > management not re-using OpenMP's (which might make sense to do?) -- but > I can't see acc_cost being initialized anywhere? Yes, these are planned too. Best wishes, Dmitri Botcharnikov
