--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #12 from cvs-commit at gcc dot gnu dot org 2005-10-25 08:04
---
Subject: Bug 21625
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-25 08:04:09
Modified files:
gcc/fortran: ChangeLog trans-
--- Comment #13 from eedelman at gcc dot gnu dot org 2005-10-25 08:07
---
With Richard Henderson's patch, things should now work on 4.0 too. Thus, I
declare this bug fixed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
-
bootstrapping gives ICE in c-parser.o for gcc-4.1-20051022
stage1/xgcc -Bstage1/
-B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/bin/ -c
-g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmiss
ing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2005-10-25 09:26
---
OK, confirmed with a pristine tree on i686.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from jakub at gcc dot gnu dot org 2005-10-25 09:31 ---
openmp keyword is enough.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Assig
command:
"gcc -g -Wall vector_bug.cc -lstdc++"
results in error message:
"vector_bug.cc:5: internal compiler error:
in write_builtin_type, at cp/mangle.c:1784
Please submit a full bug report,
with preprocessed source if appropriate."
preprocessed source:
// /usr/libexec/gcc/x86_64-redhat-linu
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-25 10:31 ---
Fixed in 4.0.2 (at least).
./cc1plus -quiet -o /dev/null -Wall /tmp/t.C
/tmp/t.C: In function int main(int, char**):
/tmp/t.C:22: error: no matching function for call to V4sf::set4(float&)
/tmp/t.C:9: note: can
--- Comment #3 from martin at mpa-garching dot mpg dot de 2005-10-25 11:26
---
This patch appears to work very well, thanks!
However, later in my code I run into a problem of the following sort:
The (patched) compiler rejects the following code
void bar (int *p)
{
#pragma omp para
--- Comment #4 from jakub at gcc dot gnu dot org 2005-10-25 11:34 ---
That's unrelated. Please file a different bug (and make sure it has openmp
keyword). Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24513
--- Comment #21 from hidden_peak at mail dot ru 2005-10-25 11:46 ---
May be is not gcc bug, but ld: the sample work with GNU ld version 2.12.90.0.1
20020307 Debian/GNU Linux, work with warnings with GNU ld version 2.15.94.0.2.2
20041220 (SuSE Linux) and don't work with ld 2.16.x (all wit
The current gomp branch (including Jakub Jelinek's proposed patch for
PR24513, rejects the following code:
void bar (int *p)
{
#pragma omp parallel for
for (int m=0; m<1000; ++m)
{
switch(p[m])
{
case 1:
p[m]=2;
break;
}
}
}
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --host=i3
--- Comment #1 from falk at debian dot org 2005-10-25 12:40 ---
(In reply to comment #0)
>*memptr++ = (unsigned char)donothing(*memptr, 0);
This expression modifies memptr after accessing it for something other
than determining the new value without an intervening sequence point. T
This:
real*8 :: x = 10.0e9
do i = 10, 22
x = 10d0 * x
print '(a,i2,a,g14.8)', "mod (10**",i,", 1.7_8) = ",mod (x, 1.7_8)
end do
end
does this with cvs gfortran
mod (10**10, 1.7_8) = 1.326
mod (10**11, 1.7_8) = 1.1000261
mod (10**12, 1.7_8) = 0.80026150
mod (10**13, 1.7_8) =
This PR is concerned with gfortran's performance relative to commercial
compilers in respect of Polyhedron's TEST_FPU.F90.
Baseline(test_fpu.f90 out of the box):
gfortran 20050903 -fmax-stack-var-size=100 -O2
Benchmark running, hopefully as only ACTIVE task
Test1 - Gauss 2000 (101x101) inv
Posted in: http://gcc.gnu.org/ml/fortran/2005-10/msg00443.html
I have been investigating the relatively poor performance of gfortran for
some of the Polyhedron Benchmark Tests (www.polyhedron.com).
I already discussed a couple of days ago how test_fpu.f90 exposed some
weakness in the dependency a
--- Comment #11 from cvs-commit at gcc dot gnu dot org 2005-10-25 13:44
---
Subject: Bug 22290
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-25 13:44:46
Modified files:
gcc/testsuite : ChangeLog
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 13:47 ---
Confirmed, I saw this while working on another bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
this is the output i get:
including in doc/man/misc...
making all in ./include...
making all in include/bitmaps...
making all in include/extensions...
making all in include/fonts...
making all in include/GL...
making all in include/DPS...
making all in ./config...
making all in config/cf...
making
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-25 13:55 ---
Woops wrong button.
One more testcase which looks like will show up in SPEC 2k5:
temp = #
c = #
DO j = 1, n
b(array) = b(array)-temp*c
END DO
We have a couple of temps here, two for array
--- Comment #1 from redeeman at metanurb dot dk 2005-10-25 13:56 ---
Created an attachment (id=10054)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10054&action=view)
cc5F7DsV.out
this is the output thing it talks about in the error message
--
http://gcc.gnu.org/bugzilla/show
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-25 13:56 ---
Did you read:
See http://bugs.gentoo.org/> for instructions.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from redeeman at metanurb dot dk 2005-10-25 14:03 ---
bugs.gentoo.org is just a bugzilla - but i figure this is not a gentoo problem.
i guy told me to report it to gcc's bugzilla. so i did.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24521
--- Comment #12 from cvs-commit at gcc dot gnu dot org 2005-10-25 14:06
---
Subject: Bug 22290
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-25 14:06:23
Modified files:
gcc/testsuite : ChangeLog
gcc/fortran: ChangeLog t
--- Comment #13 from fengwang at gcc dot gnu dot org 2005-10-25 14:09
---
Fixed.
--
fengwang at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-25 14:16 ---
This works for me, so it has to be a patch which gentoo adds.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 14:37 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 14:39 ---
Confirmed (note IE sucks).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from redeeman at metanurb dot dk 2005-10-25 14:40 ---
hmm ok.. do you think it could be because it is a 32bit chroot within a 64bit
install?
anyway, i will try a vanilla gcc 4.0.2, and get back to you later today or
tomorow perhaps (more likely)
--
http://gcc.gnu.org
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-10-25 14:59
---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01489.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24489
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17574
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=100
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23911
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24147
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |0.19
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17362
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-25 15:05
---
Subject: Bug 15067
CVSROOT:/cvs/gcc
Module name:gcc
Branch: csl-arm-branch
Changes by: [EMAIL PROTECTED] 2005-10-25 15:05:37
Modified files:
gcc: ChangeLog Chang
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from steven at gcc dot gnu dot org 2005-10-25 15:30 ---
Backtrace:
Breakpoint 1, fancy_abort (file=0xb1cc18
"../../mainline/gcc/tree-ssa-loop-ivopts.c",
line=2948, function=0xb1d0bb "aff_combination_to_tree") at diagnostic.c:590
590 internal_error ("in %s, at %s
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2005-10-25 15:33
---
Jan,
> Can you please check if -fno-tree-ter makes the bug go away? We've
> chatted recently with Jakub concerning bug in argument saving in nested
> call and -maccumulate-outgoing-args. I was under impression
--- Comment #74 from mueller at kde dot org 2005-10-25 15:41 ---
yes, well one reason for it is that several libs (e.g. libgcc2) already use
push/pop visibility macros and it doesn't seem to harm.
furthermore I manually added push/pop macros to libstdc++ headers on a debian
system (whi
--- Comment #75 from pcarlini at suse dot de 2005-10-25 15:44 ---
(In reply to comment #74)
> furthermore I manually added push/pop macros to libstdc++ headers on a debian
> system (which is broken regarding visibility support) and it made my testcase
> pass.
To be clear: I have nothin
--- Comment #2 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2005-10-25 15:56 ---
Subject: Re: [4.1 Regression] ICE in ivopts
Hello,
> Breakpoint 1, fancy_abort (file=0xb1cc18
> "../../mainline/gcc/tree-ssa-loop-ivopts.c",
> line=2948, function=0xb1d0bb "aff_combinatio
--- Comment #5 from steven at gcc dot gnu dot org 2005-10-25 16:24 ---
Jakub, ping!
Are you going to post your patch from comment #4??
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
Overview Description: More detailed expansion of summary.
When compiling template functions in g++ 4.0.2 (Debian 4.0.2-2) (Debian
testing/unstable) with -O2 and -Wall, the compiler generates a warning about a
statement with no effect. This seems to be due to the inlining with __v; as a
st
--- Comment #1 from ckillian at cs dot ucsd dot edu 2005-10-25 16:26
---
Created an attachment (id=10055)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10055&action=view)
The test.cc file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24522
--- Comment #2 from ckillian at cs dot ucsd dot edu 2005-10-25 16:26
---
Created an attachment (id=10056)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10056&action=view)
preprocessor output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24522
--- Comment #3 from ian at airs dot com 2005-10-25 16:36 ---
I believe this winds up being a duplicate of PR c++/8057, which is fixed on
mainline. With the test case in the PR, I see the warning with 4.0, but I do
not see the warning on mainline.
Note that this slightly modified test c
--- Comment #4 from ckillian at cs dot ucsd dot edu 2005-10-25 17:09
---
(In reply to comment #3)
> I believe this winds up being a duplicate of PR c++/8057, which is fixed on
> mainline. With the test case in the PR, I see the warning with 4.0, but I do
> not see the warning on mainli
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-25 17:51 ---
Here is a reduced testcase:
template
void f(int i)
{
int i1 = (__extension__ ({int i2 = i; i2;}));
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-25 17:59 ---
(In reply to comment #3)
> I believe this winds up being a duplicate of PR c++/8057, which is fixed on
> mainline. With the test case in the PR, I see the warning with 4.0, but I do
> not see the warning on mainline
program testcase_fold
real, dimension(:), pointer :: mystruct
mystruct(1:3) = mystruct(2:4)
END Program testcase_fold
That loop should be transvered in reverse oder so that we don't need a
temporary array.
--
Summary: Fortran dependency checking should reverse loops
Pr
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 18:14 ---
Another issue is that we should be able to reverse the loop too, see PR 24524
for a testcase for that (which I got the idea from Tobias in the email about my
patch which fixes a related bug to temporary arrays).
--
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org
--- Comment #22 from cvs-commit at gcc dot gnu dot org 2005-10-25 18:59
---
Subject: Bug 24295
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-25 18:59:21
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/g++.old-deja
--- Comment #2 from cvs-commit at gcc dot gnu dot org 2005-10-25 18:59
---
Subject: Bug 24477
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-25 18:59:21
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/g++.old-deja/
--- Comment #3 from aoliva at gcc dot gnu dot org 2005-10-25 18:59 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Component|target |testsuite
GCC
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-25 19:18 ---
I don't think --enable-maintainer-mode will ever work until the top level
directory is changed to 2.53 autoconf.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
g++-4.0.0 compiles the following code without warning, with both -Wconversion
and -Wall turned on. Since it is converting the UDT into a double, then
converting the double to an int, I believe it should warn exactly as it does in
the case when the commented-out line is used in place of the direct a
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-25 19:19 ---
Can you try this again, I think these are all fixed now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-25 19:22 ---
(In reply to comment #6)
> - For some reason, GCC is casting "char" to "int" prior to returning their
> value as a "char", which
>although works, is a fairly gross mis-optimization? (which should also
> likely
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 19:26 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-25 19:39
---
Is this now fixed?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 19:40 ---
Is this a bug in libtool, can you report to them and then please suspend this
bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21071
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-25 19:44 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 19:45 ---
I think this working again, right?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21190
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-25 19:45 ---
We need a testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 19:46 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 19:47 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 19:49 ---
Confirmed, testcase which shows this is also a rejects valid:
int f[.0e2 == 0?1:-1];
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
$ cat module.f90
module foo
real :: a
end module foo
program main
use foo, only : a
a = 42.
print *,a
end program main
$ gfortran -g module.f90
$ gdb ./a.out
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, an
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2005-10-25
19:52 ---
Subject: Re: [4.1 Regression] g-spitbo.adb:274: error: unrecognizable insn
> --- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 19:45
> ---
> I think this working again, right?
Right,
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 19:53 ---
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-25 19:57 ---
Fixed so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
This may be a gdb bug, but anyway...
cat type.f90
program main
type foo
real :: a
integer :: b
end type foo
type(foo) :: q
q = foo(3.14, 42)
print *,q
end program main
$ gfortran -g type.f90
$ gdb ./a.out
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is fr
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 20:06 ---
The second testcase works on x86_64 with -O2 -fschedule-insns -funroll-loops
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-25 20:11 ---
The easiest way to make this go away, is to make TImode not a workable mode on
mips64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22209
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-10-25 20:12
---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 20:13 ---
Can you try this again, I think this has been fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Component|rtl-optimization|target
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 20:23 ---
We do have an inconstaincy here, with -W, I get a warning for all 6 of them.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-25 20:24 ---
t.c: In function void c(unsigned int):
t.c:17: warning: comparison of unsigned expression < 0 is always false
t.c: In function void d(long unsigned int):
t.c:23: warning: comparison of unsigned expression < 0 is
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-25 20:34 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-25 20:35 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #14 from mckinlay at redhat dot com 2005-10-25 20:36 ---
Robert, thanks very much for working on this. Examining the behaviour of Sun's
verifier a bit more shows that it does attempt to resolve classes where type
compatibility can not be proven by a simple string comparison,
Given the following c code from sysvinit's init.c:
if (ch->action == SYSINIT) strcpy(ch->rlevel, "#");
gcc is producing the correct set of instructions for little endian arm, but
incorrect set of instructions for big endian arm.
That line when compiled with -mlittle-endian (correct):
While compiling ntp-4.2.0 from an i86 host for arm, I received the following
error. The host OS was recent linux (2.6.12 from a Fedora Core 3 base), but the
GCC in question was a cross-compile environment aimed at an ARM720T. The file
in question was 'a_md5encrypt.c' from the ntp-4.2.0 distribution
--- Comment #22 from cvs-commit at gcc dot gnu dot org 2005-10-25 21:38
---
Subject: Bug 17886
CVSROOT:/cvs/gcc
Module name:gcc
Branch: apple-local-200502-branch
Changes by: [EMAIL PROTECTED]2005-10-25 21:38:27
Modified files:
gcc: Chang
testcase: t.cpp
#include
#include
using namespace std;
void func_1( )
{
string aCvla="func1";
throw aCvla;
}
void func_2 ()
{
char aCvla[6];
strcpy (aCvla, "func2");
throw aCvla;
}
int main()
{
try {
func_1();
} catch ( string &aCA ) {
cout << aCA << endl;
}
try {
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-25 21:39 ---
And it also asked you to attach the preprocessed source too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 173 matches
Mail list logo
