* [Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
@ 2014-03-16 16:07 ` dominiq at lps dot ens.fr
2014-03-16 17:49 ` burnus at gcc dot gnu.org
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-03-16 16:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-03-16
Summary|Random number problems with |[4.8/4.9 Regression]
|REAL64 precision at |Function with side effect
|different optimization |removed by the optimizer.
|levels |
Ever confirmed|0 |1
--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed, although this has nothing to do with REAL64 precision nor with
random number. The problem comes from the fact that one call to random() is
optimized away.
On trunk (4.9) the code is optimized as with following changes:
@@ -45,7 +45,7 @@ USE globalParameters
USE generalFunctions
IMPLICIT NONE
-REAL(DP):: magnitude
+REAL(DP):: magnitude, tmp
REAL(DP):: mass
REAL(DP):: angle1, angle2
REAL(DP):: upsilon0_local, gasConstant, T
@@ -71,11 +71,12 @@ DO i=1,2000
DO
magnitude = 5e0_DP*random()
! WRITE(*,*) magnitude, EXP(-magnitude**2)
- IF ( random() <= EXP(-magnitude**2) ) EXIT
+ tmp = random()
+ IF ( tmp <= EXP(-magnitude**2) ) EXIT
END DO
! WRITE(*,*)
- angle1=random()*twopi
+ angle1=tmp*twopi
angle2=ACOS(2e0_DP*random()-1e0_DP) ; angle2=angle2-pi/2e0_DP
upsilon0_local=SQRT(2e0_DP * gasConstant * T)
For the moment I don't really understand what is happening with 4.8, i.e.,
infinite loop. AFAIU the dumps it looks optimized as
@@ -69,9 +69,10 @@ T=293.15e0_DP
DO i=1,2000
DO
- magnitude = 5e0_DP*random()
+ tmp = random()
+ magnitude = 5e0_DP*tmp
! WRITE(*,*) magnitude, EXP(-magnitude**2)
- IF ( random() <= EXP(-magnitude**2) ) EXIT
+ IF ( tmp <= EXP(-magnitude**2) ) EXIT
END DO
! WRITE(*,*)
But the executable does not hang when compiled with 4.7.4 or trunk.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
2014-03-16 16:07 ` [Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer dominiq at lps dot ens.fr
@ 2014-03-16 17:49 ` burnus at gcc dot gnu.org
2014-03-17 6:38 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-03-16 17:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
CC| |burnus at gcc dot gnu.org
Target Milestone|--- |4.8.3
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Confirmed.
The problem is that "function random" is regarded as (implicit) pure. However,
gfortran's subroutine random_number is properly declared as impure.
Reduced example:
module m
contains
REAL(8) FUNCTION random()
CALL RANDOM_NUMBER(random)
END FUNCTION random
end module m
$ zgrep -i pure m.mod
0 0 FUNCTION IMPLICIT_PURE) () (REAL 8 0 0 0 REAL ()) 0 0 () () 3 () ()
Draft patch:
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -4407 +4407 @@ gfc_intrinsic_sub_interface (gfc_code *c, int error_flag)
- if (gfc_pure (NULL) && !isym->pure)
+ if (!isym->pure && gfc_pure (NULL))
@@ -4413,0 +4414,3 @@ gfc_intrinsic_sub_interface (gfc_code *c, int error_flag)
+ if (!isym->pure && gfc_implicit_pure (NULL))
+ gfc_current_ns->proc_name->attr.implicit_pure = 0;
+
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
2014-03-16 16:07 ` [Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer dominiq at lps dot ens.fr
2014-03-16 17:49 ` burnus at gcc dot gnu.org
@ 2014-03-17 6:38 ` jakub at gcc dot gnu.org
2014-03-19 21:03 ` burnus at gcc dot gnu.org
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-03-17 6:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
CC| |jakub at gcc dot gnu.org
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (2 preceding siblings ...)
2014-03-17 6:38 ` jakub at gcc dot gnu.org
@ 2014-03-19 21:03 ` burnus at gcc dot gnu.org
2014-03-20 6:53 ` burnus at gcc dot gnu.org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-03-19 21:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Wed Mar 19 21:03:14 2014
New Revision: 208687
URL: http://gcc.gnu.org/viewcvs?rev=208687&root=gcc&view=rev
Log:
2014-03-18 Tobias Burnus <burnus@net-b.de>
PR fortran/60543
PR fortran/60283
* gfortran.h (gfc_unset_implicit_pure): New prototype.
* resolve.c (gfc_unset_implicit_pure): New.
(resolve_structure_cons, resolve_function,
pure_subroutine): Use it.
* decl.c (match_old_style_init, gfc_match_data,
match_pointer_init, variable_decl): Ditto.
* expr.c (gfc_check_pointer_assign): Ditto.
* intrinsic.c (gfc_intrinsic_sub_interface): Ditto.
* io.c (match_vtag, gfc_match_open, gfc_match_close,
match_filepos, gfc_match_inquire, gfc_match_print,
gfc_match_wait): Ditto.
* match.c (gfc_match_critical, gfc_match_stopcode,
lock_unlock_statement, sync_statement, gfc_match_allocate,
gfc_match_deallocate): Ditto.
* parse.c (decode_omp_directive): Ditto.
* symbol.c (gfc_add_save): Ditto.
2014-03-18 Tobias Burnus <burnus@net-b.de>
PR fortran/60543
PR fortran/60283
* gfortran.dg/implicit_pure_4.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/implicit_pure_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/io.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (3 preceding siblings ...)
2014-03-19 21:03 ` burnus at gcc dot gnu.org
@ 2014-03-20 6:53 ` burnus at gcc dot gnu.org
2014-03-20 19:42 ` burnus at gcc dot gnu.org
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-03-20 6:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Thu Mar 20 06:53:01 2014
New Revision: 208693
URL: http://gcc.gnu.org/viewcvs?rev=208693&root=gcc&view=rev
Log:
2014-03-19 Tobias Burnus <burnus@net-b.>
PR fortran/60543
* io.c (check_io_constraints): Use gfc_unset_implicit_pure.
* resolve.c (resolve_ordinary_assign): Ditto.
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/fortran/resolve.c
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (4 preceding siblings ...)
2014-03-20 6:53 ` burnus at gcc dot gnu.org
@ 2014-03-20 19:42 ` burnus at gcc dot gnu.org
2014-03-20 19:42 ` burnus at gcc dot gnu.org
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-03-20 19:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Thu Mar 20 19:42:15 2014
New Revision: 208733
URL: http://gcc.gnu.org/viewcvs?rev=208733&root=gcc&view=rev
Log:
2014-03-20 Tobias Burnus <burnus@net-b.de>
PR fortran/60543
PR fortran/60283
* gfortran.h (gfc_unset_implicit_pure): New prototype.
* resolve.c (gfc_unset_implicit_pure): New.
(resolve_structure_cons, resolve_function,
pure_subroutine, resolve_ordinary_assign): Use it.
* decl.c (match_old_style_init, gfc_match_data,
match_pointer_init, variable_decl): Ditto.
* expr.c (gfc_check_pointer_assign): Ditto.
* intrinsic.c (gfc_intrinsic_sub_interface): Ditto.
* io.c (match_vtag, gfc_match_open, gfc_match_close,
match_filepos, gfc_match_inquire, gfc_match_print,
gfc_match_wait, check_io_constraints): Ditto.
* match.c (gfc_match_critical, gfc_match_stopcode,
lock_unlock_statement, sync_statement, gfc_match_allocate,
gfc_match_deallocate): Ditto.
* parse.c (decode_omp_directive): Ditto.
* symbol.c (gfc_add_save): Ditto.
2014-03-20 Tobias Burnus <burnus@net-b.de>
PR fortran/60543
PR fortran/60283
* gfortran.dg/implicit_pure_4.f90: New.
Added:
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/implicit_pure_4.f90
Modified:
branches/gcc-4_7-branch/gcc/fortran/ChangeLog
branches/gcc-4_7-branch/gcc/fortran/decl.c
branches/gcc-4_7-branch/gcc/fortran/gfortran.h
branches/gcc-4_7-branch/gcc/fortran/intrinsic.c
branches/gcc-4_7-branch/gcc/fortran/io.c
branches/gcc-4_7-branch/gcc/fortran/match.c
branches/gcc-4_7-branch/gcc/fortran/parse.c
branches/gcc-4_7-branch/gcc/fortran/resolve.c
branches/gcc-4_7-branch/gcc/fortran/symbol.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (5 preceding siblings ...)
2014-03-20 19:42 ` burnus at gcc dot gnu.org
@ 2014-03-20 19:42 ` burnus at gcc dot gnu.org
2014-03-20 19:44 ` [Bug fortran/60543] [4.7/4.8/4.9 " burnus at gcc dot gnu.org
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-03-20 19:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Thu Mar 20 19:42:00 2014
New Revision: 208732
URL: http://gcc.gnu.org/viewcvs?rev=208732&root=gcc&view=rev
Log:
2014-03-20 Tobias Burnus <burnus@net-b.de>
PR fortran/60543
PR fortran/60283
* gfortran.h (gfc_unset_implicit_pure): New prototype.
* resolve.c (gfc_unset_implicit_pure): New.
(resolve_structure_cons, resolve_function,
pure_subroutine, resolve_ordinary_assign): Use it.
* decl.c (match_old_style_init, gfc_match_data,
match_pointer_init, variable_decl): Ditto.
* expr.c (gfc_check_pointer_assign): Ditto.
* intrinsic.c (gfc_intrinsic_sub_interface): Ditto.
* io.c (match_vtag, gfc_match_open, gfc_match_close,
match_filepos, gfc_match_inquire, gfc_match_print,
gfc_match_wait, check_io_constraints): Ditto.
* match.c (gfc_match_critical, gfc_match_stopcode,
lock_unlock_statement, sync_statement, gfc_match_allocate,
gfc_match_deallocate): Ditto.
* parse.c (decode_omp_directive): Ditto.
* symbol.c (gfc_add_save): Ditto.
2014-03-20 Tobias Burnus <burnus@net-b.de>
PR fortran/60543
PR fortran/60283
* gfortran.dg/implicit_pure_4.f90: New.
Added:
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/implicit_pure_4.f90
Modified:
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/decl.c
branches/gcc-4_8-branch/gcc/fortran/expr.c
branches/gcc-4_8-branch/gcc/fortran/gfortran.h
branches/gcc-4_8-branch/gcc/fortran/intrinsic.c
branches/gcc-4_8-branch/gcc/fortran/io.c
branches/gcc-4_8-branch/gcc/fortran/match.c
branches/gcc-4_8-branch/gcc/fortran/parse.c
branches/gcc-4_8-branch/gcc/fortran/resolve.c
branches/gcc-4_8-branch/gcc/fortran/symbol.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.7/4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (6 preceding siblings ...)
2014-03-20 19:42 ` burnus at gcc dot gnu.org
@ 2014-03-20 19:44 ` burnus at gcc dot gnu.org
2014-03-23 14:48 ` sarantis.pantazis at gmail dot com
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-03-20 19:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|4.8.3 |4.7.4
Summary|[4.8/4.9 Regression] |[4.7/4.8/4.9 Regression]
|Function with side effect |Function with side effect
|removed by the optimizer. |removed by the optimizer.
--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
FIXED on the 4.7 and 4.8 branches and on the trunk (to become 4.9.0).
Thanks for the report and sorry for the breakage!
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.7/4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (7 preceding siblings ...)
2014-03-20 19:44 ` [Bug fortran/60543] [4.7/4.8/4.9 " burnus at gcc dot gnu.org
@ 2014-03-23 14:48 ` sarantis.pantazis at gmail dot com
2014-03-23 14:52 ` sarantis.pantazis at gmail dot com
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: sarantis.pantazis at gmail dot com @ 2014-03-23 14:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #8 from Sarantis Pantazis <sarantis.pantazis at gmail dot com> ---
Created attachment 32430
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32430&action=edit
Compilation logs and installation workflow
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.7/4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (8 preceding siblings ...)
2014-03-23 14:48 ` sarantis.pantazis at gmail dot com
@ 2014-03-23 14:52 ` sarantis.pantazis at gmail dot com
2014-03-23 15:07 ` dominiq at lps dot ens.fr
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: sarantis.pantazis at gmail dot com @ 2014-03-23 14:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #9 from Sarantis Pantazis <sarantis.pantazis at gmail dot com> ---
Thank you for the fast response and effort. I have installed gcc from svn but
the results are still the same. Perhaps I mis-installed something? Attached you
will find the logs and the installation workflow. Is step #14 perhaps wrong?
The output of gfortran -v seems correct though.
Using built-in specs.
COLLECT_GCC=/home/sarantis/latestGcc/gcc-build/gcc/gfortran
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/sarantis/latestGcc
--enable-languages=c,fortran,c++ --disable-multilib
Thread model: posix
gcc version 4.9.0 20140323 (experimental) (GCC)
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.7/4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (9 preceding siblings ...)
2014-03-23 14:52 ` sarantis.pantazis at gmail dot com
@ 2014-03-23 15:07 ` dominiq at lps dot ens.fr
2014-03-23 23:18 ` dominiq at lps dot ens.fr
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-03-23 15:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Thank you for the fast response and effort. I have installed gcc from svn
> but the results are still the same. Perhaps I mis-installed something?
> Attached you will find the logs and the installation workflow.
> Is step #14 perhaps wrong?
Did you recompile the module defining random()?
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.7/4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (10 preceding siblings ...)
2014-03-23 15:07 ` dominiq at lps dot ens.fr
@ 2014-03-23 23:18 ` dominiq at lps dot ens.fr
2014-03-24 20:35 ` sarantis.pantazis at gmail dot com
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-03-23 23:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Yes, I did; I used "make clean" first (also "rm *.o *.f90 *.s" in the main
> folder to clean up the files generated by -save-temps).
Did you update the compiler name in your makefile? I have just been caught by
that when comparing the results in the bug_OPT1mode_withWRITE and
bug_OPT1mode_noWRITE directories. With the right compiler for both, I get
2000 1058 1005 1017
Can you do the following
cp MOD/generalfunctions.mod generalFunctions.mod.gz
gunzip generalFunctions.mod.gz
grep PURE generalFunctions.mod
you should only see
UNKNOWN-PROC DECL UNKNOWN 0 0 INTRINSIC FUNCTION PURE) () (CHARACTER 1 0
UNKNOWN-PROC DECL UNKNOWN 0 0 INTRINSIC FUNCTION PURE) () (CHARACTER 1 0
i.e., no IMPLICIT_PURE.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.7/4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (11 preceding siblings ...)
2014-03-23 23:18 ` dominiq at lps dot ens.fr
@ 2014-03-24 20:35 ` sarantis.pantazis at gmail dot com
2014-03-24 20:43 ` mikael at gcc dot gnu.org
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: sarantis.pantazis at gmail dot com @ 2014-03-24 20:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #13 from Sarantis Pantazis <sarantis.pantazis at gmail dot com> ---
> Did you update the compiler name in your makefile?
I have left the line COMPILER=gfortran at the top as it is and I have defined
an alias in my ~/.bashrc for gfortran pointing to the newly installed location
(alias gfortran='$HOME/latestGcc/gcc-build/gcc/gfortran').
> cp MOD/generalfunctions.mod generalFunctions.mod.gz
> gunzip generalFunctions.mod.gz
I get "gzip: generalFunctions.mod.gz: not in gzip format". But anyway, the mod
file is readable so I can skip to the third line.
> grep PURE generalFunctions.mod
UNKNOWN-INTENT MODULE-PROC DECL UNKNOWN 0 0 SUBROUTINE IMPLICIT_PURE) (
MODULE-PROC DECL UNKNOWN 0 0 FUNCTION IMPLICIT_PURE) (REAL 8 0 0 0 REAL
So, I still get IMPLICIT_PURE. And when I run it I still get the infinite loop
as well, so I guess I missed something during the installation?
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.7/4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (12 preceding siblings ...)
2014-03-24 20:35 ` sarantis.pantazis at gmail dot com
@ 2014-03-24 20:43 ` mikael at gcc dot gnu.org
2014-03-24 21:47 ` sarantis.pantazis at gmail dot com
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: mikael at gcc dot gnu.org @ 2014-03-24 20:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #14 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Sarantis Pantazis from comment #13)
> > Did you update the compiler name in your makefile?
>
> I have left the line COMPILER=gfortran at the top as it is and I have
> defined an alias in my ~/.bashrc for gfortran pointing to the newly
> installed location (alias gfortran='$HOME/latestGcc/gcc-build/gcc/gfortran').
>
>
> > cp MOD/generalfunctions.mod generalFunctions.mod.gz
> > gunzip generalFunctions.mod.gz
>
> I get "gzip: generalFunctions.mod.gz: not in gzip format". But anyway, the
> mod file is readable so I can skip to the third line.
>
This means you are using an old compiler.
Did you install the compiler (i.e. run 'make install')?
Do you get gzip'ed modules if you use .../gcc/f951 instead of .../gcc/gfortran?
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.7/4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (13 preceding siblings ...)
2014-03-24 20:43 ` mikael at gcc dot gnu.org
@ 2014-03-24 21:47 ` sarantis.pantazis at gmail dot com
2014-03-24 21:49 ` anlauf at gmx dot de
2014-03-24 22:12 ` kargl at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: sarantis.pantazis at gmail dot com @ 2014-03-24 21:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #15 from Sarantis Pantazis <sarantis.pantazis at gmail dot com> ---
> Did you install the compiler (i.e. run 'make install')?
Yes, I did. I read http://gcc.gnu.org/install/index.html and made a summary of
the steps I followed (attached here). I also kept a log of "make" and "make
install" (also attached here).
I also tried changing COMPILER=gfortran to
COMPILER=/home/sarantis/latestGcc/gcc-build/gcc/gfortran and got the following
error:
gfortran: error trying to exec 'f951': execvp: No such file or directory
> Do you get gzip'ed modules if you use .../gcc/f951 instead of .../gcc/gfortran?
Compiling with COMPILER=/home/sarantis/latestGcc/gcc-build/gcc/f951 leads to
zipped files and no IMPLICIT_PURE. But f951 does not accept -c so no executable
was produced.
It seems it is something trivial but my knowledge outside of fortran is still
rather limited...
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.7/4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (14 preceding siblings ...)
2014-03-24 21:47 ` sarantis.pantazis at gmail dot com
@ 2014-03-24 21:49 ` anlauf at gmx dot de
2014-03-24 22:12 ` kargl at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: anlauf at gmx dot de @ 2014-03-24 21:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #16 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Sarantis Pantazis from comment #13)
> > Did you update the compiler name in your makefile?
>
> I have left the line COMPILER=gfortran at the top as it is and I have
> defined an alias in my ~/.bashrc for gfortran pointing to the newly
> installed location (alias gfortran='$HOME/latestGcc/gcc-build/gcc/gfortran').
I think that aliases in a Makefile are a bad idea. You need to make sure
that the aliases are exported from the invoking shell.
On my system I get:
% alias gfc
alias gfc='gfortran'
% cat Makefile
SHELL = /bin/bash
aliastest:
echo "Running make: alias:"; alias
% make aliastest
echo "Running make: alias:"; alias
Running make: alias:
So no aliases are set! Try "man bash" and search for "expand_aliases".
I use a symbolic link gfc-trunk (you might prefer gfortran-latest)
to the installed binary and use this in the makefile.
^ permalink raw reply [flat|nested] 18+ messages in thread* [Bug fortran/60543] [4.7/4.8/4.9 Regression] Function with side effect removed by the optimizer.
2014-03-16 11:47 [Bug fortran/60543] New: Random number problems with REAL64 precision at different optimization levels sarantis.pantazis at gmail dot com
` (15 preceding siblings ...)
2014-03-24 21:49 ` anlauf at gmx dot de
@ 2014-03-24 22:12 ` kargl at gcc dot gnu.org
16 siblings, 0 replies; 18+ messages in thread
From: kargl at gcc dot gnu.org @ 2014-03-24 22:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60543
--- Comment #17 from kargl at gcc dot gnu.org ---
(In reply to Sarantis Pantazis from comment #15)
>
> It seems it is something trivial but my knowledge outside of fortran is
> still rather limited...
>
Bugzilla is not a Fortran User support forum. But, to aid in your
suffering. Remove ALL installed versions of gfortran. Make sure
that there are no leftover gfortrans or f951 in your path and remove
all old *.mod files. Now, re-install the latest and greatest version
of gfortran from trunk.
^ permalink raw reply [flat|nested] 18+ messages in thread