Harvey Harrison wrote:
Was this repo made with svnimport or git-svn? svnimport is faster but
chooses bad delta bases as a result. git repack -a -d -f would allow
git to choose better deltas rather than reusing the deltas that
svnimport created.
I used:
git-svn fetch
git-fetch .
On Fri, Jun 01, 2007 at 02:52:43AM -0400, Bernardo Innocenti wrote:
Harvey Harrison wrote:
Was this repo made with svnimport or git-svn? svnimport is faster but
chooses bad delta bases as a result. git repack -a -d -f would allow
git to choose better deltas rather than reusing the deltas
Hello,
Can someone tell me the back-end optimizations available for itanium
(IA64)?
We (HP) may be able to contribute to this from our side.
Thanks
-kamal
Like e.g. the generated code
IF match-char1 THEN ..
ELSIF match-char2 THEN ..
ELSIF match-char3 THEN ..
..
END
?
Similar. It identifies ranges of character point sets and
brackets them via binary bracketting.
Why to complicate the things? The determinist finite automaton
Jan-Benedict Glaw wrote:
On Thu, 2007-05-31 21:34:33 -0400, Bernardo Innocenti [EMAIL PROTECTED] wrote:
I've set up a Git mirror of the entire GCC history on
server space kindly provided by David Woodhouse.
You can clone it with:
git-clone git://git.infradead.org/gcc.git
How often will it
Hello all,
I am working with a private target(GCC v4.1.1).
For my target the function arguments are passed through registers.
For this purpose 4 registers are used. If the no. of arguments are
more than 4, the remaining arguments are passed through stack.
But for varargs the arguments are
On Fri, 2007-06-01 04:47:11 -0400, Bernardo Innocenti [EMAIL PROTECTED] wrote:
Jan-Benedict Glaw wrote:
On Thu, 2007-05-31 21:34:33 -0400, Bernardo Innocenti [EMAIL PROTECTED]
wrote:
I've set up a Git mirror of the entire GCC history on
server space kindly provided by David Woodhouse.
On Fri, 2007-06-01 at 10:39 +0200, Jan-Benedict Glaw wrote:
How often will it be synced with upstream SVN? While you're at it,
would David mind to also place a binutils, glibc and glibc-ports GIT
repo next to it? That way, there would be a nice single point of GIT
repos for the whole
On Fri, Jun 01, 2007 at 04:47:11AM -0400, Bernardo Innocenti wrote:
Jan-Benedict Glaw wrote:
On Thu, 2007-05-31 21:34:33 -0400, Bernardo Innocenti [EMAIL PROTECTED]
wrote:
I've set up a Git mirror of the entire GCC history on
server space kindly provided by David Woodhouse.
You can clone
Hi,
my questions is, why not use the element construction algorithm? The Thomson
Algorithm creates an epsilon-NFA which needs quite a lot of memory. The
element construction creates an NFA directly and therefor has fewer states.
Well, this is only interesting in the scanner creation which is
On Thu, 2007-05-31 21:34:33 -0400, Bernardo Innocenti [EMAIL PROTECTED] wrote:
I've set up a Git mirror of the entire GCC history on
server space kindly provided by David Woodhouse.
You can clone it with:
git-clone git://git.infradead.org/gcc.git
How often will it be synced with upstream
2007/6/1, Frank Schaefer [EMAIL PROTECTED] wrote:
To obtain 200-250% in speed gain won't be possible for this GCC
optimizing compiler because of http://en.wikipedia.org/wiki/Amdahl%27s_law
Amdahl's Law talks about paralellism. That is not the case here.
He apply a different approach for
On Fri, 2007-06-01 12:12:59 +0200, Gabriel Paubert [EMAIL PROTECTED] wrote:
On Fri, Jun 01, 2007 at 04:47:11AM -0400, Bernardo Innocenti wrote:
Be our guest, and let me know if you find a way to
repack the repo to a smaller size.
I just upgraded my git to 1.5.2 and repacked the git
Hi all,
please don't panish me, I know there were plenty of discussions concerning
this subject, however I'm a newbie in multi-threaded programming :-) and
couldn't find a good explanation to my problem in former discussions..
so, perhaps somebody could redirect my question to the appropriate
Hi,
While working on a vdso for Linux/m68k I stumbled again on a problem, I
already had with the fallback unwind handler in gcc, where I'd like to
hear some opinions.
I'm looking at the i386 unwind handler and that doesn't bother to restore
any fp registers. On m68k it's a little more
Prasad, Kamal R [EMAIL PROTECTED] writes:
Can someone tell me the back-end optimizations available for itanium
(IA64)?
We (HP) may be able to contribute to this from our side.
GCC implements more or less the same set of optimizations for all
targets. I don't think there are any IA64
Mohamed Shafi [EMAIL PROTECTED] writes:
I am working with a private target(GCC v4.1.1).
For my target the function arguments are passed through registers.
For this purpose 4 registers are used. If the no. of arguments are
more than 4, the remaining arguments are passed through stack.
But
Roman Zippel [EMAIL PROTECTED] writes:
While working on a vdso for Linux/m68k I stumbled again on a problem, I
already had with the fallback unwind handler in gcc, where I'd like to
hear some opinions.
I'm looking at the i386 unwind handler and that doesn't bother to restore
any fp
Gabriel Paubert wrote:
This may be the pack depth which was increased to 50 according
to 1.5.2 release notes:
I've repacked with 1.5.2, and it doesn't seem to decrease
the repo size considerably.
I'm now repacking with git-repack -a -d -f --window=20 --depth=100,
but it takes a lot of time
Gabriel Paubert wrote:
I just upgraded my git to 1.5.2 and repacked the git repository
with git-gc --aggressive. It is quite impressive: the size of
the pack file was almost cut in half, from ~23MB to ~12MB!
The --aggressive option is undocumented in 1.5.2. What
is it supposed to do?
--
On Fri, Jun 01, 2007 at 11:00:29AM -0400, Bernardo Innocenti wrote:
Gabriel Paubert wrote:
I just upgraded my git to 1.5.2 and repacked the git repository
with git-gc --aggressive. It is quite impressive: the size of
the pack file was almost cut in half, from ~23MB to ~12MB!
The
Hi,
On Fri, 1 Jun 2007, Ian Lance Taylor wrote:
I don't know the answer. But I do know that you need to think about
-fasynchronous-unwind-tables, and you need to think about how your
kernel handles registers when calling a handler, and you need to think
about what unwind information is
Prasad, Kamal R wrote:
Hello,
Can someone tell me the back-end optimizations available for itanium
(IA64)?
We (HP) may be able to contribute to this from our side.
Sorry, it is ambiguous question. There are a lot of optimizations in
GCC. Most of them are available for Itanium.
If you
Hi!
Has there been any contribution from HP at all on itanium specific
optimizations? I am referring to instruction scheduling and stuff at
that level.
Our interfaces are derived largely from stanford (SUIF) -but if I had
to contribute, I can contribute to the existing environment. It is a
Prasad, Kamal R wrote:
Hi!
Has there been any contribution from HP at all on itanium specific
optimizations? I am referring to instruction scheduling and stuff at
that level.
Please, ask Steve Ellcey [EMAIL PROTECTED] about this. He is most active
developer of GCC from HP.
Our
Gabriel Paubert wrote:
On Fri, Jun 01, 2007 at 11:00:29AM -0400, Bernardo Innocenti wrote:
Gabriel Paubert wrote:
I just upgraded my git to 1.5.2 and repacked the git repository
with git-gc --aggressive. It is quite impressive: the size of
the pack file was almost cut in half, from ~23MB to
The predictive commoning patch:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01061.html
miscompiles 482.sphinx3 in SPEC CPU 2006 with -O2 -ffast-math on
Linux/x86-64. Zdenek, do you have any ideas?
BTW, we are working on a small testcase.
H.J.
On Fri, Jun 01, 2007 at 09:37:54AM -0700, H. J. Lu wrote:
The predictive commoning patch:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01061.html
miscompiles 482.sphinx3 in SPEC CPU 2006 with -O2 -ffast-math on
Linux/x86-64. Zdenek, do you have any ideas?
Something is wrong. Predictive
On 6/1/07, H. J. Lu [EMAIL PROTECTED] wrote:
On Fri, Jun 01, 2007 at 09:37:54AM -0700, H. J. Lu wrote:
The predictive commoning patch:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01061.html
miscompiles 482.sphinx3 in SPEC CPU 2006 with -O2 -ffast-math on
Linux/x86-64. Zdenek, do you have
Hi,
addition of alloc_size attribute to the changes.html.
Ciao, Marcus
Index: htdocs/gcc-4.3/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/changes.html,v
retrieving revision 1.57
diff -u -r1.57 changes.html
---
On Fri, Jun 01, 2007 at 06:28:52PM +0200, Marcus Meissner wrote:
Hi,
addition of alloc_size attribute to the changes.html.
Ciao, Marcus
Less plugging of examples as suggested by Dirk...
Index: htdocs/gcc-4.3/changes.html
===
On Fri, Jun 01, 2007 at 09:55:53AM -0700, Andrew Pinski wrote:
Because the patch had other effects like adding a DCE after Copyprop
in the loop optimizer section.
Disable DCE after Copyprop in the loop optimizer section fixes my
problem. Any idea why?
Thanks.
H.J.
On 6/1/07, H. J. Lu [EMAIL PROTECTED] wrote:
On Fri, Jun 01, 2007 at 09:55:53AM -0700, Andrew Pinski wrote:
Because the patch had other effects like adding a DCE after Copyprop
in the loop optimizer section.
Disable DCE after Copyprop in the loop optimizer section fixes my
problem. Any idea
Hi.
What is purpose of introducing numbered variables kind of a.0 a.1...in
pre-SSA pass, which are actually copies of local variable say a.
I observed them specially in array references.
In case of global variable it is fine as we have to re-read global
variable and globals are treated as memory
Hello,
Because the patch had other effects like adding a DCE after Copyprop
in the loop optimizer section.
Disable DCE after Copyprop in the loop optimizer section fixes my
problem. Any idea why?
no, not really; it could be anything (it may even have nothing to do
with dce, performing
On Fri, Jun 01, 2007 at 10:30:52PM +0200, Zdenek Dvorak wrote:
Hello,
Because the patch had other effects like adding a DCE after Copyprop
in the loop optimizer section.
Disable DCE after Copyprop in the loop optimizer section fixes my
problem. Any idea why?
no, not really;
On 01 Jun 2007 07:22:39 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Mohamed Shafi [EMAIL PROTECTED] writes:
I am working with a private target(GCC v4.1.1).
For my target the function arguments are passed through registers.
For this purpose 4 registers are used. If the no. of arguments
Mohamed Shafi [EMAIL PROTECTED] writes:
On 01 Jun 2007 07:22:39 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Mohamed Shafi [EMAIL PROTECTED] writes:
I am working with a private target(GCC v4.1.1).
For my target the function arguments are passed through registers.
For this
Ive been working on a c program that does the error
condition check in the beginning as follows,
char *fun(str)
const char *str;
{
if (str == NULL) -- Error check, taking the const char variable directly.
printf(Null string \n);
..
}
But the code fails to perform the error
--- Comment #12 from ubizjak at gmail dot com 2007-06-01 06:42 ---
*** Bug 32123 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2007-06-01 06:42 ---
*** This bug has been marked as a duplicate of 26449 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #11 from ubizjak at gmail dot com 2007-06-01 06:42 ---
New test (from PR32123):
Standalone testcase, compile with -O2 -msse2 -mtune=k8:
--cut here--
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__
--- Comment #10 from ubizjak at gmail dot com 2007-06-01 06:39 ---
Not fixed, please look for the same failure at PR32123.
start_sequence ();
op = force_operand (SET_SRC (set), reg);
+ if (!op)
+ {
+ end_sequence ();
+ goto
--- Comment #5 from eres at il dot ibm dot com 2007-06-01 06:24 ---
(In reply to comment #3)
*** This bug has been marked as a duplicate of 28684 ***
Related, but a different issue.
I Agree. Bug 28684 mainly deals with the need to redefine
-funsafe-math-optimizations as IEEE
--- Comment #5 from patchapp at dberlin dot org 2007-06-01 07:05 ---
Subject: Bug number PR 27078
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg8.html
--
reduced from CP2K (PR 29975)
gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
gcc version 4.3.0 20070531 (experimental)
gfortran -fprefetch-loop-arrays -O2 test.f90
test.f90: In function polint:
test.f90:1: internal compiler error: tree check: expected integer_cst, have
--- Comment #105 from jv244 at cam dot ac dot uk 2007-06-01 07:08 ---
Another ICE has been filed as PR 32176
gfortran -fprefetch-loop-arrays -O2 test.f90
test.f90: In function polint:
test.f90:1: internal compiler error: tree check: expected integer_cst, have
plus_expr in
--- Comment #13 from ubizjak at gmail dot com 2007-06-01 07:29 ---
(In reply to comment #11)
New test (from PR32123):
Standalone testcase, compile with -O2 -msse2 -mtune=k8:
Hm, this bug was misteriously fixed. It was manifested as
gcc.target/i386/sse2-vec-6.c failure in [1] and
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-01 07:49 ---
While the assert is occurs in the middle end, I think it is very likely a
tree-type mismatch in the front end.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from mikael dot morin at tele2 dot fr 2007-06-01 10:57
---
Ok, placing the function in a contains statement still reproduces the bug with
4.1.2, but doesn't compile with 4.3, complaining about the wrong size
of the string arguments.
And using variable size strings
--- Comment #2 from kmanjunat at gmail dot com 2007-06-01 07:52 ---
The test case is being called from a shared library with the
eabi support using dlopen.
The following is the test case
#include stdio.h
#include string.h
#include malloc.h
int main()
{
char *a=NULL;
char *b=abcd;
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2007-06-01 10:22 ---
Created an attachment (id=13644)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13644action=view)
The source code showing the potential bug
--
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-01 11:06 ---
reduced:
SUBROUTINE polint(n)
INTEGER, PARAMETER :: dp=KIND(0.0D0)
REAL(dp) :: ya(n), xa(n), x
DO m = 1,n-1
DO i = 1,n-m
ho=xa(i)-x
hp=xa(i+m)-x
den=ho-hp
This is with gcc version 4.3.0 20070528 (experimental) and gcc-4.1.1 (redhat
FC5 version). I suspect it is also true for all intermediate versions...
The attached program when compiled with g++ and the flags -fopenmp gives the
following diagnostic and aborts compilation:
futuna-
--- Comment #5 from kloedej at knmi dot nl 2007-06-01 08:41 ---
(In reply to comment #1)
for integer overflows, see e.g.
https://www.cisl.ucar.edu/docs/ibm/ref/fpe.html
For x86 (32/64) platforms, this does not seem to be directly supported by
hardware; in this case one would need to
--- Comment #8 from pcarlini at suse dot de 2007-06-01 08:49 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-01 11:19 ---
*** This bug has been marked as a duplicate of 32166 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-01 11:19 ---
*** Bug 32174 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32166
First here is my gcc -v output:
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--- Comment #1 from henne at nachtwindheim dot de 2007-06-01 11:38 ---
Created an attachment (id=13645)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13645action=view)
The eample snippet.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32178
--- Comment #9 from burnus at gcc dot gnu dot org 2007-06-01 11:36 ---
Indeed, the compiler should report an error ; but it is just an improvement.
Still much to learn about Fortran ;)
In Fortran, subroutines and functions in the same file have nothing to do with
each another if they
--- Comment #32 from kazssym at nifty dot com 2007-06-01 12:24 ---
If Bug 21706 is fixed, it can be built without defining _ALL_SOURCE even on
Interix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-01 11:28 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-01 11:19 ---
*** This bug has been marked as a duplicate of 32166 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-01 11:19 ---
*** Bug 32175 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32166
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-01 11:23 ---
#2 0x00a30ddc in int_cst_value (x=0x2b8d9ea73780)
at /space/rguenther/src/svn/trunk/gcc/tree.c:7720
7720 unsigned HOST_WIDE_INT val = TREE_INT_CST_LOW (x);
(gdb) call debug_generic_expr (x)
(int8)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-01 11:28 ---
We have a
with_cleanup_expr 0x2aadb4071380
type void_type 0x2aadb3ecf240 void VOID
align 8 symtab 0 alias set -1 canonical type 0x2aadb3ecf240
pointer_to_this pointer_type 0x2aadb3ecf300
--- Comment #33 from markus dot duft at salomon dot at 2007-06-01 12:32
---
(In reply to comment #32)
If Bug 21706 is fixed, it can be built without defining _ALL_SOURCE even on
Interix.
are you sure? my experiences with interix tell me to almost allways enable
_ALL_SOURCE, or not
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-01 14:14 ---
Your inline-asm is broken, you early clobber the output so you need to mark as
such like:
asm volatile(movl $1,%0 \n\t \
xchgl %0,%1 \n\t \
xorl $1,%0
:
--- Comment #1 from ian at gcc dot gnu dot org 2007-06-01 15:06 ---
Subject: Bug 31455
Author: ian
Date: Fri Jun 1 15:06:19 2007
New Revision: 125265
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125265
Log:
PR rtl-optimization/31455
* lower-subreg.c
--- Comment #2 from ian at airs dot com 2007-06-01 15:09 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #10 from burnus at gcc dot gnu dot org 2007-06-01 15:21 ---
As gfortran seems to do everything as required by the Fortran standard (or at
least other compilers do the same ;-), this no bug.
It it only missing whole-file interface checking. As this enhancement is
tracked in
--- Comment #10 from burnus at gcc dot gnu dot org 2007-06-01 15:21 ---
*** Bug 32170 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
GCC 4.3.0 compiled on Linux does NOT pass as many tests as GCC 3.4.4 for
Cygwin.
How seriously will people take _newer_ versions gcc if it can't pass the same
tests as older versions did. Something has slipped over the years.
Now that I have a great compiler I decide to do some tests to see how
--- Comment #34 from kazssym at nifty dot com 2007-06-01 15:39 ---
(In reply to comment #33)
(In reply to comment #32)
If Bug 21706 is fixed, it can be built without defining _ALL_SOURCE even on
Interix.
are you sure? my experiences with interix tell me to almost allways enable
Just to now forget ...
To the patch to PR 32156, Paul Thomas wrote in
http://gcc.gnu.org/ml/fortran/2007-05/msg00531.html :
There is something not right with string concatenation
in the front-end that fails to transmit the string length correctly.
I have made several attempts to get to the
--- Comment #11 from bkoz at gcc dot gnu dot org 2007-06-01 16:35 ---
Subject: Bug 31717
Author: bkoz
Date: Fri Jun 1 16:35:34 2007
New Revision: 125266
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125266
Log:
2007-05-28 Benjamin Kosnik [EMAIL PROTECTED]
PR
The following program prints FAILED; it should print PASSED
as per RM 3.4(27), which states:
-- For the execution of a call on an inherited subprogram,
-- a call on the corresponding primitive subprogram of the
-- parent or progenitor type is performed; the normal conversion
-- of each actual
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-01 16:15 ---
Can you try with -ffloat-store, this might be the normal x87 issue (see PR
323).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-01 16:01 ---
Just to now forget ...
A Freudian slip, I presume. This should of cause be:
Just to NOT forget [to fix it]...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32179
--- Comment #6 from rask at sygehus dot dk 2007-06-01 19:56 ---
According to the documentation, -B passes -L to the linker, so there is no need
to pass both. It seems to work as documented.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
I may have found a situation where GCC's optimizations causes a constructor to
be skipped that leads to a crash. This problem first manifested itself in a
program involving well over 10 lines of code (not including the extra lines
from #include'd files). The initial problem is in code
--- Comment #1 from epperly2 at llnl dot gov 2007-06-01 20:44 ---
Created an attachment (id=13646)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13646action=view)
tar file containing complete source to reproduce problem
% sha1sum bug32182.tar.bz2
--- Comment #2 from epperly2 at llnl dot gov 2007-06-01 20:53 ---
To avoid depending on system #include files, the example has
typedef unsigned int size_t;
hardwired in the code. This may be an incorrect definition for some platforms.
Oddly enough, if I delete NextClass and make
--- Comment #3 from epperly2 at llnl dot gov 2007-06-01 21:07 ---
The Babel bug tracking entry corresponding to this GCC issue report is here:
https://www.cca-forum.org/bugs/babel/issue480
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
--- Comment #5 from epperly2 at llnl dot gov 2007-06-01 21:24 ---
In response to comment #4, I may be violating C++ aliasing rules, but I don't
see how that explains the behavior I am seeing and where I am seeing it. How
could aliasing analysis give the compiler permission to skip
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-01 21:16 ---
I am thinking you are volating C++ aliasing rules (though if you convert the
static casts over to placement news it will not work either but that is PR
29286).
--
With -O2 -ffast-math on Linux/x86-64, I got
Running (#1) 482.sphinx3 ref base o2 default
Error with '/export/spec/src/2006/spec/bin/specinvoke -E -d
/export/spec/src/2006/spec/benchspec/CPU2006/482.sphinx3/run/run_base_ref_o2.
-c 1 -e compare.err -o compare.stdout -f compare.cmd': check
--- Comment #6 from epperly2 at llnl dot gov 2007-06-01 22:04 ---
Created an attachment (id=13647)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13647action=view)
An example involving less casting than the previous one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
--- Comment #7 from epperly2 at llnl dot gov 2007-06-01 22:12 ---
Created an attachment (id=13648)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13648action=view)
A further simplified example showing the problem without any C++ casting
--
--- Comment #1 from hjl at lucon dot org 2007-06-01 22:13 ---
Created an attachment (id=13649)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13649action=view)
A testcase
This testcase has 2 assembly files compiled with -O2 -ffast-math. good.s is
good and bad.s is bad.
--
--- Comment #8 from epperly2 at llnl dot gov 2007-06-01 22:14 ---
I've simplified the sample case that demonstrates the problem, and it has *no*
casting in C++. In C, it casts the result of malloc to the appropriate pointer
type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
--- Comment #2 from hjl at lucon dot org 2007-06-01 23:09 ---
Is that OK to transform
float sf;
...
sf = 500 * sf;
for (i = 0; i ceplen; i++)
sum[i] *= sf;
to
for (i = 0; i ceplen; i++)
sum[i] = (sum[i]* 500)*sf;
You can certainly get
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-06-01 23:13 ---
(In reply to comment #2)
Is that OK to transform
float sf;
...
sf = 500 * sf;
for (i = 0; i ceplen; i++)
sum[i] *= sf;
to
for (i = 0; i ceplen; i++)
--- Comment #9 from epperly2 at llnl dot gov 2007-06-01 23:24 ---
Created an attachment (id=13650)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13650action=view)
The function pointer in RefCount_t can be removed too
This is a smaller program that removes a couple function pointer
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-01 23:57
---
test_3 works for me on the trunk on i686-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-02 00:01 ---
So this is not a wrong code, just a missed optimization.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-06-02 00:06
---
Here is an other test case.
program testCode
implicit none
type vec
real, dimension(3) :: coords
end type
integer, parameter :: n = 5
integer :: i
real,
--with-stabs --enable-hash-synchronization --enable-gc-debug
--enable-interpreter --with-system-zlib --enable-libada --with-tls
--with-cpu=athlon-xp --with-arch=athlon-xp
--enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree
Thread model: posix
gcc version 4.3.0 20070601 (experimental
--- Comment #5 from hjl at lucon dot org 2007-06-02 00:10 ---
(In reply to comment #3)
(In reply to comment #2)
Is that OK to transform
float sf;
...
sf = 500 * sf;
for (i = 0; i ceplen; i++)
sum[i] *= sf;
to
for (i = 0; i
1 - 100 of 115 matches
Mail list logo
