--- Comment #11 from jason at redhat dot com 2006-08-01 07:10 ---
Subject: Re: C++ (throw() and catch(...) {/* fall through
*/ } ) and pthread cancellation are incompatible (at least with NPTL)
drow at gcc dot gnu dot org wrote:
Just making sure I understand - catch (...) { foo();
--- Comment #8 from patchapp at dberlin dot org 2006-08-01 11:45 ---
Subject: Bug number PR tree-optimizations/26969
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg6.html
--
--- Comment #2 from pcarlini at suse dot de 2006-08-01 12:02 ---
The problem cannot be reproduced in mainline, only in 4_1-branch. Seems an
rtl-optimization bug: for the below slightly reduced testcase t97.final_cleanup
is identical in mainline and 4_1-branch:
#include string
#include
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-08-01 12:18 ---
-O2 -finline-functions is sufficient to reproduce the problem on the branch, or
if you mark CfgSchema::CfgSchema(const std::string ) 'inline'.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #12 from drow at gcc dot gnu dot org 2006-08-01 13:02 ---
Subject: Re: C++ (throw() and catch(...) {/* fall through */ } ) and pthread
cancellation are incompatible (at least with NPTL)
On Tue, Aug 01, 2006 at 07:10:53AM -, jason at redhat dot com wrote:
[What does
--- Comment #10 from drow at gcc dot gnu dot org 2006-08-01 14:24 ---
Subject: Bug 23336
Author: drow
Date: Tue Aug 1 14:23:58 2006
New Revision: 115853
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115853
Log:
gcc/
PR debug/23336
* c-typeck.c
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-08-01 15:34 ---
After a closer investigation, there indeed seems to be a problem in
chrec_convert, I am preparing a patch.
Nevertheless, the code in VRP still needs fixing -- the problem might still be
reproduced even with a
--- Comment #1 from sje at gcc dot gnu dot org 2006-08-01 16:31 ---
Subject: Bug 28256
Author: sje
Date: Tue Aug 1 16:31:40 2006
New Revision: 115856
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115856
Log:
PR c++/28256
* decl.c (check_initializer): Check for 1
--- Comment #2 from sje at gcc dot gnu dot org 2006-08-01 16:45 ---
Subject: Bug 28432
Author: sje
Date: Tue Aug 1 16:45:14 2006
New Revision: 115857
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115857
Log:
PR c++/28432
* decl2.c (check_classfn): Remove early
--
sje at cup dot hp dot com changed:
What|Removed |Added
CC||sje at cup dot hp dot com
AssignedTo|unassigned at gcc dot gnu
--- Comment #6 from spkelly at andrew dot cmu dot edu 2006-08-01 16:48
---
Okay. I find it a little odd that I was at first still geting the stdlibc++
error when I specified --enable-languages=c (and, for the reference of anyone
else, --disable-libssp), but after poking around and
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-08-01 17:15 ---
Subject: Bug 28542
Author: tkoenig
Date: Tue Aug 1 17:15:04 2006
New Revision: 115858
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115858
Log:
2006-08-01 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-08-01 17:26 ---
*sigh* I got the PR number wrong when committing a fix for PR 28452.
Sorry 'bout that.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28542
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-08-01 17:30 ---
Subject: Bug 28452
Author: tkoenig
Date: Tue Aug 1 17:29:50 2006
New Revision: 115859
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115859
Log:
2006-08-01 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #14 from dj at redhat dot com 2006-08-01 17:35 ---
First off, I was mostly just explaining that assertion.
Second, I think that this code can be a valid initializer - the value
we initialize to is, in this case, an 8 byte value which contains the
least significant 4 bytes
Unlike other tools such as gdb that need source files, gcov does not store the
absolute path. As a result, gcov must be run in the same directory in which gcc
was invoked. This makes it particularly difficult to generate coverage reports
for separately compiled libraries that have separate src/
--- Comment #8 from sje at cup dot hp dot com 2006-08-01 18:22 ---
The time that this started occurring looks to be about the time that Maxim was
making scheduling changes for IA64 speculation. Maxim could you look at this
bug and see if it is related to any of your changes to IA64
--- Comment #15 from mmitchel at gcc dot gnu dot org 2006-08-01 18:27
---
DJ --
Thanks for the detailed comments. I understand that the assertion is guarding
against some cases where we may silently generate wrong code (as with the
situation with pointers on the m16c). However,
--- Comment #16 from dj at redhat dot com 2006-08-01 18:37 ---
I think it's acceptable to temporarily disable that assertion for this release,
but (1) we should test that code on both big and little endian 64 bit machines
and see if it produces wrong code (perhaps with a larger offset
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-08-01 20:05
---
Subject: Bug 28523
Author: mmitchel
Date: Tue Aug 1 20:04:57 2006
New Revision: 115862
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115862
Log:
PR c++/28523
* tree.c (stabilize_expr):
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-08-01 20:05
---
Subject: Bug 28523
Author: mmitchel
Date: Tue Aug 1 20:05:49 2006
New Revision: 115863
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115863
Log:
PR c++/28523
* tree.c (stabilize_expr):
--- Comment #9 from andreast at gcc dot gnu dot org 2006-08-01 20:24
---
Patch is here:
http://gcc.gnu.org/ml/java-patches/2006-q3/msg00249.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546
--- Comment #3 from laurent dot deniel at free dot fr 2006-08-01 20:55
---
Newer gcc/gcov version (3.4.5 and 4) again changed the behavior, it is no
longer possible to do gcov if :
- the .gcda file is empty
- there is no .gcda file
In the later case at least, gcov invoked on the .c
--- Comment #13 from jason at gcc dot gnu dot org 2006-08-01 21:08 ---
Created an attachment (id=11988)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11988action=view)
NPTL patch for sticky cancellation
Revised, tested patch with testcase.
So, there are 3 patches here, which are
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-08-01 21:33
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
building with --enable-objc-gc now succeeds, but libobjc_gc isn't linked with
the gc convenience library
Matthias
--
Summary: building with --enable-objc-gc doesn't link with the gc
convenience library
Product: gcc
Version: 4.2.0
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-08-01 23:45
---
Subject: Bug 28259
Author: reichelt
Date: Tue Aug 1 23:45:11 2006
New Revision: 115866
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115866
Log:
PR c++/28250
PR c++/28257
PR
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-08-01 23:45
---
Subject: Bug 28267
Author: reichelt
Date: Tue Aug 1 23:45:11 2006
New Revision: 115866
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115866
Log:
PR c++/28250
PR c++/28257
PR
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-08-01 23:45
---
Subject: Bug 28250
Author: reichelt
Date: Tue Aug 1 23:45:11 2006
New Revision: 115866
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115866
Log:
PR c++/28250
PR c++/28257
PR
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-08-01 23:45
---
Subject: Bug 28257
Author: reichelt
Date: Tue Aug 1 23:45:11 2006
New Revision: 115866
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115866
Log:
PR c++/28250
PR c++/28257
PR
--- Comment #11 from reichelt at gcc dot gnu dot org 2006-08-01 23:47
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-08-01 23:49
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-08-01 23:50
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-08-01 23:51
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from mark at codesourcery dot com 2006-08-02 03:29 ---
Subject: Re: [4.0/4.1/4.2 regression] ICE in ia64_expand_move,
at config/ia64/ia64.c:1088
steven at gcc dot gnu dot org wrote:
Why is this a P1 regression? ia-64 is not a primary platform.
True -- but IA64 is
--- Comment #7 from ksharenkov at ya dot ru 2006-08-02 03:47 ---
Hello.
Now I can say more about this problem. before code listing
I am sure that problem in template instantiation.
code if CBaseSeat::CBaseSeat() id used deeply in templates
holderT1 contains T1 which contains of
36 matches
Mail list logo
