[Bug target/36713] [4.4 regression] r137252 breaks -O2 optimization on x86_64-unknown-linux-gnu
--- Comment #4 from franke dot daniel at gmail dot com 2008-07-03 09:53 --- Subject: Re: [4.4 regression] r137252 breaks -O2 optimization on x86_64-unknown-linux-gnu 3 Jul 2008 09:42:44 -, rguenther at suse dot de [EMAIL PROTECTED]: Hm, I'm out of quick ideas ;) Polyhedron still seems to work fine for me, as does SPEC 2000. Any hint of what I should look for? Some specific feature that the change in question might affect? If nothing else, I'll try to compare dumps between the two revisions. Is this a specific pass or will -fdump-tree-optimized do? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36713
[Bug target/36713] [4.4 regression] r137252 breaks -O2 optimization on x86_64-unknown-linux-gnu
--- Comment #17 from franke dot daniel at gmail dot com 2008-07-03 19:33 --- Subject: Re: [4.4 regression] r137252 breaks -O2 optimization on x86_64-unknown-linux-gnu Well, the circumstances where the miscompilation occurs may be tricky. So you say you have a testcase but that doesn't show wrong behavior? That's unfortunate ... :/ There was this small glimmer of hope that you could tell from the assembly difference that something's horribly, horribly wrong and you know perfectly well how to fix it. No? :) A properly failing testcase might take a while ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36713
[Bug bootstrap/30678] sysmacros.h get currupt from Fixincludes with updated glibc.
--- Comment #1 from franke dot daniel at gmail dot com 2007-02-02 10:39 --- fixincludes/inclhack.def (glibc_c99_inline_4) deals with sys/sysmacros.h by replacing any extern with #if __STDC_VERSION__ 19901L extern #endif Since your include defines __extern, this leaves __. The patch is Geoffrey's, added him to CC. -- franke dot daniel at gmail dot com changed: What|Removed |Added CC||geoffk at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30678
[Bug bootstrap/30008] New: bootstrapping failure: multiple function definitions
SVN revision: 119289 Host: x86_64-unknown-linux-gnu (Debian GNU/Linux 3.1) Configured as: ../../svn/gcc-head/configure --prefix=/data/home/daniel/x86_64-unknown-linux-gnu/gcc-head-svn --with-gmp=/data/home/daniel/x86_64-unknown-linux-gnu/gmp-4.2.1 --with-mpfr=/data/home/daniel/x86_64-unknown-linux-gnu/mpfr-2.2.0 --enable-bootstrap --enable-threads=posix --enable-shared --with-system-zlib --program-suffix=-head-svn --disable-multilib x86_64-linux --disable-nls --enable-languages=c,fortran While linking libgfortran: .libs/environ.o: In function `__signbitf':/usr/include/x86_64-linux/bits/mathinline.h:46: multiple definition of `__signbitf' .libs/compile_options.o:/usr/include/x86_64-linux/bits/mathinline.h:46: first defined here .libs/environ.o: In function `__signbit':/usr/include/x86_64-linux/bits/mathinline.h:52: multiple definition of `__signbit' .libs/compile_options.o:/usr/include/x86_64-linux/bits/mathinline.h:52: first defined here [snipped couple of thousands of lines] .libs/in_unpack_generic.o: In function `strtod':/usr/include/x86_64-linux/stdlib.h:311: multiple definition of `atof' .libs/environ.o:/usr/include/x86_64-linux/stdlib.h:311: first defined here collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1 make[3]: Leaving directory `/data/home/daniel/svn-build/gcc-head/x86_64-linux/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/data/home/daniel/svn-build/gcc-head/x86_64-linux/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/data/home/daniel/svn-build/gcc-head' make: *** [bootstrap-lean] Error 2 -- Summary: bootstrapping failure: multiple function definitions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30008
[Bug bootstrap/30008] bootstrapping failure: multiple function definitions
--- Comment #1 from franke dot daniel at gmail dot com 2006-11-28 15:18 --- Created an attachment (id=12703) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12703action=view) /usr/include/x86_64-linux/bits/string2.h As requested by Andrew Pinski in http://gcc.gnu.org/ml/fortran/2006-11/msg00700.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30008
[Bug fortran/29992] New: INTERFACE equivalent to MODULE PROCEDURE?!
The following code is accepted by gfortran while ifort rejects it with error messages as quoted below. $ cat foo.f90 MODULE class_foo_type TYPE :: foo INTEGER :: dummy END TYPE END MODULE MODULE class_foo USE class_foo_type, ONLY: foo INTERFACE foo_init MODULE PROCEDURE foo_init_default END INTERFACE INTERFACE SUBROUTINE foo_init_default(this) USE class_foo_type, ONLY: foo TYPE(foo), INTENT(out) :: this END SUBROUTINE END INTERFACE END MODULE $ gfortran-4.3 -g -Wall -pedantic -std=f95 -c foo.f90 echo ok ok $ gfortran-4.3 -v version 4.3.0 20061116 (experimental) $ ifort -g -warn all -c foo.f90 fortcom: Error: foo.f90, line 15: The procedure name of the INTERFACE block conflicts with a name in the encompassing scoping unit. [FOO_INIT_DEFAULT] SUBROUTINE foo_init_default(this) -^ fortcom: Error: foo.f90, line 11: Unresolved MODULE PROCEDURE specification name. [FOO_INIT_DEFAULT] MODULE PROCEDURE foo_init_default ---^ compilation aborted for foo.f90 (code 1) The following is accepted likewise: -- Summary: INTERFACE equivalent to MODULE PROCEDURE?! Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29992
[Bug fortran/29992] INTERFACE equivalent to MODULE PROCEDURE?!
--- Comment #1 from franke dot daniel at gmail dot com 2006-11-27 09:28 --- (report continued) $ cat foo2.f90 MODULE class_foo_type TYPE :: foo INTEGER :: dummy END TYPE END MODULE MODULE class_foo USE class_foo_type, ONLY: foo INTERFACE foo_init SUBROUTINE foo_init_default(this) USE class_foo_type, ONLY: foo TYPE(foo), INTENT(out) :: this END SUBROUTINE END INTERFACE END MODULE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29992
[Bug libgomp/29949] New: implement argument checking for user accessable runtime routines
Arguments for omp_set_num_threads/OMP_NUM_THREADS are used without checking for validity, i.e. $ cat omp_set_num_threads.f90 PROGRAM main USE OMP_LIB CALL omp_set_num_threads(-3) !$OMP PARALLEL WRITE(*,*) thread:, omp_get_thread_num() !$OMP END PARALLEL END PROGRAM $ gfortran-4.3 -g -Wall -fbounds-check omp_set_num_threads.f90 $ ./a.out -3 libgomp: Out of memory allocating 4294967288 bytes Segmentation Fault The specifications v2.5, section 3.2.1, state: If the number of threads requested exceeds the number the implementation can support, or is not a positive integer, the behavior of this routine is implementation defined. Although crashing is a form of implementation, it is not very user friendly. -- Summary: implement argument checking for user accessable runtime routines Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29949
[Bug libgomp/29949] implement argument checking for user accessable runtime routines
--- Comment #1 from franke dot daniel at gmail dot com 2006-11-22 23:12 --- Correction: checks are already implemented for environment variables. In above report OMP_NUM_THREADS is not affected, but omp_set_num_threads still is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29949
[Bug fortran/29759] ice on line continuation in OMP statements (gfc_next_char_literal, at fortran/scanner.c:701)
--- Comment #2 from franke dot daniel at gmail dot com 2006-11-10 09:46 --- Proposed patch, including a testcase: http://gcc.gnu.org/ml/fortran/2006-11/msg00293.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29759
[Bug fortran/29759] ice on line continuation in OMP statements (gfc_next_char_literal, at fortran/scanner.c:701)
--- Comment #1 from franke dot daniel at gmail dot com 2006-11-10 00:19 --- Proposed patch: http://gcc.gnu.org/ml/fortran/2006-11/msg00285.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29759
[Bug fortran/29759] New: ice on line continuation in OMP statements (gfc_next_char_literal, at fortran/scanner.c:701)
$ cat ice.f90 PROGRAM test_omp !$OMP PARALLEL !$NUM_THREADS(2) END PROGRAM $ gfortran-svn -g -Wall -fopenmp ice.f90 ice.f90:0: internal compiler error: in gfc_next_char_literal, at fortran/scanner.c:701 Please submit a full bug report, $ gfortran-svn -v gcc version 4.3.0 20061106 (experimental) -- Summary: ice on line continuation in OMP statements (gfc_next_char_literal, at fortran/scanner.c:701) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29759
[Bug fortran/29670] New: [meta-bug] fortran interfaces
As suggested in PR29652, a meta-bug for interfaces in fortran. -- Summary: [meta-bug] fortran interfaces Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29670
[Bug fortran/29671] New: preprocessor statements must start in column 1
Preprocessor statements (as if|else|endif|error|warning) must start in colum 1,
otherwise gfortran tries to handle them itself?!
$ cat pp.F90
PROGRAM test_preprocessor
#error EEE ! whitespace is significant
END PROGRAM
$ gfortran-4.3 -g -Wall pp.F90
In file pp.F90:3
#error EEE
1
Error: Unclassifiable statement at (1)
$ cat pp.F90
PROGRAM test_preprocessor
#error EEE
END PROGRAM
$ gfortran-4.3 -g -Wall pp.F90
pp.F90:3: error: #error EEE
Filed this as fortran report since gcc bails out as expected and both run
(afaik) the same preprocessor:
$ cat pp.c
int main() {
#error EEE /* whitespaces are not significant */
return 0;
}
$ gcc-svn -g -Wall pp.c
pp.c:2:4: error: #error EEE
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../svn/gcc/configure
--prefix=/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc-svn --disable-nls
--enable-threads=posix --enable-shared --enable-bootstrap --with-system-zlib
--program-suffix=-svn --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.3.0 20061030 (experimental)
--
Summary: preprocessor statements must start in column 1
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: franke dot daniel at gmail dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29671
[Bug fortran/29652] New: ambiguous interface declaration undetected
The following code has an ambiguous interface, sub_a and sub_b are identical. This is correctly reported as an error, if sub_a/sub_b are the only procedures listed. Adding a third and different overload to the interface (sub_c), the ambiguity in sub_a/sub_b goes undetected. $ cat iface.f90 MODULE mod INTERFACE iface MODULE PROCEDURE sub_a MODULE PROCEDURE sub_b MODULE PROCEDURE sub_c END INTERFACE CONTAINS SUBROUTINE sub_a(x) INTEGER, INTENT(in) :: x WRITE (*,*) 'A: ', x END SUBROUTINE SUBROUTINE sub_b(y) INTEGER, INTENT(in) :: y WRITE (*,*) 'B: ', y END SUBROUTINE SUBROUTINE sub_c(x, y) REAL, INTENT(in) :: x, y WRITE(*,*) x, y END SUBROUTINE END MODULE PROGRAM test_interface USE mod CALL iface(42) END PROGRAM $ gfortran-svn -g -Wall iface.f90 ./a.out B: 42 $ gfortran-svn -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../svn/gcc/configure --prefix=$(localpath) --disable-nls --enable-threads=posix --enable-shared --enable-bootstrap --with-system-zlib --program-suffix=-svn --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20061030 (experimental) -- Summary: ambiguous interface declaration undetected Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29652
[Bug fortran/29629] ICE on OpenMP-enabled program (gfc_conv_variable, at fortran/trans-expr.c:404)
--- Comment #5 from franke dot daniel at gmail dot com 2006-10-29 11:52 --- Great. Jakub, thank you very much! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29629
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #9 from franke dot daniel at gmail dot com 2006-10-28 14:27 --- I ran into this on a x86_64 running some flavour of debian. Since I can not alter the system setup, I have to compile svn sources with multilib disabled (otherwise the build process stops due to various errors). There wasn't any problem up until recently when I tried to compile an OMP enabled fortran program: $ gfortran-4.2-svn -fopenmp foo.f gfortran-4.2-svn: libgomp.spec: No such file or directory $ cat foo.f PROGRAM main END PROGRAM $ gfortran-4.2-svn Using built-in specs. Target: x86_64-linux Configured with: ../../svn/gcc-4.2-branch/configure --prefix=$(localpath)/gcc-4.2-svn --with-gmp=$(localpath)/gmp-4.2.1 --with-mpfr=$(localpath)/mpfr-2.2.0 --enable-bootstrap --enable-threads=posix --enable-shared --with-system-zlib --program-suffix=-4.2-svn --disable-multilib x86_64-linux --disable-nls --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.0 20061026 (prerelease) Any suggestions how to work around this problem? Setting up my own toolchain is, due to quota, not an option. -- franke dot daniel at gmail dot com changed: What|Removed |Added CC||franke dot daniel at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug fortran/29629] New: ICE on OpenMP-enabled program (gfc_conv_variable, at fortran/trans-expr.c:404)
There must be something inherently evil with the code below as both, gfortran and ifort, crash. If either func is not array valued or not listed in the REDUCE-clause, everything is fine. $ cat omp.f90 PROGRAM omp write (*,*) func(n) CONTAINS FUNCTION func(n) INTEGER, INTENT(in) :: n INTEGER, DIMENSION(n) :: func INTEGER :: k func = 0 !$OMP PARALLEL DO PRIVATE(k), REDUCTION(+:func) DO k = 1, n func = func + 1 END DO !$OMP END PARALLEL DO END FUNCTION END PROGRAM $ gfortran-svn -g -Wall -fopenmp omp.f90 omp.f90: In function 'func': omp.f90:11: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:404 Please submit a full bug report, with preprocessed source if appropriate. $ gfortran-svn -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../svn/gcc/configure --prefix=/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc-svn --disable-nls --enable-threads=posix --enable-shared --enable-bootstrap --with-system-zlib --program-suffix=-svn --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20061026 (experimental) $ ifort -g -warn all -check all -openmp omp.f90 fortcom: Severe: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. $ ifort -v Version 9.0 -- Summary: ICE on OpenMP-enabled program (gfc_conv_variable, at fortran/trans-expr.c:404) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29629
[Bug fortran/29606] New: Internal Error: Derived type I/O should have been handled via the frontend
A somewhat similar issue was described in (fixed?) PR #24862. $ cat ie.f90 PROGRAM ie TYPE foo INTEGER :: value END TYPE TYPE foo_array TYPE(foo), DIMENSION(:), POINTER :: array END TYPE TYPE(foo_array):: array_holder INTEGER, DIMENSION(:), POINTER :: array_ptr ALLOCATE( array_holder%array(3) ) array_holder%array = (/ foo(1), foo(2), foo(3) /) WRITE(*,*) array_holder%array%value array_ptr = array_holder%array%value WRITE(*,*) array_ptr END PROGRAM $ gfortran-svn -g -Wall ie.f90 $ ./a.out 1 2 3 At line 18 of file ie.f90 Internal Error: Derived type I/O should have been handled via the frontend. $ gfortran-svn -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../svn/gcc/configure --prefix=$(localpath) --disable-nls --enable-threads=posix --enable-shared --enable-bootstrap --with-system-zlib --enable-languages=c,c++,fortran --program-suffix=-svn Thread model: posix gcc version 4.3.0 20061023 (experimental) -- Summary: Internal Error: Derived type I/O should have been handled via the frontend Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29606
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #10 from franke dot daniel at gmail dot com 2006-10-14 08:46 --- Don't know whether it makes any difference - but if it is the array constructor that crashes because of unequal string lengths within its arguments, why is there no problem with this code? PROGRAM test_constructor CHARACTER(len=32), DIMENSION(1,2) :: a a = reshape((/ one arg, another arg /), (/ 1, 2 /)) END PROGRAM (Also compare with #3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #8 from franke dot daniel at gmail dot com 2006-10-13 15:54 --- As requested in comment #7, a testcase for equal string lengths (identical to original PR but to_string() returns CHARACTER(len=255) instead of CHARACTER(len=32)): $ cat cat pr29267.f90 PROGRAM test_ice CHARACTER(len=255), DIMENSION(1,2) :: a a = reshape((/ x, to_string(1.0) /), (/ 1, 2 /)) CONTAINS CHARACTER(len=255) FUNCTION to_string(x) REAL, INTENT(in) :: x WRITE(to_string, FMT=(F6.3)) x END FUNCTION END PROGRAM $ gfortran-4.2 -g -Wall pr29267.f90 pr29267.f90: In function 'MAIN__': pr29267.f90:3: internal compiler error: in operand_subword_force, at emit-rtl.c:1353 $ gfortran-4.2 -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=$mylocalprefix --enable-bootstrap --enable-threads=posix --enable-shared --with-system-zlib --enable-languages=c,fortran --disable-nls --program-suffix=-4.2 Thread model: posix gcc version 4.2.0 20061013 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #6 from franke dot daniel at gmail dot com 2006-10-07 07:09 --- Tobi, Actually this is invalid code. The string lengths in the constructor are different, even though they have to be the same. please try the testcase in the orignal PR with idental string lengths. It will crash gfortran as well. OTOH, a(1,1) = x a(1,2) = to_string(1.0) should work even if CHARACTER(len=255), DIMENSION(1,2) :: a and CHARACTER(len=32) FUNCTION to_string(x), so, why is an equivalent assignment through the array constructor invalid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] New: ICE in operand_subword_force, at emit-rtl.c:1353
$ cat ice.f90 PROGRAM test_ice CHARACTER(len=255), DIMENSION(1,2) :: a a = reshape((/ x, to_string(1.0) /), (/ 1, 2 /)) CONTAINS CHARACTER(32) FUNCTION to_string(x) REAL, INTENT(in) :: x WRITE(to_string, FMT=(F6.3)) x END FUNCTION END PROGRAM $ gfortran-4.2 -g -Wall ice.f90 ice.f90: In function #8216;MAIN__#8217;: ice.f90:3: internal compiler error: in operand_subword_force, at emit-rtl.c:1353 Please submit a full bug report, $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc-4.2-svn --enable-threads=posix --enable-shared --with-system-zlib --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.0 20060914 (experimental) Initially reported here: http://gcc.gnu.org/ml/fortran/2006-09/msg00335.html (the testcase above is a reduced version of that posted to the ML) -- Summary: ICE in operand_subword_force, at emit-rtl.c:1353 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug libfortran/29101] New: memory leak in libgfortran
Please find below a stripped down testcase and a session log from valgrind. The code reads input from stdin, compares what was read against a couple of choices (exactly one in this case) and repeats reading until a single 'x' was entered. The leak is related to the length of the input buffer within the main program, hitting [enter] N times before giving an 'x' results in N leaked blocks of strlen(input). Also involved is the SELECT CASE: if it is replaced by an equivalent IF-statement, no memory is leaked. Reproducible with gfortran-4.1.1 and gfortran-4.2 20060914 (experimental). $ cat test.f90 MODULE stringutils CHARACTER(*), PRIVATE, PARAMETER :: lowercase = 'abcdefghijklmnopqrstuvwxyz' CHARACTER(*), PRIVATE, PARAMETER :: uppercase = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' CONTAINS FUNCTION tolower(instr) RESULT (outstr) CHARACTER(len=*), INTENT(in) :: instr CHARACTER(len=len(instr)):: outstr INTEGER :: i, k outstr = instr DO i = 1, len_trim(outstr) k = index(uppercase, outstr(i:i)) if (k /= 0) outstr(i:i) = lowercase(k:k) END DO END FUNCTION END MODULE MODULE configuration CONTAINS LOGICAL FUNCTION validate_value(input, value) USE stringutils CHARACTER(len=*), INTENT(in) :: input INTEGER, INTENT(out) :: value validate_value = .TRUE. SELECT CASE (tolower(input)) CASE (x); value = 1 CASE DEFAULT validate_value = .FALSE. END SELECT END FUNCTION END MODULE PROGRAM test USE configuration USE stringutils INTEGER :: value CHARACTER(len=256) :: input DO WRITE (*, FMT=(A), ADVANCE = NO) $ READ (*, FMT=(A)) input IF (validate_value(input, value)) EXIT END DO END PROGRAM $ gfortran-4.2 -g -Wall test.f90 $ valgrind --tool=memcheck --leak-check=full ./a.out ==9829== Memcheck, a memory error detector. ==9829== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==9829== Using LibVEX rev 1606, a library for dynamic binary translation. ==9829== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==9829== Using valgrind-3.2.0, a dynamic binary instrumentation framework. ==9829== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==9829== For more details, rerun with: -v ==9829== % % % % % % x ==9829== ==9829== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 1) ==9829== malloc/free: in use at exit: 1,536 bytes in 6 blocks. ==9829== malloc/free: 24 allocs, 18 frees, 55,080 bytes allocated. ==9829== For counts of detected errors, rerun with: -v ==9829== searching for pointers to 6 not-freed blocks. ==9829== checked 78,156 bytes. ==9829== ==9829== 1,536 bytes in 6 blocks are definitely lost in loss record 1 of 1 ==9829==at 0x4021396: malloc (vg_replace_malloc.c:149) ==9829==by 0x40304EC: _gfortrani_get_mem (memory.c:53) ==9829==by 0x80488FA: __configuration__validate_value (dump.f90:29) ==9829==by 0x8048A9A: MAIN__ (dump.f90:47) ==9829==by 0x8048AD6: main (fmain.c:18) ==9829== ==9829== LEAK SUMMARY: ==9829==definitely lost: 1,536 bytes in 6 blocks. ==9829== possibly lost: 0 bytes in 0 blocks. ==9829==still reachable: 0 bytes in 0 blocks. ==9829== suppressed: 0 bytes in 0 blocks. ==9829== Reachable blocks (those to which a pointer was found) are not shown. ==9829== To see them, rerun with: --show-reachable=yes -- Summary: memory leak in libgfortran Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: franke dot daniel at gmail dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29101
[Bug fortran/28974] New: Extremely slow compilation of enumerated DATA statements.
Compilation of enumerated DATA statements is extremely slow.
Related PR:
* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13465
Related threads on ML:
* http://gcc.gnu.org/ml/fortran/2004-08/msg00131.html
* http://gcc.gnu.org/ml/fortran/2006-09/msg00025.html
Shell script to generate example data:
$ cat datagen.sh
#! /bin/bash
outfile=data.f90
dim1=50
dim2=1000
echo MODULE appdata${outfile}
echo INTEGER :: thedata(${dim1}, ${dim2}) ${outfile}
for i in `seq 1 ${dim1}` ; do
for j in `seq 1 ${dim2}` ; do
echo DATA thedata(${i}, ${j}) / $((i*j)) /${outfile}
done
done
echo END MODULE ${outfile}
P4 3.2 GHz, 2GB RAM:
$ bash datagen.sh
$ time gfortran-4.2 -c data.f90
real3m31.646s
user3m29.545s
sys 0m0.172s
--
Summary: Extremely slow compilation of enumerated DATA
statements.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: franke dot daniel at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28974
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #23 from franke dot daniel at gmail dot com 2006-07-03 12:14 --- Is the list of missing intrinsics given in comment #7 still valid? I tried to compile F77 code I inherited and got undefined references for itime_ and idate_ (gfortran-4.1.1). If they are still missing, is someone working on those? -- franke dot daniel at gmail dot com changed: What|Removed |Added CC||franke dot daniel at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
