[Bug c++/57709] New: -Wshadow is too strict / has false positives

[Bug c++/57709] New: -Wshadow is too strict / has false positives

[jan.kratochvil at redhat dot com]

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

            Bug ID: 57709
           Summary: -Wshadow is too strict / has false positives
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jan.kratochvil at redhat dot com
            Target: x86_64-unknown-linux-gnu

class C {
  int both_var;
  void var_and_method() {}
  void m() { int both_var, var_and_method; }
};

FAIL: gcc (GCC) 4.8.2 20130625 (prerelease)
FAIL: gcc (GCC) 4.9.0 20130625 (experimental)
g++ -c -o shadow.o shadow.C -Wshadow -Wno-unused
shadow.C:4:18: warning: declaration of ‘both_var’ shadows a member of 'this'
[-Wshadow]
shadow.C:4:28: warning: declaration of ‘var_and_method’ shadows a member of
'this' [-Wshadow]

clang-3.3-0.4.rc2.fc18.x86_64
clang -c -o shadow.o shadow.C -Wshadow -Wno-unused
shadow.C:4:18: warning: declaration shadows a field of 'C' [-Wshadow]
  void m() { int both_var, var_and_method; }
                 ^
shadow.C:2:7: note: previous declaration is here
  int both_var;
      ^
1 warning generated.

------------------------------------------------------------------------------

clang does no warn on "var_and_method" as variable vs. method are safe, if one
tries to use them inappropriately one gets an error.

It is difficult to enable -Wshadow for existing project as it has many needless
warnings, with clang it is easier and still safe.
>From gcc-bugs-return-425092-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 25 14:01:12 2013
Return-Path: <gcc-bugs-return-425092-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25074 invoked by alias); 25 Jun 2013 14:01:12 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25045 invoked by uid 48); 25 Jun 2013 14:01:10 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57707] gcc misinterprets hex escapes in constant strings
Date: Tue, 25 Jun 2013 14:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.7.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-57707-4-hz3sgmWPCE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57707-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57707-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01471.txt.bz2
Content-length: 465

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW707

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> ---
6.4.4.4

Bugzilla is not the right place to learn C.

[Bug c++/57709] -Wshadow is too strict / has false positives

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> clang does no warn on "var_and_method" as variable vs. method are safe, if one
> tries to use them inappropriately one gets an error.

Not always.  Think of function pointers or pointer to member functions.  clang
is not loose in my mind rather than GCC is too strict.

[Bug c++/57709] -Wshadow is too strict / has false positives

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yeah, I agree, this looks like a clang bug (or misdesigned feature) to me.

[Bug c++/57709] -Wshadow is too strict / has false positives

[jan.kratochvil at redhat dot com]

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

--- Comment #3 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
It may not be exactly correct but from a practical standpoint clang has caught
my bug while not annoying me with tons of needless changes like gcc did, FYI.

[Bug c++/57709] -Wshadow is too strict / has false positives

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> > clang does no warn on "var_and_method" as variable vs. method are safe, if one
> > tries to use them inappropriately one gets an error.
> 
> Not always.  Think of function pointers or pointer to member functions. 
> clang is not loose in my mind rather than GCC is too strict.

In GCC 4.8 I implemented:

"The option -Wshadow no longer warns if a declaration shadows a function
declaration, unless the former declares a function or pointer to function,
because this is a common and valid case in real-world code."

I think this is a useful heuristic also for member functions, no? I don't have
time to work on this at the moment, but it would be useful to know whether the
maintainers agree, so someone (Jan?) may start working on a patch.
>From gcc-bugs-return-425097-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 25 16:51:54 2013
Return-Path: <gcc-bugs-return-425097-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7628 invoked by alias); 25 Jun 2013 16:51:54 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7566 invoked by uid 48); 25 Jun 2013 16:51:50 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57709] -Wshadow is too strict / has false positives
Date: Tue, 25 Jun 2013 16:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_severity
Message-ID: <bug-57709-4-6dTf4lD4mI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57709-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57709-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01476.txt.bz2
Content-length: 1079

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #4)
> "The option -Wshadow no longer warns if a declaration shadows a function
> declaration, unless the former declares a function or pointer to function,
> because this is a common and valid case in real-world code."
> 
> I think this is a useful heuristic also for member functions, no? I don't
> have time to work on this at the moment, but it would be useful to know
> whether the maintainers agree, so someone (Jan?) may start working on a
> patch.

