This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT


On Apr  9, 2001, Joern Rennecke <amylaar@redhat.com> wrote:

>  Is it safe to use arithmetic SHIFTs instead of letting the compiler
>> choose them instead of DIVs and MULTs?  For some reason, on
>> mn10300-elf, the div makes it to the generated code, which we
>> certainly don't want.

> A signed division is not a portable way to extract a bit.

I don't want to extract a bit.  I want to extract the remaining bits.
The delta was shifted left (or multiplied by 2) to make room for the
vbit; now I want the delta back.  It's a signed offset.  The question
is : does GCC's notion of arithmetic shift, in the tree level,
guarantee sign-extension semantics, or do we really have to use
TRUNC_DIV, and I have to figure out why the heck it's not being
converted to an arithmetic shift on mn10300-elf, given that the asr
opcode does exactly the right thing.

> And for negative values, it just doesn't work.

Doh.  Never mind.  I *does* work.  It's TRUNC_DIV that doesn't, for
what I need.  I really need a right shift with sign extension:

     3 >> 1 == 1
     2 >> 1 == 1
     1 >> 1 == 0
     0 >> 1 == 0
0xffff >> 1 == 0xffff
0xfffe >> 1 == 0xffff
0xfffd >> 1 == 0xfffe
0xfffc >> 1 == 0xfffe

Does RSHIFT_EXPR guarantee the preservation of the most significant
(sign) bit?  Does it guarantee the semantics above?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]