public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Address as HImode when Pmode is QImode?
@ 2009-08-13 14:56 Markus L
  2009-08-13 22:54 ` Adam Nemet
  0 siblings, 1 reply; 3+ messages in thread
From: Markus L @ 2009-08-13 14:56 UTC (permalink / raw)
  To: gcc

Hi,

I am using gcc 4.4.1 and working on a port where

#define BITS_PER_UNIT 16
#define UNITS_PER_WORD 1
#define Pmode QImode
#define LONG_TYPE_SIZE 32

(i.e. int is 16 bits QImode, long is 32 bits HImode and pointer mode is QImode)

POINTERS_EXTEND_UNSIGNED is not defined since POINTER_SIZE is equal to
the width of Pmode

trying to compile a simple function like

int foo(int *a)
{
  int i,s = 0;
  for (i = 0; i < 256; i++)
    s += a[i];
  return s;
}

I run into an assert in convert_memory_address not beeing able to
convert the address rtx (beeing HImode) into to Pmode (i.e. QImode). A
few frames up the I can dump the tree node and it looks like the
address calculations are done in HImode. Why is the address beeing
calculated as unsigned long int and not as unsigned int which would be
Pmode for my target? Is this expected (and my problem originates from
elsewhere) or am I missing something obvious here?


#3  0x0821c0a7 in expand_expr_real_1 (exp=0xb7d2b0a8, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../trunk/gcc-4.4.1/gcc/expr.c:7576
(gdb) call debug_tree(exp)
 <target_mem_ref 0xb7d2b0a8
    type <integer_type 0xb7cae2d8 int sizes-gimplified public QI
        size <integer_cst 0xb7ca0348 constant 16>
        unit size <integer_cst 0xb7ca0364 constant 1>
        align 16 symtab 0 alias set 2 canonical type 0xb7cae2d8
precision 16 min <integer_cst 0xb7ca0444 -32768> max <integer_cst
0xb7ca0460 32767>
        pointer_to_this <pointer_type 0xb7cb5820>>

    arg 1 <plus_expr 0xb7d2a510
        type <integer_type 0xb7cae000 long unsigned int public
unsigned sizetype HI
            size <integer_cst 0xb7ca0508 constant 32>
            unit size <integer_cst 0xb7ca0524 constant 2>
            align 16 symtab 0 alias set -1 canonical type 0xb7cb51a0
precision 32 min <integer_cst 0xb7ca0540 0> max <integer_cst
0xb7ca0000 -1>>

        arg 0 <nop_expr 0xb7cacde0 type <integer_type 0xb7cae000 long
unsigned int>
            arg 0 <var_decl 0xb7d23000 i>
            /home/elamark/gcc/flexdsp_gcc/build_4.4.1/dotprod.c:21:5>
        arg 1 <nop_expr 0xb7cace00 type <integer_type 0xb7cae410 long
unsigned int>

            arg 0 <nop_expr 0xb7cacdc0 type <pointer_type 0xb7cb5820>

                arg 0 <nop_expr 0xb7cacda0 type <integer_type
0xb7cae000 long unsigned int>
                    arg 0 <parm_decl 0xb7d22000 a>
                    /home/elamark/gcc/flexdsp_gcc/build_4.4.1/dotprod.c:21:5>
                /home/elamark/gcc/flexdsp_gcc/build_4.4.1/dotprod.c:21:5>
            /home/elamark/gcc/flexdsp_gcc/build_4.4.1/dotprod.c:21:5>
        /home/elamark/gcc/flexdsp_gcc/build_4.4.1/dotprod.c:21:5>
    arg 5 <indirect_ref 0xb7caccc0 type <integer_type 0xb7cae2d8 int>

        arg 0 <var_decl 0xb7d23108 D.1196 type <pointer_type 0xb7cb5820>
            used unsigned ignored QI file
/home/elamark/gcc/flexdsp_gcc/build_4.4.1/dotprod.c line 21 col 11
size <integer_cst 0xb7ca0348 16> unit size <integer_cst 0xb7ca0364 1>
            align 16 context <function_decl 0xb7d18400 foo> chain
<var_decl 0xb7d23160 D.1197>>
        /home/elamark/gcc/flexdsp_gcc/build_4.4.1/dotprod.c:21:5>
    arg 6 <symbol_memory_tag 0xb7f124a4 SMT.10 type <integer_type
0xb7cae2d8 int>
        addressable used file
/home/elamark/gcc/flexdsp_gcc/build_4.4.1/dotprod.c line 17 col 5
context <function_decl 0xb7d18400 foo>>
    /home/elamark/gcc/flexdsp_gcc/build_4.4.1/dotprod.c:21:5>
(gdb)



#0  fancy_abort (file=0x88f0014 "../../trunk/gcc-4.4.1/gcc/explow.c",
line=326, function=0x88f0103 "convert_memory_address") at
../../trunk/gcc-4.4.1/gcc/diagnostic.c:712
#1  0x081f0e5a in convert_memory_address (to_mode=QImode,
x=0xb7d293f0) at ../../trunk/gcc-4.4.1/gcc/explow.c:326
#2  0x081f0e7f in memory_address (mode=QImode, x=0xb7d293f0) at
../../trunk/gcc-4.4.1/gcc/explow.c:417
#3  0x0821c0a7 in expand_expr_real_1 (exp=0xb7d2b0a8, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../trunk/gcc-4.4.1/gcc/expr.c:7576
#4  0x0821952c in expand_expr_real (exp=0xb7d2b0a8, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../trunk/gcc-4.4.1/gcc/expr.c:7125
#5  0x0820674d in expand_expr (exp=0xb7d2b0a8, target=0x0,
mode=VOIDmode, modifier=EXPAND_NORMAL) at
../../trunk/gcc-4.4.1/gcc/expr.h:539
#6  0x08218115 in expand_operands (exp0=0xb7d23058, exp1=0xb7d2b0a8,
target=0x0, op0=0xbfbad064, op1=0xbfbad060, modifier=EXPAND_NORMAL) at
../../trunk/gcc-4.4.1/gcc/expr.c:6735
#7  0x0822688c in expand_expr_real_1 (exp=0xb7d2a60c,
target=0xb7d29310, tmode=QImode, modifier=EXPAND_NORMAL,
alt_rtl=0xbfbae8f0) at ../../trunk/gcc-4.4.1/gcc/expr.c:8498
#8  0x0821952c in expand_expr_real (exp=0xb7d2a60c, target=0xb7d29310,
tmode=QImode, modifier=EXPAND_NORMAL, alt_rtl=0xbfbae8f0) at
../../trunk/gcc-4.4.1/gcc/expr.c:7125
#9  0x0820c363 in store_expr (exp=0xb7d2a60c, target=0xb7d29310,
call_param_p=0, nontemporal=0 '\0') at
../../trunk/gcc-4.4.1/gcc/expr.c:4611
#10 0x0820ad93 in expand_assignment (to=0xb7d23058, from=0xb7d2a60c,
nontemporal=0 '\0') at ../../trunk/gcc-4.4.1/gcc/expr.c:4395
#11 0x082310d1 in expand_expr_real_1 (exp=0xb7d2a630, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../trunk/gcc-4.4.1/gcc/expr.c:9234
#12 0x0821952c in expand_expr_real (exp=0xb7d2a630, target=0xb7ca42b8,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../trunk/gcc-4.4.1/gcc/expr.c:7125
#13 0x084a19e2 in expand_expr (exp=0xb7d2a630, target=0xb7ca42b8,
mode=VOIDmode, modifier=EXPAND_NORMAL) at
../../trunk/gcc-4.4.1/gcc/expr.h:539
#14 0x084a3311 in expand_expr_stmt (exp=0xb7d2a630) at
../../trunk/gcc-4.4.1/gcc/stmt.c:1352
#15 0x0878cb6a in expand_gimple_basic_block (bb=0xb7c9aac8) at
../../trunk/gcc-4.4.1/gcc/cfgexpand.c:1979
#16 0x0878e199 in gimple_expand_cfg () at
../../trunk/gcc-4.4.1/gcc/cfgexpand.c:2382
#17 0x083e2ba6 in execute_one_pass (pass=0x8993ec0) at
../../trunk/gcc-4.4.1/gcc/passes.c:1280
#18 0x083e2ddc in execute_pass_list (pass=0x8993ec0) at
../../trunk/gcc-4.4.1/gcc/passes.c:1329
#19 0x08531811 in tree_rest_of_compilation (fndecl=0xb7d18400) at
../../trunk/gcc-4.4.1/gcc/tree-optimize.c:420
...

thanks and best regards
/Markus

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Address as HImode when Pmode is QImode?
  2009-08-13 14:56 Address as HImode when Pmode is QImode? Markus L
@ 2009-08-13 22:54 ` Adam Nemet
  2009-08-14 10:20   ` Markus L
  0 siblings, 1 reply; 3+ messages in thread
From: Adam Nemet @ 2009-08-13 22:54 UTC (permalink / raw)
  To: Markus L; +Cc: gcc

Markus L <markusl.se78@gmail.com> writes:
> I run into an assert in convert_memory_address not beeing able to
> convert the address rtx (beeing HImode) into to Pmode (i.e. QImode). A
> few frames up the I can dump the tree node and it looks like the
> address calculations are done in HImode. Why is the address beeing
> calculated as unsigned long int and not as unsigned int which would be
> Pmode for my target? Is this expected (and my problem originates from
> elsewhere) or am I missing something obvious here?

What's your sizetype?  This could be related to:

http://gcc.gnu.org/ml/gcc/2008-05/msg00313.html

Adam

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Address as HImode when Pmode is QImode?
  2009-08-13 22:54 ` Adam Nemet
