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]> 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]> 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]> > 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]> 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]> 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]> 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
Description: Binary data
