[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
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
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&root=gcc&view=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
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&root=gcc&view=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
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
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
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
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
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
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&action=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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 --- Comment #9 from Jouko Orava --- 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 --- Comment #8 from Jouko Orava --- 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 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 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: _nl_init_era_entries.part.0: 4996ea: _nl_load_domain:
[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 --- Comment #7 from Dominique d'Humieres --- > 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 Jouko Orava changed: What|Removed |Added CC||jouko.orava at iki dot fi --- Comment #6 from Jouko Orava --- 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 : 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 40ba98: 41 83 fd 1c cmp$0x1c,%r13d 40ba9c: 0f 85 06 05 00 00 jne40bfa8 40baa2: 83 f9 08cmp$0x8,%ecx 40baa5: 0f 84 4a 05 00 00 je 40bff5 40baab: 0f 8e 6f 08 00 00 jle40c320 40bab1: 83 f9 0acmp$0xa,%ecx 40bab4: 0f 84 7e 08 00 00 je 40c338 40baba: 83 f9 10cmp$0x10,%ecx 40babd: 0f 1f 00nopl (%rax) 40bac0: 0f 85 63 08 00 00 jne40c329 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 40baeb: 00 40baec: 66 0f 6f 0d 4c 30 0bmovdqa 0xb304c(%rip),%xmm1# 4beb40 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 40bb12: 66 0f 6f 0d 26 30 0bmovdqa 0xb3026(%rip),%xmm1# 4beb40 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 40bb2c: 45 85 f6test %r14d,%r14d 40bb2f: 74 14 je 40bb45 40bb31: 66 0f 6f 44 24 40 movdqa 0x40(%rsp),%xmm0 40bb37: 66 0f ef 05 11 30 0bpxor 0xb3011(%rip),%xmm0# 4beb50 40bb3e: 00 40bb3f: 66 0f 7f 44 24 40 movdqa %xmm0,0x40(%rsp) 40bb45:
[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-24 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 --- Comment #4 from Steve Kargl 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
[Bug fortran/50201] gfortran with -static causes seg fault at runtime for writing double prec array with precision increased to kind=16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 --- Comment #3 from Steve Kargl 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201 --- Comment #2 from Bill Long 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
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