Bug 36198 - [4.4 Regression] expected integer_cst, have mult_expr
Summary: [4.4 Regression] expected integer_cst, have mult_expr
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.4.0
: P2 normal
Target Milestone: 4.4.0
Assignee: Sebastian Pop
URL:
Keywords: ice-on-valid-code
Depends on: 36206
Blocks: 29975
  Show dependency treegraph
 
Reported: 2008-05-10 08:37 UTC by Joost VandeVondele
Modified: 2008-05-20 16:08 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-05-11 21:30:18


Attachments
all files needed to reproduce and a README with the command (19.60 KB, application/x-compressed-tar)
2008-05-10 08:44 UTC, Joost VandeVondele
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joost VandeVondele 2008-05-10 08:37:52 UTC
/data03/vondele/clean/cp2k/src/../src/d3_poly.F: In function ‘init_d3_poly_module’:
/data03/vondele/clean/cp2k/src/../src/d3_poly.F:68: internal compiler error: tree check: expected integer_cst, have mult_expr in int_cst_value, at tree.c:8002

after the fix for PR36129, gfortran ([trunk revision 135124]) ICEs with the above. I'll try to get to a testcase, but it only happens with -fprofile-use, so it will be an ugly testcase at best.
Comment 1 Joost VandeVondele 2008-05-10 08:44:47 UTC
Created attachment 15624 [details]
all files needed to reproduce and a README with the command

all files needed to reproduce and a README with the command
Comment 2 Joost VandeVondele 2008-05-10 10:03:47 UTC
backtrace

#0  internal_error (gmsgid=0xc2d800 "tree check: %s, have %s in %s, at %s:%d") at /data03/vondele/gcc_trunk/gcc/gcc/diagnostic.c:594
#1  0x00000000008a284e in tree_check_failed (node=0x2b6a9f6ec4c0, file=0xc2d628 "/data03/vondele/gcc_trunk/gcc/gcc/tree.c", line=8002, function=0xc2f7fc "int_cst_value")
    at /data03/vondele/gcc_trunk/gcc/gcc/tree.c:6764
#2  0x00000000008a2c08 in int_cst_value (x=0xffffffffffffffff) at /data03/vondele/gcc_trunk/gcc/gcc/tree.c:8002
#3  0x000000000072ca52 in analyze_subscript_affine_affine (chrec_a=0x2b6a9faf5410, chrec_b=0x2b6a9fc29000, overlaps_a=0x7fff0bb79240, overlaps_b=0x7fff0bb79238,
    last_conflicts=0x7fff0bb79248) at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:2076
#4  0x000000000072eb86 in analyze_siv_subscript (chrec_a=0xc2d800, chrec_b=0x7fff0bb78f70, overlaps_a=0xba887e, overlaps_b=0xc2f7fc, last_conflicts=0xc2d64a)
    at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:2394
#5  0x000000000072f783 in subscript_dependence_tester_1 (ddr=0x102c620, dra=0x126dea0, drb=0x102c570, loop_nest=0x2b6a9fc15820)
    at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:2633
#6  0x00000000007300cd in subscript_dependence_tester (ddr=0x102c620, loop_nest=0x2b6a9fc15820) at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:3219
#7  0x00000000007315e8 in compute_all_dependences (datarefs=0x1046270, dependence_relations=0x7fff0bb795e8, loop_nest=0x104ca60, compute_self_and_rr=1 '\001')
    at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:3849
#8  0x0000000000732899 in compute_data_dependences_for_loop (loop=0x2b6a9fc15820, compute_self_and_read_read_dependences=252 '', datarefs=0x7fff0bb795f0,
    dependence_relations=0x7fff0bb795e8) at /data03/vondele/gcc_trunk/gcc/gcc/tree-data-ref.c:4169
#9  0x00000000007786f2 in tree_predictive_commoning_loop (loop=0x2b6a9fc15820) at /data03/vondele/gcc_trunk/gcc/gcc/tree-predcom.c:2495
#10 0x0000000000779d5d in tree_predictive_commoning () at /data03/vondele/gcc_trunk/gcc/gcc/tree-predcom.c:2604
#11 0x00000000007fe6c7 in run_tree_predictive_commoning () at /data03/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop.c:191
Comment 3 Uroš Bizjak 2008-05-10 12:36:11 UTC
This is what goes into int_cst_value:

#2  0x00000000008a60c8 in int_cst_value (x=0x2aaaae72a4c0) at ../../gcc-svn/trunk/gcc/tree.c:8002
8002      unsigned HOST_WIDE_INT val = TREE_INT_CST_LOW (x);
(gdb) p debug_generic_expr (x)
((integer(kind=8)) {1, +, {1, +, 1}_1}_1 + -1) * 2
Comment 4 Richard Biener 2008-05-10 12:58:07 UTC
That looks more like a fallout from:

2008-05-09  Jan Sjodin  <jan.sjodin@amd.com>
            Sebastian Pop  <sebastian.pop@amd.com>

        * tree-scalar-evolution.c: Document instantiate_scev.
        (instantiate_parameters_1): Renamed instantiate_scev_1.
        Don't use the same loop for instantiation_loop and evolution_loop.
        (instantiate_scev): New.
        (instantiate_parameters): Moved...
        (resolve_mixers): Update call to instantiate_scev_1 to pass the
        same loop twice.  Maintains the semantics for this function.
        * tree-scalar-evolution.h (instantiate_scev): Declare.
        (instantiate_parameters): ...here.  Now static inline.
        * tree-data-ref.c (dr_analyze_indices): Call instantiate_scev
        instead of resolve_mixers.
Comment 5 Joost VandeVondele 2008-05-19 14:07:52 UTC
with the patches for PR36206, d3_poly appears to compile. However, gfortran segfaults later in the compilation process. 
Comment 6 Joost VandeVondele 2008-05-19 14:22:50 UTC
(In reply to comment #5)
> with the patches for PR36206, d3_poly appears to compile. However, gfortran
> segfaults later in the compilation process. 
> 
this seems an unrelated issue, now PR36265. I would say the patches of PR36206 work as advertised (I have not regression tested them).
Comment 7 Sebastian Pop 2008-05-20 16:08:59 UTC
Fixed.