Bug 2288 - Variable declared in for-loop-header is in wrong scope
Summary: Variable declared in for-loop-header is in wrong scope
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 2.95
: P3 normal
Target Milestone: ---
Assignee: Gabriel Dos Reis
URL: http://gcc.gnu.org/ml/gcc-patches/201...
Keywords: accepts-invalid, monitored
: 7387 21837 41427 49083 (view as bug list)
Depends on:
Blocks: 12944 5605 18770
  Show dependency treegraph
Reported: 2001-03-14 06:56 UTC by Gabriel Dos Reis
Modified: 2011-06-05 02:08 UTC (History)
15 users (show)

See Also:
Known to work:
Known to fail: 3.4.4, 4.0.0, 4.1.0
Last reconfirmed: 2006-12-24 15:50:50


Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel Dos Reis 2001-03-14 06:56:00 UTC
g++ fails to diagnose the program construct below.
The redeclaration in the controled-statement is ill-formed
as per 3.3.2/4.

g++ also fails to diagnose conflicts with declarations in conditions; see the XFAILs in g++.old-deja/g++.jason/cond.C.
Some of these failures are new since 2.95.

gcc-2.95 and gcc-3_0 are affected


#include <iostream>

int main()
   for (int i = 0; i < 10; ++i)
        int i = 5;
         std::cout << i << std::endl;
  return 0;
Comment 1 Gabriel Dos Reis 2001-08-11 11:41:36 UTC
Responsible-Changed-From-To: unassigned->gdr
Responsible-Changed-Why: Analyzed.  Confirmed as a bug.
Comment 2 Gabriel Dos Reis 2001-08-11 11:42:24 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: oops.
Comment 3 Wolfgang Bangerth 2002-11-14 18:13:47 UTC
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: gcc-gnats@gcc.gnu.org, <gcc-bugs@gcc.gnu.org>
Subject: Re: c++/2288: Variable declared in for-loop-header is in wrong scope
Date: Thu, 14 Nov 2002 18:13:47 -0600 (CST)

 Still happens with recent CVS. A smaller, self-contained testcase is this:
 void f(int);
 int main() {
    for (int i=0;;++i) {
      int i=5;
    return 0;
 I don't get an error upon the second declaration of "i", although it 
 should be in the same scope as that declared in the loop-header. If I use 
 -Wshadow, it says
 x.cc: In function `int main()':
 x.cc:4: warning: declaration of `i' shadows a previous local
 x.cc:3: warning: shadowed declaration is here
 So one can assume that gcc generates two nested scopes for this construct, 
 in the outer one those variables are placed which are declared in the loop 
 header, in the inner one those go that are declared in the loop body. I 
 think this is not the intent of the standard...
 The C frontend in gnu99 mode suffers from the same problem, by the way.
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth

Comment 4 Joseph S. Myers 2002-11-15 00:14:23 UTC
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: <gcc-gnats@gcc.gnu.org>,  <gcc-bugs@gcc.gnu.org>
Subject: Re: c++/2288: Variable declared in for-loop-header is in wrong scope
Date: Fri, 15 Nov 2002 00:14:23 +0000 (GMT)

 On Thu, 14 Nov 2002, Wolfgang Bangerth wrote:
 > The C frontend in gnu99 mode suffers from the same problem, by the way.
 Not a bug for C99.  See 6.8.5#5.
 Joseph S. Myers
Comment 5 Andrew Pinski 2003-05-24 21:29:46 UTC
still happens on the mainline (20030524).
Comment 6 Andrew Pinski 2005-05-31 13:16:17 UTC
*** Bug 21837 has been marked as a duplicate of this bug. ***
Comment 7 Andrew Stubbs 2007-05-17 16:37:28 UTC
Another example that might be of interest if anybody eventually tries to fix this:

foo ()
  for (int i = 0; int i = 0; i++) ;
Comment 8 Andrew Pinski 2009-09-21 14:22:52 UTC
*** Bug 41427 has been marked as a duplicate of this bug. ***
Comment 9 Janis Johnson 2010-02-23 19:07:59 UTC
Is there a reason this hasn't been fixed?  If not, I'll try.
Comment 10 Wolfgang Bangerth 2010-02-23 20:40:19 UTC
(In reply to comment #9)
> Is there a reason this hasn't been fixed?

Lack of public demand? There's only one duplicate of this bug that has
been reported in the last 9 years...

>  If not, I'll try.

I think that would still be cool!


Comment 11 Janis Johnson 2010-02-23 21:54:21 UTC
In response to comment #10, there are several duplicates to similar bug PR18770 and demand for a fix from within my company.
Comment 12 Peter Bergner 2010-10-27 14:34:30 UTC
Janis, I noticed your patch:


to fix this PR and PR18770 was approved by Jason here:


Now that we're in 4.6 stage1, can we commit this patch to mainline?
Comment 13 Janis Johnson 2010-10-27 16:04:10 UTC
It's fine with me to commit the patch, but can someone else do it? I wrote the patch when I worked at IBM. I have a personal copyright assignment now, but haven't been involved for several months and it would be a lot of work to get set up to commit it myself.
Comment 14 Peter Bergner 2010-10-27 17:26:27 UTC
I can do it, I just wanted to make sure I could.  I'll apply the patch to current mainline and give it another bootstrap regtesting before committing.  I assume I should use "Janis Johnson  <janis187@us.ibm.com>" as your email address in the ChangeLog since that was what you used to submit the patch?
Comment 15 Janis Johnson 2010-10-27 17:38:36 UTC
Peter, I don't know what address you should use for me; ask on #gcc if you should use the IBM one, otherwise it's janis.marie.johnson@gmail.com.
Comment 16 Andrew Pinski 2011-05-20 17:09:41 UTC
*** Bug 49083 has been marked as a duplicate of this bug. ***
Comment 17 David Fang 2011-05-20 17:56:25 UTC
I usually catch these with -Wshadow -Werror.
Comment 18 Nathan Froyd 2011-05-20 18:34:08 UTC
Peter, can you apply Janis's patch now that we're in 4.7 stage 1?
Comment 19 Peter Bergner 2011-05-23 15:38:11 UTC
I applied Janis' patch (modulo a small fixup due to upstream changes) to current mainline and did a bootstrap and regtest.  We bootstrap fine, unfortunately the patch no longer fixes the new added test case (g++.dg/parse/pr18770.C) and the modified test case (g++.old-deja/g++.jason/cond.C) also fails.  I'm not really a C++ expert, so I'm not sure what to do here.
Comment 20 Nathan Froyd 2011-06-05 02:08:38 UTC
This bug was fixed on trunk in r174307; the automated update was not done because something was wonky with my email.  Closing.