[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #28 from toon at moene dot indiv dot nluug dot nl 2008-10-22 08:28 --- Jerry, do you think your patch can be applied and this bug closed ? As I wrote, it fixed the original problem from which I constructed the two test cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #26 from toon at moene dot indiv dot nluug dot nl 2008-10-19 16:11 --- The patch works for my case, Please be careful with the namelist_18,f90 test case - I can't off-hand say whether it's right or (an extension). Cheers, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #13 from toon at moene dot indiv dot nluug dot nl 2008-10-18 08:43 --- Unfortunately, while the original test case has been solved, the original problem that led me to file this bug report hasn't been ... Here's a failing example closer to the original source: TYPE geometry INTEGER :: nlon,nlat,nlev,projection INTEGER :: center,subcenter,process REAL:: west,south,east,north REAL:: dlon,dlat REAL:: polat,polon REAL:: lonc,latc REAL:: projlat,projlat2,projlon CHARACTER(LEN=1) :: arakawa ='#' INTEGER :: truncx,truncy ! Spectral truncation INTEGER :: cie ! Flag fort CI (0), CIE gridpoint (1) ! or CIE spectral (-1) INTEGER :: nlat_i,nlon_i ! I length in Y and X direction INTEGER :: nlat_e ,nlon_e ! E length in Y and X direction LOGICAL :: do_geo = .true. END TYPE geometry TYPE shortkey INTEGER :: PPP ! 2. Parameter INTEGER :: NNN ! 12. Gridpoint or spectral field 0 = gridpoint, 1 = spectral INTEGER :: INTPM CHARACTER(LEN=16) :: name END TYPE shortkey INTEGER, PARAMETER :: maxl = 200 ! Maximum number of levels to be read from namelist INTEGER, PARAMETER :: max_atmkey = 10 ! Maximum number of extra fields in the REAL:: ahalf(maxl),bhalf(maxl) TYPE (geometry) :: outgeo ; SAVE outgeo ! Output geometry TYPE (shortkey) :: atmkey(max_atmkey) ; SAVE atmkey TYPE (shortkey) :: mlevkey(max_atmkey) ; SAVE mlevkey character*200 :: l = NAMINTERP atmkey%ppp = 076,058,062,079, atmkey%nnn = 000,000,000,000, atmkey%name ='LIQUID_WATER','SOLID_WATER','SNOW','RAIN', OUTGEO%NLEV=10, AHALF=0.,1.,2.,3.,4.,5.,6.,7.,8.,9., BHALF=0.,1.,2.,3.,4.,5.,6.,7.,8.,9., / namelist /naminterp/outgeo,ahalf,bhalf,atmkey read(l,naminterp) write(6,naminterp) end It yields: At line 40 of file nl4.f90 Fortran runtime error: Cannot match namelist object name 5.6.7.8.9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #14 from toon at moene dot indiv dot nluug dot nl 2008-10-18 08:46 --- Created an attachment (id=16514) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16514action=view) New Failing Example. This a more complicated example that still fails after Jerry's fix for the first example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #15 from toon at moene dot indiv dot nluug dot nl 2008-10-18 08:47 --- Sorry, source code of new example got mangled; I created an attachment (nl4.f90) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #19 from toon at moene dot indiv dot nluug dot nl 2008-10-18 15:33 --- character*200 :: l = NAMINTERP atmkey%ppp = 076,058,062,079, atmkey%nnn = 0 1 Warning: CHARACTER expression at (1) is being truncated (222/200) Tobias, you are right - the string is too short - 250 characters should do, however, and I get the same error. How did you provoke the warning (I certainly do not get it by default) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug libfortran/37707] New: Namelist read of array of derived type incorrect
The following program: type s integer m integer n end type s type(s) :: a(3) character*80 :: l = ' namlis a%m=1,2, a%n=5,6, /' namelist /namlis/ a a%m=[87,88,89] a%n=[97,98,99] print*,a%m print*,a%n read(l,namlis) write(*,namlis) end prints: 87 88 89 97 98 99 At line 12 of file nl.f90 Fortran runtime error: Cannot match namelist object name 2 The error condition is bogus. According to the Fortran 2003 Standard, subclause 10.10.1.2 (third paragraph): When the name in the input record represents an array variable or a variable of derived type, the effect is as if the variable represented where expanded into a sequence of scalar list items of intrinsic data types, in the same way that formatted input/output list items are expanded. In other words: a%m has to be read in in the same way as it has to be written out. That means that the original namelist read above should assign 1 to a(1)%m and 2 to a(2)%m and nothing (i.e., not change the value of a(3)%m) and, mutatis mutandis, for a(..)%n. -- Summary: Namelist read of array of derived type incorrect 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 indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
[Bug fortran/34567] module name without a module
--- Comment #8 from toon at moene dot indiv dot nluug dot nl 2008-09-10 18:18 --- Indeed, can be closed - thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34567
[Bug fortran/36316] New: type mismatch in binary expression caught by verify_gimple
The following module definition: MODULE YOMCAIN IMPLICIT NONE SAVE TYPE distributed_vector REAL, pointer :: local(:) INTEGER :: global_length,local_start,local_end,nchnks END TYPE distributed_vector INTERFACE ASSIGNMENT (=) MODULE PROCEDURE assign_dv_dv END INTERFACE INTERFACE OPERATOR (*) MODULE PROCEDURE multiply_dv_dv END INTERFACE CONTAINS SUBROUTINE assign_dv_dv (handle1,handle2) ! copy one distributed_vector to another TYPE (distributed_vector), INTENT(IN):: handle2 TYPE (distributed_vector), INTENT(INOUT) :: handle1 handle1%local(:) = handle2%local(:) RETURN END SUBROUTINE assign_dv_dv FUNCTION multiply_dv_dv (handle1,handle2) ! multiply two distributed_vectors TYPE (distributed_vector), INTENT(IN) :: handle2 TYPE (distributed_vector), INTENT(IN) :: handle1 REAL, DIMENSION(handle1%local_start:handle1%local_end) ::multiply_dv_dv multiply_dv_dv = handle1%local(:) * handle2%local(:) RETURN END FUNCTION multiply_dv_dv SUBROUTINE CAININAD_SCALE_DISTVEC () TYPE (distributed_vector) :: PVAZG TYPE (distributed_vector) :: ZTEMP TYPE (distributed_vector) :: SCALP_DV ZTEMP = PVAZG * SCALP_DV END SUBROUTINE CAININAD_SCALE_DISTVEC END MODULE YOMCAIN draws this error message when compiling with a recent 4.4.0 gfortran: a.F90: In function 'caininad_scale_distvec': a.F90:47: error: type mismatch in binary expression integer(kind=8) integer(kind=4) integer(kind=4) D.1027 = D.1026 - D.1025 a.F90:47: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This 4.3.1 gfortran doesn't have any complaints about this source: gfortran -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure linux gnu Thread model: posix gcc version 4.3.1 20080401 (prerelease) (Debian 4.3.0-3) -- Summary: type mismatch in binary expression caught by verify_gimple Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36316
[Bug fortran/36316] type mismatch in binary expression caught by verify_gimple
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2008-05-23 20:07 --- Ugh, sorry, I see I included the wrong source. Here's the correct one: MODULE YOMCAIN IMPLICIT NONE SAVE TYPE distributed_vector REAL, pointer :: local(:) INTEGER :: global_length,local_start,local_end,nchnks END TYPE distributed_vector INTERFACE ASSIGNMENT (=) MODULE PROCEDURE assign_ar_dv END INTERFACE INTERFACE OPERATOR (*) MODULE PROCEDURE multiply_dv_dv END INTERFACE CONTAINS SUBROUTINE assign_ar_dv (handle,pvec) ! copy array to the distributed_vector REAL, INTENT(IN):: pvec(:) TYPE (distributed_vector), INTENT(INOUT) :: handle handle%local(:) = pvec(:) RETURN END SUBROUTINE assign_ar_dv FUNCTION multiply_dv_dv (handle1,handle2) ! multiply two distributed_vectors TYPE (distributed_vector), INTENT(IN) :: handle2 TYPE (distributed_vector), INTENT(IN) :: handle1 REAL, DIMENSION(handle1%local_start:handle1%local_end) ::multiply_dv_dv multiply_dv_dv = handle1%local(:) * handle2%local(:) RETURN END FUNCTION multiply_dv_dv SUBROUTINE CAININAD_SCALE_DISTVEC () TYPE (distributed_vector) :: PVAZG TYPE (distributed_vector) :: ZTEMP TYPE (distributed_vector) :: SCALP_DV ZTEMP = PVAZG * SCALP_DV END SUBROUTINE CAININAD_SCALE_DISTVEC END MODULE YOMCAIN Apologies ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36316
[Bug fortran/35627] [4.3, 4.4 regression] namelist read error
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2008-03-19 08:37 --- I'm hit by this, too - don't know when it started (it's in a namelist I've been using for years). -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added CC||toon at moene dot indiv dot ||nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug fortran/35612] testsuite ISO_C_BIND code error
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2008-03-17 16:00 --- *** Bug 35613 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35612
[Bug fortran/35613] testsuite ISO_C_BIND code error
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2008-03-17 16:00 --- *** This bug has been marked as a duplicate of 35612 *** -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35613
[Bug fortran/35203] OPTIONAL, VALUE actual argument cannot be an INTEGER 0
--- Comment #9 from toon at moene dot indiv dot nluug dot nl 2008-02-18 08:32 --- What will happen now? Will anyone send an interpretation request, which will bring it up on the table again? No, as it isn't *impossible* to implement it (with a hidden argument), an interp won't stand a chance. I intent to submit the following patch: Yep, it's *much* better to say outright that we do not support it. We will hear from people who actually need it :-) Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35203
[Bug fortran/35203] OPTIONAL, VALUE actual argument cannot be an INTEGER 0
--- Comment #7 from toon at moene dot indiv dot nluug dot nl 2008-02-15 18:15 --- As written, I checked all my compilers and all get a wrong result - gfortran, g95, NAG f95: NOT PRESENT - ifort: PRESENT, WITH VALUE: 0 (even if not present) (ifort 10 and ifort 10.1 print a warning that present should not be used with value; ifort 9 give the same run-time result, but does not have the warning) - sunf95: Compile-time error: OPTIONAL and VALUE may not be used both I just asked Bill Long of Cray (who heads the subgroup that covers this) to try it on Cray's compiler - it ICE'd with a message that clearly showed that it didn't expect to be handed an OPTIONAL, VALUE argument (without flagging it as a not-legal construct, though). I'm closing the PR as WONTFIX. (While we are at it: Please make sure that OPTION + VALUE + BIND(C) will not be allowed in the upcoming interoperability TR; if it is included, there should be a note giving implementation suggestions. F2003 is unaffected by this as OPTIONAL is not allowed with BIND(C).) You bet. There was a heated discussion on this yesterday, which didn't result in any progress. Bill will send out an e-mail with the issues. -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35203
[Bug fortran/35203] New: OPTIONAL, VALUE actual argument cannot be an INTEGER 0
Run this program: INTERFACE SUBROUTINE AAP(I) INTEGER, OPTIONAL, VALUE :: I END SUBROUTINE END INTERFACE CALL AAP(0) END SUBROUTINE AAP(N) INTEGER, OPTIONAL, VALUE :: N IF (PRESENT(N)) THEN PRINT*,'PRESENT, WITH VALUE:',N ELSE PRINT*,'NOT PRESENT' ENDIF END and get: $ ./a.out NOT PRESENT $ which should come to no surprise, if one glazes his/her eyes over trans_expr.c:gfc_conv_missing_dummy. -- Summary: OPTIONAL, VALUE actual argument cannot be an INTEGER 0 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35203
[Bug fortran/35203] OPTIONAL, VALUE actual argument cannot be an INTEGER 0
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2008-02-15 01:04 --- At the moment I do not see how one could implement this if WG5 insists that this is valid - except of passing a hidden argument. As I am at a WG5 just right now, I decided to ask. Allowing OPTIONAL,VALUE was a conscious decision by the Committee (although not necessarily an unanimous one :-) -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2008-02-15 01:04:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35203
[Bug fortran/35203] OPTIONAL, VALUE actual argument cannot be an INTEGER 0
-- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2008-02-15 01:04:01 |2008-02-15 01:06:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35203
[Bug fortran/34820] New: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147
The attached gzipped tar file unpacks in a directory gf. If the definition in the Makefile of F95 is changed to invoke the latest gfortran-4.3.0, one gets the following error message: grid_io.f90: In function 'read_grid_header': grid_io.f90:40: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans- array.c:147 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34820
[Bug fortran/34820] internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2008-01-16 21:47 --- Created an attachment (id=14952) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14952action=view) Tar file with sources to evoke problem The test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34820
[Bug fortran/34820] internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2008-01-16 21:49 --- Does fail on x86-64-unknown-gnu-linux and OSX ppc (probably not relevant). -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-16 21:49:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34820
[Bug fortran/34820] internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2008-01-16 22:19 --- Also wrong with Debian's 4.2.3 prerelease. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34820
[Bug fortran/34567] New: module name without a module
If I revert the following line from module.c: Index: module.c === --- module.c(revision 131134) +++ module.c(working copy) @@ -3732,7 +3732,6 @@ if (st only_flag !st-n.sym-attr.use_only !st-n.sym-attr.use_rename - st-n.sym-module strcmp (st-n.sym-module, module_name) == 0) st-name = gfc_get_string (hidden.%s, name); the attached build runs into a segmentation fault. It is suspected that the above fix just papers over the real problem. To get the ICE, unpack the accompanying tar file and type make all. -- Summary: module name without a module Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34567
[Bug fortran/34567] module name without a module
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2007-12-23 13:21 --- Created an attachment (id=14809) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14809action=view) The Test Case This is the directory with makefile to show the bug. If you have a gfortran with the line in module.c removed, just ascertain yourself it's first in your PATH and type make all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34567
[Bug fortran/34567] module name without a module
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2007-12-23 13:49 --- Gfortran 4.2.2 gets this right (at least when using Debian/testing's default gfortran): [EMAIL PROTECTED]:~/pr34567$ gfortran -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-23 13:49:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34567
[Bug libfortran/33905] New: show_backtrace hangs on SIGSEGV in malloc/free
The current implementation of show_backtrace hangs on a mutex lock in the malloc/free routines when a segmentation fault due to corruption of the malloc/free administration happens to trigger the backtrace. There is an alternative implementation using a temporary file to store the translation of address - symbol name that doesn't malloc storage (see 'man backtrace'). A work around is to force the hanging process to the background and using the attach functionality of gdb to force a backtrace with the where command. -- Summary: show_backtrace hangs on SIGSEGV in malloc/free Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33905
[Bug fortran/33906] New: -fshape-check
Sometimes, when an array bounds overrun is detected, it is actually due to a shape mismatch between arrays in an expression / assignment. Fortran 2003, 7.1.5: For all elemental binary operations, the two operands shall be in shape conformance ... and mutatis mutandis for more complex expressions. The constraints on assignment are in 7.4.1.2. Because it's much cheaper to check for shape conformance violation than for array bound overruns, it might be useful to add an optional check for this. -- Summary: -fshape-check Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33906
[Bug libfortran/33421] New: Weird quotation of namelist output of character arrays.
This program: character*20 a(3) namelist / nam / a read (4, nml=nam) write(6, nml=nam) end given the following input (fort.4): nam a(1)='aap noot mies wim zus jet', a(2)='surf.pressure', a(3)='apekool', / produces the following output: NAM A=aap noot mies wim zu,a(2)='surf.pressure',a(3)='apekool' , / This mixing of quoted and unquoted strings cannot be correct. The a(2) and a(3) are weird. -- Summary: Weird quotation of namelist output of character arrays. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33421
[Bug libfortran/33422] New: Weird quotation of namelist output of character arrays.
This program: character*20 a(3) namelist / nam / a read (4, nml=nam) write(6, nml=nam) end given the following input (fort.4): nam a(1)='aap noot mies wim zus jet', a(2)='surf.pressure', a(3)='apekool', / produces the following output: NAM A=aap noot mies wim zu,a(2)='surf.pressure',a(3)='apekool' , / This mixing of quoted and unquoted strings cannot be correct. The a(2) and a(3) are weird. -- Summary: Weird quotation of namelist output of character arrays. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33422
[Bug libfortran/33422] Weird quotation of namelist output of character arrays.
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2007-09-13 18:43 --- G, bugzilla *** This bug has been marked as a duplicate of 33421 *** -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33422
[Bug libfortran/33421] [4.3 Regression] Weird quotation of namelist output of character arrays
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2007-09-13 18:43 --- *** Bug 33422 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33421
[Bug libfortran/33421] [4.3 Regression] Weird quotation of namelist output of character arrays
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2007-09-13 18:44 --- Two witnesses should be enough ... -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-13 18:44:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33421
[Bug libfortran/33298] Wrong code for SPREAD on zero-sized arrays
--- Comment #8 from toon at moene dot indiv dot nluug dot nl 2007-09-06 08:56 --- Wouldn't it be an option to simply bail out early (i.e., after the error checks) in case of size == 0 ? E.g., like this: 62 63 rrank = srank + 1; 64 if (rrank GFC_MAX_DIMENSIONS) 65 runtime_error (return rank too large in spread()); 66 67 if (*along rrank) 68 runtime_error (dim outside of rank in spread()); if (size == 0) return Or do we actually have to set something on return ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug fortran/33298] New: Wrong code for SPREAD on dummy arguments
This code: REAL X(2,3), Y(2) Y=[1.,2.] CALL SUB(X,Y) DO I = 1, 3 PRINT*,X(:,I) ENDDO END SUBROUTINE SUB(A,B) REAL A(:,:), B(:) A(:,:) = SPREAD(B(:),2,SIZE(A,2)) END results in: 0.00 0.00 0.00 0.00 0.00 0.00 using: /usr/snp/bin/gfortran -static -v -g -O2 -fbacktrace spread.f Driving: /usr/snp/bin/gfortran -static -v -g -O2 -fbacktrace spread.f -lgfortranbegin -lgfortran -lm Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/usr/snp/ --disable-multilib --disable-nls --enable-languages=fortran Thread model: posix gcc version 4.3.0 20070903 (experimental) (GCC) /usr/snp/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 spread.f -ffixed-form -quiet -dumpbase spread.f -mtune=generic -auxbase spread -g -O2 -version -fbacktrace -fintrinsic-modules-path /usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude -o /tmp/ccjGK59d.s GNU F95 (GCC) version 4.3.0 20070903 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.0 20070903 (experimental), GMP version 4.2.1, MPFR version 2.3.0-rc1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -V -Qy -o /tmp/cc53anSf.o /tmp/ccjGK59d.s GNU assembler version 2.17.90 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.17.90.20070812 /usr/snp/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/collect2 -m elf_x86_64 -static /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtbeginT.o -L/usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0 -L/usr/snp/bin/../lib/gcc -L/usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../.. /tmp/cc53anSf.o -lgfortranbegin -lgfortran -lm --start-group -lgcc -lgcc_eh -lc --end-group /usr/snp/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o /usr/lib/../lib64/crtn.o Debian's testing gfortran-4.2 gave me another bunch of nonsense: -4.5149084E-10 4.5916347E-41 -4.5151327E-10 4.5916347E-41 -4.5151283E-10 4.5916347E-41 Trying to print the SPREAD expression directly gave me a segmentation fault using the above gfortran 4.2 and an empty line using 4.3. -- Summary: Wrong code for SPREAD on dummy arguments Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl 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=33298
[Bug fortran/33298] Wrong code for SPREAD on dummy arguments
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2007-09-04 08:11 --- Yeah, I have to come up with a better example. In the original code that I reduced, the interface came from a module file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug fortran/33298] Wrong code for SPREAD on zero sized dummy arguments
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2007-09-04 10:15 --- Second try, now with interface and using zero sized arrays: $ cat spread.f INTERFACE SUB SUBROUTINE SUB(P,Q) REAL, INTENT(OUT) :: P(:,:) REAL, INTENT(IN) :: Q(:) END SUBROUTINE END INTERFACE REAL, ALLOCATABLE :: X(:,:), Y(:) ALLOCATE(X(0,3)) ALLOCATE(Y(0)) ! Y=[1.,2.] CALL SUB(X,Y) DO I = 1, 3 PRINT*,X(:,I) ENDDO END SUBROUTINE SUB(A,B) REAL, INTENT(OUT) :: A(:,:) REAL, INTENT(IN) :: B(:) A(:,:) = SPREAD(B(:),2,SIZE(A,2)) END $ /usr/snp/bin/gfortran -g -O2 -static -fbacktrace spread.f $ ./a.out Program received signal 11 (SIGSEGV): Segmentation fault. Backtrace for this error: + function __restore_rt (0x4185D0) from file libgcc2.c + function memcpy (0x432D85) + function spread_internal (0x40A50F) at line 145 of file spread_generic.c + function sub_ (0x400404) at line 16 of file spread.f + in the main program at line 11 of file spread.f + function __libc_start_main (0x4138E7) -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Summary|Wrong code for SPREAD on|Wrong code for SPREAD on |dummy arguments |zero sized dummy arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug libfortran/33298] Wrong code for SPREAD on zero-sized arrays
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2007-09-04
13:04 ---
Quoting spread_generic.c:
145 for (n = 0; n ncopies; n++)
146{
147 memcpy (dest, sptr, size);
148 dest += rdelta;
149}
The C 99 Standard has the following to say about the mem* functions (7.21.2.1
ff):
Where an argument declared as size_t n specifies the length of the array for a
function, n can have the value zero on a call to that function. Unless
explicitly stated otherwise in the description of a particular function in this
subclause, pointer arguments on such a call shall still have valid values, as
described in 7.1.4.
So size can be zero, *but the the pointer arguments on such a call shall
still have valid values.*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
[Bug fortran/33189] New: read(blah, fmt=*) is accepted, but read(blah, '*') not.
The following, IMNSHO, is valid Fortran 95: CHARACTER*10 a a = '15' READ(a, '*') i PRINT*,i END Unfortunately, it draws: ugh.f:3.72: READ(a, '*') i 1 Error: Missing leading left parenthesis in format string at (1) If I change '*' to fmt=* the code is accepted. -- Summary: read(blah, fmt=*) is accepted, but read(blah, '*') not. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33189
[Bug fortran/33189] read(blah, fmt=*) is accepted, but read(blah, '*') not.
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2007-08-25 16:52 --- Ah, but then the question becomes: Why is this not valid ? CHARACTER*10 a a = '15' READ(a, '(*)') i PRINT*,i END 33189.f:3.72: READ(a, '(*)') i 1 Error: Unexpected element in format string at (1) Cheers, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33189
[Bug fortran/32103] Module with equivalence draws unsatisfied reference
--- Comment #5 from toon at moene dot indiv dot nluug dot nl 2007-05-30 01:18 --- Subject: Re: Module with equivalence draws unsatisfied reference pault at gcc dot gnu dot org wrote: --- Comment #4 from pault at gcc dot gnu dot org 2007-05-29 10:39 --- The patch below works and regtests OK. I am trying to devise a safe method of gettting rid of the redundant symbols if none of the equivalence members is USEd. If I cannot see something by tonight, I will submit anyway. Yep - that worked. Thanks ! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32103
[Bug fortran/32103] New: Module with equivalence draws unsatisfied reference
Given this eq-mod.f90 module aap real a(5) real b(3) equivalence (a(3),b(1)) end module aap and the following main program eq-main.f90 use aap, only : b print*,b end draws, when compiling with GNU Fortran (GCC) 4.2.1 20070523 (prerelease), as follows: [EMAIL PROTECTED]:~/g95-bugs$ /usr/rel/bin/gfortran -c eq-mod.f90 [EMAIL PROTECTED]:~/g95-bugs$ /usr/rel/bin/gfortran -c eq-main.f90 [EMAIL PROTECTED]:~/g95-bugs$ /usr/rel/bin/gfortran -static eq-main.o eq-mod.o eq-main.o: In function `MAIN__': eq-main.f90:(.text+0x78): undefined reference to `__aap(bool)' collect2: ld returned 1 exit status The (bool) is a red herring, caused by collect2's helpful reinterpretation of the following external reference: [EMAIL PROTECTED]:~/g95-bugs$ nm eq-main.o U __aap__b ... -- Summary: Module with equivalence draws unsatisfied reference Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32103
[Bug fortran/32103] Module with equivalence draws unsatisfied reference
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2007-05-27 17:23 --- Subject: Re: Module with equivalence draws unsatisfied reference Thanks for taking this up. This bug prevents much of Europe to compile the weather code of the European Centre. Kind regards, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32103
[Bug tree-optimization/31756] New: Doesn't optimize the following (obvious) sequence
Given the following Fortran source: SUBROUTINE SUB(A, B, N, M) DIMENSION A(N, M), B(N, M) DO I = 1, N DO J = 1, M A(I, J) = B(I, J) ENDDO ENDDO END It should be vectorized using the following compile time options: -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -ftree-loop-linear Unfortunately, it doesn't. -- Summary: Doesn't optimize the following (obvious) sequence Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl GCC build triplet: idem GCC host triplet: x64_86-unknown-gnu-linux GCC target triplet: idem http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31756
[Bug fortran/30660] [4.2 and 4.1 only] Allocatable components of a derived type require the SAVE attribute.
--- Comment #5 from toon at moene dot indiv dot nluug dot nl 2007-02-04 13:17 --- It's not completely fixed yet, though. The following: MODULE types_m TYPE coord_t INTEGER ncord REAL,ALLOCATABLE,DIMENSION(:) :: x, y END TYPE TYPE grib_t INTEGER ksec0(2), ksec1(64), ksec2(64), ksec3(2), ksec4(64) REAL psec2(512), psec3(3) LOGICAL packed ! if packed then the data are stored in g_work INTEGER npts REAL,DIMENSION(:),ALLOCATABLE :: vdata TYPE(coord_t) coords END TYPE END MODULE MODULE globals_m USE types_m TYPE(grib_t) g_dest ! output field END MODULE still fails with: globals.f90:21.21: TYPE(grib_t) g_dest ! output field 1 Error: Object 'g_dest' at (1) must have the SAVE attribute for default initialization of a component probably because of the nested nature of the allocatable component in coord_t. Hope this helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30660
[Bug fortran/30660] New: Allocatable components of a derived type require the SAVE attribute.
The attached code draws the following, bogus, error message from the compiler: $ /usr/snp/bin/gfortran -c globals.f90 globals.f90:37.24: TYPE(weight_t) g_winfo ! weights info 1 Error: Object 'g_winfo' at (1) must have the SAVE attribute for default initialization of a component globals.f90:36.21: TYPE(grib_t) g_dest ! output field 1 Error: Object 'g_dest' at (1) must have the SAVE attribute for default initialization of a component It's related to the allocatable components of said types. -- Summary: Allocatable components of a derived type require the SAVE attribute. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30660
[Bug fortran/30660] Allocatable components of a derived type require the SAVE attribute.
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2007-01-31 21:37 --- I can't attach the source file, so I reproduce it here: MODULE types_m INTEGER,PRIVATE,PARAMETER :: MXLEN = 2024, MXKEYS = 50, MXGRIBFLDS = 1000, MXFIN = 2 TYPE coord_t INTEGER ncord REAL,ALLOCATABLE,DIMENSION(:) :: x, y END TYPE TYPE weight_t INTEGER id CHARACTER(LEN=128) :: fname LOGICAL set, init INTEGER ksec2in(60), ksec2out(60) REAL psec2in(60), psec2out(60) INTEGER wdim INTEGER offset(16) INTEGER,ALLOCATABLE,DIMENSION(:) :: gridpts REAL,ALLOCATABLE,DIMENSION(:,:) :: weights REAL,ALLOCATABLE,DIMENSION(:) :: rotX, rotY, rotAngle LOGICAL rotatedComp END TYPE TYPE grib_t INTEGER ksec0(2), ksec1(64), ksec2(64), ksec3(2), ksec4(64) REAL psec2(512), psec3(3) LOGICAL packed ! if packed then the data are stored in g_work INTEGER npts REAL,DIMENSION(:),ALLOCATABLE :: vdata TYPE(coord_t) coords END TYPE END MODULE MODULE globals_m USE types_m TYPE(grib_t) g_dest ! output field TYPE(weight_t) g_winfo! weights info END MODULE Hope this helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30660
[Bug fortran/30320] program crash for SUM applied to zero-size array
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-12-29 09:03 --- *** This bug has been marked as a duplicate of 30321 *** -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30320
[Bug fortran/30321] program crash for SUM applied to zero-size array
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-12-29 09:03 --- *** Bug 30320 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30321
[Bug tree-optimization/27773] New: ICE: in find_lattice_value, at tree-complex.c:133
With the attached source, gcc version 4.2.0 20060524 (experimental) gets: /usr/snp/bin/gfortran -S -O2 -ffast-math imhdiff4_pp.f imhdiff4_pp.f: In function 'imhdiff4': imhdiff4_pp.f:1: internal compiler error: in find_lattice_value, at tree-complex.c:133 Note the use of -ffast-math - without it, there's no error. -- Summary: ICE: in find_lattice_value, at tree-complex.c:133 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug tree-optimization/27773] ICE: in find_lattice_value, at tree-complex.c:133
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-05-26 13:02 --- Created an attachment (id=11516) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11516action=view) Source file showing the wrong behaviour -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug tree-optimization/27773] [4.2 regression] ICE: in find_lattice_value, at tree-complex.c:133
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-05-26 13:06 --- Changed summary to indicate this bug is a 4.2 regression. -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Summary|ICE: in find_lattice_value, |[4.2 regression] ICE: in |at tree-complex.c:133 |find_lattice_value, at tree- ||complex.c:133 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
[Bug fortran/27698] New: subroutine _foo draws unclassifiable statement instead of a useful error.
subroutine _foo end draws the following error: In file bhatt.f:1 subroutine _foo 1 Error: Unclassifiable statement at (1) whereas the compiler would be far more helpful pointing out that _foo is against the Standard (Rule R304: A name should start with a letter). -- Summary: subroutine _foo draws unclassifiable statement instead of a useful error. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698
[Bug fortran/24993] LAPACK builds but dies in the testsuite
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-03-31 11:24 --- Could you retry this with gfortran 4.1 (now that it is out) ? Thanks. -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24993
[Bug fortran/26891] Automatic conversion for optional parameters of missing dummies
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-03-28 08:15 --- logical, optional, intent(in) :: back myscan = scan (str, substr, back) I thought passing non-present optional arguments down to routines as an optional argument is within the confines of the Standard. If in doubt, consult comp.lang.fortran ... -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-28 08:15:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26891
[Bug fortran/26054] Gratuitous warning about Fortran 2003 features w/o -std=...
--- Comment #7 from toon at moene dot indiv dot nluug dot nl 2006-03-11 12:09 --- Bug fix now also committed to the 4.1 branch, so will be fixed as of 4.1.1. -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26054
[Bug fortran/26054] Gratuitous warning about Fortran 2003 features w/o -std=...
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2006-02-11 13:27 --- Subject: Re: Gratuitous warning about Fortran 2003 features w/o -std=... We don't warn for other Fortran 2003 features we support without a -std=f95, so I'll look into it and fix it. Well, that's not true, we do. So I'll propose a fix for the whole, to [EMAIL PROTECTED] and [EMAIL PROTECTED] Cheers, Toon -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26054
[Bug fortran/26054] Gratuitous warning about Fortran 2003 features w/o -std=...
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2006-02-10 08:42 --- We don't warn for other Fortran 2003 features we support without a -std=f95, so I'll look into it and fix it. -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |toon at moene dot indiv dot |dot org |nluug dot nl Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-02-10 08:42:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26054
[Bug fortran/25716] FAIL: gfortran.dg/char_result_11.f90 -O (test for excess errors)
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2006-01-10 13:04 --- Also, very telling, it fails for s390x-ibm-linux-gnu (64 bits) and *not* for s390-ibm-linux-gnu (32 bits). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
[Bug fortran/25494] [g77 only] error in g77 documentation (all versions)
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2005-12-27 12:11 --- Fixed in 3.4.6. -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25494
[Bug middle-end/18913] [3.4 Regression] seg. fault with -finit-local-zero option on complex array of dimension 1
--- Comment #5 from toon at moene dot indiv dot nluug dot nl 2005-12-27
12:24 ---
This is not a g77 error. The following C routine's compilation
fails in the same way - deep down in the middle world:
main()
{
__complex c[1] = { 0.0 };
}
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
Component|fortran |middle-end
Known to fail|3.2.3 3.3.3 3.4.0 |3.2.3 3.3.3 3.4.0 3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18913
[Bug fortran/25494] error in g77 documentation (all versions)
-- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |toon at moene dot indiv dot |dot org |nluug dot nl Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-19 15:43:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25494
[Bug fortran/25424] ICE in f77 with -finit-local-zero
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2005-12-15 08:29 --- *** This bug has been marked as a duplicate of 18913 *** -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25424
[Bug fortran/18913] [3.4 Regression] seg. fault with -finit-local-zero option on complex array of dimension 1
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2005-12-15 08:29 --- *** Bug 25424 has been marked as a duplicate of this bug. *** -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added CC||halcy0n at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18913
[Bug libfortran/25116] namelist read from non-opened file
--- Comment #9 from toon at moene dot indiv dot nluug dot nl 2005-11-29 19:20 --- FX, Your patch solved the problem for me. AFAICS, this patch is indeed the correct fix for this problem. Please apply it to (at least) 4.1 and trunk. It might be appropriate for the 4.0 branch, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25116
[Bug libfortran/25116] namelist read from non-opened file
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2005-11-28 15:36 --- I think you are right. I have been putting in debug statements all over and find that we are asking the wrong length of reads, 8 characters, instead of 1 in the failing case. I will get back to this in a day or so. Isn't this a sign that we are treating the read as UNFORMATTED ? Which would be wrong as namelist reads are always FORMATTED (note: the file isn't opened, so that cannot discern between FORMATTED and UNFORMATTED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25116
[Bug libfortran/25116] New: [regression wrt g77] A namelist read from an unnamed file should read from fort.n
Gfortran should read a namelist from a file that has not been given a name on an open statement from the fort.n where n is the unit number in the read statement. (this a defacto standard way to do it on Unix systems). Hmm, in lynx I do not see the attach file option, so here goes: namelist /nlist/ i, a read(9,nlist) write(6,nlist) end with the following contents of fort.9: nlist i=1, a=3.5 / should print the namelist to stdout, not give end of file. It works if you add open(9,file='fort.9') before the read. Blocks: HIRLAM. -- Summary: [regression wrt g77] A namelist read from an unnamed file should read from fort.n Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25116
[Bug fortran/24643] Unclassifiable statement on implicitly typed character substring
--- Comment #7 from toon at moene dot indiv dot nluug dot nl 2005-11-05 11:51 --- I got some preliminary results from debugging. By -fdump-parse-tree, YLOCAL does have the correct (implicitly determined) type of CHARACTER*8 at statement YLOCAL='A'. However, by the time we reach gfc_match_rvalue for the next statement YBTABLE=YLOCAL(1:2) its type is BT_UNKNOWN. So something has to squash the correctly determined type. How does one find out ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug fortran/24643] Unclassifiable statement on implicitly typed character substring
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2005-11-03 19:34 --- Mine ! All Mine ! -- toon at moene dot indiv dot nluug dot nl changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |toon at moene dot indiv dot |dot org |nluug dot nl Status|NEW |ASSIGNED Last reconfirmed|2005-11-02 20:39:10 |2005-11-03 19:34:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug fortran/24643] New: Unclassifiable statement on character substring concatenation
gfortran issues an Unclassifiable statement error when trying to compile a statement with concatenation of substrings of character variables. -- Summary: Unclassifiable statement on character substring concatenation Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug fortran/24643] Unclassifiable statement on character substring concatenation
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2005-11-02 20:36 --- Created an attachment (id=10114) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10114action=view) Test case for this bug Test case added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
[Bug fortran/20178] COMPLEX function returns incompatible with g77
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-05-15 11:32 --- Subject: Re: COMPLEX function returns incompatible with g77 tobi at gcc dot gnu dot org wrote: --- Additional Comments From tobi at gcc dot gnu dot org 2005-05-10 22:23 --- Fixed on the mainline. I will commit this to the branch after the obligatory testing and the necessary changes (unfortunately -fsecond-underscore became the default on the branch). [ Sorry for the late reply ] I wonder if that really means we have to stick to -fsecond-underscore on the 4.0 branch. Only 4.0.0 is out, and it is very probable that *nobody* uses it for any serious work in Fortran anyway. I feel we can safely change the default, even on the branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20178
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-05-15 18:49 --- Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 corsepiu at gcc dot gnu dot org wrote: Joel, do you recall the target in RTEMS which has 4-byte floats only? (We recently had an issue with it floating point context sizes related to it? IIRC, it had been a powerpc variant and we were forced to drop it because GCC doesn't support it. BTW1: IFAIK, there also exist sh-variants (target tuple *-single*) which don't have 8byte floats. RTEMS doesn't support them, so I've never tried to build fortran for then. Note that the major demand the Fortran Standard places on DOUBLE PRECISION is that it takes up twice the amount of storage. It also is supposed to be of higher precision, but that is a QOI issue. Cheers, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-04-23 10:58 --- (In reply to comment #10) Kazu, I just tried the patch, pr21030-vrp-ice.patch. It seems to fix the problems with gfortran and -O2. Kazu, could you propose your patch on gcc-patches or ping it ? Without this patch I won't be able to do any testing for my GCC Summit paper (deadline 1st of May). Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
[Bug fortran/20334] Dimensioned parameters get their dimensions lost.
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-03-12 12:57 --- Sorry, should have looked at old bugs first ... *** This bug has been marked as a duplicate of 19926 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20334
[Bug fortran/19926] Incorrect rank with PARAMETER and array element.
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-03-12 12:57 --- *** Bug 20334 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||toon at moene dot indiv dot ||nluug dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19926
[Bug fortran/20334] New: Dimensioned parameters get their dimensions lost.
This: character(len=50), dimension(100), parameter :: regels = 'Schrijf dit honderd keer uit.' print '(a)', regels end should print one hundred lines of Schrijf dit honderd keer uit. Unfortunately, it only does it only once: [EMAIL PROTECTED]:~/g95-bugs$ /usr/snp/bin/gfortran -static -O2 strafwerk.f90 [EMAIL PROTECTED]:~/g95-bugs$ ./a.out Schrijf dit honderd keer uit. [EMAIL PROTECTED]:~/g95-bugs$ cat strafwerk.f90 It *does* work if you remove the 'parameter' part. -- Summary: Dimensioned parameters get their dimensions lost. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot indiv dot nluug dot nl CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20334
[Bug middle-end/18902] Naive (default) complex division algorithm
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-01-21 20:23 --- Subject: Re: Naive (default) complex division algorithm pcarlini at suse dot de wrote: --- Additional Comments From pcarlini at suse dot de 2005-01-20 12:10 --- A first implementation of the algorithm was already in 3_4, under the name expand_cmplxdiv_wide (in optabs.cc), then Rth rewrote it in the tree-ssa branch as part of the new tree-complex.cc (It would be mildly interesting to see if the version in 3_4 works) In the meanwhile, I'm adding Rth in CC of 19486. Indeed (ChangeLog.1): Tue May 18 03:53:37 1999 Craig Burley [EMAIL PROTECTED] Improve open-coding of complex divide: * flags.h: Declare new front-end-malleable flag. * toplev.c: Define new flag. * optabs.c (expand_cmplxdiv_straight): New function to do original open-coding. (expand_cmplxdiv_wide): New function to do new open-coding, from Toon Moene, with changes (call to emit_barrier, dropping of spurious `ok = 1;', plus the obvious `break;' - `return 0;'). (expand_binop): A bit of spacing fixing, while at it. Use new functions instead of inlining the open-coding code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902
[Bug fortran/19292] [metabug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 19280, which changed state. Bug 19280 Summary: Inconsistent licensing of libgfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19280 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug libfortran/19280] Inconsistent licensing of libgfortran
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-01-12 22:16 --- Weapons of Mass Relicensing ... -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19280
[Bug driver/13464] -i8 and -r8 not passed correctly to compiler proper.
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-01-07 21:58 --- This really, really is a driver issue. AFAICS, we stick to the correct definitions ... -- What|Removed |Added Component|fortran |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13464
[Bug libfortran/19280] Inconsistent licensing of libgfortran
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-01-05 22:18 --- This, indeed, is a real problem. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-05 22:18:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19280
[Bug libfortran/19280] Inconsistent licensing of libgfortran
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-01-05 22:19 --- I'll work on this (hopefully this weekend 8/9th of January '05) -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |toon at moene dot indiv dot |dot org |nluug dot nl Status|NEW |ASSIGNED Last reconfirmed|2005-01-05 22:18:11 |2005-01-05 22:19:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19280
[Bug target/18630] can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2004-11-28 12:42 --- Subject: Re: New: can't find a register in class `GENERAL_REGS' when trying to make Firefox 1.0 Dirk dot Schwartzkopff at gmx dot de wrote: It is impossible to compile Firefox on IBM zSeries with gcc 3.2.2: Dan, can you put this in a fortune cookie for Bugzilla - this is the best one I read in ages ... :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18630
[Bug fortran/18565] gfortran: CONJG: false error message about standard violation
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2004-11-24 00:26 --- Subject: Re: gfortran: CONJG: false error message about standard violation sgk at troutmask dot apl dot washington dot edu wrote: --- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2004-11-22 01:43 --- Toon, Don't you have commit access to the tree? You can fix this under the obvious rule. Given the comments on [EMAIL PROTECTED] you don't seem to understand how little time each of the maintainers have to even test their own patches :-) I just today managed to check that my idea actually holds water, and will probably (!) be committed the coming weeked (!) Cheers, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18565
[Bug fortran/18565] gfortran: CONJG: false error message about standard violation
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2004-11-24 00:33 --- Subject: Re: gfortran: CONJG: false error message about standard violation sgk at troutmask dot apl dot washington dot edu wrote: --- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2004-11-22 04:19 --- Toon, I take it back. The code as written is correct. Now you know why I want to have it reviewed :-( However, your data point is interesting. Perhaps the point where the decision is this a Fortran XX intrinsic is made at the wrong point. conjg(double complex) obviously is correct Fortran 95 (when double complex is a typedef of COMPLEX(8)), but dconjg is not a correct specific intrinsic. Thanks for looking into this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18565
[Bug fortran/18565] gfortran: CONJG: false error message about standard violation
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2004-11-20 12:03 --- (In reply to comment #0) z2 = conjg (z1) 1 Error: Type of argument 'z' in call to 'conjg' at (1) should be COMPLEX(4), not COMPLEX(8) Yep, I think this in intrinsic.c: add_sym_1 (dconjg, 1, 1, BT_COMPLEX, dd, GFC_STD_GNU, NULL, gfc_simplify_conjg, gfc_resolve_conjg, z, BT_COMPLEX, dd, 0); should be: add_sym_1 (dconjg, 1, 1, BT_COMPLEX, dd, GFC_STD_F95, NULL, gfc_simplify_conjg, gfc_resolve_conjg, z, BT_COMPLEX, dd, 0); Toon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18565
[Bug fortran/18518] equivalenced variables are not saved
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2004-11-20 12:10 --- Hmmm, I do not get this on my powerpc-unknown-linux-gnu: [EMAIL PROTECTED]:~/g95-bugs$ /usr/snp/bin/gfortran -O2 18518.f90 [EMAIL PROTECTED]:~/g95-bugs$ (LD_LIBRARY_PATH=/usr/snp/lib export LD_LIBRARY_PATH; ./a.out) 12345 12345 [EMAIL PROTECTED]:~/g95-bugs$ /usr/snp/bin/gfortran -v Reading specs from /usr/snp/lib/gcc/powerpc-unknown-linux-gnu/4.0.0/specs Configured with: ../gcc/configure --prefix=/usr/snp --disable-nls --disable-multilib Thread model: posix gcc version 4.0.0 20041119 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18518
[Bug fortran/17815] Language name for --enable-languages should be fortran instead of f95
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2004-11-20 12:16 --- I agree too, that's why I changed the status of this bug report to NEW, i.e., confirmed :-) Toon. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-20 12:16:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17815
[Bug fortran/17588] segfault with multiply included module with uninitialized vector
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2004-09-23 20:21 --- Also crashes on powerpc-unknown-linux-gnu (testing Debian up to date to Saterday 9:00 UTC). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC host triplet|i686-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2004-09-23 20:21:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17588
[Bug driver/13464] [gfortran options] -d8, -i8 and -r8 not passed correctly to compiler proper.
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2003-12-23 23:48 --- I believe this is what we want. -d8 shouldn't be Joined though. Well, yes, obviously - unfortunately, it *is*: a prefix [for -dletters] and therefore eaten (while it shouldn't, because '8' isn't one of the letters). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13464
