-
Notifications
You must be signed in to change notification settings - Fork 145
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
mkmf.template.intel.osx out of date #219
Comments
compilation errors also for the following assimilation_code/programs/obs_total_error/work/input.nml obs_type |
Preprocess error with intel 2021 mac: (one API) ifort (IFORT) 2021.2.0 20210228
Error does not occur on Cheyenne ifort (IFORT) 2021.2.0 20210228 |
This might be old netcdf + new intel:
|
branch build_fixes has the fixes for these |
For compiling openmpi and netcdf with intel on mac, ifort does not recognize libtool option lt_cv_ld_force_load=no CC=icc FC=ifort CXX=icpc .... ./configure --prefix=____ openmpi 4.0.4 an example of the errors:
|
pgi 20.4 Cheyenne. I think this is the \
|
try making line 138? if (thisc == '\\') then (compare to '\\' -- two consecutive backslashes. that works for me on ifort on my mac. ) edit: dang smart parsing in this comment. |
does the parse_args_mod still work with //? |
sadly, no. for now i think the compiler flag may be a better fix but it would be nice not to have to count on that. there may be a different way to make a character constant that it can compare against instead of the literal string '\' . at least i don't believe it's working. this is hard to test because so many parts of the system want to help you out with escaped characters. if running interactively, the shell reads the line and parses it before the program sees it, so it parses \\ into \ . if you run the program with stdin redirected to a file i don't know what the fortran 'read next line' routine does with quotes and escapes before it gets put into a character string variable. in the developer test directory, under utilities is a parse_args_test.in input file but it's very simplistic. also, the parse_args_test program is a bit broken in that it has 2 sections - one for testing white-space separated words from a line, and one for name=value pairs. but it wants control-d to end the first part of the test and move to the second. control-d stays in the input stream and ends both parts of the test. i will open an issue with making parse_args_test and the input file for the test more robust. |
pgi does not like the inflation flavors being integers.
- inf_flavor = 2, 0,
+ inf_flavor = '2', '0', |
for the backslash issue here is a small test program. i think using ACHAR() to set a character string of length 1 is the best solution here. i can make a branch and fix it if you want and beef up the parse tests at the same time. then you don't have to fool with compiler flags and it should be more portable. let me know. there may be other much higher priorities. in spite of the display, there are 2 backslashes in the BS1 variable. cat > bs_test.f90 <<'EOF' program bs_test ! if this program does not compile, comment out this next line character(len=1) :: BS2 character(len=20) :: bob ! this is a fortran intrinsic and should be portable bob = 'this is a string' ! if BS1 give errors comment out these 2 lines ! this should be portable print * end program |
Just so I am following, for 131 ! next character on line
132 thisc = argline(thisoff:thisoff)
133
134 if (debug) print *, 'thisoff, finaloff, inword, endword, thisc = ', thisoff, finaloff, &
135 inword, '"'//endword//'"', ' ', '"'//thisc//'"'
136
137 ! escaped chars - backslash prevents interpretation of next char
138 if (thisc == '\') then
139 ! move the remainder of the string over, overwriting the \ and
140 ! skipping the next char.
141 do i=thisoff, finaloff-1
142 argline(i:i) = argline(i+1:i+1)
143 enddo
144 argline(finaloff:finaloff) = ' '
145 finaloff = finaloff-1
146 thisoff = thisoff+1
147 cycle NEXTCHAR
148 endif And the problem is '\' is being treated by pgi like C where \ is an escape character So the code would become the following using achar(92) -138 if (thisc == '\') then
+138 if (thisc == achar(92)) then protip:
|
yes, the intent in get_args_from_string() is that in the input string backslash skips interpretation of the next char, whatever it is. so backslash followed by a newline or carriage return would put those chars into the output string. you could follow backslash with a quote to put the quote into the string instead of it being interpreted as the end of string. backslash followed by backslash (double backslash) in your input string would become a single backslash in the output. yes, pgi is treating the backslash in the source code like C, so it's turning quote backslash quote into 'quote to start a string, quote as the first character of that string' then erroring out because it thinks it is missing the closing quote. yes to how to use achar, although i might put it in a variable because if you search for double backslash (good luck) you will find several other places this occurs in the file. edit: updated to try to be more clear |
one more thought about get_args_from_string() - this routine takes a character string as input. the contents of that string had to be created by something. it could be a character constant in another program, it could be read from the terminal, it could be a variable from a namelist. whatever is reading the characters and putting them into the string before calling this routine may also try to interpret special characters like backslash and quotes. so this is tricky to test. |
note - got a dart support email about the backslash problem with PGI |
nvfortran also complains about \
|
in re-reading this thread i am reminded that ACHAR is a way to set a character variable without having an explicit backslash in the code and having to fool with compiler flags. i think the fix for this and issue #555 should be: character(len=1), parameter :: BACKSLASH = ACHAR(92) ... if (thisc == BACKSLASH) then |
🐛 Your bug may already be reported!
Please search on the issue tracker before creating a new issue.
Describe the bug
List the steps someone needs to take to reproduce the bug.
run quickbuild.csh with mkmf.template.intel.osx for mkmf.template
What was the expected outcome?
Compile DART executables without error
What actually happened?
For the production options, there is a remark
ifort: command line remark #10148: option '-vec-report0' not supported
For the debug options, the compilation errors out:
fortcom: Error: Unrecognized keyword "argument_checking" for option "-warn argument_checking"
Error Message
fortcom: Error: Unrecognized keyword "argument_checking" for option "-warn argument_checking
Which model(s) are you working with?
Version of DART
v9.10.3
Have you modified the DART code?
No
Build information
Please describe:
The text was updated successfully, but these errors were encountered: