--- Comment #8 from jakub at gcc dot gnu dot org 2007-11-07 09:15 ---
I'd stress that this is extremely worthless benchmark, because it makes no
attempt to ensure the calls are really done and not optimized away, which
happens
in the 3.4.x -march=athlon-xp case. At expand time GCC
Following testcase exposes optimization problem with current SVN gcc:
--cut here--
extern const int srcshift;
void good (const int *srcdata, int *dstdata)
{
int i;
for (i = 0; i 256; i++)
dstdata[i] = srcdata[i] srcshift;
}
void bad (const int *srcdata, int *dstdata)
{
int i;
--- Comment #2 from valera dot veryazov at teokem dot lu dot se 2007-11-07
09:45 ---
VV: confirmed also in 4.2.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34006
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
On
void bar (long int *);
void foo (void)
{
long int buf[10];
__builtin_memset (buf, 8, sizeof (buf));
bar (buf);
}
fwprop effectively undoes what CSE optimized. 0x0808080808080808 is not a
valid constant for movdi_1_rex64 when the target is memory (movdi_1_rex64 only
allows
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-07 10:24 ---
With 4.2 and earlier, we get:
movabsq $578721382704613384, %rax
movq%rsp, %rdi
movq%rax, (%rsp)
movq%rax, 8(%rsp)
movq%rax, 16(%rsp)
movq%rax,
--- Comment #11 from r dot emrich at de dot tecosim dot com 2007-11-07
10:58 ---
Created an attachment (id=14494)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14494action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
--- Comment #3 from bonzini at gnu dot org 2007-11-07 11:04 ---
Created an attachment (id=14495)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14495action=view)
patch that fixes the bug
I'm not sure about the correctness of the i386.c hunk. The problem is that a
cost of 0 is
--- Comment #10 from r dot emrich at de dot tecosim dot com 2007-11-07
10:57 ---
Patch solves the problem for rtl.c in gcc-4.3.0, but later:
gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
--- Comment #1 from pault at gcc dot gnu dot org 2007-11-07 11:02 ---
Two dummy arguments are distinguishable if neither is a subroutine and
neither
is TKR compatible (5.1.1.2) with the other.
Does this mean, though, that a subroutine is or is not distinguishable from a
--- Comment #2 from bonzini at gnu dot org 2007-11-07 11:03 ---
fwprop should check costs just like combine does. Unfortunately the cost do
need a little bit of tweaking even if one implements the idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34012
A subversion gcc, x86_64-pc-mingw32-gcc (GCC) 4.3.0 20071106
(experimental),
built with
$ ../configure --target=x86_64-pc-mingw32
built on cygwin running on Vista 64-bit.
I observe similar effects on a bunch of earlier versions too.
Then
x86_64-pc-mingw32-gcc -Wall -O2 cbug3.c -o cbug2
--- Comment #14 from dnovillo at google dot com 2007-11-07 12:14 ---
Subject: Re: [4.3 Regression] Revision 119502 causes significantly slower
results with 4.3 compared to 4.2
On 7 Nov 2007 06:03:09 -, paolo dot bonzini at lu dot unisi dot ch
[EMAIL PROTECTED] wrote:
I don't
--- Comment #9 from ubizjak at gmail dot com 2007-11-07 18:56 ---
(In reply to comment #8)
So if we can agree to dump -fforce-addr: yes, please.
Sometimes -fforce-addr produces faster code, as claimed in
http://gcc.gnu.org/ml/fortran/2007-10/msg00048.html
--
--- Comment #7 from daney at gcc dot gnu dot org 2007-11-07 18:59 ---
We no longer regress with respect to this testcase (bootstrapping on my small
mipsel-linux system).
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from zadeck at naturalbridge dot com 2007-11-07 18:44
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
This patch keeps recursive functions from being marked as pure or const.
Full testing in progress on x86-64.
Test 454.calculix from SPEC CPU2006 fails to build on powerpc-linux using -O2
-ftree-loop-linear with an ICE in execute_todo at passes.c:983. This minimized
test case demonstrates the problem:
subroutine bug()
implicit none
integer i,j
real*8 gr(6,6)
do i=1,6
Using gcc version 4.3.0 20071102 (experimental) (GCC)
When I use ext/hash_set I get a one-line warning copied below. It is
essentially illegible; perhaps it should point to a web page instead where the
question of what replaces what and how can properly be explained?
--- Comment #8 from matz at gcc dot gnu dot org 2007-11-07 16:45 ---
When I analyzed this for the first time and finally found the root cause
my immediate reaction was huh? we still have -fforce-addr? . So, I also
wanted to get rid of it. But Richard had some reservations at that time
--- Comment #19 from bonzini at gnu dot org 2007-11-07 16:35 ---
Might be tree-level forwprop, CCing richi...
--
bonzini at gnu dot org changed:
What|Removed |Added
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
In the .gimple dump of the testcase from PR33604
(http://gcc.gnu.org/bugzilla/attachment.cgi?id=14498) you can see things like
this one:
D.2136 = operator 1 (D.2127);
where 1 is actually operator double.
--
Summary: conversion operators misprinted in gimple dump
--- Comment #18 from bonzini at gnu dot org 2007-11-07 16:26 ---
Created an attachment (id=14498)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14498action=view)
never say minimal!
So this is a testcase constructed from scratch. 4.3 is 4.5x slower (0.8s vs.
0.18s). Furthermore,
--- Comment #16 from bonzini at gnu dot org 2007-11-07 14:22 ---
4.3 does much less SRA.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
--- Comment #13 from dnovillo at google dot com 2007-11-07 13:57 ---
Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at
tree-ssa-operands.c:487 with -O3
On 7 Nov 2007 13:52:29 -, amacleod at redhat dot com
[EMAIL PROTECTED] wrote:
There is also an issue with
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #15 from bonzini at gnu dot org 2007-11-07 13:09 ---
Created an attachment (id=14496)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14496action=view)
self contained testcase
4.2 4.3
-O214.5s11.4s
-O3
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-07 19:19 ---
Created an attachment (id=14500)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14500action=view)
possible patch
This patch does two things I would like someone to comment on:
* Add a bit 'in_if_stmt' to c_parser
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-07 19:27 ---
Subject: Bug 33501
Author: jakub
Date: Wed Nov 7 19:27:27 2007
New Revision: 129968
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129968
Log:
PR c++/33501
* call.c (build_over_call): Don't
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-07 19:29 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-07 19:33 ---
This was fixed in 4.3.0 by:
Author: geoffk
Date: Wed Nov 1 04:53:33 2006
New Revision: 118358
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118358
Log:
PR 15834
* config/darwin.h
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-07 19:37 ---
Related to PR 13178.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34014
Platform:
Fedora release 7 (Moonshine)
Linux idle.lbl.gov 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 20:47:39 EDT 2007 x86_64
x86_64 x86_64 GNU/Linux
% g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /net/rosie/scratch2/rwgk/gcc_trunk/configure
--- Comment #1 from dorit at gcc dot gnu dot org 2007-11-07 18:06 ---
(In reply to comment #0)
Following testcase exposes optimization problem with current SVN gcc:
...
the same address
is accessed with unaligned access (3) as well as aligned access.
This is a missed-optimization in
--- Comment #4 from rask at gcc dot gnu dot org 2007-11-07 16:35 ---
Francois-Xavier, do you still see a performance regression? If so, please post
asm output (-S -dp) from both versions?
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenther at suse dot de 2007-11-07 15:05 ---
Subject: Re: [4.3 Regression] ICE in
ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
On Wed, 7 Nov 2007, dnovillo at google dot com wrote:
Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at
--- Comment #15 from dnovillo at google dot com 2007-11-07 15:14 ---
Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc, at
tree-ssa-operands.c:487 with -O3
On 7 Nov 2007 15:05:57 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
It actually contains all pointed-to SFTs.
--- Comment #12 from amacleod at redhat dot com 2007-11-07 13:52 ---
Subject: Re: [4.3 Regression] ICE in ssa_operand_alloc,
at tree-ssa-operands.c:487 with -O3
rguenther at suse dot de wrote:
--- Comment #11 from rguenther at suse dot de 2007-11-06 21:36 ---
Subject: Re:
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-07 20:18 ---
Created an attachment (id=14502)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14502action=view)
gcc43-pr34012.patch
Updated patch with testcase. Paolo, are you bootstrapping/regtesting this or
should I? I can
Test 445.gobmk in SPEC CPU2006 fails to build on powerpc64-linux with -m64 -O2
-ftree-loop-linear due to an ICE in lambda_loopnest_to_gcc_loopnest, at
lambda-code.c:1840. This test case demonstrates the problem:
extern int size;
struct data2 { };
struct data1 { int origin; };
static void
print
--- Comment #6 from bonzini at gnu dot org 2007-11-07 17:02 ---
Created an attachment (id=14499)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14499action=view)
patch using rtx_cost
This patch uses rtx_cost instead of insn_rtx_cost, which is faster and does not
require touching
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-11-07 16:49
---
No, I don't see it any more.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2007-11-07 14:39 ---
According to
12.3.2.1.2 Defined assignments
If ASSIGNMENT is specified in an INTERFACE statement, all the procedures in the
interface block shall be subroutines that may be referenced as defined
assignments
--- Comment #5 from paolo dot bonzini at lu dot unisi dot ch 2007-11-07
13:53 ---
Subject: Re: [4.3 Regression] Pessimization caused
by fwprop
BTW, why don't you use just rtx_cost instead of insn_rtx_cost?
In each case you have an insn, so you can do single_set on it and run
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from rwgk at yahoo dot com 2007-11-07 19:45 ---
Created an attachment (id=14501)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14501action=view)
reproducer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34018
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-07 13:40 ---
BTW, why don't you use just rtx_cost instead of insn_rtx_cost?
In each case you have an insn, so you can do single_set on it and run
rtx_cost (SET_SRC (set), SET) on it directly.
--
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-11-07 20:48
---
Subject: Bug 33822
Author: ebotcazou
Date: Wed Nov 7 20:48:08 2007
New Revision: 129970
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129970
Log:
PR rtl-optimization/33822
* rtl.h
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-11-07 20:48
---
Subject: Bug 33822
Author: ebotcazou
Date: Wed Nov 7 20:48:38 2007
New Revision: 129971
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129971
Log:
PR rtl-optimization/33822
* rtl.h
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-11-07 20:49
---
Subject: Bug 33822
Author: ebotcazou
Date: Wed Nov 7 20:49:01 2007
New Revision: 129972
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129972
Log:
PR rtl-optimization/33822
* rtl.h
--- Comment #14 from aldot at gcc dot gnu dot org 2007-11-07 20:50 ---
Created an attachment (id=14503)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14503action=view)
updated to gcc-4.3 trunk
updated against gcc-trunk (for 4.3.0)
--
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-07 21:01 ---
This stems from the inliner, which changes:
result_end_9 = retval.elems[0] + D.2223_8;
into:
result_end_6 = this_2(D)-n_cells.elems[0] + D.2233_5;
While the former is valid GIMPLE, as retval is TREE_INVARIANT, this is
--- Comment #17 from bonzini at gnu dot org 2007-11-07 16:03 ---
Created an attachment (id=14497)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14497action=view)
minimal testcase
This is as small as I could get it (130 lines). Can be made smaller, but the
performance difference
--- Comment #21 from jacob at math dot jussieu dot fr 2007-11-07 20:58
---
Hi, I'm the guy behind Eigen, from which the initial testcase is taken.
Would it help the compiler if I removed most of the const keywords in my
code?
I am asking because of the following. As Eigen has Lvalue
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-11-07 20:51
---
On all branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-11-07 17:28
---
Basically things like
D.2196_13 = (struct Ref *) D.2150.lhs;
D.2196_13-m ={v} I;
where D.2150.lhs is const and thus there is a (not useless) cast from
(const struct Ref *) to (struct Ref *). So what the
reused.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20071107-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgcleanup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33737
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2007-11-07 22:08
---
The symptoms are masked.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Page 15 of the 4.2.2 gcj manual (and also the current manual), contains this
line:
In the below, a directory or path component can refer either to an actual
directory on the filesystem...
This should read In the below options, ... or something similar. below is
not a noun, and cannot stand
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-07 22:56 ---
Subject: Bug 34019
Author: tromey
Date: Wed Nov 7 22:55:58 2007
New Revision: 129974
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129974
Log:
PR java/34019:
* gcj.texi (Input Options): Add
--- Comment #2 from tromey at gcc dot gnu dot org 2007-11-07 22:56 ---
Fix checked in.
Thanks.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from nightstrike at gmail dot com 2007-11-07 23:27 ---
Wow, fast!
I may not be able to contribute much, but I do so where I can :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34019
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-11-07 23:37 ---
Subject: Bug 33837
Author: dgregor
Date: Wed Nov 7 23:37:29 2007
New Revision: 129975
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129975
Log:
2007-11-07 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-11-07 23:37 ---
Subject: Bug 33045
Author: dgregor
Date: Wed Nov 7 23:37:29 2007
New Revision: 129975
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129975
Log:
2007-11-07 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-11-07 23:37 ---
Subject: Bug 33838
Author: dgregor
Date: Wed Nov 7 23:37:29 2007
New Revision: 129975
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129975
Log:
2007-11-07 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-11-07 23:39 ---
Fixed for decltype (typeof is already doing what it is supposed to do)
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-11-07 23:39 ---
Fixed
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-11-07 23:40 ---
Fixed
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #21 from dnovillo at gcc dot gnu dot org 2007-11-08 00:26
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00374.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
The following C++ code crashes when compiling with G++ 4.1.3, even though it is
perfectly valid C++. To reproduce the bug, simply compile the program with -O2
and run it.
EXECUTION:
[EMAIL PROTECTED]:~/cs/temp$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with:
--- Comment #1 from chuongdo at cs dot stanford dot edu 2007-11-08 00:33
---
Created an attachment (id=14504)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14504action=view)
C++ code which crashes when compiled with -O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34021
--- Comment #2 from chuongdo at cs dot stanford dot edu 2007-11-08 00:34
---
Created an attachment (id=14505)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14505action=view)
File created when compiling with -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34021
--- Comment #3 from chuongdo at cs dot stanford dot edu 2007-11-08 00:35
---
The C++ code crashes with
g++ -o a a.cc -O2
but not
g++ -o a a.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34021
--- Comment #2 from sergey dot gcc at comrades dot id dot au 2007-11-08
02:03 ---
(In reply to comment #1)
I've checked other versions of compiler, such as 3.4.6 and 4.X.X. Can someone
check?
Sorry, I mean, I have *NOT*.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34023
When compiled with gcc 3.4.4 through 4.1.2 -O on x86_64 the program below never
terminates. I haven't checked the standard for possible undefined behavior in
this case but since the same program terminates when compiled with many (all?)
all other compilers we have available I'm making the
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-08 02:01 ---
cleanup_point Unknown tree: expr_stmt
bar ((char ) TARGET_EXPR D.3338, *forward ((char ) (char *) t))
;
vs:
cleanup_point Unknown tree: expr_stmt
bar ((struct S ) (struct S *) forward ((struct S ) (struct S
--- Comment #3 from pault at gcc dot gnu dot org 2007-11-08 07:16 ---
This fixes the problem. I'll do something with it when I am back at base -
likely, early next week.
Paul
Index: gcc/fortran/trans-array.c
===
***
--- Comment #8 from paolo dot bonzini at lu dot unisi dot ch 2007-11-08
06:10 ---
Subject: Re: [4.3 Regression] Pessimization caused
by fwprop
jakub at gcc dot gnu dot org wrote:
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-07 20:18 ---
Created an attachment
--- Comment #1 from sergey dot gcc at comrades dot id dot au 2007-11-08
01:58 ---
I've checked other versions of compiler, such as 3.4.6 and 4.X.X. Can someone
check?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34023
// gcc version 3.4.5 (mingw-special)
class a
{
public:
templateclass T
operator T () const
{
static int f;
return f; // line # 10
}
/*
// unsafe workaround:
operator a const () const
{
Compile the following program with -std=c++0x. In my understanding, the two
printed addresses should be the same. They are when I invoke foo() with a class
type, but not with built-in types like char.
This is with the latest g++ built from SVN.
#include cstdio
#include utility
templatetypename
The codegen for atomic instructions with indirect/reference operands on
Itanium seems to be bogus:
% cat bar.F
subroutine atomic_add(lhs, rhs)
real lhs, rhs
!$omp atomic
lhs = rhs + lhs
end
% gfortran -v -fopenmp -O1 -S bar.F
Using built-in specs.
Target:
--- Comment #20 from dnovillo at gcc dot gnu dot org 2007-11-08 00:01
---
Subject: Bug 33870
Author: dnovillo
Date: Thu Nov 8 00:01:38 2007
New Revision: 129976
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129976
Log:
PR 33870
* tree.h (struct
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34021
--- Comment #11 from zadeck at naturalbridge dot com 2007-11-08 01:23
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
zadeck at naturalbridge dot com wrote:
--- Comment #10 from zadeck at naturalbridge dot com 2007-11-07
--- Comment #1 from spop at gcc dot gnu dot org 2007-11-08 01:56 ---
Occurs only on 64bit machines: I cannot reproduce it on i686-linux.
I'll give a look at this bug on amd64 later on.
Sebastian
--
spop at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from spop at gcc dot gnu dot org 2007-11-08 01:58 ---
Fails also on i686-linux. I'm working on a fix.
Sebastian
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-08 01:59 ---
D.3322 = 97;
printf (%p\n[0], D.3322);
D.3373 = D.3322;
printf (%p\n[0], D.3373);
D.3323 = {};
printf (%p\n[0], D.3323);
printf (%p\n[0], D.3323);
--
--- Comment #22 from paolo dot bonzini at lu dot unisi dot ch 2007-11-08
06:12 ---
Subject: Re: [4.3 Regression] Revision 119502
causes significantly slower results with 4.3 compared to 4.2
jacob at math dot jussieu dot fr wrote:
--- Comment #21 from jacob at math dot jussieu
89 matches
Mail list logo
