Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Compilation issues with recent gfortran versions (6.4.1 and 7.3.1) #57

Open
pietrodelugas opened this issue Apr 26, 2018 · 4 comments · May be fixed by #74
Open

Compilation issues with recent gfortran versions (6.4.1 and 7.3.1) #57

pietrodelugas opened this issue Apr 26, 2018 · 4 comments · May be fixed by #74

Comments

@pietrodelugas
Copy link

There is a bug introduced in recent versions of gfortran (6.4.1, 7.3.1 ). These versions raise an internal compiler error when compiling FoX.

I made a bug report to gcc ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 ).

As far as I understand the bug is related to the usage of the len interface to compute the dimensions of the results of character type of many pure functions used for example in fox_m_fsys_format.F90 or in
m_dom_dom.F90.

A workaround that seems to work is to move the routines involved in the len interface at the bottom of their modules, but as explained by a note in the code this clashes with an explicit fortran specification and the modified source is not accepted as valid by other compilers.

A more stable workaround could be to move the len interface to a new module and import the interface.
@andreww
Copy link
Owner

andreww commented Apr 26, 2018

Thanks for this. So I should also add more gcc compilers to the mix of the CI. What fun!

I think the latest suggestion in the gcc bug report (just move the checkFmt function to the top of the file) will give us something that compiles with the latest gcc compilers (working around the bug) and is valid Fortran 2008. I say think because I am struggling a bit with:

If a specification expression in the specification-part of a module or submodule includes a reference to a generic entity, that generic entity shall have no specific procedures defined in the module or submodule subsequent to the specification expression.
(Paragraph 9 of section 7.2.11 of the Fortran2008 specification)

We don't reference the generic entity in checkFmt so this compiler bug workaround should be OK. But validating this for the Cray compiler (which seems to be the only compiler that enforces this constraint) would be useful. I wonder if NAG does this yet...

@pietrodelugas
Copy link
Author

Yes it works with gfortran and pgi. Much simpler that I was afraid.
There is also another function get_TextContent_len to move upwards, It is in dom/m_dom_dom.F90, should be done in the m4 file but I don't know how to do.
I will do more tests with intel and let you know

@butala
Copy link

butala commented Aug 31, 2018 •
edited
Loading

Just writing to say that I experienced the same problems as above with gfortran (7.3.0), moved the functions checkFmt and get_TextContent_len as suggested, and I was able to build successfully.

@andreww andreww mentioned this issue Feb 3, 2019
Open
@andreww
Copy link
Owner

andreww commented Mar 4, 2021

Sorry for the delay!

At least a partial fix to this is at libAtoms@1eef739 and/or ye-luo@e4d0479

Looks like the gfortran bug ended up getting fixed and the fix got back ported (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138) but I don't see a problem with these fixes. I'll pull together a patch

andreww added a commit that referenced this issue Mar 4, 2021
@andreww
Move checkFmt to top of file to avoid compiler bug
6739255 
Some versions of gfortran ICE with the function in
the body of the file. Defining it first seems to be
fine and should be valid Fortran 2008.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138
and #57
andreww added a commit that referenced this issue Mar 4, 2021
@andreww
Move getTextContent_len towards the top of the file
881e668 
Some versions of gfortran ICE with the function in
the body of the file. Defining it first seems to be
fine and should be valid Fortran 2008.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138
and #57

Do the actual move in the m4 and rebuild (we comit the
resulting F90 files so users don't need an m4 implementation
to build FoX). At the same time propogate a couple of changes
from the F90 back into other m4 files so we don't loose those
changes.
@andreww andreww linked a pull request Mar 4, 2021 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Function order andreww/fox
3 participants
@andreww @butala @pietrodelugas