Bug 71564 - label inside a lambda conflicts (?) with another one outside it
Summary: label inside a lambda conflicts (?) with another one outside it
Status: RESOLVED DUPLICATE of bug 61358
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: c++-lambda, rejects-valid
Depends on:
Blocks: lambdas
  Show dependency treegraph
 
Reported: 2016-06-17 05:08 UTC by LIU Hao
Modified: 2022-03-11 00:32 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-10-04 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description LIU Hao 2016-06-17 05:08:55 UTC
This code fails to compile with any current version of g++ from 4.7 to 7.0:

```
int main(){
_infinite_retry:
	[=]{
	_infinite_retry:
		goto _infinite_retry; // go to the second _infinite_retry.
	}();
	goto _infinite_retry; // go to the first _infinite_retry.
}
```

D:\Desktop>g++ test.cpp -Wall
test.cpp: In function 'int main()':
test.cpp:2:2: warning: label '_infinite_retry' defined but not used [-Wunused-label]
  _infinite_retry:
  ^~~~~~~~~~~~~~~
test.cpp:7:8: error: label '_infinite_retry' used but not defined
   goto _infinite_retry; // go to the outer _infinite_retry.
        ^~~~~~~~~~~~~~~


Quoting from the standard:
```
ISO/IEC WG21 N4582 

5.1.2 Lambda expressions [expr.prim.lambda]
8 The lambda-expression’s compound-statement yields the function-body (8.4) of the function call operator, ...

3.3.5 Function scope [basic.funscope]
1 Labels (6.1) have function scope and may be used anywhere in the function in which they are declared. Only
labels have function scope.
```

The compound statement of a lambda expression is a function body thus it creates a function scope. The second label should reside in that scope but somehow nullifies the first one, causing the second goto statement to fail to find the first label.
Comment 1 LIU Hao 2016-06-17 05:18:30 UTC
clang++ 3.0 seems to have issues dealing with this, but it seems to have been fixed since clang++ 3.1.
Comment 2 Paolo Carlini 2017-10-04 08:51:48 UTC
Very likely duplicate of PR61358, testcase slightly different, better keep both.
Comment 3 Paolo Carlini 2018-03-03 01:00:54 UTC
Indeed, now that PR61358 is fixed in trunk, this one is fixed too. I will add a testcase.

*** This bug has been marked as a duplicate of bug 61358 ***