--- Additional Comments From tim dot vanholder at anubex dot com
2004-11-16 07:56 ---
(In reply to comment #11)
> --disable-nls doesn't kill the build, but it does give extra fails in
> 22_locale
> for the messages facet. This is expected.
Maybe so, but I never used --disable-nls, so w
The following code causes GCC to suck up all RAM when 'throw error1;' is
uncommented, and to output the following error when 'throw error2;' is
uncommented:
kill_gcc.cpp: In function `void test() [with T = int]':
kill_gcc.cpp:5: internal compiler error: in c_expand_expr, at c-common.c:4341
Please
--
What|Removed |Added
Summary|mmix-knuth-mmixware |[4.0 regression] mmix-knuth-
|testsuite failure: |mmixware testsuite failure:
--
What|Removed |Added
Summary|mmix-knuth-mmixware |[4.0 regression] mmix-knuth-
|testsuite failure: gcc.c- |mmixware testsuite failure:
With LAST_UPDATED: "Mon Nov 15 19:30:07 UTC 2004" I get:
FAIL: gcc.dg/20040910-1.c (test for errors, line 2)
FAIL: gcc.dg/20040910-1.c (test for excess errors)
With the message in the .log being:
/gcc/testsuite/gcc.dg/20040910-1.c:2: error: syntax error before 'int'
Last known to work on: "Mon N
With LAST_UPDATED: "Mon Nov 15 19:30:07 UTC 2004" I get:
gcc.c-torture/execute/simd-4.c execution, -O0
gcc.c-torture/execute/simd-4.c execution, -O1
gcc.c-torture/execute/simd-4.c execution, -O2
gcc.c-torture/execute/simd-4.c execution, -O3 -fomit-frame-pointer
gcc.c-torture/execute/simd-4.c ex
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
05:33 ---
now I understand why it works on x86-linux, size_t is defined as unsigned int
and not unsigned long.
It worked in 3.3.
The problem appeared between 20030301 and 20030302.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
04:37 ---
Confirmed on ppc-darwin but it works on x86-linux for some reason.
--
What|Removed |Added
Compile the following test case:
extern "C" {
typedef unsigned long size_t;
int snprintf(char * , size_t, const char * , ...) __asm("_fancy_snprintf");
}
namespace std { using ::snprintf; }
namespace std { void foo() { snprintf(0, 3, ""); } }
If you examine the assembly file or the .o file
--- Additional Comments From law at redhat dot com 2004-11-16 04:25 ---
Subject: Re: [4.0 Regression] ICE with
-funroll-loops
On Sun, 2004-11-14 at 17:50 +, giovannibajo at libero dot it wrote:
> --- Additional Comments From giovannibajo at libero dot it 2004-11-14
> 1
--- Additional Comments From phython at gcc dot gnu dot org 2004-11-16
04:17 ---
Having sparc_expand_builtin return target/op[0] instead of pat makes gets rid
of the problems in extract_insn.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18510
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-16
02:55 ---
Hmmm... the following patch seems to have allowed my build to complete. Changed
sed line and created s-macro_list target/timestamp'd file, similar to what is
done throughout Makefile.in. Dropping into bugz
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
02:52 ---
Read http://gcc.gnu.org/bugs.html#nonbugs_general
Casting does not work as expected when optimization is turned on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18468
--- Additional Comments From james_avera at yahoo dot com 2004-11-16 02:47
---
Subject: Re: bad code in template function called from template class method
Hi,
Can you summarize what aliasing rule is violated?
Note that the argument is a ref, so the code is
not taking the adderess of
--
What|Removed |Added
Component|c++ |rtl-optimization
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzill
--- Additional Comments From jim at dishaw dot org 2004-11-16 02:41 ---
I attempted the build again execpt that I set LD_LIBRARY_PATH=/sys/sdf/sci/lib
before the first configure and it now builds to completion. Is this buggy
behaviour or the intended behaviour? One part of the configure
--- Additional Comments From brian at cubik dot ca 2004-11-16 02:40 ---
Created an attachment (id=7552)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7552&action=view)
recvol.ii (preprocessed source)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18513
# c++ -O2 -DUNRAR -c recvol.cpp
recvol.cpp: In member function `bool RecVolumes::Restore(RAROptions*, const
char*, const wchar*, bool)':
recvol.cpp:377: internal compiler error: Bus error
--
Summary: unrar 3.4.3 build fails with bus error
Product: gcc
V
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-16
02:35 ---
More compact testcase:
==
template struct A {};
struct B : A<0>
{
void foo() { this->A<0>; }
};
==
This is really invalid code.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
02:21 ---
Confirmed.
: Search converges between 2003-07-08-trunk (#288) and 2003-07-09-trunk (#289).
reduced testcase:
template struct property {
};
struct iii : public property {
const int get_callback()
Hello,
I was just wondering around code and following code resulted in ICE (MinGW
3.4.2). I don't think that this is some kind of terrible bug as the code is
obviously wrong (or isn't it?). Maybe you'll want to know about it, at least
the compiler want me to report bug :) Maybe someone already
--- Additional Comments From pbrook at gcc dot gnu dot org 2004-11-16
02:03 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-16
02:02 ---
Subject: Bug 13010
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-16 02:02:38
Modified files:
gcc/fortran: trans-array.c trans-types.c trans-typ
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-16
02:01 ---
Subject: Bug 13010
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-16 02:01:19
Modified files:
gcc/fortran: ChangeLog
gcc/testsuite : C
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
01:51 ---
ir.cc 47.17 69.26 -31.89 72.42 129.49 -44.07 100.1 165.27
-39.43
I just sped up ir.cc a little with my patch to cp-gimplify.c (which was
committed)
Reference: http://gcc.gnu.org/ml/gc
For x86 cross sh4-unknown-linux-gnu, 4.0.0 cc1plus segfaults
when compiling libstdc++-v3/src/localename.cc:
Program received signal SIGSEGV, Segmentation fault.
0x082d8e77 in regno_clobbered_p (regno=1139, insn=0x9bb9, mode=SImode, sets=0)
at ../../ORIG/gcc/gcc/reload.c:6931
6931 unsigned
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2004-11-16 01:00 ---
Subject: Re: [3.3 only] [hppa] try-catch program fails when
> > Which exception model (sjlj or dwarf2) are you using?
>
> sjlj for gcc-3.3. now that you mention it, i see that my 3.4 compiler is
>
--- Additional Comments From tausq at debian dot org 2004-11-16 00:55
---
(In reply to comment #3)
> I don't believe there have been any specific changes to the backend
> with respect to exception support since 3.3.0. 3.0 didn't have dwarf2
> EH support. There possibly have been some c
--- Additional Comments From danglin at gcc dot gnu dot org 2004-11-16
00:40 ---
I don't believe there have been any specific changes to the backend
with respect to exception support since 3.3.0. 3.0 didn't have dwarf2
EH support. There possibly have been some changes in the libstdc++
--- Additional Comments From phython at gcc dot gnu dot org 2004-11-16
00:36 ---
Created an attachment (id=7551)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7551&action=view)
VIS intrinsics patch, fails in recog
This patch gets GCC to the point where recog fails to recognize th
GCC currently doesn't have any builtin functions to access SPARCs VIS
instructions. It should have nice functions for instructions such as
fpack{16,32,fix} .
--
Summary: GCC should have instrinsics for SPARC VIS instructions
Product: gcc
Version: 4.0.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
00:13 ---
This is most likely only effects 3.3.x because something changed in the
back-end to support
exceptions better.
--
What|Removed |Added
--
--
What|Removed |Added
Component|c++ |target
Keywords||EH, wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Additional Comments From tausq at debian dot org 2004-11-16 00:07
---
Created an attachment (id=7550)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7550&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18509
[EMAIL PROTECTED]:/tmp$ g++ -o try_catch try_catch.cc
[EMAIL PROTECTED]:/tmp$ ./try_catch
Segmentation fault (core dumped)
[EMAIL PROTECTED]:/tmp$ g++ -fomit-frame-pointer -o try_catch try_catch.cc
[EMAIL PROTECTED]:/tmp$ ./try_catch
[EMAIL PROTECTED]:/tmp$
[EMAIL PROTECTED]:/tmp$ g++ -O1 -fno-o
When building the compiler without bootstrapping, ie. with make all-gcc, the
file libgcc_s_nof.so.1 is always rebuilt and a bogus libgcc_s_nof.so.1. (with
a trailing dot) is created. During this rebuild basename is called without
argument because $(STAGE_PREFIX) is empty.
--
Summa
For the testcase in PR 13776 (ir.ii) we spend a lot of time (10% out of 120
seconds) in ggc_alloc.
Most of that time comes from creatting/expanding the block_defs_stack varray in
tree-into-ssa.c
Why is this GC allocated in the first place?
Maybe this should be a non-gc'ed VEC.
We know that this v
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
22:51 ---
PR 10469 looks like a testcase where this could improve the code generation.
--
What|Removed |Added
--
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
Poor generated code for initializing vectors with constants because vec_init
pattern is not defined for Altivec.
--
Summary: Altivec definitions of vec_init
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Prior
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
22:31 ---
*** Bug 18505 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
22:31 ---
Yes this is the same as PR 18403, which was reported by Dorit and then found by
me that we now ICE.
*** This bug has been marked as a duplicate of 18403 ***
--
What|Removed
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
Sometime between 20041112 (my last successful bootstrap) and 20041115, five
tests in gcc.dg/vect start getting an ICE for -m64 on powerpc64-linux-gnu:
elm3b11% /home/janis/tools/gcc-mline-20041115-patches/bin/gcc -m64 -maltivec -O2
-ftree-vectorize vect-60.c
vect-60.c: In function main1:
vect
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-15
22:10 ---
Subject: Bug 18498
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-15 22:10:17
Modified files:
gcc: ChangeLog c-decl.c
gcc/tests
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-11-15 22:01
---
--disable-nls doesn't kill the build, but it does give extra fails in 22_locale
for the messages facet. This is expected.
I'll close this next week unless somebody can tell me what the problem is.
-benjamin
--- Additional Comments From jim at dishaw dot org 2004-11-15 21:55 ---
Subject: Re: Build fails with "libgmp.so.6 not found" error
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
> 14:12 --
--- Additional Comments From stevenb at suse dot de 2004-11-15 19:31
---
Subject: Re: [4.0 Regression] quadratic behavior in cfgexpand
The complexity is O(N) with vectors and with lists. How on earth
do you get to O(N*M)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18499
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
19:30 ---
No they come from that fact remove_edge is O(number of edges in succ of
BB)+O(number of edges in
pred of BB) and then you are doing O(number of edges) with calling remove_edge
the whole thing now
becomes
--- Additional Comments From giovannibajo at libero dot it 2004-11-15
19:25 ---
Doesn't the quadraticy come from VEC_unordered_remove? If you have M total
edges and you want to remove N of them, the complexity is O(N*M) with vectors,
but used to be O(N) with lists.
--
http://gcc.gn
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15
19:04 ---
Just noticed there is thread on gcc-patches on this:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01232.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18486
--- Additional Comments From dorit at il dot ibm dot com 2004-11-15 18:53
---
(In reply to comment #2)
> At least on powerpc-darwin (with -m64) we now vectorize these loops but we
ICE because we have:
> pointer_type + int_type which is not valid and is even worse on 64bit targets
as in
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15
18:40 ---
seems like this may just be a race on tmp-macro_list?? the macro_list code
looks bogus, but really doesn't account for the behavior. not sure how parallel
build races are protected against gcc build machine
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
18:12 ---
confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
18:09 ---
"c.f();" is just a dup of bug 795 which was fixed by the new parser in 3.4.x.
Now we do have a bug in that we accept the code without though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18497
--- Additional Comments From phil at mkdoc dot com 2004-11-15 18:03 ---
This bug also affects GCJ 3.3.2 on GNU/Linux and 3.3.3 on Cygwin.
The class org.w3c.tidy.ParserImpl in the JTidy tool is another test case.
http://sourceforge.net/projects/jtidy/
--
What|Removed
--- Additional Comments From law at redhat dot com 2004-11-15 17:56 ---
Subject: Re: [4.0 Regression] ICE with
-funroll-loops
On Sun, 2004-11-14 at 17:50 +, giovannibajo at libero dot it wrote:
> --- Additional Comments From giovannibajo at libero dot it 2004-11-14
> 1
--- Additional Comments From zhaojiangbin at yahoo dot com 2004-11-15
17:54 ---
(In reply to comment #0)
> The code in question:
> begin
> struct C
> {
> template void f() {}
> };
>
> template void ff()
> {
> C c;
> c.f(); // <--
> }
> end
Sorry there was a m
--- Additional Comments From jlquinn at gcc dot gnu dot org 2004-11-15
17:23 ---
OK, my problem is that the patch didn't actually get applied to mainline. So
it's not so surprising I didn't see the failures.
I'll apply locally and debug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Additional Comments From bkoz at redhat dot com 2004-11-15 17:04
---
Subject: Re: Floating point output is slow
>I don't see any of those failures. I updated tonight (11/12). Did a fresh
>config and make (not bootstrap) on x86 pentium M.
Hmmm. Well, maybe I munged the floatconv
--- Additional Comments From law at redhat dot com 2004-11-15 17:01 ---
Subject: Re: [4.0 Regression] ICE with
-funroll-loops
On Sun, 2004-11-14 at 15:47 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 2004-11-14
> 15:
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15
16:46 ---
Hmmm in Makefile.in
macro_list : $(GCC_PASSES)
echo | $(GCC_FOR_TARGET) -E -dM - | \
sed -n 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p ; \
s/^#define \(_[^_A-Z][a-zA-Z0-9_]*\)
--- Additional Comments From torgeihe at stud dot ntnu dot no 2004-11-15
16:26 ---
Subject: Re: _mm_move_ss SSE intrinsic causes
erroneous
pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
> 15:47 ---
> No you are
--- Additional Comments From joseph at codesourcery dot com 2004-11-15
15:51 ---
Subject: Re: trigraphs don't work with -std=gnu99
On Mon, 15 Nov 2004, pinskia at gcc dot gnu dot org wrote:
> Confirmed, the problem is either in the C front-end (which is really the code
> which drives
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
15:47 ---
No you are reading the asm backwards, the corresponding intel asm is:
bug:subss %xmm0, %xmm1
ret
Which you can get with -masm=intel.
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
15:41 ---
*** This bug has been marked as a duplicate of 18503 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
15:41 ---
*** Bug 18504 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18503
Compiling the following function on x86 with options -O -fomit-frame-pointer
-msse -S seems to result in erroneous code.
#include
__m128 bug(__m128 a, __m128 b) {
__m128 c = _mm_sub_ps(a, b);
return _mm_move_ss(c, a);
}
This is what the function in the resulting .s file looke li
Compiling the following function on x86 with options -O -fomit-frame-pointer
-msse -S seems to result in erroneous code.
#include
__m128 bug(__m128 a, __m128 b) {
__m128 c = _mm_sub_ps(a, b);
return _mm_move_ss(c, a);
}
This is what the function in the resulting .s file looke li
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
15:15 ---
Confirmed, the problem is either in the C front-end (which is really the code
which drives the
preprocessor library) or in the C driver part:
/Users/pinskia/local/libexec/gcc/powerpc-apple-darwin7.6.0/4.0
--
What|Removed |Added
CC||jgrimm2 at us dot ibm dot
||com
http://gcc.gnu.org/bugzilla/sho
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-15
15:02 ---
This showed up in linux-powerpc64 builds over the weekend on build machine's
belonging to Janis and myself.
I'm just doing a normal bootstrap, not profiledbootstrap. The build machines
are both SMP mac
--- Additional Comments From jlquinn at gcc dot gnu dot org 2004-11-15
15:02 ---
I don't see any of those failures. I updated tonight (11/12). Did a fresh
config and make (not bootstrap) on x86 pentium M.
FAIL: 23_containers/bitset/input/1.cc (test for excess errors)
FAIL: 23_containe
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-11-15
14:58 ---
Looking at the source of SPREAD, I note that it does not assert the rank of the
output matrix. Thus, in the fragment from the LLNL test it should be possible
to output the calls to SPREAD to temporary arra
Hello,
$ echo '??-' | gcc -P -E -trigraphs -std=gnu99 -trigraphs -
:1:1: warning: trigraph ??- ignored, use -trigraphs to enable
??-
$
That shouldn't happen. Apparently -trigraphs is ignored with -std=gnu99. Weird.
Lukas
--
Summary: trigraphs don't work with -std=gnu99
Pr
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
14:15 ---
I think this is autoconf/automake/libtool bug (it is a quoting problem I
assume).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18222
--
What|Removed |Added
Component|libfortran |fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18496
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
14:12 ---
Does setting LD_LIBRARY_PATH to /sys/sdf/sci help?
I don't know if we can count this as a bug or not.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
14:10 ---
This should be rejected, why it is not I don't know.
--
What|Removed |Added
Stat
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
14:06 ---
Confirmed, still present on the mainline.
For the mainline the problem could be solved by a DECL_EXPR around a TYPE_DECL.
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
13:51 ---
Confirmed:
: Search converges between 2003-12-16-trunk (#429) and 2003-12-17-trunk (#430).
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-15
13:50 ---
Confirmed, CCP is removing the use of the uninitialized variable.
--
What|Removed |Added
--- Additional Comments From joseph at codesourcery dot com 2004-11-15
13:42 ---
Subject: Re: New: gcc allows non-integral bitfield types
On Mon, 15 Nov 2004, rwxr-xr-x at gmx dot de wrote:
> Is this a bug in gcc or am I missing something?
This is indeed a regression bug in 3.4 and 4
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-15
13:36 ---
Created an attachment (id=7548)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7548&action=view)
test case, from tree-ssa-pre.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
The attached testcase has an uninitialized variable, it is not
diagnosed with -O2 -W -Wall. Gcc 3.2 says,
uninit.i: In function `bitmap_print_value_set':
uninit.i:8: warning: `first' might be used uninitialized in this function
this is a regression
--
Summary: Missing 'used unintial
--- Additional Comments From gerald at pfeifer dot com 2004-11-15 12:17
---
I'm seeing this in general, on *all* platforms, if I set CFLAGS to a string
ending with a blank: export CFLAGS="-pipe ", for example.
--
What|Removed |Added
--
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-15
12:16 ---
I think the sparclite-*-* targets should be removed for 4.0. Is there a new
round of target removing scheduled before the 4.0.0 release?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12027
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-15
12:11 ---
Investigating.
--
What|Removed |Added
CC|ebotcazou at gcc dot gnu dot|
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-15
12:08 ---
The compiler can now automatically emit VIS instructions with -mvis.
--
What|Removed |Added
---
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-15
12:05 ---
This is a regression wrt to the Fortran 77 compiler.
--
What|Removed |Added
Su
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-15
12:04 ---
This is a regression wrt to the Fortran 77 compiler.
--
What|Removed |Added
Su
It fails on the following versions of gcc.
arm-elf target, i686-pc-linux-gnu host:
gcc version 3.3.2
i386-redhat-linux: gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
i486-linux:gcc version 3.3.4 (Debian 1:3.3.4-13)
powerpc-macintosh: gcc version 3.3 20030304 (Apple
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-15
11:38 ---
Created an attachment (id=7547)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7547&action=view)
Suggestion for removing many edges at once
Something like this might help. There are still a few other p
--- Additional Comments From stevenb at suse dot de 2004-11-15 10:41
---
Subject: Re: [4.0 Regression] quadratic behavior in cfgexpand
Actually this has always been there, independent of the edge vector
work. The old code has exactly the same problem.
There is *no* canonical way to r
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18471
--- Additional Comments From jh at suse dot cz 2004-11-15 10:37 ---
Subject: Re: New: [4.0 Regression] quadratic behavior in cfgexpand
> The test case for 17340 exposes quadratic behavior caused by
> abnormal edges in the CFG:
>
>
> % cumulative self self to
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-11-15
10:37 ---
Fixed by patch:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01321.html
No formatting change was necessary. In addition, the testcase
from this PR is added as g++.dg/template/crash26.C.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-15
10:34 ---
Subject: Bug 18471
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-11-15 10:34:06
Modified files:
gcc/cp : ChangeLog decl.c name-lookup.c name-l
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-15
10:34 ---
Perhaps we should have an edge flag to mark edges dead, then walk the
entire CFG visiting all succ edges once (marking the dead ones) and
have a function remove_many_edges() in cfg.c to kill marked edges...
1 - 100 of 106 matches
Mail list logo