That would be fine.  But it seems less important for member functions, since
there's much less chance of a local variable name conflicting with some random
function declared by an #include file.
>From gcc-bugs-return-425098-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 25 16:59:33 2013
Return-Path: <gcc-bugs-return-425098-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14311 invoked by alias); 25 Jun 2013 16:59:33 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14251 invoked by uid 48); 25 Jun 2013 16:59:24 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/57710] New: [OOP] _vptr not set for allocatable CLASS components
Date: Tue, 25 Jun 2013 16:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter
Message-ID: <bug-57710-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01477.txt.bz2
Content-length: 1324

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW710

            Bug ID: 57710
           Summary: [OOP] _vptr not set for allocatable CLASS components
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code, wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org

The following code (minus the IF condition) shows that _vptr is not set for the
allocatable component:
        y.x._data = 0B;
there should be - but isn't - additionally: y.x._vptr = &__vtab_m_T;


Additionally, the test case as is (with IF condition), currently crashes with:

internal compiler error: in gfc_conv_component_ref, at
fortran/trans-expr.c:1654
   if (.not. same_type_as(y%x, z)) call abort ()
 ^
0x632ce2 gfc_conv_component_ref
        ../../gcc/fortran/trans-expr.c:1654
0x63fc89 gfc_conv_variable
        ../../gcc/fortran/trans-expr.c:1921


module m
  type t
  end type t
  type t2
    integer :: ii
    class(t), allocatable :: x
  end type t2
contains
  subroutine fini(x)
     type(t) :: x
  end subroutine fini
end module m

use m
block
  type(t) :: z
  type(t2) :: y
  y%ii = 123
  if (.not. same_type_as(y%x, z)) call abort ()
end block
end

[Bug c++/57709] -Wshadow is too strict / has false positives

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #5)
> 
> That would be fine.  But it seems less important for member functions, since
> there's much less chance of a local variable name conflicting with some
> random function declared by an #include file.

Well, Jan here is complaining precisely that a local variable (not function
pointer, not other function) conflicts with a member function. I would expect
that to almost never happen but I guess some programmers are not very good at
naming things ;-)
>From gcc-bugs-return-425119-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 25 18:02:40 2013
Return-Path: <gcc-bugs-return-425119-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1230 invoked by alias); 25 Jun 2013 18:02:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1094 invoked by uid 48); 25 Jun 2013 18:02:37 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/45170] [F2003] allocatable character lengths
Date: Tue, 25 Jun 2013 18:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status
Message-ID: <bug-45170-4-6vIyZ0o1Is@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-45170-4@http.gcc.gnu.org/bugzilla/>
References: <bug-45170-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01498.txt.bz2
Content-length: 440

http://gcc.gnu.org/bugzilla/show_bug.cgi?idE170

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #43 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Per comment #39, it seems that this PR could be closed as FIXED.

[Bug c++/57709] -Wshadow is too strict / has false positives

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic, patch
             Target|x86_64-unknown-linux-gnu    |
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-19
     Ever confirmed|0                           |1

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
The following patch compiles and gives the following output:


/home/manuel/t.cc:6:18: warning: declaration of ‘both_var’ shadows a member of
‘C’ [-Wshadow]
   void m() { int both_var, var_and_method; }
                  ^
/home/manuel/t.cc:3:7: note: shadowed declaration is here
   int both_var;
       ^

No other testing besides that. Please feel free to take it from here.


