[Bug middle-end/113636] New: internal compiler error: in dead_debug_global_find, at valtrack.cc:275
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113636
Bug ID: 113636
Summary: internal compiler error: in dead_debug_global_find, at
valtrack.cc:275
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
A build + test run [r14-8465] on aarch64-linux-gnu draws the following ICE
while compiling math/cmplx:
during RTL pass: sched1
cmath_test.go: In function 'math/cmplx.BenchmarkCos':
cmath_test.go:1520:1: internal compiler error: in dead_debug_global_find, at
valtrack.cc:275
1520 | func BenchmarkCos(b *testing.B) {
| ^
0x131ce17 dead_debug_global_find
/home/toon/compilers/gcc/gcc/valtrack.cc:275
0x131ce17 dead_debug_global_find
/home/toon/compilers/gcc/gcc/valtrack.cc:269
0x131cef3 dead_debug_global_replace_temp
/home/toon/compilers/gcc/gcc/valtrack.cc:321
0x131df33 dead_debug_promote_uses
/home/toon/compilers/gcc/gcc/valtrack.cc:450
0x131df33 dead_debug_local_finish(dead_debug_local*, bitmap_head*)
/home/toon/compilers/gcc/gcc/valtrack.cc:487
0x1d777eb dce_process_block
/home/toon/compilers/gcc/gcc/dce.cc:1060
0x1d777eb fast_dce
/home/toon/compilers/gcc/gcc/dce.cc:1128
0x1d77d17 rest_of_handle_fast_dce
/home/toon/compilers/gcc/gcc/dce.cc:1194
0x1d77d17 run_fast_df_dce()
/home/toon/compilers/gcc/gcc/dce.cc:1242
0xa6c8e7 df_lr_finalize
/home/toon/compilers/gcc/gcc/df-problems.cc:1065
0xa6585f df_analyze_problem(dataflow*, bitmap_head*, int*, int)
/home/toon/compilers/gcc/gcc/df-core.cc:1190
0xa658ff df_analyze_1
/home/toon/compilers/gcc/gcc/df-core.cc:1235
0x1e5574b sched_init()
/home/toon/compilers/gcc/gcc/haifa-sched.cc:7348
0x1e570e7 haifa_sched_init()
/home/toon/compilers/gcc/gcc/haifa-sched.cc:7372
0xf38a4f schedule_insns()
/home/toon/compilers/gcc/gcc/sched-rgn.cc:3517
0xf39157 schedule_insns()
/home/toon/compilers/gcc/gcc/sched-rgn.cc:3511
0xf39157 rest_of_handle_sched
/home/toon/compilers/gcc/gcc/sched-rgn.cc:3729
0xf39157 execute
/home/toon/compilers/gcc/gcc/sched-rgn.cc:3839
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
FAIL: math/cmplx
The build was started with the following system compiler:
$ echo | gcc -### -E - -march=native -mtune=native
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 13.2.0-9'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--enable-fix-cortex-a53-843419 --disable-werror
--enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-13-13.2.0/debian/tmp-nvptx/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=4
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (Debian 13.2.0-9)
COLLECT_GCC_OPTIONS='-E' '-mlittle-endian' '-mabi=lp64' '-mtune=thunderxt88'
/usr/libexec/gcc/aarch64-linux-gnu/13/cc1 -E -quiet -imultiarch
aarch64-linux-gnu - -mlittle-endian "-mabi=lp64" "-mtune=thunderxt88"
-fasynchronous-unwind-tables -dumpbase -
COMPILER_PATH=/usr/libexec/gcc/aarch64-linux-gnu/13/:/usr/libexec/gcc/aarch64-linux-gnu/13/:/usr/libexec/gcc/aarch64-linux-gnu/:/usr/lib/gcc/aarch64-linux-gnu/13/:/usr/lib/gcc/aarch64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/aarch64-linux-gnu/13/:/usr/lib/gcc/aarch64-linux-gnu/13/../../../aarch64-linux-gnu/:/usr/lib/gcc/aarch64-linux-gnu/13/../../../../lib/:/lib/aarch64-linux-gnu/:/lib/../lib/:/usr/lib/aarch64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/aarch64-linux-gnu/13/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-E' '-mlittle-endian' '-mabi=lp64' '-mtune=thunderxt88'
using these configure flags:
Compiler version: 14.0.1 20240127 (experimental) [master r
[Bug fortran/111218] New: Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218 Bug ID: 111218 Summary: Conflict in BIND(C) INTERFACEs in two Modules leads to ICE. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: toon at moene dot org Target Milestone: --- The following program: MODULE FIELD_2RM_UTIL_MODULE INTERFACE SUBROUTINE SET_ABOR1_EXCEPTION_HANDLER() BIND(C,name="set_abor1_exception_handler") END SUBROUTINE SET_ABOR1_EXCEPTION_HANDLER END INTERFACE END MODULE MODULE FIELD_3RM_UTIL_MODULE INTERFACE SUBROUTINE SET_ABOR1_EXCEPTION_HANDLER() BIND(C,name="set_abor1_exception_handler") END SUBROUTINE SET_ABOR1_EXCEPTION_HANDLER END INTERFACE END MODULE MODULE FIELD_UTIL_MODULE USE FIELD_2RM_UTIL_MODULE USE FIELD_3RM_UTIL_MODULE IMPLICIT NONE END MODULE leads to the following internal compiler error: /home/toon/compilers/install/gcc/bin/gfortran -c -g a.f90 in gfc_format_decoder, at fortran/error.cc:1078 0x75917d gfc_format_decoder /home/toon/compilers/gcc/gcc/fortran/error.cc:1078 0x2153e1f pp_format(pretty_printer*, text_info*) /home/toon/compilers/gcc/gcc/pretty-print.cc:1475 0x21315be diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) /home/toon/compilers/gcc/gcc/diagnostic.cc:1606 0x9b628e gfc_report_diagnostic /home/toon/compilers/gcc/gcc/fortran/error.cc:890 0x9b628e gfc_error_opt /home/toon/compilers/gcc/gcc/fortran/error.cc:1460 0x9b7470 gfc_error(char const*, ...) /home/toon/compilers/gcc/gcc/fortran/error.cc:1489 0xa6205b ambiguous_symbol /home/toon/compilers/gcc/gcc/fortran/symbol.cc:3167 0xa6ce9e gfc_find_sym_tree(char const*, gfc_namespace*, int, gfc_symtree**) /home/toon/compilers/gcc/gcc/fortran/symbol.cc:3240 0xa6cec1 gfc_find_symbol(char const*, gfc_namespace*, int, gfc_symbol**) /home/toon/compilers/gcc/gcc/fortran/symbol.cc:3291 0xb27a05 check_against_globals /home/toon/compilers/gcc/gcc/fortran/frontend-passes.cc:5842 0xa630e2 do_traverse_symtree /home/toon/compilers/gcc/gcc/fortran/symbol.cc:4190 0xb30231 gfc_check_externals(gfc_namespace*) /home/toon/compilers/gcc/gcc/fortran/frontend-passes.cc:5888 0xa293d8 gfc_parse_file() /home/toon/compilers/gcc/gcc/fortran/parse.cc:7195 0xa7aecf gfc_be_parse_file /home/toon/compilers/gcc/gcc/fortran/f95-lang.cc:229 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. (tested with gcc version 14.0.0 20230828 (experimental) [master r14-3528-gc3669bb677b] (GCC)
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #29 from Toon Moene --- On 9/8/21 10:05 PM, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 > > anlauf at gcc dot gnu.org changed: > > What|Removed |Added > > Status|NEW |WAITING > > --- Comment #28 from anlauf at gcc dot gnu.org --- > (In reply to Toon Moene from comment #27) >> Yes, I am now convince this works (64 leads to stop 1, but 63 works). > > So has this been definitely fixed, and can we close it? > Yes, it can be closed - thanks !
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #27 from Toon Moene --- Yes, I am now convince this works (64 leads to stop 1, but 63 works). Note that I slightly changed the program today, to add a sync all before the forecasting loop, and adding one to the copy_local_to_global defined assignment procedure. Thanks for your perseverance.
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #25 from Toon Moene --- BTW, the speed difference between the native and the OpenMPI based program is staggering. For a 936x770x60 grid, the native run takes around 14 seconds elapsed time, while the OpenMPI based one takes 2 minutes on my 10 core x 2 hyperthreads Skylake machine.
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #24 from Toon Moene --- And I can reproduce the GFORTRAN_NUM_IMAGES=64 segfault: (export LD_LIBRARY_PATH=/home/toon/compilers/install/coarray_native/lib/gcc/x86_64-pc-linux-gnu/11.0.0; export GFORTRAN_NUM_IMAGES=64; echo ' nxglobal=936, nyglobal=770, nzglobal=60 / ' | ./a.out) Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7fec7b252bd0 in ??? #1 0x7fec7b251e25 in ??? #2 0x7fec7af00cbf in ??? #3 0x7fec7b5377ae in shared_malloc at /home/toon/compilers/coarray_native/libgfortran/caf_shared/allocator.c:70 #4 0x7fec7b5374ab in get_memory_by_id_internal at /home/toon/compilers/coarray_native/libgfortran/caf_shared/alloc.c:75 #5 0x4141ed in random_weather at /home/toon/src/random-weather.f90:551 #6 0x7fec7b537c0a in image_main_wrapper at /home/toon/compilers/coarray_native/libgfortran/caf_shared/coarraynative.c:183 #7 0x415d2a in main at /home/toon/src/random-weather.f90:413 ERROR: Image 64(0x3a877f) failed after which message it hangs ... Notably, I did add a check on boundary relaxation zone size, so that cannot be the problem.
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #23 from Toon Moene --- The segfault at GFORTRAN_NUM_IMAGES=64 might be due to the fact that the program doesn't contain a check whether the size of the boundary relaxation zone (currently set to 4) is too large for the slabs. The boundary relaxation is programmed under the assumption that the size of a slab >= 4x4. If that's the problem, it should go away by setting the size to 3 or 2 (or use a larger domain than horizontally 72 x 70). The current version of the program can be found at: http://moene.org/~toon/random-weather
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #20 from Toon Moene --- Example of the problem described in the last comment: (export LD_LIBRARY_PATH=/home/toon/compilers/install/coarray_native/lib/gcc/x86_64-pc-linux-gnu/11.0.0; export GFORTRAN_NUM_IMAGES=28; echo ' nxglobal=936, nyglobal=770, nzglobal=60 / ' | ./a.out) Decomposition information on image 1 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 6 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 9 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 24 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 23 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 2 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 22 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 16 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 21 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 12 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 8 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 26 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 14 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 5 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 15 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 3 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 19 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 27 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 10 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 7 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 25 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 11 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 4 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 13 : there are 4 * 7 slabs; the slabs are 18 * 10 grid cells in size. Decomposition information on image 20 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 17 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 18 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Decomposition information on image 28 : there are 4 * 7 slabs; the slabs are 234 * 110 grid cells in size. Size mismatch for coarray allocation id 0x419400: found = 2882880 != size = 20160 Size mismatch for coarray allocation id 0x419400: found = 2882880 != size = 20160 ERROR: Image 28(0x1e0a22) failed BTW, I cannot replicate this reliably, so it is probably timing related ...
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #19 from Toon Moene --- Thanks. It works now for export GFORTRAN_NUM_IMAGES=1..10 for me. Unfortunately, when I want to change the nxglobal and nyglobal values in the domain via the namelist, sometimes the "default" values are used. However, this could well be because I do not do the distribution of the configuration values to the images other than 1 correctly. If you see any shortcoming here I would be very interested in the analysis. In any way, you can use this test case as you see fit - I wrote this in 2018 specifically to test the native coarrays ...
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #11 from Toon Moene --- Created attachment 49564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49564=edit The full program I am testing. This is the full program I am testing. I have compiled it as follows (after building the latest coarray_native branch): ~/compilers/install/coarray_native/bin/gfortran -g -fbacktrace -fcoarray=shared random-weather.f90 -lcaf_shared -lrt -lpthread and run it as: (export LD_LIBRARY_PATH=/home/toon/compilers/install/coarray_native/lib/gcc/x86_64-pc-linux-gnu/11.0.0; export GFORTRAN_NUM_IMAGES=N; echo ' / ' | ./a.out) It works with export GFORTRAN_NUM_IMAGES=2 ... 10 but crashes with a segmentation fault using export GFORTRAN_NUM_IMAGES=1 (besides, it gives bogus numbers when it runs - this is readily apparent by running the program compiled with -fcoarray=lib -lcaf_openmpi and compare). Hope this helps - I am looking forward to this alternative implementation of coarrays !
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 Toon Moene changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #9 from Toon Moene --- Unfortunately, I now get the following error on the original code in the attachment: (export LD_LIBRARY_PATH=/home/toon/compilers/install/coarray_native/lib/gcc/x86_64-pc-linux-gnu/11.0.0; export GFORTRAN_NUM_IMAGES=1; echo ' / ' | ./a.out) Decomposition information on image 1 : there are 1 * 1 slabs; the slab on this image has 90 * 90 grid cells. Fortran runtime error: Integer overflow when calculating the amount of memory to allocate Error termination. Backtrace: #0 0x7f310ff36bd0 in ??? #1 0x7f310ff37685 in ??? #2 0x7f310ff37b49 in ??? #3 0x40247b in __types_MOD_global_alloc at /home/toon/src/test-coarrays.f90:21 #4 0x403a74 in random_weather at /home/toon/src/test-coarrays.f90:95 #5 0x7f311021bc0a in image_main_wrapper at /home/toon/compilers/coarray_native/libgfortran/nca/coarraynative.c:184 #6 0x403acb in main at /home/toon/src/test-coarrays.f90:28
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #7 from Toon Moene --- I agree - the coarrays should be the same size and the program should just only *use* the part that it needs. I also got an error with the caf-mpi library, but that one was impossible to understand (in fact, that was the reason I wanted to try the native version ...) Thanks !
[Bug fortran/97589] New: Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 Bug ID: 97589 Summary: Segementation fault when allocating coarrays. Product: gcc Version: coarray_native Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: toon at moene dot org Target Milestone: --- Created attachment 49446 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49446=edit The failing program. I compiled the attached program as follows: ~/compilers/install/coarray_native/bin/gfortran -fbacktrace -fcoarray=shared test-coarrays.f90 -lcaf_shared -lrt -lpthread and ran it: (export LD_LIBRARY_PATH=/home/toon/compilers/install/coarray_native/lib/gcc/x86_64-pc-linux-gnu/11.0.0; export GFORTRAN_NUM_IMAGES=1; echo ' / ' | ./a.out) Decomposition information on image 1 : there are 1 * 1 slabs; the slab on this image has 90 * 90 grid cells. Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f4af6b41bd0 in ??? #1 0x7f4af6b40e25 in ??? #2 0x7f4af67efcbf in ??? #3 0x7f4af6916e6d in ??? #4 0x7f4af6e264fb in get_memory_by_id_internal at /home/toon/compilers/coarray_native/libgfortran/nca/alloc.c:73 #5 0x401f70 in ??? #6 0x403a74 in ??? #7 0x7f4af6e26a7f in image_main_wrapper at /home/toon/compilers/coarray_native/libgfortran/nca/coarraynative.c:83 #8 0x403acb in ??? #9 0x7f4af67dacc9 in ??? #10 0x401189 in ??? #11 0x in ??? ERROR: Image 1(0x22dbf4) failed
[Bug fortran/97530] Segmentation fault compiling coarray program with option -fcoarray=shared (not with -fcoarray={lib,single})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97530 --- Comment #1 from Toon Moene --- Created attachment 49437 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49437=edit Reduced test case. I managed to reduce the failing program.
[Bug fortran/97530] New: Segmentation fault compiling coarray program with option -fcoarray=shared (not with -fcoarray={lib,single})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97530
Bug ID: 97530
Summary: Segmentation fault compiling coarray program with
option -fcoarray=shared (not with
-fcoarray={lib,single})
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
Created attachment 49424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49424=edit
Source code of the of the full program reported on.
This is actually using the compiler from the devel/coarray_native branch (built
today), but I couldn't select that with the "version" option.
I get the following Segmentation fault when compiling the attached program, as
follows:
~/compilers/install/devel/coarray_native/bin/gfortran -S -fcoarray=shared
random-weather.f90
random-weather.f90:236:0:
236 | int_mult % ps = ms % ps * ifactor
|
internal compiler error: Segmentation fault
0xe61e3f crash_signal
/home/toon/compilers/coarray_native/gcc/toplev.c:327
0x92954d gfc_conv_ss_descriptor
/home/toon/compilers/coarray_native/gcc/fortran/trans-array.c:3044
0x92c380 gfc_conv_ss_startstride(gfc_loopinfo*)
/home/toon/compilers/coarray_native/gcc/fortran/trans-array.c:4433
0x961ba9 gfc_trans_assignment_1
/home/toon/compilers/coarray_native/gcc/fortran/trans-expr.c:10858
0x920a82 trans_code
/home/toon/compilers/coarray_native/gcc/fortran/trans.c:1899
0x94ff8e gfc_generate_function_code(gfc_namespace*)
/home/toon/compilers/coarray_native/gcc/fortran/trans-decl.c:7067
0x924f61 gfc_generate_module_code(gfc_namespace*)
/home/toon/compilers/coarray_native/gcc/fortran/trans.c:2299
0x8cc28d translate_all_program_units
/home/toon/compilers/coarray_native/gcc/fortran/parse.c:6334
0x8cc28d gfc_parse_file()
/home/toon/compilers/coarray_native/gcc/fortran/parse.c:6616
0x91da6f gfc_be_parse_file
/home/toon/compilers/coarray_native/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Doesn't happen with -fcoarray={lib,single}
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 Toon Moene changed: What|Removed |Added CC||toon at moene dot org --- Comment #7 from Toon Moene --- *** Bug 96712 has been marked as a duplicate of this bug. ***
[Bug fortran/96712] internal compiler error: in build_round_expr, at fortran/trans-intrinsic.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96712 Toon Moene changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Toon Moene --- I wasn't quick enough. Reported as PR 96711. *** This bug has been marked as a duplicate of bug 96711 ***
[Bug fortran/96712] New: internal compiler error: in build_round_expr, at fortran/trans-intrinsic.c:399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96712 Bug ID: 96712 Summary: internal compiler error: in build_round_expr, at fortran/trans-intrinsic.c:399 Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: toon at moene dot org Target Milestone: --- The following source: integer i real(kind=8) r i = nint(r, 16) end generates an ICE when compiled with 10.2 as follows gfortran -S nint_pr.f90 nint_pr.f90:3:0: 3 | i = nint(r, 16) | internal compiler error: in build_round_expr, at fortran/trans-intrinsic.c:399 Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
[Bug analyzer/93405] Passing constant arguments to subroutines in Fortran ... and the analyzer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405 --- Comment #5 from Toon Moene --- I have no problem with it. I will ACK it on the fortran mailing list.
[Bug analyzer/93405] Passing constant arguments to subroutines in Fortran ... and the analyzer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405 --- Comment #3 from Toon Moene --- The patch indeed solved the test case. Thanks !
[Bug analyzer/93405] New: Passing constant arguments to subroutines in Fortran ... and the analyzer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405 Bug ID: 93405 Summary: Passing constant arguments to subroutines in Fortran ... and the analyzer. Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: toon at moene dot org Target Milestone: --- I think the analyzer has a problem in the way constant arguments are passed "by reference" in Fortran: $ cat main1.f real a(10), b(10), c(10) a = 0. b = 1. call sum(a, b, c, 10) print *, c(5) end subroutine sum(a, b, c, n) integer i, n real a(n), b(n), c(n) do i = 1, n c(i) = a(i) + b(i) enddo end $ ~/compilers/install/bin/gfortran -fanalyzer -S main1.f during IPA pass: analyzer main1.f:4:0: 4 | call sum(a, b, c, 10) | internal compiler error: in get_lvalue_1, at analyzer/region-model.cc:4617 0x782863 ana::region_model::get_lvalue_1(ana::path_var, ana::region_model_context*) /home/toon/compilers/gcc/gcc/analyzer/region-model.cc:4617 0x11bc8c3 ana::region_model::get_lvalue(ana::path_var, ana::region_model_context*) /home/toon/compilers/gcc/gcc/analyzer/region-model.cc:4720 0x11bdcdc ana::region_model::get_rvalue_1(ana::path_var, ana::region_model_context*) /home/toon/compilers/gcc/gcc/analyzer/region-model.cc:4763 0x11bde53 ana::region_model::get_rvalue(ana::path_var, ana::region_model_context*) /home/toon/compilers/gcc/gcc/analyzer/region-model.cc:4800 0x11bf209 ana::region_model::update_for_call_superedge(ana::call_superedge const&, ana::region_model_context*) /home/toon/compilers/gcc/gcc/analyzer/region-model.cc:5658 0x11bf2f7 ana::region_model::maybe_update_for_edge(ana::superedge const&, gimple const*, ana::region_model_context*) /home/toon/compilers/gcc/gcc/analyzer/region-model.cc:5599 0x11aaba2 ana::program_state::on_edge(ana::exploded_graph&, ana::exploded_node const&, ana::superedge const*, ana::state_change*) /home/toon/compilers/gcc/gcc/analyzer/program-state.cc:734 0x1198349 ana::exploded_node::on_edge(ana::exploded_graph&, ana::superedge const*, ana::program_point*, ana::program_state*, ana::state_change*) const /home/toon/compilers/gcc/gcc/analyzer/engine.cc:1081 0x119f1ad ana::exploded_graph::process_node(ana::exploded_node*) /home/toon/compilers/gcc/gcc/analyzer/engine.cc:2506 0x119f7b2 ana::exploded_graph::process_worklist() /home/toon/compilers/gcc/gcc/analyzer/engine.cc:2259 0x119fe19 ana::impl_run_checkers(ana::logger*) /home/toon/compilers/gcc/gcc/analyzer/engine.cc:3580 0x11a0883 ana::run_checkers() /home/toon/compilers/gcc/gcc/analyzer/engine.cc:3634 0x11967d8 execute /home/toon/compilers/gcc/gcc/analyzer/analyzer-pass.cc:84 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug analyzer/93388] New: ensure -fanalyzer works with our C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93388 Bug ID: 93388 Summary: ensure -fanalyzer works with our C code Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: toon at moene dot org Target Milestone: --- Trying to bootstrap with a new config/bootstrap-analyzer.mk: STAGE2_CFLAGS += -fanalyzer STAGE3_CFLAGS += -fanalyzer fails while building libbacktrace/dwarf.c:448:12: warning: use of uninitialized value 'unit_buf.buf' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
[Bug fortran/90937] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937 --- Comment #1 from Toon Moene --- It compiles with gfortran 7.3
[Bug fortran/90937] New: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90937 Bug ID: 90937 Summary: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1538 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: toon at moene dot org Target Milestone: --- Compiling he following code leads to the ICE in the summary: SUBROUTINE LFIDIFF IMPLICIT NONE INTEGER, PARAMETER :: JPIM = SELECTED_INT_KIND(9) CONTAINS SUBROUTINE FRLFI (KLUN, KLON, CDNOM, CDF) INTEGER (KIND=JPIM), INTENT (IN) :: KLUN INTEGER (KIND=JPIM), POINTER :: KLON (:) CHARACTER (LEN=*), POINTER :: CDNOM (:) CHARACTER (LEN=*), INTENT (IN) :: CDF INTEGER (KIND=JPIM) :: IREP CALL LFIFER(IREP,KLUN,'KEEP') END SUBROUTINE FRLFI SUBROUTINE GRLFI (KLUN, KLON, CDNOM, CDF) INTEGER (KIND=JPIM), INTENT (IN) :: KLUN INTEGER (KIND=JPIM), POINTER :: KLON (:) CHARACTER (LEN=*), POINTER :: CDNOM (:) CHARACTER (LEN=*), INTENT (IN) :: CDF INTEGER(KIND=JPIM) :: IREP INTEGER(KIND=JPIM) :: ILONG, IPOSEX CHARACTER(LEN=LEN(CDNOM)) :: CLNOMA CALL LFICAS(IREP,KLUN,CLNOMA,ILONG,IPOSEX,.TRUE.) END SUBROUTINE GRLFI END SUBROUTINE LFIDIFF It fails in the same way using 8.3.0.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #9 from Toon Moene ---
> So with this suggestion, this procedure would be generated without the hidden
> length argument. The brokenness comes from
> call foo("ab")
> which would generate a call to a procedure WITH the hidden string length
> argument. However, this code is perfectly standard conforming, F2018 15.5.2.4
> says that a character dummy argument must have a length less than or equal to
> the actual argument, which is fulfilled by the above (1 <= 2). That is, we
> can't special case len=1 procedures and calls in any way.
And this happens *a lot* in the LAPACK code itself.
Just do a grep -i sgemm on it and you will see it in action.
Perhaps this is the reason why this occurs in the R -> LAPACK boundary code ...
[Bug fortran/51310] -finit-bla doesn't initialize *all* items of type bla to the requested constant.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310 --- Comment #10 from Toon Moene --- On 1/14/19 11:52 PM, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310 > > --- Comment #9 from Dominique d'Humieres --- > Output from the test in comment 0 is now > > NaN 0. > NaN > n= 3 > a= NaN NaN > NaN > var= NaN > b= NaN NaN > NaN > c= 0.0.0. > > i.e., the allocated allocatable arrays are not initialized. > > Toon do you still want to have this PR assigned to you? > > This PR is also related to pr33430. > Yes, leave it for the time being - I will see if I can do something about it (or unassign, if not). Thanks,
[Bug rtl-optimization/88519] New: internal compiler error: in expand_widen_pattern_expr, at optabs.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88519 Bug ID: 88519 Summary: internal compiler error: in expand_widen_pattern_expr, at optabs.c:278 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: toon at moene dot org Target Milestone: --- Created attachment 45244 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45244=edit Source code that provokes the ICE. The attached source provokes the following ICE: during RTL pass: expand hlcfint2.f90:159:0: 159 |zpsi2 = ppsi(i,k) + (ppsi(i,k)-ppsi(i,k-1))*zxx/(pph(i,k)-pph(i,k-1)) | internal compiler error: in expand_widen_pattern_expr, at optabs.c:278 0x6bcac1 expand_widen_pattern_expr(separate_ops*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, int) /home/toon/compilers/trunk/gcc/optabs.c:278 0xabe134 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /home/toon/compilers/trunk/gcc/expr.c:9465 0xaaeb2f expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /home/toon/compilers/trunk/gcc/expr.c:9882 0xaac1b5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /home/toon/compilers/trunk/gcc/expr.c:11037 0xab8843 store_expr(tree_node*, rtx_def*, int, bool, bool) /home/toon/compilers/trunk/gcc/expr.c:5633 0xab9f79 expand_assignment(tree_node*, tree_node*, bool) /home/toon/compilers/trunk/gcc/expr.c:5416 0xab9f79 expand_assignment(tree_node*, tree_node*, bool) /home/toon/compilers/trunk/gcc/expr.c:4977 0x9a064f expand_gimple_stmt_1 /home/toon/compilers/trunk/gcc/cfgexpand.c:3746 0x9a064f expand_gimple_stmt /home/toon/compilers/trunk/gcc/cfgexpand.c:3844 0x9a2b01 expand_gimple_basic_block /home/toon/compilers/trunk/gcc/cfgexpand.c:5880 0x9a7687 execute /home/toon/compilers/trunk/gcc/cfgexpand.c:6502 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. when compiled in the following way: ~toon/compilers/install/bin/gfortran -Ofast -march=skylake-avx512 -c hlcfint2.f90 Version of the compiler: ~toon/compilers/install/bin/gfortran -v Using built-in specs. COLLECT_GCC=/home/toon/compilers/install/bin/gfortran COLLECT_LTO_WRAPPER=/home/toon/compilers/install/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/toon/compilers/trunk/configure --prefix=/home/toon/compilers/install --with-gnu-as --with-gnu-ld --enable-languages=all,go,ada --disable-multilib --disable-nls Thread model: posix gcc version 9.0.0 20181216 (experimental) (GCC)
[Bug middle-end/87218] Extremely long compile time with 710 line Fortran code using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87218 --- Comment #1 from Toon Moene --- Well, OK - it's more like 9 minutes ...
[Bug middle-end/87218] New: Extremely long compile time with 710 line Fortran code using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87218 Bug ID: 87218 Summary: Extremely long compile time with 710 line Fortran code using -O2 Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: toon at moene dot org Target Milestone: --- Created attachment 44660 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44660=edit Source of Fortran routine taking 12+ minutes to compile Attached file compiled with: toon@moene:~/src$ gfortran -v -ftime-report -O2 -S suafn.f90 Using built-in specs. COLLECT_GCC=gfortran OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-4' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.2.0 (Debian 8.2.0-4) COLLECT_GCC_OPTIONS='-v' '-ftime-report' '-O2' '-S' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/8/f951 suafn.f90 -quiet -dumpbase suafn.f90 -mtune=generic -march=x86-64 -auxbase suafn -O2 -version -ftime-report -o suafn.s -fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/8/finclude GNU Fortran (Debian 8.2.0-4) version 8.2.0 (x86_64-linux-gnu) compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (Debian 8.2.0-4) version 8.2.0 (x86_64-linux-gnu) compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 gives this time report: Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 182 kB ( 0%) phase parsing : 0.05 ( 0%) 0.00 ( 0%) 0.08 ( 0%) 7841 kB ( 6%) phase opt and generate : 534.57 (100%) 0.45 (100%) 553.90 (100%) 127110 kB ( 94%) dump files : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%) callgraph construction : 0.03 ( 0%) 0.00 ( 0%) 0.06 ( 0%) 4906 kB ( 4%) ipa function summary : 0.13 ( 0%) 0.00 ( 0%) 0.09 ( 0%) 5 kB ( 0%) ipa pure const : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) ipa icf: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) ipa free inline summary: 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%) cfg cleanup: 487.98 ( 91%) 0.04 ( 9%) 503.57 ( 91%) 1045 kB ( 1%) trivially dead code: 0.10 ( 0%) 0.00 ( 0%) 0.10 ( 0%) 0 kB ( 0%) df scan insns : 0.08 ( 0%) 0.03 ( 7%) 0.10 ( 0%) 0 kB ( 0%) df multiple defs : 0.10 ( 0%) 0.00 ( 0%) 0.10 ( 0%) 0 kB ( 0%) df reaching defs : 0.29 ( 0%) 0.01 ( 2%) 0.31 ( 0%) 0 kB ( 0%) df live regs : 1.07 ( 0%) 0.00 ( 0%) 1.14 ( 0%) 0 kB ( 0%) df live regs : 0.26 ( 0%) 0.00 ( 0%) 0.29 ( 0%) 0 kB ( 0%) df must-initialized regs : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%) df use-def / def-use chains: 0.12 ( 0%) 0.00 ( 0%) 0.12 ( 0%) 0 kB ( 0%) df live reg subwords : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) df reg dead/unused notes : 0.79 ( 0%) 0.01 ( 2%) 0.87 ( 0%) 4881 kB ( 4%) register information : 0.19 ( 0%) 0.00 ( 0%) 0.19 ( 0%) 0 kB ( 0%) alias analysis : 0.26 ( 0%) 0.00 ( 0%) 0.26 (
[Bug fortran/71783] [5/6/7 Regression ] ICE on valid code in gimplify_var_or_parm_decl at gimplify.c:1801
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71783 --- Comment #13 from Toon Moene --- On 07/11/2016 10:26 PM, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71783 > > Thomas Koenig changed: > >What|Removed |Added > > Status|WAITING |RESOLVED > Resolution|--- |FIXED > > --- Comment #12 from Thomas Koenig --- > (In reply to Martin Liška from comment #11) >> (In reply to Thomas Koenig from comment #10) >>> Fixed on 5/6/7. I don't have a working 4.9 compiler at the moment. >>> >>> Could anybody check if the fix also needs to be applied there? >> >> 4.9 is not affected by the PR. > > Thanks. > > Closing. > Thanks for working on this !
[Bug fortran/71783] [5/6/7 Regression ] ICE on valid code in gimplify_var_or_parm_decl at gimplify.c:1801
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71783
--- Comment #6 from Toon Moene ---
On 07/08/2016 11:15 PM, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71783
>
> --- Comment #3 from Thomas Koenig ---
> The solution turns that fixes the ICE turns out to be reasonably simple: We
> were missing a charlen for the allocatable case.
>
> What I do not yet understand is why this code was reached in the first place;
> the temporary assignment should never happen for this case.
>
> Index: frontend-passes.c
> ===
> --- frontend-passes.c (Revision 237949)
> +++ frontend-passes.c (Arbeitskopie)
> @@ -665,12 +665,10 @@ create_var (gfc_expr * e, const char *vname)
> {
>gfc_expr *length;
>
> + symbol->ts.u.cl = gfc_new_charlen (ns, NULL);
>length = constant_string_length (e);
>if (length)
> - {
> - symbol->ts.u.cl = gfc_new_charlen (ns, NULL);
> - symbol->ts.u.cl->length = length;
> - }
> + symbol->ts.u.cl->length = length;
>else
> symbol->attr.allocatable = 1;
> }
>
> Toon, does this fix the ICE for you as well?
This works for me on trunk - it is hard to see whether it invokes
regressions, because those have been varying with various targets ...
Nevertheless, looks OK as a solution.
Thanks,
[Bug fortran/71783] New: ICE on valid code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71783 Bug ID: 71783 Summary: ICE on valid code. Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: toon at moene dot org Target Milestone: --- Created attachment 38843 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38843=edit The code leading to the ICE. The following code: SUBROUTINE prtdata(ilen) INTEGER :: ilen character(len=ilen), allocatable :: cline(:) allocate(cline(2)) cline(1) = 'a' cline(2) = cline(1) END SUBROUTINE prtdata leads to an Internal Compiler Error in both 5.4 and 6.1 (and possibly previous versions.
[Bug fortran/71717] New: A gfortran silent "wrong code" bug in the transition from 4.9.0 -> 4.9.1, using OpenMP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71717
Bug ID: 71717
Summary: A gfortran silent "wrong code" bug in the transition
from 4.9.0 -> 4.9.1, using OpenMP.
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: toon at moene dot org
Target Milestone: ---
Created attachment 38805
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38805=edit
The (reduced) failing code.
The attached code shows that code that worked with gfortran -fopenmp in 4.9.0
doesn't work with 4.9.1 anymore.
As 4.9.1 introduced the OpenMP standard 4, it might be related to that update.
Compile the attached code with gfortran -fopenmp .
The output of the executable should be four zeros.
[Bug libfortran/63460] New: Some namelists cannot be read from stdin (unit 5): Fortran runtime error: End of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63460 Bug ID: 63460 Summary: Some namelists cannot be read from stdin (unit 5): Fortran runtime error: End of file Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: toon at moene dot org The following Fortran program, when compiled with gfortran 4.9.1 or trunk (5.0), cannot read a valid namelist file from stdin (unit 5). Reading it from another unit (or as an internal file) proceeds fine. Fortran program: character*10 file /'noot.hdf'/ character*5 aap(10) /10*/ integer par(10) /10*3/ namelist /namlis/ file, aap, par read (5, namlis) write(6, namlis) end Namelist file (which is redirected to stdin): NAMLIS file='aap.hdf', aap(5)='noot', par(5)=6 /
[Bug fortran/51310] -finit-bla doesn't initialize *all* items of type bla to the requested constant.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310 Toon Moene toon at moene dot org changed: What|Removed |Added Severity|normal |enhancement --- Comment #6 from Toon Moene toon at moene dot org 2011-12-08 21:01:06 UTC --- The bugs in the documentation have been fixed, so now it is an enhancement to a set of debugging compiler flags.
[Bug fortran/51310] -finit-bla doesn't initialize *all* items of type bla to the requested constant.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310 Toon Moene toon at moene dot org changed: What|Removed |Added Attachment #25948|0 |1 is obsolete|| Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-05 AssignedTo|unassigned at gcc dot |toon at moene dot org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Toon Moene toon at moene dot org 2011-12-05 18:17:14 UTC --- Created attachment 25996 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25996 A patch to the documentation that actually passes a build I'll submit this patch to fort...@gcc.gnu.org for approval. After that's done, and the patch is committed, I'll leave the bug report open to see if I can fix some of the shortcomings.
[Bug fortran/51310] -finit-bla doesn't initialize *all* items of type bla to the requested constant.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310 --- Comment #3 from Toon Moene toon at moene dot org 2011-12-05 20:04:21 UTC --- At first I thought that gfortran would initialize small local arrays to whatever -finit-real indicated by making them static, instead of stack based. However, perusing the assembler output of subroutine sub real a(3) print*,a end (as a diff between gfortran -S and gfortran -S -finit-real=snan): 17c17,27 movq$.LC0, -536(%rbp) --- movl$1, %eax .L3: cmpq$3, %rax jg .L2 leaq-1(%rax), %rdx movl$0x7fa0, %ecx movl%ecx, -16(%rbp,%rdx,4) addq$1, %rax jmp .L3 .L2: and checking with a small main program call sub end that the output is really different: $ ./a.out 1.12103877E-44 0.000 9.80908925E-45 vs: $ ./a.out NaN NaN NaN convinced me otherwise. So one wonders why that doesn't work with variable length automatic arrays (or why it would even be hard to initialize malloc'd automatic arrays / allocatables). This quest to be continued (do you think coconuts migrate ? No - but they could be carried.).
[Bug fortran/51310] -finit-bla doesn't initialize *all* items of type bla to the requested constant.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310 --- Comment #1 from Toon Moene toon at moene dot org 2011-11-29 19:37:19 UTC --- Created attachment 25948 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25948 Untested patch to the documentation This is a completely untested patch to the documentation, as I cannot build gcc trunk on Debian testing since August. Perhaps someone else can review it as to: - Correct texi syntax. - Correct contents :-) Thanks,
[Bug fortran/51310] New: -finit-bla doesn't initialize *all* items of type bla to the requested constant.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310 Bug #: 51310 Summary: -finit-bla doesn't initialize *all* items of type bla to the requested constant. Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@moene.org The following source: program nan implicit none real(8) :: joo(3) joo(2) = 0 print *,joo call sub(3) end program nan subroutine sub(n) implicit none integer, intent(in) :: n real(8) :: a(n), var, b(3) real(8), allocatable :: c(:) !a(1) = 1 print *,'n=',n print *,'a=',a print *,'var=',var print *,'b=',b allocate(c(size(b))) print *,'c=',c a(1) = a(1) + 1 end subroutine sub when compiled with gfortran -g -finit-real=snan outputs: NaN 0.NaN n= 3 a= 0.0.0. var= NaN b= NaN NaN NaN c= 0.0.0. Clearly, the allocatable c and the automatic array a are not initialized by the compiler option. 1. Consider this an enhancement request - a colleague of mine was severely hampered in his search for a bug. 2. Consider this a bug report with respect to our documentation, which doesn't mention this exceptions at all.
[Bug middle-end/50178] New: [4.6 regression] ICE with gfortran -O3, not with gfortran -02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178 Bug #: 50178 Summary: [4.6 regression] ICE with gfortran -O3, not with gfortran -02 Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@moene.org Created attachment 25089 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25089 Source code of the failing compilation. Compiling the attached source code with gfortran 4.6.1 using optimization -O3 leads to the following Internal Compiler Error: $ gfortran -O3 -c suedyn.f90 suedyn.f90: In function ‘suedyn’: suedyn.f90:10:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Compiling with -O2 instead succeeds (hence my suspicion that it is a middle-end failure).
[Bug middle-end/50178] [4.6 regression] ICE with gfortran -O3, not with gfortran -02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178 Toon Moene toon at moene dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-24 Ever Confirmed|0 |1 --- Comment #1 from Toon Moene toon at moene dot org 2011-08-24 17:21:23 UTC --- The source code as attached is much reduced from the original, courtesy of Steve Kargl. Dominique Dhumieres wrote: It started to fail between revisions 158105 and 158252 and it has been fixed on 4.7 between revisions 174599 and 175148. in this note: http://gcc.gnu.org/ml/fortran/2011-08/msg00198.html
[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149 --- Comment #6 from Toon Moene toon at moene dot org 2011-05-08 13:15:44 UTC --- Well, that was a bit too quick (careful which compiler you are using). It works with this compiler: $ /usr/snp/bin/gfortran -v Using built-in specs. COLLECT_GCC=/usr/snp/bin/gfortran COLLECT_LTO_WRAPPER=/usr/snp/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/snp --with-gnu-ld --disable-multilib --disable-nls --with-arch=native --with-tune=native Thread model: posix gcc version 4.7.0 20110417 (experimental) (GCC) and the Debian Testing GNU ld: $ ld -v GNU ld (GNU Binutils for Debian) 2.21.0.20110327 It might still be that it is solved for the released 4.6.0 (that I do not have lying around).
[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149 --- Comment #5 from Toon Moene toon at moene dot org 2011-05-08 13:00:33 UTC --- The bug does not manifest itself with the default compiler and linker on a recent version of Debian Testing: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.2-11' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.5.2 (Debian 4.5.2-11) $ ld.gold -v GNU gold (GNU Binutils for Debian 2.21.0.20110327) 1.11 $ ld -v GNU ld (GNU Binutils for Debian) 2.21.0.20110327 so perhaps this has been fixed in GCC 4.5.3 and ld 2.21.
[Bug lto/44149] lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
--- Comment #2 from toon at moene dot org 2010-05-16 18:35 --- Created an attachment (id=20675) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20675action=view) reduced test case A reduced test case that failes in the same way. -- toon at moene dot org changed: What|Removed |Added Attachment #20664|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug lto/44149] lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
--- Comment #3 from toon at moene dot org 2010-05-16 18:51 ---
It might be useful to compare the two decls that invoke the mismatch that
triggers the gcc_assert:
prevailing-decl is:
function_decl 0x7fb0f574f900 convect_satmixratio
type function_type 0x7fb0f5786b28
type void_type 0x7fb0f584cd20 VOID
align 8 symtab 0 alias set -1 canonical type 0x7fb0f584cd20
pointer_to_this pointer_type 0x7fb0f584cdc8
QI
size integer_cst 0x7fb0f583d758 constant 8
unit size integer_cst 0x7fb0f583d780 constant 1
align 8 symtab 0 alias set -1 canonical type 0x7fb0f5786b28
public external QI file bkfconv.f90 line 517 col 0 align 8
whereas e-decl is:
function_decl 0x7fb0f574f600 convect_satmixratio
type function_type 0x7fb0f5763b28
type void_type 0x7fb0f584cd20 VOID
align 8 symtab 0 alias set -1 canonical type 0x7fb0f584cd20
pointer_to_this pointer_type 0x7fb0f584cdc8
QI
size integer_cst 0x7fb0f583d758 constant 8
unit size integer_cst 0x7fb0f583d780 constant 1
align 8 symtab 0 alias set -1 canonical type 0x7fb0f5763b28
arg-types tree_list 0x7fb0f5754bb8 value reference_type
0x7fb0f5750738
chain tree_list 0x7fb0f5754be0 value pointer_type 0x7fb0f5763bd0
chain tree_list 0x7fb0f5754c08 value pointer_type
0x7fb0f5764000
chain tree_list 0x7fb0f5754c30 value pointer_type
0x7fb0f57643f0
chain tree_list 0x7fb0f5754c58 value pointer_type
0x7fb0f57647e0 chain tree_list 0x7fb0f5754c80
nothrow public static QI file bkfconv.f90 line 400 col 0 align 8
arguments parm_decl 0x7fb0f5760660 klon
type reference_type 0x7fb0f5750738 type integer_type 0x7fb0f584c498
unsigned restrict DI
size integer_cst 0x7fb0f583da50 constant 64
unit size integer_cst 0x7fb0f583da78 constant 8
align 64 symtab 0 alias set -1 canonical type 0x7fb0f5750738
readonly used unsigned DI passed-by-reference file bkfconv.f90 line 400
col 0 size integer_cst 0x7fb0f583da50 64 unit size integer_cst
0x7fb0f583da78 8
align 64 context function_decl 0x7fb0f574f600 convect_satmixratio
arg-type reference_type 0x7fb0f5750738
chain parm_decl 0x7fb0f57606e8 ppres type pointer_type
0x7fb0f57653f0
readonly used unsigned DI passed-by-reference file bkfconv.f90 line
400 col 0 size integer_cst 0x7fb0f583da50 64 unit size integer_cst
0x7fb0f583da78 8
align 64 context function_decl 0x7fb0f574f600 convect_satmixratio
arg-type pointer_type 0x7fb0f5763bd0 chain parm_decl 0x7fb0f5760770 pt
result result_decl 0x7fb0f5752180 D.2157 type void_type 0x7fb0f584cd20
ignored VOID file bkfconv.f90 line 400 col 0
align 8 context function_decl 0x7fb0f574f600 convect_satmixratio
This is found by adding the following to lto-symtab.c:
$ svn diff
Index: lto-symtab.c
===
--- lto-symtab.c(revision 159454)
+++ lto-symtab.c(working copy)
@@ -603,8 +603,15 @@
/* Assert it's the only one. */
if (prevailing)
for (e = prevailing-next; e; e = e-next)
- gcc_assert (e-resolution != LDPR_PREVAILING_DEF_IRONLY
- e-resolution != LDPR_PREVAILING_DEF);
+ {
+ if (!(e-resolution != LDPR_PREVAILING_DEF_IRONLY
+ e-resolution != LDPR_PREVAILING_DEF))
+{
+ debug_tree(prevailing-decl);
+ debug_tree(e-decl);
+ gcc_assert(0);
+}
+ }
/* If there's not a prevailing symbol yet it's an external reference.
Happens a lot during ltrans. Choose the first symbol with a
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug lto/44149] New: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
The attached subroutine is compiled as follows: gfortran -c -flto -O2 -fwhole-program bkfconv.F90 and then the object file is placed in a library of its own: ar rv x.a bkfconv.o Subsequently, a main program, b.f: call deep_convection end is linked with this library, as follows: gfortran -fuse-linker-plugin -flto -O2 -fwhole-program b.f x.a This results in the ICE in the subject. gfortran -v Using built-in specs. COLLECT_GCC=/usr/snp/bin/gfortran COLLECT_LTO_WRAPPER=/usr/snp/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-checking=release --prefix=/usr/snp --enable-gold --enable-plugins --disable-multilib --disable-nls --with-arch-64=native --with-tune-64=native --enable-languages=fortran,c++ --enable-stage1-languages=c++ --disable-werror Thread model: posix gcc version 4.6.0 20100514 (experimental) (GCC) ld -v GNU gold (GNU Binutils 2.20.51.20100506) 1.9 -- Summary: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot org GCC host triplet: x64_86-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug lto/44149] lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
--- Comment #1 from toon at moene dot org 2010-05-15 09:32 --- Created an attachment (id=20664) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20664action=view) source code that shows the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug fortran/40998] Source with routine in CONTAINS section and a local variable: No symbol nerr in current context
--- Comment #7 from toon at moene dot org 2010-03-20 09:39 --- Works when using Debian's version of gfortran 4.4.3 and their gdb (version 7.0.1). -- toon at moene dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40998
[Bug fortran/42848] compiler crashes and asks for this bug report
--- Comment #2 from toon at moene dot org 2010-01-23 13:24 --- Tobias, If we ask a bug submitter for more information, or to confirm our suspicions, we put the bug report in WAITING. Note to submitter: bug reports with status WAITING will be closed if not replied to within 3 months. Kind regards. -- toon at moene dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42848
[Bug libfortran/33905] show_backtrace hangs on SIGSEGV in malloc/free
--- Comment #5 from toon at moene dot org 2009-12-17 21:58 --- (Even with a temporary file, other things can go wrong!) Paul, you are right - I agree with FX, but forgot to reply. Closing as WONTFIX is OK with me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33905
[Bug fortran/42131] Weird translation of DO loops
--- Comment #12 from toon at moene dot org 2009-11-24 18:03 --- Any tricks I have missed? Yes - we could provide for loop versioning in the front end. I.e., generate code like: IF (M3 0) THEN ... compute loop count ... ... perform loop ... ELSE IF (M3 0) THEN ... compute loop count ... ... perform loop ... ELSE ABORT M3 MUST NOT BE ZERO ENDIF And then hope that Value Range Propagation and InterProcedural Analysis will throw away 2 of the 3 branches of this loop because it is able to determine the sign of M3. evil grin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug fortran/42131] Weird translation of DO loops
--- Comment #9 from toon at moene dot org 2009-11-22 10:20 --- Richard wondered about this earlier: countm1.1 = (character(kind=4)) (D.1337 - D.1336) / (character(kind=4)) D.1338; but perhaps it's better to asked explicitly: Where does the (character(kind=4)) comes from in this (obvious) integer computation ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #15 from toon at moene dot org 2009-11-21 12:11 --- I don't see that the standard suggests the specific code the Frontend generates. In fact it should be valid to increment the DO variable by m3 and express the exit test in terms of the DO variable as well. The Standard doesn't prescribe the code the Frontend generates - however, to be sure one follows the Standard, it's most easy to simply implement the steps given. To illustrate this with a simple example: DO I = M1, M2, M3 B(I) = A(I) ENDDO would be most easily, and atraightforwardly, implemented as follows: IF (M3 0 .AND. M1 M2) GOTO 200 ! Loop executed zero times IF (M3 0 .AND. M1 M2) GOTO 200 ! Ditto ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop count I = M1 100 CONTINUE B(I) = A(I) ITEMP = ITEMP - 1 ! Adjust internal loop counter I = I + M3 ! Adjust DO loop variable IF (ITEMP 0) GOTO 100 200 CONTINUE That there are two induction variables in this loop is inconsequential - one of them should be eliminated by induction variable elimination (at least, that was the case with g77 and the RTL loop optimization pass). If you think that the Frontend does something different / in addition to the above, feel free to open a separate PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug fortran/42131] Weird translation of DO loops
--- Comment #2 from toon at moene dot org 2009-11-21 17:33 --- Sorry, Steve - my mistake. The original message should have been: To illustrate this with a simple example: DO I = M1, M2, M3 B(I) = A(I) ENDDO would be most easily, and straightforwardly, implemented as follows: IF (M3 0 .AND. M1 M2) GOTO 200 ! Loop executed zero times IF (M3 0 .AND. M1 M2) GOTO 200 ! Ditto ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop counter I = M1 100 CONTINUE B(I) = A(I) ITEMP = ITEMP - 1 ! Adjust internal loop counter I = I + M3 ! Adjust DO loop variable IF (ITEMP = 0) GOTO 100 200 CONTINUE I hope this makes clear what's weird about the way the Fortran Frontend does it now. The example code follows the Standard as close as possible (it only doesn't check that m3 isn't zero, which isn't allowed), except that I follow Note 8.7 instead of the reasoning in the sequence of steps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug fortran/42131] Weird translation of DO loops
--- Comment #5 from toon at moene dot org 2009-11-21 21:40 ---
The middle-end prefers do { } while () loop style so it knows the loop is
always executed.
And the Fortran Standard describes the loops being built (by compilers) just
so:
1. First you determine what is m1, m2, m3
2. Then you initialize the do loop counter with m1
3. Then you determine the loop count (m2 - m1 + m3) / m3
4. If the loop count is zero or negative, you skip the loop
5. Otherwise, you traverse the loop body at least once.
Or, to return to our example (and fix the mistake Thomas Koenig noted):
DO I = M1, M2, M3
B(I) = A(I)
ENDDO
turns into
ITEMP = (M2 - M1 + M3) / M3 ! The iteration count
IF (ITEMP = 0) GOTO 200 ! Past this point, the loop is executed
I = M1 ! at least once.
100 CONTINUE
B(I) = A(I)
ITEMP = ITEMP - 1
I = I + M3
IF (ITEMP 0) GOTO 100
200 CONTINUE
therewith following the (normative) text of the Standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #13 from toon at moene dot org 2009-11-20 19:45 --- The funny conditional initialization of countm1.6 makes the analysis of the number of iterations of this loop impossible (not to mention the conversions to character(kind=4)). Why does the frontend do induction variable optimization at all and not simply generate a loop with a non-unit counting IV? It's not trying to be funny - it just follows the text of the Fortran Standard (hey, what a concept !): 12 8.1.6.6.1Loop initiation 13 1 When the DO statement is executed, the DO construct becomes active. If loop-control is 14 2 [ , ] do-variable = scalar-int-expr 1 , scalar-int-expr 2 [ , scalar-int-expr 3 ] 15 3 the following steps are performed in sequence. 16 (1)The initial parameter m1 , the terminal parameter m2 , and the incrementation parameter m3 are 17 of type integer with the same kind type parameter as the do-variable. Their values are established 18 by evaluating scalar-int-expr 1 , scalar-int-expr 2 , and scalar-int-expr 3 , respectively, including, if ne- 19 cessary, conversion to the kind type parameter of the do-variable according to the rules for numeric 20 conversion (Table 7.11). If scalar-int-expr 3 does not appear, m3 has the value 1. The value of m3 21 shall not be zero. 22 (2)The DO variable becomes defined with the value of the initial parameter m1 . 23 (3)The iteration count is established and is the value of the expression (m2 - m1 + m3 )/m3 , unless that 24 value is negative, in which case the iteration count is 0. Only interprocedural analysis can tell us that this is a simple loop only executed 3 times (I got this wrong at first - it's *always* executed 3 times). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #6 from toon at moene dot org 2009-11-19 19:53 --- Richard Guenther wrote: Well, within eval there's nothing really obvious to me. The innermost loop is exactly the same: But it is a very inefficient way of vectorizing, because the inner loop's body is either executed twice or three times per outer loop (depending on the value of i). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug lto/41871] New: lto-plugin gives: could not open/create temporary file
This might be a limit-on-number-of-open-files issue. I encounter it while trying to link with link time optimization *and* using the linker plugin an executable which needs loads of object files from two dozen libraries. To study this, use a program that's build from libraries and linked as follows: gcc [optimization options] -flto -fwhole-program -fuse-linker-plugin -o exe mainprogram.c lib1.a lib2.a ... libn.a To enforce the limit, use the following command in bash ulimit -n some small number around 20 -- Summary: lto-plugin gives: could not open/create temporary file Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41871
[Bug lto/41654] New: ICE: in gimple_cond_get_ops_from_tree, at gimple.c:417
The attached routine (scanbufr.f) draws the following ICE when compiled with -c -O3 -flto: scanbufr.f90: In function 'scanbufr_': scanbufr.f90:3:0: internal compiler error: in gimple_cond_get_ops_from_tree, at gimple.c:417 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Compiling with -O1 instead of -O3 completes normally. -- Summary: ICE: in gimple_cond_get_ops_from_tree, at gimple.c:417 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41654
[Bug lto/41654] ICE: in gimple_cond_get_ops_from_tree, at gimple.c:417
--- Comment #1 from toon at moene dot org 2009-10-10 09:26 --- Created an attachment (id=18770) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18770action=view) Source code that elicits the error. Added source code that evokes error. It is a .f90 source, not .f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41654
[Bug lto/41654] ICE: in gimple_cond_get_ops_from_tree, at gimple.c:417
--- Comment #2 from toon at moene dot org 2009-10-10 09:50 --- (From update of attachment 18770) Wrong (incomplete) source. -- toon at moene dot org changed: What|Removed |Added Attachment #18770|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41654
[Bug lto/41654] ICE: in gimple_cond_get_ops_from_tree, at gimple.c:417
--- Comment #3 from toon at moene dot org 2009-10-10 09:52 --- Created an attachment (id=18771) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18771action=view) Source code that elicits the error. This is the complete source evoking the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41654
[Bug lto/41566] New: ICE with -g -O3, no ICE without -g
The attached bzip2'd tar file unpacks into a directory pgb2as-lto. To build, change to that directory, then do: $ for f in *.f *.c; do gfortran -c -g -O3 -flto $f; done $ rm pgb2as.o $ ar rv lib.a *.o $ ranlib lib.a $ gfortran -g -O3 -flto pgb2as.f lib.a This results in: In function 'pgb2as': lto1: internal compiler error: in gimple_call_fndecl, at gimple.h:1960 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /usr/snp/bin/gfortran returned 1 exit status collect2: lto-wrapper returned 1 exit status Removing the -g option in the above sequence of commands makes it work. -- Summary: ICE with -g -O3, no ICE without -g Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41566
[Bug lto/41566] ICE with -g -O3, no ICE without -g
--- Comment #1 from toon at moene dot org 2009-10-04 13:09 --- Created an attachment (id=18701) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18701action=view) Test case bzip2'd tar file with test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41566
[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.
--- Comment #6 from toon at moene dot org 2009-09-20 17:03 --- It seems we have exhausted the arguments in this case. The best cause of action seems to be to document that gfortran won't allow to open dangling symlinks with STATUS='NEW'. This bug report remains open until that is done. -- toon at moene dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |toon at moene dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-20 17:03:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387
[Bug libfortran/41387] New: OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.
The following program: OPEN(UNIT=1,FILE='noot',STATUS='NEW') END when compiled/linked into a.out and run as follows: $ rm aap $ ln -s aap noot $ ./a.out gives: At line 1 of file a.f (unit = 1, file = '') Fortran runtime error: File 'noot' already exists Other compilers (tested: xlf (IBM) and ifort (Intel)) permit to open a non-existing file as 'NEW' this way. The reason our run-time library doesn't is that in io/unix.c, we open a 'NEW' file with open(, O_CREAT | O_EXCL, ...). The man page of open says about O_EXCL: O_EXCL Ensure that this call creates the file: if this flag is specified in conjunction with O_CREAT, and pathname already exists, then open() will fail. The behavior of O_EXCL is undefined if O_CREAT is not specified. When these two flags are specified, symbolic links are not followed: if pathname is a symbolic link, then open() fails regardless of where the symbolic link points to. -- Summary: OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387
[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.
--- Comment #1 from toon at moene dot org 2009-09-17 13:26 --- Perhaps the system call 'access' can provide help here. From the man page (man 2 access): access() checks whether the calling process can access the file pathname. If pathname is a symbolic link, it is dereferenced. The mode specifies the accessibility check(s) to be performed, and is either the value F_OK, or a mask consisting of the bitwise OR of one or more of R_OK, W_OK, and X_OK. F_OK tests for the existence of the file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387
[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.
--- Comment #4 from toon at moene dot org 2009-09-17 19:57 ---
In response to reply 2 (thanks Steve), we might be able to exploit the system
call access to at least solve the inconsistency between INQUIRE and OPEN:
man 2 access
ENOENT A component of pathname does not exist or is a dangling symbolic
link.
IOW, if we check for this (instead of requesting a stat buffer), we might be
able to answer the question consistently with OPEN.
See libgfortran/io/unix.c:
1376 /* file_exists()-- Returns nonzero if the current filename exists on
1377 * the system */
1378
1379 int
1380 file_exists (const char *file, gfc_charlen_type file_len)
1381 {
1382 char path[PATH_MAX + 1];
1383 struct stat statbuf;
1384
1385 if (unpack_filename (path, file, file_len))
1386 return 0;
1387
1388 if (stat (path, statbuf) 0)
1389 return 0;
1390
1391 return 1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387
[Bug libfortran/39668] Wrongly read namelist with two dimensional array.
--- Comment #7 from toon at moene dot org 2009-08-18 16:40 --- The relevant wording in the Standard (2003) is: 9.5.3.4 Data transfer ... The list items for a namelist input statement are processed in the order of the entities specified within the input records. ... To spell it out for this example: 1 is assigned to i(1,1) 2 is assigned to i(2,1) ! Array element order, as no other order is specified. 3 is assigned to i(3,1) ! Ditto. 4 is assigned to i(2,1) ! Overwriting the 2 that was there. 5 is assigned to i(3,1) ! Overwriting the 3 that was there. 6 is assigned to i(2,2) ! Got that ? 7 is assigned to i(3,1) ! Overwriting the 5 that was there. 8 is assigned to i(3,2) ! Hah ! 9 is assigned to i(3,3) ! So there ! i(1,2), i(1,3) and i(2,3) are never set via the namelist I/O and remain at 0. So printing the namelist will get you: 1, 4, 7, 0 (=i(1,2)), 6, 8, 0 (=i(1,3)), 0 (=i(2,3)), 9 which seems perfectly OK with me. Closing the bug report as INVALID, i.e., not a bug. -- toon at moene dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
[Bug fortran/40998] Source with routine in CONTAINS section and a local variable: No symbol nerr in current context
--- Comment #5 from toon at moene dot org 2009-08-07 16:58 --- Could indeed be the version of gdb. Mine is: $ gdb -v GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. which seems to be a bog standard 6.8 gdb (from 2008). So perhaps it's not gfortran's fault, but a short-coming in not totally up-to-date gdb's Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40998
[Bug tree-optimization/40801] New: internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1096
The attached Fortran source fails to compile with the error message mentioned in the summary. Revision (4.5.0 experimental): 149775 Compile flags: -g -c -O3 -ffast-math -fdefault-real-8 -fdefault-double-8 -- Summary: internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect- stmts.c:1096 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40801
[Bug tree-optimization/40801] internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1096
--- Comment #1 from toon at moene dot org 2009-07-18 18:28 --- Created an attachment (id=18220) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18220action=view) Source code that elicits the error. Not reduced (sorry). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40801
[Bug middle-end/40328] New: internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1811
The attached Fortran source, when compiled with a recent version of the trunk, gives the above ICE. Compile options: -O3 -c. -- Summary: internal compiler error: in set_ssa_val_to, at tree- ssa-sccvn.c:1811 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40328
[Bug middle-end/40328] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1811
--- Comment #5 from toon at moene dot org 2009-06-03 12:55 --- It works for the testcase with your change (over revision 148127). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40328
[Bug libfortran/39668] Wrongly read namelist with two dimensional array.
--- Comment #5 from toon at moene dot org 2009-05-05 13:33 --- Hmm, I said I'd put it in waiting until I found the definite wording in the Standard about this use of namelist values ... -- toon at moene dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
[Bug libfortran/39668] Wrongly read namelist with two dimensional array.
--- Comment #3 from toon at moene dot org 2009-04-07 18:41 --- Note that the namelist is overwriting earlier assignments, so it's doubtful it's legal Fortran. The original that got my colleague questioning gfortran was: namtest i(1,:)=1,2,3, i(2,:)=4,5,6, i(3,:)=7,8,9, / which, using gfortran version 4.3.3, gave the same (but for this example wrong) results as the namelist submitted in this bug report. gfortran 4.[45] does *this* one right. So it might be a red herring - put bug report in waiting until I figured out the exact language in the Standard that either allows or disallows the original namelist. -- toon at moene dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
[Bug libfortran/39668] New: Wrongly read namelist with two dimensional array.
Fortran code: INTEGER :: i(3,3) namelist/namtest/i i=0 OPEN(10) CLOSE(10) READ(10,namtest) WRITE(6,namtest) END Namelist in fort.10: namtest i(1,1)=1,2,3, i(2,1)=4,5,6, i(3,1)=7,8,9, / Print out of program: NAMTEST I= 1, 4, 7, 0, 6, 8, 2*0 , 9, / Output should have been: NAMTEST I= 1, 4, 7, 2, 5, 8, 3, 6, 9, / -- Summary: Wrongly read namelist with two dimensional array. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
[Bug libfortran/33905] show_backtrace hangs on SIGSEGV in malloc/free
--- Comment #2 from toon at moene dot org 2009-03-29 13:36 --- I'll try to come up with a bug report this week (the original case is much to complicated to use as an example). However, it might take some time and it also might be system dependent to trigger this event. It's clear, however, from the way you implemented the traceback feature that it is possible to hit this snag - it's just that not many people will hit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33905
