Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

running ifort on the gfortran testsuite

Janus
New Contributor I
1,664 Views

Hi,

as reported in another thread and on c.l.f. (https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/AIHRQ2kJv3c), I recently tried running different compilers (including ifort 18) on the gfortran testsuite, via a cmake script:

https://gist.github.com/janusw/17a294125d6956bea736a20c409e7881

My current results indicate that ifort 18 passes on 82% of all 1553 tests that were used, and fails on 281 tests. Although I'm sure that my methodology is not perfect (for details see the c.l.f. link and the script on github), and probably not all of  those 281 are actual issues with ifort, it is still quite easy to identify certain cases that very likely point to ifort bugs.

The first such category is regressions (cases that worked with earlier ifort versions, but fail with 18.1). Here's a list:

+     19 - aliasing_array_result_1.f90 (Failed)
+     22 - alloc_comp_assign_1.f90 (Failed)
+     70 - allocatable_scalar_10.f90 (Failed)
+    127 - array_constructor_45.f90 (Failed)
+    182 - associate_28.f90 (Failed)
+    347 - class_to_type_4.f90 (Failed)
+    398 - common_2.f90 (Failed)
+    811 - intrinsic_modulo_1.f90 (Failed)
+    901 - minloc_3.f90 (Failed)
+    967 - namelist_42.f90 (Failed)
+    968 - namelist_43.f90 (Failed)
+    1064 - pdt_13.f03 (Failed)
+    1322 - scalar_mask_2.f90 (Failed)
+    1398 - submodule_1.f08 (Failed)
+    1469 - typebound_operator_15.f90 (Failed)

 

The numbers represent an arbitrary test numbering, the files names correspond to the files in the gfortran test suite. In the worst case each of those files corresponds to a bug in ifort18, but I haven't checked them case by case.

On top of these there are several internal compilers errors (each of which by definition is a bug):

associate_20.f03(25): catastrophic error: **Internal compiler error: internal abort**
class_allocate_10.f03: catastrophic error: **Internal compiler error: segmentation violation signal raised**
class_allocate_8.f03: catastrophic error: **Internal compiler error: segmentation violation signal raised**
class_assign_1.f08(44): error #5270: Internal Compiler Error: symbol not a SYMTOK
parameter_array_init_4.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised**
spread_init_expr.f03: catastrophic error: **Internal compiler error: segmentation violation signal raised**
submodule_30.f08: catastrophic error: **Internal compiler error: segmentation violation signal raised**
submodule_31.f08(20): error #5270: Internal Compiler Error: symbol not a SYMTOK
submodule_31.f08(36): error #5270: Internal Compiler Error: symbol not a SYMTOK
typebound_operator_9.f03: catastrophic error: **Internal compiler error: segmentation violation signal raised**

 

And then there are 60 instances of runtime segfaults, which are also quite likely to be bugs. I won't list them all here, but my script can be easily used to get a complete list of all 281 failures. I think it would be great if some of the above bugs could be fixed for ifort 18.2.

Cheers,

Janus

 

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
1,657 Views

It may be that Intel is unable, for legal reasons, to access and use the gfortran test suite. Like many commercial software vendors, Intel has strict policies about use of open-source software. That's not to say it can't be done, but it's something that the Intel development team would have to discuss with Intel's lawyers first.

Intel, of course, has its own test suite. It's also likely that at least some of the gfortran tests assume incorrect behavior - I have seen that before (Intel's tests are not immune from that.)

It's good that you tried this. After getting approval, someone would have to perform triage on the tests - some might be more important than others. (For example, incorrect syntax, often found in so-called "negative tests", leading to an ICE is less important than an ICE from a correct program.)

View solution in original post

0 Kudos
35 Replies
Steve_Lionel
Honored Contributor III
443 Views

I've been looking at the standard and am torn between two possible interpretations of the words. I've sent this example to J3 and asked for comment. It boils down to the meaning of "the same derived type", when the standard doesn't indicate if it means same dynamic type or same declared type. If "dynamic type" is meant, the program is disallowed, but if "declared type" is meant, there is a plausible interpretation based on the description of how intrinsic assignment of derived types is performed.

0 Kudos
Steve_Lionel
Honored Contributor III
443 Views

Got my answer, and indeed I had overlooked a crucial word.

7.2.1.2(4) says (emphasis mine):

(4) if the variable is polymorphic it shall be type compatible with expr ; otherwise the declared types of the variable and expr shall conform as specified in Table 7.8,

