--- 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
--- 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 #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 #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 #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 #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 #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
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 #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
-
--- 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 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: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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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
--
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 #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
--
--- 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 #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
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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36778
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
--- 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
--
--- 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 #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
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Severity|enhancement |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36755
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
--- 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
--- 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 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 #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_
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 #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
--- 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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
http:
--- 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
--- 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 #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 #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 #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 #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
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
$ 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)
--- 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-
--- 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 #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 #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 #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
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
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,
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
--- 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
--- 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 #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 #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 #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 #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 #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 #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 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 #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
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 #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
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
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.
88 matches
Mail list logo
