[Bug c++/94764] New: block extern incorrectly resolved to external linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94764
Bug ID: 94764
Summary: block extern incorrectly resolved to external linkage
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tabloid.adroit at gmail dot com
Target Milestone: ---
Related to DR426
source:
https://stackoverflow.com/questions/61276220/why-same-named-extern-local-variables-in-different-blocks-get-different-linkages
// foo.cpp
int var = 10;// external linkage
// main.cpp
#include
static int var = 100;// internal linkage
int main() {
extern int var; // internal linkage
std::cout << var << std::endl;
{
extern int var; // g++: external linkage , clang++: internal
linkage
std::cout << var << std::endl;
{
extern int var; // g++: external linkage , clang++: internal
linkage
std::cout << var << std::endl;
}
}
}
g++ : "100 10 10"
clang++ : "100 100 100" (msvc++)
[basic.link] #6 is pretty clear about this. I'm not sure it is a UB.
[Bug c++/94764] block extern incorrectly resolved to external linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94764 --- Comment #2 from tabloid.adroit at gmail dot com --- Do you think it is still UB at this moment? If not, I guess PR14769 could be worked on?
[Bug c++/106493] New: trailing requires clauses is not used for partial ordering when the ellipsis parameter is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106493
Bug ID: 106493
Summary: trailing requires clauses is not used for partial
ordering when the ellipsis parameter is present
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tabloid.adroit at gmail dot com
Target Milestone: ---
test case:
```
template
concept AtLeast2 = sizeof(T) >= 2;
template
constexpr int doo(int a, ...) requires AtLeast2 && true {
return 1;
}
template
constexpr int doo(int b) requires AtLeast2 {
return 2;
}
static_assert(doo(2) == 1);
```
The assertion fails due to ambiguity. However, I'd expect the trailing requires
clauses kicks in by https://eel.is/c++draft/temp.fct#temp.func.order-6.4
Removing the ellipsis parameter fixes the assertion failure.
[Bug c++/106493] trailing requires clauses is not used for partial ordering when the ellipsis parameter is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106493 --- Comment #2 from Yuanfang Chen --- I'm actually fixing it on the Clang side. It would be great to make GCC/Clang match each other.
[Bug c++/99963] [11 Regression] [concepts] template vs concept auto reports ambiguous overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99963 tabloid.adroit at gmail dot com changed: What|Removed |Added CC||tabloid.adroit at gmail dot com --- Comment #4 from tabloid.adroit at gmail dot com --- (In reply to Patrick Palka from comment #1) > Started with r11-1571. Reduced testcase that replaces the abbreviated > function templates with their corresponding non-abbreviated forms: > > template concept C1 = true; > template concept C2 = C1 && true; > > template int f(T, U); > template int f(U, T); > > int x = f(0, 0); // error: ambiguous call > > > If I understand the wording of P2113 correctly: > > If deduction against the other template succeeds for both transformed > templates, constraints can be considered as follows: > - ... if the corresponding template-parameters of the > template-parameter-lists are not equivalent ([temp.over.link]) or if the > function parameters that positionally correspond between the two templates > are not of the same type, neither template is more specialized than the other > > then I think we're correct to reject the call as ambiguous because although > the second overload is more constrained than the first, their function > parameter lists aren't equivalent. IMHO, `template int f(U, T);` should win over `template int f(T, U);`. Based on interpreting the intent mentioned in https://github.com/cplusplus/nbballot/issues/119 and the second example in https://eel.is/c++draft/temp.fct#temp.func.order-example-6, the `corresponding` (of the `corresponding template-parameters of ...`) relationship is based on the mapping used during partial-ordering deduction. So the deduction between `f(T, ..)` against `f(U, ..)` builds the mapping, the deduction between `f(.., U)` against `f(.., T)` builds the mapping. The correspondence is [T, U] against [U, T]. So `C1 T` is less constrained than `C2 U`, thus the second `f` wins.
[Bug c++/99963] [11 Regression] [concepts] template vs concept auto reports ambiguous overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99963 --- Comment #5 from Yuanfang Chen --- (In reply to Yuanfang Chen from comment #4) > (In reply to Patrick Palka from comment #1) > > Started with r11-1571. Reduced testcase that replaces the abbreviated > > function templates with their corresponding non-abbreviated forms: > > > > template concept C1 = true; > > template concept C2 = C1 && true; > > > > template int f(T, U); > > template int f(U, T); > > > > int x = f(0, 0); // error: ambiguous call > > > > > > If I understand the wording of P2113 correctly: > > > > If deduction against the other template succeeds for both transformed > > templates, constraints can be considered as follows: > > - ... if the corresponding template-parameters of the > > template-parameter-lists are not equivalent ([temp.over.link]) or if the > > function parameters that positionally correspond between the two templates > > are not of the same type, neither template is more specialized than the > > other > > > > then I think we're correct to reject the call as ambiguous because although > > the second overload is more constrained than the first, their function > > parameter lists aren't equivalent. > > IMHO, `template int f(U, T);` should win over `template C1 U> int f(T, U);`. > > Based on interpreting the intent mentioned in > https://github.com/cplusplus/nbballot/issues/119 and the second example in > https://eel.is/c++draft/temp.fct#temp.func.order-example-6, the > `corresponding` (of the `corresponding template-parameters of ...`) > relationship is based on the mapping used during partial-ordering deduction. > So the deduction between `f(T, ..)` against `f(U, ..)` builds the > mapping, the deduction between `f(.., U)` against `f(.., T)` builds the T> mapping. The correspondence is [T, U] against [U, T]. So `C1 T` is less > constrained than `C2 U`, thus the second `f` wins. Sorry. I spoke too soon. Template parameters reordering is not allowed for the test case. The call is indeed ambiguous.
