Bug 86181 - [DR 1839] static object mangling conflicts
Summary: [DR 1839] static object mangling conflicts
Status: SUSPENDED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 8.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: accepts-invalid
Depends on:
Blocks:
 
Reported: 2018-06-17 01:11 UTC by zhonghao
Modified: 2018-08-08 07:37 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2018-08-07 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description zhonghao 2018-06-17 01:11:54 UTC
I found that gcc+ produces errors when it compiles the following code:
extern "C" void abort();
static int i;
int *p = &i;
int main()
{ 
 int i;
 { 
 extern int i;
 i = 1;
 *p = 2;
 if (i == 2)
 abort ();
 }
 return 0;
}

When compiling the above code, clang++ does not produce any errors. The code comes from https://bugs.llvm.org/show_bug.cgi?id=5966

Indeed, the situation is more complicated. The above bug report of clang says that the code comes from a bug report of gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775

The gcc report has a long discussion on this issue. Perhaps, the bug is not fully fixed?
Comment 1 Richard Biener 2018-06-18 09:11:01 UTC
I think the clang bug is incomplete and misses the 2nd TU which defines i.  So
GCC works (and the testcase is in the testsuite).
Comment 2 zhonghao 2018-08-07 07:01:21 UTC
I reported the code to llvm. A developer of llvm said:

Clang follows the agreed direction for CWG issue 1839, which says that redeclaration lookup for 'extern int i;' finds the 'static int i;' declared at namespace scope and thus the internal linkage is inherited.


Does gcc follow a different lookup?
Comment 3 Jonathan Wakely 2018-08-07 09:35:56 UTC
I've asked you repeatedly to provide links to the clang bugs you're quoting from.
Comment 4 Jonathan Wakely 2018-08-07 09:52:47 UTC
CWG 1839 hasn't been resolved yet and doesn't even have a proposed resolution in the issues list. It's not a bug for GCC to follow the current standard.

However DR 426 says it's ill-formed. As a result of DR 426 the meaning of the program changed from undefined to ill-formed between C++14 and C++17, so GCC was previously correct, but the standard changed.

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#426


If 1839 is going to make more changes in this area then this PR should be suspended until any change happens.