Open olebole opened 4 years ago
I agree that the warnings are annoying and would prefer to stay within the standard. I've done several things to minimize this. E.g, the expansion of @assertEqual()
splits the Fortran arguments across lines with one argument per line.
Generally the longest lines in the generated code are the #line
semaphores that enable more useful line numbers in the original .pf source when the compiler generates errors.
I poked around quickly in some of my projects to see if I had any long lines, but did not find any. Would you be willing to post a small example (pre and post the parsing step). I'll be happy to use that to see if I can find any place to further trip the lines.
I am running into this with MAX_ASSERT_RANK=6 and gcc-9.1.0
@bd4 could you try editing ./cmake/GNU.cmake
and change the 512
on line 9 to be 0
? If that fixes it for you,
I'll push a fix.
I like sticking to the standard, but code generators are harder to fix than line-lengths. Besides, the next Fortran release is going to all extremely long lines and this issue will vanish.
Unfortunately that did not fix it, because the externals also set it to 512 and that seems to override the one set in top level cmake/GNU.cmake. Setting -DCMAKE_Fortran_FLAGS="-ffree-line-length-none"
on the cmake command line does work, so I have a workaround.
OK - I can propagate across the whole set of repos this weekend. (I hope.)
I released v4.2.2 today which includes unlimited line length for gfortran in all the dependencies. Please confirm whether this release fixes your issue.
Still failing for me in v4.2.2 with MAX_ASSERT_RANK=6:
/home/ci/src/pFUnit/build-gcc9/extern/fArgParse/extern/gFTL-shared/extern/gFTL/include/v1/templates/vector_impl.inc:449:132:
449 | __TYPE_MOVE(__GET(this%elements(i+1)),__GET(this%elements(i)))
|
Workaround -DCMAKE_Fortran_FLAGS="-ffree-line-length-none"
does still work.
In our project, I sometimes see the following error with gfortran:
While one could increase the allowed line length with
-ffree-line-length
, it would also be good to stick with the standard here.