[Bug c/43624] Bad code generation: introduces strict aliasing warnings and references to uninitialized memory

2010-04-08 Thread veksler at il dot ibm dot com
--- Comment #7 from veksler at il dot ibm dot com 2010-04-08 19:29 --- Created an attachment (id=20340) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20340&action=view) testcase: A simple set::iterator wrapper produces the same warning This c++ file gives a similar warni

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

2010-02-21 Thread veksler at il dot ibm dot com
--- Comment #38 from veksler at il dot ibm dot com 2010-02-21 18:20 --- (In reply to comment #37) > is_modulo is intended to describe the implementation's choice, not necessarily > the CPU behaviour (which the implementation may choose to mask or not.) > > The issue

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

2010-02-21 Thread veksler at il dot ibm dot com
--- Comment #35 from veksler at il dot ibm dot com 2010-02-21 13:33 --- (In reply to comment #34) > (In reply to comment #33) > > (In reply to comment #32) > > > If this hazard is so prevalent shouldn't it deserve a separate PR? > > > If a method or fu

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

2010-02-21 Thread veksler at il dot ibm dot com
--- Comment #32 from veksler at il dot ibm dot com 2010-02-21 12:44 --- (In reply to comment #31) > (In reply to comment #30) > > Wouldn't it be a violation of the one definition rule (ODR), > > when one translation unit is compiled with -fwrapv and another witho

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

2010-02-20 Thread veksler at il dot ibm dot com
--- Comment #30 from veksler at il dot ibm dot com 2010-02-21 07:52 --- (In reply to comment #25) > It would probably be useful to add a preprocessor macro when -fwrapv is > in effect. > Wouldn't it be a violation of the one definition rule (ODR), when one translation un

[Bug target/30484] Miscompilation of remainder expressions on CPUs of the i386 family

2007-01-17 Thread veksler at il dot ibm dot com
--- Comment #6 from veksler at il dot ibm dot com 2007-01-17 08:49 --- (In reply to comment #0) > The program below shows (at all the optimization levels) a miscompilation of > the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of > the i386 family

[Bug c++/23542] Warn template instantiation calling static functions

