--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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&
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
--- 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
--- 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
--- 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
--- 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.
--- 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
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
--- 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
--- 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
... 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
--- 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
--- 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
--- 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
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
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
--- 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
29 matches
Mail list logo