[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  
> 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 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  changed:
>
> What|Removed |Added
> 
>   CC||jakub at gcc dot gnu.org
>
> --- Comment #6 from Jakub Jelinek  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 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  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.
>

[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  changed:
>
> What|Removed |Added
> 
>   CC||jakub at gcc dot gnu.org
>
> --- Comment #5 from Jakub Jelinek  ---
> 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



>