https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201
--- Comment #14 from Jouko Orava <jouko.orava at iki dot fi> ---
(In reply to Steve Kargl from comment #13)
> I've tested your patch on i386-*-freebsd. It works.
Excellent, thank you.
> Do you have commit privilege for the source tree?
> The patch with a testcase is ok.
No, I'm just an occasional bughunter without fixed affiliations.
I'd appreciate it if you could commit the patch, with whatever message you find
most pertinent for this.
If it helps, here's a recap of my findings and the patch:
Test case fdp2.f90,
PROGRAM fdp2
IMPLICIT none
INTEGER, PARAMETER :: b128 = SELECTED_REAL_KIND(33, 1000)
REAL(KIND=b128) :: x(4)
x = 3.4_b128
PRINT *, KIND(x)
WRITE (*, "(4F10.3)") x(1:4)
END PROGRAM
will crash when compiled static using e.g.
gfortran -static -ggdb -W -Wall -O3 fdp2.f90 -o fdp2
The underlying problem is one of linkage; libgfortran/io/write_float.def uses
'__qmath_(quadmath_snprintf)' to use '__qmath_quadmath_snprintf()' whenever
weak symbols are supported. This causes 'quadmath_snprintf' to be marked as an
untyped weak dynamic symbol in the compiled binary. For the above test case,
this leads to a crash.
(I fail to see the logic in having libgfortran use a weak alias to access
'quadmath_snprintf()' in any case. It would make sense if
'__qmath_quadmath_snprintf()' was the actual symbol and 'quadmath_snprintf()'
its weak alias, but that is not the case here. It all really looks like a bad
thinko to me.)
The workaround is to explicitly mark the quadmath_snprintf() symbol as
undefined in the executable, at link time:
gfortran -static -ggdb -W -Wall -O3 fdp2.f90 -Wl,-uquadmath_snprintf -o
fdp2
This seems to be sufficient to resolve both the 'quadmath_snprintf()' symbol
and its weak alias, avoiding the crash.
The actual fix implemented in the patch is to have libgfortran always use the
'quadmath_snprintf()' symbol, and not '__qmath_(quadmath_snprintf)' in
libgfortran/io/write_float.def.
