public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/61180] New: surprising -Wsurprising warning
@ 2014-05-13 16:36 Joost.VandeVondele at mat dot ethz.ch
  2014-05-13 17:39 ` [Bug fortran/61180] " dominiq at lps dot ens.fr
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2014-05-13 16:36 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 61180
           Summary: surprising -Wsurprising warning
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Joost.VandeVondele at mat dot ethz.ch

To my surprise, -Wsurprising produces surprising warnings. The issue is the
following:

MODULE M1
 TYPE foo_type
   INTEGER, POINTER, DIMENSION(:) :: data
 END TYPE
CONTAINS
  FUNCTION get_data(foo) RESULT(res)
    TYPE(foo_type) :: foo
    INTEGER, POINTER, DIMENSION(:) :: res
    res=>foo%data
  END FUNCTION
END MODULE M1

  USE M1
  TYPE(foo_type) :: foo
  INTEGER, DIMENSION(:), ALLOCATABLE :: data1
  INTEGER, DIMENSION(:), POINTER :: data2
  INTEGER, DIMENSION(:), POINTER :: data3
  ALLOCATE(data1(10))
  ALLOCATE(data2(10))
  ALLOCATE(foo%data(10))
  ! no warning needed...pointer assignment not possible
  data1=get_data(foo)
  ! no warning needed...pointer assignment not intended 
  data2(:)=get_data(foo) 
  ! warning possible, but not documented on 
  ! gfortran/Error-and-Warning-Options.html#Error-and-Warning-Options
  data3=get_data(foo)
END PROGRAM

warnings for the first two cases are presumably not needed, the 3rd case is not
documented

bug.f90:22.8:

  data1=get_data(foo)
        1
Warning: POINTER-valued function appears on right-hand side of assignment at
(1)

The option has been added quite a while ago:

http://gcc.gnu.org/ml/fortran/2004-08/msg00220.html

maybe it should just be a bit restricted


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/61180] surprising -Wsurprising warning
  2014-05-13 16:36 [Bug fortran/61180] New: surprising -Wsurprising warning Joost.VandeVondele at mat dot ethz.ch
@ 2014-05-13 17:39 ` dominiq at lps dot ens.fr
  2014-05-13 17:46 ` Joost.VandeVondele at mat dot ethz.ch
  2014-05-15 14:09 ` dominiq at lps dot ens.fr
  2 siblings, 0 replies; 4+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-05-13 17:39 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-05-13
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
(1) The warnings appear also with -Wall (without -Wsurprising).
(2) The code crashes at run time, i.e., the code is likely wrong (as suggested
by the warnings).
(3) With the following variant

  USE M1
  TYPE(foo_type) :: foo
  INTEGER, DIMENSION(:), ALLOCATABLE :: data1
  INTEGER, DIMENSION(:), POINTER :: data2
  INTEGER, DIMENSION(:), POINTER :: data3
  ALLOCATE(data1(10))
  ALLOCATE(data2(10))
  ALLOCATE(foo%data(10))
  foo%data=1
  ! no warning needed...pointer assignment not possible
!  data1=get_data(foo)
  ! no warning needed...pointer assignment not intended 
  data2(3:)=>get_data(foo)
  ! warning possible, but not documented on 
  ! gfortran/Error-and-Warning-Options.html#Error-and-Warning-Options
  data3=>get_data(foo)
  print *, data2(12)
  print *, data3(10)
END PROGRAM

the code compiles and prints 1 twice at run time.

