Hi,
The code at the bottom compiled with this line
gcc -fprofile-arcs -O2 -c kk.cpp
causes this crash
gcc: Internal error: Segmentation fault (program cc1plus)
It occurs on both:
* Suse 11.0 with gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch
revision 135036] (rpms: gcc43-4.3.
Hi,
The code at the bottom compiled with this line
gcc -fprofile-arcs -O2 -c kk.cpp
causes this crash
gcc: Internal error: Segmentation fault (program cc1plus)
It occurs on both:
* Suse 11.0 with gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch
revision 135036] (rpms: gcc43-4.3.
Hello,
We have following original Cisco,Card,GBIC/SFP,WIC,cables items for sale
If you are interested, pls feel free to contact me.
example of the products:
CWDM-SFP-1G 38dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm
WS-G5483,
GLC-SX-MM
SFP-GE-L
WS-G5487,
WS-G5484,
WS-G5486
--- Comment #7 from paolo dot carlini at oracle dot com 2008-07-09 11:13
---
(In reply to comment #6)
> Subject: Re: Simple std::bind use causes warnings with -Wextra
>
> paolo dot carlini at oracle dot com wrote:
>
> > Thanks Tom. In fact, yesterday I was writing without remembering
Have to take place implicit convesion type1 to type2 to sss in function main()
in string:
sss xxx = x;
But it works (workaround?) for only the following syntax:
sss xxx( x );
All addition info follows (test4.ii includes all source required):
[EMAIL PROTECTED]:~/test$ g++ -v
Using built-in specs
--- Comment #4 from paolo dot carlini at oracle dot com 2008-07-09 11:18
---
(In reply to comment #3)
> a) The problem does not exist on gcc 4.2 (Intel), but I do not have a
> 4.2 PPC x-compiler - only 4.0. So I cannot confirm a x-compile issue in 4.2.
Ok.
> b) It would be very helpf
--- Comment #1 from schwab at suse dot de 2008-07-09 11:41 ---
Only a single user-defined conversion is allowed in an implicit conversion
sequence, but the copy-initialization would require two.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #2 from jia3ep at gmail dot com 2008-07-09 12:30 ---
Please, look at the following code. There are the same conversions, but it's
compiles and works without any errors. In the following sample takes place
implicit conversion 'int' to 'double' and then copy-initialization(that
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-09 12:32 ---
*** Bug 36768 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36767
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-09 12:32 ---
*** This bug has been marked as a duplicate of 36767 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-09 12:53 ---
This one blows the stack recursing through
#40147 0x0065fa9a in mangle_decl (decl=0x7f398018d0a0)
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/cp/mangle.c:2655
2655 tree id = get_identifier_nocopy
--- Comment #3 from schwab at suse dot de 2008-07-09 13:06 ---
int->double is not a user-defined conversion, but a standard conversion.
--
schwab at suse dot de changed:
What|Removed |Added
--
--- Comment #5 from brtnfld at hdfgroup dot org 2008-07-09 14:24 ---
The behavior conforms to the standard:
For the C_LOC(X) function X must be interpretable and interpretable for a
character the standard says:
15.2.1 Interoperability of intrinsic types
A Fortran intrinsic
4 type wit
--- Comment #8 from mmitchel at gcc dot gnu dot org 2008-07-09 14:28
---
Paolo --
You're absolutely right; I'd not thought about the orthogonality between what
the library should do and how the compiler should behave. I agree that the
patch is correct; go ahead check it in.
I was als
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-07-09 14:49 ---
(In reply to comment #3)
> > b = a(1:12)
> > Error: Different shape for array assignment at (1) on dimension 1 (1 and 12)
> > ? I don't have that many patches left.
>
> Hmm, I currently get the same (with all gfortr
GCC fails to generate efficient code for basic pointer operations.
Please have a look at this example:
***
test.c:
register int * src asm("r15");
int test( ){
src[1]=src[0];
src++;
}
main(){
}
***
compile the above with gcc -S -O3 test.c
shows us the following ASM output:
test:
m
Would it be possible to implement the non-standard extension for a character
argument X in C_LOC(X) to have a LEN >1. Most if not all the current Fortran
compilers provide this extension and I think it would be useful for other users
of gfortran as well.
The feature would allow:
CHARACTER(LEN=80,
Andreas Schwab and Gunther Nikl have pointed out that GCC
will incorrectly create "on purpose" impossible branch instructions.
Reason Summary:
- GCC is able to simplify certain compares.
- GCC seems to be unable to correctly rewrite the corresponding branch
instructions.
- GCC thereby generates br
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-07-09 15:31 ---
(In reply to comment #2)
> I am not sure the code is valid.
It's not, as -fbounds-check will tell you:
$ gfortran -fbounds-check foo.f90
$ ./a.out
At line 15 of file foo.f90
Fortran runtime error: Array bound mism
--- Comment #3 from lloyd at randombit dot net 2008-07-09 15:39 ---
Seemingly fixed in 4.3.0 or 4.3.1, closing this pr. Tested attached testcase
with
$ g++ -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/config
--- Comment #9 from paolo at gcc dot gnu dot org 2008-07-09 15:46 ---
Subject: Bug 36760
Author: paolo
Date: Wed Jul 9 15:45:50 2008
New Revision: 137660
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137660
Log:
/cp
2008-07-09 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-09 15:54
---
Fixed for mainline and 4.3.2. Many thanks again for the PR!
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #34 from lucier at math dot purdue dot edu 2008-07-09 16:05
---
Problem still exists with
euler-18% /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../mainline/configure --enable-checking=release
--with-gmp=/pkgs/gmp-
$ cat cshift.f90
program main
real, dimension(1,0) :: a,b
print *,size(a),size(b)
b = cshift(a,1)
end program main
$ gfortran cshift.f90
$ ./a.out
0 0
Segmentation fault (core dumped)
$ cat eoshift.f90
program main
real, dimension(1,0) :: a,b
print *,size(a),size(b)
When a nested function is compiled with -Wmissing-prototypes, the compiler
reports that the function lacks a prototype. A prototype with an `auto' storage
class silences the warning, but the usefulness of such a prototype is very
dubious.
The right solution seems to be to make the warning ignore n
--- Comment #1 from mj at ucw dot cz 2008-07-09 16:10 ---
Created an attachment (id=15877)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15877&action=view)
A test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36774
--- Comment #2 from mj at ucw dot cz 2008-07-09 16:11 ---
Can I do anything to help catch the bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33262
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-09 16:19 ---
Try with a recent GCC 4.2 version - GCC 4.2.4 is available. Also try
GCC 4.3.1. Try to reduce the testcase or at least make it executable and
arrange for it to abort () whenever the problem appears.
--
http://
--- Comment #10 from bangerth at dealii dot org 2008-07-09 17:04 ---
(In reply to comment #8)
> I was also trying to raise the issue of whether we think the warning is
> useful.
> If it's not practical to avoid the warning in the library, then I wonder if
> it's practical to avoid it o
--- Comment #11 from paolo dot carlini at oracle dot com 2008-07-09 17:11
---
Well I didn't want to reopen a discussion which I considered closed. But yes, I
also agree. And in case, we should have the change in 4_3-branch too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
--- Comment #12 from paolo dot carlini at oracle dot com 2008-07-09 17:13
---
And, by the way, I'm noticing the hard way that return by reference is the most
annoying case: if you want to suppress the warnings still deal appropriately
with references, it's a huge special casing everywhe
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
http:
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-09 18:22 ---
forward-propagate is causing some of the issues as shown by:
int *test(int *a ){
a[1]=a[0];
a++;
return a;
}
But using the register extension is causing the rest :). I would recommend
against using them in rea
--- Comment #13 from mark at codesourcery dot com 2008-07-09 19:08 ---
Subject: Re: Simple std::bind use causes warnings with -Wextra
bangerth at dealii dot org wrote:
> --- Comment #10 from bangerth at dealii dot org 2008-07-09 17:04 ---
> (In reply to comment #8)
>> I was al
--- Comment #14 from paolo dot carlini at oracle dot com 2008-07-09 19:20
---
(In reply to comment #13)
> is probably worth warning about, but maybe we ought to just skip this
> warning when instantiating a template function. In other words, warn at
> the point of original declaratio
--- Comment #15 from bangerth at dealii dot org 2008-07-09 19:22 ---
(In reply to comment #14)
> Ah, I didn't consider this option! Seems also trivial to implement, just
> remove
> completely the pt.c version of the warning and keep the one in decl.c. Then,
> over the next hours, if I d
--- Comment #16 from paolo dot carlini at oracle dot com 2008-07-09 19:34
---
Humm, this case
template
const int i(T);
is a little more tricky, let's what I can do...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
--- Comment #17 from paolo dot carlini at oracle dot com 2008-07-09 19:38
---
Ignore my last message, I had a spurious #pragma system header in my
experiments. Great ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760
--- Comment #6 from rsandifo at gcc dot gnu dot org 2008-07-09 20:04
---
Subject: Bug 35802
Author: rsandifo
Date: Wed Jul 9 20:03:40 2008
New Revision: 137670
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137670
Log:
gcc/
PR target/35802
* config/mips/mips.h
--- Comment #7 from rsandifo at gcc dot gnu dot org 2008-07-09 20:06
---
Subject: Bug 35802
Author: rsandifo
Date: Wed Jul 9 20:06:20 2008
New Revision: 137671
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137671
Log:
gcc/
PR target/35802
* config/mips/mips.h
--- Comment #8 from rsandifo at gcc dot gnu dot org 2008-07-09 20:08
---
Patch applied.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #2 from hjl dot tools at gmail dot com 2008-07-09 20:34 ---
The current fork/exec implementation is incorrect. Basically, it
re-implements system (). It is tricky to get it 100% correct. One
can take a look at system () source to see it him/herself. I think
we should call ch
I have found a bug in the gcc cross-compiler supplied in eldk-4.2 for
ppc_4xxFP-gcc. (Available from http://denx.de)
I noticed that the dumpe2fs program segfaulted on my sequoia powerpc evaluation
board (running Linux with nfs as the rootfs). After a lot of detective work, I
have produced a smal
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-09 20:48 ---
> The current fork/exec implementation is incorrect.
How is it incorrect? Since file could have spaces in it, using system is not
useful at all and even harder to do the correct thing. Really it does not use
syste
--- Comment #1 from sfalco at harris dot com 2008-07-09 20:49 ---
Created an attachment (id=15878)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15878&action=view)
Source code .i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36775
--- Comment #2 from sfalco at harris dot com 2008-07-09 20:50 ---
Created an attachment (id=15879)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15879&action=view)
Output of the -v option to the compiler
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36775
--- Comment #3 from sfalco at harris dot com 2008-07-09 20:51 ---
Created an attachment (id=15880)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15880&action=view)
Object dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36775
--- Comment #18 from paolo at gcc dot gnu dot org 2008-07-09 20:53 ---
Subject: Bug 36760
Author: paolo
Date: Wed Jul 9 20:52:45 2008
New Revision: 137672
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137672
Log:
/cp
2008-07-09 Paolo Carlini <[EMAIL PROTECTED]>
PR c
--- Comment #19 from paolo dot carlini at oracle dot com 2008-07-09 20:55
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
I first encountered this problem with GCC 4.3.1. With that compiler, the
program compiles fine (without warnings) but crashes at runtime. I tried a
recent snapshot of version 4.4 before submitting a bug report, and there an
internal compiler error is produced instead. So although this bug report is
--- Comment #1 from maksverver at geocities dot com 2008-07-09 20:57
---
Created an attachment (id=15881)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15881&action=view)
The test case that produces the output described in the bug summary.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-07-09 21:04 ---
This looks like an aliasing violation.What happens if you compile with -O2
-fno-strict-aliasing ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36775
--- Comment #5 from sfalco at harris dot com 2008-07-09 21:08 ---
That works. Here is what the generated code looks like. As you can see, r3 is
immediately stored to bb->list, which is what I would expect.
14c0: 48 04 05 d1 bl 10040a90 <[EMAIL PROTECTED]>
14c4:
--- Comment #4 from hjl dot tools at gmail dot com 2008-07-09 21:18 ---
(In reply to comment #3)
> > The current fork/exec implementation is incorrect.
>
> How is it incorrect? Since file could have spaces in it, using system is not
> useful at all and even harder to do the correct thi
Protected type cannot have access taken from its body.
The following should work:
protected type P is
procedure Foo;
end P;
protected body P is
procedure Foo is
Ptr : access P; -- here P denotes the type P
begin
Ptr := P'Access; -- here P denotes the
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Severity|enhancement |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36755
--- Comment #5 from hjl dot tools at gmail dot com 2008-07-09 21:24 ---
Here is one working implementation:
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/posix/system.c?rev=1.6&content-type=text/x-cvsweb-markup&cvsroot=glibc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
--- Comment #6 from schwab at suse dot de 2008-07-09 21:30 ---
extern __inline__ errcode_t ext2fs_get_mem(unsigned long size, void *ptr)
{
void **pp = (void **)ptr;
*pp = malloc(size);
[...]
}
[...]
{
ext2_u32_list bb;
errcode_t retval;
retval = ext2fs_get_mem(sizeof(struct ext2_s
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-07-09 21:50 ---
Not a bug as the code violates aliasing rules.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Gcc has a versatile set of warning/error flags that let one tune its behavior,
but there is one thing that it seems is currently not supported: the ability to
have gcc abort on the first diagnostic, without losing information about
whether that diagnostic is a warning or an error.
One can use -Wer
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36778
This is pretty trivial, but it would be nice to fix.
I tried to generate the pdf documents for gcc 4.3.1 on an x86 running fedora 9
without building gcc first. I ran configure with no options (in a separate
directory from the gcc source tree), then "make pdf". It generated a lot of
the pdf docum
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-09 22:31 ---
I think this is by design.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36779
--- Comment #2 from hal at oz dot net 2008-07-09 22:36 ---
Fair enough, but if that's the case, it'd be better to generate a "you can't do
that - make the compiler first" message and quit gracefully.
BTW, this used to not work at all, but now make pdf does work in gcc/doc and
libiberty
--- Comment #8 from paolo dot carlini at oracle dot com 2008-07-09 22:49
---
Mark, could you possibly comment on this PR? With some good hints I could even
try to work on it...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-07-10 00:06 ---
Subject: Bug 36552
Author: bkoz
Date: Thu Jul 10 00:05:27 2008
New Revision: 137677
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137677
Log:
2008-07-09 Andreas Beckmann <[EMAIL PROTECTED]>
PR libst
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-07-10 00:38 ---
Subject: Bug 36552
Author: bkoz
Date: Thu Jul 10 00:38:13 2008
New Revision: 137682
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137682
Log:
2008-07-09 Andreas Beckmann <[EMAIL PROTECTED]>
PR libst
--- Comment #6 from nightstrike at gmail dot com 2008-07-10 00:49 ---
Kai, can you apply FX's fix?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34315
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-07-10 01:05 ---
Mine
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-07-10 01:06 ---
fixed for 4.3.2
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGN
--- Comment #1 from bkoz at gcc dot gnu dot org 2008-07-10 01:10 ---
This is by design. It turns out that PCH files vary enough system-to-system
that rebuilding them on a per-computer basis is necessary. Thus, schlepping
around 20-40MB files is of limited value.
Instead, we are now adv
For trunk and 4.3-branch, bootstrapping on SH fails during building
libstdc++-v3
/exp/ldroot/dodes/xsh-gcc-orig/sh4-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:559:
error: insn does not satisfy its constraints:
(insn 2055 2054 716 106
/exp/ldroot/dodes/xsh-gcc-orig/sh4-unknown-li
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-07-10 01:24 ---
This is pretty suspicious, in that C++ on x86/linux for the 4.3.1 release is
well-trod territory and if stdlib.h was missing, many other people would be
seeing this too.
That leads me to think that this is probably so
--- Comment #1 from kkojima at gcc dot gnu dot org 2008-07-10 01:27 ---
Created an attachment (id=15882)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15882&action=view)
A reduced test case for -O0
Before r137639, the insn in problem was
(insn 200 330 331 20 yyy.cc:181 (set (mem/
--- Comment #1 from bkoz at gcc dot gnu dot org 2008-07-10 01:31 ---
Thanks for providing feedback on the docs.
Yes, you are correct about the broken links. Fixing...
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-07-10 01:42 ---
Subject: Bug 36451
Author: bkoz
Date: Thu Jul 10 01:41:29 2008
New Revision: 137685
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137685
Log:
2008-07-09 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstd
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-07-10 01:44 ---
Fixed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from bkoz at gcc dot gnu dot org 2008-07-10 01:52 ---
Ian last to change gnu_ld_version bits, which are currently broken with stock
2.18 GNU release for libstdc++/libgomp.
It would be really nice to fix this in one place, not two.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #3 from ian at airs dot com 2008-07-10 01:52 ---
What is the output of ld --version using your 2.18 version of ld?
--
ian at airs dot com changed:
What|Removed |Added
-
If you have an environment where special CFLAGS are needed for compilation, gcc
doesn't compile (in my example, it was Sparc that requires -m64). The
configure/make scripts are so messed up that they will eventually drop CFLAGS
and try to compile parts of gcc without them.
How to reproduce on any
--- Comment #1 from joseph at codesourcery dot com 2008-07-10 02:51 ---
Subject: Re: New: gcc can't be compiled in an environment
that requires CFLAGS
On Thu, 10 Jul 2008, mikulas at artax dot karlin dot mff dot cuni dot cz wrote:
> If you have an environment where special CFLAGS ar
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-07-10 03:01 ---
fixed
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #15 from bangerth at dealii dot org 2008-07-10 03:38 ---
(In reply to comment #11)
> Subject: Re: [4.3 regression] -Wreturn-type warns about more
> than what the documentation says
>
>
> > I think this was done on purpose.
>
> It is contrary to what the documentation say
--- Comment #20 from bangerth at dealii dot org 2008-07-10 03:40 ---
(In reply to comment #19)
> Fixed for 4.4.0.
Thanks a lot!
Two questions:
1/ Is the text in the documentation that Dirk Mueller added in the last commit
of PR 30601 now wrong/outdated?
2/ Does your patch also fix t
--- Comment #9 from mark at codesourcery dot com 2008-07-10 03:42 ---
Subject: Re: [4.4 regression] warning "array subscript is
below array bounds" on delete [] with -O2, -Wall
paolo dot carlini at oracle dot com wrote:
> Mark, could you possibly comment on this PR? With some good hi
--- Comment #21 from doko at gcc dot gnu dot org 2008-07-10 03:51 ---
Subject: Bug 28322
Author: doko
Date: Thu Jul 10 03:51:04 2008
New Revision: 137687
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137687
Log:
2008-07-10 Peter Maydell <[EMAIL PROTECTED]>
PR other/2
--- Comment #1 from ian at airs dot com 2008-07-10 05:49 ---
Yes, the old demangler printed additional text in some cases when DMGL_VERBOSE
was passed as a flag. c++filt passes that flag. The new demangler doesn't
print that additional text. There are several FIXME comments in
libiber
88 matches
Mail list logo
