[Bug fortran/55591] New: strict-aliasing & Fortran

[Bug fortran/55591] New: strict-aliasing & Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

             Bug #: 55591
           Summary: strict-aliasing & Fortran
    Classification: Unclassified
           Product: gcc
           Version: 4.7.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Joost.VandeVondele@mat.ethz.ch


As suggested in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55585#c5

Richard:
GFortran could enable strict-aliasing unconditionally if it likes (even
at -O0).

I think this makes sense given the Fortran semantics and the way people usually
code in Fortran. Given this is the default at -O2 already, I think
-fstrict-aliasing is well tested.

[Bug fortran/55591] strict-aliasing & Fortran

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2012-12-04 13:35:54 UTC ---
Btw, the same holds true for all languages.  That it's only enabled at -O2+
is historical (but I don't remember the result of likely past discussions to
change this default).

[Bug fortran/55591] strict-aliasing & Fortran

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot
                   |                            |gnu.org

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2012-12-04 15:46:27 UTC ---
I think just the compile time saving during code development justifies this
change and it can always be over-ridden by the user if ever needed.

[Bug fortran/55591] strict-aliasing & Fortran

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-04 17:05:45 UTC ---
Untested (but successfully compiled) patch:

--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -170,4 +170,6 @@ gfc_init_options (unsigned int decoded_options_count,
   set_default_std_flags ();

+  flag_strict_aliasing = -1;
+
   /* Initialize cpp-related options.  */
   gfc_cpp_init_options (decoded_options_count, decoded_options);
@@ -275,4 +277,8 @@ gfc_post_options (const char **pfilename)
     gfc_option.flag_whole_file = 1;

+  /* By default use strict-aliasing semantics.  */
+  if (flag_strict_aliasing == -1)
+    flag_strict_aliasing = 1;
+
   /* Fortran allows associative math - but we cannot reassociate if
      we want traps or signed zeros. Cf. also flag_protect_parens.  */

[Bug fortran/55591] strict-aliasing & Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joost.VandeVondele at mat
                   |                            |dot ethz.ch

--- Comment #4 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-19 07:47:41 UTC ---
(In reply to comment #3)
> Untested (but successfully compiled) patch:

I would say, deserves to be posted, since it fixes PR55585 as a side effect. I
have been running with -fstrict-aliasing now at -O1, and this looks good.

[Bug fortran/55591] strict-aliasing & Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #5 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2013-03-29 06:13:38 UTC ---
(In reply to comment #3)
> Untested (but successfully compiled) patch:
> 
> --- a/gcc/fortran/options.c
> +++ b/gcc/fortran/options.c
> @@ -170,4 +170,6 @@ gfc_init_options (unsigned int decoded_options_count,
>    set_default_std_flags ();
> 
> +  flag_strict_aliasing = -1;
> +
>    /* Initialize cpp-related options.  */
>    gfc_cpp_init_options (decoded_options_count, decoded_options);
> @@ -275,4 +277,8 @@ gfc_post_options (const char **pfilename)
>      gfc_option.flag_whole_file = 1;
> 
> +  /* By default use strict-aliasing semantics.  */
> +  if (flag_strict_aliasing == -1)
> +    flag_strict_aliasing = 1;
> +
>    /* Fortran allows associative math - but we cannot reassociate if
>       we want traps or signed zeros. Cf. also flag_protect_parens.  */

what about applying this to stage 1 4.9 ?

[Bug fortran/55591] strict-aliasing & Fortran

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-12-21
     Ever confirmed|0                           |1

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> what about applying this to stage 1 4.9 ?

Too late for 5.0? Note that the patch in comment 3 may have to be updated to
take into account the recent option reform (I did not test it).

[Bug fortran/55591] strict-aliasing & Fortran

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591

--- Comment #7 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Dominique d'Humieres from comment #6)
> > what about applying this to stage 1 4.9 ?
> 
> Too late for 5.0? Note that the patch in comment 3 may have to be updated to
> take into account the recent option reform (I did not test it).

Yes, I looked a couple of months ago in the patch comment #3, and it didn't
work, figuring out why this didn't work lead to the patches on errno etc.
Something in the option mechanism was causing this to be overwritten, I didn't
figure out how to fix this cleanly. I would guess that, maybe, the new option
handling mechanism makes this easier.