This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gomp - equivalence for threadprivate data


Tim Prince wrote:
>>> I've attached a cut-down example of the way a well-known legacy
>>> application violates OpenMP standard.
>>>       
>> I had do add something like [...]
>>     
> I cut out too many COMMON blocks.  Those arrays were declared in
> additional labeled COMMON blocks, set as threadprivate.
> The Sun, Intel, and PGI compilers are used in production for this application.
>   
And as written, it also works with the Pathscale compiler and the free
Open64 compiler, i.e. of my 6 OpenMP supporting compilers, only gfortran
rejects it.

I filled a bugreport (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979)
to track this.

 * * *

Steve Kargl wrote:
> <rant>
> Gfortran (and OpenMP) should not be turned into a cess pool 
> of numerable many options because people are too lazy to 
> fix their code.  What's the point in having Standards and
> writing compilers that conform to those Standard, if gfortran
> continually provides options to violate those Standards.
> </rant>

Well, I think there are two user groups: Those who simply want to get --
well defined or not so well defined -- old code running. And those who
actively develop a code. I would like if the formers get some nice
legacy options with sparse warnings -- while the second should get a
strict checking with errors. As the compiler cannot automatically tell
those users apart, one needs to have some compromise (and some options).

I think it is OK that gfortran is quite strict - especially, if one can
override the settings by e.g. -std=legacy or -fno-range-check.
(Sometimes the error messages miss pointers to those options, which are
hard to find unless you know those.)

For the specific problem: Given that most (all?) other OpenMP compiler
support it, I think it would be useful to accept it as well. However, I
think having either an overrideable error message (-fopenmp-std=legacy
or similar) - or a default-enabled warning - should be used.

Regarding the legacy checking: Gfortran also supports the <tab>
character in $omp! contrary to the standard but in line with the other
compilers. One could add an error/warning there, but again one misses a
-fopenmp-std= option.

Tobias


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]