--- Additional Comments From pcarlini at suse dot de 2005-03-10 17:13
---
Eh, I was looking at the very same code... Can't we deal with EMPTY_CLASS_EXPR
similarly to USING_STMT? ;) ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--- Additional Comments From pcarlini at suse dot de 2005-03-10 21:19
---
Seems already fixed in mainline and 4_0-branch...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20414
--- Additional Comments From pcarlini at suse dot de 2005-03-11 18:27
---
Maybe I can fix this one too...
--
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Additional Comments From pcarlini at suse dot de 2005-03-11 21:20
---
1.39065e-309 is just a random bit pattern: a is uninitialized. Indeed, the input
of 1.0e+309 fails, a is left untouched and afterwards cin.fail() is true. Ok.
--
What|Removed
--- Additional Comments From pcarlini at suse dot de 2005-03-13 00:01
---
This issue seems related (or maybe we should open a separate PR?)
http://gcc.gnu.org/ml/gcc/2004-12/msg01140.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20448
--- Additional Comments From pcarlini at suse dot de 2005-03-13 00:20
---
Agreed, tomorrow will create one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20448
: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
CC: aj at suse dot de,gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20451
--- Additional Comments From pcarlini at suse dot de 2005-03-17 14:42
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pcarlini at suse dot de 2005-03-17 18:32
---
Seems simple.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at
--- Additional Comments From pcarlini at suse dot de 2005-03-18 12:04
---
Looking into it.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini
--- Additional Comments From pcarlini at suse dot de 2005-03-18 22:16
---
Notice that the ICE happen only with checking enabled, but seems easy to fix
and we can avoid "confused by earlier errors, bailing out" otherwise.
--
What|Removed
--- Additional Comments From pcarlini at suse dot de 2005-03-19 20:52
---
Sorry about the apparently not-so-helpful reply, but really I think something is
broken with your specific setup: if this were a real bug, then basically no
non-trivial c++ program would work on x86_64, and this
--- Additional Comments From pcarlini at suse dot de 2005-03-19 22:38
---
> Yes I have also installed gcc-3.4.3!
> GCC-3.4.3 has no problem at all compiling that program!
> What can I do?
Ok, therefore this is only an installation problem, not a bug anywhere (I'm
going
--- Additional Comments From pcarlini at suse dot de 2005-03-19 22:45
---
...and also, at minimum, for the example:
'LD_LIBRARY_PATH="/usr/local/gcc34/lib:$LD_LIBRARY_PATH"; export
LD_LIBRARY_PATH'
Unfortunately, I think you had better removing completely
--- Additional Comments From pcarlini at suse dot de 2005-03-19 23:17
---
> Do you really think is an installation problem?
Definitely. Those bash lines must *not* go inside .bashrc! Otherwise, are in
effect also when you use your system compiler and the wrong (3.4.3) library
--- Additional Comments From pcarlini at suse dot de 2005-03-20 09:51
---
> The problem persists!
> What can I do?
As I replied privately, please clean-up your paths to the standard ones and
re-install (completely, core, c++, library) you system compiler.
Sorry, but I will not b
--- Additional Comments From pcarlini at suse dot de 2005-03-20 20:13
---
Seenms doable...
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini
--- Additional Comments From pcarlini at suse dot de 2005-03-21 12:52
---
Oops! Will do momentarily. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20461
--- Additional Comments From pcarlini at suse dot de 2005-03-21 12:58
---
Fixed for 4.0.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
IRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
CC: caj at cs dot york dot ac dot uk,gcc-bugs at gcc dot gnu
dot org
http://gcc.gnu.org/bug
--- Additional Comments From pcarlini at suse dot de 2005-03-21 15:36
---
Fixed for 3.4.4.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pcarlini at suse dot de 2005-03-22 09:29
---
Fixed for 4.0.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pcarlini at suse dot de 2005-03-22 09:30
---
Fixed for 4.0.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pcarlini at suse dot de 2005-03-22 12:09
---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pcarlini at suse dot de 2005-03-22 15:36
---
Hi Volker: probably your patch fixes c++/20443 too! Can you check?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19980
--- Additional Comments From pcarlini at suse dot de 2005-03-24 00:19
---
But, isn't 19953 about -ffast-math? Or you really want the same code *without*
that switch?!? We are talking about completely different issues, IMHO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20610
--- Additional Comments From pcarlini at suse dot de 2005-03-24 00:26
---
For concreteness, this is what I get (with 4.0.0 20050321) if I add
-ffast-math to your switches, seems not so bad, first blush:
_Z1fv:
.LFB1939:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1
--
What|Removed |Added
CC||pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20610
--- Additional Comments From pcarlini at suse dot de 2005-03-24 01:17
---
Ok, thanks. Then closing as not a libstdc++ bug.
--
What|Removed |Added
Status
--- Additional Comments From pcarlini at suse dot de 2005-03-24 09:28
---
> It would be nice if the multiplication worked like this also for
> complex, even without -ffast-math. Or, is there something in the
> standard which would disallow this?
I don't think there
--- Additional Comments From pcarlini at suse dot de 2005-03-24 09:33
---
Side note: here we are talking about the specializations for real/double/long
double, therefore no _M_real but __real__ _M_value and so on. In this case we
rely on the compiler to expand the operations using to
--- Additional Comments From pcarlini at suse dot de 2005-03-24 09:55
---
Argh! No, I was totally wrong: I tried fixing this problem some time ago and
did something wrong. We can fix it in the library. Sorry.
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-03-24 11:08
---
Richard, can you possibly have a look? Why fold_complex_mult_parts doesn't
optimize well complex * real also when no-fast-math?
--
What|Removed |
--- Additional Comments From pcarlini at suse dot de 2005-03-24 11:39
---
The middle-end problem seems that, when no-fast-math, c99-conforming method, we
are not implementing systematically the special cases in G.5.1/2 (and /3 for the
division).
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From pcarlini at suse dot de 2005-03-24 15:52
---
I'm recategorizing back to middle-end: really this should be properly fixed
in the middle-end.
--
What|Removed |
--- Additional Comments From pcarlini at suse dot de 2005-03-30 15:09
---
Irrespective of the fact that the code compiles or doesn't, I believe it's
*invalid*, because, according to 23.1/8, "All other constructors for these
container types take an Allocator& argument,
--- Additional Comments From pcarlini at suse dot de 2005-03-30 15:15
---
> One more argument is that this feature is required to compile correctly
> STLport.
*Assuming* this is true, it's a serious problem for STLPort ;) because the
other
widespread C++ front-end, u
--
What|Removed |Added
Severity|critical|normal
Component|c++ |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Additional Comments From pcarlini at suse dot de 2005-03-31 20:56
---
This is not a bug, it's the intended, standard conforming, behavior.
This is happening because, when you call dest.reserve(dest.length() + 1) the
string class is actually *shrinking* the capacity of the s
--- Additional Comments From pcarlini at suse dot de 2005-03-31 20:57
---
*** Bug 20706 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2005-03-31 21:14
---
I should also add, that, in general, your snippet could be simpler, without
penalizing the performance: typically reserve is only called once, at the
outset, if we can estimate in advance the final size of the
--- Additional Comments From pcarlini at suse dot de 2005-03-31 21:15
---
So closing it.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
--- Additional Comments From pcarlini at suse dot de 2005-04-01 13:31
---
Ok, my change was only dictated by consistency, and the original idea of using
"enhancement" is not mine ;) Let's remove "enhancement" from both. By the way,
I really noticed yesterda
--
What|Removed |Added
Severity|enhancement |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
--- Additional Comments From pcarlini at suse dot de 2005-04-01 14:26
---
> I think it is not OK to include or .
I agree. Actually, probably we have already briefly discussed that (privately)
with Benjamin. Is there something wrong with just using if () abort() instead?!?
(in case
--- Additional Comments From pcarlini at suse dot de 2005-04-01 14:34
---
I think we can safely close this one.
--
What|Removed |Added
Status|UNCONFIRMED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|WAITING
--- Additional Comments From pcarlini at suse dot de 2005-04-01 22:54
---
Humpf! A problem with the trivial fix using abort() is that doesn't emit
diagnostic about the failure point. This is relevant for , which
uses _GLIBCXX_DEBUG_ASSERT/PEDASSERT directly.
--
http://gcc.gn
--- Additional Comments From pcarlini at suse dot de 2005-04-01 23:02
---
...and also elsewhere (there are more uses besides ).
--
What|Removed |Added
AssignedTo
--- Additional Comments From pcarlini at suse dot de 2005-04-04 23:37
---
Hi. I suspect some of these issues are well known and general, not specific to
our implementation (e.g., the Std vs signed zeros, see N1612, available from:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers
--- Additional Comments From pcarlini at suse dot de 2005-04-05 14:36
---
Ok, you are right (forgot that your testcases is for negative real part): then
the imaginary part of the log changes from +Pi to -Pi, since it's equal to arg.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Additional Comments From pcarlini at suse dot de 2005-04-05 14:47
---
Gaby, what do you think about this issue? In fact, it seems to me that an
implementation strictly following the standard (26.2.6/6), or complex1.patch
here, doesn't not incur in this pr
--
What|Removed |Added
CC||pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
--- Additional Comments From pcarlini at suse dot de 2005-04-06 09:17
---
> I think we need more careful analysis and tracking of both C99, C++ and
> LIA-3.
Ok, thanks, I will start on such analysis (in particulat wrt LIA-3). A minor
issue with complex1.patch is that probably
--- Additional Comments From pcarlini at suse dot de 2005-04-06 09:27
---
By the way, about the log, now that you mention it, it's really a pity that we
cannot enable and use the builtin due to the namespace issues with the clog
stream. We should really figure out a way to resolve
4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: pcarlini at suse dot de
ReportedBy: pcarlini at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.c
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20787
--- Additional Comments From pcarlini at suse dot de 2005-04-07 09:14
---
> The problem is that the native read translates the input \r\n to
> \n, returning the number of chars written,
This is a very fundamental assumption to break, which is likely to case much
more pr
--- Additional Comments From pcarlini at suse dot de 2005-04-07 09:14
---
> The problem is that the native read translates the input \r\n to
> \n, returning the number of chars written,
This is a very fundamental assumption to break, which is likely to cause much
more pr
--
What|Removed |Added
CC||pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20806
--- Additional Comments From pcarlini at suse dot de 2005-04-07 10:31
---
Ok, now I see the real, underlying problem: in config/io/basic_file_stdio.cc we
don't deal properly with "short read", that is, we don't try to loop if the
number of read chars is < n but
--- Additional Comments From pcarlini at suse dot de 2005-04-07 13:02
---
Actually, we are not already doing that for a reason: doesn't work with pipes
(fifos), because, after the first succesful, short read, they block...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20806
--- Additional Comments From pcarlini at suse dot de 2005-04-07 21:17
---
> Apart from looking at standards, we could also try to use our brains, right?
> It must be possible to answer the question whether the current behavior is
> right or not by analogy with real numbers, i
--- Additional Comments From pcarlini at suse dot de 2005-04-07 22:19
---
> Indeed. Has that standard been released yet?
Not to my knowldege.
> What's the exact reference, and
> is there some public access, maybe to draft
--- Additional Comments From pcarlini at suse dot de 2005-04-08 09:51
---
Yes, I agree that things seem rather crazy, indeed the behavior that you
reported
seemed crazy in the first place. I think all of this is a matter of compromises:
when zero is involved the signedness turns out to
--- Additional Comments From pcarlini at suse dot de 2005-04-08 21:00
---
Yes, this is actually a very long standing bug, which we hoped didn't trigger
in common situations (because the fix probably is rather ugly :(
Ok, let's finally work on it. Thanks for y
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20909
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20806
Summary: Another grouping trouble
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: pcarlini at suse dot de
ReportedBy: pcarlini at suse dot de
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-04-
--- Additional Comments From pcarlini at suse dot de 2005-04-09 07:53
---
Can you expand a bit on that? I understand perfectly that we are not going to
have CAS for i386, but what's wrong with i486+?!?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14311
--- Additional Comments From pcarlini at suse dot de 2005-04-09 08:10
---
Ah, ok, now I got it ;) Actually, you meant exactly that i386 will *never* be
exchangeable with i486+...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14311
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20914
--- Additional Comments From pcarlini at suse dot de 2005-04-16 11:53
---
Can you please try either a snapshot of 3.4.4 or 4.0? I'm pretty sure this is
already fixed: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00308.html.
--
What|Removed |
--- Additional Comments From pcarlini at suse dot de 2005-04-17 16:34
---
Hi. It can well be a libstdc++ problem, and indeed I can imagine ways to avoid
signed integers in the code. However, I'm not sure that someone will actually
do the work, given the soon-to-be-deprecated stat
--- Additional Comments From pcarlini at suse dot de 2005-04-17 18:16
---
This can be safely closed: in Lillehammer, the LWG moved the proposed resolution
of DR 467 to [Ready] (modulo a minor pasto in the first sentence) thus
explicitly
mandating the behavior implemented by v3
--- Additional Comments From pcarlini at suse dot de 2005-04-17 18:27
---
Ick! :(
Actually, I clearly remember a message from Mark warning that something could go
wrong when using different allocators in different sources, but then forgot
about the issue when we switched. I really hope
--- Additional Comments From pcarlini at suse dot de 2005-04-18 14:14
---
Hi Michael and thanks for asking: really, I'm lost in this tangle of front-end,
back-end and library issues. When I'm back from Oxford really want to move the
issue forward, somehow, asking all the kno
--- Additional Comments From pcarlini at suse dot de 2005-04-18 14:23
---
> This is news to me. Does this mean that vector is not going to be
> special-
> cased any more? That seems like a very bad idea to me, since programs will
> suddenly take 8 times as much memory (
--- Comment #2 from pcarlini at suse dot de 2008-01-17 18:15 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #3 from pcarlini at suse dot de 2008-01-17 19:10 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #2 from pcarlini at suse dot de 2008-01-17 23:21 ---
The behavior is correct. First the default constructor is used in resize, then
(you can't see it with the snippet) the copy constructor binds to that default
constructed element, used in 3 placement new; finall
--- Comment #2 from pcarlini at suse dot de 2008-01-18 11:27 ---
This is fixed by the same patch which fixes c++/34766
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2008-01-18 11:34 ---
I meant c++/34776, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34486
--- Comment #6 from pcarlini at suse dot de 2008-01-19 20:24 ---
This is not a bug, and already spuriously reported: yu *cannot* use
-D_GLIBCXX_FULLY_DYNAMIC_STRING, it's completely unsupported and not described
anywhere in the documentation. You can only completely rebuild the li
--- Comment #5 from pcarlini at suse dot de 2008-01-21 01:52 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at
--- Comment #4 from pcarlini at suse dot de 2008-01-21 01:52 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #2 from pcarlini at suse dot de 2008-01-21 02:31 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at
--- Comment #5 from pcarlini at suse dot de 2008-01-21 23:23 ---
Related to PR28475, then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34824
--- Comment #2 from pcarlini at suse dot de 2008-01-24 10:58 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #5 from pcarlini at suse dot de 2008-01-24 12:02 ---
In mainline is now back to accepts-invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32029
--- Comment #2 from pcarlini at suse dot de 2008-01-24 12:05 ---
Similarly to PR32029, now only accepts-invalid in mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34487
--- Comment #3 from pcarlini at suse dot de 2008-01-24 16:23 ---
Most likely due to the fix for c++/28560, this problem doesn't affect mainline
anymore.
--
pcarlini at suse dot de changed:
What|Removed |
--- Comment #3 from pcarlini at suse dot de 2008-01-24 16:42 ---
Benjamin, can you have a look to the resolution of DR 259:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#259
I believe Simon is basically right...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #5 from pcarlini at suse dot de 2008-01-24 17:36 ---
Excellent, indeed. I also checked stock 4.2.1 and current 4_2-branch.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2008-01-24 19:58 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at
--- Comment #5 from pcarlini at suse dot de 2008-01-24 21:31 ---
Let's try to fix this...
--
pcarlini at suse dot de changed:
What|Removed |Added
Assig
901 - 1000 of 2287 matches
Mail list logo
