FYI: my h8/300h builds are failing with the same message, but with different types. Haven't investigated yet.
> What size is the internal 'sizetype'? 16 bits. > Is there an integer type with the same width as the pointer type? No. The m32c doesn't have enough operators to have a pointer-sized sizetype (specifically, it needs an arbitrary-multiply op). There is a PSImode type, but no C type to correspond to it. Pointers are 24 bits because the address registers are physically 24 bits wide, and there are some math operators that operate on them directly (adding and shifting, mostly). But 24 bit math is incomplete, and 32 bit math is a LOT more expensive than 16 bit math. > Basically the problems look like converting a pointer to an integer > always either extends or truncates which is both prohibited in the > GIMPLE IL (as the pointer doesn't have a sign we don't know whether > to sign- or zero-extend it). In this case, though, we *are* doing signed arithmatic on it before converting. Plus, the code would work (for m32c) if there were no conversion at all - just leave it as a pointer type. > Richard. > > > [ gdb ] up > > #3 0x085588ec in verify_gimple_2 (stmts=0xb6e7c738) at > > ../../gcc/gcc/tree-cfg.c:4126 > > 4126 bool err2 = verify_gimple_stmt (stmt); > > > > [ gdb ] call debug_generic_expr (stmts) > > D.25526 = &this->D.17063._vptr.basic_ostream; > > D.25527 = *D.25526; > > D.25528 = D.25527 + -12; > > D.25529 = *D.25528; > > D.25530 = (unsigned int) D.25529; > > D.25531 = this + D.25530; > > *.LTHUNK0 (D.25531);
