[ATfL] Stop copying Fortran OpenMP headers and modules for packaging

[pawosm-arm]

This copying has been introduced for the backward compatibility with ACfL and will soon collide with the ongoing work on standardizing the compiler-recognized place for flang modules and headers.

[kiranchandramohan]

I have a few questions here.
-> Aren't these modules and headers from the OpenMP runtime directory? Who placed them previously in include/flang? Should the fix also stop copying them from the OpenMP runtime directory to include/flang ?
-> Will this PR be submitted only when the upstream PR that changes the behaviour is merged?
-> Could you give a link to the upstream PR?

[pawosm-arm]

-> Aren't these modules and headers from the OpenMP runtime directory?

Their sources are there. But where they will land in the installation directory is up to the compiler, and this behavior changed with thime.

Who placed them previously in include/flang? Should the fix also stop copying them from the OpenMP runtime directory to include/flang ?

In the past, when classic flang has been a separate thing, fortran modules and headers for OpenMP were installed (make install) in the place where classic flang could find it. And it worked OK. In the new flang not enough attention has been paid to all of the corner cases of finding the runtime libs Fortran modules, so we started copying the OpenMP Fortran modules and FORTRAN70 header files to a general include directory, knowing that they were easily found in there. And it did the job for the two of ATfL releases.

The work currently happening upstream is aiming at sorting this out, but I suspect it will still not sort it correctly for the FORTRAN70's omp_lib.h header file, we'll see.

-> Will this PR be submitted only when the upstream PR that changes the behaviour is merged?

Yes, no point in doing it earlier.

-> Could you give a link to the upstream PR?

First it got merged: llvm/llvm-project#169638 but it has been quickly reverted a minutes after I had prepared my own PR to remedy the situation for our toolchain (see the upstream revert commit llvm/llvm-project@d233e78). I've noticed that and did not assign any formal reviewers to the change discussed here.