[Bug c++/88458] New: Conditional expression where the second and third operand are int and nullptr treated as ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88458 Bug ID: 88458 Summary: Conditional expression where the second and third operand are int and nullptr treated as ill-formed Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yaghmour.shafik at gmail dot com Target Milestone: --- Given the following code char* ch4 = true ? 0 : nullptr; and compiling with the following flags: -std=c++17 gcc produces the following diagnostic: error: operands to ?: have different types 'int' and 'std::nullptr_t' 4 | char* ch4 = true ? 0 : nullptr; | ~^ Both clang and MSVC accepts this code w/o diagnostic, see godbolt: https://godbolt.org/z/BraaEu I believe according to http://eel.is/c++draft/expr.cond#7.5 this is well-formed.
[Bug c++/87275] unsequenced writes not diagnosed in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87275 --- Comment #3 from Shafik Yaghmour --- Note, I have filed similar bugs for clang: https://bugs.llvm.org/show_bug.cgi?id=38420 and MSVC: https://developercommunity.visualstudio.com/content/problem/304122/unsequenced-modifications-of-variable-within-a-con.html Also see https://twitter.com/StephanTLavavej/status/1024714057603899392
[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64372 --- Comment #11 from Shafik Yaghmour --- Bumping, it has been a while. I ran into this reviewing [diff.cpp11.expr] https://timsong-cpp.github.io/cppwp/n4659/diff.cpp11.expr and noticed the code in the example similar to the reduced sample fails to compile with current gcc trunk godbolt: https://godbolt.org/z/Ihm9Ps
[Bug c++/89149] New: Out of bounds array access not detected as ill-formed in a constant expression context in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89149
Bug ID: 89149
Summary: Out of bounds array access not detected as ill-formed
in a constant expression context in some cases
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Target Milestone: ---
Given the following C++ example:
void foo() {
constexpr char c1 =
(&(&"abc"[2])[-1])[-3];
constexpr char c2 =
(&(&(&"abc"[2])[-1])[-3])[4];
}
Both declarations should be ill-formed since we have out of bounds array access
in a constant expression context. gcc correctly produces a diagnostic for c1
but not for c2. See live godbolt:
https://godbolt.org/z/z7MrES
Both clang and icc produce a diagnostic for both cases and as indicated here so
does EDG https://twitter.com/zygoloid/status/1090863346016907264
[Bug c++/85867] New: Subscript operator applied to an temporary array results in an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85867
Bug ID: 85867
Summary: Subscript operator applied to an temporary array
results in an lvalue
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Target Milestone: ---
This Stackoverflow question https://stackoverflow.com/q/33161003/1708801
provides the following code:
using Y = int[10];
int main() {
(Y { })[0] = 1;
}
which compiles without diagnostic, CWG defect report 1213:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1213 says the
result of the subscript operator should be an xvalue and therefore not
assignable to.
Also see the following clang bug report on the same issue, which was resolved
at the end of 2017: https://bugs.llvm.org/show_bug.cgi?id=25357
I have a godbolt for it here: https://godbolt.org/g/AmzbFh
We can see that clang no longer allows this but gcc does.
[Bug c/83433] New: Should -Wstrict-overflow=2 produce a diagnostic for abs(INT_MIN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83433
Bug ID: 83433
Summary: Should -Wstrict-overflow=2 produce a diagnostic for
abs(INT_MIN)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Target Milestone: ---
Given the following code:
#include
#include
#include
int main() {
printf( "%d\n", abs(INT_MIN) ) ;
}
and compiling with -Wstrict-overflow=2 should it generate a diagnostic?
Live example: https://wandbox.org/permlink/IzlAIizAPKPCi3Y4
The warning options documentation:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html says:
"Also warn about other cases where a comparison is simplified to a constant.
For example: abs (x) >= 0. This can only be simplified when signed integer
overflow is undefined, because abs (INT_MIN) overflows to INT_MIN, which is
less than zero. -Wstrict-overflow (with no level) is the same as
-Wstrict-overflow=2."
Which seems to indicate(although awkwardly worded) this case should be caught.
[Bug c/83433] Should -Wstrict-overflow=2 produce a diagnostic for abs(INT_MIN)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83433 --- Comment #3 from Shafik Yaghmour --- I still think it is awkwardly worded but your second point is valid about it only warning on comparisons. Please, feel free to close.
[Bug c++/69967] New: #pragma GCC diagnostic ignored being ignored for -Wunused-variable in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69967
Bug ID: 69967
Summary: #pragma GCC diagnostic ignored being ignored for
-Wunused-variable in some cases
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Target Milestone: ---
Given the following example:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"
#include
#pragma GCC diagnostic pop
int main()
{
}
and the following command line options:
--std=c++11 -Wno-deprecated-declarations -Wunused-variable -Werror -O2
gcc 5.3 produces the following diagnostics:
error: ‘boost::system::posix_category’ defined but not used
[-Werror=unused-variable]
static const error_category & posix_category = generic_category();
^
error: ‘boost::system::errno_ecat’ defined but not used
[-Werror=unused-variable]
static const error_category & errno_ecat = generic_category();
^
rror: ‘boost::system::native_ecat’ defined but not used
[-Werror=unused-variable]
static const error_category & native_ecat= system_category();
^
even though it should be ignored due to the:
#pragma GCC diagnostic ignored "-Wunused-variable"
You can find an online example that reproduces this here
http://melpon.org/wandbox/permlink/LhOgWD7JOFrf95ZQ
This issue only shows up when optimization is turned on with -O1 or above.
GCC 4.9.2 and 6.0.0 do not have this issue. In the case of GCC 6.0.0 it is hard
to tell if the issue is fixed since the diagnostic does not show up all even
when reduce the test case to the following:
#include
int main(){}
So in 6.0.0 the warning appears to be less aggressive but now we don't know if
the underlying issue with the pragma is fixed or just hidden by change in
behavior of the warning.
[Bug c++/66170] New: Bogus warning with -Wsign-conversion when using static_cast on an int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66170
Bug ID: 66170
Summary: Bogus warning with -Wsign-conversion when using
static_cast on an int
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Target Milestone: ---
Given the following code:
#include
int main()
{
int length = 0;
size_t n;
n = static_cast(length) ; // Line 8
n = static_cast(length) * sizeof(int) ;
n = sizeof(int) * static_cast(length) ;
n = sizeof(int) * static_cast(length) ; // Line 11
n = sizeof(int) * static_cast(length) ; // Line 13
}
building with gcc 4.9.2 or greater using the following command line:
g++ -Wsign-conversion
generates the following warning on line 13:
warning: conversion to 'long unsigned int' from 'int' may change the sign of
the result [-Wsign-conversion]
This looks like an error to me, the documentation for -Wsign-conversion says:
An explicit cast silences the warning
and line 8 to line 11 are very similar but do not generate any warning.
Optimization level does not make a difference and -Wall -Wextra does not
indicate additional issues.
[Bug c++/60049] New: Right and left shift undefined behavior not an error in a constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60049
Bug ID: 60049
Summary: Right and left shift undefined behavior not an error
in a constexpr
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
I expected the following code involving constexpr to generate errors since all
the shifts invoke undefined behavior:
int main()
{
constexpr int x1 = 1 << 33 ;
constexpr int x2 = 1 << -1 ;
constexpr int x3 = -1 << 1 ;
constexpr int x4 = 1 >> 33 ;
constexpr int x5 = 1 >> -1 ;
}
but instead they generate warnings and all the variables are still considered
constant expressions:
main.cpp:3:34: warning: left shift count >= width of type [enabled by
default]
constexpr int x1 = 1 << 33 ; //Assuming 32-bit int
^
main.cpp:4:35: warning: left shift count is negative [enabled by default]
constexpr int x2 = 1 << -1 ;
^
I built this using the following flags:
-std=c++11 -Wall -Wextra -pedantic -fno-strict-aliasing -fwrapv
and you can see it live here:
http://coliru.stacked-crooked.com/a/95685bb86b5b81e7
while clang 3.5 will generate errors for all these cases, see it live here:
http://coliru.stacked-crooked.com/a/0638d424b28ecd87
I brought this up on StackOverflow, since it was not clear to me this was a
bug:
http://stackoverflow.com/questions/21502017/is-the-compiler-allowed-leeway-in-what-it-considers-undefined-behavior-in-a-cons
and although the consensus seems to be that this is strictly conforming
standard behavior, a conversation I had offline suggests this behavior is
surprising and probably not intended.
Note that in all the other cases I have tested of undefined behavior in a
constexpr gcc does generate an error for example:
constexpr int x = std::numeric_limits::max() + 1 ;
generates the following error:
main.cpp:6:61: error: overflow in constant expression [-fpermissive]
constexpr int x = std::numeric_limits::max() + 1 ;
^
[Bug c++/55986] RHS of logical operators may render LHS unevaluated in constant-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55986
--- Comment #5 from Shafik Yaghmour ---
It looks like this case from this Stackoverflow question
http://stackoverflow.com/q/32920229/1708801 is possibly related:
int main(int argc, char**)
{
constexpr int a = argc * 0;
}
gcc treats `argc * 0` as a constant expression a comment indicates this is due
to constant folding and it seems possible that gcc is constant folding `i ||
true` as well.
[Bug c++/68262] New: Ill-formed function pointer declaration acts as multi-line comment until ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68262
Bug ID: 68262
Summary: Ill-formed function pointer declaration acts as
multi-line comment until ;
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Target Milestone: ---
Given the following code:
#include
int main()
{
void (*) {}
We could go on and on
line after line
and no errors?
;
std::cout << "hello\n" ;
}
live example here http://melpon.org/wandbox/permlink/iWzF2dKUBxZ3NOMn
What looks like an ill-formed function pointer declaration does not generate a
diagnostic and allows complete none sense until a ; is reached.
After that the compiler seems to go on as if nothing odd has happened.
This seems to go back as far as 4.4.7 and version 4.3.6 does not seem to have
this bug.
[Bug c++/49813] [C++0x] sinh vs asinh vs constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813 Shafik Yaghmour changed: What|Removed |Added CC||yaghmour.shafik at gmail dot com --- Comment #59 from Shafik Yaghmour --- The resolution of LWG 2013 changed: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3788.html#2013 and it no longer gives implementation the freedom to treat standard library functions as constexpr unless it is explicitly required. The new wording was included in the draft standard since at least N3936. Although a strict reading seems to leave some wiggle room the intention as mentioned in the updated issue was to avoid "diverging library implementations, as users may use SFINAE to observe different behavior from otherwise identical code".
[Bug c++/65043] New: Expected narrowing conversion during list initialization of bool from double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65043
Bug ID: 65043
Summary: Expected narrowing conversion during list
initialization of bool from double
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Given the following code form this stackoverflow question
http://stackoverflow.com/q/27507361/1708801 :
#include
struct X
{
X(bool arg) { std::cout << arg << '\n'; }
};
int main()
{
double d = 7.0;
X x{d};
}
I expect a narrowing conversion error on this line:
X x{d};
Neither clang nor gcc produce an error although Visual Studio does. Although
the comment is now deleted Jonathan Wakely noted that the EDG compiler gives a
narrowing error for the code.
[Bug c++/65327] GCC rejects "constexpr volatile int i = 5;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65327 Shafik Yaghmour changed: What|Removed |Added CC||yaghmour.shafik at gmail dot com --- Comment #1 from Shafik Yaghmour --- Defect report 1688: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4093.html#1688 confirms that this is valid, and it says: "The combination is intentionally permitted and could be used in some circumstances to force constant initialization."
[Bug c++/62110] New: Attempting to use template conversion operator in a contextual conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62110
Bug ID: 62110
Summary: Attempting to use template conversion operator in a
contextual conversion
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Given the following code:
class Var
{
public:
operator int () const
{ return 0; }
template
operator T () const
{ return T(); }
};
int main()
{
Var v;
switch (v)
{ }
}
gcc 4.9 produces the following error:
main.cpp: In function 'int main()':
main.cpp:17:14: error: default type conversion can't deduce template argument
for 'template Var::operator T() const'
switch (v)
^
using the following command line options:
-std=c++11 -Wall -Wextra -Wconversion -pedantic
Using -std=c++1y also produces the same error.
while clang 3.4 does not produce any errors. As far as I can tell clang is
correct here for C++1y and is probably correct for C++11 although that may
depend on whether you consider N3323: "A Proposal to Tweak Certain C++
Contextual Conversions" to be a fix for C++11 or part of C++1y.
N3323 is incorporated in N3485 which I consider to be C++11 with fixes but
perhaps that is an incorrect interpretation. Based on this assumption then if
we look at section 6.4.2 it says:
The condition shall be of integral type, enumeration type, or class type. If of
class type, the condition is contextually implicitly converted (Clause 4) to an
integral or enumeration type.
and this would force us to use section 4 paragraph 5 which does not allow or
overload resolution making int conversion the only one available for this
context.
If N3323 is not part of C++11 then it seems unclear to me whether the template
conversion function should be considered or not.
This bug report comes the following Stackoverflow question:
http://stackoverflow.com/questions/25047109/classes-with-both-template-and-non-template-conversion-operators-in-the-conditio
[Bug c++/62116] New: Allowing redeclaration of global variable x using ::x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116
Bug ID: 62116
Summary: Allowing redeclaration of global variable x using ::x
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Given the following code:
int x;
int main() {
int(::x); //does not compile
int(::x + 2); //compiles
}
gcc 4.9 will compile it without an error while gcc 4.8.x and clang 3.4 will
generate an error. For gcc 4.8.x the error is:
error: invalid use of qualified-name '::x'
int(::x); //does not compile
^
and clang gives the following error:
error: definition or redeclaration of 'x' cannot name the global scope
int(::x); //does not compile
~~^
as far as I can tell both gcc 4.8.x and clang are correct here based on my
reading of section 8.3 paragraph 6:
int(::x) ;
is equivalent to:
int ::x ;
which is not valid.
The problem originally cam up in the following Stackoverflow question:
http://stackoverflow.com/questions/24623071/is-typex-valid
[Bug c++/62116] Allowing redeclaration of global variable x using ::x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116 --- Comment #2 from Shafik Yaghmour --- I am happy to be mistaken here, but it seems like section 6.8 paragraph 1 applies, for example if we have the following: int(y) = 10; it is being treated as a declaration not a cast and further more section 6.8 comments on an ill-formed example and says: This is of course ill-formed for semantic reasons, but that does not affect the syntactic analysis. so even though: int(::x); would be ill-formed we are forced to treat it as a declaration and not a function style cast.
[Bug c++/68604] New: typeid does not allow an id-expression that denotes a non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68604
Bug ID: 68604
Summary: typeid does not allow an id-expression that denotes a
non-static data member
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Target Milestone: ---
Given the following simplified example from this Stackoverflow question
http://stackoverflow.com/q/28053640/1708801 :
#include
#include
struct A{ int i; };
int main()
{
std::cout << typeid(A::i).name() << '\n';
}
gcc produces the following error:
error: invalid use of non-static data member 'A::i'
std::cout << typeid(A::i).name() << '\n';
^
As far as I can tell since this is an unevaluated operand like in sizeof and
decltype this should should be ok. clang accepts this code.
[Bug c++/68604] typeid does not allow an id-expression that denotes a non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68604 --- Comment #2 from Shafik Yaghmour --- Wandbox has clang 3.8 and we can see that clang accepts this in C++11 mode: http://melpon.org/wandbox/permlink/IzawQ5DDLFyIyQNo but not in C++03 mode: http://melpon.org/wandbox/permlink/IzawQ5DDLFyIyQNo. Note, defect report 613: http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#613 has CD1 status.
[Bug c++/55986] RHS of logical operators may render LHS unevaluated in constant-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55986 Shafik Yaghmour changed: What|Removed |Added CC||yaghmour.shafik at gmail dot com --- Comment #4 from Shafik Yaghmour --- This issue showed up recently in this Stackoverflow question: http://stackoverflow.com/q/31526278/1708801 As far as I can tell there should at least be a diagnostic when using -pedantic
