[Bug fortran/30689] equivalence modifies common block
--- Comment #7 from milan at cmm dot ki dot si 2007-02-04 22:56 --- Subject: Re: equivalence modifies common block pault == pault at gcc dot gnu dot org [EMAIL PROTECTED] writes: pault --- Comment #6 from pault at gcc dot gnu dot org pault 2007-02-04 12:03 --- I think that we can close this pault one, OK? pault I've marked it as invalid, although that seems a trifle pault unfair. pault Please feel post bugs if you find them - we would rather pault discuss PRs like this one than have disatisfied users out pault there! Yes it is OK to close it. I am sorry to bother you with this one, but I was thinking if it works with other compilers it should with gfortran, too. But then it is not very clear how the others do it, and I am not too much interested into other compilers, anyway. Thanks for helping me shed some new light in fortran tricks :-) Milan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30689
[Bug fortran/30689] New: equivalence modifies common block
I hope this is a new bug (I am not good at searching through bugzilla). I am also not sure if this is according to standards, but as I undertand equivalence is a harmless statement. It shouldn't change the lenght of the common block. I am using gfortran -fdefault-integer-8 to compile gaussian-03 program on x86_64 machine. Everything works fine including GOMP stuff. Only the command to reserve memory in the beginning doesn't work. One can use environment variable, but it is annoying to tell every student, how to do it, so I decided to fix also this and stumbled on the following problem: program lstint Implicit Integer(A-Z) REAL FP DOUBLE PRECISION DP COMMON/QPSTAT/LASTYP,STATUS,CHRCTR,DIGIT,Intger,FP,dp,LENSTR lenstr=15 write(*,*)'QPtranenter:lenstr=',lenstr Call QPutIt End Subroutine QPutIt Implicit Integer(A-Z) integer fpl,dpl(2) integer LASTYP,STATUS,CHRCTR,DIGIT,Intger,LENSTR Real FP Double Precision DP Common/QPStat/LASTYP,STATUS,CHRCTR,DIGIT,Intger,FP,DP,LENSTR Equivalence (DPL,DP),(FPL,FP) write(*,*)'QPutItstart:lenstr=',lenstr return end gfortran -fdefault-integer-8 -o x x.f ./x lenstr=15 lenstr=0 Apparently the address of lenstr gets shifted in the subroutine because of the equivalence statement. Is this the right behavior? -- Summary: equivalence modifies common block Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan at cmm dot ki dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30689
[Bug fortran/30689] equivalence modifies common block
--- Comment #3 from milan at cmm dot ki dot si 2007-02-03 23:52 --- I am sorry for misunderstanding the program. I just took out of something big, to show some weird behavior of COMMON and EQUIVALENCE. As you can imagine -fdefault-integer-8 trick is the only solution to make those old 1 million line of f77 code work in 64 bit machines. -fdefault-real-8 is not very good idea to compile gaussian03. I don't want to change too much in this program, but I do like gfortran for its speed over PGF. The weird behavior comes out if you delete the equivalence line, then everything is OK. So with the equivalence statement the COMMON block structure changes. And the program I put in the PR is showing just this. Of course it doesn't do anything useful, but you don't want to see the whole thing. I already fixed the stuff in gaussian program and it works OK now, but I still think there is something strange going on in the compiler to show this things or maybe I don't understand everything about the equivalece statement. I am using Jan 19 snapshot and I see the same warnings as Paul did and this and the wrong value of lenstr tells me that something is not right. Apparently it works with other compilers (pgf, intel) because there are a lot of testcases coming with gaussian03 package which would fail with this code not working. Is it right that any equivalence statement can change the lenght of a common block? -- milan at cmm dot ki dot si changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30689
[Bug fortran/30689] equivalence modifies common block
--- Comment #4 from milan at cmm dot ki dot si 2007-02-04 00:13 --- OK, maybe gfortran is right. It doesn't make much sense to me, but this is what I found from wikipedia links in its fortran entry: Variables and arrays in common blocks can appear in EQUIVALENCE statements but this has the effect of bringing all the associated items into the block. They can be used to extend the contents of the block upwards, subject to the rules for common block length, but not downwards. So it seems that equivalence can change the size of common block :-( In the next statement it also says that equivalence is mainly used to brake the rules of fortran :-? So I am basically willing to give up on this and never touch any equivalence stuff in the future :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30689
[Bug fortran/30613] New: gfortran -fopenmp -static produces bad executable
the command: gfortran -static -fopenmp -o xomp xomp.f works OK, but I when executing xomp it segfaults: export OMP_NUM_THREADS=2 ./xomp Segmentation fault if compiling with: gfortran -static -fopenmp -o xomp xomp.f everything is OK. This happens with any OpenMP program. Here is a simple example: PROGRAM OMPSTATIC !$OMP PARALLEL PRIVATE(n, p) p = omp_get_thread_num() n = OMP_GET_NUM_THREADS() write(*,*)'n,p=',n,p !$OMP END PARALLEL END PROGRAM I am using this: [EMAIL PROTECTED] ~/proj/g03 $ ~/gcc/bin/gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/milan/gcc-src/gcc-4.3-20070119/configure --prefix=/home/milan/gcc --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-shared --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20070119 (experimental) -- Summary: gfortran -fopenmp -static produces bad executable Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan at cmm dot ki dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30613
[Bug fortran/30450] New: calling subroutine with constant parameter
I checked google and gcc bugzila and couldn't find if this is standard or not but the following program should work (fortran used to pass all arguments as reference!!??): call sub(1) end subroutine sub(i) integer i i=i+1 return end Of course this program is very dumb but the functionality it requires has many uses in real life programs. Right now the program segfaults! -- Summary: calling subroutine with constant parameter Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan at cmm dot ki dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30450
[Bug fortran/30450] calling subroutine with constant parameter
--- Comment #3 from milan at cmm dot ki dot si 2007-01-12 18:23 --- Subject: Re: calling subroutine with constant parameter pinskia == pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: pinskia --- Comment #1 from pinskia at gcc dot gnu dot org pinskia 2007-01-12 17:58 --- The only use is to change the pinskia value of 1 :). pinskia Gfortran is correct as this behavior is undefined as you pinskia are trying to change the value of the constant 1. in pinskia Fortran all agruments are passed as reference. This has pinskia been what Fortran has done for years. Yes but in my case the compiler should create a temporary variable and use that in a real call to subroutine. Passing 1 to the the subroutine is just telling the compiler I am not interested in the final value of this parameter in the calling routine. But in some other places in the code this valus is important. I think this is what the compilers did in the old VAX times and I guess some other compilers do it also now. Since gfortran/gcc is so good (within 10% of ifort, sometimes faster sometimes slower) I lost interest in any other compiler, so I don't have anything handy to compile this program with say ifort. pinskia Oh and this is not an issue that was introduced by the pinskia change over to gfortran from g77. g77 also segfaulted on pinskia your undefined code. I couldn't remember this for sure, but I know this problem for long time already. Only I just fixed a bug in a very old program and couldn't beleive it is still there. I think gfortran is more picky when something goes wrong in the program and reports an error, while others just go on with some stupid values :-( I am still not convinced this is not standard complying. Milan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30450
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #18 from milan at cmm dot ki dot si 2005-12-29 07:34 --- Created an attachment (id=10564) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10564action=view) patch against gcc-4.1-20051223 As requested, I am posting Rob's patch which goes against the Dec 23 snapshot. I didn't change reverse_memcpy() which I think I should, but maybe the one who added it should be more appropriate person to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #17 from milan at cmm dot ki dot si 2005-12-26 15:54 --- (In reply to comment #16) Created an attachment (id=10296) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10296action=view) [edit] Patch to change delimitters to 4 bytes for unformatted records This is nearly the same patch that I posted before except for the head of the subversion repository. I tried this one, but is now already out of date. I just made a hand patch of 4.1.0-beta20051223 and it seems to be OK. When will this be in the 4.1 snapshots, so I don't need to patch it by hand? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #15 from milan at cmm dot ki dot si 2005-11-19 19:09 --- I didn 't know how to compile gcc-4.1... so I couldn't reply before. I realised I have to install both mpfr and gmp libraries for gcc to compile. It complains only about gmp :-( Yes, this patch works OK. I had to patch the gcc-4.1-20051112 snapshot myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug fortran/24945] New: calling two open statements (same unit) without close fails
I am trying to open the same file twice. This works in g77, but fails in gfortran-4.1-20051112 snapshot This is the program: integer iun,irecl iun=1 irecl=5 open(unit=iun,file='uu',status='unknown',access='direct', $ form='unformatted',recl=8*irecl) C close(unit=iun) open(unit=iun,file='uu',status='unknown',access='direct', $ form='unformatted',recl=8*irecl) end If I use close it works, but as you can guess this is a part of larger program so I don't want to know where to put this close statement! -- Summary: calling two open statements (same unit) without close fails Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan at cmm dot ki dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24945
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From milan at cmm dot ki dot si 2005-05-31 08:41 --- Great work! Thanks a million! Somehow I also have a problem with the name of the option, since g77 has exactly the same problem. When I compile with the g77 I get 8 byte headers on AMD64, so the name g77 doesn't really correspond to always get 4 byte headers. But this is very minor thing especially if it is documented how it works, the name shouldn't really matter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libfortran/17992] [4.0 only] reading empty line does not return 0
--- Additional Comments From milan at cmm dot ki dot si 2005-04-20 01:10 --- (In reply to comment #10) Can you try with a later build and tell us what your exact source and output is? OK, now it is fixed! I had to wait one more week to get the new snapshot. Thank you very much. On top of this bug many others which I didn't report yet (I didn't know what was going on) are fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 17992, which changed state. Bug 17992 Summary: [4.0 only] reading empty line does not return 0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/20932] Writing of strings sometime does not work
--- Additional Comments From milan at cmm dot ki dot si 2005-04-20 01:14 --- (In reply to comment #1) Can you try compiling your code with a compiler from today's source (2005-05-10)? Thomas Koenig just committed several fixes for handling End-of-Record. I had to wait another week to get the new snapshot. Indeed a lot of bugs were fixed so I am almost happy. However this one is still there. I actually have no idea how to simplify this problem. I'll try to isolate this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20932
[Bug fortran/20932] New: Writing of strings sometime does not work
I don't have a short example for this bug, but maybe someone can see what is
going on from the error message that I get. I am running large molecular
dynamics program
named CHARMM (Chemistry at HARvard Macromolecular Mechanics) and it runs fine
when compiled with gfortran (gcc-4.0.0-beta20050402.ebuild). Except a few
quirks. This one is very strange:
In the CHARMM we have a subroutine PSFSUM which basically prints out some info
about the molecular structure to be simulated. This is the message I get when
running CHARMM:
charmm 100x 100x-scalar
At line 442 of file psfsum.f
Fortran runtime error: Expected INTEGER for item 1 in formatted transfer, got
CHARACTER
(A)
^
If I make a separate program out of this line, which looks like this everything
is OK!!!
integer unit
unit=6
WRITE (UNIT, '(A)') ! this is line 441 in psfsum.f
' PSFSUM PSF modified: NONBOND lists and IMAGE atoms cleared.'
end
Then I go back into original psfsum.f and modify the above line to:
WRITE (UNIT, )
FORMAT(' ',
$ ' PSFSUM PSF modified: NONBOND lists and IMAGE atoms cleared.')
the big prgram is happy too. Note the single space string in the format
statement. If I don't put it there, then the program skips the whole line. If it
is there the printout is OK.
--
Summary: Writing of strings sometime does not work
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: milan at cmm dot ki dot si
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20932
[Bug fortran/20932] Writing of strings sometime does not work
--- Additional Comments From milan at cmm dot ki dot si 2005-04-11 00:42 --- (In reply to comment #1) Can you try compiling your code with a compiler from today's source (2005-05-10)? Thomas Koenig just committed several fixes for handling End-of-Record. I renamed the ebuild, so it downloaded and compiled gcc-4.1-20050410.tar.bz2 (I love Gantoo!) I tried with the problematic code and it is still the same problem :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20932
[Bug libfortran/17992] [4.0 only] reading empty line does not return 0
--- Additional Comments From milan at cmm dot ki dot si 2005-04-11 00:46 --- (In reply to comment #6) Fixed in 4.1.0, waiting for inclusion into 4.0. I just tried 4.1-20050410 and the problem is still there. So what was fixed? Or maybe the patches are not in this snapshot yet? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
[Bug libfortran/17992] [4.0 only] reading empty line does not return 0
--- Additional Comments From milan at cmm dot ki dot si 2005-04-11 01:58 --- (In reply to comment #8) (In reply to comment #7) (In reply to comment #6) Fixed in 4.1.0, waiting for inclusion into 4.0. I just tried 4.1-20050410 and the problem is still there. So what was fixed? Or maybe the patches are not in this snapshot yet? Are you sure that you are using that version? I would not trust gentoo. Gentoo has gcc-config command with which one can choose among installed gcc versions. After that I always run also gfortran --verbose which tells me the version which I use. This is GCC's command, so I think I can trust it ?? Also I noticed about 6% speedup in execution time over gcc-4.0, so I guess I am using the new stuff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
[Bug libfortran/17992] reading empty line does not return 0
--- Additional Comments From milan at cmm dot ki dot si 2005-01-06 23:16 --- 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. I simplified thing and threw out the / from format specification. If I put 2 empty lines in the psfres.dat file I get the two zeros. This is improvement!! I am using 4.0.0-20041212 snapshot. But still I need only one empty line for g77. However if I put only 2 space characters in the one line psfres.dat then I get 2 zeros. So we are almoste there I think this is what always worked in fortran even in the days of punch cards: the blank card always produced zeros when read in the input deck. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
[Bug libfortran/19303] New: Opteron problem when writing binary files: 8-byte record header instead of 4-byte record header
I am trying to read the binary files produced with amd64 on a 32 bit machine. This is not possible because the record header changed from 4-bytes to 8-bytes. Can this be fixed? Example program: write(1)'Z' end produces fort.1 on opteron with the following content if opened in emacs: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ But it produces: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ on 32 bit machine or using -m32 on opteron. I beleive this is libfortran bug or feature, but I still thing the files should be readable across the platforms, or there should be some compile time option for this. I hope this is not against some stupid standard :-( -- Summary: Opteron problem when writing binary files: 8-byte record header instead of 4-byte record header Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan at cmm dot ki dot si CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug fortran/17992] New: reading empty line does not return 0
This program should return 2 zeros if the file psfres.dat consist of 2 empty lines. This is true in case of g77, but gcc version 4.0.0 20041013 reports an end of file error. integer n,m open(unit=8,file='psfres.dat',status='unknown') read(8,'(/2i2)')n,m write(*,*)n,m end psfres.dat ( is just 2 empty lines ) If non empty then it works OK, but this is not fortran standard. I havent check the f95 standard :-( The program is taken from a much larger program (CHARMM), this is why there is / in the format. Another strange behavior is if I put numbers in the firat line (which should be ignored), then there is no eof error in gfortran. g77 behaves OK also in this case. -- Summary: reading empty line does not return 0 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan at cmm dot ki dot si CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992