Index: name-lookup.c
===================================================================
--- name-lookup.c       (revision 205004)
+++ name-lookup.c       (working copy)
@@ -1216,13 +1216,25 @@ pushdecl_maybe_friend_1 (tree x, bool is
              else
                member = NULL_TREE;

              if (member && !TREE_STATIC (member))
                {
-                 /* Location of previous decl is not useful in this case.  */
-                 warning (OPT_Wshadow, "declaration of %qD shadows a member of
'this'",
-                          x);
+                 if (BASELINK_P (member))
+                   member = BASELINK_FUNCTIONS (member);
+
+                 /* Do not warn if a variable shadows a function, unless
+                    the variable is a function or a pointer-to-function.  */
+                 if (!(TREE_CODE (member) == METHOD_TYPE
+                      && TREE_CODE (x) != FUNCTION_DECL
+                      && !FUNCTION_POINTER_TYPE_P (TREE_TYPE (x)))) {
+                   if (warning_at (input_location,
+                                   OPT_Wshadow, "declaration of %qD shadows a
member of %qT",
+                                x, current_nonlambda_class_type ())
+                       && DECL_P(member))
+                     inform (DECL_SOURCE_LOCATION (member),
+                             "shadowed declaration is here");
+                 }
                }
              else if (oldglobal != NULL_TREE
                       && (VAR_P (oldglobal)
                            /* If the old decl is a type decl, only warn if the
                               old decl is an explicit typedef or if both the
>From gcc-bugs-return-434966-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 19 06:54:24 2013
Return-Path: <gcc-bugs-return-434966-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18239 invoked by alias); 19 Nov 2013 06:54:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18177 invoked by uid 48); 19 Nov 2013 06:54:18 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/16351] NULL dereference warnings
Date: Tue, 19 Nov 2013 06:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.0.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: law at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-16351-4-bgYDv2RHXg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-16351-4@http.gcc.gnu.org/bugzilla/>
References: <bug-16351-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg01743.txt.bz2
Content-length: 917

http://gcc.gnu.org/bugzilla/show_bug.cgi?id\x16351

--- Comment #13 from Jeffrey A. Law <law at redhat dot com> ---
Just adding a quick warning_at at the points where we optimize erroneous uses
of NULL I get:

j.c: In function 'test1':
j.c:10:9: warning: Erroneous NULL pointer use (explicit)
 [enabled by default]
  s->bar = 1;  /* { dg-warning "null" } */
         ^
j.c: In function 'test2':
j.c:15:20: warning: Erroneous NULL pointer use (explicit)
 [enabled by default]
  if (s == NULL && s->bar > 2)  /* { dg-warning "null" } */
                    ^
j.c: In function 'test3':
j.c:23:20: warning: Erroneous NULL pointer use (explicit)
 [enabled by default]
  if (s != NULL || s->bar > 2)  /* { dg-warning "null" } */
                    ^
j.c:26:9: warning: Erroneous NULL pointer use (explicit)
 [enabled by default]
  s->bar = 3;  /* { dg-warning "null" } */
         ^

Which is exactly what I would expect.

[Bug c++/57709] -Wshadow is too strict / has false positives

[jan.kratochvil at redhat dot com]

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

--- Comment #8 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
Created attachment 31248
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31248&action=edit
Comment 7 patch as a file

I still get both warnings, applied the patch to:
g++ (GCC) 4.9.0 20131119 (experimental)


shadow2.C: In member function ‘void C::m()’:
shadow2.C:4:18: warning: declaration of ‘both_var’ shadows a member of ‘C’
[-Wshadow]
   void m() { int both_var, var_and_method; }
                  ^
shadow2.C:2:7: note: shadowed declaration is here
   int both_var;
       ^
shadow2.C:4:28: warning: declaration of ‘var_and_method’ shadows a member of
‘C’ [-Wshadow]
   void m() { int both_var, var_and_method; }
                            ^
shadow2.C:3:8: note: shadowed declaration is here
   void var_and_method() {}
        ^
shadow2.C:4:18: warning: unused variable ‘both_var’ [-Wunused-variable]
   void m() { int both_var, var_and_method; }
                  ^
shadow2.C:4:28: warning: unused variable ‘var_and_method’ [-Wunused-variable]
   void m() { int both_var, var_and_method; }
                            ^
>From gcc-bugs-return-435052-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 19 13:40:12 2013
Return-Path: <gcc-bugs-return-435052-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12845 invoked by alias); 19 Nov 2013 13:40:11 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12726 invoked by uid 48); 19 Nov 2013 13:40:08 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59006] [4.9 Regression] internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:5963
Date: Tue, 19 Nov 2013 13:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-59006-4-fYDj79mtAb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59006-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59006-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg01829.txt.bz2
Content-length: 468

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY006

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will have a look.

[Bug c++/57709] -Wshadow is too strict / has false positives

[manu at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4542 bytes --]

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

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Something has changed in the C++ FE in the meanwhile. Could you try with this
one?

