[Bug fortran/45318] Do more parenthesis simplification with -fno-protect-parens

2013-07-20 Thread tkoenig at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45318

Thomas Koenig tkoenig at gcc dot gnu.org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org ---
Any specific examples?


[Bug fortran/45318] Do more parenthesis simplification with -fno-protect-parens

2013-07-20 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45318

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #5)
 Any specific examples?

I looked now through the code (for INTRINSIC_PARENTHESES) and glanced at some
of the related PRs. I failed to find a case where one could do something in the
FE - and the ME already handles it. (An example would be (a+5)-7 - however,
the ME essentially ignores all code involving nonconstants; the only exception
is dependency tracing and there such a case is also unlikely.)

In summary, while there could be in principle a case, which should be handled,
in practice, there does not seem to be one.

Thus: Close as WORKSFORME.


[Bug fortran/45318] Do more parenthesis simplification with -fno-protect-parens

2013-06-19 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45318

--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 Given Richard's comments and no testcase, I'm in doubt if this PR 
 is meaningful?!

Any new opinion about this PR? or should we close it as WONTFIX.

NOTE: I'ld like very much that the -no-protect-parens be removed from -Ofast!-(


[Bug fortran/45318] Do more parenthesis simplification with -fno-protect-parens

2010-12-28 Thread dfranke at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45318

Daniel Franke dfranke at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.12.28 23:37:54
 CC||dfranke at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-28 
23:37:54 UTC ---
Given Richard's comments and no testcase, I'm in doubt if this PR is
meaningful?!


[Bug fortran/45318] Do more parenthesis simplification with -fno-protect-parens

2010-08-18 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2010-08-18 14:23 ---
(In reply to comment #0)
 In some cases, one might need to check for the unsave_math_optimization flag
 before changing, e.g., 2+(a-2) to a - or rather (a).

The whole point of PAREN_EXPR in the middle-end is to avoid transforming
2 + (a - 2) even _with_ -funsafe-math-optimizations / -ffast-math!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45318



[Bug fortran/45318] Do more parenthesis simplification with -fno-protect-parens

2010-08-18 Thread burnus at gcc dot gnu dot org


--- Comment #2 from burnus at gcc dot gnu dot org  2010-08-18 17:44 ---
(In reply to comment #1)
 (In reply to comment #0)
  In some cases, one might need to check for the unsave_math_optimization flag
  before changing, e.g., 2+(a-2) to a - or rather (a).
 
 The whole point of PAREN_EXPR in the middle-end is to avoid transforming
 2 + (a - 2) even _with_ -funsafe-math-optimizations / -ffast-math!

Well, I am talking about FE optimizations with -fno-protect-parens (note the
no-). The PAREN_EXPR protection *is* and *should* one done with
-fprotect-parens (which is the default setting).

In terms of the middle end, -fno-protect-parens and -fprotect-parens are both
properly handled.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45318