Bug 52531 - [OOP] Compilation fails with polymorphic dummy argument and OpenMP
[OOP] Compilation fails with polymorphic dummy argument and OpenMP
Status: NEW
Product: gcc
Classification: Unclassified
Component: fortran
4.7.0
: P3 enhancement
: ---
Assigned To: Not yet assigned to anyone
: openmp, rejects-valid
: 55282 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-08 14:05 UTC by kaladhorn
Modified: 2013-07-24 07:29 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-03-17 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kaladhorn 2012-03-08 14:05:08 UTC
The following code does not compile:

--
module test_mod
  type, public :: test_type
  end type
contains
  subroutine foo(bar)
    type(test_type) :: bar
!$omp parallel default(none) shared(bar) ! Compiles if one removes default(none)
    call question(bar)
!$omp end parallel
  end subroutine
  subroutine question(var)
    class(test_type), intent(in) :: var ! Compiles if one replaces class by type
  end subroutine
end module
--

The error message is:
‘__vtab_test_mod_Test_type’ not specified in enclosing parallel

This was reproduced with gfortran 4.6 (gcc version 4.6.3 (GCC) ) and 4.7 (gcc version 4.7.0 20120121 (experimental) (GCC) ) on x86_64-unknown-linux-gnu .
Comment 1 Jakub Jelinek 2012-03-08 15:11:03 UTC
OpenMP 3.1 or earlier releases don't cover Fortran 2003 nor 2008, so what you are trying to compile is not valid.
Comment 2 kaladhorn 2012-03-08 19:33:24 UTC
(In reply to comment #1)
> OpenMP 3.1 or earlier releases don't cover Fortran 2003 nor 2008, so what you
> are trying to compile is not valid.

hmm that's true, I did not think of it that way. My apologies, then.
However, I think a proper error message would be nice.

Out of curiosity, would there be a technical issue in this case?
It sure seemed natural to me.

Thanks!
Comment 3 janus 2012-06-08 13:00:53 UTC
(In reply to comment #2)
> Out of curiosity, would there be a technical issue in this case?
> It sure seemed natural to me.

AFAICS there should not be any huge issues. One might consider to implement this as an extension.
Comment 4 kaladhorn 2012-06-08 18:46:11 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > Out of curiosity, would there be a technical issue in this case?
> > It sure seemed natural to me.
> 
> AFAICS there should not be any huge issues. One might consider to implement
> this as an extension.

If it does not hurt, I think it would be a good thing.

As far as I am concerned, I engineered around it, as it is really an edge case we do not want to rely on.
It arguably makes some code uglier, though.
Comment 5 janus 2012-06-09 09:34:53 UTC
Note: Apart from the two workarounds mentioned in the test case, there is one other possibility to make it work, namely to make 'bar' also polymorphic (like the dummy 'var'), e.g.:

class(test_type), allocatable :: bar
Comment 6 janus 2013-03-17 17:06:41 UTC
*** Bug 55282 has been marked as a duplicate of this bug. ***
Comment 7 janus 2013-03-17 17:09:12 UTC
Note that OpenMP 4.0 RC2 still lists polymorphic entities as unsupported, cf. http://openmp.org/wp/openmp-specifications/
Comment 8 janus 2013-07-24 07:29:42 UTC
(In reply to janus from comment #7)
> Note that OpenMP 4.0 RC2 still lists polymorphic entities as unsupported,
> cf. http://openmp.org/wp/openmp-specifications/

Update: OpenMP has been officially released by now, but polymorphic variables continue to be unsupported.