Thank you for your explanations, looking in "detail" what happens in my case (I would like to have modes that have less bits/precision than BITS_PER_UNIT), I cannot understand if there is a bug in convert.c:440 or is a feature that prevents me to use a FRACTIONAL_INT as a small precision (<memory layout size) integer mode that has the same memory layout as an integer. The conbination of SHORT_TYPE_SIZE=BITS_PER_WORD/2 and the definition of FRACTIONAL_INT_MODE (PQ, 16, 1) generate a recursive loop (then a segmentation) trying to convert the small precision type to the size of the mode PQ that has 1*BITS_PER_WORD bits as memory layout. To summarize I think (and probably I make a mistake), that this control should be avoided at least in case of fractional_int_modes with precision< BITS_PER_UNIT. Modifing this check I succeeded in my cross compilation of simple short integer/integer programs on my not byte oriented architecture (similar to c4x). What do you think?
best regards Andrea. On Thu, 17 Mar 2005 17:45:29 +0000 (UTC), Joseph S. Myers <[EMAIL PROTECTED]> wrote: > On Thu, 17 Mar 2005, Andrea wrote: > > > I'm trying to port gcc 4.1 for an architecture that has the following > > memory layout BITS_PER_UNIT=32 and UNITS_PER_WORD=1. > > Support for systems with bytes wider than 8 bits is somewhat bitrotten at > present, as it seems little has been done on the c4x port lately and it is > the only such port we currently have; various PRs indicate it simply > doesn't work (won't build libgcc) at present. I have however CC:ed the > maintainer of the c4x port in case he should wish to improve the state of > this port and the general support for such ports. > > > It has support (16bit registers and operators) for 16bit signed > > atithmetic used mainly for addressing. There are also operators for 32 > > bit integer and floating point support. > > I set SHORT_TYPE_SIZE=POINTER_SIZE=(BITS_PER_WORD/2). > > short needs to have at least the precision of char in C. (C99 made > explicit various aspects of the ordering rules for type precision which > C90 was insufficiently complete about.) > > However, types narrower than char do work in the compiler - we have them > for bit-fields. As required by the C standard, types narrower that int > are promoted to int in arithmetic. Bit-field types don't have their own > modes, but in principle you should be able to have a special type with its > own mode narrower than char: however, you may need to implement > optimizations which convert operations on promoted types to operations on > narrow types for targets with such types. > > -- > Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ > [EMAIL PROTECTED] (personal mail) > [EMAIL PROTECTED] (CodeSourcery mail) > [EMAIL PROTECTED] (Bugzilla assignments and CCs) >
