Re: M32C vs PR tree-optimization/39233

[DJ Delorie]

> 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?

I don't remember every patch you sent, but I"ve been careful to test
everything you've offered and reported it's effects.  If you can
recall which patch it was, I'll test it again.

I suspect that promoting a short to a pointer won't work right anyway,
as it means that pointers will always have the upper 8 bits masked
off.  The root of the problem is using HImode integers to store
PSImode pointers.

Re: M32C vs PR tree-optimization/39233

[Richard Guenther]

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  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=, 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=) 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=0xb974) 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.

Re: M32C vs PR tree-optimization/39233

[Paolo Bonzini]

> Note that the issue is with our representation of POINTER_PLUS_EXPR
> which insists on using sizetype for the pointer offset argument
> (where I don't remember if m32c uses a bigger or smaller mode for
> sizetype than for pointers).  Whenever the sizes of the modes for
> pointers and sizetype do not match we have a problem.
> 
> Note that while this particular issue may likely be fixed with
> the no-undefined-overflow branch work the above much general issue
> is _not_ fixed by it.

What about forbidding pointer induction variables completely if the
modes for sizetype and pointers do not match?

Paolo

Re: M32C vs PR tree-optimization/39233

[Richard Guenther]

On Wed, 15 Apr 2009, DJ Delorie wrote:

> > yes; however, maybe it would be easier to wait till Richard finishes the
> > work on not representing the overflow semantics in types (assuming that's
> > going to happen say in a few weeks?), which should make the fix
> > unnecessary,
> 
> Another thought - is this bug in the 4.4 branch?  If so, a 4.4 fix may
> be needed too.

Note that the issue is with our representation of POINTER_PLUS_EXPR
which insists on using sizetype for the pointer offset argument
(where I don't remember if m32c uses a bigger or smaller mode for
sizetype than for pointers).  Whenever the sizes of the modes for
pointers and sizetype do not match we have a problem.

Note that while this particular issue may likely be fixed with
the no-undefined-overflow branch work the above much general issue
is _not_ fixed by it.

Richard.

Re: M32C vs PR tree-optimization/39233

[DJ Delorie]

> yes; however, maybe it would be easier to wait till Richard finishes the
> work on not representing the overflow semantics in types (assuming that's
> going to happen say in a few weeks?), which should make the fix
> unnecessary,

Another thought - is this bug in the 4.4 branch?  If so, a 4.4 fix may
be needed too.

Re: M32C vs PR tree-optimization/39233

[DJ Delorie]

> yes; however, maybe it would be easier to wait till Richard finishes the
> work on not representing the overflow semantics in types (assuming that's
> going to happen say in a few weeks?), which should make the fix
> unnecessary,

Ah, ok.  Can I ask for m32c to be on the test list for this work?
It's probably the chip most sensitive to these kinds of problems.

Re: M32C vs PR tree-optimization/39233

[Zdenek Dvorak]

Hi,

> Can we somehow make this fix contingent on ports that have suitable
> integral modes?

yes; however, maybe it would be easier to wait till Richard finishes the
work on not representing the overflow semantics in types (assuming that's
going to happen say in a few weeks?), which should make the fix
unnecessary,

Zdenek