[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand

2014-03-26 Thread ramrad01 at arm dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655

--- Comment #6 from ramrad01 at arm dot com ---
On 03/26/14 09:46, jakub at gcc dot gnu.org wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655

 Jakub Jelinek jakub at gcc dot gnu.org changed:

 What|Removed |Added
 
   CC||jakub at gcc dot gnu.org

 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
 As discussed yesterday with Ramana on IRC, my suggested fix for this for 4.9 
 is
 something like:
 --- gcc/dwarf2out.c2014-03-03 08:24:14.841895755 +0100
 +++ gcc/dwarf2out.c2014-03-26 10:42:32.027508796 +0100
 @@ -11326,7 +11326,12 @@ const_ok_for_output_1 (rtx *rtlp, void *
   }

 if (GET_CODE (rtl) != SYMBOL_REF)
 -return 0;
 +{
 +  /* NOT is not handled by output_addr_const.  */
 +  if (GET_CODE (rtl) == NOT)
 +return 1;
 +  return 0;
 +}


I have a very similar patch under testing only with a comment linking 
this to the bug report and bootstrapping and regression testing on 
aarch64, armhf and x86_64.


 if (CONSTANT_POOL_ADDRESS_P (rtl))
   {

 and for 5.0 we want to gather some statistics what we actually accept as CONST
 operands in const_ok_for_output and then successfully emit it into debug info
 and assemble that, and based on that adjust const_ok_for_output or it's
 callers, so that for CONST expressions that have no chance of being assembled
 we actually ignore the CONST around the expression and try to emit it as the
 individual expressions.  So, say instead of trying to emit DW_OP_addr
 (-1-symbol) in this case which won't assemble we emit it as DW_OP_const1s -1
 DW_OP_addr (symbol) DW_OP_minus.

Agreed.


regards
Ramana

[Bug other/54398] Incorrect ARM assembly when building with -fno-omit-frame-pointer -O2

2012-09-11 Thread ramrad01 at arm dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398

--- Comment #7 from ramrad01 at arm dot com 2012-09-11 10:44:30 UTC ---
On 09/11/12 07:09, jakub at gcc dot gnu.org wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398

 Jakub Jelinek jakub at gcc dot gnu.org changed:

 What|Removed |Added
 
   CC||jakub at gcc dot gnu.org

 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11 
 06:09:13 UTC ---
 cselib.c has for this the various spots that special case
 HARD_FRAME_POINTER_REGNUM (or STACK_POINTER_REGNUM or FRAME_POINTER_REGNUM).
 Please see why that doesn't work in this case.


This rings a bell.

Maybe the patch mentioned below needs backporting given Carrot is 
reporting this against the 4.6 branch. What's not clear if this is 
reproducible on anything later though.

http://old.nabble.com/-PATCH--Prevent-cselib-substitution-of-FP,-SP,-SFP-td33080657.html

Full disclaimer that I've not investigated whether the same problem 
occurs on trunk.

HTH,
Ramana

[Bug target/54252] [4.7/4.8 Regression] Bad alignment code generated for Neon loads

2012-08-30 Thread ramrad01 at arm dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54252

--- Comment #9 from ramrad01 at arm dot com 2012-08-30 16:48:12 UTC ---
On 30/08/12 16:52, eric.batut at allegorithmic dot com wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54252

 --- Comment #8 from Eric Batut eric.batut at allegorithmic dot com 
 2012-08-30 15:52:20 UTC ---
 The original bug instance is fixed on trunk (rev 190803).
 I had what I think is another instance of the same bug, where the error 
 message
 is alignment of array elements is greater than element size, and this is 
 also
 fixed by rev 190803.


Good to hear that this fixes the original bug instance on trunk. I 
intend to do a backport to 4.7 next week if there are no more problems 
reported with this.


Thanks,
Ramana

[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives

2012-08-02 Thread ramrad01 at arm dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664

--- Comment #15 from ramrad01 at arm dot com 2012-08-02 10:10:47 UTC ---
On 08/02/12 00:35, janis at gcc dot gnu.org wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664

 --- Comment #14 from Janis Johnson janis at gcc dot gnu.org 2012-08-01 
 23:35:12 UTC ---
 Ramana, chunks of regular expressions within parentheses are matched and added
 to the returned expression that is used in scan-assembler-times.  To avoid
 returning parenthesized bits you need to replace (regexp) with (?:regexp).
 Here's what works in vst4Qu8.c (cut and pasted, so tabs are wrong):

 /* { dg-final { scan-assembler-times vst4\.8\[
 \]+\\\{(?:(?:\[dD\]\[0-9\]+-\[dD\]\[0-9\]+)|(?:\[dD\]\[0-9\]+, \[dD\]\[0-9\]+,
 \[dD\]\[0-9\]+, \[dD\]\[0-9\]+))\\\},
 \\\[\[rR\]\[0-9\]+\(?::\[0-9\]+\)?\\\]!?\(?:\[ \]+@\[a-zA-Z0-9 \]+\)?\n 2
 } } */


Thanks for digging further. I assume this will work the same regardless 
of whether it used in scan-assembler and scan-assembler-times. I'll try 
to change the generator later today if you think that to be the case or 
muck about with a couple of the vld2Q tests to check if this works there 
as well.


Ramana

 I haven't tried modifying the test generator.