Bug 86181 (cwg1839) - [DR 1839] static object mangling conflicts
Summary: [DR 1839] static object mangling conflicts
Status: NEW
Alias: cwg1839
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 8.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: accepts-invalid
Depends on: P1787R6
Blocks: c++-core-issues
  Show dependency treegraph
Reported: 2018-06-17 01:11 UTC by zhonghao
Modified: 2024-04-04 22:20 UTC (History)
2 users (show)

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


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.


If 1839 is going to make more changes in this area then this PR should be suspended until any change happens.
Comment 5 Andrew Pinski 2024-04-04 22:20:35 UTC

[Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to DR at the February, 2021 meeting.]