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_734 { 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_722 { 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/sizeof.f90,
line =
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: 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: 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 URL: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 URL: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 URL: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 URL: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]
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_734 { 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_722 { 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
[Bug rtl-optimization/32293] [4.3 Regression] internal compiler error: in do_SUBST, at combine.c:502
--- Comment #9 from ubizjak at gmail dot com 2007-06-12 07:01 ---
Following patch should fix the ICE:
Index: combine.c
===
--- combine.c (revision 125636)
+++ combine.c (working copy)
@@ -5210,11 +5210,17 @@ simplify_if_then_else (rtx x)
if (true_code == EQ true_val == const0_rtx
exact_log2 (nzb = nonzero_bits (from, GET_MODE (from))) = 0)
- false_code = EQ, false_val = GEN_INT (nzb);
+ {
+ false_code = EQ;
+ false_val = GEN_INT (trunc_int_for_mode (nzb, GET_MODE (from)));
+ }
else if (true_code == EQ true_val == const0_rtx
(num_sign_bit_copies (from, GET_MODE (from))
== GET_MODE_BITSIZE (GET_MODE (from
- false_code = EQ, false_val = constm1_rtx;
+ {
+ false_code = EQ;
+ false_val = constm1_rtx;
+ }
/* Now simplify an arm if we know the value of the register in the
branch and it is used in the arm. Be careful due to the potential
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-06-12 07:01:32
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32293
[Bug fortran/32298] New: Intrinsic MINLOC / MAXLOC gives wrong results (gfortran build 20070522)
The following source code: !- PROGRAM ERR_MINLOC INTEGER, PARAMETER :: N = 7 DOUBLE PRECISION, DIMENSION (N), PARAMETER :: A = (/ 0.3D0, 0.455D0, 0.6D0, 0.7D0, 0.72D0, 0.76D0, 0.79D0 /) DOUBLE PRECISION :: B INTEGER :: I, J, K DO I = 1, N B = A(I) J = MINLOC (ABS (A - B), 1) K = MAXLOC (ABS (A - B), 1) PRINT *, I, J, K END DO STOP END PROGRAM ERR_MINLOC !-- gives the following result: (superflouos blanks are deleted): -- 1 2 7 2 2 7 3 3 7 4 4 2 5 5 2 6 6 2 7 7 2 -- The correct result is: -- 1 1 7 2 2 7 3 3 1 4 4 1 5 5 1 6 6 1 7 7 1 -- -- Summary: Intrinsic MINLOC / MAXLOC gives wrong results (gfortran build 20070522) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jens dot bischoff at freenet dot de GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32298
[Bug rtl-optimization/32293] [4.3 Regression] internal compiler error: in do_SUBST, at combine.c:502
--- Comment #10 from ubizjak at gmail dot com 2007-06-12 08:26 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00759.html -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg00759.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2007-06-12 07:01:32 |2007-06-12 08:26:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32293
[Bug ada/32299] New: 4.3-20070608 gnat bug detected in gimplify_addr_expr, at gimplify.c:3919
$ gcc -v -c gcc43.adb Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../SOURCES/gcc-4.3-20070608/configure --prefix=/usr --enable-languages=c,c++,ada Thread model: posix gcc version 4.3.0 20070608 (experimental) /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/gnat1 -quiet -dumpbase gcc43.adb -mtune=generic gcc43.adb -o /tmp/ccxo3ZQM.s +===GNAT BUG DETECTED==+ | 4.3.0 20070608 (experimental) (i686-pc-linux-gnu) GCC error: | | in gimplify_addr_expr, at gimplify.c:3919| | Error detected around gcc43.adb:28 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. gcc43.adb gcc43.ads -- file: gcc43.ads with Interfaces.C.Pointers, Interfaces.C.Strings; with System.Storage_Elements; package Gcc43 is package SSE renames System.Storage_Elements; package Conv is new Interfaces.C.Pointers (Index = SSE.Storage_Offset, Element = SSE.Storage_Element, Element_Array = SSE.Storage_Array, Default_Terminator = 16#00#); -- unused procedure Push_To_LLAPI (header_len : SSE.Storage_Offset; header_data : Conv.Pointer; data_len : SSE.Storage_Offset; data : Conv.Pointer); subtype Dummy_Contents is SSE.Storage_Array (1 .. 72); type J3_2_Llapi_T is record Dummy : Dummy_Contents; end record; end Gcc43; -- file: gcc43.adb with Interfaces.C.Pointers; with Ada.Exceptions; with System.Storage_Elements; with Unchecked_Conversion; with Text_IO; package body Gcc43 is use type SSE.Storage_Offset; procedure Push_To_LLAPI (header_len : SSE.Storage_Offset; header_data : Conv.Pointer; data_len : SSE.Storage_Offset; data : Conv.Pointer) is Header : SSE.Storage_Array (1 .. Header_Len); Buf : SSE.Storage_Array (1 .. 1 + Data_Len); Buf_Address : constant System.Address := Buf (1)'Address; Ext_Track : J3_2_Llapi_T; pragma Import (Ada, Ext_Track); for Ext_Track'Address use Buf_Address; begin if Header_Len = 0 then return; end if; begin Header := Conv.Value (Header_Data, Interfaces.C.ptrdiff_t (Header_Len)); Buf (1) := Header (1); Buf (2 .. Buf'Last) := Conv.Value (Data, Interfaces.C.ptrdiff_t (Data_Len)); exception when E : others = Text_IO.Put_Line (Push_To_LLAPI: exception on assigning Buf, Ada.Exceptions.Exception_Information (E)); end; end Push_To_LLAPI; end Gcc43; -- Summary: 4.3-20070608 gnat bug detected in gimplify_addr_expr, at gimplify.c:3919 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oliver dot kellogg at eads dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32299
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-12 10:05 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-12 10:05:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug rtl-optimization/32293] [4.3 Regression] internal compiler error: in do_SUBST, at combine.c:502
--- Comment #11 from uros at gcc dot gnu dot org 2007-06-12 10:31 --- Subject: Bug 32293 Author: uros Date: Tue Jun 12 10:31:04 2007 New Revision: 125643 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125643 Log: PR rtl-optimization/32293 * combine.c (simplify_if_then_else): Truncate return from nonzero_bits() to correct mode. testsuite/ChangeLog: PR rtl-optimization/32293 * gcc.dg/pr32293.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr32293.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32293
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #8 from rob1weld at aol dot com 2007-06-12 10:53 --- should be many more tests. It's OK. I followed the advice on page http://gcc.gnu.org/install/test.html - Section 0.1 How can you run the testsuite on selected tests?. make check-gcc RUNTESTFLAGS=dg-torture.exp I did that so I could check quickly and post here; so people would not be trying to fix what is NOT broken and know the correct place to look for the trouble. Just completed the whole test on everything - see here: http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00573.html Also please look at the end of the report. I made a mod to the test_summary to catch assembler errors - and it found some ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug testsuite/32063] contrib/test_summary script could output results more neatly
--- Comment #5 from rob1weld at aol dot com 2007-06-12 11:11 --- Here is another, this caught some errors! See end of: http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00573.html print grep -e undefined\\ reference\\ to /opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.log | sort -u -k 2 | head -n 10 print ; system(grep -e undefined\\ reference\\ to /opt/gcc-4_3-build/gcc/testsuite/gcc/gcc.log | sort -u -k 2 | head -n 10); print ---; print ; Note: These additions go directly before these lines: print Compiler version: prefix version lang; print Platform: host; print configflags; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32063
[Bug libmudflap/31845] Need to adjust libmudflap timeout values in testsuite.
--- Comment #3 from rob1weld at aol dot com 2007-06-12 11:16 ---
FIX - Altered dg-timeout:
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.cth/pass37-frag-Origonal.c
/* { dg-output 100 100 100 100 100 100 100 100 100 100 } */
/* { dg-repetitions 20 } */
/* { dg-timeout 10 } */
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.cth/pass37-frag.c
/* { dg-output 100 100 100 100 100 100 100 100 100 100 } */
/* { dg-repetitions 20 } */
/* { dg-timeout 300 } */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31845
[Bug libmudflap/31681] [4.3 regression]: Many libmudflap faulures
--- Comment #5 from rob1weld at aol dot com 2007-06-12 11:21 --- [EMAIL PROTECTED] Fixed. Nope. Results for 4.3.0 20070611 (experimental) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00573.html A portion of this bug report is duplicated at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32276 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31681
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #4 from tbm at cyrius dot com 2007-06-12 11:22 --- This works with 4.3.0 20070604 on mips. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug target/32276] [4.3 Regression] New libmudflap failures
--- Comment #1 from rob1weld at aol dot com 2007-06-12 11:24 ---
These bug were first mentioned in report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31681
Confirmed for similar target:
Results for 4.3.0 20070611 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00573.html
--- My Notes ---
Screen output:
=== libmudflap tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /root/downloads/gcc-4_3-trunk/libmudflap/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.c/cfrags.exp ...
Running
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.c/externs.exp ...
Running
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.c++/c++frags.exp
...
FAIL: libmudflap.c++/pass41-frag.cxx execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-static) execution test
FAIL: libmudflap.c++/pass41-frag.cxx ( -O) execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-O2) execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-O3) execution test
Running
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.c++/ctors.exp ...
Running
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.cth/cthfrags.exp
...
=== libmudflap Summary ===
# of expected passes1985
# of unexpected failures5
Log file i686-pc-linux-gnu/libmudflap/testsuite/libmudflap.log output:
mudflap violation 1 (check/read): time=1181641131.727908 ptr=0x401fd640 size=4
pc=0x40027c0d
location=`/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/include/ostream:546
(main)'
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__mf_check+0x3d)
[0x40027c0d]
./pass41-frag.exe(main+0x2bb) [0x8048f7b]
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__wrap_main+0x4f)
[0x4002745f]
number of nearby objects: 0
FAIL: libmudflap.c++/pass41-frag.cxx execution test
mudflap violation 1 (check/read): time=1181641140.406737 ptr=0x80fb280 size=4
pc=0x804b3d0
location=`/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/include/ostream:546
(main)'
[0x804b3d0]
[0x804851b]
[0x804b416]
number of nearby objects: 0
FAIL: libmudflap.c++/pass41-frag.cxx (-static) execution test
mudflap violation 1 (check/read): time=1181641147.350329 ptr=0x401fd640 size=4
pc=0x40027c0d
location=`/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/include/ostream:546
(main)'
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__mf_check+0x3d)
[0x40027c0d]
./pass41-frag.exe(main+0x1b1) [0x8048e65]
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__wrap_main+0x4f)
[0x4002745f]
number of nearby objects: 0
FAIL: libmudflap.c++/pass41-frag.cxx ( -O) execution test
mudflap violation 1 (check/read): time=1181641153.350016 ptr=0x401fd640 size=4
pc=0x40027c0d
location=`/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/include/ostream:546
(main)'
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__mf_check+0x3d)
[0x40027c0d]
./pass41-frag.exe(main+0x2bb) [0x8048f7b]
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__wrap_main+0x4f)
[0x4002745f]
number of nearby objects: 0
FAIL: libmudflap.c++/pass41-frag.cxx (-O2) execution test
mudflap violation 1 (check/read): time=1181641160.020512 ptr=0x401fd640 size=4
pc=0x40027c0d
location=`/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/include/ostream:546
(main)'
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__mf_check+0x3d)
[0x40027c0d]
./pass41-frag.exe(main+0x2bb) [0x8049f7b]
/opt/gcc-4_3-build/i686-pc-linux-gnu/./libmudflap/.libs/libmudflap.so.0(__wrap_main+0x4f)
[0x4002745f]
number of nearby objects: 0
FAIL: libmudflap.c++/pass41-frag.cxx (-O3) execution test
All the log entries show number of nearby objects: 0. Does this mean that it
is
not the test itself that is failing but instead something other than the test -
IE:
GXX is compiling incorrect code or the libraries are incorrectly written.
# cat
/root/downloads/gcc-4_3-trunk/libmudflap/testsuite/libmudflap.c++/pass41-frag.cxx
#include string
#include iostream
int
main (int argc, char *argv[])
{
std::string myStr = Hello, World!;
std::cout myStr std::endl;
return 0;
}
/opt/gcc-4_3-build/./gcc/g++ -shared-libgcc -B/opt/gcc-4_3-build/./gcc
-nostdinc++ -L/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/src
-L/opt/gcc-4_3-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/test/i686-pc-linux-gnu/bin/ -B/usr/test/i686-pc-linux-gnu/lib/ -isystem
/usr/test/i686-pc-linux-gnu/include -isystem
/usr/test/i686-pc-linux-gnu/sys-include -ffloat-store
[Bug c++/32290] GCC crashes with OOM when compiling relatively simple source file (no endless loop)
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-12 11:29 --- mainline uses 10MB to compile reduced-problem.ii.nocrap. So this is actually a dup of PR29433. *** This bug has been marked as a duplicate of 29433 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32290
[Bug c++/29433] using boost::MPL requires lots of memory
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-06-12 11:29 --- *** Bug 32290 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aribrei at arcor dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
[Bug rtl-optimization/32293] [4.3 Regression] internal compiler error: in do_SUBST, at combine.c:502
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-06-12 11:31 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32293
[Bug c++/32300] New: ICE with -O2 -fsee
cat bug.ii
struct vector {
int *start, *finish;
unsigned long size() { return finish - start; }
};
void f(vector v) {
for (unsigned i = 0; i v.size(); ++i);
}
g++ -O2 -fsee bug.ii
bug.ii: In function void f(vector):
bug.ii:7: internal compiler error: Segmentation fault
This started failing in the last couple of days.
I'm compiling on linux_x86_64.
--
Summary: ICE with -O2 -fsee
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug bootstrap/32287] gas version style changed causs warnings with configure
--- Comment #3 from rob1weld at aol dot com 2007-06-12 11:37 --- Even if they did change it back people may still have one of these versions since _all_ my versions of gas are less than a year old. Oneis the newest that apt-get will fetch (IE: the standard OS version), another is the newest snapshot, the last is the newest SVN compiled by me - so each is actually new, depending on how you look at it. My patch only grabs the numbers. If they change version numbering to 2.17.50.gamma.7.four then were screwed. I welcome anyone to write a better script. I'm just pointing out the bug. When things work (however badly) in one part of gcc and then fail (but only partially) in another spot (or work OK) then it can cause some weird errors that are hard to track down. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #5 from tbm at cyrius dot com 2007-06-12 11:43 --- I can reproduce this with current 4.1 from SVN, but not with 4.2 from SVN. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug tree-optimization/31657] Should combine bit tests in if stmts
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-12 12:06 --- Subject: Bug 31657 Author: rguenth Date: Tue Jun 12 12:06:19 2007 New Revision: 125644 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125644 Log: 2007-06-12 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/15353 PR tree-optimization/31657 * passes.c (init_optimization_passes): Add pass_tree_ifcombine. * timevar.def: Add TV_TREE_IFCOMBINE. * tree-pass.h (pass_tree_ifcombine): Declare. * tree-ssa-ifcombine.c: New file. * tree-ssa-phiopt.c (blocks_in_phiopt_order): Export. * tree-flow.h (blocks_in_phiopt_order): Declare. * Makefile.in (OBJS-common): Add tree-ssa-ifcombine.o. (tree-ssa-ifcombine.o): New dependencies. * gcc.c-torture/execute/20070424-1.c: New testcase. * gcc.dg/tree-ssa/ssa-ifcombine-1.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-2.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-3.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-4.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-5.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20070424-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-5.c trunk/gcc/tree-ssa-ifcombine.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/timevar.def trunk/gcc/tree-flow.h trunk/gcc/tree-pass.h trunk/gcc/tree-ssa-phiopt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31657
[Bug tree-optimization/15353] [tree-ssa] Merge two ifs if one subsumes the other.
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-06-12 12:06 --- Subject: Bug 15353 Author: rguenth Date: Tue Jun 12 12:06:19 2007 New Revision: 125644 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125644 Log: 2007-06-12 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/15353 PR tree-optimization/31657 * passes.c (init_optimization_passes): Add pass_tree_ifcombine. * timevar.def: Add TV_TREE_IFCOMBINE. * tree-pass.h (pass_tree_ifcombine): Declare. * tree-ssa-ifcombine.c: New file. * tree-ssa-phiopt.c (blocks_in_phiopt_order): Export. * tree-flow.h (blocks_in_phiopt_order): Declare. * Makefile.in (OBJS-common): Add tree-ssa-ifcombine.o. (tree-ssa-ifcombine.o): New dependencies. * gcc.c-torture/execute/20070424-1.c: New testcase. * gcc.dg/tree-ssa/ssa-ifcombine-1.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-2.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-3.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-4.c: Likewise. * gcc.dg/tree-ssa/ssa-ifcombine-5.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20070424-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-5.c trunk/gcc/tree-ssa-ifcombine.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/timevar.def trunk/gcc/tree-flow.h trunk/gcc/tree-pass.h trunk/gcc/tree-ssa-phiopt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15353
[Bug tree-optimization/15353] [tree-ssa] Merge two ifs if one subsumes the other.
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-06-12 12:08 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15353
[Bug tree-optimization/31657] Should combine bit tests in if stmts
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-12 12:08 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31657
[Bug tree-optimization/15357] [tree-ssa] combing if statements
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-12 12:10 --- The new if-combining pass can be told to make the transformation suggested in the description. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15357
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-12 12:36 --- Confirmed. A dataflow merge fallout probably: Program received signal SIGSEGV, Segmentation fault. 0x007c449c in df_insn_refs_verify (collection_rec=0x7fff1ab011c0, bb=0x2aec90911360, insn=0x2aec9074dfa0, abort_if_fail=1 '\001') at /space/rguenther/src/svn/trunk/gcc/df-scan.c:4148 4148 if (!DF_INSN_UID_DEFS (uid)) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at naturalbridge dot ||com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-12 12:36:27 date|| Summary|ICE with -O2 -fsee |[4.3 Regression] ICE with - ||O2 -fsee Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug middle-end/32301] New: int __attribute__((vector_size(8))) doesn't use %mm0, produces ugly code
When the code below is compiled with -march=pentium4 -msse2 -O3
-fomit-frame-pointer, when N == 4 f() is correct:
f:
movdqa b, %xmm0
paddd a, %xmm0
movdqa %xmm0, c
ret
However for N == 2 gcc 4.2.0 doesn't use %mm0 any more (gcc 4.0.0 worked OK).
OK, for some reason gcc decides to synthesize the operation using scalar
instructions. But why the code for f() is so scary, not even close to that of
g()? My wild guess is that gcc copies vectors onto the stack because it thinks
the vectors may overlap. But is it really possible? If so, how can I say that
they never overlap? Perhaps this is a bug too, because they are declared as
different objects, should not overlap.
#define N 2
typedef signed int data_type;
typedef data_type __attribute__((vector_size(sizeof(data_type) * N))) vector;
extern vector a, b, c;
void
f()
{
c = a + b;
}
typedef data_type vector2[N];
extern vector2 a2, b2, c2;
void
g()
{
int i;
for (i = 0; i N; ++i)
c2[i] = a2[i] + b2[i];
}
For the code above gcc 4.2.0 produces:
f:
pushl %esi
pushl %ebx
subl$36, %esp
movla, %ebx
movla+4, %esi
movlb, %edx
movlb+4, %ecx
movl%edx, 24(%esp)
movl%ecx, 28(%esp)
movl24(%esp), %eax
movl%ebx, 16(%esp)
movl%esi, 20(%esp)
addl16(%esp), %eax
movl%eax, c
movl%edx, 8(%esp)
movl%ecx, 12(%esp)
movl12(%esp), %eax
movl%ebx, (%esp)
movl%esi, 4(%esp)
addl4(%esp), %eax
movl%eax, c+4
addl$36, %esp
popl%ebx
popl%esi
ret
g:
movla2, %eax
addlb2, %eax
movl%eax, c2
movla2+4, %eax
addlb2+4, %eax
movl%eax, c2+4
ret
--
Summary: int __attribute__((vector_size(8))) doesn't use %mm0,
produces ugly code
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tomash dot brechko at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32301
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-12 12:40 --- FYI (gdb) bt #0 0x007c449c in df_insn_refs_verify (collection_rec=0x70a74130, bb=0x2aaeba99e360, insn=0x2aaeba7dafa0, abort_if_fail=1 '\001') at /space/rguenther/src/svn/trunk/gcc/df-scan.c:4148 #1 0x007c4717 in df_bb_verify (bb=0x2aaeba99e360) at /space/rguenther/src/svn/trunk/gcc/df-scan.c:4195 #2 0x007c4bf4 in df_scan_verify () at /space/rguenther/src/svn/trunk/gcc/df-scan.c:4334 #3 0x007b1f56 in df_verify () at /space/rguenther/src/svn/trunk/gcc/df-core.c:1513 #4 0x007b0fa0 in df_analyze () at /space/rguenther/src/svn/trunk/gcc/df-core.c:1106 #5 0x00efa835 in init_dce (fast=1 '\001') at /space/rguenther/src/svn/trunk/gcc/dce.c:187 #6 0x00efbd0f in rest_of_handle_fast_dce () at /space/rguenther/src/svn/trunk/gcc/dce.c:719 #7 0x00efbda3 in run_fast_dce () at /space/rguenther/src/svn/trunk/gcc/dce.c:767 #8 0x00a3840e in rest_of_handle_see () at /space/rguenther/src/svn/trunk/gcc/see.c:3823 #9 0x009a4c69 in execute_one_pass (pass=0x1454340) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug target/32301] int __attribute__((vector_size(8))) doesn't use %mm0, produces ugly code
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 12:42 --- This is on purpose as if the compiler used the MMX registers it would need to emit emms but it does not do that yet. There are two other bugs about this issue already too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32301
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #3 from zadeck at naturalbridge dot com 2007-06-12 12:46 --- I am not surprised at this at all. Given that there are no regression tests that use -fsee and this pass is never on by default. I will look into this. However, the big picture is that we need to make a decision about optimizations like this. They should either be enabled either at some -O level or in regression tests or they should be removed from the compiler. They serve no purpose the way that they are now. -- zadeck at naturalbridge dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |zadeck at naturalbridge dot |dot org |com Status|NEW |ASSIGNED Last reconfirmed|2007-06-12 12:36:27 |2007-06-12 12:46:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug target/32280] _mm_srli_si128, heinous code for some shifts
--- Comment #6 from ubizjak at gmail dot com 2007-06-12 12:48 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32280
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-12 13:37 --- Yes, those should be at least excercised by the tortures. So, if enabling at -O3 regtests ok I'd vote for enabling it there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300
[Bug c++/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
--- Comment #1 from alessandro dot mei at elsagdatamat dot com 2007-06-12 13:30 --- Created an attachment (id=13685) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13685action=view) compiler output and warnings; the preprocessed file (*.ii) that triggers the bug the complete command line that triggers the bug; /home/mag/sviluppo/bin/bkeuti /home/mag/sviluppo/config/bkeuti.xml /home/mag/sviluppo/config/processi.dtd /dev/null The stack content relative to the core file is the following: (gdb) where #0 0xd1514a98 in _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base ( __x=incomplete type) at ../../../../gcc-4.1.1/libstdc++-v3/src/tree.cc:68 #1 0x10019fac in _ZNSt17_Rb_tree_iteratorISt4pairIKSsP6CTimerEEppEi ( this=incomplete type) at /usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.1.1/../../../../include/c++/4 .1.1/bits/stl_tree.h:190 #2 0x100200b0 in _ZN13bus_CProcesso17azioniDiBackGroudEv ( this=incomplete type) at bus_CProcesso.cpp:838 #3 0x10022750 in _ZN13bus_CProcesso3vaiEbi (this=incomplete type, bSync=false, intSec=1) at bus_CProcesso.cpp:458 #4 0x10022e18 in _ZN22bus_CProcessoExceptionC1Ev (this=incomplete type) at bus_CProcesso.hpp:88 #5 0x10005054 in main (argc=3, argv=0x2ff22934, envp=0x2ff22944) at bkeuti.cpp:655 #6 0x1214 in __start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug fortran/32302] New: gfortran - incorrect result with -O3
The output of this program is correct when using -g, but incorrect with -O3 - [dranta:~/junk] dir% cp dyna3dTest01.F Test01.F [dranta:~/junk] dir% gfortran -g -O3 -std=legacy -DSGI -DWKSTN -DUNIX -DVECLEN=32 -DDP -fcray-pointer -fno-automatic -o Test01 Test01.F Test01.F:47.19: common/aux32/a17(lnv),a28(lnv),dett(lnv), 1 Warning: Named COMMON block 'aux32' at (1) shall be of the same size Test01.F:53.19: common/aux33/ix1(lnv),ix2(lnv),ix3(lnv),ix4(lnv),ix5(lnv), 1 Warning: Named COMMON block 'aux33' at (1) shall be of the same size /usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced from: /usr/local/gfortran/lib/gcc/powerpc-apple-darwin8.9.0/4.3.0/../../../libgfortran.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) [dranta:~/junk] dir% Test01 0.250 0.250 [dranta:~/junk] dir% gfortran -g -std=legacy -DSGI -DWKSTN -DUNIX -DVECLEN=32 -DDP -fcray-pointer -fno-automatic -o Test01 Test01.F Test01.F:47.19: common/aux32/a17(lnv),a28(lnv),dett(lnv), 1 Warning: Named COMMON block 'aux32' at (1) shall be of the same size Test01.F:53.19: common/aux33/ix1(lnv),ix2(lnv),ix3(lnv),ix4(lnv),ix5(lnv), 1 Warning: Named COMMON block 'aux33' at (1) shall be of the same size /usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced from: /usr/local/gfortran/lib/gcc/powerpc-apple-darwin8.9.0/4.3.0/../../../libgfortran.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) [dranta:~/junk] dir% Test01 1.001.00 [dranta:~/junk] dir% cat Test01.F subroutine unpki(ixp,nwcon,nmel) parameter(lnv=VECLEN) #ifdef DP implicit double precision (a-h,o-z)dp #endif c c unpack connection data c common/aux32/kka(lnv),kkb(lnv),kkc(lnv), 1 kk1(lnv),kk2(lnv),kk3(lnv),dxy(lnv), 2 dyx(lnv),dyz(lnv),dzy(lnv),dzx(lnv), 3 dxz(lnv),vx17(lnv),vx28(lnv),vx35(lnv), 4 vx46(lnv),vy17(lnv),vy28(lnv), 5 vy35(lnv),vy46(lnv),vz17(lnv),vz28(lnv),vz35(lnv),vz46(lnv) common/aux33/ix1(lnv),ix2(lnv),ix3(lnv),ix4(lnv),ix5(lnv), 1 ix6(lnv),ix7(lnv),ix8(lnv),mxt(lnv) dimension ixp(nwcon,*) c return end subroutine prtal parameter(lnv=VECLEN) #ifdef DP implicit double precision (a-h,o-z)dp #endif common/aux8/ x1(lnv),x2(lnv),x3(lnv),x4(lnv), x5(lnv),x6(lnv),x7(lnv),x8(lnv), y1(lnv),y2(lnv),y3(lnv),y4(lnv), y5(lnv),y6(lnv),y7(lnv),y8(lnv), z1(lnv),z2(lnv),z3(lnv),z4(lnv), z5(lnv),z6(lnv),z7(lnv),z8(lnv) common/aux9/vlrho(lnv),det(lnv) common/aux10/ 1 px1(lnv),px2(lnv),px3(lnv),px4(lnv), px5(lnv),px6(lnv),px7(lnv),px8(lnv), 2 py1(lnv),py2(lnv),py3(lnv),py4(lnv), py5(lnv),py6(lnv),py7(lnv),py8(lnv), 3 pz1(lnv),pz2(lnv),pz3(lnv),pz4(lnv), pz5(lnv),pz6(lnv),pz7(lnv),pz8(lnv), 4 vx1(lnv),vx2(lnv),vx3(lnv),vx4(lnv), 5 vx5(lnv),vx6(lnv),vx7(lnv),vx8(lnv), 6 vy1(lnv),vy2(lnv),vy3(lnv),vy4(lnv), 7 vy5(lnv),vy6(lnv),vy7(lnv),vy8(lnv), 8 vz1(lnv),vz2(lnv),vz3(lnv),vz4(lnv), 9 vz5(lnv),vz6(lnv),vz7(lnv),vz8(lnv) common/aux32/a17(lnv),a28(lnv),dett(lnv), 1 aj1(lnv),aj2(lnv),aj3(lnv),aj4(lnv), 2 aj5(lnv),aj6(lnv),aj7(lnv),aj8(lnv), 3 aj9(lnv),x17(lnv),x28(lnv),x35(lnv), 4 x46(lnv),y17(lnv),y28(lnv),y35(lnv), 5 y46(lnv),z17(lnv),z28(lnv),z35(lnv),z46(lnv) common/aux33/ix1(lnv),ix2(lnv),ix3(lnv),ix4(lnv),ix5(lnv), 1 ix6(lnv),ix7(lnv),ix8(lnv),mxt(lnv),nmel common/aux36/lft,llt common/failu/sieu(lnv),failu(lnv) common/sand1/ihf,ibemf,ishlf,itshf dimension aj5968(lnv),aj6749(lnv),aj4857(lnv),aji1(lnv),aji2(lnv), 1 aji3(lnv),aji4(lnv),aji5(lnv), 1 aji6(lnv),aji7(lnv),aji8(lnv),aji9(lnv),aj12(lnv), 2 aj45(lnv),aj78(lnv),b17(lnv),b28(lnv),c17(lnv),c28(lnv) c equivalence (x17,aj5968),(x28,aj6749),(x35,aj4857),(x46,aji1), 1 (y17,aji2),(y28,aji3),(y35,aji4),(y46,aji5),(z17,aji6), 2 (z28,aji7),(z35,aji8),(z46,aji9),(aj1,aj12),(aj2,aj45), 3 (aj3,aj78),(px1,b17),(px2,b28),(px3,c17),(px4,c28) data o64th/0.0156250/ c c jacobian matrix c do 10 i=lft,llt x17(i)=x7(i)-x1(i) x28(i)=x8(i)-x2(i) x35(i)=x5(i)-x3(i) x46(i)=x6(i)-x4(i) y17(i)=y7(i)-y1(i) y28(i)=y8(i)-y2(i) y35(i)=y5(i)-y3(i) y46(i)=y6(i)-y4(i) z17(i)=z7(i)-z1(i) z28(i)=z8(i)-z2(i) z35(i)=z5(i)-z3(i) 10 z46(i)=z6(i)-z4(i) do 20 i=lft,llt aj1(i)=x17(i)+x28(i)-x35(i)-x46(i) aj2(i)=y17(i)+y28(i)-y35(i)-y46(i)
[Bug c++/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
--- Comment #2 from alessandro dot mei at elsagdatamat dot com 2007-06-12 13:42 --- (From update of attachment 13685) the complete command line that triggers the bug: /home/mag/sviluppo/bin/bkeuti /home/mag/sviluppo/config/bkeuti.xml /home/mag/sviluppo/config/processi.dtd /dev/null The stack content relative to the core file is the following: (gdb) where #0 0xd1514a98 in _ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base ( __x=incomplete type) at ../../../../gcc-4.1.1/libstdc++-v3/src/tree.cc:68 #1 0x10019fac in _ZNSt17_Rb_tree_iteratorISt4pairIKSsP6CTimerEEppEi ( this=incomplete type) at /usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.1.1/../../../../include/c++/4 .1.1/bits/stl_tree.h:190 #2 0x100200b0 in _ZN13bus_CProcesso17azioniDiBackGroudEv ( this=incomplete type) at bus_CProcesso.cpp:838 #3 0x10022750 in _ZN13bus_CProcesso3vaiEbi (this=incomplete type, bSync=false, intSec=1) at bus_CProcesso.cpp:458 #4 0x10022e18 in _ZN22bus_CProcessoExceptionC1Ev (this=incomplete type) at bus_CProcesso.hpp:88 #5 0x10005054 in main (argc=3, argv=0x2ff22934, envp=0x2ff22944) at bkeuti.cpp:655 #6 0x1214 in __start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug c++/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
--- Comment #3 from alessandro dot mei at elsagdatamat dot com 2007-06-12 13:48 --- the exact version of GCC; the system type; the options given when GCC was configured/built; gcc -v Using built-in specs. Target: powerpc-ibm-aix5.3.0.0 Configured with: ../gcc-4.1.1/configure --disable-nls Thread model: aix gcc version 4.1.1 -- alessandro dot mei at elsagdatamat dot com changed: What|Removed |Added CC||alessandro dot mei at ||elsagdatamat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug target/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c++ |target GCC target triplet||owerpc-ibm-aix5.3.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug tree-optimization/32303] New: [4.3 Regression] SPEC2006 447.dealII miscompiled at -O3
See PR30252 comment #30 for bug analysis and a patch. -- Summary: [4.3 Regression] SPEC2006 447.dealII miscompiled at -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code, alias Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32303
[Bug target/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-12 14:01 --- And why do you think GCC is at fault? It is hard to debug this huge sources really. Have you tried to pin point exactly where the issue. Do you have any uninitialized variables? Are you going over array bounds? Do you take an address of a local variable and keep it around even after it goes out of scope? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug tree-optimization/32303] [4.3 Regression] SPEC2006 447.dealII miscompiled at -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32303
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #6 from michael dot a dot richmond at nasa dot gov 2007-06-12 14:04 --- When you build gcc and gfortran on your mips box, do you specify your system type as mips-unknown-linux-gnu or as mips64-unknown-linux-gnu? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug c++/32304] New: ICE in set_mem_attributes_minus_bitpos
cat bug.ii
struct S {
S() {}
};
S f() {
static S s;
return s;
}
g++ -O bug.ii
bug2.ii: In function S f():
bug2.ii:6: internal compiler error: in set_mem_attributes_minus_bitpos, at
emit-rtl.c:1573
--
Summary: ICE in set_mem_attributes_minus_bitpos
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32304
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #7 from tbm at cyrius dot com 2007-06-12 14:12 --- mips-linux-gnu, as the Debian package does. Why? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug c++/32305] New: ICE in initialize_flags_in_bb with -O -fipa-pta
cat bug.ii
struct S1 {
S1() {}
};
struct S2 {
void f2() {
static S1 s1;
}
};
void f(S2 s2) {
s2.f2();
}
g++ -O -fipa-pta bug.ii
bug1.ii: In function void f(S2):
bug1.ii:9: internal compiler error: in initialize_flags_in_bb, at
tree-into-ssa.c:437
--
Summary: ICE in initialize_flags_in_bb with -O -fipa-pta
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
[Bug middle-end/32304] [4.3 Regression] ICE in set_mem_attributes_minus_bitpos
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 14:20 --- readonly is set on this decl which is wrong. I think I know what is wrong. ipa-reference.c sets TREE_READONLY on the decl when it really should not be (even though it is readonly now). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c++ |middle-end Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-06-12 14:20:18 date|| Summary|ICE in |[4.3 Regression] ICE in |set_mem_attributes_minus_bit|set_mem_attributes_minus_bit |pos |pos Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32304
[Bug middle-end/32304] [4.3 Regression] ICE in set_mem_attributes_minus_bitpos
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-12 14:22 --- *** Bug 31685 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32304
[Bug middle-end/31685] [4.3 regression] ICE in set_mem_attributes
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-12 14:22 --- I am going to mark this as a dup of bug 32304 (even though that is newer) because it has a short testcase and I added some anyalsis to the problem there. *** This bug has been marked as a duplicate of 32304 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31685
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #8 from michael dot a dot richmond at nasa dot gov 2007-06-12 14:33 --- (In reply to comment #7) mips-linux-gnu, as the Debian package does. Why? When I run the configure script on an SGI Indy under Debian 4.0, it sets the system type to mips64-unknown-linux-gnu, and sets the ABI to N32. When I run the configure script under Debian 3.1, it sets the system type to mips-unknown-linux-gnu, and sets the ABI to 32. Which ABI do you use? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug tree-optimization/32306] New: Bad Code generation ( Tree optimization )
For the following Code Snippet
void bar ()
{
b1 = foo(1);
b2 = foo(1);
b3 = foo(1);
b4 = foo(1);
b5 = foo(1);
b6 = foo(1);
b7 = foo(1);
b8 = foo(1);
b9 = foo(1);
b10 = foo(1);
b11 = foo(1);
b12 = foo(1);
array[0] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[1] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[2] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[3] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[4] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[5] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[6] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[7] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[8] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[9] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
array[10] = b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11
b12;
return;
}
Where b ( from b1 to b12) are all declared static short b1, static short b2
etc.
and array is static short array[11].
This should generate code such as
if (b1 == 0) goto L1 else goto L2
L2:
if (b2 == 0) goto L1 else goto L3
L3:
if (b3 == 0) goto L1 else goto L4
L4:
if (b4 == 0) goto L1 else goto L5
L5:
if (b5 == 0) goto L1 else goto L6
L6:
if (b6 == 0) goto L1 else goto L7
L7:
if (b7 == 0) goto L1 else goto L8
L8:
if (b8 == 0) goto L1 else goto L9
L9:
if (b9 == 0) goto L1 else goto L10
L10:
if (b10 == 0) goto L1 else goto L11
L11:
if (b11 == 0) goto L1 else goto L12
L12:
if (b12 == 0) goto L1 else goto L13
L13:
array[i]=1 (for i from 0 to 10)
return
L1:
array[i]=0 (for i from 0 to 10)
return
This is exactly what 4.1 generates but 4.3 fails to combine the if sequences.
Version Details:
GNU C version 4.3.0 20070316 (experimental) (arm-none-eabi)
compiled by GNU C version 3.4.6 (Ubuntu 3.4.6-1ubuntu2).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
--
Summary: Bad Code generation ( Tree optimization )
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pranav dot bhandarkar at gmail dot com
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] Bad Code generation ( Tree optimization )
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-06-12 14:48 --- Created an attachment (id=13686) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13686action=view) Tes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] Bad Code generation ( Tree optimization )
--- Comment #2 from pranav dot bhandarkar at gmail dot com 2007-06-12 14:50 --- Created an attachment (id=13687) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13687action=view) Code Generated by 4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] Bad Code generation ( Tree optimization )
--- Comment #3 from pranav dot bhandarkar at gmail dot com 2007-06-12 14:50 --- Created an attachment (id=13688) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13688action=view) Code Generated by 4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug tree-optimization/32306] [4.2/4.3 Regression] Bad Code generation ( Tree optimization )
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-12 15:06 --- Try to narrow it down to sth shorter. (Looks like a jump-threading issue) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|arm-none-eabi | Keywords||missed-optimization Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2007-06-12 15:06:52 date|| Summary|Bad Code generation ( Tree |[4.2/4.3 Regression] Bad |optimization ) |Code generation ( Tree ||optimization ) Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
[Bug c++/32305] ICE in initialize_flags_in_bb with -O -fipa-pta
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-12 15:08 --- trunk-g/gcc ./cc1plus -O -fipa-pta t.ii S1::S1() S1::S1() S1::S1() void S2::f2() void f(S2) Analyzing compilation unit Performing interprocedural optimizations visibility early_local_cleanups inline static-var pure-const pta t.ii: In member function 'void S2::f2()': t.ii:10: error: stmt (0x2b369f6d8780) marked modified after optimization pass: _ZGVZN2S22f2EvE2s1.0_1 = (char *) _ZGVZN2S22f2EvE2s1; t.ii:10: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-06-12 15:08:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-12 15:09 --- Until I know for sure, i am moving this back to the fortran component, it might be a front end issuse still. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|middle-end |fortran Summary|[4.2, 4.3 Regression] |[4.2/4.3 Regression] |Incorrect result with -O2 |Incorrect result with -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug middle-end/32302] [4.2, 4.3 Regression] Incorrect result with -O2
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-12 15:03 --- Works with 4.1.3 20070521. Fails with 4.2.1 20070604. Fails with 4.3.0 20070612. (On x86_64 Linux) Result is ok (1.0 1.0) for real(4), but not for real(8) (0.25 0.25). -O1 is also ok, but not -O2. I used gfortran -DVECLEN=1 -DDP -O2 (and also without -DDP and with -O1.) Presumably a middle-end problem. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |middle-end Ever Confirmed|0 |1 GCC host triplet|powerpc-apple-darwin8.9.0 | Keywords||wrong-code Known to fail||4.2.0 4.3.0 Known to work||4.1.3 Last reconfirmed|-00-00 00:00:00 |2007-06-12 15:03:55 date|| Summary|gfortran - incorrect result |[4.2, 4.3 Regression] |with -O3|Incorrect result with -O2 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-06-12 15:15 --- I see those as well, on x86_64-unknown-linux-gnu FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O0 scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O1 scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O2 scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O3 -fomit-frame-pointer scan-tree-d ump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -O3 -g scan-tree-dump pow FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c -Os scan-tree-dump pow ./gcc/cc1 --version GNU C version 4.3.0 20070612 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.0 20070612 (experimental), GMP version 4.2.1, MPFR version 2.2.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug c/32307] New: ICE building simple httpd log.c for -m5282x option
The full command line is below. It appears to be triggered by -m528x and is
indepdendent of selected optimization level.
m68k-rtems4.8-gcc --pipe -DHAVE_CONFIG_H -I..
-I../../cpukit/../../../uC5282/lib/include -DHAVE_MD5 -Wall -fasm -m528x -O2
-g -MT libshttpd_a-log.o -MD -MP -MF .deps/libshttpd_a-log.Tpo -c -o
libshttpd_a-log.o `test -f 'log.c' || echo
'../../../../../../current/c/src/../../cpukit/shttpd/'`log.c
../../../../../../current/c/src/../../cpukit/shttpd/log.c: In function
'log_access':
../../../../../../current/c/src/../../cpukit/shttpd/log.c:111: error: insn does
not satisfy its constraints:
(insn 74 158 159 10
../../../../../../current/c/src/../../cpukit/shttpd/log.c:90 (set (mem/c:SI
(plus:SI (reg/f:SI 14 %a6)
(reg:SI 1 %d1)) [57 D.6863+0 S4 A16])
(mem/s:SI (plus:SI (reg/v/f:SI 10 %a2 [orig:48 c ] [48])
(const_int 220 [0xdc])) [22 variable.loc.io.total+0 S4 A16]))
34 {*movsi_cf} (nil)
(nil))
../../../../../../current/c/src/../../cpukit/shttpd/log.c:111: internal
compiler error: in reload_cse_simplify_operands, at postreload.c:393
Please submit a full bug report,
--
Summary: ICE building simple httpd log.c for -m5282x option
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-rtems4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug c/32307] ICE building simple httpd log.c for -m5282x option
--- Comment #1 from joel at gcc dot gnu dot org 2007-06-12 15:17 --- Created an attachment (id=13689) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13689action=view) preprocessed code to generate problem The following should reproduce the error: m68k-rtems4.8-gcc -m528x -c log_preprocessed.c I believe this should occur on any m68k target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug target/32307] ICE building simple httpd log.c for -m5282x option
--- Comment #2 from joel at gcc dot gnu dot org 2007-06-12 15:21 --- Tested using RTEMS cross RPMs for RTEMS 4.6 (gcc 3.2.3) and RTEMS 4.7 (gcc 4.1.1). -- joel at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.2.3 4.1.1 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-12 15:31 --- This is not a bug. Here is the deal, the reporter compiled GCC with the new headers but is using the old library (which is known to be buggy). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug target/32307] ICE building simple httpd log.c for -m5282x option
--- Comment #3 from joel at gcc dot gnu dot org 2007-06-12 15:39 --- Created an attachment (id=13690) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13690action=view) alternate version of bug file which has if 0 around offensive code I hacked on the file that tripped the bug and now have this one which has if 0's around the offensive code. It appears to have offensive sections. + an inline conditional + two calls to my_snprintf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug target/32288] Our C++ program (gcc 4.1.1 under Aix 5.3) crashes with a core dump
--- Comment #5 from alessandro dot mei at elsagdatamat dot com 2007-06-12 15:41 --- (In reply to comment #4) And why do you think GCC is at fault? It is hard to debug this huge sources really. Have you tried to pin point exactly where the issue. Do you have any uninitialized variables? Are you going over array bounds? Do you take an address of a local variable and keep it around even after it goes out of scope? We have tried to pin point exactly where the crash occurs. It is hard to debug the source really, we agree, however there is nothing strange at that line and that code works fine on the test server. We are using GCC 4.1.1 downloaded from aixpdslib UCLA ftp website. We suspect that the GCC binary downloaded from this ftp site had been compiled on an AIX 5.3 version different from the one we are using in the production server. So we are now asking support if our suspect could explain the crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32288
[Bug middle-end/32176] [4.3 Regression] ICE tree-type mismatch: expected integer_cst, have plus_expr in int_cst_value, at tree.c:7720
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-12 15:44 --- (In reply to comment #1) While the assert is occurs in the middle end, I think it is very likely a tree-type mismatch in the front end. I think it is. It also fails for me on i686-darwin, with -O2 -fprefetch-loop-arrays -m64. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2007-06-01 07:49:47 |2007-06-12 15:44:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32176
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-06-12 15:47 --- I see it also with today's compiler on i686-darwin: $ gfortran test.f90 -O2 ./a.out a.bb ccc -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2007-05-29 15:32:38 |2007-06-12 15:47:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug c++/32308] New: template typename T int CTemp int ::sta; make the error
gcc -v :
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
g++ -o a a.cpp
a.cpp: In function ¡®void func(T) [with T = int]¡¯:
a.cpp:19: instantiated from ¡®int CTempint::sta¡¯
a.cpp:19: instantiated from ¡®void func(T) [with T = int]¡¯
a.cpp:24: instantiated from here
a.cpp:19: internal compiler error: in instantiate_decl, at cp/pt.c:11775
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
Preprocessed source stored into /tmp/ccXG3CFA.out file, please attach this to
your bugreport.
Source File:
#includeiostream
using namespace std;
template class T
class CTemp{
private:
T element;
public:
CTemp (T arg):element(arg){ }
static int sta;
};
template typename T int CTemp int ::sta;
template class T
void func (T arg){
CTemp T a (arg);
int i;
cout a.sta endl;
return;
}
int main(){
func (5);
return 0;
}
I'm sorry but I find anywhere to add an attachment
--
Summary: template typename T int CTemp int ::sta; make the
error
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cxcxcxcx at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32308
[Bug fortran/32298] MINLOC / MAXLOC: off-by one for PARAMETER arrays
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-12 16:05 ---
The result is ok, if one removes PARAMETER.
If one looks at the dump one find the following difference between arrays which
are parameters and those which are variables:
-S.3 = 0;
+S.3 = 1;
while (1)
{
- if (S.3 6) goto L.3;
+ if (S.3 7) goto L.3;
- if (ABS_EXPR A.2[S.3] - D.1367 limit.1 || pos.0 == 0)
+ if (ABS_EXPR a[S.3 + -1] - D.1367 limit.1 || pos.0 ==
0)
{
- limit.1 = ABS_EXPR A.2[S.3] - D.1367;
+limit.1 = ABS_EXPR a[S.3 + -1] - D.1367;
-pos.0 = S.3;
+pos.0 = S.3;
(This might also affect MAXVAL/MINVAL, though I did not manage to cook up an
example.)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2007-06-12 16:05:26
date||
Summary|Intrinsic MINLOC / MAXLOC |MINLOC / MAXLOC: off-by one
|gives wrong results |for PARAMETER arrays
|(gfortran build 20070522) |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32298
[Bug middle-end/31541] [4.3 Regression] cannot take address of bit field
--- Comment #7 from dcb314 at hotmail dot com 2007-06-12 16:05 --- (In reply to comment #5) I am finally getting around to testing the patch (been busy with a release of our own toolchain last week). I can confirm that this bug still exists in gcc snapshot 20070608. Is it significant that the last couple of months of gcc 4.3 haven't been able to compile recent Linux kernels ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31541
[Bug c++/32308] template typename T int CTemp int ::sta; make the error
--- Comment #1 from cxcxcxcx at gmail dot com 2007-06-12 16:08 --- Created an attachment (id=13691) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13691action=view) The ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32308
[Bug fortran/32298] MINLOC / MAXLOC: off-by one for PARAMETER arrays
-- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org GCC target triplet|i386-pc-mingw32 | Known to fail||4.3.0 4.2.0 4.1.3 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32298
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #9 from tbm at cyrius dot com 2007-06-12 16:31 --- O32, just like Debian. Note that 4.0 also uses O32, although the kernel is 64-bit, so that might explain why it's configuring mips64 for you. I don't see the point of these questions though. After all, I confirmed your bug with gcc 4.1, and also that it's fixed in 4.2 and 4.3. So the remaining question is whether this will be fixed in 4.1 (which I doubt). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug target/32301] int __attribute__((vector_size(8))) doesn't use %mm0, produces ugly code
--- Comment #2 from tomash dot brechko at gmail dot com 2007-06-12 16:43 --- Sorry, I failed to find two other reports you reference, maybe I'm repeating someone's questions then. Okay, there are reasons not to use %mm0, but why %xmm0 is not used then? Something like f: movqb, %xmm0 movqa, %xmm1 paddd %xmm1, %xmm0 movq%xmm0, c ret And the other question is if copying of vector onto the stack is a misfeature, or there are reasons for doing that in synthesized vector operations, so this won't change. Thank you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32301
[Bug tree-optimization/32309] New: Unnecessary conversion from short to unsigend short breaks vectorization
void Sub(short * __restrict src1row, short * __restrict src2row, int
num_in_row) {
for(int i=num_in_row; i--;) {
*src1row -= *src2row;
++src1row;
++src2row;
}
}
In the test case above, GCC inserts several explicit conversions soon after the
gimple transformation stage and gets,
D.2097 = *src1row;
D.2098 = (short unsigned int) D.2097;
D.2099 = *src2row;
D.2100 = (short unsigned int) D.2099;
D.2101 = D.2098 - D.2100;
D.2102 = (short int) D.2101;
These conversions breaks the vectorization and GCC reports,
/* i686-unknown-linux-gnu-gcc -O3 -ftree-vectorize -ftree-vectorizer-verbose=5
-march=nocona -fno-strict-aliasing -c test.cc */
..
test.cc:2: note: not vectorized: relevant stmt not supported: D.2430_11 =
(short unsigned int) D.2429_10
test.cc:1: note: vectorized 0 loops in function.
--
Summary: Unnecessary conversion from short to unsigend short
breaks vectorization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gangren at google dot com
GCC build triplet: i686-unknown-linux-gnu-gcc
GCC host triplet: i686-unknown-linux-gnu-gcc
GCC target triplet: i686-unknown-linux-gnu-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-12 17:20 --- The conversions are not Unnecessary, they are necessary because short_var+short_var when that would overflow the range of short is still defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
[Bug fortran/32310] New: Intel-darwin specific ICE on CP2K code
I'm working towards reducing this, but it's coming slowly :( The code attached leads to an ICE with: $ gfortran -c -O0 qs_mo_types.f90 gfortran: Internal error: Illegal instruction (program f951) The backtrace for the ICE is: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xbf7fffec 0x000688fd in gfc_free_equiv_lists (l=Cannot access memory at address 0xbf70 0x44567150) at /tmp/gfortran-20070611/ibin/../gcc/gcc/fortran/symbol.c:2621 2621 gfc_free_equiv_lists (l-next); (gdb) where #0 0x000688fd in gfc_free_equiv_lists (l=0x44567150) at /tmp/gfortran-20070611/ibin/../gcc/gcc/fortran/symbol.c:2621 I wonder if this was introduced by Paul's patch recent for multiple equivalences. Paul, do you have any idea (I know you have no access to darwin, but I can debug for you if you so wish). I could not reproduce this on i386-linux (even with valgrind). -- Summary: Intel-darwin specific ICE on CP2K code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: i386-apple-darwin8.8.1 GCC host triplet: i386-apple-darwin8.8.1 GCC target triplet: i386-apple-darwin8.8.1 OtherBugsDependingO 29975 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32310
[Bug tree-optimization/32309] Unnecessary conversion from short to unsigend short breaks vectorization
--- Comment #2 from gangren at google dot com 2007-06-12 17:28 --- (In reply to comment #1) The conversions are not Unnecessary, they are necessary because short_var+short_var when that would overflow the range of short is still defined. Do you mean that short_var + short_var is defined as (short)((unsigned short)short_var + (unsigned short)short_var)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
