[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #16 from Steve Kargl  ---
On Sat, Dec 05, 2015 at 08:13:25AM +, jouko.orava at iki dot fi wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201
> 
> --- Comment #14 from Jouko Orava  ---
> (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.
> 

OK, I'll commit the patch for you after a little more testing.
Thanks for tracking this bug down.

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #17 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Dec  5 18:12:26 2015
New Revision: 231320

URL: https://gcc.gnu.org/viewcvs?rev=231320=gcc=rev
Log:
2015-12-05  Juoko Orava 

PR fortran/50201
* io/write_float.def: Avoid marking quadmath_snprintf as an untyped
weak reference, which fixing linking with -static.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #15 from Dominique d'Humieres  ---
> The patch with a testcase is ok.

Beware that some platforms don't support -static, e.g., darwin.

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #18 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Dec  5 23:33:23 2015
New Revision: 231323

URL: https://gcc.gnu.org/viewcvs?rev=231323=gcc=rev
Log:
2015-12-05  Juoko Orava 

PR fortran/50201
* io/write_float.def: Avoid marking quadmath_snprintf as an untyped
weak reference, which fixing linking with -static.

Modified:
branches/gcc-5-branch/libgfortran/ChangeLog
branches/gcc-5-branch/libgfortran/io/write_float.def

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.3

--- Comment #19 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch. Jouko thanks for the patch.  Bill thanks for the
bug report, sorry that it so long to fix.

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[jouko.orava at iki dot fi]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #14 from Jouko Orava  ---
(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.

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #10 from Dominique d'Humieres  ---
Any progress?

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[jouko.orava at iki dot fi]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #11 from Jouko Orava  ---
Created attachment 36931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36931=edit
Untested patch to fix the bug.

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[jouko.orava at iki dot fi]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #12 from Jouko Orava  ---
I suspect the bug occurs because libgfortran uses the weak symbol version of
quadmath_snprintf(). Unfortunately, I don't have the resources to verify this
in the near future.

If you could recompile gcc/gfortran with the attached patch applied, and check
my test case in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201#c9 I would
be very grateful.

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #13 from Steve Kargl  ---
On Sat, Dec 05, 2015 at 12:26:14AM +, jouko.orava at iki dot fi wrote:
> I suspect the bug occurs because libgfortran uses the weak symbol version of
> quadmath_snprintf(). Unfortunately, I don't have the resources to verify this
> in the near future.
> 
> If you could recompile gcc/gfortran with the attached patch applied, and check
> my test case in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201#c9 I would
> be very grateful.
> 

I've tested your patch on i386-*-freebsd.  It works.

Do you have commit privilege for the source tree?
The patch with a testcase is ok.

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[jouko.orava at iki dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

Jouko Orava jouko.orava at iki dot fi changed:

   What|Removed |Added

 CC||jouko.orava at iki dot fi

--- Comment #6 from Jouko Orava jouko.orava at iki dot fi ---
Confirmed. The second test case still segfaults when run if compiled with
-static in Linux 3.8.0 x86_64 kernel on Ubuntu 12.04.4 LTS, using gfortran
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5).

When gdb is run on the static binary, it warns that no loadable sections found
in added symbol-file system-supplied DSO at 0x77ffd000.

gdb backtrace:

(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x0040bb83 in write_float ()
#2  0x00404d27 in formatted_transfer ()
#3  0x0040318a in _gfortran_transfer_array ()
#4  0x004013a5 in MAIN__ () at fdp1.f90:4
(gdb) info registers
rax0x11
rbx0x6fb6e87321320
rcx0x2739
rdx0x4be7124974354
rsi0x3149
rdi0x7fffdb80140737488345984
rbp0x280x28
rsp0x7fffdab80x7fffdab8
r8 0x00
r9 0x00
r100x00
r110xb333197032483697459
r120x7fffddc0140737488346560
r130x7fffdb80140737488345984
r140x00
r150x00
rip0x00
eflags 0x10202[ IF RF ]
cs 0x3351
ss 0x2b43
ds 0x00
es 0x00
fs 0x6399
gs 0x00

The disassembly of the write_float () up to the segmentation fault:

0040ba60 write_float:
  40ba60:   41 57   push   %r15
  40ba62:   41 56   push   %r14
  40ba64:   41 55   push   %r13
  40ba66:   41 54   push   %r12
  40ba68:   49 89 fcmov%rdi,%r12
  40ba6b:   55  push   %rbp
  40ba6c:   bd 28 00 00 00  mov$0x28,%ebp
  40ba71:   53  push   %rbx
  40ba72:   48 89 f3mov%rsi,%rbx
  40ba75:   48 81 ec 08 01 00 00sub$0x108,%rsp
  40ba7c:   44 8b 2emov(%rsi),%r13d
  40ba7f:   64 48 8b 04 25 28 00mov%fs:0x28,%rax
  40ba86:   00 00 
  40ba88:   48 89 84 24 f8 00 00mov%rax,0xf8(%rsp)
  40ba8f:   00 
  40ba90:   31 c0   xor%eax,%eax
  40ba92:   41 83 fd 1e cmp$0x1e,%r13d
  40ba96:   74 0a   je 40baa2 write_float+0x42
  40ba98:   41 83 fd 1c cmp$0x1c,%r13d
  40ba9c:   0f 85 06 05 00 00   jne40bfa8 write_float+0x548
  40baa2:   83 f9 08cmp$0x8,%ecx
  40baa5:   0f 84 4a 05 00 00   je 40bff5 write_float+0x595
  40baab:   0f 8e 6f 08 00 00   jle40c320 write_float+0x8c0
  40bab1:   83 f9 0acmp$0xa,%ecx
  40bab4:   0f 84 7e 08 00 00   je 40c338 write_float+0x8d8
  40baba:   83 f9 10cmp$0x10,%ecx
  40babd:   0f 1f 00nopl   (%rax)
  40bac0:   0f 85 63 08 00 00   jne40c329 write_float+0x8c9
  40bac6:   66 0f 6f 02 movdqa (%rdx),%xmm0
  40baca:   66 0f 7f 44 24 40   movdqa %xmm0,0x40(%rsp)
  40bad0:   e8 9b 27 01 00  callq  41e270 __trunctfdf2
  40bad5:   66 44 0f 50 f0  movmskpd %xmm0,%r14d
  40bada:   66 0f 6f 54 24 40   movdqa 0x40(%rsp),%xmm2
  40bae0:   41 83 e6 01 and$0x1,%r14d
  40bae4:   66 0f db 15 44 30 0bpand   0xb3044(%rip),%xmm2#
4beb30 CSWTCH.109+0xb0
  40baeb:   00 
  40baec:   66 0f 6f 0d 4c 30 0bmovdqa 0xb304c(%rip),%xmm1#
4beb40 CSWTCH.109+0xc0
  40baf3:   00 
  40baf4:   66 0f 6f c2 movdqa %xmm2,%xmm0
  40baf8:   66 0f 7f 54 24 10   movdqa %xmm2,0x10(%rsp)
  40bafe:   e8 ed 25 01 00  callq  41e0f0 __unordtf2
  40bb03:   48 85 c0test   %rax,%rax
  40bb06:   66 0f 6f 54 24 10   movdqa 0x10(%rsp),%xmm2
  40bb0c:   0f 85 8e 0c 00 00   jne40c7a0 write_float+0xd40
  40bb12:   66 0f 6f 0d 26 30 0bmovdqa 0xb3026(%rip),%xmm1#
4beb40 CSWTCH.109+0xc0
  40bb19:   00 
  40bb1a:   66 0f 6f c2 movdqa %xmm2,%xmm0
  40bb1e:   e8 8d 2c 01 00  callq  41e7b0 __getf2
  40bb23:   48 85 c0test   %rax,%rax
  40bb26:   0f 8f 74 0c 00 00   jg 40c7a0 write_float+0xd40
  40bb2c:   45 85 f6test   %r14d,%r14d
  40bb2f:   74 14   je 40bb45 

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 Confirmed. The second test case still segfaults when run if compiled with 
 -static in Linux 3.8.0 x86_64 kernel on Ubuntu 12.04.4 LTS, using 
 gfortran 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5).

The 4.6 versions are no longer supported. Could you test with the current
releases 4.7.3 and/or 4.8.2?

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[jouko.orava at iki dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #8 from Jouko Orava jouko.orava at iki dot fi ---
I confirm, still occurs with 4.7.3 and 4.8.1.

For simplicity, I obtained the 4.7 and 4.8 versions from Ubuntu toolchain test
builds' PPA, https://launchpad.net/~ubuntu-toolchain-r/.

GNU Fortran 4.7.3 (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04):
gdb backtrace:
  #0  0x in ?? ()
  #1  0x0040c868 in write_float ()
  #2  0x00405db6 in formatted_transfer ()
  #3  0x00404004 in _gfortran_transfer_array ()
  #4  0x00401396 in MAIN__ ()
Code near the segfault:
  40c85b:   0f 94 84 24 80 00 00sete   0x80(%rsp)
  40c862:   00 
  40c863:   e8 98 37 bf ff  callq  0 __libc_tsd_LOCALE
  40c868:   41 83 3c 24 20  cmpl   $0x20,(%r12)
  40c86d:   0f 84 bd 08 00 00   je 40d130 write_float+0x9e0
  40c873:   44 0f b6 84 24 80 00movzbl 0x80(%rsp),%r8d
Assigning a breakpoint at 40c863 and jumping to 40d130 avoids the segfault. The
printed output contains 'V' instead of \xb6.

GNU Fortran 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04):
gdb backtrace:
  #0  0x in ?? ()
  #1  0x0040c3e9 in write_float ()
  #2  0x00406671 in formatted_transfer ()
  #3  0x0040402f in _gfortran_transfer_array ()
  #4  0x00401396 in MAIN__ ()
Code near the segfault:
  40c3dc:   4c 89 e6mov%r12,%rsi
  40c3df:   b8 01 00 00 00  mov$0x1,%eax
  40c3e4:   e8 17 3c bf ff  callq  0 __libc_tsd_LOCALE
  40c3e9:   41 89 c0mov%eax,%r8d
  40c3ec:   0f b6 85 f0 fe ff ffmovzbl -0x110(%rbp),%eax
  40c3f3:   89 44 24 08 mov%eax,0x8(%rsp)
  40c3f7:   e9 c7 00 00 00  jmpq   40c4c3 write_float+0x273
Assigning a breakpoint at 40c3e4 and jumping to 40c3e9 or 40c4c3 avoids the
first segfault (again a call to __libc_tsd_LOCALE). Another segfault will occur
at 4531fb in memcpy(), in a 'rep movsq %ds:(%rsi),%es:(%rdi)' instruction, with
source (%rsi register) referring to just past/above stack (0x7000).
(The process map indicates stack is at 7ffde000-7000). To me, this
looks like trying to copy a string, but with the source string missing
completely.

In fact, this enforces my belief that the call to __libc_tsd_LOCALE really
should be some kind of setup for the locale-specific numeric formatting string,
and that finding out how a reference to the thread-specific locale structure
can be changed to a function call to that address.

That said, in all cases there are other calls to __libc_tsd_LOCALE (which all
would cause a segmentation fault, if executed) in the disassembly. If compiled
with 4.7.3, in
_IO_flush_all_linebuffered: 438d04: 438d3a:
_IO_flush_all_lockp: 438860: 4388da:
_IO_link_in: 43787d: 4378ba:
_IO_un_link: 43766f: 4376a2:
_IO_vfprintf: 47a94e: 47aa5f:
_IO_vfscanf: 4a448a: 4a55c0:
_IO_vfwprintf: 4851ab: 4851f7:
_Unwind_Find_FDE: 422a45: 422a95:
__assert_fail_base: 4235dc:
__dcigettext: 424609: 424613: 42469d: 4246cb: 4249db: 4249e5: 424a2f:
424a39: 424bc2: 424bcc: 424d78: 424db6:
__deregister_frame_info_bases: 4228ed: 422975:
__dl_iterate_phdr: 46b611: 46b6cf:
__dlerror: 4ad826: 4ad83f:
__dlsym: 4b3912: 4b393d:
__dlvsym: 4b39c4: 4b39f1:
__gconv_compare_alias: 46d621:
__gconv_find_transform: 46d729:
__libc_enable_asynccancel: 46a740:
__libc_fork: 4664d6:
__libc_start_main: 422e4e:
__register_frame_info_bases: 42278b:
__register_frame_info_table_bases: 42284a:
__wcsmbs_load_conv: 465f3f: 466071:
_dl_add_to_namespace_list: 49f7cb:
_dl_addr: 46b7ad: 46b9c2:
_dl_close: 4b3566:
_dl_close_worker: 4b2ed9: 4b3078:
_dl_fini: 4b5b3f: 4b5c06:
_dl_lookup_symbol_x: 49f325: 49f3f5: 49f481:
_dl_open: 4b1a4d: 4b1b12: 4b1b97: 4b1c6d:
_dl_tlsdesc_resolve_hold_fixup: 4b3787:
_dl_tlsdesc_resolve_rela_fixup: 4b361c: 4b363f:
_dlerror_run: 4adad1: 4adb60: 4adb9f:
_gfortran_arandom_r10: 41011b:
_gfortran_arandom_r16: 41030b:
_gfortran_arandom_r4: 40fd7b:
_gfortran_arandom_r8: 40ff2a:
_gfortran_random_r10: 40fb18:
_gfortran_random_r16: 40fbef:
_gfortran_random_r4: 40f9d3:
_gfortran_random_r8: 40fa48:
_gfortran_random_seed_i4: 4104c2: 410648:
_gfortran_random_seed_i8: 4106e3:
_gfortrani_close_units: 408c90:
_gfortrani_convert_infnan: 41898b:
_gfortrani_convert_real: 41888e:
_gfortrani_find_file: 40a24e: 40a268: 40a282: 40a29b: 40a2af: 40a2b7:
40a335:
_gfortrani_flush_all_units: 40a36a: 40a3a1: 40a3c2: 40a3e9: 40a3f1: 40a40d:
40a415:
_gfortrani_get_internal_unit: 4083c8:
_gfortrani_init_units: 408777: 40884b: 408922:
_nl_find_domain: 424efb: 424f5b: 425064: 4250c1:
_nl_find_msg: 423ca8: 423d11: 423ef2: 423f79: 424418: 42454b:
_nl_get_alt_digit: 49942a: 49945e:
_nl_get_walt_digit: 4994d9: 49956a:

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[jouko.orava at iki dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #9 from Jouko Orava jouko.orava at iki dot fi ---
It turns out that while 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
crashes when compiled static,
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), x(3:4)
END PROGRAM
does not. The only thing that changes in the second-to-last line:
with x(1:4) it segfaults, with x(1),x(3:4) it works fine.
Compiled on 4.7.3 using
gfortran-4.7 -static -ggdb -W -Wall -O3 fdp2.f90 -o fdp2
and on 4.8.1 using
gfortran-4.8 -static -ggdb -W -Wall -O3 fdp2.f90 -o fdp2

Comparing the disassembly of the two, both do have a large number of
callq  0 __libc_tsd_LOCALE
calls. However, where the first one segfaults, the second one has
callq  423320 quadmath_snprintf

Furthermore, compiling using -Wl,-uquadmath_snprintf fixes the issue, i.e.
gfortran-4.7 -static -ggdb -W -Wall -O3 fdp2.f90 -Wl,-uquadmath_snprintf
fdp2
causes the shown example program to work correctly.

Finally, compiling Bill Long's example fdp2.f90 using
gfortran-4.7 -fdefault-real-8 -static fdp2.f90 -Wl,-uquadmath_snprintf -o
a.out
or
gfortran-4.8 -fdefault-real-8 -static fdp2.f90 -Wl,-uquadmath_snprintf -o
a.out
fixes the segfault for me.

It seems like some kind of linking issue. How the issue is masked by printing a
scalar before an array is a mystery to me, however.

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-06-24
 Ever confirmed|0   |1

--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Since I don't access to a box (linux or not) allowing -static, I cannot
reproduce the segmentation fault. Is the array test in comment #0 still
failing?

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-08-26 20:54:56 UTC ---
(In reply to comment #0)
 It appears that the combination of -static and promoting 'double precision' to
 kind=16 causes problems for writing an double precision array.  Either 
 changing
 from array to scalar, or removing -static avoids the problem. 
 
 Writing quad scalar with -static is fine:
 
  cat fdp2.f90
 double precision :: x
 x = 3.4
 print *, kind(x)
 write (*, (f10.3) ) x
 end
  gfortran -fdefault-real-8 -static fdp2.f90
  ./a.out
   16
  3.400
 
 Writing quad array with -static - segfault.
 
  cat fdp1.f90
 double precision :: x(4)
 x = 3.4
 print *, kind(x)
 write (*, (4f10.3) ) x
 end
  gfortran -fdefault-real-8 -static fdp1.f90
  ./a.out
   16
 Segmentation fault
 
 But is OK without -static:
 
  gfortran -fdefault-real-8  fdp1.f90
  ./a.out
   16
  3.400 3.400 3.400 3.400
 

What operating system?

It works for me.

troutmask:sgk[207] gfc4x -o z a.f90  ./z
   8
 3.400
troutmask:sgk[208] gfc4x -o z -static a.f90  ./z
   8
 3.400
troutmask:sgk[209] gfc4x -o z -static -fdefault-real-8 a.f90  ./z
  16
 3.400
troutmask:sgk[210] gfc4x -o z -fdefault-real-8 a.f90  ./z
  16
 3.400

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[longb at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #2 from Bill Long longb at cray dot com 2011-08-26 21:00:04 UTC 
---
OS is Linux SLES 11.

From the output in the test, it looks like you tried only the scalar case,
which I agree works.  The array case (second test code) is the one the fails.

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu 
2011-08-26 21:09:42 UTC ---
On Fri, Aug 26, 2011 at 09:00:04PM +, longb at cray dot com wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201
 
 --- Comment #2 from Bill Long longb at cray dot com 2011-08-26 21:00:04 UTC 
 ---
 OS is Linux SLES 11.
 
 From the output in the test, it looks like you tried only the scalar case,
 which I agree works.  The array case (second test code) is the one the fails.

Whoops, Yes, I grabbed the wrong testcase. :(

==4791== Conditional jump or move depends on uninitialised value(s)
==4791==at 0x43F6DF: strlen (in /usr/home/sgk/tmp/z)
==4791==by 0x40B12D: write_integer (write.c:1285)
==4791==by 0x40EB13: _gfortrani_list_formatted_write (write.c:1571)
==4791==by 0x4002FB: MAIN__ (in /usr/home/sgk/tmp/z)
==4791==by 0x4003FE: main (in /usr/home/sgk/tmp/z)
==4791== 
  16
==4791== Jump to the invalid address stated on the next line
==4791==at 0x0: ???
==4791==by 0x44AB7F: ??? (in /usr/home/sgk/tmp/z)
==4791==by 0x3: ???
==4791==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==4791== 
==4791== 
==4791== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==4791==  Bad permissions for mapped region at address 0x0
==4791==at 0x0: ???
==4791==by 0x44AB7F: ??? (in /usr/home/sgk/tmp/z)
==4791==by 0x3: ???

[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201

--- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu 
2011-08-26 21:29:41 UTC ---
On Fri, Aug 26, 2011 at 09:09:42PM +, sgk at troutmask dot
apl.washington.edu wrote:
 
 ==4791== Conditional jump or move depends on uninitialised value(s)
 ==4791==at 0x43F6DF: strlen (in /usr/home/sgk/tmp/z)
 ==4791==by 0x40B12D: write_integer (write.c:1285)
 ==4791==by 0x40EB13: _gfortrani_list_formatted_write (write.c:1571)
 ==4791==by 0x4002FB: MAIN__ (in /usr/home/sgk/tmp/z)
 ==4791==by 0x4003FE: main (in /usr/home/sgk/tmp/z)
 ==4791== 
   16
 ==4791== Jump to the invalid address stated on the next line
 ==4791==at 0x0: ???
 ==4791==by 0x44AB7F: ??? (in /usr/home/sgk/tmp/z)
 ==4791==by 0x3: ???
 ==4791==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
 ==4791== 
 ==4791== 
 ==4791== Process terminating with default action of signal 11 (SIGSEGV):
 dumping core
 ==4791==  Bad permissions for mapped region at address 0x0
 ==4791==at 0x0: ???
 ==4791==by 0x44AB7F: ??? (in /usr/home/sgk/tmp/z)
 ==4791==by 0x3: ???

Some additional debugging.

(gdb) run
Starting program: /usr/home/sgk/tmp/z 
  16

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x0040c2e2 in write_float (dtp=0x7fffd2f0, f=0x200820588, 
source=Unhandled dwarf expression opcode 0xf3
) at ../../../gcc4x/libgfortran/io/write_float.def:1062
#2  0x004049b6 in formatted_transfer_scalar_write (dtp=0x7fffd2f0, 
type=BT_REAL, p=0x7fffd4d0, kind=16, size=16, nelems=4)
at ../../../gcc4x/libgfortran/io/transfer.c:1630
#3  formatted_transfer (dtp=0x7fffd2f0, type=BT_REAL, p=0x7fffd4d0, 
kind=16, size=16, nelems=4)
at ../../../gcc4x/libgfortran/io/transfer.c:1868
#4  0x00402e80 in transfer_array (dtp=0x7fffd2f0, desc=Unhandled
dwarf expression opcode 0xf3
)
at ../../../gcc4x/libgfortran/io/transfer.c:2036
#5  0x004003ba in MAIN__ () at a.f90:4