[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #3 from ubizjak at gmail dot com 2007-10-17 09:11 --- Confirmed with plain -O2 -ffast-math on i686-pc-linux-gnu. -- ubizjak at gmail dot com changed: What|Removed |Added Summary|Wrong code w/ -m32 -ffast- |[4.3 regression] Wrong code |math -march=opteron |w/ -ffast-math http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #4 from ubizjak at gmail dot com 2007-10-17 10:23 --- Bisection points to r129350: http://gcc.gnu.org/viewcvs?view=revrevision=129350 PR tree-optimization/33619 * tree-ssa-ter.c (is_replaceable_p): Return false for all calls. * gcc.dg/pr33619.c: New test. -- ubizjak at gmail dot com changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-17 10:39 --- And really that patch should not change anything really since it just means TER does not cross function call boundaries now (and not just accross over non pure/const function calls). Can you at least give the final_clean for the file which is missed compiled for both before and after the patch? Since I doubt TER is doing something wrong. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-10-17 11:02 --- Also what happens if you use -ffloat-store ? Even though it might be 3 orders of magnitude, this could be still the same issue as PR 323 (errors multiply in some cases). Also note -ffloat-store disables TER for floating point types. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #8 from ubizjak at gmail dot com 2007-10-17 11:40 --- (In reply to comment #6) Also what happens if you use -ffloat-store ? -O2 -ffast-math -ffloat-store works OK... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #7 from ubizjak at gmail dot com 2007-10-17 11:38 --- (In reply to comment #5) There are (many!) changes of type: - D.6241 = __builtin_sqrt (receive_coil_1.self_ind * transmit_coil.self_ind); - coil_coil_mutuals[0] = coil_coil_mutuals[0] / D.6241; + coil_coil_mutuals[0] = coil_coil_mutuals[0] / __builtin_sqrt (receive_coil_1 where (-) represents failed run and (+) successful run, produced with Jakub's patch removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-10-17 11:46 --- I think what is happening is that coil_coil_mutuals[0] / D.6241 is being expanded as coil_coil_mutuals[0] * (1/D.6241) which is not bad, just inconstaint. I think we need to look into this more but I doubt there is anything you can fix here. This is just the way stuff works with -ffast-math and x87. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #10 from ubizjak at gmail dot com 2007-10-17 12:28 --- (In reply to comment #9) I don't want to claim excess precision problems here. I was trying to debug self_ind_cir_coil procedure, as it looks that the problem is in calculation of self_r output. The input to this procedure is always the same: 2.99989E-002 3.6E-003 16.666 1.25663706143591729E-006 but for -O2 -ffast-math -ffloat-store, self_l is returned as self_l 3.66008420600437631E-002 and for -O2 -ffast-math, self_l is returned as (wrong): self_l 8.51113565610957021E-008 I don't see why the code in between would produce such wildly different result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #11 from ubizjak at gmail dot com 2007-10-17 12:39 --- The problem is somewhere around line 212 in induct.f90. Adding some debug code at the end of the function: ... !evaluate self-inductance ! self_l = (mu * turns**2 * l**2 * 2.0_longreal * r)/3.0_longreal * (((tan(alpha)**2-1.0_longreal)*elliptice+elliptick)/sin(alpha) - tan(alpha)**2) ! print *,input, mu, turns, l, r, alpha, elliptice, elliptick print *,result, self_l end subroutine self_ind_cir_coil we obtain: -O2 -ffast-math input 1.25663706143591729E-006 16.666 3.6E-003 2.99989E-002 1.5208379310729538 1.00484582819708894.3853871539549072 result 8.51113565610956888E-008 -O2 -ffast-math -ffloat-store: input 1.25663706143591729E-006 16.666 3.6E-003 2.99989E-002 1.5208379310729538 1.00484582819708894.3853871539548939 result 2.13170362012935939E-002 So, for the same input parameters, the equation above returns the result that differs in 3 orders of magnitude. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
[Bug middle-end/33794] [4.3 regression] Wrong code w/ -ffast-math
--- Comment #16 from ubizjak at gmail dot com 2007-10-17 17:11 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|target |middle-end Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33794
