[Bug fortran/126940] [17 Regression] testsuite fails for libgomp.oacc-fortran/host_data-5.F90

"burnus at gcc dot gnu.org via Gcc-bugs" <[email protected]>
Newsgroups gmane.comp.gcc.bugs
Message-ID <[email protected]/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126940

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #5)
> We used to pack-in/unpack-out assumed-shape target arguments before the
> regressing patch. That was wrong because the argument may have pointers
> associated with it on entry, and pointers may be newly associated with it
> during  procedure execution.

It sound wrong in general – as there shouldn't be any reason to do so for
assumed-shape variables in general, unless there is a 'contiguous' argument...

Thanks for the enlightenment.


(In reply to Jerry DeLisle from comment #6)
> Is this an existing problem uncovered by my commit or caused by my commit. I
> have never tested with those options before, so did not see anything here.

I think we have two issues here:

(1) The testcase now fails because of the change. - Like several testcases, it
does not fail in all combinations (hardware, flags) but in some.
This issue can be fixed by changing expected output (dg-...) or adding² the
'contiguous' attribute to the dummy argument.


(2) Suboptimal code gen: we know that the memory must be contiguous¹ and,
hence, there shouldn't be a packed check. This can be fixed (cf. attachment
65371)³ by modifying the interface in the OpenACC module. - This also fixes the
issue (1).² 


¹This is technically required - and, hence, the spec requires the user to pass
only contiguous memory.

²Likely those variants require undoing the changes to the test file, added in
commit r17-3342-gf3943597388db4.

³There are some known bugs (fails if compiled as interfaces aren't
consistently) and omissions (not tested, .map file needs to be updated).

* * *

TODO: Decide for an option - and implement it.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.