Debugging var-tracking problem

[Michael Collison]

Folks,

I am working on a bug in variable tracking:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033

GCC is looping infinitely in attempting to solve a data flow problem in 
vt_find_locations. My working theory is that compute_bb_dataflow is 
incorrectly asserting some value has changed when it has not. I have 
reduced my case to a candidate set of basic blocks and a (candidate) RTL 
location this is continually removed/added. The rtl location is:


dataflow difference found: removal of:
 name: D#255
   offset 0
 (mem/f/c:SI (value/u:SI 106:3955 @0x22cb2f8/0x23424a0) [3 
result.d+0 S4 A32])


I understand that the argument to 'VALUE" is a cselib_val_struct but I 
don't know how to map this back to a insn that is causing the problem. 
Any thoughts on how I might debug thus further?


Regards,

Michael Collison
michael.colli...@linaro.org

RTL representation of i386 shrdl instruction is incorrect?

[Niranjan Hasabnis]

Hello,

I was studying i386 machine description for my research purpose,
and I stumbled upon following MD entry for 'shrdl' x86 instruction.
It is obtained from the most recent i386.md file.

(define_insn "x86_shrd"
  [(set (match_operand:SI 0 "nonimmediate_operand" "+r*m")
(ior:SI (ashiftrt:SI (match_dup 0)
 (match_operand:QI 2 "nonmemory_operand" "Ic"))
(ashift:SI (match_operand:SI 1 "register_operand" "r")
 (minus:QI (const_int 32) (match_dup 2)
   (clobber (reg:CC FLAGS_REG))]
  ""
  "shrd{l}\t{%s2%1, %0|%0, %1, %2}"
  [(set_attr "type" "ishift")
   (set_attr "prefix_0f" "1")
   (set_attr "mode" "SI")
   (set_attr "pent_pair" "np")
   (set_attr "athlon_decode" "vector")
   (set_attr "amdfam10_decode" "vector")
   (set_attr "bdver1_decode" "vector")])

It seems to me that the RTL representation for 'shrdl' is incorrect.

Semantics of shrdl instruction as per Intel manual is:
"The instruction shifts the first operand (destination operand) to the right
the number of bits specified by the third operand (count operand).
The second operand (source operand) provides bits to shift in from the
left (starting with the most significant bit of the destination operand)."
And the way RTL does it is by inclusive-or of arithmetically
right-shifted destination and left-shifted source operand.

But the problem is that: in case of a destination (reg/mem) containing
negative value, arithmetically right-shifted destination will have top bits
set to 1. Inclusive-or with such a value is going to generate a
result with top bits set to 1 instead of moving contents of source
into top bits of destination.

E.g., when ebx = b72f60d0, ebp = bfcbd2c8
shrdl $16, %ebp, %ebx (ebx is dest, ebp is src)
produces 0xd2c8b72f in ebx.
But the corresponding RTL produces 0xb72f in ebx.

So it seems to me that instead of 'ashiftrt', RTL should have 'lshiftrt'.
Can anyone help me with this confusion?

-- 

Thanks,
Niranjan Hasabnis,
PhD student,
Secure Systems Lab,
Stony brook University,
Stony brook, NY.

gcc-4.9-20140604 is now available

[gccadmin]

Snapshot gcc-4.9-20140604 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140604/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch 
revision 211248

You'll find:

 gcc-4.9-20140604.tar.bz2 Complete GCC

  MD5=57aa4ff81c56262dc89994853c4d0149
  SHA1=103f634c9e94e0abe8a9801bf0ace555f7111379

Diffs from 4.9-20140528 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.