http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
--- Comment #16 from Jason Merrill jason at gcc dot gnu.org 2011-03-24
08:58:46 UTC ---
The committee closed my DR as not a defect. We could still downgrade this
error to a pedwarn, though.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
--- Comment #18 from Gunther Piez gpiez at web dot de 2011-03-24 11:45:47 UTC
---
I have chosen the recommended way and added a cast, -fpermissive would allow
to many other dubious constructs to pass. Still I think c++ should get rid of
--- Comment #15 from jason at gcc dot gnu dot org 2010-07-09 21:29 ---
I agree that this is a bug, but it's a bug in C++0x, not with GCC, and
unfortunately it came up too late for me to include it as a national body
comment. I have submitted it as a defect report.
--
jason at gcc
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
--- Comment #14 from redi at gcc dot gnu dot org 2010-06-13 17:14 ---
(In reply to comment #12)
Why not make -Wconversion an error, at least this would
be consistent ;-)
You can use -Werror=conversion
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
--- Comment #13 from gpiez at web dot de 2010-06-12 08:47 ---
...
--
gpiez at web dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #12 from gpiez at web dot de 2010-06-12 08:46 ---
I am closing this, as it isn't a gcc bug, as it behaves according to the
standard.
The bug is in the standard, as it mandates
f1,1 // ok
fCHAR_MAX, CHAR_MAX() // error
gINT_MAX, INT_MAX() // no error, but
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-11 10:57 ---
I wonder what the C++ standard said because we have the same issue in
Wconversion and Joseph rejected my patch arguing that the operation was done in
the larger type, so there was a narrowing conversion. I still
--- Comment #2 from gpiez at web dot de 2010-06-11 11:34 ---
Sorry for the unicode mess. The error message is 'error: narrowing conversion
of (((int)y) + 1) from int to char inside { }'.
The same error happens with a non templated function, but if I use two template
parameters, the
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-11 11:37 ---
'y' and 'C' are both promoted to int and 'y' is not a constant, so the
resulting value cannot be proven to fit in a char, so it's a narrowing
conversion.
If you make 'y' a const int then the value y+C is a constant
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-11 11:42 ---
(In reply to comment #2)
Sorry for the unicode mess. The error I believe I should not get an error,
even if the template parameter type is
larger than a char, as long as the template parameter value fits in in
--- Comment #5 from gpiez at web dot de 2010-06-11 12:09 ---
So is it provable that for a T op T to be stored in T no narrowing takes
place?
If the answer for T == char is no and for T == int it is yes this is rather
fishy ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44500
--- Comment #6 from redi at gcc dot gnu dot org 2010-06-11 12:51 ---
(In reply to comment #5)
So is it provable that for a T op T to be stored in T no narrowing takes
place?
Yes, if the values are constants.
If the answer for T == char is no and for T == int it is yes this is
--- Comment #7 from manu at gcc dot gnu dot org 2010-06-11 13:07 ---
He is referring to a testcase like:
templatetypename T, T C void f() {
struct A {
T x;
};
T y = 42;
A a = { y + C };
}
int main() {
fint,1();
fchar,1();
}
So, we warn for T == char but not for T ==
--- Comment #8 from redi at gcc dot gnu dot org 2010-06-11 13:20 ---
(In reply to comment #7)
He is referring to a testcase like:
templatetypename T, T C void f() {
struct A {
T x;
};
T y = 42;
A a = { y + C };
}
int main() {
fint,1();
fchar,1();
}
--- Comment #9 from gpiez at web dot de 2010-06-11 13:27 ---
I understand now after the implicit promotion to int of a non constant value
the result of the narrowing operation can't be guaranteed to fit in the
original type. But I still think it shouldn't give an error, and if the
--- Comment #10 from manu at gcc dot gnu dot org 2010-06-11 13:33 ---
(In reply to comment #8)
In both cases, T+T has type int,
We know that, but I don't think most C/C++ programmers know about integer
promotion rules. We just disagree here. But since this is mandated by the
--- Comment #11 from redi at gcc dot gnu dot org 2010-06-11 14:56 ---
(In reply to comment #9)
I understand now after the implicit promotion to int of a non constant value
the result of the narrowing operation can't be guaranteed to fit in the
original type. But I still think it
20 matches
Mail list logo
