Following my commit of the patch for PR29786, I did a further regtest,
which produced a good number of fortran testsuite failures. Being
late, I put it out of its misery. I reverted to before my patch
(r125628) and find that the failures are still there. For example,
$ /irun/bin/gfortran $test
Hello,
In file loop_doloop.c function doloop_condition_get makes sure that
the condition is GE or NE
otherwise it prevents doloop optimizations. This caused a problem for
a loop which had NE condition without unrolling and EQ if unrolling
was run. Can I make doloop work after the unroller?
Thank
Hello,
> In file loop_doloop.c function doloop_condition_get makes sure that
> the condition is GE or NE
> otherwise it prevents doloop optimizations. This caused a problem for
> a loop which had NE condition without unrolling and EQ if unrolling
> was run.
actually, doloop_condition_get is not a
On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
on x86_64 some performance regressions with Botan (a collection of
cryptographic algorithms (see
http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
small enough to investigate, but wait another day in case its ju
You will excuse me please if I cannot identify the patch that is
responsible - this sort of investigation is just a bit too tedious
under Cygwin. I will make one further reversion this morning and will
report if I have bracketed the problem.
The problem is between r125620 and r125628 but is NO
> The engine only knew how to propagate cases that always make the same
> set of vdef/vuses, so it was safe to only tell it to use the first
> vdef.
>
> /* Note that for propagation purposes, we are only interested in
> visiting statements that load the exact same memory reference
>
The problem is between r125620 and r125628 but is NOT, as I
suspected, r125621.
Is nobody else seeing it, or is it a Cygwin specific problem?
ia64-linux testresults with rev. 12640 appear to be fine (http://
gcc.gnu.org/ml/gcc-testresults/2007-06/msg00572.html).
Doh, wait, it appears that
Thanks,
To make sure I understood you correctly, does it mean that the change
(below in /* */) in doloop_condition_get is safe?
/* We expect a GE or NE comparison with 0 or 1. */
if (/*(GET_CODE (condition) != GE
&& GET_CODE (condition) != NE)
||*/ (XEXP (condition, 1) != const0_rt
On 12 June 2007 13:13, Paul Richard Thomas wrote:
>> You will excuse me please if I cannot identify the patch that is
>> responsible - this sort of investigation is just a bit too tedious
>> under Cygwin. I will make one further reversion this morning and will
>> report if I have bracketed the pr
Hi all,
I have added two new data types for GCC 4.1.1 (for private target).
They are fixed and accum.
Variants of fixed are,
short fixed (1 byte)
fixed (4 byte)
long fixed (8 byte).
While passing short fixed as a function argument, i want to promote it
to fixed type. I tried using PROMOTE_FUNC
Hello,
> To make sure I understood you correctly, does it mean that the change
> (below in /* */) in doloop_condition_get is safe?
>
> /* We expect a GE or NE comparison with 0 or 1. */
> if (/*(GET_CODE (condition) != GE
> && GET_CODE (condition) != NE)
> ||*/ (XEXP (condition, 1)
Richard Guenther wrote:
> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
> on x86_64 some performance regressions with Botan (a collection of
> cryptographic algorithms (see
> http://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably
> small enough to investigate, bu
On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
> Richard Guenther wrote:
> > On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
> > on x86_64 some performance regressions with Botan (a collection of
> > cryptographic algorithms (see
> > http://www.suse.de/~gcctest/c++bench/botan/)) -
On 12 June 2007 15:05, Kenneth Zadeck wrote:
> Richard Guenther wrote:
>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
>> on x86_64 some performance regressions with Botan (a collection of
>> cryptographic algorithms (see
>> http://www.suse.de/~gcctest/c++bench/botan/)) - tho
Richard Guenther wrote:
> On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
>
>
>> Richard Guenther wrote:
>>
>>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
>>> on x86_64 some performance regressions with Botan (a collection of
>>> cryptographic algorithms (see
>>> http://
On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
> Richard Guenther wrote:
> > On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
> >
> >
> >> Richard Guenther wrote:
> >>
> >>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
> >>> on x86_64 some performance regressions with Botan (a
Hello,
I appreciate your help in figuring what is considered a valid sequence
of operations for creating a new variable in the tree level.
Is the following sequence OK -
tmp_var = create_tmp_var (type, "_new_");
add_referenced_tmp_var (tmp_var);
mark_sym_for_renaming (tmp_var);
Or should I
Dave Korn wrote:
> On 12 June 2007 15:05, Kenneth Zadeck wrote:
>
>
>> Richard Guenther wrote:
>>
>>> On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
>>> on x86_64 some performance regressions with Botan (a collection of
>>> cryptographic algorithms (see
>>> http://www.su
On 6/12/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
Hello,
I appreciate your help in figuring what is considered a valid sequence
of operations for creating a new variable in the tree level.
Is the following sequence OK -
tmp_var = create_tmp_var (type, "_new_");
add_referenced_tmp_var (tm
On 12 June 2007 15:55, Kenneth Zadeck wrote:
> Dave Korn wrote:
>> On 12 June 2007 15:05, Kenneth Zadeck wrote:
>>> Richard Guenther wrote:
>>>
On ia64 SPEC2000 I see fma3d and applu now miscompare, and we have
on x86_64 some performance regressions with Botan (a collection of
cryp
On Tue, 12 Jun 2007, Richard Guenther wrote:
>
> On ia64 SPEC2000 I see fma3d and applu now miscompare.
On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
/gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
zscal.o-fprofile-use -O2 -ffast-math zscal.
Hmm, this looks like a dataflow bug to me. I believe the problem is that
DF_LIVE_OUT assumes/requires problems_by_index[DF_LIVE] to be non-NULL.
You should replace it with df_get_live_out. Please CC me if you have a
patch.
Paolo
On 6/12/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On Tue, 12 Jun 2007, Richard Guenther wrote:
>
> On ia64 SPEC2000 I see fma3d and applu now miscompare.
On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
/gcc/spec/sb-haydn-fdo-64/x86_64/install-200706120559/bin/gfortran -c -o
zsca
Seongbae Park (???, ???) wrote:
> On 6/12/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
>> On Tue, 12 Jun 2007, Richard Guenther wrote:
>>
>> >
>> > On ia64 SPEC2000 I see fma3d and applu now miscompare.
>>
>> On x86_64 186.wupwise ICEs with -O2 -ffast-math and FDO:
>>
>> /gcc/spec/sb-haydn-fdo-6
I'm getting a new bootstrap failure today on sparc-sun-solaris2.10 which
I've filed under PR bootstrap/32312. GCC dies in stage1 building libgcc2,
I see that it's getting a SEGV because the variable "df" is nil. It might
be related to the dataflow merge.
There's an attachment in the PR, would yo
Kaveh R. GHAZI wrote:
> I'm getting a new bootstrap failure today on sparc-sun-solaris2.10 which
> I've filed under PR bootstrap/32312. GCC dies in stage1 building libgcc2,
> I see that it's getting a SEGV because the variable "df" is nil. It might
> be related to the dataflow merge.
>
> There's
The information is here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
David Daney
Hi All.
I'm trying to get access to .dynamic section of executable in from my
shared library. I'm using _DYNAMIC pointer. But, according to objdump
output, it points to .dynamic section of library instead of executable.
I've made investigations an found out that every object file(executable
of
On 6/12/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
> The engine only knew how to propagate cases that always make the same
> set of vdef/vuses, so it was safe to only tell it to use the first
> vdef.
>
> /* Note that for propagation purposes, we are only interested in
> visiting stat
29 matches
Mail list logo