Since the declared types DO conform (they are the same), the assignment is valid. Malcolm Cohen wrote,

"We very carefully wrote the semantics of intrinsic assignment to make this feature work!  We have no notation for selecting the declared part of a polymorphic variable – instead, the design is that in nonpoly contexts, the declared part is what gets used; this feature is part of that design.

So... The test program is valid and ifort is wrong in rejecting it. I can well understand how this mistake was made. I will report it to Support. (Issue 03232819.)

0 Kudos
FortranFan
Honored Contributor II
443 Views

Steve Lionel (Ret.) wrote:

Got my answer, and indeed I had overlooked a crucial word. ..

Without knowing exactly what was inquired of J3 and with what code snippet as the basis for the discussion, it's difficult to make sense of the feedback.

Looking at the standard, one can see there are two parts to the intrinsic assignment discussion:

First is the intrinsic assignment statement itself where, per section 7.2.1.2  of WD 1539-1 toward Fortran 2008, the declared types per Table 7.8 come into play and informs the processor on the conformance requirements of the statements.  So this allows the following:

   type :: t
   end type

   type, extends(t) :: e
   end type

   type(t) :: foo
   class(t), allocatable :: bar

   foo = bar !<--- Allowed per Table 7.8 in WD 1539-1

end

whereas the following is NOT allowed:

   type :: t
   end type

   type, extends(t) :: e
   end type

   type(t) :: foo
   type(e) :: bar

   foo = bar !<--- Not allowed

end

Upon compilation with gfortran,

p.f90:10:9:
    foo = bar
         1
Error: Can't convert TYPE(e) to TYPE(t) at (1)

The second part however deals with the execution of the assignment as addressed in section 7.2.1.3 on "Interpretation of intrinsic assignments".  Paragraph 1 is the relevant one for the code in question and the standard mentions, "Execution of an intrinsic assignment causes, in effect, the evaluation of the expression expr and all expressions within variable (7.1), the possible conversion of expr to the type and type parameters of the variable (Table 7.9), and the defi nition of the variable with the resulting value"  Thus the only conversion explicitly allowed with assignment is with Table 7.9 which only allows covers intrinsic type conversions in numeric expressions.  Note the standard does NOT mention anything about an *UPCASTING* conversion such as from type(e) to type(t) during actual execution of an intrinsic assignment.  The standard clearly disallows it in statements as shown above whereas one can complain the standard is not explicit enough on this on the execution side.

Now any instruction the standard does not explicitly permit a processor has to be free to reject.  This is why a processor such as Intel Fortran is well within its rights to throw a run-time exception with the instruction at line 12 of the code in Quote #20 given the instruction at line 10 that leads to a situation of having to "convert TYPE(e) to TYPE(t)" which the very same standard lets the processor disallow while processing an assignment statement.

J3, particularly Malcolm Cohen, has likely missed out on this aspect in their response, or it was not pointed out to them clearly enough in the inquiry.

0 Kudos
Steve_Lionel
Honored Contributor III
443 Views

FortranFan, I am puzzled. We were previously discussing your "snippet" in post 20, which is the first case you show in post 25. You previously claimed that this was NOT allowed, and you now seem to agree with me that it is allowed. This is the case I asked Malcolm about, and is what you claim the gfortran test program reduces to (I have not examined the gfortran test myself.)

Your second case here, where foo and bar are of different declared types, is clearly NOT allowed and I see no room for further discussion of it. It is interesting that gfortran complains about conversion - there is no place in the Fortran language where one derived type gets "converted" to another. One can have defined assignment of different derived types, but there is none in these examples. I would have preferred to see a message more like ifort's ("error #6197: An assignment of different structure types is invalid.   [BAR]"). I think gfortran's message about "can't convert" is misleading, as there is no situation where one CAN convert these.

What, exactly, do you think J3 has "missed"?

0 Kudos
FortranFan
Honored Contributor II
443 Views

Steve Lionel (Ret.) wrote:

FortranFan, I am puzzled. We were previously discussing your "snippet" in post 20, which is the first case you show in post 25. You previously claimed that this was NOT allowed, ..

What, exactly, do you think J3 has "missed"?

Steve,

