--- Comment #23 from pcarlini at suse dot de 2006-01-24 23:14 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #22 from paolo at gcc dot gnu dot org 2006-01-24 23:12 ---
Subject: Bug 25649
Author: paolo
Date: Tue Jan 24 23:12:26 2006
New Revision: 110186
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110186
Log:
2006-01-24 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #21 from pcarlini at suse dot de 2006-01-24 22:45 ---
Ok, let's move the concerned inserters and extractors out of line, for the sake
of warning consistency. The performance loss seems bearable.
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-01-24 18:38
---
(In reply to comment #18)
> (In reply to comment #17)
> > I now see how the other PR caused this bug, we now inline "operator >>".
>
> Which means compiling with 4.2, you cannot use a 4.1's libstdc++ so we have an
--- Comment #19 from pcarlini at suse dot de 2006-01-24 18:38 ---
Indeed, as I said already, it's only by *chance* that the warning was not
emitted before, because the logic of the library has not changed and in fact,
**cannot** be changed. Really, if we want something ""better"", either
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-01-24 18:35
---
(In reply to comment #17)
> I now see how the other PR caused this bug, we now inline "operator >>".
Which means compiling with 4.2, you cannot use a 4.1's libstdc++ so we have an
ABI incompatibility now too.
--
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-01-24 18:34
---
I now see how the other PR caused this bug, we now inline "operator >>".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25649
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-24 18:32
---
The guess this bug is invalid then. If the standard is not sane, then this is
actually not a bug.
But then again libstdc++ can be a little saner in the case I gave for comment
#9. That is all I am asking for rea
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-01-24 18:27
---
(In reply to comment #12)
> Andrew, please stop saying stupid things. If you can support your claims with
> the library chapters of the standards, ok, otherwise please spend time on
> something else.
What does the
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-01-24 18:24
---
Lets look at the final IR:
_M_extract (&cin, &__l);
this.90 = (struct basic_ios > *) &cin;
D.31548 = this.90 + *(long int *) (cin._vptr.basic_istream + -24);
__a.59 = (int) D.31548->D.24021._M_streambuf_sta
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-24 18:19
---
(In reply to comment #10)
> I suppose changing the component to libstc++ was a mistake... Irrespective of
> whether the compiler want or not to suppress this warning (in my opinion, it
> should not) the logic in th
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-24 17:14 ---
Here is an example of where we get a false postive:
#include
using namespace std;
int main()
{
int x;
cin >> x;
if (!cin)
{
x = -1;
}
cout << x << endl;
}
We check the error status of cin afte
13 matches
Mail list logo