Why do you think the warnings are not needed?


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/61180] surprising -Wsurprising warning
  2014-05-13 16:36 [Bug fortran/61180] New: surprising -Wsurprising warning Joost.VandeVondele at mat dot ethz.ch
  2014-05-13 17:39 ` [Bug fortran/61180] " dominiq at lps dot ens.fr
@ 2014-05-13 17:46 ` Joost.VandeVondele at mat dot ethz.ch
  2014-05-15 14:09 ` dominiq at lps dot ens.fr
  2 siblings, 0 replies; 4+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2014-05-13 17:46 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #2 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Dominique d'Humieres from comment #1)
> Why do you think the warnings are not needed?

I'm only suggesting that the warning is not needed for the first two
assignments. They are just correct, and clearly pointer assignment is not
intended (or possible in the first case).

The crash is for the 3rd case, where the warning is indeed correct (but it is
not documented that this check is done).


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/61180] surprising -Wsurprising warning
  2014-05-13 16:36 [Bug fortran/61180] New: surprising -Wsurprising warning Joost.VandeVondele at mat dot ethz.ch
  2014-05-13 17:39 ` [Bug fortran/61180] " dominiq at lps dot ens.fr
  2014-05-13 17:46 ` Joost.VandeVondele at mat dot ethz.ch
@ 2014-05-15 14:09 ` dominiq at lps dot ens.fr
  2 siblings, 0 replies; 4+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-05-15 14:09 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
                 CC|                            |jvdelisle at gcc dot gnu.org,
                   |                            |sgk at troutmask dot apl.washingto
                   |                            |n.edu

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
(1) I shall RTFM before rather than after answering: -Wsurprising is indeed
included in -Wall!(which I find surprising, yet another bad naming).

(2) with the following patch

--- ../_clean/gcc/fortran/expr.c    2014-05-07 12:46:43.000000000 +0200
+++ gcc/fortran/expr.c    2014-05-15 12:00:21.000000000 +0200
@@ -3157,7 +3157,8 @@ gfc_check_assign (gfc_expr *lvalue, gfc_

   /* This is possibly a typo: x = f() instead of x => f().  */
   if (gfc_option.warn_surprising
-      && rvalue->expr_type == EXPR_FUNCTION && gfc_expr_attr (rvalue).pointer)
+      && rvalue->expr_type == EXPR_FUNCTION && gfc_expr_attr (rvalue).pointer
+      && gfc_expr_attr (lvalue).pointer)
     gfc_warning ("POINTER-valued function appears on right-hand side of "
          "assignment at %L", &rvalue->where);

--- ../_clean/gcc/fortran/invoke.texi    2014-05-08 19:46:13.000000000 +0200
+++ gcc/fortran/invoke.texi    2014-05-15 14:38:09.000000000 +0200
@@ -852,21 +852,26 @@ This currently produces a warning under 

I get (without regression)

[Book15] f90/bug% gfc pr61180.f90 -Wall
pr61180.f90:27.8:

  data3=get_data(foo)
        1
Warning: POINTER-valued function appears on right-hand side of assignment at
(1)

I shamelessly admit a very limited understanding of 'gfc_expr_attr
(lvalue).(pointer|target))': replacing 'gfc_expr_attr (lvalue).pointer' with
'gfc_expr_attr (lvalue).target' gives the last two warning, while
'!gfc_expr_attr (lvalue).pointer' gives the first one only.

(3) Is the following change in the manual OK?

 @itemize @bullet
 @item
-An INTEGER SELECT construct has a CASE that can never be matched as its
-lower value is greater than its upper value.
+An @code{INTEGER SELECT} construct has a @code{CASE} that can never be
+matched as its lower value is greater than its upper value.

 @item
-A LOGICAL SELECT construct has three CASE statements.
+A @code{LOGICAL SELECT} construct has three @code{CASE} statements.

 @item
-A TRANSFER specifies a source that is shorter than the destination.
+A @code{TRANSFER} specifies a source that is shorter than the destination.

 @item
-The type of a function result is declared more than once with the same type. 
If
-@option{-pedantic} or standard-conforming mode is enabled, this is an error.
+The type of a function result is declared more than once with the same
+type.  If @option{-pedantic} or standard-conforming mode is enabled,
+this is an error.

 @item
 A @code{CHARACTER} variable is declared with negative length.
+
+@item
+@code{POINTER}-valued function appears on right-hand side of assignment
+to a pointer.
 @end itemize

 @item -Wtabs

Note I have wrapped some additional keyword in @code. Is it OK?


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-05-15 14:09 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-13 16:36 [Bug fortran/61180] New: surprising -Wsurprising warning Joost.VandeVondele at mat dot ethz.ch
2014-05-13 17:39 ` [Bug fortran/61180] " dominiq at lps dot ens.fr
2014-05-13 17:46 ` Joost.VandeVondele at mat dot ethz.ch
2014-05-15 14:09 ` dominiq at lps dot ens.fr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).