[Bug fortran/39945] New: -fopenmp causes runtime crash on assigning reasonably large array
The attached very simple program crashes at runtime if compiled with -fopenmp if the variable m is sufficiently large. -- Summary: -fopenmp causes runtime crash on assigning reasonably large array Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: KnowlesPJ at Cardiff dot ac dot uk GCC build triplet: i386-apple-darwin9.2.2 GCC host triplet: i386-apple-darwin9.2.2 GCC target triplet: i386-apple-darwin9.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39945
[Bug fortran/39945] -fopenmp causes runtime crash on assigning reasonably large array
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2009-04-28 14:30 --- Created an attachment (id=17774) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17774action=view) sample source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39945
[Bug fortran/39945] -fopenmp causes runtime crash on assigning reasonably large array
--- Comment #2 from KnowlesPJ at Cardiff dot ac dot uk 2009-04-28 14:32 --- $ gfortran -v Using built-in specs. Target: i386-apple-darwin9.2.2 Configured with: ../configure --prefix=/opt/gcc --with-languages=c,fortran Thread model: posix gcc version 4.4.0 20080424 (experimental) (GCC) $ gfortran -g -fopenmp openmp_compiler_bug.f90 ./a.out Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39945
[Bug fortran/39945] -fopenmp causes runtime crash on assigning reasonably large array
--- Comment #5 from KnowlesPJ at Cardiff dot ac dot uk 2009-04-28 14:53 --- O, now I see my stupidity, as for some reason ulimit -s is set to a pathetic 8192k. I am sorry to have troubled you folks with this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39945
[Bug fortran/39594] [4.4/4.5 Regression] compiler falls over in gfc_get_symbol_decl
--- Comment #12 from KnowlesPJ at Cardiff dot ac dot uk 2009-04-02 19:49 --- It's a pleasure, and also amazing to see you folks work so quickly on this. The context for the report is our large code (http://www.molpro.net) which hopefully now for the first time will build correctly with released gcc on linux and Darwin. Lots of our users will be happy about this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39594
[Bug fortran/39594] New: compiler falls over in gfc_get_symbol_decl
$ /usr/local/gfortran/bin/gfortran --save-temps -c -fno-second-underscore -fdefault-integer-8 -m64 -DMOLPRO -I. -I.. -I../global f12_integrals.f f12_integrals.f: In function 'dfasmbl_f12': f12_integrals.f:2850: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:950 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ gfortran -v Using built-in specs. Target: i386-apple-darwin8.10.1 Configured with: /tmp/gfortran-20090321/ibin/../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20090321/gfortran_libs --enable-bootstrap Thread model: posix gcc version 4.4.0 20090321 (experimental) [trunk revision 144983] (GCC) -- Summary: compiler falls over in gfc_get_symbol_decl Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: KnowlesPJ at Cardiff dot ac dot uk GCC build triplet: i386-apple-darwin8.10.1 GCC host triplet: i386-apple-darwin8.10.1 GCC target triplet: i386-apple-darwin8.10.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39594
[Bug fortran/39594] compiler falls over in gfc_get_symbol_decl
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2009-03-31 08:13 --- Created an attachment (id=17566) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17566action=view) tarball containing source file and its includes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39594
[Bug fortran/39595] New: gfortran falls over in optimization
$ /usr/local/gfortran/bin/gfortran -c -fno-second-underscore -fdefault-integer-8 -m64 -DMOLPRO -I. -I.. -I../global -O3 dftgrid.f dftgrid.f: In function 'grid_neighbour_dint': dftgrid.f:4288: internal compiler error: vector VEC(tree,base) index domain error, in vectorizable_store at tree-vect-transform.c:5358 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. $ gfortran -v Using built-in specs. Target: i386-apple-darwin8.10.1 Configured with: /tmp/gfortran-20090321/ibin/../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20090321/gfortran_libs --enable-bootstrap Thread model: posix gcc version 4.4.0 20090321 (experimental) [trunk revision 144983] (GCC) $ /usr/local/gfortran/bin/gfortran -c -fno-second-underscore -fdefault-integer-8 -m64 -DMOLPRO -I. -I.. -I../global -O2 dftgrid -- Summary: gfortran falls over in optimization Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: KnowlesPJ at Cardiff dot ac dot uk GCC build triplet: i386-apple-darwin8.10.1 GCC host triplet: i386-apple-darwin8.10.1 GCC target triplet: i386-apple-darwin8.10.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39595
[Bug fortran/39595] gfortran falls over in optimization
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2009-03-31 08:24 --- Created an attachment (id=17567) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17567action=view) source and includes that demonstrate the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39595
[Bug fortran/39594] compiler falls over in gfc_get_symbol_decl
--- Comment #3 from KnowlesPJ at Cardiff dot ac dot uk 2009-03-31 10:12 --- My apologies that I did not do some reduction, which of course I could have easily done. I was merely following the guidelines at http://gcc.gnu.org/bugs.html which says lots of things, but does not mention this as desirable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39594
[Bug fortran/35892] gfortran lost memory blocks
--- Comment #22 from KnowlesPJ at Cardiff dot ac dot uk 2008-04-25 08:10 --- Yes, this was the silver bullet. With Using built-in specs. Target: i386-apple-darwin9.2.2 Configured with: ../configure --prefix=/opt/gcc Thread model: posix gcc version 4.4.0 20080424 (experimental) (GCC) we now get through the regression tests on our code that were failing before. Thank you to those who have contributed to this - the final piece that was needed for our code (http://www.molpro.net) to work with gfortran on both linux and mac. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug fortran/35892] gfortran lost memory blocks
--- Comment #19 from KnowlesPJ at Cardiff dot ac dot uk 2008-04-24 09:34 --- As the originator of this report, I just wanted to add a context comment in case it is helpful. This construction (common declared both in the module and in subroutines (contained or external)) is horrible, but one of our developers has found it to be the only reasonable way of dragging in a dusty deck. Although the compiler crash was reported, this is not our main interest, since the compiler seems to crash only with -g. Without -g, at any optimization level, we are getting wrong numbers at run time. Abstracting that from the 1.5 million line code for a reasonable test case to report will not be easy, so we are hoping that the fix to the compiler crash will be the silver bullet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug fortran/35892] New: gfortran dies on file containing module and common
Compilation with -O0 -g causes the compiler to crash: /opt/gcc/bin/gfortran -c -fno-second-underscore -fdefault-integer-8 -m64 -g -O0 --save-temps f12_integrals.f f12_integrals.f: In function 'f12_integrals_raw': f12_integrals.f:980: internal compiler error: in expand_expr_real_1, at expr.c:7258 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Using built-in specs. Target: i386-apple-darwin9.2.2 Configured with: ../configure --prefix=/opt/gcc --enable-languages=c,fortran : (reconfigured) ../configure --prefix=/opt/gcc --enable-languages=c,fortran --no-create --no-recursion Thread model: posix gcc version 4.4.0 20080409 (experimental) (GCC) Although gcc -v reports 'i386' this is in fact an x86_64. But compiling on a true ia32 (and omitting -m64) produces the same crash. With -g removed or -O1 the compiler completes. However we are getting wrong results, so perhaps the place to start is with the crash and then try again? -- Summary: gfortran dies on file containing module and common Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: KnowlesPJ at Cardiff dot ac dot uk GCC host triplet: i386-apple-darwin9.2.2 GCC target triplet: i386-apple-darwin9.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug fortran/35892] gfortran dies on file containing module and common
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2008-04-09 17:24 --- Created an attachment (id=15458) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15458action=view) Fortran source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892
[Bug fortran/32155] Unresolved external __gfortran_os_error in program that manipulates strings
--- Comment #4 from KnowlesPJ at Cardiff dot ac dot uk 2007-05-31 11:58 --- The compiler was downloaded from the link in http://hpc.sourceforge.net/ . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32155
[Bug fortran/32155] New: Unresolved external __gfortran_os_error in program that manipulates strings
In the following code, __gfortran_os_error is thrown as unresolved at link time. The trouble goes away if //'=0' is removed. $ cat silly.f character(16) :: str,namx len=4 namx='abcdefg' str=' ' str(7:)=namx(1:len)//'=0' write (6,*) str end $ gfortran silly.f /usr/bin/ld: Undefined symbols: __gfortran_os_error collect2: ld returned 1 exit status $ gfortran -v Using built-in specs. Target: i386-apple-darwin8.9.1 Configured with: ../gcc-4.3-20070518/configure --enable-languages=fortran --enable-static --disable-shared Thread model: posix gcc version 4.3.0 20070518 (experimental) $ uname -a Darwin Peter-Knowles-MacBook.local 8.9.1 Darwin Kernel Version 8.9.1: Thu Feb 22 20:55:00 PST 2007; root:xnu-792.18.15~1/RELEASE_I386 i386 i386 -- Summary: Unresolved external __gfortran_os_error in program that manipulates strings Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: KnowlesPJ at Cardiff dot ac dot uk GCC build triplet: i386-apple-darwin8.9.1 GCC host triplet: i386-apple-darwin8.9.1 GCC target triplet: i386-apple-darwin8.9.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32155
[Bug fortran/32155] Unresolved external __gfortran_os_error in program that manipulates strings
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2007-05-30 13:42 --- Created an attachment (id=13633) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13633action=view) Failing program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32155
[Bug fortran/31725] New: overwriting of neighbouring character array
In the following program, at line 68, array zsymelr is overwritten during the assignment to zsymelr. The output contains 'This should not happen' when the bug is present. Other compilers produce correct output, for which the last line reads 'symelr-symel' $ gfortran -v Using built-in specs. Target: i386-apple-darwin8.9.1 Configured with: ../gcc-4.3-20070316/configure --enable-languages=fortran,c++ Thread model: posix gcc version 4.3.0 20070316 (experimental) -- Summary: overwriting of neighbouring character array Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: KnowlesPJ at Cardiff dot ac dot uk GCC build triplet: i386-apple-darwin8.9.1 GCC host triplet: i386-apple-darwin8.9.1 GCC target triplet: i386-apple-darwin8.9.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31725
[Bug fortran/31725] overwriting of neighbouring character array
--- Comment #1 from KnowlesPJ at Cardiff dot ac dot uk 2007-04-27 10:34 --- Created an attachment (id=13455) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13455action=view) failing program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31725
[Bug fortran/31725] overwriting of neighbouring character array
--- Comment #3 from KnowlesPJ at Cardiff dot ac dot uk 2007-04-27 16:13 --- I don't agree with this analysis, as ll is certainly defined in char3.f as attached - ll=len(s) Please try with the program exactly as supplied! Yes, you are right, this function is the same as len_trim but all I am doing is pulling a small extract from a legacy code and I wanted simply to expose the problem not tidy up. But if I replace lenstr by len_trim the error still occurs. -- KnowlesPJ at Cardiff dot ac dot uk changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31725
[Bug fortran/31696] New: -malign-double trashes fortran format
The following code goes wrong with gfortran -malign-double (but is OK without malign-double) PROGRAM test CHARACTER(80) :: buffer READ (*,1) buffer 1 FORMAT(a) END PROGRAM test $ gfortran -v Using built-in specs. Target: i386-apple-darwin8.9.1 Configured with: ../gcc-4.3-20070316/configure --enable-languages=fortran,c++ Thread model: posix gcc version 4.3.0 20070316 (experimental) $ uname -a Darwin m038.chem.cf.ac.uk 8.9.1 Darwin Kernel Version 8.9.1: Thu Feb 22 20:55:00 PST 2007; root:xnu-792.18.15~1/RELEASE_I386 i386 i386 $ gfortran -malign-double format.f90 $ echo xxx | ./a.out At line 3 of file format.f90 Fortran runtime error: Missing initial left parenthesis in format H å? $ gfortran format.f90 $ echo xxx | ./a.out -- Summary: -malign-double trashes fortran format Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: KnowlesPJ at Cardiff dot ac dot uk GCC build triplet: i386-apple-darwin8.9.1 GCC host triplet: i386-apple-darwin8.9.1 GCC target triplet: i386-apple-darwin8.9.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31696
[Bug fortran/31696] -malign-double trashes fortran format
--- Comment #2 from KnowlesPJ at Cardiff dot ac dot uk 2007-04-25 16:47 --- I don't understand your response, or the assumptions that might be behind it. The program is standard fortran that compiles without warning, and I cannot see why I would not want doubles aligned at 64 bits on x86 hardware, just like all the other compilers, including the other free one, do. Is it written down somewhere that there is no intention to support this mode of operation in the foreseeable future? Google sends me to, for example, http://gcc.gnu.org/ml/fortran/2007-02/msg00026.html which does not undermine my assumptions as unreasonable. If you speak on behalf of the gfortran community in saying you will not address this, then we will simply once again for a while walk away from attempting support of gfortran in our large and widely-used code. -- KnowlesPJ at Cardiff dot ac dot uk changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31696
[Bug fortran/31696] -malign-double trashes fortran format
--- Comment #5 from KnowlesPJ at Cardiff dot ac dot uk 2007-04-25 22:46 --- I guess I walk away from you guys at this point. You need to think carefully about the fortran standard, which does not define any abi whatsoever (unfortunately). The fortran programmer is not supposed to think about this, but instead write within the language. It is just different to C and CPP. If you can not think about the overall system (compiler and supporting libraries that aim to implement the standard) as a single entity instead of just the compiler, then you will not win friends in the application code development community. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31696
