[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type
--- Comment #18 from photon at seznam dot cz 2010-06-12 16:46 --- (In reply to comment #17) The patch was rejected but it may be accepted by using a new -Wno-* option to disable these warnings. Perhaps -Wno-conversion-after-promotion? Suggestions are welcome. -Wconversion should be fixed to work as specified. No warning should be generated for the following code: char c = 2; // warning: conversion to char from int may alter its value c = 1; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type
-- photon at seznam dot cz changed: What|Removed |Added Severity|enhancement |normal Summary|-Wconversion: do not warn |-Wconversion generates false |for operands not larger than|warnings for operands not |target type |larger than target type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug c++/40752] -Wconversion: do not warn for operands not larger than target type
--- Comment #6 from photon at seznam dot cz 2009-07-15 07:50 --- (In reply to comment #1) Theses are not false warnings: c = 1; is really c = (int)c 1; They are false warnings. The implicit conversion cannot alter the value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug c++/40752] -Wconversion: do not warn for operands not larger than target type
--- Comment #7 from photon at seznam dot cz 2009-07-15 07:54 --- (In reply to comment #5) Then, let's keep this around as an enhancement request. I think this is actually a bug as the specification of the warning is: Warn for implicit conversions that may alter a value. This is not the case here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug c++/40752] -Wconversion: do not warn for operands not larger than target type
--- Comment #11 from photon at seznam dot cz 2009-07-15 16:55 ---
(In reply to comment #8)
For:
c += (char) 1;
The value can change as you have a wrapping if c is CHAR_MAX.
Likewise with:
c += c2;
The value cannot change even if an overflow occurs.
{
unsigned char c = 0xff;
c += 1;
// c is 0 here
c = 0xff;
c = (unsigned int)c + 1;
// c is 0 here
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug c++/40752] -Wconversion: do not warn for operands not larger than target type
--- Comment #14 from photon at seznam dot cz 2009-07-15 18:24 ---
(In reply to comment #13)
Or rather from SCHAR_MAX + 1 to SCHAR_MIN :). Since it is 0x7F + 1 ==
(int)0x80. So we have a negative value now from a positive value.
This occurs regardless of the implicit conversion. The implicit conversion
cannot alter the result. Therefore, the warning is false in this case too.
{
char c = 0x7f;
++c;
// c is 0x80 here
c = 0x7f;
c = (int)c + 1;
// c is 0x80 here
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss
--- Comment #4 from photon at seznam dot cz 2009-07-14 08:37 --- (In reply to comment #3) and with integer promotion happening with simple stuff like a + b, some folks will have a hard time to understand that happens which is why it is not enabled with -Wall. The warning is issued only for rare conversions involving a potential data loss which should always be explicit. Plus there are style warnings not included in -Wall. I really doubt you want style warnings enabled with -Wall :). -Wall should be a real -Wall. Now it does not include important warnings like those generated by -Wconversion (potential implicit data loss). GCC should use numerical warning levels. The current -Wall should be renamed to, e.g., -W3 and the new -Wall option should enable all warnings as the name says. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40733
[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss
--- Comment #7 from photon at seznam dot cz 2009-07-14 15:13 --- (In reply to comment #5) -Wconversion hits extremely often, it is definitely not a warning that can or should be enabled in -Wall, nor in -W. The fact that it hits often should not be an argument against including it in the warning level -Wall. Implicit conversion to a smaller type occurs infrequently and should always be explicit to avoid hard to find bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40733
[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss
--- Comment #8 from photon at seznam dot cz 2009-07-14 15:31 --- (In reply to comment #6) As for Wall, we have users requesting less warnings from Wall and users requesting more. We try to find a balance. But you are free to suggest that existing warnings be moved to Wall or Wextra. There should be no discussion about adding or removing anything from the -Wall level. It should include all warnings available. The current -Wall should be renamed to something like -W3 to prevent misleading users. Each warning should be assigned a warning level depending on the severity. The user should normally only need to specify the desired warning level. -Wall should be used only occasionally to make sure no warning is missed. However, first try compiling a few big projects (like the kernel, QT libraries and KDE) and check that the suggested warning only finds real bugs. Thanks. Are you suggesting that -Wconversion does not find real bugs? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40733
[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss
--- Comment #10 from photon at seznam dot cz 2009-07-14 18:11 --- (In reply to comment #9) So your definition of -Wall is not very useful at all and will be even more misleading to users or why the warnings are happening. MSC's /Wall enables all warnings and I don't find it misleading at all. http://msdn.microsoft.com/en-us/library/thxezb7y(VS.71).aspx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40733
[Bug c++/40752] New: -Wconversion generates false warnings
-Wconversion generates false warnings for the following clean code:
{
char c = 1;
char c2 = 2;
// warning: conversion to char from int may alter its value
c = 1;
c += (char) 1;
c += c2;
c = ~c2;
}
--
Summary: -Wconversion generates false warnings
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: photon at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
[Bug c++/40733] No warning is issued when an implicit conversion can lead to a data loss
--- Comment #2 from photon at seznam dot cz 2009-07-13 20:57 --- -Wall has a very misleading name and should probably be changed to match the MSC behaviour (enable all warnings available). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40733
[Bug c/33980] New: Precompiled header file not removed on error
$ cat err.h #error err $ gcc -c err.h err.h:1:2: error: #error err $ ls err.h.gch err.h.gch -- Summary: Precompiled header file not removed on error Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: photon at seznam dot cz GCC host triplet: Linux OpenSuse 10.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33980
[Bug c++/33754] Default argument of type list pair A, B compiles only when typedef is used
--- Comment #7 from photon at seznam dot cz 2007-10-16 09:23 ---
(In reply to comment #6)
What are your thoughts about the other issues raised by 325?
The suggested resolution disregards the syntactical needs of templates and
makes 'int Foo (int i = T1, int::i);' invalid. The current standard is
inconsistent and should be fixed. For example, the following code is invalid:
class A
{
void f (T a);
typedef int T;
};
Yet, this one is not:
class B
{
void f (int a = (T) 1);
typedef int T;
};
This inconsistency is unexpected and confusing. Default arguments should be
strictly required to be parsed at the point of appearance. Deferred parsing
brings very little benefit here, yet the price paid for it is high: template
argument separator does not work as expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33754
[Bug c++/33754] Default argument of type list pair A, B compiles only when typedef is used
--- Comment #5 from photon at seznam dot cz 2007-10-15 07:29 --- (In reply to comment #4) DR 325 describes the ambiguities in the standard. There are a number of possible solutions to accepting this syntax, with different implementation complexities, and it is not clear what the desired outcome is. The desired outcome is clear in this case but the compiler does not recognize the template arguments. Before encountering '=' the parser honors the template argument separator with a higher priority than the function argument separator, afterwards it does not. That does not make sense and certainly either the standard or the compiler should be fixed. As there is a simple workaround -- adding parentheses -- which is unambiguously correct, I do not see a need to speculatively implement a language extension here. Provided the standard is ambiguous, fixing this problem would not introduce a language extension. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33754
[Bug c++/33754] Default argument of type list pair A, B compiles only when typedef is used
--- Comment #2 from photon at seznam dot cz 2007-10-13 08:24 --- (In reply to comment #1) *** This bug has been marked as a duplicate of 57 *** I should note this bug is suspended. This is because the standard is unclear at what is the correct behavior. See DR 325 for all the details. I vote for this to be fixed in GCC, especially since the standard is unclear. The compiler has the knowledge 'pair' is a template class. MS C++ accepts the syntax and does not violate any standards by doing so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33754
[Bug c++/33470] New: Reassignment of a reference to a polymorphic class fails at runtime
The following code compiles cleanly with 4.2.1. The expected output is C but
the executable outputs B.
#include iostream
using namespace std;
struct A
{
virtual ~A() { }
virtual void f() { cout A; }
};
struct B : public A
{
virtual void f() { cout B; }
};
struct C : public A
{
virtual void f() { cout C; }
};
int main(int argc, char **argv)
{
B Binst;
C Cinst;
A Aref = Binst;
Aref = Cinst;
Aref.f();
return 0;
}
--
Summary: Reassignment of a reference to a polymorphic class fails
at runtime
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: photon at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33470
[Bug c++/33470] Reassignment of a reference to a polymorphic class fails at runtime
--- Comment #2 from photon at seznam dot cz 2007-09-18 12:01 --- (In reply to comment #1) No, B is correct. A Aref = Binst; Aref = Cinst; is the same as: Binst = (A)Cinst; Binst = (A)Cinst would not compile (C is not derived from B). -- photon at seznam dot cz changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33470
[Bug c++/33470] Reassignment of a reference to a polymorphic class fails at runtime
--- Comment #3 from photon at seznam dot cz 2007-09-18 15:12 --- (In reply to comment #1) No, B is correct. A Aref = Binst; Aref = Cinst; is the same as: Binst = (A)Cinst; The compiler treats this case as Ainst = (A) Cinst. -- photon at seznam dot cz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33470
