* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
@ 2013-06-25 15:52 ` pinskia at gcc dot gnu.org
2013-06-25 16:17 ` jakub at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2013-06-25 15:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
2013-06-25 15:52 ` [Bug c++/57709] " pinskia at gcc dot gnu.org
@ 2013-06-25 16:17 ` jakub at gcc dot gnu.org
2013-06-25 16:40 ` jan.kratochvil at redhat dot com
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-06-25 16:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
2013-06-25 15:52 ` [Bug c++/57709] " pinskia at gcc dot gnu.org
2013-06-25 16:17 ` jakub at gcc dot gnu.org
@ 2013-06-25 16:40 ` jan.kratochvil at redhat dot com
2013-06-25 16:46 ` manu at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jan.kratochvil at redhat dot com @ 2013-06-25 16:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
` (2 preceding siblings ...)
2013-06-25 16:40 ` jan.kratochvil at redhat dot com
@ 2013-06-25 16:46 ` manu at gcc dot gnu.org
2013-06-25 18:00 ` manu at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: manu at gcc dot gnu.org @ 2013-06-25 16:46 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
` (3 preceding siblings ...)
2013-06-25 16:46 ` manu at gcc dot gnu.org
@ 2013-06-25 18:00 ` manu at gcc dot gnu.org
2013-11-19 6:31 ` manu at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: manu at gcc dot gnu.org @ 2013-06-25 18:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
` (4 preceding siblings ...)
2013-06-25 18:00 ` manu at gcc dot gnu.org
@ 2013-11-19 6:31 ` manu at gcc dot gnu.org
2013-11-19 13:40 ` jan.kratochvil at redhat dot com
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: manu at gcc dot gnu.org @ 2013-11-19 6:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
` (5 preceding siblings ...)
2013-11-19 6:31 ` manu at gcc dot gnu.org
@ 2013-11-19 13:40 ` jan.kratochvil at redhat dot com
2013-11-19 16:49 ` manu at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jan.kratochvil at redhat dot com @ 2013-11-19 13:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
` (6 preceding siblings ...)
2013-11-19 13:40 ` jan.kratochvil at redhat dot com
@ 2013-11-19 16:49 ` manu at gcc dot gnu.org
2013-11-19 17:15 ` jan.kratochvil at redhat dot com
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: manu at gcc dot gnu.org @ 2013-11-19 16:49 UTC (permalink / raw)
To: gcc-bugs
[-- 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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
` (7 preceding siblings ...)
2013-11-19 16:49 ` manu at gcc dot gnu.org
@ 2013-11-19 17:15 ` jan.kratochvil at redhat dot com
2013-12-14 7:57 ` jan.kratochvil at redhat dot com
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jan.kratochvil at redhat dot com @ 2013-11-19 17:15 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
` (8 preceding siblings ...)
2013-11-19 17:15 ` jan.kratochvil at redhat dot com
@ 2013-12-14 7:57 ` jan.kratochvil at redhat dot com
2013-12-17 22:35 ` joseph at codesourcery dot com
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jan.kratochvil at redhat dot com @ 2013-12-14 7:57 UTC (permalink / raw)
To: gcc-bugs
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;
}
}
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
` (9 preceding siblings ...)
2013-12-14 7:57 ` jan.kratochvil at redhat dot com
@ 2013-12-17 22:35 ` joseph at codesourcery dot com
2014-08-22 19:13 ` manu at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: joseph at codesourcery dot com @ 2013-12-17 22:35 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
` (10 preceding siblings ...)
2013-12-17 22:35 ` joseph at codesourcery dot com
@ 2014-08-22 19:13 ` manu at gcc dot gnu.org
2015-06-09 9:33 ` gael.guennebaud at gmail dot com
2015-06-09 9:47 ` manu at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: manu at gcc dot gnu.org @ 2014-08-22 19:13 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
` (11 preceding siblings ...)
2014-08-22 19:13 ` manu at gcc dot gnu.org
@ 2015-06-09 9:33 ` gael.guennebaud at gmail dot com
2015-06-09 9:47 ` manu at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: gael.guennebaud at gmail dot com @ 2015-06-09 9:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug c++/57709] -Wshadow is too strict / has false positives
2013-06-25 13:52 [Bug c++/57709] New: -Wshadow is too strict / has false positives jan.kratochvil at redhat dot com
` (12 preceding siblings ...)
2015-06-09 9:33 ` gael.guennebaud at gmail dot com
@ 2015-06-09 9:47 ` manu at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: manu at gcc dot gnu.org @ 2015-06-09 9:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread