From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexandre Oliva To: Joern Rennecke Cc: wilson@cygnus.com (Jim Wilson), gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: C++ ptrmemfun break if FUNCTION_BOUNDARY < 2 * BITS_PER_UNIT Date: Mon, 09 Apr 2001 13:12:00 -0000 Message-id: References: <200104091927.f39JRtw00873@phal.cambridge.redhat.com> X-SW-Source: 2001-04/msg00075.html On Apr 9, 2001, Joern Rennecke 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