Please read Quotes #20, #22, and #25 in this thread again carefully:

  • note I keep saying this is a run-time issue,
  • that the standard allows a compiler to process "foo = bar" intrinsic assignment even if the RHS is polymorphic but the LHS is not, as long as the declared types of the variable on the LHS is the same as the expr on the RHS,
  • however it is also incumbent upon the coder to ensure the types are compatible during the actual execution of the assignment,
  • the standard makes no mention of any implicit upcasting of derived types during an intrinsic assignment,
  • so at run-time if the RHS evaluates to type(e) which is not the type(t) of the variable on LHS, then a processor such as Intel Fortran is right to throw a run-time exception.  type(e) cannot be assigned to type(t), period.

This is what is happening in the code snippet in Quote #20 on account of the instruction on line 10, "allocate( e :: bar )".

This is what J3 has missed.

0 Kudos
Steve_Lionel
Honored Contributor III
443 Views

You missed the key point in Malcolm's response. In the case in question, the standard says to copy only those components which exist in the LHS, ignoring any components in the type extension. This is always possible because the declared types must match (and the compiler can check that.) See 7.2.1.3 paragraph 13.

0 Kudos
FortranFan
Honored Contributor II
443 Views

Steve,

No I didn't miss it.  I had taken a close look at the intrinsic assignment section before I even posted Quote #20.  Things just do not add up.  Section 7.2.1.3 paragraph 13 makes no reference to the "declared part" of RHS and it has no verbiage about "copy only those components".  Moreover this section has nothing about any "nonpoly contexts" in the response you quoted.  

0 Kudos
Steve_Lionel
Honored Contributor III
443 Views

I've explained it in my previous replies - I don't know how to do it any better. See post 24 first, then read 7.2.1.3p13 very carefully.

0 Kudos
FortranFan
Honored Contributor II
443 Views

Steve Lionel (Ret.) wrote:

I've explained it in my previous replies - I don't know how to do it any better. See post 24 first, then read 7.2.1.3p13 very carefully.

It's not a question of explaining further or differently, rather that the actual text in the standard simply does not jive with any of it.

Considering paragraphs 8, 9, thru' 11 in section 7.2.1.3 in the standard, if paragraph 13 can include something along the following lines, "For an intrinsic assignment statement where the variable is of derived type and the expr is an extension type of the variable, the assignment applies only to the components of the derived type of the variable." and/or a NOTE to go along with the paragraph (as can be seen with other aspects in the same section), then the comment in the J3 response, "We very carefully wrote the semantics of intrinsic assignment to make this feature work", would carry some credibility.

But as things said, readers who are not "in the loop" can get misdirected due to the sins of omission in the standard and it can then lead to implementation differences as seen with Intel Fortran.

0 Kudos
Steve_Lionel
Honored Contributor III
443 Views

The actual words in the standard are:

An intrinsic assignment where the variable is of derived type is performed as if each component of the variable were assigned from the corresponding component of expr using pointer assignment (7.2.2) for each pointer component, defined assignment for each nonpointer nonallocatable component of a type that has a type-bound defined assignment consistent with the component, intrinsic assignment for each other nonpointer nonallocatable component, and intrinsic assignment for each allocated coarray component.

Implementation problems most often occur when developers make assumptions rather than reading the words in the standard. J3 often debates as to whether to add explanatory notes, but I think there would be objections to adding one here that just restates the words already there. Notes can be handy if one has to put together pieces from several disparate parts of the standard.

0 Kudos
Steve_Lionel
Honored Contributor III
443 Views

Support tells me that the inappropriate run-time error for the code in post 20 is a regression from version 17.

0 Kudos
FortranFan
Honored Contributor II
443 Views

Steve Lionel (Ret.) wrote:

.. Implementation problems most often occur when developers make assumptions rather than reading the words in the standard. J3 often debates as to whether to add explanatory notes, but I think there would be objections to adding one here that just restates the words already there. ..

In the particular instance involving the code in Quote #20 of this thread as well as several other features introduced starting with Fortran 2003, it is simply not right to think most implementation problems occur because "developers make assumptions rather than reading the words in the standard".  On other forum on a somewhat related topic of derived types and OO paradigm, a most polite of a developer who really "groks" the standard wrote, "extracting the full story from the standard was not exactly straightforward." which is really a big deal coming from him.

