This is an archive of the discontinued LLVM Phabricator instance.

[flang] Fix internal error with DATA-statement style initializers
ClosedPublic

Authored by unterumarmung on May 4 2022, 4:29 AM.

Details

Summary

The code below causes flang to crash with an exception.
After fixing the crash flang with an internal error "no symbol found for 'bar'"
This change fixes all the issues.

program name
  implicit none
  integer, parameter :: bar = 1
  integer foo(bar) /bar*2/
end program name

Diff Detail

Event Timeline

unterumarmung created this revision.May 4 2022, 4:29 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMay 4 2022, 4:29 AM
unterumarmung requested review of this revision.May 4 2022, 4:29 AM
unterumarmung edited the summary of this revision. (Show Details)May 4 2022, 4:35 AM

Note to reviewers: this change doesn't fix the error itself, only the crash.
Currently (with this change applied), flang invocation with the given code gives the following error:

error: Semantic errors in a.f90
./a.f90:4:28: error: Internal: no symbol found for 'm_count'
    integer :: foo(m_count) /m_count*2/
                             ^^^^^^^

So, any pointers that could help solve this problem are appreciated!

kiranchandramohan requested changes to this revision.EditedMay 4 2022, 4:43 AM

For parser, semantics, runtime patches please add @klausler as the primary reviewer.

As far as this patch is concerned,
-> Isn't the ideal behaviour a parse/semantic error? Other compilers give the following error messages:
gfortran:

   5 | integer :: foo(m_count) /m_count*2/
      |                        1
Error: Syntax error in data declaration at (1)

intel/ifx and ifort

error #6669: The specification of this object is invalid.
integer :: foo(m_count) /m_count*2/

Classic Flang/nvfortran

F90-S-0034-Syntax error at or near / (abc.f90: 5)
  0 inform,   0 warnings,   1 severes, 0 fatal for name

-> Do you want to add the testcase along with the patch?

This revision now requires changes to proceed.May 4 2022, 4:43 AM

For parser, semantics, runtime patches please add @klausler as the primary reviewer.

I'm sorry, I'm fairly new to the Phabricator and LLVM and I didn't know that a reviewer can be primary. If I understand correctly, the primary reviewer is the first one in the list?

As far as this patch is concerned,
-> Isn't the ideal behaviour a parse/semantic error? Other compilers give the following error messages:

You're totally right! I accidently confused code snippets I used for testing.
The given snippet is not correct and should give a meaningful semantic error.
Yet, the following code should be compiled with no problems:

program name
  implicit none
  integer, parameter :: m_count = 1
  integer foo(m_count) /m_count*2/
end program name

Invocations of gfortran and nvfortran give no errors:

$ gfortran a.f90
$ nvfortran a.f90

But flang gives the error:

$ build/bin/flang-new a.f90
error: Semantic errors in a.f90
./a.f90:4:25: error: Internal: no symbol found for 'm_count'
    integer foo(m_count) /m_count*2/
                          ^^^^^^^

-> Do you want to add the testcase along with the patch?

If this patch remains fixing only the crash, I do not think that test case is needed. I'm not sure that adding a test case for internal compiler error is ok. If it is, I'll add the test case.
If I fix the error fully, I'm going to add the test case. Maybe the full solution will be done in another patch. I'd like to gather opinions how I should address this.

What do you think?

-> Do you want to add the testcase along with the patch?

If this patch remains fixing only the crash, I do not think that test case is needed. I'm not sure that adding a test case for internal compiler error is ok. If it is, I'll add the test case.
If I fix the error fully, I'm going to add the test case. Maybe the full solution will be done in another patch. I'd like to gather opinions how I should address this.

What do you think?

First, the DATA-statement style initializer syntax is a legacy feature; the use of the "::" probably disables it in other compilers.

I think you should try to do more than patch just the crash. This program should compile.

And you don't have to add me as "primary reviewer". I'm swamped.

Fixed internal error, added test case, rebased

Fixed a typo in the commit message

unterumarmung retitled this revision from [flang] Fix crash on non-standard compliant code to [flang] Fix internal error with DATA-statement style initializers.May 5 2022, 7:10 AM
unterumarmung edited the summary of this revision. (Show Details)

I think you should try to do more than patch just the crash. This program should compile.

I fixed the issue, could you please take a look?

And you don't have to add me as "primary reviewer". I'm swamped.

Ok. Is there anyone less busy I could request review from for my changes in parsing and semantics?

Fixed newline at end of file for the test case

klausler accepted this revision.May 5 2022, 7:35 AM

@kiranchandramohan, could you please take a look?

Apologies for the confusion with the reviewers. Please feel free to add reviewers from this list. Depending on time, and familiarity with the area one or more will respond. Thanks for the contribution.

I have a couple of minor comments.

flang/lib/Semantics/data-to-inits.cpp
320–323

Nit: Is this empty line required?

flang/test/Semantics/resolve111.f90
2

I think it would be better to have a debug-dump-symbols test for this (Only test what is in the MainProgram, particularly the init portion of the foo line)
!RUN: %flang_fc1 -fdebug-dump-symbols %s | FileCheck %s

Address review comments, rebase

unterumarmung marked 2 inline comments as done.May 6 2022, 3:45 AM

@kiranchandramohan, I addressed your review comments, thank you!
If you are ok with the changes, could you please remove "request changes" on your review?

kiranchandramohan accepted this revision.May 6 2022, 3:55 AM

LGTM. Thanks.

This revision is now accepted and ready to land.May 6 2022, 3:55 AM