[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
-- bdavis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bdavis at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-09-19 00:49:39 |2006-04-17 22:53:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #15 from bdavis at gcc dot gnu dot org 2006-05-12 16:05 --- looks like there is agreement that the problem is fixed. -- bdavis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug fortran/40149] variable length still 6 ???
--- Comment #2 from bdavis at gcc dot gnu dot org 2009-06-12 17:17 --- i created a compilable example from the code snippet given: INTEGER PBLJARRAYPT(341,341,1) INTEGER NCSP0,IARRAY2,I NCSP0 = 1 IARRAY2 = 0 DO I = 2, 341 IARRAY2 = IARRAY2 + 1 PBLJARRAYPT(I,I,NCSP0) = IARRAY2 END DO PRINT*,'PBLJARRAYPT(2,2,1) = ',PBLJARRAYPT(2,2,1) PRINT*,'PBLJARRAYPT(3,3,1) = ',PBLJARRAYPT(3,3,1) PRINT*,'PBLJARRAYPT(341,341,1) = ',PBLJARRAYPT(341,341,1) END When ran, it gives PBLJARRAYPT(2,2,1) =1 PBLJARRAYPT(3,3,1) =2 PBLJARRAYPT(341,341,1) = 340 which looks fine to me. Unless more info is forthcoming on reproducing this bug, I think we should close it with no further action taken. It's only been open a month, doesn't hurt to let it sit for another :) --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40149
[Bug fortran/29050] New: segfault when too few values are in data statement of character array
[EMAIL PROTECTED] current]$ cat f.f
character*10 a(4,2) /'aaa','bbb','ccc','ddd'/
end
[EMAIL PROTECTED] current]$ /usr/local/bin/gfortran -c f.f
f.f:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED] current]$ g77 f.f
f.f: In program `MAIN__':
f.f:1:
character*10 a(4,2) /'aaa','bbb','ccc','ddd'/
^
Too few initial values in list of initializers for `a' at (^)
--
Summary: segfault when too few values are in data statement of
character array
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdavis at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29050
[Bug fortran/29051] New: segfault when too few values are in data statement of character array
[EMAIL PROTECTED] current]$ cat f.f
character*10 a(4,2) /'aaa','bbb','ccc','ddd'/
end
[EMAIL PROTECTED] current]$ /usr/local/bin/gfortran -c f.f
f.f:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED] current]$ g77 f.f
f.f: In program `MAIN__':
f.f:1:
character*10 a(4,2) /'aaa','bbb','ccc','ddd'/
^
Too few initial values in list of initializers for `a' at (^)
--
Summary: segfault when too few values are in data statement of
character array
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdavis at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29051
[Bug fortran/29052] New: segfault when too few values are in data statement of character array
[EMAIL PROTECTED] current]$ cat f.f
character*10 a(4,2) /'aaa','bbb','ccc','ddd'/
end
[EMAIL PROTECTED] current]$ /usr/local/bin/gfortran -c f.f
f.f:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED] current]$ g77 f.f
f.f: In program `MAIN__':
f.f:1:
character*10 a(4,2) /'aaa','bbb','ccc','ddd'/
^
Too few initial values in list of initializers for `a' at (^)
--
Summary: segfault when too few values are in data statement of
character array
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdavis at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29052
[Bug fortran/28974] Extremely slow compilation of enumerated DATA statements.
-- bdavis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bdavis at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-07 17:36:45 |2006-09-15 02:59:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28974
[Bug fortran/28974] Extremely slow compilation of enumerated DATA statements.
--- Comment #2 from bdavis at gcc dot gnu dot org 2006-09-15 03:01 --- This problem is very intriguing. For a first attempt I plan on adding a splay tree to constructors that need 'by element' access. This may allow this problem to be taken care of without changing every routine that uses gfc_constructor. bd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28974
[Bug fortran/28974] Extremely slow compilation of enumerated DATA statements.
--- Comment #3 from bdavis at gcc dot gnu dot org 2006-09-16 15:00 --- more mailing list traffic on this topic: http://gcc.gnu.org/ml/fortran/2006-09/msg00210.html --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28974
[Bug fortran/28974] Extremely slow compilation of enumerated DATA statements.
--- Comment #4 from bdavis at gcc dot gnu dot org 2006-09-17 13:54 --- before the patch: $ time /usr/local/bin/gfortran -c data.f90 real3m1.263s user3m0.519s sys 0m0.120s after: $ time /usr/local/bin/gfortran -c data.f90 real0m3.215s user0m3.052s sys 0m0.092s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28974
[Bug fortran/30285] gfortran excessive memory usage with large modules
--- Comment #3 from bdavis at gcc dot gnu dot org 2007-02-02 01:50 --- if you try the example, f951 may exit with a segfault. reason is this code takes a lot of stack space. for tcsh, "ulimit stacksize unlimited" was required. (just to save 10 minutes for the next person who takes a look at this !!) -- bdavis at gcc dot gnu dot org changed: What|Removed |Added CC| |bdavis at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/30285] gfortran excessive memory usage with large modules
--- Comment #4 from bdavis at gcc dot gnu dot org 2007-02-02 09:35 --- from what i see so far, the problem is in the .mod files, not in the reading of them. there are hundreds of thousands of 'commons' defined, which is silly. any way to get source to the attached mod files ? --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/30285] gfortran excessive memory usage with large modules
--- Comment #7 from bdavis at gcc dot gnu dot org 2007-02-02 22:36 --- perfect. that seems to duplicate the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/30285] gfortran excessive memory usage with large modules
--- Comment #8 from bdavis at gcc dot gnu dot org 2007-02-25 04:42 ---
the below patch looks like it fixes the problem. any chance this could be
tryed on the reported problem ?
--bud
Index: gcc/gcc/fortran/module.c
===
--- gcc/gcc/fortran/module.c(revision 122310)
+++ gcc/gcc/fortran/module.c(working copy)
@@ -3598,6 +3598,7 @@
write_common (gfc_symtree *st)
{
gfc_common_head *p;
+ pointer_info *pinfo;
const char * name;
int flags;
@@ -3607,6 +3608,14 @@
write_common (st->left);
write_common (st->right);
+ /* only need to write a given symtree entry once for
+ common blocks */
+ p = st->n.common;
+ pinfo = find_pointer(p);
+
+ if (pinfo != NULL && pinfo->u.wsym.state != UNREFERENCED)
+return;
+
mio_lparen ();
/* Write the unmangled name. */
@@ -3614,7 +3623,6 @@
mio_pool_string (&name);
- p = st->n.common;
mio_symbol_ref (&p->head);
flags = p->saved ? 1 : 0;
if (p->threadprivate) flags |= 2;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/30285] gfortran excessive memory usage with large modules
--- Comment #11 from bdavis at gcc dot gnu dot org 2007-04-20 03:41 --- i think not. i must have confued myself (rather easy to do!). will dig through the source this weekend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/30285] gfortran excessive memory usage with large modules
--- Comment #12 from bdavis at gcc dot gnu dot org 2007-04-20 20:56 --- i can confirm the attached patch is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug fortran/20086] gfortran print routine has problem with the character 'h'
--- Additional Comments From bdavis at gcc dot gnu dot org 2005-02-19 21:58 --- patch here: http://gcc.gnu.org/ml/fortran/2005-02/msg00177.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20086
[Bug libfortran/19872] closed and re-opened file not overwriten
--- Additional Comments From bdavis at gcc dot gnu dot org 2005-02-20 03:09 --- proposed patch: http://gcc.gnu.org/ml/fortran/2005-02/msg00182.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
[Bug fortran/34928] New: volatile does not accept a common block name
$ cat vol.f integer A common /C/ A volatile /C/ end $ gfortran --version GNU Fortran (GCC) 4.3.0 20071217 (experimental) Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ gfortran -c vol.f vol.f:3.15: volatile /C/ 1 Error: Syntax error in VOLATILE statement at (1) $ g77 vol.f -- Summary: volatile does not accept a common block name Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bdavis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34928
[Bug fortran/34933] New: no .XOR. operator
$ cat a.f logical a,b,c a = .TRUE. b = .FALSE. c = a .xor.b print*,c end $ gfortran --version GNU Fortran (GCC) 4.3.0 20071217 (experimental) Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ gfortran -c a.f a.f:4.17: c = a .xor.b 1 Error: Unknown operator 'xor' at (1) $ g77 a.f $ ./a.out T -- Summary: no .XOR. operator Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bdavis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34933
[Bug fortran/34933] no .XOR. operator
--- Comment #1 from bdavis at gcc dot gnu dot org 2008-01-23 02:51 --- metcalf and reid, page 40 says that .neqv. is logically the same as XOR. so, an easy work around is available. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34933
[Bug fortran/28039] Warn when ignoring extra characters in the format specification
--- Comment #2 from bdavis at gcc dot gnu dot org 2009-08-22 23:21 --- http://gcc.gnu.org/ml/fortran/2009-08/msg00324.html -- bdavis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bdavis at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-06-20 10:59:45 |2009-08-22 23:21:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
[Bug c++/28093] Wrong overload resolution with templates and namespaces
--- Comment #2 from bdavis at gcc dot gnu dot org 2009-08-23 02:20 --- Subject: Bug 28093 Author: bdavis Date: Sun Aug 23 02:19:59 2009 New Revision: 151021 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151021 Log: 2009-08-22 Bud Davis PR fortran/28093 * io.c : added variable to store original len of fmt * io.c (check_format): Consume H items using next_char in both modes to handle consecutive single quotes. Test for extra characters in fmt, issue warning. 2009-08-22 Bud Davis PR fortran/28039 * gfortran.dg/fmt_with_extra.f: new file. Added: trunk/gcc/testsuite/gfortran.dg/fmt_with_extra.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28093
[Bug fortran/28039] Warn when ignoring extra characters in the format specification
--- Comment #3 from bdavis at gcc dot gnu dot org 2009-08-23 02:20 --- Subject: Bug 28039 Author: bdavis Date: Sun Aug 23 02:19:59 2009 New Revision: 151021 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151021 Log: 2009-08-22 Bud Davis PR fortran/28093 * io.c : added variable to store original len of fmt * io.c (check_format): Consume H items using next_char in both modes to handle consecutive single quotes. Test for extra characters in fmt, issue warning. 2009-08-22 Bud Davis PR fortran/28039 * gfortran.dg/fmt_with_extra.f: new file. Added: trunk/gcc/testsuite/gfortran.dg/fmt_with_extra.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
[Bug fortran/28039] Warn when ignoring extra characters in the format specification
--- Comment #4 from bdavis at gcc dot gnu dot org 2009-08-23 02:27 --- http://gcc.gnu.org/ml/fortran/2009-08/msg00324.html -- bdavis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
[Bug fortran/41160] New: No more than one complex function in a file
gfortran gives an error, g77 accepts it without a problem [bda...@localhost ~/tmp]$ cat a.f COMPLEX FUNCTION F0_HDEC*16(M1,M2,QSQ) RETURN END COMPLEX FUNCTION F1_HDEC*16(M1,M2,QSQ) RETURN END [bda...@localhost ~/tmp]$ /home/bdavis/g77/run/bin/g77 -c a.f [bda...@localhost ~/tmp]$ gfortran -c a.f a.f:1.30: COMPLEX FUNCTION F0_HDEC*16(M1,M2,QSQ) 1 Error: Expected formal argument list in function definition at (1) a.f:4.30: COMPLEX FUNCTION F1_HDEC*16(M1,M2,QSQ) 1 Error: Expected formal argument list in function definition at (1) a.f:2.72: RETURN 1 a.f:5.72: RETURN 2 Error: Two main PROGRAMs at (1) and (2) -- Summary: No more than one complex function in a file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bdavis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41160
[Bug fortran/41160] No more than one complex function in a file
--- Comment #3 from bdavis at gcc dot gnu dot org 2009-08-25 02:03 --- lets close with no action taken. *** This bug has been marked as a duplicate of 36234 *** -- bdavis at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41160
[Bug fortran/36234] Document lack of g77's "complex function name*16" syntax
--- Comment #3 from bdavis at gcc dot gnu dot org 2009-08-25 02:03 --- *** Bug 41160 has been marked as a duplicate of this bug. *** -- bdavis at gcc dot gnu dot org changed: What|Removed |Added CC||bdavis at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36234
[Bug fortran/41152] [4.5 Regression] Spurious diagnostic "Extraneous characters in format"
-- bdavis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bdavis at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-08-24 11:19:15 |2009-08-25 02:04:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41152
[Bug c++/28093] Wrong overload resolution with templates and namespaces
--- Comment #3 from bdavis at gcc dot gnu dot org 2009-08-26 02:18 --- Subject: Bug 28093 Author: bdavis Date: Wed Aug 26 02:18:14 2009 New Revision: 151112 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151112 Log: 2009-08-22 Bud Davis PR fortran/28093 * io.c: reverted previous patch Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28093
[Bug c++/43240] New: Code does not work at -O1
the code below behaves differently at -O1 and -O2.
#include
static void swapcopy_int( int * target, char * source, int num_bytes )
{
int * to = target ;
int * from = (int *) source ;
for(int count=0; count < num_bytes/sizeof(int); count++ ){
int t2 ;
int t1 = *from++ ;
*(((char *)&t2)+3) = *(((char *)&t1) ) ;
*(((char *)&t2)+2) = *(((char *)&t1)+1) ;
*(((char *)&t2)+1) = *(((char *)&t1)+2) ;
*(((char *)&t2) ) = *(((char *)&t1)+3) ;
*to++ = t2 ;
}
}
int main()
{
int num_rows = 0;
int num_cols = 0;
num_rows = 0x1000;
num_cols = 0x2000;
swapcopy_int ( &num_rows, (char *)&num_rows, sizeof( int) );
swapcopy_int ( &num_cols, (char *)&num_cols, sizeof( int) );
printf (" rows = %d cols = %d \n", num_rows, num_cols );
return 0;
}
$ g++ -O1 xx.c
$ ./a.out
the target is 0xbf8e3acc (1000) the source is 0xbf8e3acc (1000) bytes =
4
the target is 0xbf8e3ac8 (2000) the source is 0xbf8e3ac8 (2000) bytes =
4
rows = -1740992833 cols = -1740992833
^
These are wrong
$ g++ -O2 xx.c
$ ./a.out
the target is 0xbfe7985c (1000) the source is 0xbfe7985c (1000) bytes =
4
the target is 0xbfe79858 (2000) the source is 0xbfe79858 (2000) bytes =
4
rows = 16 cols = 32
^
These are right
$ g++ --version
g++ (GCC) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--
Summary: Code does not work at -O1
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdavis at gcc dot gnu dot org
GCC host triplet: i686/linux/gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43240
[Bug fortran/43339] Incorrect output for pgm checking data sharing attributes
--- Comment #1 from bdavis at gcc dot gnu dot org 2010-04-15 02:25 --- i concur. it is a bug. -- bdavis at gcc dot gnu dot org changed: What|Removed |Added CC||bdavis at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-15 02:25:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43339
[Bug fortran/42267] New: interaction between -finit-local-zero and -fno-automatic
when using both flags, the variables are initialized on every function call. see the example below: bash-3.2$ cat lvar.f REAL A(100) PRINT*,'Expect them to be zero' CALL ONE PRINT*,'Expect them to be 1..10' CALL TWO PRINT*,'Expect them to be 1..10' CALL ONE END SUBROUTINE ONE REAL A(100) INTEGER I PRINT*,"Sub One Loc(a) is ",LOC(A) DO I=1,10 PRINT*,A(I) A(I) = I END DO END SUBROUTINE TWO REAL A(100) INTEGER I PRINT*,"Sub Two Loc(a) is ",LOC(A) DO I = 1,10 A(I) = 0 END DO END bash-3.2$ /usr/local/bin/gfortran -static lvar.f -finit-local-zero -fno-automatic bash-3.2$ /usr/local/bin/gfortran --version GNU Fortran (GCC) 4.4.1 Copyright (C) 2009 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING bash-3.2$ ./a.out Expect them to be zero Sub One Loc(a) is135144832 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 Expect them to be 1..10 Sub Two Loc(a) is135144416 Expect them to be 1..10 Sub One Loc(a) is135144832 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -- Summary: interaction between -finit-local-zero and -fno-automatic Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bdavis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42267
[Bug fortran/42267] interaction between -finit-local-zero and -fno-automatic
--- Comment #1 from bdavis at gcc dot gnu dot org 2009-12-03 19:16 ---
here is a patch against 4.4.1
diff --context --recursive gcc-4.4.1/gcc/fortran/gfortran.h
gcc-4.4.1_bud/gcc/fortran/gfortran.h
*** gcc-4.4.1/gcc/fortran/gfortran.h2009-02-21 16:25:06.0 -0600
--- gcc-4.4.1_bud/gcc/fortran/gfortran.h2009-12-03 09:24:11.0
-0600
***
*** 2024,2029
--- 2024,2030
int flag_init_character;
char flag_init_character_value;
int flag_align_commons;
+ int flag_no_automatic;
int fpe;
diff --context --recursive gcc-4.4.1/gcc/fortran/options.c
gcc-4.4.1_bud/gcc/fortran/options.c
*** gcc-4.4.1/gcc/fortran/options.c 2008-11-03 01:20:24.0 -0600
--- gcc-4.4.1_bud/gcc/fortran/options.c 2009-12-03 09:24:54.0 -0600
***
*** 346,352
/* Implement -fno-automatic as -fmax-stack-var-size=0. */
if (!gfc_option.flag_automatic)
! gfc_option.flag_max_stack_var_size = 0;
if (pedantic)
{
--- 346,355
/* Implement -fno-automatic as -fmax-stack-var-size=0. */
if (!gfc_option.flag_automatic)
! {
! gfc_option.flag_no_automatic = 1;
! gfc_option.flag_max_stack_var_size = 0;
! }
if (pedantic)
{
diff --context --recursive gcc-4.4.1/gcc/fortran/resolve.c
gcc-4.4.1_bud/gcc/fortran/resolve.c
*** gcc-4.4.1/gcc/fortran/resolve.c 2009-06-20 04:21:06.0 -0500
--- gcc-4.4.1_bud/gcc/fortran/resolve.c 2009-12-03 09:49:52.0 -0600
***
*** 7486,7492
/* For saved variables, we don't want to add an initializer at
function entry, so we just add a static initializer. */
! if (sym->attr.save || sym->ns->save_all)
{
/* Don't clobber an existing initializer! */
gcc_assert (sym->value == NULL);
--- 7486,7492
/* For saved variables, we don't want to add an initializer at
function entry, so we just add a static initializer. */
! if (sym->attr.save || sym->ns->save_all || gfc_option.flag_no_automatic )
{
/* Don't clobber an existing initializer! */
gcc_assert (sym->value == NULL);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42267
[Bug fortran/42267] interaction between -finit-local-zero and -fno-automatic
--- Comment #3 from bdavis at gcc dot gnu dot org 2009-12-03 20:21 --- silly me. glad to see we both fixed it the same way :) close with no more action taken ? --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42267
[Bug fortran/28039] Warn when ignoring extra characters in the format specification
--- Comment #10 from bdavis at gcc dot gnu dot org 2009-12-30 04:25 ---
let's give this a try:
Index: gcc/gcc/testsuite/gfortran.dg/fmt_with_extra.f
===
--- gcc/gcc/testsuite/gfortran.dg/fmt_with_extra.f (revision 155511)
+++ gcc/gcc/testsuite/gfortran.dg/fmt_with_extra.f (working copy)
@@ -4,5 +4,25 @@
implicit none
real :: r
r = 1.0
- write(*,'(a),f)') 'Hello', r ! { dg-warning "Extraneous characters in
format at" "PR28039" { xfail *-*-* } }
+ write(*,'(a),f)') 'Hello', r ! { dg-warning "Extraneous characters in
format at" }
end
+! Below routine was also submitted by tobias.bur...@physik.fu-berlin.de
+! It showed up some problems with the initial implementation of this
+! feature.
+! This routine should compile without complaint or warning.
+ SUBROUTINE rw_inp()
+ CHARACTER(len=100) :: line
+ integer :: i5
+ character(100), parameter :: subchapter =
+ &'(79("-"),/,5("-")," ",A,/,79("-"),/)'
+ i5 = 1
+
+ READ(*,FMT="(4x,a)") line
+ 7182 FORMAT (a3)
+ 7130 FORMAT (i3)
+
+ WRITE (6,'(//'' icorr is not correctly transferred. icorr='',i5)
+ &') 42
+
+ write(*,subchapter) 'test'
+ END SUBROUTINE rw_inp
Index: gcc/gcc/fortran/io.c
===
--- gcc/gcc/fortran/io.c(revision 155511)
+++ gcc/gcc/fortran/io.c(working copy)
@@ -850,11 +850,11 @@
if (u != FMT_POSINT)
{
format_locus.nextc += format_string_pos;
- gfc_error_now ("Positive width required in format "
+ gfc_error ("Positive width required in format "
"specifier %s at %L", token_to_string (t),
&format_locus);
saved_token = u;
- goto finished;
+ goto fail;
}
u = format_lex ();
@@ -866,11 +866,11 @@
format_locus.nextc += format_string_pos;
if (gfc_option.warn_std != 0)
{
- gfc_error_now ("Period required in format "
+ gfc_error ("Period required in format "
"specifier %s at %L", token_to_string (t),
&format_locus);
saved_token = u;
- goto finished;
+ goto fail;
}
else
gfc_warning ("Period required in format "
@@ -970,11 +970,11 @@
gfc_warning ("The H format specifier at %L is"
" a Fortran 95 deleted feature", &format_locus);
}
-
if (mode == MODE_STRING)
{
format_string += value;
format_length -= value;
+ format_string_pos += repeat;
}
else
{
@@ -1152,6 +1152,8 @@
static gfc_try
check_format_string (gfc_expr *e, bool is_input)
{
+ gfc_try rv;
+ int i;
if (!e || e->ts.type != BT_CHARACTER || e->expr_type != EXPR_CONSTANT)
return SUCCESS;
@@ -1162,8 +1164,20 @@
format string that has been calculated, but that's probably not worth the
effort. */
format_locus = e->where;
-
- return check_format (is_input);
+ rv = check_format (is_input);
+ /* check for extraneous characters at the end of an otherwise valid format
+ string, like '(A10,I3)F5'
+ start at the end and move back to the last character processed,
+ spaces are OK */
+ if (rv == SUCCESS && e->value.character.length > format_string_pos)
+for (i=e->value.character.length-1;i>format_string_pos-1;i--)
+ if (e->value.character.string[i] != ' ')
+{
+ format_locus.nextc += format_length + 1;
+ gfc_warning ("Extraneous characters in format at %L",
&format_locus);
+ break;
+}
+ return rv;
}
will submit an official patch after doing regtesting against a clean tree.
since we are 'stabilizing' for 4.5, it might be a while for this is committed
so i am posting it here so the work is not lost.
--bud
--
bdavis at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
Last reconfirmed|2009-08-22 23:21:18 |2009-12-30 04:25:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
[Bug fortran/28039] Warn when ignoring extra characters in the format specification
--- Comment #11 from bdavis at gcc dot gnu dot org 2009-12-30 05:23 --- http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01200.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
[Bug fortran/42517] -fcheck=recursion does not work with -fopenmp
--- Comment #7 from bdavis at gcc dot gnu dot org 2010-01-04 17:54 --- Index: gcc/gcc/fortran/trans-decl.c === --- gcc/gcc/fortran/trans-decl.c(revision 155625) +++ gcc/gcc/fortran/trans-decl.c(working copy) @@ -4330,6 +4330,7 @@ sym->name); recurcheckvar = gfc_create_var (boolean_type_node, "is_recursive"); TREE_STATIC (recurcheckvar) = 1; + DECL_TLS_MODEL (recurcheckvar) = decl_default_tls_model (recurcheckvar); DECL_INITIAL (recurcheckvar) = boolean_false_node; gfc_add_expr_to_block (&block, recurcheckvar); gfc_trans_runtime_check (true, false, recurcheckvar, &block, -- bdavis at gcc dot gnu dot org changed: What|Removed |Added CC| |bdavis at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42517
[Bug fortran/25096] Non-conforming shapes of DATA object and data
--- Comment #3 from bdavis at gcc dot gnu dot org 2010-09-05 18:56 --- just a question. why is this illegal ? it takes 8 values to initialize... --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25096
[Bug fortran/34128] slow gfortran 4.x (library?) compared to g77 3.4
--- Comment #2 from bdavis at gcc dot gnu dot org 2007-11-17 22:35 --- here is what i got on a P4, running FC8. [EMAIL PROTECTED] gfc]$ /usr/bin/gfortran -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) [EMAIL PROTECTED] gfc]$ /usr/bin/gfortran demo1.f [EMAIL PROTECTED] gfc]$ time ./a.out result = -0.690680926641407 real0m0.948s user0m0.914s sys 0m0.002s [EMAIL PROTECTED] gfc]$ /usr/bin/gfortran demo2.f [EMAIL PROTECTED] gfc]$ time ./a.out result =1570795059.20410 real0m1.853s user0m1.808s sys 0m0.004s [EMAIL PROTECTED] gfc]$ g77 --version GNU Fortran (GCC) 3.4.6 20060404 (Red Hat 3.4.6-8) Copyright (C) 2006 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING or type the command `info -f g77 Copying'. [EMAIL PROTECTED] gfc]$ g77 demo1.f [EMAIL PROTECTED] gfc]$ time ./a.out result = -0.990368962 real0m0.938s user0m0.912s sys 0m0.002s [EMAIL PROTECTED] gfc]$ g77 demo2.f [EMAIL PROTECTED] gfc]$ time ./a.out result = 1.57079506E+09 real0m2.386s user0m2.354s sys 0m0.004s gfortran g77 demo1 0m0.948s0m0.938s demo2 0m1.853s0m2.386s the answers were different on demo1.f with these versions, and on the P4 under linux, i say gfortran is OK. --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34128
[Bug fortran/29648] Inlining only done for contained procedures
--- Comment #3 from bdavis at gcc dot gnu dot org 2007-12-01 02:24 --- in case someone does not know what a contained procedure is (i sure didn't without getting out the Metcalf and Reid book), below is an example: program fred integer j j = 0 call a(j) print*,j contains subroutine a(i) integer i i = i +2 end subroutine a end program fred compile it with no optimization and look at the assembler code, then compile it with -O2, the subroutine is inlined by gfortran. not really relevant to this PR, but something I learned and verified, which might be of use. --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29648
[Bug ada/34446] gnatprep evaluating "not" operator at incorrect precidence
--- Comment #3 from bdavis at gcc dot gnu dot org 2007-12-14 23:13 --- not sure i would call this one 'resolved'. the gnat users manual does not document any such restriction: -- In this example, expression is defined by the following grammar: expression ::= expression ::= = "" expression ::= = expression ::= Â’Defined Chapter 16: Preprocessing Using gnatprep 193 expression ::= not expression expression ::= expression and expression expression ::= expression or expression expression ::= expression and then expression expression ::= expression or else expression expression ::= ( expression ) - since NOT VAR_TRUE is an EXPRESSION and an expression can be an EXPRESSION or VAR_TRUE, it sure seems like it should work as described. the change that declares this an error is this one: Revision 125441 - (view) (download) - [select for diffs] Modified Wed Jun 6 10:40:36 2007 UTC (6 months, 1 week ago) by charlet File length: 46257 byte(s) Diff to previous 118249 (colored) 2007-04-20 Vincent Celier <[EMAIL PROTECTED]> * prep.ads, prep.adb (Expression): New Boolean parameter Complemented, defaulted to False. In the "not" case, recursive call with Complemented set to True. Do not allow "or" or "and" operators when Complemented is True. i did not find any discussion on this on gcc-patches during april (but it was a busy month, could have missed it). i think this is a valid bug. if gnatprep is supposed to have this limit, it should be expressed in the users manual. if it is not, then the code should be changed to work as expected. the request is very reasonable, and it used to work that way. backwards compatibility is important. some would call this a regression. regards, bud davis -- bdavis at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34446
[Bug ada/34446] gnatprep evaluating "not" operator at incorrect precidence
--- Comment #4 from bdavis at gcc dot gnu dot org 2007-12-16 23:05 --- re-opened pending additional comments. -- bdavis at gcc dot gnu dot org changed: What|Removed |Added CC||bdavis at gcc dot gnu dot ||org Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34446
[Bug fortran/24978] ICE in gfc_assign_data_value_range
--- Comment #15 from bdavis at gcc dot gnu dot org 2007-12-23 03:07 --- the test cases are great...but they show too many bugs !! can't decide whether to go for the 'grand unified solution' or just hit them one at a time :) --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
[Bug fortran/35940] Array BACK ignored in INDEX intrinsic when other args scalar
--- Comment #3 from bdavis at gcc dot gnu dot org 2008-04-29 19:23 --- this looks promising: Index: gcc/gcc/fortran/simplify.c === --- gcc/gcc/fortran/simplify.c (revision 134801) +++ gcc/gcc/fortran/simplify.c (working copy) @@ -1570,7 +1570,8 @@ int back, len, lensub; int i, j, k, count, index = 0, start; - if (x->expr_type != EXPR_CONSTANT || y->expr_type != EXPR_CONSTANT) + if (x->expr_type != EXPR_CONSTANT || y->expr_type != EXPR_CONSTANT + || b->expr_type != EXPR_CONSTANT) return NULL; if (b != NULL && b->value.logical != 0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35940
[Bug fortran/35940] Array BACK ignored in INDEX intrinsic when other args scalar
--- Comment #5 from bdavis at gcc dot gnu dot org 2008-04-30 00:54 --- close. here is a better patch. http://gcc.gnu.org/ml/fortran/2008-04/msg00278.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35940
[Bug fortran/35940] Array BACK ignored in INDEX intrinsic when other args scalar
--- Comment #6 from bdavis at gcc dot gnu dot org 2008-04-30 00:55 --- notice the 6 minutes between the above posts :) jerry was correct, it needed a NULL check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35940
[Bug fortran/26815] New: requires both arguments to ATAN2 to be of same type
[EMAIL PROTECTED] ac_avionics]$ cat a.f
REAL*4 EW
REAL*8 ED
REAL*4 TEMP
TEMP = ATAN2(EW,ED)
END
[EMAIL PROTECTED] ac_avionics]$ g77 a.f
[EMAIL PROTECTED] ac_avionics]$ gfortran a.f
In file a.f:4
TEMP = ATAN2(EW,ED)
1
Error: 'x' argument of 'atan2' intrinsic at (1) must be the same type and kind
as 'y'
[EMAIL PROTECTED] ac_avionics]$ gfortran --version
GNU Fortran 95 (GCC) 4.2.0 20060311 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
i will let the language lawyers decide if this is a bug or if g77 was too
lenient.
--
Summary: requires both arguments to ATAN2 to be of same type
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdavis at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26815
[Bug fortran/26816] New: FLOAT Intrinsic does not work with Integer Halfword input
[EMAIL PROTECTED] ac_avionics]$ cat b.f
REAL*4 EW
INTEGER*2 IH
IH = 2
EW = FLOAT(IH)
PRINT*,EW
END
[EMAIL PROTECTED] ac_avionics]$ g77 b.f
[EMAIL PROTECTED] ac_avionics]$ ./a.out
2.
[EMAIL PROTECTED] ac_avionics]$ gfortran b.f
In file b.f:4
EW = FLOAT(IH)
1
Error: Type of argument 'a' in call to 'float' at (1) should be INTEGER(4), not
INTEGER(2)
--
Summary: FLOAT Intrinsic does not work with Integer Halfword
input
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdavis at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26816
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #7 from bdavis at gcc dot gnu dot org 2006-03-29 01:47 --- proposed patch: http://gcc.gnu.org/ml/fortran/2006-03/msg00517.html http://gcc.gnu.org/ml/fortran/2006-03/msg00518.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #9 from bdavis at gcc dot gnu dot org 2006-03-30 13:52 --- after the above patch, here is a profile of the last file (that takes so long to compile): Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 15.52 19.0419.04 60138476 0.00 0.00 parse_atom 9.33 30.4811.44 239125668 0.00 0.00 module_char 5.22 36.88 6.40 89284617 0.00 0.00 compare_integers 4.60 42.52 5.64 ht_lookup_with_hash 4.22 47.70 5.18 2224328 0.00 0.00 insert 3.56 52.07 4.37 622 0.01 0.07 load_needed 2.96 55.70 3.63 5543817 0.00 0.00 get_integer 2.63 58.93 3.23 4035787 0.00 0.00 check_interface0 2.32 61.78 2.85 312 0.01 0.03 read_cleanup 2.31 64.61 2.83 74319506 0.00 0.00 get_module_locus 2.28 67.41 2.80 21727690 0.00 0.00 set_module_locus 1.77 69.58 2.17 25323260 0.00 0.00 require_atom 1.59 71.53 1.95 4464297 0.00 0.00 clear_sym_mark 1.57 73.45 1.92 720088 0.00 0.00 count_types_test 1.56 75.36 1.91 13155211 0.00 0.00 compare_true_names 1.50 77.20 1.84 948414 0.00 0.00 traverse_ns 1.37 78.88 1.68 5424920 0.00 0.00 compare_type_rank 1.37 80.56 1.68 5424108 0.00 0.00 compare_type_rank_if --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #10 from bdavis at gcc dot gnu dot org 2006-03-30 13:58 --- with the same patch, the aermod.f90 : Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 7.69 8.80 8.80 29723933 0.00 0.00 parse_atom 5.26 14.82 6.02 125084260 0.00 0.00 module_char 3.51 18.83 4.01 record_reg_classes 2.83 22.07 3.24 find_reloads 2.19 24.58 2.51 walk_tree 1.85 26.70 2.12 2331175 0.00 0.00 gt_ggc_mx_lang_tree_node 1.77 28.73 2.03 ht_lookup_with_hash 1.72 30.70 1.97 ggc_set_mark 1.48 32.39 1.69 ggc_alloc_stat 1.37 33.96 1.57 10696036 0.00 0.00 set_module_locus 1.27 35.41 1.45 13353395 0.00 0.00 require_atom 1.14 36.71 1.30 722236 0.00 0.00 gfc_match_strings 1.12 37.99 1.28 817282 0.00 0.00 insert 1.12 39.27 1.28 constrain_operands 1.08 40.50 1.23 31922526 0.00 0.00 get_module_locus 1.03 41.68 1.18 3220 0.00 0.00 traverse_ns 0.94 42.76 1.08 706 0.00 0.02 load_needed --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #11 from bdavis at gcc dot gnu dot org 2006-03-30 14:04 --- if this patch gets accepted, i vote to close the PR. we are still slower than we should be, but it is now linear and compiles in a 'reasonable time'. --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #12 from bdavis at gcc dot gnu dot org 2006-03-31 00:47 --- Subject: Bug 21130 Author: bdavis Date: Fri Mar 31 00:47:13 2006 New Revision: 112558 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112558 Log: 2006-03-30 Paul Thomas <[EMAIL PROTECTED]> Bud Davis <[EMAIL PROTECTED]> PR 21130 * module.c (load_needed): Traverse entire tree before returning. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug libfortran/17992] reading empty line does not return 0
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-23 04:07:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
[Bug libfortran/17992] reading empty line does not return 0
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-23 04:07 --- i concur, it is a libgfortran bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
[Bug libfortran/17992] reading empty line does not return 0
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-23 04:23 --- after thinking about this some more, i think it is a bug in g77. we are trying to read 3 things, the '/' which consumes the first /n, then two numbers (each I2). the file has 2 /n's in it. from the f77 stnadard: 12.9.5.2.1 Using a Format Specification. If a format specification has been established, format control (13.3) is initiated and editing is performed as described in 13.3 through 13.5. On input, the input list and format specification must not require more characters from a record than the record contains. language lawyers, please comment ! i have suspended work on this until we get some more input; is this a bug or not ? --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
[Bug libfortran/19071] complex formatted output has too many items
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-24 00:14 --- patch here http://gcc.gnu.org/ml/fortran/2004-12/msg00224.html -- What|Removed |Added Keywords|wrong-code |patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19071
[Bug libfortran/19064] runtime error when reading complex*16 using formatted I/O
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-24 00:29 --- maybe fixed by pr19071, please check !! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19064
[Bug libfortran/18778] ENDFILE is not functionnal
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-24 03:36 --- patch here: http://gcc.gnu.org/ml/fortran/2004-12/msg00228.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18778
[Bug libfortran/19064] runtime error when reading complex*16 using formatted I/O
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-29 07:59 --- closing, as all interested report it fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19064
[Bug libfortran/18983] can't open /dev/null as an output file
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-29 09:58 --- http://gcc.gnu.org/ml/fortran/2004-12/msg00252.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18983
[Bug libfortran/19194] Missing RECL parameter in OPEN statement
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-30 01:24 --- this is a run time library bug. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-30 01:24:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19194
[Bug libfortran/18778] ENDFILE is not functionnal
--- Additional Comments From bdavis at gcc dot gnu dot org 2005-01-01 02:14 --- re-patch: http://gcc.gnu.org/ml/fortran/2005-01/msg4.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18778
[Bug libfortran/19216] New: formatted read with leading slash
This is from FM923.FOR $ cat b.f INTEGER J1I(3) DATA J1I / 3,2,1 / WRITE(20,'(A)')'/ 10 20 30' WRITE(20,'(A)')'1 2 3 4' WRITE(20,'(A)')'5 6 7 8' REWIND(20) READ(20,*) (J1I(IVI), IVI=1,3) PRINT*,(J1I(IVI), IVI=1,3) READ(20,*) I,J PRINT*,I,J READ(20,*) I,J PRINT*,I,J END $ gfc b.f $ ./a.out 1 2 1 5 6 At line 11 of file b.f Fortran runtime error: End of file $ g77 b.f $ ./a.out 3 2 1 1 2 5 6 $ gfc --version GNU Fortran 95 (GCC 4.0.0 20050101 (experimental)) -- Summary: formatted read with leading slash Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bdavis at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19216
[Bug libfortran/19216] list directed read with leading slash
-- What|Removed |Added Summary|formatted read with leading |list directed read with |slash |leading slash http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19216
[Bug libfortran/18398] Formatted I/O problems
--- Additional Comments From bdavis at gcc dot gnu dot org 2005-01-06 06:13 --- patch here: http://gcc.gnu.org/ml/fortran/2005-01/msg00038.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18398
[Bug libfortran/19155] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)
--- Additional Comments From bdavis at gcc dot gnu dot org 2005-01-16 23:45 --- added nist test to the title. -- What|Removed |Added Summary|blanks not treated as zeros |blanks not treated as zeros |in 'E' format read |in 'E' format read (NIST ||FM110.FOR) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
[Bug libfortran/19314] inquire(position=) segfaults at runtime
--- Additional Comments From bdavis at gcc dot gnu dot org 2005-01-17 04:39 --- http://gcc.gnu.org/ml/fortran/2005-01/msg00184.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19314
[Bug fortran/19313] inquire(pad=) not implemented
--- Additional Comments From bdavis at gcc dot gnu dot org 2005-01-18 13:10 --- patch here: http://gcc.gnu.org/ml/fortran/2005-01/msg00207.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19313
[Bug fortran/19551] LAPACK routine claic1.f bug
--- Additional Comments From bdavis at gcc dot gnu dot org 2005-01-21 03:15 --- works OK on AMD-64 fails on i686 --bud -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-21 03:15:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19551
[Bug libfortran/19568] incorrect formatted read
-- What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-22 04:16:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
[Bug libfortran/19478] reading back from /dev/null
--- Additional Comments From bdavis at gcc dot gnu dot org 2005-01-30 15:24 --- proposed patch: http://gcc.gnu.org/ml/fortran/2005-01/msg00329.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19478
[Bug libfortran/19872] New: closed and re-opened file not overwriten
program wtest
implicit none
open(1,file='wtest.out')
write(1,'("1 2 3 4 5 6 7 8 9")')
close(1)
open(1,file='wtest.out')
write(1,'("9 8 7 6")')
close(1)
end
[EMAIL PROTECTED] gfortran]$ gfc a.f
[EMAIL PROTECTED] gfortran]$ ./a.out
[EMAIL PROTECTED] gfortran]$ cat wtest.out
9 8 7 6
1 2 3 4 5 6 7 8 9
[EMAIL PROTECTED] gfortran]$ g77 a.f
[EMAIL PROTECTED] gfortran]$ ./a.out
[EMAIL PROTECTED] gfortran]$ cat wtest.out
9 8 7 6
--
Summary: closed and re-opened file not overwriten
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdavis at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
[Bug fortran/17987] multidimensional array problem
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-10-14 10:08 --- if the example is compiled with: [EMAIL PROTECTED] ~]$ g77 x.f -fno-automatic [EMAIL PROTECTED] ~]$ ./a.out ==1st time= first time is=: 1 1 1 0.200031 2 1 1. 2 1 1 0.400062 2 1 2. 1 1 2 0.200031 2 2 1. 2 1 2 0.400062 2 2 2. ZZZ are=: 1 0.20003 1. 0.20003 1. 2 0.40006 2. 0.40006 2. ===2nd time ZZZ are=: 1 0.20003 1. 0.20003 1. 2 0.40006 2. 0.40006 2. This is a common difference between g77 and some other fortran compilers. HTH, bud davis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17987
[Bug libfortran/17706] reading a value of 0.0 gives a value of -0.0
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-09-28 04:12 --- proposed patch: http://gcc.gnu.org/ml/fortran/2004-09/msg00276.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17706
[Bug libfortran/18122] gfortran internal error in namelist read
-- What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-23 12:41:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18122
[Bug libfortran/18284] New: BACKSPACE broken
open(unit=10,access='SEQUENTIAL')
do I = 1,200
write(10,*)I
end do
backspace(10)
backspace(10)
read(10,*)I
print*,I
end
gives a runtime error. it should report "199", just like g77.
--
Summary: BACKSPACE broken
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdavis at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18284
[Bug libfortran/18297] gfortran : file opening fails if only read access
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-11-04 23:21 --- gfortran runtime does not know that you only intend to write to the file. you need to add ACCESS='READ' to the open statement. With ACCESS set to read, a read only file can be opened. i do not think this is a bug. --bud davis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18297
[Bug libfortran/18284] BACKSPACE broken
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-11-24 21:42 --- revised patch: http://gcc.gnu.org/ml/fortran/2004-11/msg00189.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18284
[Bug libfortran/18398] Formatted I/O problems
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-26 14:34:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18398
[Bug fortran/18108] [gfortran] overloading does not work for functions
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-11-26 14:40 --- confirmed. [EMAIL PROTECTED] pr18398]$ gfc z.f90 In file z.f90:27 l = bar (3) 1 Error: Symbol 'bar' at (1) has no IMPLICIT type [EMAIL PROTECTED] pr18398]$ gfc --version GNU Fortran 95 (GCC 4.0.0 20041124 (experimental)) -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-26 14:40:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18108
[Bug libfortran/18398] Formatted I/O problems
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-11-27 15:33 --- here's a shorter test case: program rinput implicit double precision(a-h,o-z) character *8 a,b open(unit=7) write(7,*)'aaa123.456' write(7,*)'bbb-123.456' write(7,*) rewind(7) 610 format(a8,f10.5) read (7,610) a,cafin ,b,angmom print*, a,cafin ,b,angmom stop end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18398
[Bug libfortran/18364] endfile does not truncate file
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-11-27 19:31 --- proposed patch: http://gcc.gnu.org/ml/fortran/2004-11/msg00218.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18364
[Bug libfortran/18710] New: img part of complex number not written to direct access file
this from nist test fm910.for
$ cat c.f
COMPLEX C
OPEN(UNIT=9,FILE='A',ACCESS='DIRECT',STATUS='OLD',RECL=132)
C = (120.0,240.0)
WRITE(9,REC=1)C
C = (0.0,0.0)
READ(9,REC=1)C
PRINT*,C
END
$ gfc c.f
$ ./a.out
( 120., 0.00)
$ g77 c.f
$ ./a.out
(120.,240.)
$
--
Summary: img part of complex number not written to direct access
file
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bdavis at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18710
[Bug libfortran/18710] img part of complex number not written to direct access file
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-11-29 01:32 --- possibly needs a front end change, as well as run-time.. c = __complex__ (1.2e+2, 2.4e+2); _gfortran_filename = "c.f"; _gfortran_line = 4; _gfortran_ioparm.unit = 9; _gfortran_ioparm.rec = 1B; _gfortran_st_write (); _gfortran_transfer_complex (&c, 4); _gfortran_st_write_done (); c = __complex__ (0.0, 0.0); _gfortran_filename = "c.f"; _gfortran_line = 6; _gfortran_ioparm.unit = 9; _gfortran_ioparm.rec = 1B; _gfortran_st_read (); _gfortran_transfer_complex (&c, 4); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18710
[Bug fortran/18778] ENDFILE is not functionnal
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-02 11:45 --- it is really not endfile, it is endfile not creating a file if it is called on a unit that does not yet exist. confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-02 11:45:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18778
[Bug libfortran/18778] ENDFILE is not functionnal
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-02 11:46 --- changed component to library -- What|Removed |Added Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18778
[Bug libf2c/18874] ? in namelist read leads to I/O recursion
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-08 01:38 --- i would imagine that the number of bugs fixed in g77 / libf2c will be small, but gcc3.4.X will be actively supported for a while. having the bugs reported let's users know that this is a known problem. maybe someone will fix it...even if it is not included in a release, the user might want the fix. so, my opinion, if bugs are found in g77/libf2c, they should be reported. if someone wants to fix them, great, but not likely due to most effort going in to gfortran. --bud davis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18874
[Bug libfortran/18891] write with no open causes core dump
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-09 09:41 --- sounds reasonable to me. note that gfc_offset is either a 32 or a 63 bit value depending on offset_t. there is a testsuite file to test this exact problem, unopened_unit_1.f90 ! PR 14565 program unopened_unit_1 Integer I,J Do I = 1,10 Write(99,*)I End Do Rewind(99) Do I = 1,10 Read(99,*)J If (J.ne.I) Call abort End Do End program so fixing this PR should also fix at least one testsuite failure on you platform. --bud -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
[Bug libfortran/18891] write with no open causes core dump
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-09 12:07 --- 32 or 64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18891
[Bug fortran/18913] [g77 only] seg. fault with -finit-local-zero option on complex array of dimension 1
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-12-11 01:35 --- same results on 3.4.2 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-11 01:35:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18913
[Bug fortran/28974] Extremely slow compilation of enumerated DATA statements.
--- Comment #5 from bdavis at gcc dot gnu dot org 2006-11-06 04:10 --- patch here: http://gcc.gnu.org/ml/fortran/2006-11/msg00148.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28974
[Bug fortran/28974] Extremely slow compilation of enumerated DATA statements.
--- Comment #6 from bdavis at gcc dot gnu dot org 2006-11-15 05:10 --- Subject: Bug 28974 Author: bdavis Date: Wed Nov 15 05:10:22 2006 New Revision: 118844 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118844 Log: 2006-11-15 Bud Davis <[EMAIL PROTECTED]> PR fortran/28974 * gfortran.h (gfc_expr): Add element which holds a splay-tree for the exclusive purpose of quick access to a constructor by offset. * data.c (find_con_by_offset): Use the splay tree for the search. (gfc_assign_data_value): Use the splay tree. (gfc_assign_data_value_range): ditto. * expr.c (gfc_get_expr): Initialize new element to null. (gfc_free_expr): Delete splay tree when deleting gfc_expr. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/data.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28974
