The code below, is it ill-formed NDR or is it well formed? Announcing the arrival of Valued...
An adverb for when you're not exaggerating
Is it fair for a professor to grade us on the possession of past papers?
Is CEO the "profession" with the most psychopaths?
Why does it sometimes sound good to play a grace note as a lead in to a note in a melody?
Using audio cues to encourage good posture
How much damage would a cupful of neutron star matter do to the Earth?
How do I change colors in Zim (wiki editor) running on Kubuntu 18.10?
Can anything be seen from the center of the Boötes void? How dark would it be?
Take 2! Is this homebrew Lady of Pain warlock patron balanced?
Why do we bend a book to keep it straight?
Illegal assignment from sObject to Id
How to play a character with a disability or mental disorder without being offensive?
How do living politicians protect their readily obtainable signatures from misuse?
What is the appropriate index architecture when forced to implement IsDeleted (soft deletes)?
How to compare two different files line by line in unix?
Why is Nikon 1.4g better when Nikon 1.8g is sharper?
Hangman Game with C++
AppleTVs create a chatty alternate WiFi network
How would a mousetrap for use in space work?
How to react to hostile behavior from a senior developer?
How do I use the new nonlinear finite element in Mathematica 12 for this equation?
Drawing without replacement: why is the order of draw irrelevant?
Is grep documentation about ignoring case wrong, since it doesn't ignore case in filenames?
Is there a kind of relay that only consumes power when switching?
The code below, is it ill-formed NDR or is it well formed?
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 00:00UTC (8:00pm US/Eastern)
Data science time! April 2019 and salary with experience
The Ask Question Wizard is Live!Where in C++14 Standard does it say that a non-constexpr function cannot be used in a definition of a constexpr function?Inheriting constructorsWhy does an overridden function in the derived class hide other overloads of the base class?x[0] == 1 constant expression in C++11 when x is const int[]?constexpr bug in clang but not in gcc?Rationale for [dcl.constexpr]p5 in the c++ standardWhy can't lambda, when cast to function pointer, be used in constexpr context?Ill-Formed, No Diagnostic Required (NDR): ConstExpr Function Throw in C++14constexpr reference to non-const objectWhy is this constexpr function ill-formed?Constexpr constructor fails to satisfy the requirements, but still constexpr. Why?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
Clang accepts the following code, but gcc rejects it.
void h() { }
constexpr int f() {
return 1;
h();
}
int main() {
constexpr int i = f();
}
Here is the error message:
g++ -std=c++17 -O2 -Wall -pedantic -pthread main.cpp && ./a.out
main.cpp: In function 'constexpr int f()':
main.cpp:5:6: error: call to non-'constexpr' function 'void h()'
h();
~^~
main.cpp: In function 'int main()':
main.cpp:9:24: error: 'constexpr int f()' called in a constant expression
constexpr int i = f();
~^~
main.cpp:9:19: warning: unused variable 'i' [-Wunused-variable]
constexpr int i = f();
This could well be the case where both compilers are correct, once we consider [dcl.constexpr]/5, given that f() is not a constant expression, as it doesn't satisfy [expr.const]/(4.2), as it calls a non-constexpr function h. That is, the code is ill-formed, but no diagnostic is required.
One other possibility is that the code is well formed, as [expr.const]/(4.2) doesn't apply in this case because the call to h in f is not evaluated. If this is the case, gcc is wrong and clang is correct.
c++ language-lawyer c++17 constexpr
edited 11 hours ago
Barry
187k21331612
asked 11 hours ago
AlexanderAlexander
915414
add a comment |
Clang accepts the following code, but gcc rejects it.
void h() { }
constexpr int f() {
return 1;
h();
}
int main() {
constexpr int i = f();
}
Here is the error message:
g++ -std=c++17 -O2 -Wall -pedantic -pthread main.cpp && ./a.out
main.cpp: In function 'constexpr int f()':
main.cpp:5:6: error: call to non-'constexpr' function 'void h()'
h();
~^~
main.cpp: In function 'int main()':
main.cpp:9:24: error: 'constexpr int f()' called in a constant expression
constexpr int i = f();
~^~
main.cpp:9:19: warning: unused variable 'i' [-Wunused-variable]
constexpr int i = f();
This could well be the case where both compilers are correct, once we consider [dcl.constexpr]/5, given that f() is not a constant expression, as it doesn't satisfy [expr.const]/(4.2), as it calls a non-constexpr function h. That is, the code is ill-formed, but no diagnostic is required.
One other possibility is that the code is well formed, as [expr.const]/(4.2) doesn't apply in this case because the call to h in f is not evaluated. If this is the case, gcc is wrong and clang is correct.
c++ language-lawyer c++17 constexpr
edited 11 hours ago
Barry
187k21331612
asked 11 hours ago
AlexanderAlexander
915414
4
Clang does not allow callingh()before returning, so the real question here is: Is a compiler allowed to ignore dead ill-formed code?
– idmean
11 hours ago
"as it calls a non-constexpr functionh". But it doesn't actually callh. I'd say that gcc is wrong here.
– geza
11 hours ago
I'm adding the C++14 tag since on C++11 there's no question that it's ill-formed.
– Barry
11 hours ago
This code works in GCC's trunk.. godbolt.org/z/f04MCq and godbolt.org/z/bAyE8a .. So it's already fixed.. Free upvotes. If compiled with GCC 8.3 it will fail but compile with Trunk and it works fine.
– Brandon
11 hours ago
add a comment |
Clang accepts the following code, but gcc rejects it.
void h() { }
constexpr int f() {
return 1;
h();
}
int main() {
constexpr int i = f();
}
Here is the error message:
g++ -std=c++17 -O2 -Wall -pedantic -pthread main.cpp && ./a.out
main.cpp: In function 'constexpr int f()':
main.cpp:5:6: error: call to non-'constexpr' function 'void h()'
h();
~^~
main.cpp: In function 'int main()':
main.cpp:9:24: error: 'constexpr int f()' called in a constant expression
constexpr int i = f();
~^~
main.cpp:9:19: warning: unused variable 'i' [-Wunused-variable]
constexpr int i = f();
This could well be the case where both compilers are correct, once we consider [dcl.constexpr]/5, given that f() is not a constant expression, as it doesn't satisfy [expr.const]/(4.2), as it calls a non-constexpr function h. That is, the code is ill-formed, but no diagnostic is required.
One other possibility is that the code is well formed, as [expr.const]/(4.2) doesn't apply in this case because the call to h in f is not evaluated. If this is the case, gcc is wrong and clang is correct.
c++ language-lawyer c++17 constexpr
edited 11 hours ago
Barry
187k21331612
asked 11 hours ago
AlexanderAlexander
915414
Clang accepts the following code, but gcc rejects it.
void h() { }
constexpr int f() {
return 1;
h();
}
int main() {
constexpr int i = f();
}
Here is the error message:
g++ -std=c++17 -O2 -Wall -pedantic -pthread main.cpp && ./a.out
main.cpp: In function 'constexpr int f()':
main.cpp:5:6: error: call to non-'constexpr' function 'void h()'
h();
~^~
main.cpp: In function 'int main()':
main.cpp:9:24: error: 'constexpr int f()' called in a constant expression
constexpr int i = f();
~^~
main.cpp:9:19: warning: unused variable 'i' [-Wunused-variable]
constexpr int i = f();
This could well be the case where both compilers are correct, once we consider [dcl.constexpr]/5, given that f() is not a constant expression, as it doesn't satisfy [expr.const]/(4.2), as it calls a non-constexpr function h. That is, the code is ill-formed, but no diagnostic is required.
One other possibility is that the code is well formed, as [expr.const]/(4.2) doesn't apply in this case because the call to h in f is not evaluated. If this is the case, gcc is wrong and clang is correct.
c++ language-lawyer c++17 constexpr
c++ language-lawyer c++17 constexpr
edited 11 hours ago
Barry
187k21331612
asked 11 hours ago
AlexanderAlexander
915414
edited 11 hours ago
Barry
187k21331612
asked 11 hours ago
AlexanderAlexander
915414
edited 11 hours ago
Barry
187k21331612
edited 11 hours ago
Barry
187k21331612
edited 11 hours ago
Barry
187k21331612
187k21331612
asked 11 hours ago
AlexanderAlexander
915414
asked 11 hours ago
AlexanderAlexander
915414
asked 11 hours ago
AlexanderAlexander
915414
915414
4
Clang does not allow callingh()before returning, so the real question here is: Is a compiler allowed to ignore dead ill-formed code?
– idmean
11 hours ago
"as it calls a non-constexpr functionh". But it doesn't actually callh. I'd say that gcc is wrong here.
– geza
11 hours ago
I'm adding the C++14 tag since on C++11 there's no question that it's ill-formed.
– Barry
11 hours ago
This code works in GCC's trunk.. godbolt.org/z/f04MCq and godbolt.org/z/bAyE8a .. So it's already fixed.. Free upvotes. If compiled with GCC 8.3 it will fail but compile with Trunk and it works fine.
– Brandon
11 hours ago
add a comment |
4
Clang does not allow callingh()before returning, so the real question here is: Is a compiler allowed to ignore dead ill-formed code?
– idmean
11 hours ago
"as it calls a non-constexpr functionh". But it doesn't actually callh. I'd say that gcc is wrong here.
– geza
11 hours ago
I'm adding the C++14 tag since on C++11 there's no question that it's ill-formed.
– Barry
11 hours ago
This code works in GCC's trunk.. godbolt.org/z/f04MCq and godbolt.org/z/bAyE8a .. So it's already fixed.. Free upvotes. If compiled with GCC 8.3 it will fail but compile with Trunk and it works fine.
– Brandon
11 hours ago
4
4
Clang does not allow calling
h() before returning, so the real question here is: Is a compiler allowed to ignore dead ill-formed code?– idmean
11 hours ago
Clang does not allow calling
h() before returning, so the real question here is: Is a compiler allowed to ignore dead ill-formed code?– idmean
11 hours ago
"as it calls a non-constexpr function
h". But it doesn't actually call h. I'd say that gcc is wrong here.– geza
11 hours ago
"as it calls a non-constexpr function
h". But it doesn't actually call h. I'd say that gcc is wrong here.– geza
11 hours ago
I'm adding the C++14 tag since on C++11 there's no question that it's ill-formed.
– Barry
11 hours ago
I'm adding the C++14 tag since on C++11 there's no question that it's ill-formed.
– Barry
11 hours ago
This code works in GCC's trunk.. godbolt.org/z/f04MCq and godbolt.org/z/bAyE8a .. So it's already fixed.. Free upvotes. If compiled with GCC 8.3 it will fail but compile with Trunk and it works fine.
– Brandon
11 hours ago
This code works in GCC's trunk.. godbolt.org/z/f04MCq and godbolt.org/z/bAyE8a .. So it's already fixed.. Free upvotes. If compiled with GCC 8.3 it will fail but compile with Trunk and it works fine.
– Brandon
11 hours ago
add a comment |
1 Answer
1
active
oldest
votes
Clang is correct. A call to f() is a constant expression since the call to h() is never evaluated, so [dcl.constexpr]/5 doesn't apply. The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions. Indeed, a function like the following is well-formed because a call to it can be a constant expression when x is odd:
constexpr int g(int x) {
if (x%2 == 0) h();
return 0;
}
answered 11 hours ago
BrianBrian
67k799192
You answer seems to be correct, but I don't agree with your reasoning. Consider this:constexpr int f() { h(); return 1; }. In this case the code is ill-formed NDR according to [dcl.constexpr]/5 because the functionfinvokes a non-constexpr functionh, and this is not allowed according to [expr.const]/(4.2). See also this question in SO.
– Alexander
9 hours ago
@Alexander In the case where the call toh()is before the return statement, every call tofwill fail to be a constant expression, and [dcl.constexpr]/5 applies. In the case where the call toh()is after the return statement, every call tofwill be a constant expression, so [dcl.constexpr]/5 does not apply.
– Brian
9 hours ago
Ok, but why did you say "The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions."? This is what is confusing in your answer.
– Alexander
9 hours ago
1
@Alexander I'm not sure what part of that was unclear. I linked a section of the standard that lists the constructs that are forbidden from appearing in aconstexprfunction's body. A call to a non-constexprfunction is not one of the forbidden constructs. However, if the call to the non-constexprfunction becomes inevitable (i.e., occurs along all paths) then [dcl.constexpr]/5 becomes violated.
– Brian
9 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55752281%2fthe-code-below-is-it-ill-formed-ndr-or-is-it-well-formed%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Clang is correct. A call to f() is a constant expression since the call to h() is never evaluated, so [dcl.constexpr]/5 doesn't apply. The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions. Indeed, a function like the following is well-formed because a call to it can be a constant expression when x is odd:
constexpr int g(int x) {
if (x%2 == 0) h();
return 0;
}
answered 11 hours ago
BrianBrian
67k799192
You answer seems to be correct, but I don't agree with your reasoning. Consider this:constexpr int f() { h(); return 1; }. In this case the code is ill-formed NDR according to [dcl.constexpr]/5 because the functionfinvokes a non-constexpr functionh, and this is not allowed according to [expr.const]/(4.2). See also this question in SO.
– Alexander
9 hours ago
@Alexander In the case where the call toh()is before the return statement, every call tofwill fail to be a constant expression, and [dcl.constexpr]/5 applies. In the case where the call toh()is after the return statement, every call tofwill be a constant expression, so [dcl.constexpr]/5 does not apply.
– Brian
9 hours ago
Ok, but why did you say "The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions."? This is what is confusing in your answer.
– Alexander
9 hours ago
1
@Alexander I'm not sure what part of that was unclear. I linked a section of the standard that lists the constructs that are forbidden from appearing in aconstexprfunction's body. A call to a non-constexprfunction is not one of the forbidden constructs. However, if the call to the non-constexprfunction becomes inevitable (i.e., occurs along all paths) then [dcl.constexpr]/5 becomes violated.
– Brian
9 hours ago
add a comment |
Clang is correct. A call to f() is a constant expression since the call to h() is never evaluated, so [dcl.constexpr]/5 doesn't apply. The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions. Indeed, a function like the following is well-formed because a call to it can be a constant expression when x is odd:
constexpr int g(int x) {
if (x%2 == 0) h();
return 0;
}
answered 11 hours ago
BrianBrian
67k799192
You answer seems to be correct, but I don't agree with your reasoning. Consider this:constexpr int f() { h(); return 1; }. In this case the code is ill-formed NDR according to [dcl.constexpr]/5 because the functionfinvokes a non-constexpr functionh, and this is not allowed according to [expr.const]/(4.2). See also this question in SO.
– Alexander
9 hours ago
@Alexander In the case where the call toh()is before the return statement, every call tofwill fail to be a constant expression, and [dcl.constexpr]/5 applies. In the case where the call toh()is after the return statement, every call tofwill be a constant expression, so [dcl.constexpr]/5 does not apply.
– Brian
9 hours ago
Ok, but why did you say "The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions."? This is what is confusing in your answer.
– Alexander
9 hours ago
1
@Alexander I'm not sure what part of that was unclear. I linked a section of the standard that lists the constructs that are forbidden from appearing in aconstexprfunction's body. A call to a non-constexprfunction is not one of the forbidden constructs. However, if the call to the non-constexprfunction becomes inevitable (i.e., occurs along all paths) then [dcl.constexpr]/5 becomes violated.
– Brian
9 hours ago
add a comment |
Clang is correct. A call to f() is a constant expression since the call to h() is never evaluated, so [dcl.constexpr]/5 doesn't apply. The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions. Indeed, a function like the following is well-formed because a call to it can be a constant expression when x is odd:
constexpr int g(int x) {
if (x%2 == 0) h();
return 0;
}
answered 11 hours ago
BrianBrian
67k799192
Clang is correct. A call to f() is a constant expression since the call to h() is never evaluated, so [dcl.constexpr]/5 doesn't apply. The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions. Indeed, a function like the following is well-formed because a call to it can be a constant expression when x is odd:
constexpr int g(int x) {
if (x%2 == 0) h();
return 0;
}
answered 11 hours ago
BrianBrian
67k799192
answered 11 hours ago
BrianBrian
67k799192
answered 11 hours ago
BrianBrian
67k799192
answered 11 hours ago
BrianBrian
67k799192
67k799192
You answer seems to be correct, but I don't agree with your reasoning. Consider this:constexpr int f() { h(); return 1; }. In this case the code is ill-formed NDR according to [dcl.constexpr]/5 because the functionfinvokes a non-constexpr functionh, and this is not allowed according to [expr.const]/(4.2). See also this question in SO.
– Alexander
9 hours ago
@Alexander In the case where the call toh()is before the return statement, every call tofwill fail to be a constant expression, and [dcl.constexpr]/5 applies. In the case where the call toh()is after the return statement, every call tofwill be a constant expression, so [dcl.constexpr]/5 does not apply.
– Brian
9 hours ago
Ok, but why did you say "The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions."? This is what is confusing in your answer.
– Alexander
9 hours ago
1
@Alexander I'm not sure what part of that was unclear. I linked a section of the standard that lists the constructs that are forbidden from appearing in aconstexprfunction's body. A call to a non-constexprfunction is not one of the forbidden constructs. However, if the call to the non-constexprfunction becomes inevitable (i.e., occurs along all paths) then [dcl.constexpr]/5 becomes violated.
– Brian
9 hours ago
add a comment |
You answer seems to be correct, but I don't agree with your reasoning. Consider this:constexpr int f() { h(); return 1; }. In this case the code is ill-formed NDR according to [dcl.constexpr]/5 because the functionfinvokes a non-constexpr functionh, and this is not allowed according to [expr.const]/(4.2). See also this question in SO.
– Alexander
9 hours ago
@Alexander In the case where the call toh()is before the return statement, every call tofwill fail to be a constant expression, and [dcl.constexpr]/5 applies. In the case where the call toh()is after the return statement, every call tofwill be a constant expression, so [dcl.constexpr]/5 does not apply.
– Brian
9 hours ago
Ok, but why did you say "The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions."? This is what is confusing in your answer.
– Alexander
9 hours ago
1
@Alexander I'm not sure what part of that was unclear. I linked a section of the standard that lists the constructs that are forbidden from appearing in aconstexprfunction's body. A call to a non-constexprfunction is not one of the forbidden constructs. However, if the call to the non-constexprfunction becomes inevitable (i.e., occurs along all paths) then [dcl.constexpr]/5 becomes violated.
– Brian
9 hours ago
You answer seems to be correct, but I don't agree with your reasoning. Consider this:
constexpr int f() { h(); return 1; }. In this case the code is ill-formed NDR according to [dcl.constexpr]/5 because the function f invokes a non-constexpr function h, and this is not allowed according to [expr.const]/(4.2). See also this question in SO.– Alexander
9 hours ago
You answer seems to be correct, but I don't agree with your reasoning. Consider this:
constexpr int f() { h(); return 1; }. In this case the code is ill-formed NDR according to [dcl.constexpr]/5 because the function f invokes a non-constexpr function h, and this is not allowed according to [expr.const]/(4.2). See also this question in SO.– Alexander
9 hours ago
@Alexander In the case where the call to
h() is before the return statement, every call to f will fail to be a constant expression, and [dcl.constexpr]/5 applies. In the case where the call to h() is after the return statement, every call to f will be a constant expression, so [dcl.constexpr]/5 does not apply.– Brian
9 hours ago
@Alexander In the case where the call to
h() is before the return statement, every call to f will fail to be a constant expression, and [dcl.constexpr]/5 applies. In the case where the call to h() is after the return statement, every call to f will be a constant expression, so [dcl.constexpr]/5 does not apply.– Brian
9 hours ago
Ok, but why did you say "The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions."? This is what is confusing in your answer.
– Alexander
9 hours ago
Ok, but why did you say "The call to h() in the body of f() is not ill-formed because the constraints on constexpr functions don't say anything about not being allowed to call non-constexpr functions."? This is what is confusing in your answer.
– Alexander
9 hours ago
1
1
@Alexander I'm not sure what part of that was unclear. I linked a section of the standard that lists the constructs that are forbidden from appearing in a
constexpr function's body. A call to a non-constexpr function is not one of the forbidden constructs. However, if the call to the non-constexpr function becomes inevitable (i.e., occurs along all paths) then [dcl.constexpr]/5 becomes violated.– Brian
9 hours ago
@Alexander I'm not sure what part of that was unclear. I linked a section of the standard that lists the constructs that are forbidden from appearing in a
constexpr function's body. A call to a non-constexpr function is not one of the forbidden constructs. However, if the call to the non-constexpr function becomes inevitable (i.e., occurs along all paths) then [dcl.constexpr]/5 becomes violated.– Brian
9 hours ago
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55752281%2fthe-code-below-is-it-ill-formed-ndr-or-is-it-well-formed%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
Clang does not allow calling
h()before returning, so the real question here is: Is a compiler allowed to ignore dead ill-formed code?– idmean
11 hours ago
"as it calls a non-constexpr function
h". But it doesn't actually callh. I'd say that gcc is wrong here.– geza
11 hours ago
I'm adding the C++14 tag since on C++11 there's no question that it's ill-formed.
– Barry
11 hours ago
This code works in GCC's trunk.. godbolt.org/z/f04MCq and godbolt.org/z/bAyE8a .. So it's already fixed.. Free upvotes. If compiled with GCC 8.3 it will fail but compile with Trunk and it works fine.
– Brandon
11 hours ago