[Bug fortran/29872] New: GNU Fortran 95 (GCC) 4.1.1 (Gentoo 4.1.1-r2 not compatible with gdb
Problem occurs when using gdb. All works fine with GNU Fortran 95 (GCC) 4.1.1
(Gentoo 4.1.1-r1) but not with GNU Fortran 95 (GCC) 4.1.1 (Gentoo 4.1.1-r2).
(I'm assuming the bug was not introduced by Gentoo.) Get failure like this
test.f
i = 1
print '(''i='', i1)', i
end
gfortran -g -o test test.f
gdb test
b test.f:2
run
p i
With the result
Could not find the frame base for MAIN__.
I have also posted this on the gentoo bug site.
--
Summary: GNU Fortran 95 (GCC) 4.1.1 (Gentoo 4.1.1-r2 not
compatible with gdb
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fkrogh#gcc at mathalacarte dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29872
[Bug fortran/30998] New: Big code with assigned goto's loops with optimization
Code works with no optimization, and after removing the assigned goto's it works with optimization. I'm on a dual opteron system with GNU Fortran 95 (GCC) 4.1.2 (Gentoo 4.1.2) When compiling gcc, I used: CFLAGS=-O2 -march=opteron -pipe -fomit-frame-pointer The old g77 worked on this code. -- Summary: Big code with assigned goto's loops with optimization Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fkrogh#gcc at mathalacarte dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30998
[Bug fortran/56637] New: Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 Bug #: 56637 Summary: Bad result on max(1,shiftr(j,1)) Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fkrogh#g...@mathalacarte.com
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #1 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-16 18:02:49 UTC --- I realize this is not much help for a bug report. I can't get a small test case to fail, and if I change the optimization level it works. Also, I can't be sure whether the problem is in the compiler or the library, but I suspect the former. Here is a small snippet of code k = max(1, shiftr(j,1)) ! The increment during the sort do ! Sort constraints to make active (Shell sort) do i = k + 1, j In my small test case j is 13. And k gets the value 1. If I precede the first statement with a garbage statement i2=17 then after the first statement above, k has the correct value of 6, even though the added statement should not have changed the result. Here are my flags -ggdb -march=native -mpc80 -funroll-loops -pipe \ -ftree-vectorize -floop-strip-mine \ -floop-block -fimplicit-none -finit-real=NAN -fopenmp\ -fcheck=bounds -Wall -Wextra If I follow -ggdb with either -O1 or -O2 it gets the correct result. This is running on a Gentoo Linux system, with Intel I7 CPU's. Finally, here is a dump of the assembler code from the start of the first statement. Dump of assembler code from 0x40e5f1 to 0x40e6f1: = 0x0040e5f1 find_unequals+5571: mov0x1204(%rbx),%edx 0x0040e5f7 find_unequals+5577: mov$0x1,%eax 0x0040e5fc find_unequals+5582: shr%edx 0x0040e5fe find_unequals+5584: cmp%eax,%edx 0x0040e600 find_unequals+5586: jle0x40e604 find_unequals+5590 0x0040e602 find_unequals+5588: mov%edx,%eax 0x0040e604 find_unequals+5590: mov%eax,0x1330(%rbx) 0x0040e60a find_unequals+5596: mov0x1330(%rbx),%eax 0x0040e610 find_unequals+5602: add$0x1,%eax 0x0040e613 find_unequals+5605: mov0x1204(%rbx),%esi 0x0040e619 find_unequals+5611: mov%eax,0x133c(%rbx) 0x0040e61f find_unequals+5617: mov0x133c(%rbx),%eax 0x0040e625 find_unequals+5623: cmp%esi,%eax 0x0040e627 find_unequals+5625: jg 0x40ea50 find_unequals+6690 0x0040e62d find_unequals+5631: jmp0x40e630 find_unequals+5634 0x0040e62f find_unequals+5633: nop 0x0040e630 find_unequals+5634: mov0x133c(%rbx),%eax 0x0040e636 find_unequals+5640: cltq 0x0040e638 find_unequals+5642: test %rax,%rax 0x0040e63b find_unequals+5645: setle %dl 0x0040e63e find_unequals+5648: movzbl %dl,%edx 0x0040e641 find_unequals+5651: mov%edx,%edx 0x0040e643 find_unequals+5653: and$0x1,%edx 0x0040e646 find_unequals+5656: test %edx,%edx 0x0040e648 find_unequals+5658: je 0x40e666 find_unequals+5688 0x0040e64a find_unequals+5660: mov$0x1,%ecx 0x0040e64f find_unequals+5665: mov%rax,%rdx 0x0040e652 find_unequals+5668: mov$0x4820d8,%esi 0x0040e657 find_unequals+5673: mov$0x4827f0,%edi 0x0040e65c find_unequals+5678: mov$0x0,%eax 0x0040e661 find_unequals+5683: callq 0x401d70 _gfortran_runtime_error_at@plt 0x0040e666 find_unequals+5688: cmp$0x12,%rax 0x0040e66a find_unequals+5692: setg %dl 0x0040e66d find_unequals+5695: movzbl %dl,%edx 0x0040e670 find_unequals+5698: mov%edx,%edx 0x0040e672 find_unequals+5700: and$0x1,%edx 0x0040e675 find_unequals+5703: test %edx,%edx 0x0040e677 find_unequals+5705: je 0x40e695 find_unequals+5735 0x0040e679 find_unequals+5707: mov$0x12,%ecx 0x0040e67e find_unequals+5712: mov%rax,%rdx 0x0040e681 find_unequals+5715: mov$0x482148,%esi 0x0040e686 find_unequals+5720: mov$0x4827f0,%edi 0x0040e68b find_unequals+5725: mov$0x0,%eax 0x0040e690 find_unequals+5730: callq 0x401d70 _gfortran_runtime_error_at@plt 0x0040e695 find_unequals+5735: sub$0x1,%rax 0x0040e699 find_unequals+5739: add$0x4b8,%rax 0x0040e69f find_unequals+5745: mov0x4(%rbx,%rax,4),%eax 0x0040e6a3 find_unequals+5749: mov%eax,0x1200(%rbx) 0x0040e6a9 find_unequals+5755: mov0x1200(%rbx),%eax 0x0040e6af find_unequals+5761: add$0x1,%eax 0x0040e6b2 find_unequals+5764: movslq %eax,%rdx 0x0040e6b5 find_unequals+5767: test %rdx,%rdx 0x0040e6b8 find_unequals+5770: setle %al 0x0040e6bb find_unequals+5773: movzbl %al,%eax
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #3 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-16 18:46:06 UTC --- First some confusion. If I single step over the first statement it works properly. Once past that confusion, deleting both -floop-block and -floop-strip-mine from the make file it still fails. Although the test case I'm running is small, the actual code is quite large. After realizing the problem with single stepping over the statement causing it to work, I just tried that with the extra statement in front, and that actually fails if I set the breakpoint after k is defined. So that part of my original post should be ignored. When I tried a small test case before, I had not used the same flags as caused failure. I just tried such a case, and it worked, so no luck in generating a small test case.
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #5 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-16 21:25:46 UTC --- I don't mean to be argumentative, but I would like to ask: Would an index out of bounds explain why single stepping over the statement make it work, and would it explain that a higher level of optimization works?
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #7 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-16 21:44:46 UTC --- As mentioned in my first post, I am compiling with -fcheck-bounds. The errors are occurring in a subroutine inside what at the moment is a main program. That subroutine has no arguments. As this is code in the process of being developed, I have had run time errors for indexes being out of bounds. It turns out as a result of thinking more about the problems I'm dealing with (algorithmic issues) this part of the code is likely to disappear. I do appreciate others trying to find my problem, that is very nice. I was posting in the hope that I might help someone in finding a compiler bug.
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #9 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-17 04:42:39 UTC --- I have tried, but the small examples I've tried all work. And the code uses a library that I am not free to pass on. Probably you just have to call this unconfirmed and forget it. Sorry.
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #12 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-17 15:35:10 UTC --- For those using valgrind on gentoo for the first time (like me) you need to add to FEATURES in make.conf, splitdebug and re-emerge glibc. I've tried running valgrind on my program with no options. I does a lot of complaining about a use statement in connection with a library I'm using. Other than this, the next error it finds is beyond the point where I think the compiler goofed. The error found is one that my usual runtime also catches, and is either due to the previous error, or my usual sloppiness. I would ordinarily track down this error when I get to it. If there are special features in valgrind that I should be using, let me know and I'll give it a try. At this point it should be easy. I have tried making up a small example, but was unable to get the same problem. I'll try a bit more, but I don't think this is going to work.
[Bug fortran/56637] Bad result on max(1,shiftr(j,1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56637 --- Comment #13 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2013-03-17 16:40:22 UTC --- As perhaps you have already guessed, this is just me being confused. After removing a lot of stuff from the code, I inserted a print statement thus 620 k = max(1, shiftr(l,1)) ! The increment during the sort 621 do ! Sort constraints to make active (Shell sort) 622 do i = k + 1, l 623 print '(i=,i0)', i The break point is at line 621. The print occurs before the break point is reached. The print shows that all is o.k. I was confused as I thought the breakpoint would be hit before getting into the loop. Interestingly the breakpoint has the behavior I expected with -O1 or -O2. I'm sorry to have bothered you folks with this, but I'm glad to know a little about valgrind.
[Bug fortran/56887] New: Test for equality of reals now flagged with a warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56887 Bug #: 56887 Summary: Test for equality of reals now flagged with a warning Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fkrogh#g...@mathalacarte.com This is not a bug, but is a nuisance. I like to compile with -Wall -Wextra and after starting to use 4.8.0, tests for equality between reals is flagged with a warning. Perhaps you consider it a bad habit to assign small integer values (usually 0) to real variables and and occasionally test for equality on those. For me this warning is a nuisance, and I would like a way to turn it off without losing the benefits of -WALL and -Wextra. Alternatively just have it work as it did in the 4.7 series. Thanks, Fred
[Bug fortran/53867] New: Probably a bogus warning on types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53867 Bug #: 53867 Summary: Probably a bogus warning on types Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fkrogh#g...@mathalacarte.com Created attachment 27749 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27749 Compiling the attachment gives the error message Attached is a 9 line file which gives the following diagnostic EnumKind.f90:7.19: integer(k) :: C 1 Warning: Component 'c' in derived type 't' at (1) may not be C interoperable, even though derived type 't' is BIND(C) The NAG and Intel compilers (I have been told) don't give any such warning.
[Bug libfortran/58020] New: Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 Bug ID: 58020 Summary: Code for handling IEEE exceptions Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: fkrogh#gcc at mathalacarte dot com Dr. Richard Hanson has written code to provide IEEE exception handling to gfortran. He is the sole owner of that code and it could be used by gcc as they wish. The code is on my server at http://mathalacarte.com/hpcconsult He can be contacted at richard.koolh...@gmail.com. This feature is one of the oldest language features not available in gfortran, and can be a real impediment portability.
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #2 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- 1. Hanson is willing to assign the copyright if you expect to be using this work. There were thoughts to include this work on a SIAM website where we think SIAM would want the copyright, but if gfortran wants to use this work it could be posted someplace that does not require copyright. Perhaps you could provide a link that describe how this assignment can be done. The SIAM publication is still work in progress and the package can be noted as copyrighted in accordance with your standards. 2. There are no plans to support other architectures. The code is useful for the most prevalent one, and it is hoped would be useful there, as well as helpful to people interested in ports to other platforms. The Fortran standard says it is ok to *not* implement the IEEE modules, but there should be a module present on non-x86 machines that indicates this lack of support. Presently there is no support and no IEEE module of any kind. 3. The messy code is code I wrote, and is currently (I think) likely to be published in the Transactions on Mathematical Software. That code is used only in the testing code and is not used in what should be considered the main submission. It does nothing more that give pretty output of results. Please let us know, if given the above, you have an interest in pursuing this further. Fred
[Bug libfortran/58020] Code for handling IEEE exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 --- Comment #9 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- Concering Fortran language standards, our guru is W. Van Snyder a long time member of the Fortran Standards committee. He has said to me in an email: It's OK not to support stuff, but the inquiry functions have to be there to tell you.
[Bug fortran/60462] New: get_command returns more than it should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60462 Bug ID: 60462 Summary: get_command returns more than it should Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fkrogh#gcc at mathalacarte dot com
[Bug fortran/60462] get_command returns more than it should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60462 --- Comment #1 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- With this command line ./tapt -u ./mps afiro it gives /home/m/math77/lin/cons/anypoint/tapt ./tapt -u ./mps afiro The standard makes no mention of providing the first part of what is here. That first part is the full path for the command.
[Bug fortran/60462] get_command returns more than it should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60462 Fred Krogh fkrogh#gcc at mathalacarte dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- My apologies for a very bad bug report. I was running in the debugger, and started the run with run ./tapt -u ./mps afiro I should have started it with run -u ./mps afiro Doing things the correct way still puts in the the full path for the command, but I don't think there is anything here that should be called a bug. Sorry.
[Bug fortran/60993] New: Trouble initializing double precision variable using boz literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 Bug ID: 60993 Summary: Trouble initializing double precision variable using boz literals Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fkrogh#gcc at mathalacarte dot com Created attachment 32701 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32701action=edit This code illustrates the problem above The attached file gets this error during the compile inf.f90:21:0: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:5446 dinfn = transfer(infn, dinfn) ! Comment this to see failure above. If you comment out the statement causing this problem you can see that a transfer with a parameter array to a double works, but the same fails when using an array literal. I am just interested in getting plus and minus infinity set in parameters or variables to use in my code. Their use really simplifies some code. I'd like them defined for single, double, and quad precisions.
[Bug fortran/61002] New: Can't divide by 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61002 Bug ID: 61002 Summary: Can't divide by 0 Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fkrogh#gcc at mathalacarte dot com If I have a statement like real(kind(1.0d0)), parameter :: big=1.0d0/0.0d0 the compile fails with an error even when using the option -ffpe-trap= The man page for gcc makes this excellent point -Wno-div-by-zero Do not warn about compile-time integer division by zero. Floating- point division by zero is not warned about, as it can be a legitimate way of obtaining infinities and NaNs. And in fact, all I'm trying to do is obtain infinity.
[Bug fortran/61002] Can't divide by 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61002 --- Comment #2 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- Thanks, that did the job.
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 --- Comment #2 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- Thanks for the suggestion. As a result of another suggestion, I'm using -fno-range-check and defining infinity as 1.0d0/0.0d0.
[Bug fortran/61002] Can't divide by 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61002 --- Comment #4 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- No objection here. I had just missed -fno-range-check, see comment 1.
[Bug fortran/38305] New: Bug in gfortran with combination of P and F in a format.
Compile and run print '(f14.0,4pf14.0 )', 3742.0, 0.3742 end Actual Results: 3742. . Expected Results: 3742. 3742. On Gentoo this fails with versions 4.3. On Ubuntu with version 4.2. It works for me with GNU Fortran 95 (GCC) 4.1.2 (Gentoo 4.1.2 p1.1. From a long time member of X3J3 I agree that the discussion of P editing in 10.6.5.1 is silent concerning F editing on output, which might lead one to conclude that it has no effect. But the last paragraph about F editing in 10.5.1.2.1 (167:23) says modified by the established scale factor. So I think the new compiler is broken. Four of my compilers (lf95, NAG, Intel, g95 (4.0.3 0.91!)) give your old results. gfortran (4.1.2 20071124) gives your new results, which I think are wrong. -- Summary: Bug in gfortran with combination of P and F in a format. Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fkrogh#gcc at mathalacarte dot com GCC build triplet: Several http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38305
[Bug libfortran/41157] dtime not consistent in times reported
--- Comment #2 from fkrogh#gcc at mathalacarte dot com 2009-08-24 17:34
---
I had thought that was the case as well. But when I started getting some
negative times by subtracting the previous value from the current one in the
first location of the array I looked at the info file and found
Subsequent invocations of `DTIME' return values accumulated since
the previous invocation.
I modified the code to compute the times between invocations. The code now
looks like
program test_dtime
integer(8) :: i, j, k
real, dimension(2) :: tarray
real :: result
real :: accum, tarray1
real :: ptimes(10)
call dtime(tarray, result)
print '(''tarray,result:'', 1P, 3E20.11)', tarray, result
do i=1,1 ! Just a delay
j = i * i - i
end do
call dtime(tarray, result)
print '(''tarray,result:'', 1P, 3E20.11)', tarray, result
accum = 0.e0! Should accumulate 10 times previous tarray(1)
call dtime(tarray, result)
tarray1 = tarray(1)
do k=1, 10
do i=1,1! Just a delay
j = i * i - i
end do
call dtime(tarray, result)
ptimes(k) = tarray(1) - tarray1
tarray1 = tarray(1)
accum = accum + tarray(1)
end do
print '(''accum ='', 1P, E20.11 )', accum
print '(''ptimes ='', 1P, (3E20.11))', ptimes
end program test_dtime
And the output is
tarray,result: 0.000E+00 9.9939883E-04 9.9939883E-04
tarray,result: 3.80941987038E-01 3.0002608E-03 3.83941978216E-01
accum = 1.34219570160E+01
ptimes = 7.64882981777E-01 -3.78940939903E-01 7.60881841183E-01
-3.77939820290E-01 7.63881921768E-01 -3.80940914154E-01
7.63882875443E-01 -3.78940820694E-01 7.61881709099E-01
-3.78939628601E-01
There is a pattern here, but why? If dtime is getting overflows in times less
than a few seconds, there is a problem as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41157
[Bug fortran/51104] New: internal compiler error: in gfc_get_derived_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51104 Bug #: 51104 Summary: internal compiler error: in gfc_get_derived_type Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fkrogh#g...@mathalacarte.com Created attachment 25803 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25803 Try to compile this file to get the error message Attempting to compile the attached file gave atest.f90:6:0: internal compiler error: in gfc_get_derived_type, at fortran/trans-types.c:2298 Please submit a full bug report,
[Bug fortran/50619] New: Surprising interaction between -finit-real=NAN and the associate construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50619 Bug #: 50619 Summary: Surprising interaction between -finit-real=NAN and the associate construct Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fkrogh#g...@mathalacarte.com With a real variable defined in a derived type and referenced in an associate construct the value is redefined as a NaN when using the compilier flag -finit-real=NAN. The following two short routines illustrate the problem. program testa1 use testa2 type(test_ty) :: e call test(e) stop end program testa1 module testa2 type, public :: test_ty ! Values that can be set or looked at by the user. real :: rmult = 1.0e0 ! Multiplies reals using default format. end type test_ty contains subroutine test(e) type(test_ty) :: e print '(No associate: e%rmult =, es15.6)', e%rmult associate (rmult=e%rmult) print '(Associate: %rmult =, es15.6)', e%rmult end associate end subroutine test end module testa2 compile with gfortran -ggdb -finit-real=NAN -o testa1 testa2.f90 testa1.f90 and get No associate: e%rmult = 1.00E+00 Associate: %rmult =NaN
[Bug fortran/50892] New: Internal compiler error: in gimplify_expr, at gimplify.c:7477
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892 Bug #: 50892 Summary: Internal compiler error: in gimplify_expr, at gimplify.c:7477 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fkrogh#g...@mathalacarte.com Created attachment 25641 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25641 File test.f90 gives the internal compile error I'm using: GNU Fortran (Gentoo 4.6.1-r1 p1.0, pie-0.4.5) 4.6.1 Compilation flags are: -march=native -funroll-loops -pipe \ -ftree-vectorize -floop-strip-mine \ -floop-block -fimplicit-none -finit-real=NAN -ggdb In addition to the internal compiler error, there is a problem mentioned in a comment. According to a Fortran language lawyer, Fortran 2008 allows two local definitions of procedures to have the same binding label. This problem is illustrated in a comment. I'm mainly filing this bug because of the internal compiler error, which reads as follows: test.f90: In function 'test': test.f90:11:0: internal compiler error: in gimplify_expr, at gimplify.c:7477 Please submit a full bug report, with preprocessed source if appropriate. My CPU is: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz Thanks, Fred
[Bug fortran/49636] New: Associate construct confused with slightly complicated case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49636 Summary: Associate construct confused with slightly complicated case Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fkrogh#g...@mathalacarte.com Created attachment 24684 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24684 Fails test, with minor change works The attached 16 line fortran program shows the problem. The Intel (11.1) compiler works on this example.
[Bug fortran/49636] Associate construct confused with slightly complicated case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49636 --- Comment #1 from Fred Krogh fkrogh#gcc at mathalacarte dot com 2011-07-04 23:21:21 UTC --- Sorry failed to include the output of the program. Here it is. i_good= 1 3 5 i_bad= 1 4197184 3
[Bug fortran/65026] Internal compiler error with preprocessor in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65026 --- Comment #1 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- The first test.F90 I attached had some extra '=' signs in the #defines. I have tried to replace that test.F90 with a corrected version which gets the same error. I'm not clear if this replacement was successful.
[Bug fortran/65025] Internal compiler error with preprocessor in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025 --- Comment #2 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- Created attachment 34734 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34734action=edit The small test program that shows the error. Maybe this time the code will get there?
[Bug fortran/65026] New: Internal compiler error with preprocessor in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65026 Bug ID: 65026 Summary: Internal compiler error with preprocessor in gfortran Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fkrogh#gcc at mathalacarte dot com Compile the attached with gfortran -Dplet_=\'d\' -g -o test test.F90 or replace the d with s, q, or nonsense. The kind of preprocessor code used here seems to be handled just fine in the case of C code for gcc.
[Bug fortran/65025] New: Internal compiler error with preprocessor in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025 Bug ID: 65025 Summary: Internal compiler error with preprocessor in gfortran Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fkrogh#gcc at mathalacarte dot com Created attachment 34733 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34733action=edit Short program that gives the internal compiler error Compile the attached with gfortran -Dplet_=\'d\' -g -o test test.F90 or replace the d with s, q, or nonsense. The kind of preprocessor code used here seems to be handled just fine in the case of C code for gcc.
[Bug fortran/65025] Internal compiler error with preprocessor in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025 --- Comment #4 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- In collapsing a big code to the small example, I left out a line that should be there. Add below the first line use ISO_C_BINDING, only: C_DOUBLE, C_FLOAT, C_LONG_DOUBLE This has no effect however on the internal compiler error.
[Bug fortran/65025] Internal compiler error with preprocessor in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025 --- Comment #5 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- I realize (now) that this is not a valid Fortran code. I was trying to hard to make it work like it works in C. Removing the apostrophes around the s, d, and q, in both the code and on the command line, and all works, although I'm not sure about it being portable.
[Bug fortran/68968] New: Internal Compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68968 Bug ID: 68968 Summary: Internal Compiler error Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fkrogh#gcc at mathalacarte dot com Target Milestone: --- Created attachment 37073 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37073=edit Compile this as indicated in the comments and get a segmentation fault in the compiler test.F90 attached gives an internal compiler error (Segmentation fault) when compiled with gfortran -Dplet_=\'q\' -o test test.F90 If gfortran is replaced by cpp in the above, it seems to generate what one would expect.
