--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-24 04:19 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from mark at codesourcery dot com 2006-06-24 04: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:
> --- Comment #3 from drow at gcc dot gnu dot o
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-24 03:55 ---
(In reply to comment #3)
> Subject: Re: ICE with pointer to member function initializer
> and cast to a different type
> That should be legal ISO c++. That type of constuct is used actually
> pretty common in spec
--- Comment #3 from donour at cs dot unm dot edu 2006-06-24 03:45 ---
Subject: Re: ICE with pointer to member function initializer
and cast to a different type
pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-24 02:03
> ---
>
--- Comment #3 from drow at gcc dot gnu dot org 2006-06-24 02:52 ---
No, that was not the consensus, and I reported this bug specifically because
the coding practices used in libstdc++ cause problems with cancellation...
progress was being made, the last time I read c++-pthreads, but tra
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-24 02:37 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-24 02:03 ---
I cannot figure out if this is undefined code or not but it should not at least
ICE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-24 01:53 ---
Confirmed, fixed at least on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-24 01:52 ---
Fixed at least on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-24 01:49 ---
Lets close it as fixed then. Thanks.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gmail dot com 2006-06-24 01:48 ---
Subject: Re: loses type in debug info
On Jun 23, 2006, at 12:57 PM, Ilya N. Golubev wrote:
>
>> Next time please don't paste the preprocessed source in gccbug or
>> in the
>> comments section in bugzilla.
>
> Please
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-24 01:43 ---
Actually I think the consensus was talk to the C++ and POSIX standards comittee
about this case.
It is not just libstdc++ that could cause problems but any program that uses
throw() or catch(...) {/* fall through
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-06-24 00:13 ---
Subject: Bug 27984
Author: bkoz
Date: Sat Jun 24 00:13:08 2006
New Revision: 114955
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114955
Log:
2006-06-23 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstd
--- Comment #4 from pcarlini at suse dot de 2006-06-23 23:59 ---
Just tested and seems fixed indeed. Thanks a lot!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28138
--- Comment #5 from seongbae dot park at gmail dot com 2006-06-23 23:55
---
Looks like this indeed is a duplicate of 27657.
In toplev.c:
1013 cgraph_varpool_assemble_pending_decls ();
...
1040 (*debug_hooks->finish) (main_input_filename);
dwarf2 finish ends up calling final.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-06-23 23:43 ---
Created an attachment (id=11737)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11737&action=view)
fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27984
--- Comment #1 from donour at cs dot unm dot edu 2006-06-23 23:14 ---
Created an attachment (id=11736)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11736&action=view)
demo of reported behavior
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28148
I have a very simple piece of code that will produce the following error:
--
test.C:5: internal compiler error: in output_constant, at varasm.c:4031
--
A simple code fragment to reproduce this bug is:
--
struct foo {
public:
virtual int bar(int);
};
void (foo::*__Virtual__foo__Var1)() = (void
--- Comment #2 from sje at gcc dot gnu dot org 2006-06-23 21:58 ---
Subject: Bug 28114
Author: sje
Date: Fri Jun 23 21:58:25 2006
New Revision: 114953
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114953
Log:
PR c++/28114
* name-lookup.c (pushtag): Return if we
--- Comment #4 from sje at gcc dot gnu dot org 2006-06-23 21:53 ---
Subject: Bug 27019
Author: sje
Date: Fri Jun 23 21:53:36 2006
New Revision: 114952
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114952
Log:
PR c++/27019
* typeck2.c (process_init_constructor_ar
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-06-23 21:31 ---
It should be. Let's wait for new testresults.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28138
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-23 21:29 ---
Is this fixed now after Richard G.'s newest patch?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-23 21:15 ---
trying to reduce it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28146
--- Comment #4 from kargl at gcc dot gnu dot org 2006-06-23 21:12 ---
Applied to trunk. I'll apply this to 4.1 in a few days.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2006-06-23 21:05 ---
Subject: Bug 27981
Author: kargl
Date: Fri Jun 23 21:05:04 2006
New Revision: 114950
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114950
Log:
2006-06-23 Steven G. Kargl <[EMAIL PROTECTED]>
PR fort
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-06-23 21:03 ---
Ok, looks like it is s390 specific because I can reproduce it with
gcc version 4.1.2 20060531 (prerelease)
/usr/lib/gcc/s390-suse-linux/4.1.2/cc1 -fpreprocessed t.i -quiet -dumpbase t.i
-march=z900 -mtune=z9-109 -m31
--- Comment #4 from list+gcc-bugzilla at meyering dot net 2006-06-23 20:26
---
Created an attachment (id=11735)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11735&action=view)
Here's the output of running gcc -I.. -I. -g -O2 ~/j.c -v
Here's the output of running gcc -I.. -I. -g
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-06-23 20:12 ---
It produces
38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6e1da274edebfe76f65fbd51ad2f14898b95b
for me with -O and -O2. Can you post the output of
gcc -I.. -I. -g -O2 ~/j.c -v
?
--
http://gcc.gnu
--- Comment #2 from list+gcc-bugzilla at meyering dot net 2006-06-23 19:58
---
Created an attachment (id=11734)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11734&action=view)
preprocessed input
Here's the same j.i file, as an attachment.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #2 from gin at mo dot msk dot ru 2006-06-23 19:57 ---
Subject: Re: loses type in debug info
As for marking the bug as already reported, this seems plausible to
me. Confirming that `.i' sent in my bug report uses "lost" type in
exactly the same way as test code in PR 21391;
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-23 19:50 ---
Can you please attach the preprocessed source rather than pasting it in? (I
know there was no way to do so on the new bug page)
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28146
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-23 19:03 ---
(In reply to comment #4)
> It works now.
> First i installed gcc 3.4.6 and used that compiler (before that i used 3.2.1).
No more likely 3.2.1 was miscompiling part of 4.1.1.
If you did not use "make bootstrap", that
--- Comment #4 from seongbae dot park at gmail dot com 2006-06-23 18:43
---
The problem is causedby the extra DW_AT_const_value.
4.1.0 generates the following dwarf entry for auxmap:
<1>: Abbrev Number: 31 (DW_TAG_variable)
DW_AT_name: (indirect string, offset: 0x35e): au
--- Comment #4 from info at pion dot xs4all dot nl 2006-06-23 18:31 ---
It works now.
First i installed gcc 3.4.6 and used that compiler (before that i used 3.2.1).
Then i used the following configuration:
Target: hppa2.0w-hp-hpux11.00
Configured with: /*/gcc-4.1.1/conf
--- Comment #3 from seongbae dot park at gmail dot com 2006-06-23 18:26
---
I'm able to reproduce the problem with 4.2.0 on linux/x86.
valgrind-3.2.0/memcheck/mc_main.c has
359 static AuxMapEnt hacky_auxmaps[N_AUXMAPS];
...
362 static AuxMapEnt* auxmap = &hacky_auxmaps[
--- Comment #1 from mark at codesourcery dot com 2006-06-23 18:14 ---
Subject: Re: New: libstdc++ and pthread cancellation
are incompatible (at least with NPTL)
drow at gcc dot gnu dot org wrote:
> On targets using a recent version of glibc and the NPTL threading package, if
> you c
(This is not a new problem, and everyone involved is familiar with it. I was
just surprised not to find a record of it in bugzilla.)
On targets using a recent version of glibc and the NPTL threading package, if
you cancel a thread using pthread_cancel while it is writing to an ostream,
you'll get
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-06-23 17:55 ---
Created an attachment (id=11733)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11733&action=view)
patch
I'm currently testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-06-23 17:11
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-06-23 17:10
---
Subject: Bug 28112
Author: reichelt
Date: Fri Jun 23 17:10:11 2006
New Revision: 114943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114943
Log:
PR c++/28112
* parser.c (cp_parser_attribu
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-23 17:06
---
Subject: Bug 28112
Author: reichelt
Date: Fri Jun 23 17:06:13 2006
New Revision: 114942
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114942
Log:
PR c++/28112
* parser.c (cp_parser_attribu
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-06-23 17:02
---
Subject: Bug 28112
Author: reichelt
Date: Fri Jun 23 17:02:38 2006
New Revision: 114941
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114941
Log:
PR c++/28112
* parser.c (cp_parser_attribu
--- Comment #9 from chris at bubblescope dot net 2006-06-23 16:47 ---
I just tried preprocessing vector, as an example. There isn't any obvious
low-hanging fruit. The major problem is that most of the C standard libary ends
up getting dragged in.
I think a better goal would be to make p
--- Comment #2 from gary at intrepid dot com 2006-06-23 16:44 ---
I agree this is definitely an enhancement, but will note the following:
1. On Fedora Core 5, x86_64, I was able to successfully link and run
a null program (written in assembly) that initializes thread local
'ptr' that po
According to:
http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html#25363
java conversions of floating point values to integer types smaller than int
should be done by converting to integer first, and then from int to the target
type. While the former conversion is done with
--- Comment #8 from gdr at integrable-solutions dot net 2006-06-23 16:35
---
Subject: Re: header dependencies
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| I did implement a version of this myself, basically by writing a
| mapper around each container that did a few st
--- Comment #5 from sje at gcc dot gnu dot org 2006-06-23 16:22 ---
Subject: Bug 28084
Author: sje
Date: Fri Jun 23 16:21:54 2006
New Revision: 114939
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114939
Log:
PR target/28084
* inclhack.def (hpux_extern_errno): N
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-06-23 16:08
---
The ICE
internal compiler error: can't find class$
has been fixed on mainline (see PR 11468), but the ICE mentioned in
commment #5 is still present.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11006
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-06-23 16:05
---
Fixed on mainline.
Instead of
bug.cc:55: internal compiler error: can't find class$
we now get a regular error with more information:
bug.cc:55: error: can't find 'class$' in 'MyClass'
--
reichelt at gcc
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-06-23 16:00
---
Subject: Bug 11468
Author: reichelt
Date: Fri Jun 23 15:59:51 2006
New Revision: 114937
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114937
Log:
PR c++/11468
* init.c (build_new_1): Handl
--- Comment #10 from pault at gcc dot gnu dot org 2006-06-23 15:43 ---
Now for the hard work of writing simplify_transfer!
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-23 15:42 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pault at gcc dot gnu dot org 2006-06-23 15:41 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-23 15:40 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-23 15:40 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from chris at bubblescope dot net 2006-06-23 15:33 ---
(In reply to comment #4)
> Subject: Re: header dependencies
>
> On Monday 19 June 2006 11:29, pcarlini at suse dot de wrote:
> > --- Comment #1 from pcarlini at suse dot de 2006-06-19 09:29
> > Ok, let's see wha
--- Comment #29 from krebbel at gcc dot gnu dot org 2006-06-23 15:16
---
On s390x c974001, c974013 and cb20001 run into a infinite loop with current
mainline. At least the first two look related - not sure about the third.
--
krebbel at gcc dot gnu dot org changed:
What
Well, I see gcc.c-torture/execute/frame-address.c execution FAIL on sparc64,
linux and solaris,
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00985.html,
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00962.html, and
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00907.html.
I still see it
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-23 13:01 ---
Additional remarks (which I forget to make):
Both cases are valid Fortran as:
(1) If the length of 'variable' is less than that of 'expr', the value of
'expr' is truncated from the right until it
--- Comment #3 from info at yourkit dot com 2006-06-23 12:28 ---
I've discovered that if only C language is specified and --disable-libssp is
added (to work around bug #25035) then cross complier can be successfully
built. So the problem somewehere in C++ part.
--
http://gcc.gnu.org
--- Comment #9 from info at yourkit dot com 2006-06-23 12:09 ---
I can confirm this bug.
target=i386-pc-solaris2.10;
host=i386-pc-linux-gnu;
GCC 4.1.1;
BinUtils 2.16.1
Checking multilib configuration...
/bin/sh /home/anton/tmp/gcc/gcc-4.1.1/mkinstalldirs i386-pc-solaris2.10/libssp
;
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-23 11:57 ---
Fixed in 3.4.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple -mn
--- Comment #2 from info at yourkit dot com 2006-06-23 10:31 ---
I've charged target from "i386-pc-solaris2.10" to "i386-pc-solaris2.9"
and successfully built cross-compiler, but the resulting compiler
cannot produce 64bit binaries (as expected, because Solaris9 on Intel
is a 32bit).
I
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-06-23 10:06 ---
Newer gcc always inline _static_ functions that are used _once_ into their only
caller (regardless of being declared inline or not). You can disable this
behavior with -fno-inline-functions-called-once.
All gcc inl
--- Comment #3 from info at pion dot xs4all dot nl 2006-06-23 09:59 ---
1) I installed the patches which are mentioned in the installation
documentation
2) Installed newer binutils
3) Checked on an other host
4) I have checked 4.1.0 which has the same problem
5) Could you give the detail
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-06-23 09:57
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-06-23 09:57
---
Subject: Bug 28045
Author: rguenth
Date: Fri Jun 23 09:57:37 2006
New Revision: 114930
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114930
Log:
2006-06-23 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-06-23 09:52 ---
Subject: Bug 28045
Author: rguenth
Date: Fri Jun 23 09:52:40 2006
New Revision: 114929
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114929
Log:
2006-06-23 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #6 from tanaka at personal-media dot co dot jp 2006-06-23
09:52 ---
Please answer my question again.
It can not be distinguished between a function, which specified
__inline__ and an another function, which is not specified __inline__,
after gcc-3.4.
This is sample.
/**
--- Comment #5 from dannysmith at users dot sourceforge dot net 2006-06-23
08:27 ---
Patch committed to trunk.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--
--- Comment #4 from dannysmith at gcc dot gnu dot org 2006-06-23 08:25
---
Subject: Bug 27789
Author: dannysmith
Date: Fri Jun 23 08:25:33 2006
New Revision: 114927
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114927
Log:
PR target/27789
* config/i386/winnt.c
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-06-23
07:04 ---
It should be noted that encasing the two subroutines in a module produces the
correct error
In file pr22571.f90:15
call a(q)
1
Error: Type/rank mismatch in argument 'p' at (1)
The proble
74 matches
Mail list logo