In fact, it will be outright offensive in the case at hand to think the issue is that of a developer making an assumption with reading of the standard.  It's entirely the standard text that is failing the developers and in several ways too.  First the words such as in section 7.2.1.3 paragraph 13 are simply inadequate to convey the full message.  Secondly, but perhaps more importantly, the purported intent as indicated in the J3 response shown in Quote #24 goes against the very concepts put forth in the rest of the standard, those involving type safety and TKR conformance in operations including assignment, restricted and constrained implementation of OO which is supposedly performance-minded for technical and scientific computing.  In other words, even the developers with most familiarity with standard-speak of 1539-1 are susceptible to missing out on the feature stated in the J3 response in Quote #24.  The very same standard text that asks of a processor to follow conformance at the level of the same derived type in an intrinsic assignment would suddenly allow upcasting during execution just doesn't flow.  Such subtlety would definitely call for further explanation and illustration, but none of it can be seen in the standard.  And as can be seen from Quote #32, all suggestions and pleas from mere mortals are going to fall on deaf ears too; and this won't be the first time.  I have been seeing it for several years and matters now. 

Moreover the entire feature in question i.e., the one stated in the J3 response in Quote #24 is quite lame; it shows a rather poor understanding of the state of OO paradigm and the facilities in other languages that have become as popular for technical and scientific computing as Fortran or surpassed Fortran in several domains.  These other languages and their accompanying standards (wherever applicable) try to allow a processor to handle as much as possible at compilation time itself.  Meaning if there are things can be handled at run-time, then strive to process them during compilation itself with the consideration of early intervention to help developers catch potential problems earlier in their development cycle.  For the case at hand with the codes in Quote #20 and Quote #25, top multi-paradigm languages which also include support for OO allow direct upcasting because it has been established to be safe.  Contrast this with the second Fortran code snippet in Quote #25 where a conforming processor can be expected to barf at a similar statement.  Then when a similar action occurs during execution of code developed with these other languages, it only comes across as natural as to what the result would be.  With Fortran, it is not; at least for anyone who attempts to understand and not simply follow some rules blindly.  

But the problem with Fortran is what increasingly appears to be an entirely arbitrary set of rules particularly with facilities such as OO: one thing is allowed, another aspect however related will not be, with little bearing to any of the well-established computer science principles.  It is then accompanied by a standard text that is as obfuscating and dense as they come and an editor and a supporting cast who won't listen to anything outside of their own echo chamber.  It was mentioned in Quote #24 about "a crucial word" being overlooked and which was pointed out by the standard editor.  One can go through threads on this forum related to the standard over the last few years as well as comp-fortran-90 mailing list to find it is not an occasional ailment but a frequent symptom of a deeper affliction that is the standard text itself which has become largely captive to one person and that person's interpretation only.  And when that person says the standard text states exactly is meant and nary a word need be different, there is no one who pushes back.  "Blame the victim" mentality then prevails; it's only the developers and practitioners who are responsible for getting it wrong.  That is bad, really bad for Fortran.

0 Kudos
Juergen_R_R
Valued Contributor I
443 Views

Quote by FortranFan

 

One can go through threads on this forum related to the standard over the last few years as well as comp-fortran-90 mailing list to find it is not an occasional ailment but a frequent symptom of a deeper affliction that is the standard text itself which has become largely captive to one person and that person's interpretation only.  And when that person says the standard text states exactly is meant and nary a word need be different, there is no one who pushes back.  "Blame the victim" mentality then prevails; it's only the developers and practitioners who are responsible for getting it wrong.  That is bad, really bad for Fortran.

 

 [edited]

0 Kudos
Steve_Lionel
Honored Contributor III
443 Views

I spent 38 years doing both compiler development and compiler support. My observation was based on numerous cases throughout the decades. Certainly not all bugs have that origin, but some do. Developers are only human (so far...)

FortranFan, I have invited you more than once to attend J3 meetings or even to join the committee. We'd love to have more users (especially industry users, of which we have none at present) on the committee, and if you're an alternate it doesn't cost you anything (other than travel expenses and sometimes a $50 meeting fee). If you're interested in doing so, let me know - you could even join as my alternate (I'm a paying member now.) We meet next week in Vegas, after that is June 11-15 in Berkeley, CA. INCITS rules allow two meetings as a "visitor" before you'd be required to join the committee.

0 Kudos
FortranFan
Honored Contributor II
443 Views

Steve Lionel (Ret.) wrote:

.. meet next week in Vegas, after that is June 11-15 in Berkeley, CA. INCITS rules allow two meetings as a "visitor" before you'd be required to join the committee.

Thanks Steve, I'll see what I might be able to manage considering several factors, especially work schedule.

0 Kudos
Reply