2005-08-24 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-08-24 07:11 --- There is another enhancement possibility for this issue. GCC may mark the instantiated template function is such a way that the linker will detect multiple instantiation (which will lead to undefined

[Bug c++/23542] New: Warn template instantiation calling static functions

2005-08-23 Thread veksler at il dot ibm dot com
s: UNCONFIRMED Severity: enhancement Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: veksler at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23542

[Bug gcov/profile/12786] -fvpt does not work with signed mod or signed divide with a constant negative number

2005-07-31 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-07-31 07:24 --- Does it mean that it won't be fixed neither on gcc-3.4 nor gcc-4.0 branches? By marking it "resolved" will it not hide this PR when number of open issues is counted for gcc-3.4 and g

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc

2005-06-27 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27 22:00 --- (In reply to comment #22) > (In reply to comment #21) > > 2. (OTOH) Undefind situations are unhelpful the the users, they complicate > >debugging, and make programming harder. Reducing r

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc

2005-06-27 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27 20:28 --- (In reply to comment #13) > Invalid as the C++ standard says: > " True if the type is modulo.203) A type is modulo if it is possible to add > two positive numbers and > have a result that

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc

2005-06-27 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27 16:35 --- In Comment #5 Andrew Pinski writes: > Actually it is modulo for all operations. > and INT_MAX/-1 does not raise a trap. That was a typo on my part. It was supposed to be INT_MIN/-1 INT_MAX/-1 do

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistend with gcc

2005-06-27 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-06-27 15:33 --- This is a bug because std::numeric_limits::is_modulo should be true only if singed overflow is defined. This is not the case with gcc, because gcc does not have the extension "signed oveflow == module&

[Bug libstdc++/22200] New: numeric_limits::is_modulo is inconsistend with gcc

2005-06-27 Thread veksler at il dot ibm dot com
Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: veksler at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org

[Bug libstdc++/21951] [4.0 only] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions

2005-06-08 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-06-08 14:43 --- (In reply to comment #7) > It sure as hell is for those shops that require -Werror. > > But ok, I'll be happy if it's fixed for 4.0.2. I think that your argument (as phrased) does not ho

[Bug libstdc++/21951] [4.0 only] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions

2005-06-08 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-06-08 14:11 --- (In reply to comment #6) > Note Mark has said in the past (and in a private mail which was supposed to be a public one too) that > warnings cannot cause this to be a rejects valid. For the same reas

[Bug c++/21951] [gcc-4.0 regression, rejects-valid] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions

2005-06-07 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-06-07 19:46 --- (In reply to comment #3) > Paolo I copied the quote fully when I really should not have. RTH did not know we could not fix the > if(0) part in libstdc++ at the time he wrote that comment, if you re

[Bug middle-end/19699] [4.0/4.1 Regression] warning about not returning from end of a non-void function because of dead code

2005-06-06 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-06-06 15:20 --- (In reply to comment #13) > (In reply to comment #12) > > Will the patch be applied to 4.0 branch too? > No because it is too big in that it also changes the inliner to be a CFG aware inliner.

[Bug c++/21808] Uninformative diagnostic for name lookup for template functions

2005-05-29 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-05-29 20:33 --- I disagree. 1. Because it is a template the "correct" error is supressed. 2. It passes with gcc-3.3, but fails with gcc-3.4.3 This is unlike your example: template struct A { T t; }; // Swap

[Bug c++/21808] New: Uninformative diagnostic for name lookup from template function

2005-05-29 Thread veksler at il dot ibm dot com
D Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: veksler at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808

[Bug c++/21483] Spurious 'control may reach end of non-void function' ... being inlined

2005-05-10 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-05-11 03:53 --- (In reply to comment #1) > > *** This bug has been marked as a duplicate of 19699 *** Shouldn't it be marked as a duplicate of 19583 instead, and 19583 be reopened? -- http://gcc.gnu.o

[Bug c++/21483] Spurious 'control may reach end of non-void function' ... being inlined

2005-05-10 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2005-05-11 03:52 --- (In reply to comment #1) > > *** This bug has been marked as a duplicate of 19699 *** Shouldn't it be marked as a duplicate of 19583 instead, and 19583 be reopened? -- http://gcc.gnu.o

[Bug c++/21483] New: Spurious 'control may reach end of non-void function' ... being inlined

2005-05-09 Thread veksler at il dot ibm dot com
... being inlined Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: veksler at il dot ibm dot com

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

2004-10-19 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2004-10-19 20:53 --- Subject: Re: Undefined reference to ~basic_iostream(), with -O[12] I also think that 2.14 is not uncommon. RHEL-3 is also affected. If this is fixed, I'll continue my efforts to evaluate gcc-4.0

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

2004-10-19 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2004-10-19 13:32 --- Subject: Re: Undefined reference to ~basic_iostream(), with -O[12] To summarize the difference between our setups: My setup (that fails): - binutils-2.14.90.0.4-35 - No special configure --enable flags

[Bug libstdc++/18054] Undefined reference to ~basic_iostream(), with -O[12]

2004-10-19 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2004-10-19 11:01 --- Yes, I do get the same errors as reported in http://gcc.gnu.org/ml/libstdc++/2004-09/msg00125.html Here is the offending symbol: $ nm --demangle /home/veksler/gcc-4.0-20041017/lib/libstdc++.so | grep

[Bug libstdc++/18054] New: Undefined reference to ~basic_iostream(), with -O[12]

2004-10-19 Thread veksler at il dot ibm dot com
mal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: veksler at il dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18054

[Bug c++/18047] New: Wrong precedence between equality (==, !=) and < operators

2004-10-18 Thread veksler at il dot ibm dot com
gcc-4.0 gives operator== higher precedence than operator<, which is against 5.10 paragraph 1: "Note: ahttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=18047

[Bug c++/14950] [3.4 Regression] [non unit-at-a-time] always_inline does not mix with templates and -O0

2004-10-13 Thread veksler at il dot ibm dot com
--- Additional Comments From veksler at il dot ibm dot com 2004-10-13 11:23 --- I can still reproduce on 3.4.2 with the original test case, using "g++ -g -c t.cpp". There is a proposal in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950#c5 to stop support for always_inline