--- 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
===
*** gcc/f
--- 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 d
--- 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
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 assumptio
--- 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
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-08 02:01 ---
<) >>>
>>;
vs:
<>>
>>;
--
pinskia 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);
--
http://gcc.gnu.org/bugzilla/sho
--- 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 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
--- 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
// gcc version 3.4.5 (mingw-special)
class a
{
public:
template
operator T &() const
{
static int f;
return f; // line # 10
}
/*
// unsafe workaround:
operator a const &() const
{
retu
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
#include
template void bar(T &&t)
{
--- 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 18
--
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 #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 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=14505&action=view)
File created when compiling with -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34021
--- 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=14504&action=view)
C++ code which crashes when compiled with -O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34021
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: ../src/configure
--- 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 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: ia64-unkn
--- 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=gcc&view=rev&rev=129976
Log:
PR 33870
* tree.h (struct tree_struct_fi
--- 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 #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 #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 #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=gcc&view=rev&rev=129975
Log:
2007-11-07 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- 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=gcc&view=rev&rev=129975
Log:
2007-11-07 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- 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=gcc&view=rev&rev=129975
Log:
2007-11-07 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- 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 #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 #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=gcc&view=rev&rev=129974
Log:
PR java/34019:
* gcj.texi (Input Options): Add
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 #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
has been 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 #2 from jakub at gcc dot gnu dot org 2007-11-07 21:01 ---
This stems from the inliner, which changes:
result_end_9 = &.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 & is TREE_INVARIANT, this is not
mark
--- 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 #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=14503&action=view)
updated to gcc-4.3 trunk
updated against gcc-trunk (for 4.3.0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- 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=gcc&view=rev&rev=129972
Log:
PR rtl-optimization/33822
* rtl.h (REG_O
--- 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=gcc&view=rev&rev=129971
Log:
PR rtl-optimization/33822
* rtl.h (REG_O
--- 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=gcc&view=rev&rev=129970
Log:
PR rtl-optimization/33822
* rtl.h (REG_O
--- 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=14502&action=view)
gcc43-pr34012.patch
Updated patch with testcase. Paolo, are you bootstrapping/regtesting this or
should I? I ca
--- 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=14501&action=view)
reproducer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34018
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
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
--prefix=/net/cci-filer1/vo
--- 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
--- 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=gcc&view=rev&rev=118358
Log:
PR 15834
* config/darwin.h (NO_IMPLICI
--- 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 t
--- 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=gcc&view=rev&rev=129968
Log:
PR c++/33501
* call.c (build_over_call): Don't ch
--- 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=14500&action=view)
possible patch
This patch does two things I would like someone to comment on:
* Add a bit 'in_if_stmt' to c_parse
--- 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 #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
--
http://gcc.gnu.org/b
--- 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. B
--- 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
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
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 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?
/Users/bhudson/gcc-4.3-snapshot/lib/gcc
--- 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 c
--- 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=14499&action=view)
patch using rtx_cost
This patch uses rtx_cost instead of insn_rtx_cost, which is faster and does not
require touching i
--- 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 #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 tim
--- 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
--- 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
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|000
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=14498&action=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 #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=14497&action=view)
"minimal" testcase
This is as small as I could get it (130 lines). Can be made smaller, but the
performance differenc
--- 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
> tree-ss
--- 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 #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 (7.5.1.3).
--- 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 #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 #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 partitioni
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|000
--- 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=14496&action=view)
self contained testcase
4.2 4.3
-O214.5s11.4s
-O3
--- 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
> rt
--- 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.
--
http://gcc.gnu.org/bugzilla/sho
--- 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
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 -DBAD=
--- 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=14495&action=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 ma
--- 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
--- 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
var
--- 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=14494&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34003
--- 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
-Wmissing-fo
--- 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, 24(%rsp
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
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 non-32-bit-sign-
--- 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
--- 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 dec
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;
89 matches
Mail list logo
