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
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
The information is here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313
David Daney
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
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
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
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
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 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.
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 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
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
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
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
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 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
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/)) -
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
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)
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
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
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
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
> 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
>
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
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
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
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
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
29 matches
Mail list logo