Index: name-lookup.c
===================================================================
--- name-lookup.c       (revision 205004)
+++ name-lookup.c       (working copy)
@@ -1216,13 +1216,25 @@ pushdecl_maybe_friend_1 (tree x, bool is
              else
                member = NULL_TREE;

              if (member && !TREE_STATIC (member))
                {
-                 /* Location of previous decl is not useful in this case.  */
-                 warning (OPT_Wshadow, "declaration of %qD shadows a member of
'this'",
-                          x);
+                 if (BASELINK_P (member))
+                   member = BASELINK_FUNCTIONS (member);
+
+                 /* Do not warn if a variable shadows a function, unless
+                    the variable is a function or a pointer-to-function.  */
+                 if (!(TREE_CODE (member) == FUNCTION_DECL
+                      && TREE_CODE (x) != FUNCTION_DECL
+                      && !FUNCTION_POINTER_TYPE_P (TREE_TYPE (x)))) {
+                   if (warning_at (input_location,
+                                   OPT_Wshadow, "declaration of %qD shadows a
member of %qT",
+                                x, current_nonlambda_class_type ())
+                       && DECL_P(member))
+                     inform (DECL_SOURCE_LOCATION (member),
+                             "shadowed declaration is here");
+                 }
                }
              else if (oldglobal != NULL_TREE
                       && (VAR_P (oldglobal)
                            /* If the old decl is a type decl, only warn if the
                               old decl is an explicit typedef or if both the
>From gcc-bugs-return-435104-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 19 17:00:25 2013
Return-Path: <gcc-bugs-return-435104-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21021 invoked by alias); 19 Nov 2013 17:00:25 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20866 invoked by uid 48); 19 Nov 2013 17:00:22 -0000
From: "charles.baylis at linaro dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/59142] [4.8 / 4.9 Regression] internal compiler error while compiling OpenCV 2.4.7
Date: Tue, 19 Nov 2013 17:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: charles.baylis at linaro dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc attachments.created
Message-ID: <bug-59142-4-Bt8lyOICbA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59142-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59142-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg01881.txt.bz2
Content-length: 754

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY142

Charles Baylis <charles.baylis at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |charles.baylis at linaro dot org

--- Comment #5 from Charles Baylis <charles.baylis at linaro dot org> ---
Created attachment 31251
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id1251&actioníit
Reduced test case


I have attached a reduced test case (produced using c-reduce).

$ arm-unknown-linux-gnueabi-gcc -W -fPIC -O2 -c -mcpu=cortex-a9 -mthumb
reference/reduced.cpp

I did a git bisect, and that points to the problem being introduced in r172837

[Bug c++/57709] -Wshadow is too strict / has false positives

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #31248|0                           |1
        is obsolete|                            |

--- Comment #10 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
Created attachment 31252
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31252&action=edit
Comment 9 patch as a file

Yes, it works for me now, thanks:

shadow2.C: In member function ‘void C::m()’:
shadow2.C:4:18: warning: declaration of ‘both_var’ shadows a member of ‘C’
[-Wshadow]
   void m() { int both_var, var_and_method; }
                  ^
shadow2.C:2:7: note: shadowed declaration is here
   int both_var;
       ^
shadow2.C:4:18: warning: unused variable ‘both_var’ [-Wunused-variable]
   void m() { int both_var, var_and_method; }
                  ^
shadow2.C:4:28: warning: unused variable ‘var_and_method’ [-Wunused-variable]
   void m() { int both_var, var_and_method; }
                            ^

BTW copy-pasting patches here is very inconvenient.
>From gcc-bugs-return-435106-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Nov 19 17:16:52 2013
Return-Path: <gcc-bugs-return-435106-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15951 invoked by alias); 19 Nov 2013 17:16:51 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15916 invoked by uid 48); 19 Nov 2013 17:16:48 -0000
From: "olaf--mail.gcc at olafdietsche dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/59192] error:=?UTF-8?Q? use of deleted function ‘A?=::A(const A&)=?UTF-8?Q?’?Date: Tue, 19 Nov 2013 17:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olaf--mail.gcc at olafdietsche dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59192-4-vpsAfh7Cfg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59192-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59192-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg01883.txt.bz2
Content-length: 249

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY192

--- Comment #2 from Olaf Dietsche <olaf--mail.gcc at olafdietsche dot de> ---
I don't know how hard this is. When I replace deque with vector or list, it
compiles with all versions from 4.6 to 4.8

[Bug c++/57709] -Wshadow is too strict / has false positives

[jan.kratochvil at redhat dot com]

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

--- Comment #11 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
Similar inappropriate warning is generated for typedef-vs-variable as reported
now by Adam Jackson.  Again a mistaken use cannot harm as it causes other
errors.  And clang also does not warn on it.

int main(void) {
  typedef int x; 
  {
    int x = 0;
    return x;
  }
}

[Bug c++/57709] -Wshadow is too strict / has false positives

[joseph at codesourcery dot com]

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

--- Comment #12 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sat, 14 Dec 2013, jan.kratochvil at redhat dot com wrote:

> Similar inappropriate warning is generated for typedef-vs-variable as reported
> now by Adam Jackson.  Again a mistaken use cannot harm as it causes other
> errors.  And clang also does not warn on it.
> 
> int main(void) {
>   typedef int x; 
>   {
>     int x = 0;
>     return x;

If that's "return (x)-1;" then the interpretation as cast or arithmetic 
depends on whether x is a type or a variable.

[Bug c++/57709] -Wshadow is too strict / has false positives

[manu at gcc dot gnu.org]

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

--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Author: manu
Date: Fri Aug 22 19:12:46 2014
New Revision: 214357

URL: https://gcc.gnu.org/viewcvs?rev=214357&root=gcc&view=rev
Log:
gcc/cp/ChangeLog:

2014-08-22  Manuel López-Ibáñez  <manu@gcc.gnu.org>

    PR c++/57709
    * name-lookup.c (pushdecl_maybe_friend_1): Do not warn if a
    declaration shadows a function declaration, unless the former
    declares a function, pointer to function or pointer to member
    function, because this is a common and valid case in real-world
    code.
    * cp-tree.h (TYPE_PTRFN_P,TYPE_REFFN_P,TYPE_PTRMEMFUNC_P):
    Improve description.

gcc/testsuite/ChangeLog:

2014-08-22  Manuel López-Ibáñez  <manu@gcc.gnu.org>

    PR c++/57709
    * g++.dg/Wshadow.C: New test.


Added:
    trunk/gcc/testsuite/g++.dg/Wshadow.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/name-lookup.c
    trunk/gcc/testsuite/ChangeLog
>From gcc-bugs-return-459066-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 22 19:15:42 2014
Return-Path: <gcc-bugs-return-459066-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19471 invoked by alias); 22 Aug 2014 19:15:42 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19419 invoked by uid 48); 22 Aug 2014 19:15:39 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57709] -Wshadow is too strict / has false positives
Date: Fri, 22 Aug 2014 19:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: diagnostic, patch
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-57709-4-3YldHgy8H3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57709-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57709-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg01563.txt.bz2
Content-length: 476

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Fixed in gcc 5.0
>From gcc-bugs-return-459067-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 22 19:24:40 2014
Return-Path: <gcc-bugs-return-459067-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24681 invoked by alias); 22 Aug 2014 19:24:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24639 invoked by uid 48); 22 Aug 2014 19:24:37 -0000
From: "tkoenig at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/31593] Invariant DO loop variables and subroutines
Date: Fri, 22 Aug 2014 19:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.3.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: tkoenig at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: tobi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-31593-4-EDUAtHS9lB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-31593-4@http.gcc.gnu.org/bugzilla/>
References: <bug-31593-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg01564.txt.bz2
Content-length: 3287

https://gcc.gnu.org/bugzilla/show_bug.cgi?id1593

--- Comment #46 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #45)
> Anything left to fix in this PR?

Unfortunately yes...

We still do not take advantage of the fact that the call
to a subroutine cannot change the value of the do loop:

ig25@linux-fd1f:~/Krempel/Do> cat call_unspec.f90
module foo
contains
  subroutine output(i1,i2,i3,i4,i5)
    integer :: i1,i2,i3,i4,i5
    print '(5(I0,:" "))',i1,i2,i3,i4,i5
  end subroutine output
end module foo
program main
  use foo
  implicit none
  integer :: value
  integer :: p1, p2, p3, p4
  integer :: i

  do value = 750,800
     do i=1, 10
        do p1 = 1, value-2
           do p2 = p1 + 1, value - p1
              do p3 = p2 + 1, (value - (p1 + p2))/2
                 p4 = value - p1 - p2 - p3
                 if (p1 * p2 * p3 * p4 == value * 1000000) &
                      & call output (value, p1, p2, p3, p4)
              end do
           end do
        end do
     end do
  end do
end program main
ig25@linux-fd1f:~/Krempel/Do> gfortran -O2 call_unspec.f90 && time ./a.out >
/dev/null

real    0m4.586s
user    0m4.578s
sys     0m0.000s
ig25@linux-fd1f:~/Krempel/Do> cat call_intent.f90
module foo
contains
  subroutine output(i1,i2,i3,i4,i5)
    integer, intent(in) :: i1,i2,i3,i4,i5
    print '(5(I0,:" "))',i1,i2,i3,i4,i5
  end subroutine output
end module foo
program main
  use foo
  implicit none
  integer :: value
  integer :: p1, p2, p3, p4
  integer :: i

  do value = 750,800
     do i=1, 10
        do p1 = 1, value-2
           do p2 = p1 + 1, value - p1
              do p3 = p2 + 1, (value - (p1 + p2))/2
                 p4 = value - p1 - p2 - p3
                 if (p1 * p2 * p3 * p4 == value * 1000000) &
                 & call output(value , p1 , p2 , p3 , p4)
              end do
           end do
        end do
     end do
  end do
end program main
ig25@linux-fd1f:~/Krempel/Do> gfortran -O2 call_intent.f90 && time ./a.out >
/dev/null

real    0m3.090s
user    0m3.089s
sys     0m0.000s
ig25@linux-fd1f:~/Krempel/Do> cat call_parens.f90
module foo
contains
  subroutine output(i1,i2,i3,i4,i5)
    print '(5(I0,:" "))',i1,i2,i3,i4,i5
  end subroutine output
end module foo
program main
  use foo
  implicit none
  integer :: value
  integer :: p1, p2, p3, p4
  integer :: i

  do value = 750,800
     do i=1, 10
        do p1 = 1, value-2
           do p2 = p1 + 1, value - p1
              do p3 = p2 + 1, (value - (p1 + p2))/2
                 p4 = value - p1 - p2 - p3
                 if (p1 * p2 * p3 * p4 == value * 1000000) &
                 & call output((value),(p1),(p2),(p3),(p4))
              end do
           end do
        end do
     end do
  end do
end program main
ig25@linux-fd1f:~/Krempel/Do> gfortran -O2 call_parens.f90 && time ./a.out >
/dev/null

real    0m3.134s
user    0m3.131s
sys     0m0.000s

[Bug c++/57709] -Wshadow is too strict / has false positives

[gael.guennebaud at gmail dot com]

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

Gael Guennebaud <gael.guennebaud at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gael.guennebaud at gmail dot com

--- Comment #15 from Gael Guennebaud <gael.guennebaud at gmail dot com> ---
-Wshadow still trigger false positive when a base member functions is imported
with the "using" keyword, as in the following example (tested with gcc 5.1):

template<typename T> struct BaseClass {
  BaseClass(int size) : m_size(size) {}
  int size() { return m_size; }
  int m_size;
};

template<typename T> struct Foo : BaseClass<T> {
  typedef BaseClass<T> Base;
  Foo(int size) : Base(size) {}
  using Base::size;
};

$ g++-mp-5 gcc_shadow.cpp -c  -Wshadow 
gcc_shadow.cpp: In constructor 'Foo<T>::Foo(int)':
gcc_shadow.cpp:9:17: warning: declaration of 'size' shadows a member of
'Foo<T>' [-Wshadow]
   Foo(int size) : Base(size) {}
                 ^
gcc_shadow.cpp:10:15: note: shadowed declaration is here
   using Base::size;


Note that clang does not warn in this case, so it should be possible to figure
out that in this case, the imported "size" symbol is a function and not a
variable.

[Bug c++/57709] -Wshadow is too strict / has false positives

[manu at gcc dot gnu.org]

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

--- Comment #16 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Gael Guennebaud from comment #15)
> -Wshadow still trigger false positive when a base member functions is
> imported with the "using" keyword, as in the following example (tested with
> gcc 5.1):

Please open a new PR. This one is fixed.

> Note that clang does not warn in this case, so it should be possible to
> figure out that in this case, the imported "size" symbol is a function and
> not a variable.

Sure, probably TREE_CODE (member) != FUNCTION_DECL but there must be a way to
check that it does represent a function_decl (or member-function). Run gcc
under gdb in your testcase and break at the call to warning_at and use "p
debug_tree(member)" to understand what member is in your testcase.
>From gcc-bugs-return-488466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 09 09:54:19 2015
Return-Path: <gcc-bugs-return-488466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 109752 invoked by alias); 9 Jun 2015 09:54:18 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 109694 invoked by uid 48); 9 Jun 2015 09:54:15 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/45780] Warning for arithmetic operations involving C99 _Bool variable
Date: Tue, 09 Jun 2015 09:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-45780-4-reKioD5YdX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-45780-4@http.gcc.gnu.org/bugzilla/>
References: <bug-45780-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg00798.txt.bz2
Content-length: 327

https://gcc.gnu.org/bugzilla/show_bug.cgi?idE780

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I think -Wbool-arith makes sense as a separate option.  While -Wc90-c99-compat
warns about any use of bool (in a declaration, cast, ...), -Wbool-arith would
only warn about suspicious uses of boolean vars.