Make real128 optional #83
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I merged the kinds module, I didn't see you sent this. It will have to be rebased, sorry about that.
The fact that .f90 are not automatically preprocessed unfortunately means that we probably have to change all file extensions to .F90.
However, if there is a way to avoid the preprocessor, I think we should. In particular I think this PR is needed to make it work with Flang, correct?
What does Flang segfault on exactly? Can the qp be imported in the use statement? But it segfaults when it is used?
…On Sun, Jan 5, 2020, at 6:59 AM, Michael Hirsch, Ph.D. wrote:
this same concept is readily extended to other types. Based on the
current architecture, this seemed to be the most expedient way to make
a kind optional.
The only thing lacking is the Makefiles--how would you prefer to handle
having some files .F90 and some .f90. One way would be to just make
*all* the files .F90 as there is no harm in preprocessing every file,
and eventually all the files may have preprocessing anyway.
You can view, comment on, or merge this pull request online at:
#83
Commit Summary
* fence out real128 with preprocessor
* assume all tests are preprocessed .F90
File Changes
* *M* src/CMakeLists.txt
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-0> (11)
* *M* src/Makefile.manual
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-1> (4)
* *R* src/stdlib_experimental_io.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-2> (15)
* *R* src/stdlib_experimental_optval.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-3> (13)
* *M* src/tests/CMakeLists.txt
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-4> (2)
* *M* src/tests/Makefile.manual.test.mk
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-5> (4)
* *R* src/tests/ascii/test_ascii.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-6> (0)
* *M* src/tests/io/CMakeLists.txt
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-7> (2)
* *M* src/tests/io/Makefile.manual
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-8> (12)
* *R* src/tests/io/test_loadtxt.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-9> (2)
* *R* src/tests/io/test_loadtxt_qp.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-10> (0)
* *R* src/tests/io/test_open.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-11> (0)
* *R* src/tests/io/test_parse_mode.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-12> (0)
* *R* src/tests/io/test_savetxt.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-13> (0)
* *R* src/tests/io/test_savetxt_qp.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-14> (0)
* *R* src/tests/optval/test_optval.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-15> (46)
* *R* src/tests/test_always_fail.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-16> (0)
* *R* src/tests/test_always_skip.F90
<https://github.com/fortran-lang/stdlib/pull/83/files#diff-17> (0)
Patch Links:
* https://github.com/fortran-lang/stdlib/pull/83.patch
* https://github.com/fortran-lang/stdlib/pull/83.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#83?email_source=notifications&email_token=AAAFAWDLFMLLW5RP3Y4HK5LQ4HRULA5CNFSM4KC3LPZKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IECO7AQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWE6XJXUMRDJHXKG3ZTQ4HRULANCNFSM4KC3LPZA>.
|
|
Both PGI and Flang are broken in multiple ways for Fortran 2003. It might be best to just wait for them to fix themselves. However if there's any other non-universal kind we wish to add, it would currently be done perhaps like this, unless we refactored. E.g. if someone wants So while this PR may be unnecessary as is, something like this would need to be done to accomodate kinds not available in all systems. Or a refactor. |
|
So this PR fixes only part of the things wrong with Flang and PGI. The rest are due to improper implementation of Fortran 2003 in Flang/PGI. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this same concept is readily extended to other types. Based on the current architecture, this seemed to be the most expedient way to make a kind optional.
The only thing lacking is the Makefiles--how would you prefer to handle having some files .F90 and some .f90. One way would be to just make all the files .F90 as there is no harm in preprocessing every file, and eventually all the files may have preprocessing anyway.