Large number of fortran testsuite failures
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/sizeof.f90 /cygdrive/d/svn/trunk/gcc/testsuite/gfortran.dg/sizeof.f90: In function 'check_r eal': /cygdrive/d/svn/trunk/gcc/testsuite/gfortran.dg/sizeof.f90:37: internal compiler error: Segmentation fault f951, run under gdb, runs to completion, so the problem is further towards the backend. I regested earlier last night and all was well (sorry, I did not record the revision #), so the problem has creapt in over a very small number of patches. 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. I do not know if there are other gcc regressions. Cheers Paul
Does unrolling prevents doloop optimizations?
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?
Thanks,
Vladimir
Without unrolling:
(insn 135 80 136 4 (set (reg:SI 204 [ LastIndex ])
(plus:SI (reg:SI 204 [ LastIndex ])
(const_int -1 [0x]))) 51 {addsi3} (nil)
(nil))
(jump_insn 136 135 84 4 (set (pc)
(if_then_else (ne:SI (reg:SI 204 [ LastIndex ])
(const_int 0 [0x0]))
(label_ref:SI 69)
(pc))) 368 {*spu.md:3288} (insn_list:REG_DEP_TRUE 135 (nil))
(expr_list:REG_BR_PROB (const_int 9000 [0x2328])
(nil)))
After unrolling:
(insn 445 421 446 21 (set (reg:SI 213)
(plus:SI (reg:SI 213)
(const_int -1 [0x]))) 51 {addsi3} (nil)
(nil))
(jump_insn 446 445 667 21 (set (pc)
(if_then_else (eq:SI (reg:SI 213)
(const_int 0 [0x0]))
(label_ref:SI 465)
(pc))) 368 {*spu.md:3288} (insn_list:REG_DEP_TRUE 445 (nil))
(expr_list:REG_BR_PROB (const_int 1000 [0x3e8])
(nil)))
Re: Does unrolling prevents doloop optimizations?
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 applied to the code of the
program, so this change is irrelevant (doloop_condition_get is applied
to the doloop pattern from the machine description). So there must be
some other reason why doloop transformation is not applied for your
loop.
Zdenek
> Can I make doloop work after the unroller?
>
> Thanks,
> Vladimir
>
>
> Without unrolling:
> (insn 135 80 136 4 (set (reg:SI 204 [ LastIndex ])
>(plus:SI (reg:SI 204 [ LastIndex ])
>(const_int -1 [0x]))) 51 {addsi3} (nil)
>(nil))
>
> (jump_insn 136 135 84 4 (set (pc)
>(if_then_else (ne:SI (reg:SI 204 [ LastIndex ])
>(const_int 0 [0x0]))
>(label_ref:SI 69)
>(pc))) 368 {*spu.md:3288} (insn_list:REG_DEP_TRUE 135 (nil))
>(expr_list:REG_BR_PROB (const_int 9000 [0x2328])
>(nil)))
>
>
> After unrolling:
> (insn 445 421 446 21 (set (reg:SI 213)
>(plus:SI (reg:SI 213)
>(const_int -1 [0x]))) 51 {addsi3} (nil)
>(nil))
>
> (jump_insn 446 445 667 21 (set (pc)
>(if_then_else (eq:SI (reg:SI 213)
>(const_int 0 [0x0]))
>(label_ref:SI 465)
>(pc))) 368 {*spu.md:3288} (insn_list:REG_DEP_TRUE 445 (nil))
>(expr_list:REG_BR_PROB (const_int 1000 [0x3e8])
>(nil)))
Some regressions from the dataflow merge
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 just noise. Otherwise things look smooth as expected. Richard.
Re: Large number of fortran testsuite failures
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 NOT, as I suspected, r125621. Is nobody else seeing it, or is it a Cygwin specific problem? Paul
Re: Help in understanding ccp propagator
> 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
> stored here. Those statements will have the exact same list
> of virtual uses, so it is enough to set the output of this
> statement to be its first virtual definition. */
>
>
> You are changing this, AFAIK, so you will need to make it handle
> multiple output values.
>
That's indeed the problem:
Consider the following stmt that is been visited -
# MPT.1416_722 = VDEF { MPT.1416 }
D.61410.first = i0_62;
Than output_p will be set to MPT.1416_722 (which is the
only vdef of this stmt) -
*output_p = first_vdef (stmt);
And later on (in add_ssa_edge () function) all the uses of MPT.1416_722
will be added to the working set which in our case is D.61410.second =
97; statement instead of the real uses of D.61410.first.
# MPT.1416_723 = VDEF { MPT.1416 }
D.61410.second = 97;
Is there a way to retrieve the real uses of D.61410.first?
Thanks again,
Revital
Re: Large number of fortran testsuite failures
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 rev. 125624 is the dataflow merge. Although it doesn't appear to touch specific cygwin files, it certainly is a commit with sufficiently high order-of-magnitude that it can disrupt a few seemingly unrelated code paths. Maybe it's worth trying to bracket that one? (although I know cygwin bootstrap is awfully slow) FX
Re: Does unrolling prevents doloop optimizations?
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_rtx
&& XEXP (condition, 1) != const1_rtx))
return 0;
Thanks,
Vladimir
On 6/12/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
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 applied to the code of the
program, so this change is irrelevant (doloop_condition_get is applied
to the doloop pattern from the machine description). So there must be
some other reason why doloop transformation is not applied for your
loop.
Zdenek
> Can I make doloop work after the unroller?
>
> Thanks,
> Vladimir
>
>
> Without unrolling:
> (insn 135 80 136 4 (set (reg:SI 204 [ LastIndex ])
>(plus:SI (reg:SI 204 [ LastIndex ])
>(const_int -1 [0x]))) 51 {addsi3} (nil)
>(nil))
>
> (jump_insn 136 135 84 4 (set (pc)
>(if_then_else (ne:SI (reg:SI 204 [ LastIndex ])
>(const_int 0 [0x0]))
>(label_ref:SI 69)
>(pc))) 368 {*spu.md:3288} (insn_list:REG_DEP_TRUE 135 (nil))
>(expr_list:REG_BR_PROB (const_int 9000 [0x2328])
>(nil)))
>
>
> After unrolling:
> (insn 445 421 446 21 (set (reg:SI 213)
>(plus:SI (reg:SI 213)
>(const_int -1 [0x]))) 51 {addsi3} (nil)
>(nil))
>
> (jump_insn 446 445 667 21 (set (pc)
>(if_then_else (eq:SI (reg:SI 213)
>(const_int 0 [0x0]))
>(label_ref:SI 465)
>(pc))) 368 {*spu.md:3288} (insn_list:REG_DEP_TRUE 445 (nil))
>(expr_list:REG_BR_PROB (const_int 1000 [0x3e8])
>(nil)))
Dataflow bug [RE: Large number of fortran testsuite failures]
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 problem.
>>
>
> 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?
Dunno, because I'm on cygwin too. Stack gots messed up:
Program received signal SIGSEGV, Segmentation fault.
0x004ecbee in ix86_expand_prologue () at /gnu/gcc/gcc/gcc/df.h:973
973 if (index < df_live->block_info_size)
(gdb) bt
#0 0x004ecbee in ix86_expand_prologue () at /gnu/gcc/gcc/gcc/df.h:973
#1 0x0079a71f in gen_prologue ()
at /gnu/gcc/gcc/gcc/config/i386/i386.md:14460
#2 0x0023c938 in ?? ()
#3 0x006174b6 in thread_prologue_and_epilogue_insns ()
at /gnu/gcc/gcc/gcc/function.c:5060
#4 0x in ?? ()
(gdb)
By breaking on thread_prologue_and_epilogue_insns, you can see the whole
thing before the segfault:
Breakpoint 1, thread_prologue_and_epilogue_insns ()
at /gnu/gcc/gcc/gcc/function.c:5059
5059 start_sequence ();
(gdb) c
Continuing.
Breakpoint 1, thread_prologue_and_epilogue_insns ()
at /gnu/gcc/gcc/gcc/function.c:5059
5059 start_sequence ();
(gdb) bt
#0 thread_prologue_and_epilogue_insns () at /gnu/gcc/gcc/gcc/function.c:5059
#1 0x006180d0 in rest_of_handle_thread_prologue_and_epilogue ()
at /gnu/gcc/gcc/gcc/function.c:5485
#2 0x006a77ef in execute_one_pass (pass=0xa8d9b0)
at /gnu/gcc/gcc/gcc/passes.c:1123
#3 0x006a79e7 in execute_pass_list (pass=0xa90e40)
at /gnu/gcc/gcc/gcc/passes.c:1176
#4 0x006a79fa in execute_pass_list (pass=0xa8d930)
at /gnu/gcc/gcc/gcc/passes.c:1177
#5 0x006a79fa in execute_pass_list (pass=0xa8d7e0)
at /gnu/gcc/gcc/gcc/passes.c:1177
#6 0x006bdb9f in tree_rest_of_compilation (fndecl=0x7fe3bc00)
at /gnu/gcc/gcc/gcc/tree-optimize.c:406
#7 0x006a9431 in cgraph_expand_function (node=0x7fe3bd00)
at /gnu/gcc/gcc/gcc/cgraphunit.c:1073
#8 0x006aa710 in cgraph_assemble_pending_functions ()
at /gnu/gcc/gcc/gcc/cgraphunit.c:436
#9 0x006aab95 in cgraph_finalize_function (decl=0x7fe3bc00, nested=0)
at /gnu/gcc/gcc/gcc/cgraphunit.c:553
#10 0x004818d6 in gfc_generate_function_code (ns=0x1ab44a0)
at /gnu/gcc/gcc/gcc/fortran/trans-decl.c:3285
#11 0x00443d23 in gfc_parse_file () at /gnu/gcc/gcc/gcc/fortran/parse.c:3272
#12 0x00464940 in gfc_be_parse_file (set_yydebug=0)
at /gnu/gcc/gcc/gcc/fortran/f95-lang.c:301
#13 0x0050e5a5 in toplev_main (argc=15, argv=0x1a78f18)
at /gnu/gcc/gcc/gcc/toplev.c:1051
#14 0x004a8cef in main (argc=2346392, argv=0x61006148)
at /gnu/gcc/gcc/gcc/main.c:35
From there we go to gen_prologue. The stack isn't actually messed up, gdb
just seems to have trouble tracing back through a function derived from the md
file. gen_prologue calls ix86_expand_prologue and I stepped through that for
a bit:
(gdb) s
ix86_expand_prologue () at /gnu/gcc/gcc/gcc/config/i386/i386.c:5974
5974 ix86_compute_frame_layout (&frame);
(gdb) bt
#0 ix86_expand_prologue () at /gnu/gcc/gcc/gcc/config/i386/i386.c:5974
#1 0x0079a71f in gen_prologue ()
at /gnu/gcc/gcc/gcc/config/i386/i386.md:14460
#2 0x0023c938 in ?? ()
#3 0x006174b6 in thread_prologue_and_epilogue_insns ()
at /gnu/gcc/gcc/gcc/function.c:5060
#4 0x in ?? ()
(gdb) n
5976 if (cfun->machine->force_align_arg_pointer)
(gdb) print cfun
$2 = (struct function *) 0x7ff60348
(gdb) print *cfun
$3 = {eh = 0x7ff404d0, expr = 0x7fe5ad80, emit = 0x7ff72820,
varasm = 0x7ff115a8, cfg = 0x7fe5ab60, gimple_df = 0x0,
x_current_loops = 0x0, value_histograms = 0x0, decl = 0x7fe3bc00,
outer = 0x0, pops_args = 0, args_size = 8, pretend_args_size = 0,
outgoing_args_size = 0, arg_offset_rtx = 0x7ff10250, args_info = {
words = 2, nregs = 0, regno = 0, fastcall = 0, sse_words = 0,
sse_nregs = 0, warn_sse = 1, warn_mmx = 1, sse_regno = 0, mmx_words = 0,
mmx_nregs = 0, mmx_regno = 0, maybe_vaarg = 0, float_in_sse = 0},
return_rtx = 0x0, internal_arg_pointer = 0x7ff20040,
hard_reg_initial_vals = 0x0, x_nonlocal_goto_handler_labels = 0x0,
x_return_label = 0x0, x_naked_return_label = 0x0,
x_stack_slot_list = 0x7fe88b70, x_stack_check_probe_note = 0x0,
x_arg_pointer_save_area = 0x0, x_frame_offset = -32352,
static_chain_decl = 0x0, nonlocal_goto_save_area = 0x0,
x_parm_birth_insn = 0x7fe5aee0, x_used_temp_slots = 0x7fe83bd0,
x_avail_temp_slots = 0x0, fixup_var_refs_queue = 0x0,
x_temp_slot_level = 0, inl_max_label_num = 0, funcdef_no = 3,
machine = 0x7ff71740, stack_alignment_needed = 64,
preferred_stack_boundary = 128, language = 0x0, used_types_hash = 0x0,
epilogue_delay_list = 0x0, max_jumptable_ents = 0, last_label_uid = 8,
function_end_locus = {
file = 0x1a8dbc0 "/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/siz
promoting function arguments - GCC 4.1.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_FUNCTION_MODE. But it is not getting invoked. Is there any other target hook used for doing this? Regards, Rohit
Re: Does unrolling prevents doloop optimizations?
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) != const0_rtx
> && XEXP (condition, 1) != const1_rtx))
>return 0;
no; that there is nothing wrong with doloop_condition_get --
changing it will not help, as it is not applied to the
exit condition of the loop at all. The problem must be somewhere
else.
Zdenek
> Thanks,
> Vladimir
>
>
> On 6/12/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> >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 applied to the code of the
> >program, so this change is irrelevant (doloop_condition_get is applied
> >to the doloop pattern from the machine description). So there must be
> >some other reason why doloop transformation is not applied for your
> >loop.
> >
> >Zdenek
> >
> >> Can I make doloop work after the unroller?
> >>
> >> Thanks,
> >> Vladimir
> >>
> >>
> >
> >> Without unrolling:
> >> (insn 135 80 136 4 (set (reg:SI 204 [ LastIndex ])
> >>(plus:SI (reg:SI 204 [ LastIndex ])
> >>(const_int -1 [0x]))) 51 {addsi3} (nil)
> >>(nil))
> >>
> >> (jump_insn 136 135 84 4 (set (pc)
> >>(if_then_else (ne:SI (reg:SI 204 [ LastIndex ])
> >>(const_int 0 [0x0]))
> >>(label_ref:SI 69)
> >>(pc))) 368 {*spu.md:3288} (insn_list:REG_DEP_TRUE 135 (nil))
> >>(expr_list:REG_BR_PROB (const_int 9000 [0x2328])
> >>(nil)))
> >>
> >>
> >> After unrolling:
> >> (insn 445 421 446 21 (set (reg:SI 213)
> >>(plus:SI (reg:SI 213)
> >>(const_int -1 [0x]))) 51 {addsi3} (nil)
> >>(nil))
> >>
> >> (jump_insn 446 445 667 21 (set (pc)
> >>(if_then_else (eq:SI (reg:SI 213)
> >>(const_int 0 [0x0]))
> >>(label_ref:SI 465)
> >>(pc))) 368 {*spu.md:3288} (insn_list:REG_DEP_TRUE 445 (nil))
> >>(expr_list:REG_BR_PROB (const_int 1000 [0x3e8])
> >>(nil)))
> >
Re: Some regressions from the dataflow merge
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, but wait another day in case its just noise. > > Otherwise things look smooth as expected. > > Richard. > I looked at the graphs here and i do not see a regression except in the compile time. kenny
Re: Some regressions from the dataflow merge
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/)) - those are reasonably > > small enough to investigate, but wait another day in case its just noise. > > > > Otherwise things look smooth as expected. > > > > Richard. > > > I looked at the graphs here and i do not see a regression except in the > compile time. Note the graphs are for Throughput, so higher numbers are better. Look for example at Serpent or Skipjack at http://www.suse.de/~gcctest/c++bench/botan/botan-summary.txt-1-0.html (which has separate graphs for each algorithm). But as I said - just wait a day to see if it is noise. Richard.
RE: Some regressions from the dataflow merge
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/)) - those are reasonably small >> enough to investigate, but wait another day in case its just noise. >> >> Otherwise things look smooth as expected. >> >> Richard. >> > I looked at the graphs here and i do not see a regression except in the > compile time. Fortran has a testcase that trips one on x86/cygwin: see http://gcc.gnu.org/ml/gcc/2007-06/msg00291.html. Perhaps you can comment on whether df_live (== df->problems_by_index[DF_LIVE]) should ever be NULL? cheers, DaveK -- Can't think of a witty .sigline today
Re: Some regressions from the dataflow merge
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://www.suse.de/~gcctest/c++bench/botan/)) - those are reasonably >>> small enough to investigate, but wait another day in case its just noise. >>> >>> Otherwise things look smooth as expected. >>> >>> Richard. >>> >>> >> I looked at the graphs here and i do not see a regression except in the >> compile time. >> > > Note the graphs are for Throughput, so higher numbers are better. Look > for example at Serpent or Skipjack at > http://www.suse.de/~gcctest/c++bench/botan/botan-summary.txt-1-0.html > (which has separate graphs for each algorithm). But as I said - just > wait a day to see if it is noise. > > Richard. > this is a different set of graphs than you sent the first time. now i see the regressions. i will add this to the growing set of things to look at. kenny
Re: Some regressions from the dataflow merge
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 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 just noise. > >>> > >>> Otherwise things look smooth as expected. > >>> > >>> Richard. > >>> > >>> > >> I looked at the graphs here and i do not see a regression except in the > >> compile time. > >> > > > > Note the graphs are for Throughput, so higher numbers are better. Look > > for example at Serpent or Skipjack at > > http://www.suse.de/~gcctest/c++bench/botan/botan-summary.txt-1-0.html > > (which has separate graphs for each algorithm). But as I said - just > > wait a day to see if it is noise. > > > > Richard. > > > this is a different set of graphs than you sent the first time. now i > see the regressions. I just pointed you to the start page initially - clicking the graphs will reveal these details. Sorry for that, Richard.
Creating new variable in tree level
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 also use ssa functions as follows: temp = create_tmp_var (TREE_TYPE (expr), "pretmp"); add_referenced_tmp_var (temp); newexpr = build (MODIFY_EXPR, TREE_TYPE (expr), temp, newexpr); name = make_ssa_name (temp, newexpr); TREE_OPERAND (newexpr, 0) = name; tsi_link_after (&tsi, newexpr, TSI_CONTINUE_LINKING); Also, I do not understand what is the usage of each function in creating the new variable. Thanks, Revital
Re: Some regressions from the dataflow merge
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.suse.de/~gcctest/c++bench/botan/)) - those are reasonably small >>> enough to investigate, but wait another day in case its just noise. >>> >>> Otherwise things look smooth as expected. >>> >>> Richard. >>> >>> >> I looked at the graphs here and i do not see a regression except in the >> compile time. >> > > Fortran has a testcase that trips one on x86/cygwin: see > http://gcc.gnu.org/ml/gcc/2007-06/msg00291.html. Perhaps you can comment on > whether df_live (== df->problems_by_index[DF_LIVE]) should ever be NULL? > > > cheers, > DaveK > >From what i can gather from looking at the "stacktrace", the problem is that ix86_eax_live_at_start_p is only called on cigwin and of course we did not check cigwin. This is an easy fix. Change the macro "DF_LIVE_OUT" in this function to the function call "df_get_live_out". It takes the same parameter and returns the same thing. I believe this will fix the problem. kenny
Re: Creating new variable in tree level
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 (tmp_var); mark_sym_for_renaming (tmp_var); Or should I also use ssa functions as follows: temp = create_tmp_var (TREE_TYPE (expr), "pretmp"); add_referenced_tmp_var (temp); newexpr = build (MODIFY_EXPR, TREE_TYPE (expr), temp, newexpr); name = make_ssa_name (temp, newexpr); TREE_OPERAND (newexpr, 0) = name; you need an SSA_NAME to assign to in this case, using mark_sym_for_renaming does defer this to later so you can use tmp_var in the MODIFY_EXPR. The second form is prefered. tsi_link_after (&tsi, newexpr, TSI_CONTINUE_LINKING); That's unrelated and just inserts the MODIFY_EXPR. Richard.
RE: Some regressions from the dataflow merge
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 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 just noise. Otherwise things look smooth as expected. Richard. >>> I looked at the graphs here and i do not see a regression except in the >>> compile time. >> Fortran has a testcase that trips one on x86/cygwin: see >> http://gcc.gnu.org/ml/gcc/2007-06/msg00291.html. Perhaps you can comment >> on whether df_live (== df->problems_by_index[DF_LIVE]) should ever be >> NULL? > From what i can gather from looking at the "stacktrace", the problem is that > ix86_eax_live_at_start_p is only called on cigwin and of course we did > not check cigwin. > > This is an easy fix. > > Change the macro "DF_LIVE_OUT" in this function to the function call > "df_get_live_out". It takes the same parameter and returns the same thing. > > I believe this will fix the problem. Thanks for the advice Kenny. CC'ing the Fortran list because I don't have time to put into this right away: Paul or FX, perhaps you'd like to give that advice a try? cheers, DaveK -- Can't think of a witty .sigline today
Re: Some regressions from the dataflow merge
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.f Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2> fdo_make_pass2.err | tee fdo_make_pass2.out': zgemm.f: In function 'zgemm': zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Likewise for 176.gcc: combine.c: In function 'simplify_comparison': combine.c:9697: internal compiler error: in remove_insn, at emit-rtl.c:3597 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. specmake: *** [combine.o] Error 1 Richard.
Re: Dataflow bug [RE: Large number of fortran testsuite failures]
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
Re: Some regressions from the dataflow merge
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 zscal.o-fprofile-use -O2 -ffast-math zscal.f Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2> fdo_make_pass2.err | tee fdo_make_pass2.out': zgemm.f: In function 'zgemm': zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Likewise for 176.gcc: combine.c: In function 'simplify_comparison': combine.c:9697: internal compiler error: in remove_insn, at emit-rtl.c:3597 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. specmake: *** [combine.o] Error 1 Sounds like there's a pass that are emitting a barrier during cfglayout mode. I'll look at them. -- #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
Re: Some regressions from the dataflow merge
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-64/x86_64/install-200706120559/bin/gfortran -c -o >> zscal.o -fprofile-use -O2 -ffast-math zscal.f >> Error from fdo_make_pass2 'specmake -j2 FDO=PASS2 build 2> >> fdo_make_pass2.err | tee fdo_make_pass2.out': >> zgemm.f: In function 'zgemm': >> zgemm.f:413: internal compiler error: in remove_insn, at emit-rtl.c:3597 >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See http://gcc.gnu.org/bugs.html> for instructions. >> >> Likewise for 176.gcc: >> >> combine.c: In function 'simplify_comparison': >> combine.c:9697: internal compiler error: in remove_insn, at >> emit-rtl.c:3597 >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See http://gcc.gnu.org/bugs.html> for instructions. >> specmake: *** [combine.o] Error 1 > > Sounds like there's a pass that are emitting a barrier during > cfglayout mode. > I'll look at them. see if danny accidently reverted your gcse fix for this kenny
Sparc bootstrap failure, dataflow related?
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 you please take a look? Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Sparc bootstrap failure, dataflow related?
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 an attachment in the PR, would you please take a look? > > Thanks, > --Kaveh > -- > Kaveh R. Ghazi[EMAIL PROTECTED] > i am about to commit the patch to fix this. kenny
MIPS bootstrap failure, dataflow related?
The information is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32313 David Daney
Access to .dynamic section of executable from shared library
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 shared library) have a _DYNAMIC symbol and it's local. And when we using _DYNAMIC we using this local symbol. So when I'm using _DYNAMIC in shared library - I get pointer to .dynamic section of library, when I'm using _DYNAMIC in executable - I get pointer to .dynamic section of executable. Is there any way to get pointer to executable _DYNAMIC from shared library context. Maybe when I'm building shared library I should tell dynamic linker to replace local _DYNAMIC with _DYNAMIC from executable. I've tried to assign "weak" attribute to definition of _DYNAMIC in library code - didn't help. And also I didn't have this problem with gcc 3.4.3. Any Ideas? Thanks!
Re: Help in understanding ccp propagator
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 statements that load the exact same memory reference
> stored here. Those statements will have the exact same list
> of virtual uses, so it is enough to set the output of this
> statement to be its first virtual definition. */
>
>
> You are changing this, AFAIK, so you will need to make it handle
> multiple output values.
>
That's indeed the problem:
Consider the following stmt that is been visited -
# MPT.1416_722 = VDEF { MPT.1416 }
D.61410.first = i0_62;
Than output_p will be set to MPT.1416_722 (which is the
only vdef of this stmt) -
*output_p = first_vdef (stmt);
And later on (in add_ssa_edge () function) all the uses of MPT.1416_722
will be added to the working set which in our case is D.61410.second =
97; statement instead of the real uses of D.61410.first.
# MPT.1416_723 = VDEF { MPT.1416 }
D.61410.second = 97;
Is there a way to retrieve the real uses of D.61410.first?
No, you will have to look at each immediate use and determine if it is
really a store to the same place.
Thanks again,
Revital
