Bug 12056 (C++DR397) - [DR 397] string literal in extern inline function not unique
Summary: [DR 397] string literal in extern inline function not unique
Status: NEW
Alias: C++DR397
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.3.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
: 22459 39187 (view as bug list)
Depends on:
Blocks: c++-core-issues
  Show dependency treegraph
 
Reported: 2003-08-25 16:02 UTC by jbeulich
Modified: 2020-03-30 15:50 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-03-03 21:48:22


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jbeulich 2003-08-25 16:02:30 UTC
The standard says (7.1.2 ยง 4) "A string literal in an extern inline function is
the same object in different translation units". The compiler, not emitting a
(generated) symbol, for string literals, cannot guarantee this, resulting in
address comparisons on the address of such literals obtained through different
instances of the same function to not match.

extern inline const char*test() {
	return "xyz";
}

const char*test1(int i) {
	return test() + i;
}
Comment 1 Andrew Pinski 2003-08-26 18:09:41 UTC
I can confirm this on the mainline (20030825).
I think if it generated a named symbol and put it into the linkonce section, this will work.
Comment 2 Andrew Pinski 2005-07-13 13:35:51 UTC
*** Bug 22459 has been marked as a duplicate of this bug. ***
Comment 3 Andrew Pinski 2005-07-13 13:37:54 UTC
Suspending based on the fact the DR report is still not fully resolved yet, it is still in drafting phase.
Comment 4 Andrew Pinski 2009-02-14 00:11:07 UTC
*** Bug 39187 has been marked as a duplicate of this bug. ***
Comment 5 H.J. Lu 2009-02-14 00:56:08 UTC
FWIW, it isn't a problem with GNU linker when all files are compiled
with the same version of gcc since linker can merge identical strings
with gcc help.
Comment 6 Jason Merrill 2009-03-03 21:48:21 UTC
The DR is resolved (and is irrelevant to this testcase anyway)