Re: M32C vs PR tree-optimization/39233

[Richard Guenther <rguenther at suse dot de>]

On Wed, 15 Apr 2009, DJ Delorie wrote:

> 
> As of this fix (yes, I know it was some time ago - I've been busy),
> the m32c-elf build fails building the target libiberty:
> 
> ./cc1 -fpreprocessed regex.i -quiet -dumpbase regex.c -mcpu=m32cm \
> -auxbase-strip regex.o -g -O2 -W -Wall -Wwrite-strings -Wc++-compat \
> -Wstrict-prototypes -pedantic -version -o regex.s
> 
> 
> In file included from ../../../../gcc/libiberty/regex.c:639:
> ../../../../gcc/libiberty/regex.c: In function 'byte_re_match_2_internal':
> ../../../../gcc/libiberty/regex.c:7481: internal compiler error: in gen_add2_insn, at optabs.c:4733
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> cc1.r144405.20090224-060515 - failed
> 
> The problem is, you *can't* treat pointers and integers the same on
> m32c, as there is no integral type (16-bit? 32?) the same size as a
> pointer (24 bits).  Pointer math and pointer compatisons need to be
> done with pointer types.
> 
> [ gdb ] where
> #0  fancy_abort (file=0x87e22a8 "../../gcc/gcc/optabs.c", line=4746, 
>     function=0x87e28c9 "gen_add2_insn") at ../../gcc/gcc/diagnostic.c:724
> #1  0x0837ddc5 in gen_add2_insn (x=0xb7993bb0, y=0xb7993b80) at ../../gcc/gcc/optabs.c:4745
> #2  0x083f9df7 in gen_reload (out=0xb7993bb0, in=0xb7d086a8, opnum=0, type=RELOAD_FOR_INPUT)
>     at ../../gcc/gcc/reload1.c:8248
> #3  0x083fa959 in emit_input_reload_insns () at ../../gcc/gcc/reload1.c:7217
> #4  do_input_reload (chain=<value optimized out>, rl=0x8896fcc, j=1)
>     at ../../gcc/gcc/reload1.c:7511
> #5  0x083ff278 in emit_reload_insns () at ../../gcc/gcc/reload1.c:7702
> #6  reload_as_needed (live_known=1) at ../../gcc/gcc/reload1.c:4217
> #7  0x084040f9 in reload (first=0xb7c8cd80, global=1) at ../../gcc/gcc/reload1.c:1169
> #8  0x0832f799 in ira (f=<value optimized out>) at ../../gcc/gcc/ira.c:3239
> #9  0x08331b50 in rest_of_handle_ira () at ../../gcc/gcc/ira.c:3309
> #10 0x08396aed in execute_one_pass (pass=0x884a200) at ../../gcc/gcc/passes.c:1290
> #11 0x08396d5c in execute_pass_list (pass=0x884a200) at ../../gcc/gcc/passes.c:1339
> #12 0x08396d6f in execute_pass_list (pass=0x886bce0) at ../../gcc/gcc/passes.c:1340
> #13 0x084aca80 in tree_rest_of_compilation (fndecl=0xb7fb5400) at ../../gcc/gcc/tree-optimize.c:437
> #14 0x0860d3e2 in cgraph_expand_function (node=0xb7e84680) at ../../gcc/gcc/cgraphunit.c:1048
> #15 0x0860f23f in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1107
> #16 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1312
> #17 0x080a5c0b in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:8174
> #18 0x0845817b in compile_file () at ../../gcc/gcc/toplev.c:989
> #19 do_compile () at ../../gcc/gcc/toplev.c:2243
> #20 toplev_main (argc=20, argv=0xbffff974) at ../../gcc/gcc/toplev.c:2278
> #21 0x081266e2 in main (argc=Cannot access memory at address 0x23
> ) at ../../gcc/gcc/main.c:35
> 
> [ gdb ] call debug_reload(rl)
> Reload 0: reload_in (HI) = (reg:HI 377 [ D.9641 ])
>         A_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0)
>         reload_in_reg: (reg:HI 377 [ D.9641 ])
>         reload_reg_rtx: (reg:HI 4 a0)
> Reload 1: reload_in (PSI) = (plus:PSI (reg:HI 377 [ D.9641 ])
>                                                     (const_int 4 [0x4]))
>         A_REGS, RELOAD_FOR_INPUT (opnum = 0), inc by 4
>         reload_in_reg: (plus:PSI (reg:HI 377 [ D.9641 ])
>                                                     (const_int 4 [0x4]))
>         reload_reg_rtx: (reg:PSI 4 a0)
> Reload 2: reload_in (PSI) = (mem/f:PSI (reg/f:PSI 5 a1 [995]) [7 S4 A8])
>         A_HI_MEM_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
>         reload_in_reg: (mem/f:PSI (reg/f:PSI 5 a1 [995]) [7 S4 A8])
> 
> 
> Note "(plus:PSI (reg:HI) (const_int))" - the mode conflict between PSI
> and HI causes problems.
> 
> Can we somehow make this fix contingent on ports that have suitable
> integral modes?

I'm not sure if this is the same problem, but didn't I suggest in
the past to fix this up during expansion?  That is, if we end up
with a POINTER_PLUS_EXPR with different mode size pointer and offset
promote (or demote) the offset argument to pointer size properly?

What happened to these patch snippets I sent you?  Would they fix
this issue?

Thanks,
Richard.