Hi Camm, No, I don't do maintenance of gcc, I just help out where I can with Debian/ia64 (speaking of which, I have a bug investigation to follow up on). I'm going to have to check what version of gcc I have installed on my machines. If you can send me a test case or perhaps (simple!!) instructions on how to reproduce this, I can try it on my machine (assuming I have a different gcc version). It would be a waste, IMO, to file a bug (upstream) that is fixed in a later version of gcc, unless upstream is still actively maintaining that branch and looking for fixes. I imagine Debian maintainers, however, would be interested in seeing whatever their blessed version of gcc have a code generation bug fixed, even if it is just ia64.
On Fri, Oct 18, 2013 at 2:37 PM, Camm Maguire <[email protected]>wrote: > Greetings! > > > Now `cmp.eq` R8 does equal R14 here, doesn't it? This would make p6 = 1 > and p7 = 0 > > > > This clearly isn't doing the comparison you were hoping for since this > is always true. > > > > Yep. > > > > > In your first message you wrote: > > > > if(((V459))==((object)&Cnil_body)){ > > > > But here I see: > > if(((V459))==Cnil){ > > > > OK, so what exactly is going on here? Is Cnil / Cnil_body a constant > > value (address of a function) and V459 some function pointer variable > > it is being compared against? If so, then I would say it is generating > > the wrong code. Notice that: > > > > Yes, Cnil is a macro defined as &Cnil_body. Cnil_body is a constant > structure defined as a global. > > > > V459 == 0x6000000004af3450 == r41 == r14 == r8 > > > > It should be loading the value of Cnil / Cnil_body (const) to do the > > comparison, instead it's comparing a register against another register > > it just copied from! > > Yes, I agree. I couldn't quite parse the assembly syntax, but your > comments make it clear. > > > Please let me know if this helps. > > > > This helps to an extent, but a test case would be better. This code > > looks almost machine generated (variable names/labels are > > mechnical-looking), and it's hard to grasp without full context; but > > This is gcl generated C code. > > > the disassembly is huge by itself to just "read". I think I have made > > sense of it, and I think I would agree. I bet this (and perhaps > > another bug, yet unknown) is the cause of some ia64 weirdness. > > I think you've grasped it very clearly. So I guess I should file a gcc > bug? Wonder how long that will take to process.... You don't happen to > maintain gcc for ia64, do you? > > Take care, > -- > Camm Maguire [email protected] > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah >
