In the bad old days, fortran constants could be modified. This led to difficult-to-find bugs for fortran tyros (like me) until the penny dropped. — Peter West [email protected] `“Again, the kingdom of heaven is like a merchant in search of fine pearls, who, on finding one pearl of great value, went and sold all that he had and bought it.”`
> On 4 Aug 2025, at 6:42 AM, Dave Allured - NOAA Affiliate via macports-users > <[email protected]> wrote: > > Correction. My OCD was bothering me, so I had to look deeper. The original > program is NOT legal fortran. The main program calls the function like this: > WRITE (*,*) ToBase(16, 26). Then the function attempts to modify the second > argument. But "26" is a constant, therefore not modifiable, and not legal > fortran. This explains the crash. Sorry I missed this earlier. > > The best fix is to make a writable copy of this argument inside the function > code. See attached corrected program. Please use this version in place of > the inlined version that I sent earlier. > > This is NOT a bug in gfortran, and should not be advertised as such. Offhand > I would say that any compiler such as flang that allows this, is not > following this fortran rule carefully, therefore is in itself deficient. > > > On Sat, Aug 2, 2025 at 3:16 PM Kenneth Wolcott <[email protected] > <mailto:[email protected]>> wrote: >> Hi Dave; >> >> Thank you so much for your analysis and providing an alternative >> that appears to work well. I have added this info to the Rosetta Code >> task talk page so that it might benefit the greater Fortran communty >> on Rosetta Code. >> >> Thanks again, >> Ken Wolcott >> >> On Sat, Aug 2, 2025 at 12:11 PM Dave Allured - NOAA Affiliate >> <[email protected] <mailto:[email protected]>> wrote: >> > >> > Ken, the short answer is, the test program seems to be valid fortran; and >> > both gfortran-mp-13 and gfortran-mp-14 have a bug. They can't handle the >> > function "ToBase" as written. >> > >> > I tested several convolutions: external rather than module function; >> > subroutine instead of function; etc. The first thing that worked was to >> > get rid of the function altogether, and inline the function code. >> > Attached is the working version. Please try it. >> > >> > Also try gfortran in MacPorts gcc-devel (i.e. GCC version 15) on the >> > original program. Also try other fortran compilers if you have anything >> > else besides flang. >> > >> > This may or may not be a known gfortran bug. It would be worth checking >> > GCC bug reports, or filing a new report. >> > >> > There is a second bug here: "Could not print backtrace: DW_FORM_line_strp >> > out of range". This is a failure in the GCC backtrace code. This was >> > disappointing because it concealed useful information that I expected from >> > your second test. This is a known GCC bug, therefore not worth pursuing >> > on this forum. Google search it if you care. I don't. >> > >> > Note that MacPorts gcc13, gcc14, and gcc-devel are all slightly out of >> > date. Updating any of these may or may not fix either the fortran >> > problem, or the backtrace problem. >> > >> > >> > On Fri, Aug 1, 2025 at 7:58 PM Kenneth Wolcott <[email protected] >> > <mailto:[email protected]>> wrote: >> >> >> >> Hi Dave; >> >> >> >> I have a new directory created by the debug commands, which I did not >> >> notice when I replied earlier. I have tar'd it up and compressed it >> >> and attached it. Hopefully it is useful. >> >> >> >> Thanks, >> >> Ken >> >> >> >> On Fri, Aug 1, 2025 at 6:19 PM Kenneth Wolcott <[email protected] >> >> <mailto:[email protected]>> wrote: >> >> > >> >> > Hi Dave; >> >> > >> >> > Thanks for the debugging info hint... >> >> > >> >> > Here's my new ./test_it.bash file: >> >> > >> >> > cat -n ./test_it.bash >> >> > 1 #!/bin/bash >> >> > 2 >> >> > 3 printf "\nUsing gfortran-mp-14 ...\n" >> >> > 4 # gfortran-mp-14 -x none -o ./non_decimal_radices_convert >> >> > ./non_decimal_radices_convert.f90 >> >> > 5 stem="./non_decimal_radices_convert" >> >> > 6 source="${stem}.f90" >> >> > 7 gfortran-mp-14 -g -O0 -fbacktrace -fcheck=all -Wall -x none -o >> >> > $stem $source >> >> > 8 >> >> > 9 if [ -f $stem ]; then >> >> > 10 $stem >> >> > 11 rm $stem >> >> > 12 fi >> >> > 13 >> >> > 14 if [ -f ./conversion.mod ]; then >> >> > 15 rm ./conversion.mod >> >> > 16 fi >> >> > 17 >> >> > 18 printf "\nUsing flang-mp-20...\n" >> >> > 19 /opt/local/bin/flang-mp-20 -o $stem $source >> >> > 20 if [ -f $stem ]; then >> >> > 21 $stem >> >> > 22 rm $stem >> >> > 23 fi >> >> > 24 >> >> > 25 if [ -f ./conversion.mod ]; then >> >> > 26 rm ./conversion.mod >> >> > 27 fi >> >> > >> >> > And here's the output: >> >> > >> >> > ./test_it.bash >> >> > >> >> > Using gfortran-mp-14 ... >> >> > 26 >> >> > >> >> > Program received signal SIGBUS: Access to an undefined portion of a >> >> > memory object. >> >> > >> >> > Backtrace for this error: >> >> > #0 0x104446083 in ??? >> >> > #1 0x104445357 in ??? >> >> > #2 0x1850b56a3 in ??? >> >> > >> >> > Could not print backtrace: DW_FORM_line_strp out of range in >> >> > .debug_line at 38 >> >> > #3 0x104310c67 in ??? >> >> > #4 0x104310c67 in ??? >> >> > #5 0x104310cc7 in ??? >> >> > ./test_it.bash: line 12: 97090 Bus error: 10 $stem >> >> > >> >> > Using flang-mp-20... >> >> > 26 >> >> > 1a >> >> > >> >> > Thanks, >> >> > Ken >> >> > On Fri, Aug 1, 2025 at 2:31 PM Dave Allured - NOAA Affiliate >> >> > <[email protected] <mailto:[email protected]>> wrote: >> >> > > >> >> > > This feels like subscript out of bounds. Please add standard >> >> > > gfortran debugging options before asking for deeper analysis. In >> >> > > particular, `-fcheck=all` will check for most subscripts out of >> >> > > bounds, including string indexing. It will then give intelligent >> >> > > legible diagnostics. >> >> > > >> >> > > `gfortran -g -O0 -fbacktrace -fcheck=all -Wall` >> >> > > >> >> > > >> >> > > On Fri, Aug 1, 2025 at 2:59 PM Kenneth Wolcott >> >> > > <[email protected] <mailto:[email protected]>> wrote: >> >> > >> >> >> > >> Hi; >> >> > >> >> >> > >> Weird error from a very short bash script involving gfortran and >> >> > >> flang >> >> > >> compile/execution... >> >> > >> >> >> > >> I'm trying to compile and execute a Rosetta Code task written in >> >> > >> Fortran: >> >> > >> >> >> > >> https://rosettacode.org/wiki/Non-decimal_radices/Convert#Fortran >> >> > >> >> >> > >> ***************************** >> >> > >> Here is my ./test_it.bash script: >> >> > >> >> >> > >> cat -n ./test_it.bash >> >> > >> 1 #!/bin/bash >> >> > >> 2 >> >> > >> 3 printf "\nUsing gfortran-mp-14 ...\n" >> >> > >> 4 gfortran-mp-14 -x none -o ./non_decimal_radices_convert >> >> > >> ./non_decimal_radices_convert.f90 >> >> > >> 5 if [ -f ./non_decimal_radices_convert ]; then >> >> > >> 6 ./non_decimal_radices_convert >> >> > >> 7 rm ./non_decimal_radices_convert >> >> > >> 8 fi >> >> > >> 9 >> >> > >> 10 printf "\nUsing flang-mp-20...\n" >> >> > >> 11 /opt/local/bin/flang-mp-20 -o ./non_decimal_radices_convert >> >> > >> ./non_decimal_radices_convert.f90 >> >> > >> 12 if [ -f ./non_decimal_radices_convert ]; then >> >> > >> 13 ./non_decimal_radices_convert >> >> > >> 14 rm ./non_decimal_radices_convert >> >> > >> 15 fi >> >> > >> >> >> > >> ***************************** >> >> > >> ***************************** >> >> > >> Here are the results: >> >> > >> >> >> > >> ./test_it.bash >> >> > >> >> >> > >> Using gfortran-mp-14 ... >> >> > >> 26 >> >> > >> >> >> > >> Program received signal SIGBUS: Access to an undefined portion of a >> >> > >> memory object. >> >> > >> >> >> > >> Backtrace for this error: >> >> > >> #0 0x102e520a7 >> >> > >> #1 0x102e51357 >> >> > >> #2 0x1850b56a3 >> >> > >> #3 0x102c7c997 >> >> > >> #4 0x102c7c997 >> >> > >> #5 0x102c7c9ef >> >> > >> ./test_it.bash: line 8: 93614 Bus error: 10 >> >> > >> ./non_decimal_radices_convert >> >> > >> >> >> > >> Using flang-mp-20... >> >> > >> 26 >> >> > >> 1a >> >> > >> ***************************** >> >> > >> >> >> > >> Was the executable generated by gfortran still executing when I >> >> > >> deleted it? >> >> > >> >> >> > >> Why is there a difference? >> >> > >> >> >> > >> Is there a bug here? >> >> > >> >> >> > >> Thanks, >> >> > >> Ken Wolcott > <radices.2.f90>