@ 2009-08-14 10:20   ` Markus L
  0 siblings, 0 replies; 3+ messages in thread
From: Markus L @ 2009-08-14 10:20 UTC (permalink / raw)
  To: Adam Nemet; +Cc: gcc

Hi Adam,

Looks like you were right! My SIZE_TYPE was undefined so it defaulted
to "long unsigned int". Setting it to "unsigned int" solved my
problems.

Thank you very much!
/Markus


2009/8/13 Adam Nemet <anemet@caviumnetworks.com>:
> Markus L <markusl.se78@gmail.com> writes:
>> I run into an assert in convert_memory_address not beeing able to
>> convert the address rtx (beeing HImode) into to Pmode (i.e. QImode). A
>> few frames up the I can dump the tree node and it looks like the
>> address calculations are done in HImode. Why is the address beeing
>> calculated as unsigned long int and not as unsigned int which would be
>> Pmode for my target? Is this expected (and my problem originates from
>> elsewhere) or am I missing something obvious here?
>
> What's your sizetype?  This could be related to:
>
> http://gcc.gnu.org/ml/gcc/2008-05/msg00313.html
>
> Adam
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-08-14  7:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-13 14:56 Address as HImode when Pmode is QImode? Markus L
2009-08-13 22:54 ` Adam Nemet
2009-08-14 10:20   ` Markus L

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).