Skip to content

compilers-fortran: Fix preprocessing when fortran uses concat operator #14732

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.

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

AndrewLister-STFC
Copy link

Fixes #14695

This fixes preprocessing in fortran where code uses the concatenation operator. It also fixes preprocessing when compiling with ifx.

Note on the testing:

  • The test is currently failing as I don't now how to check the output of the compiled program via the project tests.
  • Is it possible to add ifx as a compiler for this test to avoid a regression on this?

Any help or pointers for these notes would be appreciated!

Copy link
Member

@dcbaker dcbaker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to use a printed message then you'll need a python wrapper to do the comparison. An easier approach would be to have the program exit 0 if you got the expected define, otherwise 1, since test() can easily test return codes.

Comment on lines +537 to +538
if self.language == 'fortran':
return self.get_preprocess_only_args()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we can't handle this via the language map, I think I'd prefer to just add an overriding implementation to the GnuFortran class that simply does return self.get_preprocess_only_args() than special case fortran here, unless that makes for lots of duplication in leaf classes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like GNULikeCompiler is a mixin for these classes. Happy to override in these classes if you prefer:

  • ClassicFlangFortranCompiler
  • LlvmFlangFortranCompiler
  • ElbrusFortranCompiler
  • GnuFortranCompiler
  • IntelFortranCompiler

I can test that this is an issue on the final 2 and verify it's fixed. For the other 3, I can leave them as they are or update without testing (unless that's done by CI?).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose this could be in the language map if we had something like:

gnu_lang_map = {
    'c': 'c',
    'cpp': 'c++',
    'objc': 'objective-c',
    'objcpp': 'objective-c++',
    'fortran': ''
}
def gnulike_default_include_dirs(compiler: T.Tuple[str, ...], lang: str) -> 'ImmutableListProtocol[str]':
    lang = gnu_lang_map.get(lang, '')
    if not lang:
        return []
    ...

and

        lang = gnu_lang_map.get(self.language, 'assembler-with-cpp')
        if not lang:
            return self.get_preprocess_only_args()
        return self.get_preprocess_only_args() + [f'-x{lang}']

this might be a bit more generalised though I don't know if it's better than just doing the override in the FortranCompiler subclasses... Let me know which to update to and I can make the change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Issues precompiling Fortran code due to -xassembler-with-cpp flag
2 participants