[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4/4.5
--- Comment #19 from bartoldeman at users dot sourceforge dot net 2009-06-04 04:03 --- Thanks for all the work -- another text processing program which changes some headers in big ASCII files (which is what inspired this bug) went from around real0m2.026s user0m1.764s sys 0m0.148s to around real0m0.657s user0m0.392s sys 0m0.140s It's hard to beat C or even Python here but it's certainly very good! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug libfortran/40334] 4.5 regression: changed BACKSPACE behaviour at end of file.
--- Comment #1 from bartoldeman at users dot sourceforge dot net 2009-06-04 00:30 --- Created an attachment (id=17950) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17950&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40334
[Bug libfortran/40334] New: 4.5 regression: changed BACKSPACE behaviour at end of file.
The following program (also attached) reads to eof, backspace, reads (eof detected), backspace, and reads again. The last read gets the last line with gfortran 4.5 (tested: r148116) but eof with gfortran <= 4.4, g95, g77 and Sun f95. >From reading comp.lang.fortran I know that EOF/BACKSPACE interaction can be problematic but I'd still hope this would work to be consistent with the other compilers. PROGRAM TEST IMPLICIT NONE CHARACTER(LEN=5) :: STR OPEN(2,FILE='fort.2',ACCESS='sequential') WRITE(2,'(A)')'HELLO' REWIND(2) DO READ(2,'(A)',END=1) STR PRINT *,STR ENDDO 1BACKSPACE 2 !the file pointer is now at EOF READ(2,*,END=2) STR PRINT *,'error1: not at eof',str STOP 2BACKSPACE 2 !the file pointer is now at EOF READ(2,'(A)',END=3) STR PRINT *,'error2: not at eof' STOP 3PRINT *,'correct' END -- Summary: 4.5 regression: changed BACKSPACE behaviour at end of file. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bartoldeman at users dot sourceforge dot net 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=40334
[Bug fortran/38407] New: Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy-argument
See also: http://gcc.gnu.org/ml/fortran/2007-08/msg00010.html The warning: Warning: Unused dummy argument 'foo' at (1) cannot always be easily avoided for stub functions, especially when dummy procedures are used. It would be nice if -Wunused-dummy-argument would be split from -Wunused-variable and also be moved from -Wall to -Wextra to make it consistent with C, where -Wunused-parameter plays this role. -- Summary: Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy- argument Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bartoldeman at users dot sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38407
[Bug libfortran/37754] New: READ I/O Performance regression from 4.3 to 4.4
GFortran is slower with I/O than g77 was (I think that was known already).
But 4.4 is even slower than 4.3 in certain cases, e.g.:
a simple program to count lines:
countlines.f
---
PROGRAM countlines
C Count lines on stdin
I=0
DO
READ(*,*,END=1)
I=I+1
ENDDO
1CONTINUE
PRINT *,I
END PROGRAM
-
Create a file with 10,000,000 empty lines, for instance like this:
$ python -c "import sys; sys.stdout.write('\n'*1000)" > temp
Using: gcc version 4.4.0 20081005 (experimental) [trunk revision 140878] (GCC):
$ gfortran -O countlines.f
$ time ./a.out < temp
1000
real0m3.745s
user0m3.740s
sys 0m0.004s
Using: gcc version 4.3.1 (Debian 4.3.1-9)
1000
real0m2.603s
user0m2.588s
sys 0m0.016s
Using: g77 (gcc version 3.4.6 (Debian 3.4.6-6))
1000
real0m0.733s
user0m0.728s
sys 0m0.004s
--
Summary: READ I/O Performance regression from 4.3 to 4.4
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bartoldeman at users dot sourceforge dot net
GCC build triplet: i586-pc-linux-gnu
GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug driver/35916] problem running GCC under Vista with relocated directory
--- Comment #8 from bartoldeman at users dot sourceforge dot net 2008-04-24 17:41 --- I submitted a patch to MinGW to work around the problem (in crt1.o and crt2.o): http://sourceforge.net/tracker/index.phpfunc=detail&aid=1951037&group_id=2435&atid=302435 -- bartoldeman at users dot sourceforge dot net changed: What|Removed |Added CC| |bartoldeman at users dot | |sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35916
[Bug fortran/31149] New: gfortran: no diagnostics about too many arguments in legacy code (vs. g77)
Consider this code: SUBROUTINE FOO(I) I=0 END SUBROUTINE BAR() CALL FOO(1,2) END compiled with g77 3.4.6: f77.f: In subroutine `bar': f77.f:1: SUBROUTINE FOO(I) 1 f77.f:6: (continued): CALL FOO(1,2) 2 Too many arguments passed to `foo' at (2) versus definition at (1) [info -f g77 M GLOBALS] no object file is generated. gfortran, even with -Wall, emits are no warnings or errors at all and an object file is generated. With a module or interface block gfortran does a lot better but then it is no longer Fortran 77 of course. -- Summary: gfortran: no diagnostics about too many arguments in legacy code (vs. g77) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bartoldeman at users dot sourceforge dot net GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31149
[Bug fortran/29097] New: !$ include 'omp_lib.h' does not work
The following conditional OpenMP inclusion does not work in gfortran
(gcc version 4.2.0 20060824 (experimental)):
program test
!$ include 'omp_lib.h'
end
$ gfortran -c -fopenmp test.f90
In file test.f90:2
!$ include 'omp_lib.h'
1
Error: Unclassifiable statement at (1)
!$ use omp_lib
works however, and I checked that the include succeeds without the !$.
--
Summary: !$ include 'omp_lib.h' does not work
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bartoldeman at users dot sourceforge dot net
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=29097
[Bug c/26492] -Wstrict-aliasing=2 warns about explicitly allowed cast to pointer to union.
--- Comment #2 from bartoldeman at users dot sourceforge dot net 2006-02-28 01:27 --- I am sorry about not being clear: I did read the documentation. With "Although the documentation does not say it must trigger, ..." I meant: "Although the documentation does not say that if the warning is given then strict aliasing is actually done, ...". which is why I filed this as an "enhancement" bug. I hope this case is not ambiguous, as the documentation may claim it to be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26492
[Bug c/26492] New: -Wstrict-aliasing=2 warns about explicitly allowed cast to pointer to union.
In a discussion about aliasing, some aliasing was explicitly allowed: see
http://gcc.gnu.org/ml/gcc/1999-06n/msg00294.html
from Mark Mitchell.
quote: "
extern void printf(const char*, ...);
#define noalias(type, ptr) \
(((union { type __x__; __typeof__(*(ptr)) __y__;} *)(ptr))->__x__)
typedef unsigned short usa[2];
int
main ()
{
int a = 0x12345678;
printf ("%x\n", a);
noalias(usa, &a)[1] = 0;
printf ("%x\n", a);
return 0;
}
Here's what I get:
linux1.codesourcery.com% ./a.out
12345678
5678
which is I think what you expected.
"
This still works, but with gcc 4.0.3 and -Wstrict-aliasing=2 I see:
(using #include instead of extern void printf...)
$ gcc -O2 -Wstrict-aliasing=2 alias.c
alias.c: In function 'main':
alias.c:13: warning: dereferencing type-punned pointer might break
strict-aliasing rules
$ ./a.out
12345678
5678
It would be nice if the warning would not trigger in this case. Although the
documentation does not say it must trigger, this is claimed to be a documented
extension and should work warning-free IMHO.
--
Summary: -Wstrict-aliasing=2 warns about explicitly allowed cast
to pointer to union.
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bartoldeman at users dot sourceforge dot net
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26492
[Bug c/19635] New: static nested function workaround for -Wmissing-declarations (see bug #1517) no longer works
Using gcc version 4.0.0 20050115 (experimental) (Debian 4.0-0pre4)
I see that:
int
main (void)
{
int a;
static int nested (int b)
{
return b + 2;
}
return (a + nested (a));
}
gives:
nested.c: In function 'main':
nested.c:8: error: invalid storage class for function 'nested'
without the "static" I get:
gcc -Wmissing-declarations nested.c
nested.c: In function `main':
nested.c:8: warning: no previous declaration for 'nested'
Has static been deprecated for nested functions? If yes, is there
another way to avoid the warning?
--
Summary: static nested function workaround for -Wmissing-
declarations (see bug #1517) no longer works
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bartoldeman at users dot sourceforge dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19635
