On Dec 18, 2007, Robert Dewar [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:
Yes, I've considered something along these lines, but decided against
it, for we can't afford for debug information to affect executable
code generation in any way whatsoever, and we don't want to pessimize
On Dec 18, 2007, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Dec 17, 2007, Diego Novillo [EMAIL PROTECTED] wrote:
On 12/17/07 19:50, Alexandre Oliva wrote:
Now, since you're so interested in it and you've already read the
various perspectives on the issue that I listed in my yesterday's
Ross Ridge writes:
This section doesn't make sense to me. The force_align_arg_pointer
attribute and -mstackrealign assume that the ABI is being
followed, while the -fpreferred-stack-boundary option effectively
H.J. Lu hjl at lucon dot org writes
According to Apple engineer who implemented
On 12/18/07 03:07, Alexandre Oliva wrote:
Rats, this below-the-waistline attack really got me annoyed.
I'm sorry you feel that way, it was not meant as a personal attack,
though it was rather brusque. I was getting tired of asking for the
same thing over and over again.
So, what do you
Alexandre Oliva wrote:
On Dec 18, 2007, Robert Dewar [EMAIL PROTECTED] wrote:
OK, so you are agreeing that good debuggability is impossible
with all the optimizations in place, so once again, let's have
an optimziation level that optimizes as far as possible without
harming debuggability.
I
Hi,
thanks for writting the proposal. It seems that at least in general
terms we are all in sync.
At this point we are interested in getting feedback on the general idea.
There is some refactoring that will be needed inside the call-graph
manager and some aspects of the design may not even
Ross Ridge wrote:
Ye, Joey writes:
i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Strictly speaking by the above definition it would be 8 for i386.
The hardware doesn't force the stack to be 32-bit
On Mon, Dec 17, 2007 at 11:25:35PM -0500, Ross Ridge wrote:
// Reserve two stack slots and save return address
// and previous frame pointer into them. By
// pointing new ebp to them, we build a pseudo
// stack for unwinding
Hmmm... I don't know much about the DWARF unwind
On Dec 18, 2007, Diego Novillo [EMAIL PROTECTED] wrote:
On 12/18/07 03:07, Alexandre Oliva wrote:
Rats, this below-the-waistline attack really got me annoyed.
I'm sorry you feel that way, it was not meant as a personal attack,
though it was rather brusque. I was getting tired of asking for
On Tue, Dec 18, 2007 at 03:39:42AM -0500, Ross Ridge wrote:
changes the ABI. According your defintions, I would think
that INCOMING should be ABI_STACK_BOUNDARY in the first case,
and MAX(ABI_STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) in the second.
That isn't true since some .o files
Alexandre Oliva [EMAIL PROTECTED] writes:
A plan to fix local variable debug information in GCC
by Alexandre Oliva [EMAIL PROTECTED]
2007-12-18 draft
Thank you for writing this. It makes an enormous difference.
== Goals
I note that you
Ian Lance Taylor wrote:
Alexandre Oliva [EMAIL PROTECTED] writes:
A plan to fix local variable debug information in GCC
by Alexandre Oliva [EMAIL PROTECTED]
2007-12-18 draft
Thank you for writing this. It makes an enormous difference.
Robert Dewar writes:
Ian Lance Taylor wrote:
Alexandre Oliva [EMAIL PROTECTED] writes:
A plan to fix local variable debug information in GCC
by Alexandre Oliva [EMAIL PROTECTED]
2007-12-18 draft
Thank you for writing this. It makes
Andrew Haley wrote:
=
I don't think it is fine, we have constant complaints from our
users about this. I think we definitely need an optimization
level that avoids this.
Short of putting a barrier at every sequence point, how would you stop
the debugger from jumping all over the place?
Daniel Jacobowitz wrote:
On Tue, Dec 18, 2007 at 11:22:12AM -0500, Robert Dewar wrote:
I don't think it is fine, we have constant complaints from our
users about this. I think we definitely need an optimization
level that avoids this.
It's fine because it's not the problem he's working on.
Robert Dewar writes:
Andrew Haley wrote:
=
I don't think it is fine, we have constant complaints from our
users about this. I think we definitely need an optimization
level that avoids this.
Short of putting a barrier at every sequence point, how would you stop
the
On Tue, Dec 18, 2007 at 11:22:12AM -0500, Robert Dewar wrote:
== Goals
I note that you don't say anything about the other big problem with
debugging optimized code, which is that the debugger jumps around all
over the place. That is fine, of course.
I don't think it is fine, we have
Short of putting a barrier at every sequence point, how would you stop
the debugger from jumping all over the place? I'm assuming that you
do want the debugger to show what is actually going on, not fake it.
You could, for example, add a -Og option that says don't do any
optimizations that
On Tue, Dec 18, 2007 at 08:47:35AM -0500, Daniel Jacobowitz wrote:
On Mon, Dec 17, 2007 at 11:25:35PM -0500, Ross Ridge wrote:
// Reserve two stack slots and save return address
// and previous frame pointer into them. By
// pointing new ebp to them, we build a pseudo
// stack for
On Dec 17, 2007, at 9:45 PM, Sven Herzberg wrote:
I was just browsing the gcc-list to see if there are any updates on
the Objective-C 2.0 extensions. Can you please send and email to the
gcc-list with the current state?
I hope to be able to contribute them in the next year, but exactly
Hi Mike,
Tuesday 18 December 2007 20:04:45 tarihinde Mike Stump şunları yazmıştı:
On Dec 17, 2007, at 9:45 PM, Sven Herzberg wrote:
I was just browsing the gcc-list to see if there are any updates on
the Objective-C 2.0 extensions. Can you please send and email to the
gcc-list with the
On Dec 18, 2007, at 10:08 AM, Ismail Dönmez wrote:
Any schedule for fixing Obj-C++ regressions on mainline?
Same answer. My hope would be that people that introduce regressions
would fix them...
Tuesday 18 December 2007 20:47:29 tarihinde Mike Stump şunları yazmıştı:
On Dec 18, 2007, at 10:08 AM, Ismail Dönmez wrote:
Any schedule for fixing Obj-C++ regressions on mainline?
Same answer. My hope would be that people that introduce regressions
would fix them...
We were talking about
On Dec 18, 2007, Robert Dewar [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:
On Dec 18, 2007, Robert Dewar [EMAIL PROTECTED] wrote:
OK, so you are agreeing that good debuggability is impossible
with all the optimizations in place, so once again, let's have
an optimziation level that
On 12/18/07, Alexandre Oliva [EMAIL PROTECTED] wrote:
Then, we let tree optimizers do their jobs. Whenever they rename,
renumber, coalesce, combine or otherwise optimize a variable, they
will automatically update debug statements that mention them as well.
Speaking only about the tree level,
It is desirable to be able to represent constants and other
optimized-away values, rather than stating variables have values they
can no longer have:
int
x1 (int x)
{
int i;
i = 2;
f(i);
i = x;
h();
i = 7;
g(i);
}
Even if variable i is completely optimized away, a
Ye, Joey writes:
i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Ross Ridge wrote:
Strictly speaking by the above definition it would be 8 for i386.
The hardware doesn't force the stack to be 32-bit aligned,
Ross Ridge wrote:
The -fpreferrred-stack-boundary flag currently generates code that
assumes the stack aligned to the preferred alignment on function entry.
If you assume a worse incoming alignment you'll be aligning the stack
unnecessarily and generating code that this flag doesn't require.
Hello,
This is a complaint about how the bug database is being managed. It
is getting harder and harder to find bug reports to work on, because
too many old bug reports are being kept open even though there is no
sign of intent to ever resolve the report.
For example, PR18346 is a bug report in
So I'm asking for a policy here that says when it is OK to resolve old
bug without progress as WONTFIX or SUSPENDED. Start shooting.
I think this would be a big mistake to reuse an existing state for this.
If/when someone does start caring about that particular feature it'll be
impossible for
Does anyone understand why we get the following when configure is run
in the libgomp directory on darwin?
configure:17711: checking for shared libgcc
configure:17731:
/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/./gcc/xgcc
On Wednesday 19 December 2007, Joe Buck wrote:
On Wed, Dec 19, 2007 at 01:11:11AM +, Paul Brook wrote:
So I'm asking for a policy here that says when it is OK to resolve old
bug without progress as WONTFIX or SUSPENDED. Start shooting.
I think this would be a big mistake to reuse an
On Wed, Dec 19, 2007 at 01:11:11AM +, Paul Brook wrote:
So I'm asking for a policy here that says when it is OK to resolve old
bug without progress as WONTFIX or SUSPENDED. Start shooting.
I think this would be a big mistake to reuse an existing state for this.
But this is pretty much
Ross Ridge wrote:
Ye, Joey writes:
i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Ross Ridge wrote:
Strictly speaking by the above definition it would be 8 for i386.
The hardware doesn't force the stack
On Wed, Dec 19, 2007 at 01:25:19AM +, Paul Brook wrote:
On Wednesday 19 December 2007, Joe Buck wrote:
On Wed, Dec 19, 2007 at 01:11:11AM +, Paul Brook wrote:
So I'm asking for a policy here that says when it is OK to resolve old
bug without progress as WONTFIX or SUSPENDED.
Robert Dewar writes:
Well if we have local variables of type float (and we have specified
use of SSE), we are in trouble, no?
Non-vector SSE instructions, like the ones that operate on scalar floats,
don't require memory operands to be aligned.
Ross Ridge
Ross Ridge wrote:
I'm currently using -fpreferred-stack-boundary without any trouble.
Your proposal would in fact generate code to align stack when it's not
necessary. This would change the behaviour of
-fpreferred-stack-boundary,
hurting performance and that's unacceptable to me.
This
On Tue, Dec 18, 2007 at 06:31:26PM -0500, Ross Ridge wrote:
Ross Ridge wrote:
The -fpreferrred-stack-boundary flag currently generates code that
assumes the stack aligned to the preferred alignment on function entry.
If you assume a worse incoming alignment you'll be aligning the stack
On Wed, 19 Dec 2007, Steven Bosscher wrote:
The bigger issue here, is that people seem to be using Bugzilla as a
kind-of TODO list for things may some day work on, but probably will
I don't see any problem with that. It records known issues. We can then
use the existing fields, or create
On Tue, Dec 18, 2007 at 06:31:25PM -0500, Ross Ridge wrote:
Ye, Joey writes:
i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Ross Ridge wrote:
Strictly speaking by the above definition it would be 8 for
On Wed, Dec 19, 2007 at 01:25:19AM +, Paul Brook wrote:
Ok. I did check the GCC bugzilla help pages, and they don't mention
SUSPENDED
at all :-)
I wrote:
Patches welcome, as they say.
Never mind; see
http://gcc.gnu.org/bugs/management.html
for when to use SUSPENDED.
Ross Ridge wrote:
I'm currently using -fpreferred-stack-boundary without any trouble.
Your proposal would in fact generate code to align stack when it's
not necessary. This would change the behaviour of
-fpreferred-stack-boundary, hurting performance and that's unacceptable
to me.
Ye, Joey
On Dec 18, 2007, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Alexandre Oliva [EMAIL PROTECTED] writes:
A plan to fix local variable debug information in GCC
by Alexandre Oliva [EMAIL PROTECTED]
2007-12-18 draft
Thank you for writing this. It makes an enormous difference.
NP. Thanks for
On Dec 18, 2007, Daniel Berlin [EMAIL PROTECTED] wrote:
int c = z;
whatever0(c);
c = x;
Because you have added information you have no way of knowing.
How exactly did you compute that the call *definitely sets c to the
value of z_0*, and definitely sets the value of c to x_2.
Err... I
-Original Message-
From: Steven Bosscher [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 18, 2007 6:00 PM
To: GCC
Cc: [EMAIL PROTECTED]
Subject: Regression count, and how to keep bugs around forever
Maybe it is just me, but I find it very annoying to have to wade
through
Joe Buck wrote:
On Wed, Dec 19, 2007 at 01:25:19AM +, Paul Brook wrote:
Ok. I did check the GCC bugzilla help pages, and they don't mention
SUSPENDED
at all :-)
I wrote:
Patches welcome, as they say.
Never mind; see
http://gcc.gnu.org/bugs/management.html
On Dec 18, 2007, Daniel Berlin [EMAIL PROTECTED] wrote:
Consider PRE alone,
If your debug statement strategy is move debug statements when we
insert code that is equivalent
Move? Debug statements don't move, in general. I'm not sure what you
have in mind, but I sense some disconnect here.
On 12/19/07, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Dec 18, 2007, Daniel Berlin [EMAIL PROTECTED] wrote:
Consider PRE alone,
If your debug statement strategy is move debug statements when we
insert code that is equivalent
Move? Debug statements don't move, in general. I'm not
I have been porting tic54x to gcc. I use gcc-4.2.2 version. I write some
simplest c54x.h and c54x.c and a empty md, and I
I think the answer is right there
^^
IIRC what you need as a bare minimum as a whole
--- Comment #9 from bonzini at gnu dot org 2007-12-18 08:05 ---
Uros mentioned offlist that he wanted to hijack fwprop to always propagate
stack slots into instructions.
It would be a relatively useful piece of infrastructure to have a flag in MEMs
that marks on-stack MEMs, because
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-12-18 08:10
---
It would be a relatively useful piece of infrastructure to have a flag in MEMs
that marks on-stack MEMs, because other MEMs definitely must not be propagated
blindly.
Depending on your needs, MEM_NOTRAP_P
--- Comment #20 from bonzini at gnu dot org 2007-12-18 08:35 ---
Eric, would you please take a look at my counter-proposal and commit it if it
works?
--
bonzini at gnu dot org changed:
What|Removed |Added
This test was fine with revision 130991 but broken with mainline now. This is
what I get now :
[~] gcc pr26943-2.c -lgomp
[~] ./a.out
zsh: abort ./a.out
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc/4.3.0
--- Comment #1 from jakub at gcc dot gnu dot org 2007-12-18 10:52 ---
This test relies on being compiled wit -fopenmp (as a bunch of other tests do).
Why are you compiling it without it?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2007-12-18 11:39 ---
IMHO it can validly print 7, 14, 21 or 28. See OpenMP 2.5, section 2.5.2:
The method of scheduling the structured blocks among threads in the team is
implementation defined.
Also, data sharing clause is sections
--- Comment #12 from hubicka at gcc dot gnu dot org 2007-12-18 11:41
---
But I wonder what would be the best way to add the PHI nodes. We really
shouldn't do mark_sym_for_renaming on underlying decl, perhaps create a dummy
decl, let intossa create PHIs etc. for it, then change the
--- Comment #1 from ludovic at ludovic-brenta dot org 2007-12-18 12:10
---
Actually, the declaration of x2 is illegal; GNAT is correct in rejecting it.
The declaration of T3 is legal and incorrectly rejected. The error messages
are:
gnatmake -gnat05 pak1-pak3.ads
gcc-4.1 -c -gnat05
--- Comment #47 from steven at gcc dot gnu dot org 2007-12-18 13:46 ---
(From update of attachment 10017)
Patch is obsolete because it was commited.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ubizjak at gmail dot com 2007-12-18 13:47 ---
Generated code for a similar example is just plain stupid:
--cut here--
int test(long long a, long long b)
{
return a * b;
}
--cut here--
gcc -O3:
test:
pushl %ebp
movl%esp, %ebp
--- Comment #6 from aph at gcc dot gnu dot org 2007-12-18 14:06 ---
Subject: Bug 27643
Author: aph
Date: Tue Dec 18 14:06:15 2007
New Revision: 131036
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131036
Log:
2007-12-18 Andrew Haley [EMAIL PROTECTED]
PR java/27643
-20071218/build-default-i686-pc-linux-gnu/i686-pc-linux-gnu/./libgomp/.libs:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/gcc:.:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/i686-pc-linux-gnu/./libgomp/.libs:/var/pisi/gcc
Default assert.h on Tru64 5.1 has an include guard around the whole include in
format of:
#ifndef __ASSERT_H_
#define __ASSERT_H_
... rest of the code ...
#endif /* __ASSERT_H_ */
This leads to a behavior different from the one described in the standard,
where assert.h is claimed to be the
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-18 14:30 ---
On i386 you need also -march=i486 or higher, i386 doesn't have instructions
for atomic stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34519
--- Comment #4 from ismail at pardus dot org dot tr 2007-12-18 14:39
---
[~] gcc -fopenmp -march=i486 pr26943-2.c -lgomp
[~] ./a.out
[~]
works fine like this, I don't know why it fails in the tests. Hmm wonder if
--with-cpu=generic could affect this? This is a 4 CPU Xeon machine
--- Comment #7 from dominiq at lps dot ens dot fr 2007-12-18 15:11 ---
The patch in comment #6 fix the problem without regression on PPC/Intel
Darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34413
--- Comment #4 from rask at gcc dot gnu dot org 2007-12-18 15:31 ---
Subject: Bug 33474
Author: rask
Date: Tue Dec 18 15:30:57 2007
New Revision: 131037
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131037
Log:
PR target/33474
* config/bfin/bfin.c
I am using GCC (4.3 - 20071130 snapshot) and getting the null pointer
exception.
Exception in thread [EMAIL PROTECTED]
java.lang.CloneNotSupportedExcept
ion
at java.lang.Object.clone
at gnu.javax.net.ssl.provider.SSLEngineImpl.setEnabledProtocols
--
Summary: SSLEngine - Clone
--- Comment #5 from rask at gcc dot gnu dot org 2007-12-18 15:58 ---
Fixed with revision 131037.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from bonzini at gnu dot org 2007-12-18 16:01 ---
The problem in comment #11 is that GCC generates a widening multiply, and
cannot remove the DImode operations until after register allocation (!). While
the root cause is a deficiency in RTL-level DCE, I suggest filing a
--- Comment #13 from jakub at gcc dot gnu dot org 2007-12-18 16:39 ---
I think tree level does the right thing, TER fixes this up and expand_expr
is called with
return (int) (b * a)
Later on expand_expr is called with
mult_expr 0x2e9032c0
type integer_type 0x2e937840 long
For
int test(long long a, long long b)
{
return a * b;
}
GCC generates a widening multiply, and cannot remove the DImode operations
until after register allocation. This causes unnecessary splits.
This could be fixed on the tree level by folding to (int)a * (int)b, or
alternatively in
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #14 from bonzini at gnu dot org 2007-12-18 16:50 ---
The bug with 64*64-32 multiplication is now PR34522.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
--- Comment #1 from bonzini at gnu dot org 2007-12-18 16:58 ---
Prototype untested patch. Produces
movl12(%esp), %eax
imull 4(%esp), %eax
ret
on the testcase.
Index: expr.c
===
--- expr.c
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2007-12-18
17:14 ---
Andreas,
Can't we duplicate the existing code in darwin.S, darwin_closure.S,
ffi_darwin.c and sysv.S and wrapper it with a test for __powerpc64__ as a
starting point. I think if we at least get
--- Comment #1 from csm at gnu dot org 2007-12-18 17:45 ---
A CloneNotSupportedException is not a null pointer exception.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34521
checking whether sigaltstack is declared... yes
checking for struct tms... yes
checking for clock_t... yes
checking for .preinit_array/.init_array/.fini_array support... no
checking if mkdir takes one argument... no
Unknown CPU used in --with-cpu=arm926ejs
make[2]: *** [configure-stage1-gcc] Error
--- Comment #2 from csm at gnu dot org 2007-12-18 18:08 ---
Created an attachment (id=14790)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14790action=view)
Test case
Can you try running this test program in your setup? We should confirm first
that this isn't a regression in GCJ
--- Comment #15 from ubizjak at gmail dot com 2007-12-18 18:20 ---
(In reply to comment #7)
mull%ebx
leal(%ecx,%edx), %esi ; what the heck, a simple addl could do!
movl%esi, %edx
Something disturbs RA to emit two DImode moves:
(insn:HI 10 36
--- Comment #16 from ubizjak at gmail dot com 2007-12-18 18:33 ---
(In reply to comment #15)
Note two moves [(insn 36) and (insn 37)] around (insn 12).
Bah. This is the correct sequence, around (insn 10) that seems to be the root
of all problems:
(insn:HI 9 8 36 2 m.c:2 (parallel [
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-12-18 18:51 ---
I do not see a way how to fix this in 4.3, other than disabling vectorizer when
parallelization is enabled, or vice versa.
--
rakdver at gcc dot gnu dot org changed:
What|Removed
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #13 from hubicka at gcc dot gnu dot org 2007-12-18 18:54
---
Sorry, my last comment was about different inliner issue that seems to be gone
now. I guess easiest way around would be to initialize to 0 at the beggining
of inlined function body? This happens only for
--- Comment #5 from andreast at gcc dot gnu dot org 2007-12-18 19:07
---
Jack,
you can try, but I think it is a bit wasted time. Well, depends on how long the
process takes to get the patches from apple.
[wolfram:gcc/head/objdir] andreast% file /usr/lib/libffi.dylib
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|bootstrap |other
GCC
--- Comment #7 from spop at gcc dot gnu dot org 2007-12-18 19:40 ---
Subject: Bug 34123
Author: spop
Date: Tue Dec 18 19:40:35 2007
New Revision: 131040
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131040
Log:
2007-12-18 Sebastian Pop [EMAIL PROTECTED]
PR
--- Comment #8 from spop at gcc dot gnu dot org 2007-12-18 19:42 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
In the following code, libstdc++'s debug mode does not catch the use of a
potentially invalidated std::string iterator.
#define _GLIBCXX_DEBUG
#define _GLIBCXX_DEBUG_PEDANTIC
#include string
#include vector
#include iostream
int main()
{
typedef std::string S;
S s (3,
--- Comment #4 from steven at gcc dot gnu dot org 2007-12-18 19:44 ---
Patch was pre-OKed. Andrew, what happened next, did you commit it and is this
bug fixed already?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-12-18 19:52 ---
(In reply to comment #4)
Patch was pre-OKed. Andrew, what happened next, did you commit it and is this
bug fixed already?
Hmm, I had not got already to creating a new patch. This weekend should be a
good
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28011
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 19:58 ---
Nothing happened for almost two years.
Perhaps we should close this kind of bug-goes-nowhere bug as WONTFIX?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953
--- Comment #7 from steven at gcc dot gnu dot org 2007-12-18 19:59 ---
3.5 years with no progress whatsoever.
Should probably closed as WONTFIX?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18346
--- Comment #1 from pcarlini at suse dot de 2007-12-18 20:00 ---
Did you read the documentation?
http://gcc.gnu.org/onlinedocs/libstdc++/ext/debug_mode.html
in a nutshell, our design doesn't provide safe iterators for basic_string.
--
pcarlini at suse dot de changed:
--- Comment #33 from steven at gcc dot gnu dot org 2007-12-18 20:02 ---
Honza, since you re-opened this, perhaps you can give new timings?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2007-12-18 20:06 ---
As of today this is an ICE at least on Cygwin. cc1 segfaults during inlining.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
--- Comment #26 from steven at gcc dot gnu dot org 2007-12-18 20:09 ---
Bring back on the radar for the release manager.
New timings would be much appreciated. Anyone?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 20:20 ---
Outline/plan for a fix here:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00354.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21312
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 20:23 ---
Not sure what to do with this one. Rainer, can you live with WONTFIX? :-)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2007-12-18 20:29 ---
See http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01406.html for recent test
suite results. The first three failures are gone, as observed by Andreas too.
The largefile.c failures still exist. But as Andrew
1 - 100 of 154 matches
Mail list logo
