8000 Add support for same compilers as Fortran version to Haskell version by everythingfunctional · Pull Request #289 · fortran-lang/fpm · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add support for same compilers as Fortran version to Haskell version #289

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
Merged
merged 7 commits into from
Dec 14, 2020
Merged

Add support for same compilers as Fortran version to Haskell version #289

merged 7 commits into from
Dec 14, 2020

Conversation

everythingfunctional
Copy link
Member

This adds support for the same compilers as is currently in the Fortran version to the Haskell version. I would appreciate if anyone with access to these compilers to do some testing.

@urbanjost
Copy link
Contributor

Might have left something set I did not intend to, but everyt application I build I get a warning message about MPI even in programs with no MPI calls when I use ifort; no problems with nvfortran or gfortran so far. Does not occur with the Fortran version with same
compilers. So just giving a heads-up. If aligning the two versions I missed not being able to set a default compiler with $FPM_COMPILER as with ffpm. I want to pull down the new OneAPI version as it is supposed to be fully f2018 and something I particularly want when doing this type of testing in particular is the intrinsic COMPILER_OPTIONS(); which this version of ifort does not have. Still testing but except for this message ifort, nvfortran, and gfortran look good on a Red Hat 8 box.


 M_calculator]$ fpm run --compiler ifort
[0] MPI startup(): I_MPI_CAF_RUNTIME environment variable is not supported.
[0] MPI startup(): Similar variables:
         I_MPI_THREAD_RUNTIME
[0] MPI startup(): To check the list of supported variables, use the impi_info utility or refer to https://software.intel.com/en-us/mpi-library/documentation/get-started.
 Enter expressions or "funcs" or "dump"

error===>*calculator* input line was empty
3/4
0.75 = 3/4
.
[urbanjs@localhost M_calculator]$ ifort --version
ifort (IFORT) 19.1.3.304 20200925
Copyright (C) 1985-2020 Intel Corporation.  All rights reserved.

@everythingfunctional
Copy link
Member Author

Thanks for testing @urbanjost . I may try out the Intel oneAPI on a Linux virtual machine soon. I haven't been very impressed with it on MacOS so far. ifx isn't available on Mac, and coarray features aren't available on Mac.

@LKedward
Copy link
Member
LKedward commented Dec 10, 2020 •
edited
Loading

Thanks @everythingfunctional, I've also tried with Intel fortran.
I get linker errors when using ifort (19.1.0.166, Ubuntu) with undefined references to various MPI routines.

I think -coarray=single in ifort is not the same as -fcoarray=single in gfortran: in gfortran, the single mode links against a "single-image library consisting of stubs", whereas I think ifort is still generating backend code (MPI) but for just one image, hence the linker errors.

Perhaps it's possible to link to the same caf_single stubs library with Intel, but this may not be a good solution.
Otherwise it looks like only gfortran can support coarray code without generating a coarray executable.

@LKedward
Copy link
Member

Not needed for this PR, but worth noting that submodule support in Haskell fpm breaks with ifort (and possibly other compilers) due to various different smod naming conventions.

@everythingfunctional
Copy link
Member Author

I see. That is disappointing, on both fronts. Is there proper submodule support in the Fortran version yet?

@LKedward
Copy link
Member

Is there proper submodule support in the Fortran version yet?

Yes there's support for submodules, though it's more rudimentary than the Haskell version since the implementation is ignorant of .mod/.smod files.

LKedward
LKedward approved these changes Dec 10, 2020
View reviewed changes
Copy link
Member
@LKedward LKedward left a comment

Choose a reason for hiding this comment

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

For the discussed reasons, it seems we should remove -coarray from the ifort configuration altogether. After removing -coarray=single I tested several packages successfully with ifort.

I don't have any of the other compilers to test currently, but everything else looks good with this PR 👍

@everythingfunctional
Copy link
Member Author

Ok, I'll pull the -coarray option out. Thanks for the review.

@urbanjost
Copy link
Contributor

Odd. A few replies I made seem to be missing. Essentially I agree both packagers should remove coarray from the Intel compiler, especially because ifort allows users to add options in other ways, particularly with config files; although this allows users to "corrupt" the options used by a debug or release version. Things have progressed enough we need a TOML-based method for specifying builds and custom options, especially for coarrays/OpenMP/MPI or we will limit what can easily be a package. The h-fpm version allows for custom make scripts which has allowed me to do special builds and link in external libraries like X11, etc. So we need a solution for the capability especially in f-fpm but I concur it has to go out of the defaults for now.

@everythingfunctional
Copy link
Member Author

With the majority approval and nothing else appearing to be broken, I'm going to go ahead and merge.

@everythingfunctional everythingfunctional merged commit c2e043b into fortran-lang:master Dec 14, 2020
@everythingfunctional everythingfunctional deleted the bootstrap_compiler_support branch December 14, 2020 14:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@LKedward LKedward LKedward approved these changes

@awvwgk awvwgk awvwgk approved these changes

@urbanjost urbanjost urbanjost approved these changes

@arjenmarkus arjenmarkus Awaiting requested review from arjenmarkus

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@everythingfunctional @urbanjost @LKedward @awvwgk
0