Re: [bootstrap-O3,fortran] silence warning in simplify_transformation_to_array

[Christophe Lyon]

Hi Alexandre,

On 6 January 2017 at 04:27, Alexandre Oliva  wrote:
> On Jan  5, 2017, Jeff Law  wrote:
>
>> On 01/05/2017 05:15 AM, Richard Biener wrote:
>>> Reasonable -- I'll leave it for others to comment on that "standard
>>> practice" part (it'll be the first case of using this IIRC).
>
>> It's a fair amount of clutter.  But I won't object.
>
> I'll take these as a tentative ok and check it in before swapping it all
> out and going on vacations ;-) If there's an objection, you all feel
> free to revert if I don't respond in a timely manner ;-)
>

I makes my aarch64*linux* and arm*linux* builds for fail, because:
gcc/fortran/simplify.c:613: error: #pragma GCC diagnostic not allowed
inside functions
gcc/fortran/simplify.c:620: error: #pragma GCC diagnostic not allowed
inside functions
gcc/fortran/simplify.c:624: error: #pragma GCC diagnostic not allowed
inside functions

My host compiler is RHEL6's, that is 4.4.7

I'm not sure what current minimum gcc version is required to build gcc?

Christophe

> --
> Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/   FSF Latin America board member
> Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [patch,avr] PR78883: Implement CANNOT_CHANGE_MODE_CLASS.

[Denis Chertykov]

2017-01-02 19:22 GMT+04:00 Georg-Johann Lay :
> On 02.01.2017 15:54, Dominik Vogt wrote:
>>
>> On Mon, Jan 02, 2017 at 03:47:43PM +0100, Georg-Johann Lay wrote:
>>>
>>> This fixes PR78883 which is a problem in reload revealed by a
>>> change to combine.c.  The fix is as proposed by Segher: implement
>>> CANNOT_CHANGE_MODE_CLASS.
>>>
>>> Ok for trunk?
>>>
>>> Johann
>>>
>>>
>>> gcc/
>>> PR target/78883
>>> * config/avr/avr.h (CANNOT_CHANGE_MODE_CLASS): New define.
>>> * config/avr/avr-protos.h (avr_cannot_change_mode_class): New
>>> proto.
>>> * config/avr/avr.c (avr_cannot_change_mode_class): New function.
>>>
>>> gcc/testsuite/
>>> PR target/78883
>>> * gcc.c-torture/compile/pr78883.c: New test.
>>
>>
>>> Index: config/avr/avr-protos.h
>>> ===
>>> --- config/avr/avr-protos.h (revision 244001)
>>> +++ config/avr/avr-protos.h (working copy)
>>> @@ -111,7 +111,7 @@ extern int _reg_unused_after (rtx_insn *
>>>  extern int avr_jump_mode (rtx x, rtx_insn *insn);
>>>  extern int test_hard_reg_class (enum reg_class rclass, rtx x);
>>>  extern int jump_over_one_insn_p (rtx_insn *insn, rtx dest);
>>> -
>>> +extern int avr_cannot_change_mode_class (machine_mode, machine_mode,
>>> enum reg_class);
>>>  extern int avr_hard_regno_mode_ok (int regno, machine_mode mode);
>>>  extern void avr_final_prescan_insn (rtx_insn *insn, rtx *operand,
>>> int num_operands);
>>> Index: config/avr/avr.c
>>> ===
>>> --- config/avr/avr.c(revision 244001)
>>> +++ config/avr/avr.c(working copy)
>>> @@ -11833,6 +11833,21 @@ jump_over_one_insn_p (rtx_insn *insn, rt
>>>  }
>>>
>>>
>>> +/* Worker function for `CANNOT_CHANGE_MODE_CLASS'.  */
>>> +
>>> +int
>>> +avr_cannot_change_mode_class (machine_mode from, machine_mode to,
>>> +  enum reg_class /* rclass */)
>>> +{
>>> +  /* We cannot access a hard register in a wider mode, for example we
>>> + must not access (reg:QI 31) as (reg:HI 31).  HARD_REGNO_MODE_OK
>>> + would avoid such hard regs, but reload would generate it anyway
>>> + from paradoxical subregs of mem, cf. PR78883.  */
>>> +
>>> +  return GET_MODE_SIZE (to) > GET_MODE_SIZE (from);
>>
>>
>> I understand how this fixes the ICE, but is it really necessary to
>> suppress conversions to a wider mode for lower numbered registers?
>
>
> If there is a better hook, I'll propose an according patch.
>
> My expectation was that HARD_REGNO_MODE_OK would be enough to keep
> reload from putting HI into odd registers (and in particular into R31).
> But this is obviously not the case...
>
> And internals are not very helpful here.  It only mentions modifying
> ordinary subregs of pseudos, but not paradoxical subreg of memory.
>
> What's also astonishing me is that this problem never popped up
> during the last > 15 years of avr back-end.

May be it's a related problem: https://gcc.gnu.org/ml/gcc/2011-02/msg00444.html

>
> Johann
>
>
>
>>> +}
>>> +
>>> +
>>>  /* Worker function for `HARD_REGNO_MODE_OK'.  */
>>>  /* Returns 1 if a value of mode MODE can be stored starting with hard
>>> register number REGNO.  On the enhanced core, anything larger than
>>> Index: config/avr/avr.h
>>> ===
>>> --- config/avr/avr.h(revision 244001)
>>> +++ config/avr/avr.h(working copy)
>>> @@ -216,6 +216,9 @@ These two properties are reflected by bu
>>>
>>>  #define MODES_TIEABLE_P(MODE1, MODE2) 1
>>>
>>> +#define CANNOT_CHANGE_MODE_CLASS(MFROM, MTO, RCLASS) \
>>> +  avr_cannot_change_mode_class (MFROM, MTO, RCLASS)
>>> +
>>>  enum reg_class {
>>>NO_REGS,
>>>R0_REG,  /* r0 */
>>> Index: testsuite/gcc.c-torture/compile/pr78883.c
>>> ===
>>> --- testsuite/gcc.c-torture/compile/pr78883.c   (nonexistent)
>>> +++ testsuite/gcc.c-torture/compile/pr78883.c   (working copy)
>>> @@ -0,0 +1,12 @@
>>> +/* { dg-do compile } */
>>> +
>>> +int foo (int *p)
>>> +{
>>> +  int i;
>>> +  for (i = 0; i < 5; i++)
>>> +{
>>> +  if (p[i] & 1)
>>> +return i;
>>> +}
>>> +  return -1;
>>> +}
>>
>>
>> Ciao
>>
>> Dominik ^_^  ^_^
>>
>

Re: [bootstrap-O1] change value type to avoid sprintf buffer size warning

[Andreas Schwab]

On Jan 06 2017, Alexandre Oliva  wrote:

> On Jan  5, 2017, Andreas Schwab  wrote:
>
>> On Jan 05 2017, Alexandre Oliva  wrote:
>>> On Jan  5, 2017, Andreas Schwab  wrote:
>>> 
 On Jan 05 2017, Alexandre Oliva  wrote:
> -  sprintf (xname, "", ((unsigned)((uintptr_t)(t) & 0x)));
> +  sprintf (xname, "", ((unsigned short)((uintptr_t)(t) & 
> 0x)));
>>> 
 Please fix the spacing while you are at it.
>>> 
>>> Err...  I sure would, if I knew what fix you had in mind.  Care to share
>>> your thoughts?  Thanks,
>
>> Space after cast.
>
> Wow, thanks, I think I never got that one right.
>
> Here's what I'm installing, also breaking the now-too-long line:

Alternatively you could remove the redundant parens.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Make MicroBlaze support DWARF EH (old Xilinx patch, needed for glibc build)

[Edgar E. Iglesias]

On Thu, Jan 05, 2017 at 05:58:01PM +, Joseph Myers wrote:
> On Thu, 5 Jan 2017, Michael Eager wrote:
> 
> > On multiple occasions, I have asked Xilinx to submit patches such
> > as this one directly to the GCC/Binutils projects (assuming that
> > they have a current FSF Copyright Assignment), or to give me
> > explicit permission to do so on their behalf, as was the case when
> > I originally submitted the MicroBlaze port to these projects.  For
> > whatever reason, neither has occurred.
> 
> copyright.list shows assignments from Xilinx for GCC, binutils, GDB and 
> glibc, with no indication that they are not current, or of any restriction 
> on who at Xilinx can contribute changes.
> 
> Thus, I presume we simply need someone at Xilinx to approve the 
> contribution of this patch to GCC.  The last patch sent to gcc-patches by 
> someone @xilinx.com appears to have been 
> ; author and 
> other @xilinx.com people from that discussion CC:ed on this message.

Hi Joseph,

There's no problem from our side.
In fact, a version of this patch has already been posted to gcc-patches:
https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00657.html

I don't do any work on the toolchain anymore and don't have the setup to
run the testsuite. Ajit or Nagaraju are might be able to help resolve
any issues.

Cheers,
Edgar


> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

Re: [-fcompare-debug] var tracking options are not optimization options

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 12:49:54AM -0200, Alexandre Oliva wrote:
> On Jan  5, 2017, Jakub Jelinek  wrote:
> 
> > You've just changed the hash function and my mail was about the fact that
> > it is not enough.
> 
> Sorry, it wasn't clear 'enough for what'.  It's enough to fix the
> bug/symptom I had observed and intended to fix, but yes, there is
> another latent -fcompare-debug bug with a very different symptom that
> the patch did not even attempt to address (because I had not even
> realized we had that bug ;-)

Ok, let's do it incrementally then.  Your patch is ok for trunk, and we'll
work on the extra stuff later.

BTW, the ICF hash traversal is what I've been trying to partly solve in
PR78211, but already in the patch submission mentioned there is at least
another hash table traversal that still would need adjustments.

Jakub

Re: [PATCH][ARM] Backport - Avoid partial overlaps in DImode shifts *

[Kyrill Tkachov]

On 05/01/17 18:32, Wilco Dijkstra wrote:

With -fpu=neon DI mode shifts are expanded after reload.  DI mode registers can
either fully or partially overlap on both ARM and Thumb-2.  However the shift
expansion code can only deal with the full overlap case, and generates incorrect
code for partial overlaps.  The fix is to add new variants that support either
full overlap or no overlap.

Bootstrap & regress on arm-linux-gnueabihf OK on GCC6 branch.

OK for backport?


Ok as it fixes a wrong-code issue.
Thanks,
Kyrill


ChangeLog:
2017-01-05  Wilco Dijkstra  

 gcc/
PR target/78041
* config/arm/neon.md (ashldi3_neon): Add "r 0 i" and "&r r i" variants.
Remove partial overlap check for shift by 1.
(ashldi3_neon): Likewise.
 testsuite/
* gcc.target/arm/pr78041.c: New test.
--

diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 
879c07c13b6aa20c46828d08f5a4f413a5722eca..1d51c4045a1779fbd7927c94cdd6752b95cdabc7
 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -1045,12 +1045,12 @@
  )
  
  (define_insn_and_split "ashldi3_neon"

-  [(set (match_operand:DI 0 "s_register_operand" "= w, w,?&r,?r, ?w,w")
-   (ashift:DI (match_operand:DI 1 "s_register_operand" " 0w, w, 0r, r, 
0w,w")
-  (match_operand:SI 2 "general_operand""rUm, i,  r, 
i,rUm,i")))
-   (clobber (match_scratch:SI 3"= X, X,?&r, X,  
X,X"))
-   (clobber (match_scratch:SI 4"= X, X,?&r, X,  
X,X"))
-   (clobber (match_scratch:DI 5"=&w, X,  X, X, 
&w,X"))
+  [(set (match_operand:DI 0 "s_register_operand" "= w, w,?&r,?r,?&r, 
?w,w")
+   (ashift:DI (match_operand:DI 1 "s_register_operand" " 0w, w, 0r, 0,  r, 
0w,w")
+  (match_operand:SI 2 "general_operand""rUm, i,  r, i,  
i,rUm,i")))
+   (clobber (match_scratch:SI 3"= X, X,?&r, X,  
X,  X,X"))
+   (clobber (match_scratch:SI 4"= X, X,?&r, X,  
X,  X,X"))
+   (clobber (match_scratch:DI 5"=&w, X,  X, X,  X, 
&w,X"))
 (clobber (reg:CC_C CC_REGNUM))]
"TARGET_NEON"
"#"
@@ -1082,9 +1082,11 @@
}
  else
{
-   if (CONST_INT_P (operands[2]) && INTVAL (operands[2]) == 1
-   && (!reg_overlap_mentioned_p (operands[0], operands[1])
-   || REGNO (operands[0]) == REGNO (operands[1])))
+   /* The shift expanders support either full overlap or no overlap.  */
+   gcc_assert (!reg_overlap_mentioned_p (operands[0], operands[1])
+   || REGNO (operands[0]) == REGNO (operands[1]));
+
+   if (operands[2] == CONST1_RTX (SImode))
  /* This clobbers CC.  */
  emit_insn (gen_arm_ashldi3_1bit (operands[0], operands[1]));
else
@@ -1093,8 +1095,8 @@
}
  DONE;
}"
-  [(set_attr "arch" 
"neon_for_64bits,neon_for_64bits,*,*,avoid_neon_for_64bits,avoid_neon_for_64bits")
-   (set_attr "opt" "*,*,speed,speed,*,*")
+  [(set_attr "arch" 
"neon_for_64bits,neon_for_64bits,*,*,*,avoid_neon_for_64bits,avoid_neon_for_64bits")
+   (set_attr "opt" "*,*,speed,speed,speed,*,*")
 (set_attr "type" "multiple")]
  )
  
@@ -1143,12 +1145,12 @@

  ;; ashrdi3_neon
  ;; lshrdi3_neon
  (define_insn_and_split "di3_neon"
-  [(set (match_operand:DI 0 "s_register_operand"  "= w, 
w,?&r,?r,?w,?w")
-   (RSHIFTS:DI (match_operand:DI 1 "s_register_operand" " 0w, w, 0r, r,0w, 
w")
-   (match_operand:SI 2 "reg_or_int_operand" "  r, i,  r, i, r, 
i")))
-   (clobber (match_scratch:SI 3 "=2r, X, &r, 
X,2r, X"))
-   (clobber (match_scratch:SI 4 "= X, X, &r, X, 
X, X"))
-   (clobber (match_scratch:DI 5 "=&w, X,  X, 
X,&w, X"))
+  [(set (match_operand:DI 0 "s_register_operand"  "= w, 
w,?&r,?r,?&r,?w,?w")
+   (RSHIFTS:DI (match_operand:DI 1 "s_register_operand" " 0w, w, 0r, 0,  r,0w, 
w")
+   (match_operand:SI 2 "reg_or_int_operand" "  r, i,  r, i,  i, r, 
i")))
+   (clobber (match_scratch:SI 3 "=2r, X, &r, X, 
 X,2r, X"))
+   (clobber (match_scratch:SI 4 "= X, X, &r, X, 
 X, X, X"))
+   (clobber (match_scratch:DI 5 "=&w, X,  X, X, 
X,&w, X"))
 (clobber (reg:CC CC_REGNUM))]
"TARGET_NEON"
"#"
@@ -1184,9 +1186,11 @@
}
  else
{
-   if (CONST_INT_P (operands[2]) && INTVAL (operands[2]) == 1
-   && (!reg_overlap_mentioned_p (operands[0], operands[1])
-   || REGNO (operands[0]) == REGNO (operands[1])))
+   /* The shift expanders support either full overlap or no overlap.  */
+   gcc_assert (!reg_overlap_mentioned_p (operands[0], operands[1])
+   || REGNO (oper

Re: [-fcompare-debug] var tracking options are not optimization options

[Richard Biener]

On January 6, 2017 3:49:54 AM GMT+01:00, Alexandre Oliva  
wrote:
>On Jan  5, 2017, Jakub Jelinek  wrote:
>
>> You've just changed the hash function and my mail was about the fact
>that
>> it is not enough.
>
>Sorry, it wasn't clear 'enough for what'.  It's enough to fix the
>bug/symptom I had observed and intended to fix, but yes, there is
>another latent -fcompare-debug bug with a very different symptom that
>the patch did not even attempt to address (because I had not even
>realized we had that bug ;-)
>
>> With your patch, both functions
>> will hash the same (that is ok), but as ICF for functions that hash
>the same
>> also performs memcmp on the OPTIMIZATION_NODE content, they will
>compare
>> the same in one case (-g0) and not in the other one (-g) and so ICF
>will
>> merge them in one case and not in the other one.
>
>Whereas without the proposed patch, ICF will also merge them in one
>case
>and not in the other.  The patch does not change that, it just
>introduces a situation in which hashes that used to be different become
>the same, but still without a match for merging.
>
>> BTW, seems the above exact case ICEs actually.
>
>Both with and without the proposed patch, I suppose.
>
>Anyway, would you please file a bug report about this, and copy me?  I
>might be able to have a look into this one when I get a chance.
>
>> We need to deal not just with the iteration order, but also with
>equality
>> of functions, otherwise ICF will do something depending on -g vs.
>-g0.
>
>Agreed.  But IMHO that's two different, unrelated bugs.  Maybe more ;-)

But can we perhaps solve the iteration order issue by sorting the candidates 
after sth more stable then, like their DECL_UID?

Richard.

Re: [-fcompare-debug] var tracking options are not optimization options

[Martin Liška]

On 01/06/2017 10:46 AM, Jakub Jelinek wrote:
> On Fri, Jan 06, 2017 at 12:49:54AM -0200, Alexandre Oliva wrote:
>> On Jan  5, 2017, Jakub Jelinek  wrote:
>>
>>> You've just changed the hash function and my mail was about the fact that
>>> it is not enough.
>>
>> Sorry, it wasn't clear 'enough for what'.  It's enough to fix the
>> bug/symptom I had observed and intended to fix, but yes, there is
>> another latent -fcompare-debug bug with a very different symptom that
>> the patch did not even attempt to address (because I had not even
>> realized we had that bug ;-)
> 
> Ok, let's do it incrementally then.  Your patch is ok for trunk, and we'll
> work on the extra stuff later.
> 
> BTW, the ICF hash traversal is what I've been trying to partly solve in
> PR78211, but already in the patch submission mentioned there is at least
> another hash table traversal that still would need adjustments.
> 
>   Jakub
> 

Hi.

Sorry for bigger latency. I'm going to fix the traversal and I was also 
thinking about
PerFunction and Target optimization flags. Currently, one can have a pair of 
functions
(one having for instance -fvar-tracking, second w/o) and use -fcompare-debug.
This is covered by ICF as it compares function attributes and one function will 
have
__attribute__ ((optimize(("-fno-var-tracking". Second issue can happen with 
LTO,
where one compilation unit can have -fvar-tracking and another not. To be 
honest, I'm
unable to trigger divergence in ICF by adding GCC_COMPARE_DEBUG=1 to env 
variables.

Ideal solution (next stage1) would be to not compare any 'target' and 
'optimization'
attributes of a function. But rather compare just cl_optimization_node and 
cl_target_node
with special argument (as suggested by Jakub), that some PerFunction flags 
would be ignored
for comparison (all var_tracking_* can be put to this category). Which would 
work with -fcompare-debug.

Martin

Re: [-fcompare-debug] var tracking options are not optimization options

[Martin Liška]

On 01/06/2017 11:07 AM, Richard Biener wrote:
> On January 6, 2017 3:49:54 AM GMT+01:00, Alexandre Oliva  
> wrote:
>> On Jan  5, 2017, Jakub Jelinek  wrote:
>>
>>> You've just changed the hash function and my mail was about the fact
>> that
>>> it is not enough.
>>
>> Sorry, it wasn't clear 'enough for what'.  It's enough to fix the
>> bug/symptom I had observed and intended to fix, but yes, there is
>> another latent -fcompare-debug bug with a very different symptom that
>> the patch did not even attempt to address (because I had not even
>> realized we had that bug ;-)
>>
>>> With your patch, both functions
>>> will hash the same (that is ok), but as ICF for functions that hash
>> the same
>>> also performs memcmp on the OPTIMIZATION_NODE content, they will
>> compare
>>> the same in one case (-g0) and not in the other one (-g) and so ICF
>> will
>>> merge them in one case and not in the other one.
>>
>> Whereas without the proposed patch, ICF will also merge them in one
>> case
>> and not in the other.  The patch does not change that, it just
>> introduces a situation in which hashes that used to be different become
>> the same, but still without a match for merging.
>>
>>> BTW, seems the above exact case ICEs actually.
>>
>> Both with and without the proposed patch, I suppose.
>>
>> Anyway, would you please file a bug report about this, and copy me?  I
>> might be able to have a look into this one when I get a chance.
>>
>>> We need to deal not just with the iteration order, but also with
>> equality
>>> of functions, otherwise ICF will do something depending on -g vs.
>> -g0.
>>
>> Agreed.  But IMHO that's two different, unrelated bugs.  Maybe more ;-)
> 
> But can we perhaps solve the iteration order issue by sorting the candidates 
> after sth more stable then, like their DECL_UID?
> 
> Richard.
> 

Yes, I'm working on a patch for that.

M.

Re: [PATCH, gimplefe] passes.c: split out pass-skipping logic into subroutines

[Richard Biener]

On January 6, 2017 2:57:49 AM GMT+01:00, David Malcolm  
wrote:
>The GIMPLE frontend's pass-skipping logic in execute_one_pass is
>somewhat
>awkward.  This patch splits it out into two subroutines to simplify
>things.
>
>No functional change intended (and this may make it easier to
>update the logic so that it can be shared with the RTL frontend).
>
>Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
>
>OK for trunk?

OK.

Richard.

>gcc/ChangeLog:
>   * passes.c (execute_one_pass): Split out pass-skipping logic
>   into...
>   (determine_pass_name_match): ...this new function and...
>   (should_skip_pass_p): ...this new function.
>---
>gcc/passes.c | 97
>+++-
> 1 file changed, 63 insertions(+), 34 deletions(-)
>
>diff --git a/gcc/passes.c b/gcc/passes.c
>index 32d964b..31262ed 100644
>--- a/gcc/passes.c
>+++ b/gcc/passes.c
>@@ -2273,6 +2273,67 @@ override_gate_status (opt_pass *pass, tree func,
>bool gate_status)
>   return gate_status;
> }
> 
>+/* Determine if PASS_NAME matches CRITERION.
>+   Not a pure predicate, since it can update CRITERION, to support
>+   matching the Nth invocation of a pass.
>+   Subroutine of should_skip_pass_p.  */
>+
>+static bool
>+determine_pass_name_match (const char *pass_name, char *criterion)
>+{
>+  size_t namelen = strlen (pass_name);
>+  if (! strncmp (pass_name, criterion, namelen))
>+{
>+  /* The following supports starting with the Nth invocation
>+   of a pass (where N does not necessarily is equal to the
>+   dump file suffix).  */
>+  if (criterion[namelen] == '\0'
>+|| (criterion[namelen] == '1'
>+&& criterion[namelen + 1] == '\0'))
>+  return true;
>+  else
>+  {
>+if (criterion[namelen + 1] == '\0')
>+  --criterion[namelen];
>+return false;
>+  }
>+}
>+  else
>+return false;
>+}
>+
>+/* For skipping passes until "startwith" pass.
>+   Return true iff PASS should be skipped.
>+   Clear cfun->pass_startwith when encountering the "startwith" pass,
>+   so that all subsequent passes are run.  */
>+
>+static bool
>+should_skip_pass_p (opt_pass *pass)
>+{
>+  if (!cfun)
>+return false;
>+  if (!cfun->pass_startwith)
>+return false;
>+
>+  /* We can't skip the lowering phase yet -- ideally we'd
>+ drive that phase fully via properties.  */
>+  if (!(cfun->curr_properties & PROP_ssa))
>+return false;
>+
>+  if (determine_pass_name_match (pass->name, cfun->pass_startwith))
>+{
>+  cfun->pass_startwith = NULL;
>+  return false;
>+}
>+
>+  /* And also run any property provider.  */
>+  if (pass->properties_provided != 0)
>+return false;
>+
>+  /* If we get here, then we have a "startwith" that we haven't seen
>yet;
>+ skip the pass.  */
>+  return true;
>+}
> 
> /* Execute PASS. */
> 
>@@ -2313,40 +2374,8 @@ execute_one_pass (opt_pass *pass)
>   return false;
> }
> 
>-  /* For skipping passes until startwith pass */
>-  if (cfun
>-  && cfun->pass_startwith
>-  /* But we can't skip the lowering phase yet -- ideally we'd
>- drive that phase fully via properties.  */
>-  && (cfun->curr_properties & PROP_ssa))
>-{
>-  size_t namelen = strlen (pass->name);
>-  /* We have to at least start when we leave SSA.  */
>-  if (pass->properties_destroyed & PROP_ssa)
>-  cfun->pass_startwith = NULL;
>-  else if (! strncmp (pass->name, cfun->pass_startwith, namelen))
>-  {
>-/* The following supports starting with the Nth invocation
>-   of a pass (where N does not necessarily is equal to the
>-   dump file suffix).  */
>-if (cfun->pass_startwith[namelen] == '\0'
>-|| (cfun->pass_startwith[namelen] == '1'
>-&& cfun->pass_startwith[namelen + 1] == '\0'))
>-  cfun->pass_startwith = NULL;
>-else
>-  {
>-if (cfun->pass_startwith[namelen + 1] != '\0')
>-  return true;
>---cfun->pass_startwith[namelen];
>-return true;
>-  }
>-  }
>-  /* And also run any property provider.  */
>-  else if (pass->properties_provided != 0)
>-  ;
>-  else
>-  return true;
>-}
>+  if (should_skip_pass_p (pass))
>+return true;
> 
>   /* Pass execution event trigger: useful to identify passes being
>  executed.  */

Re: [bootstrap-O3,fortran] silence warning in simplify_transformation_to_array

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 09:34:46AM +0100, Christophe Lyon wrote:
> I makes my aarch64*linux* and arm*linux* builds for fail, because:
> gcc/fortran/simplify.c:613: error: #pragma GCC diagnostic not allowed
> inside functions
> gcc/fortran/simplify.c:620: error: #pragma GCC diagnostic not allowed
> inside functions
> gcc/fortran/simplify.c:624: error: #pragma GCC diagnostic not allowed
> inside functions
> 
> My host compiler is RHEL6's, that is 4.4.7
> 
> I'm not sure what current minimum gcc version is required to build gcc?

So, do we want something like (untested) following patch then, so that we
use the pragmas only on recent GCC versions?

2017-01-06  Jakub Jelinek  

* system.h (GCC_DIAGNOSTIC_PUSH_IGNORED, GCC_DIAGNOSTIC_POP,
GCC_DIAGNOSTIC_STRINGIFY): Define.

* simplify.c (simplify_transformation_to_array): Use
GCC_DIAGNOSTIC_PUSH_IGNORED and GCC_DIAGNOSTIC_POP instead of
#pragma GCC diagnostic {push,ignored,pop}.

--- gcc/system.h.jj 2017-01-01 12:45:36.0 +0100
+++ gcc/system.h2017-01-06 11:14:02.576406680 +0100
@@ -1140,6 +1140,18 @@ helper_const_non_const_cast (const char
 #define VALGRIND_FREELIKE_BLOCK(x,y)
 #endif
 
+/* Macros to temporarily ignore some warnings.  */
+#if GCC_VERSION >= 6000
+#define GCC_DIAGNOSTIC_STRINGIFY(x) #x
+#define GCC_DIAGNOSTIC_PUSH_IGNORED(x) \
+  _Pragma ("GCC diagnostic push") \
+  _Pragma (GCC_DIAGNOSTIC_STRINGIFY (GCC diagnostic ignored #x))
+#define GCC_DIAGNOSTIC_POP _Pragma ("GCC diagnostic pop")
+#else
+#define GCC_DIAGNOSTIC_PUSH_IGNORED(x)
+#define GCC_DIAGNOSTIC_POP
+#endif
+
 /* In LTO -fwhole-program build we still want to keep the debug functions 
available
for debugger.  Mark them as used to prevent removal.  */
 #if (GCC_VERSION > 4000)
--- gcc/fortran/simplify.c.jj   2017-01-06 09:23:31.0 +0100
+++ gcc/fortran/simplify.c  2017-01-06 11:15:01.003630017 +0100
@@ -610,18 +610,17 @@ simplify_transformation_to_array (gfc_ex
  n++;
  if (n < result->rank)
{
-#pragma GCC diagnostic push
  /* If the nested loop is unrolled GFC_MAX_DIMENSIONS
 times, we'd warn for the last iteration, because the
 array index will have already been incremented to the
 array sizes, and we can't tell that this must make
 the test against result->rank false, because ranks
 must not exceed GFC_MAX_DIMENSIONS.  */
-#pragma GCC diagnostic ignored "-Warray-bounds"
+ GCC_DIAGNOSTIC_PUSH_IGNORED (-Warray-bounds)
  count[n]++;
  base += sstride[n];
  dest += dstride[n];
-#pragma GCC diagnostic pop
+ GCC_DIAGNOSTIC_POP
}
  else
done = true;

Jakub

[Ada] Missing range check on 'Read result

[Arnaud Charlet]

This patch modifies the expansion of attribute 'Read to ensure that relevant
checks are properly installed on the return value obtained by calling the
related Read routine. This is done by means of a type conversion to the
target type.


-- Source --


--  types.ads

with Ada.Streams; use Ada.Streams;

package Types is
   type Int is new Integer;

   procedure Read_Int
 (Stream : not null access Root_Stream_Type'Class;
  Item   : out Int);

   procedure Write_Int
 (Stream : not null access Root_Stream_Type'Class;
  Item   : Int);

   for Int'Read  use Read_Int;
   for Int'Write use Write_Int;

   type Small_Int is new Int range -5 .. 5;

   type Pipe (Capacity : Stream_Element_Offset) is
 new Root_Stream_Type with private;

   overriding procedure Read
 (Stream : in out Pipe;
  Item   : out Stream_Element_Array;
  Last   : out Stream_Element_Offset);

   overriding procedure Write
 (Stream : in out Pipe;
  Item   : Stream_Element_Array);

private
   type Pipe (Capacity : Stream_Element_Offset) is
 new Root_Stream_Type with
   record
  Buffer : Stream_Element_Array (1 .. Capacity);
  Cursor : Stream_Element_Offset;
   end record;
end Types;

--  types.adb

package body Types is
   overriding procedure Read
 (Stream : in out Pipe;
  Item   : out Stream_Element_Array;
  Last   : out Stream_Element_Offset)
   is
   begin
  Item := Stream.Buffer (1 .. Stream.Cursor);
  Last := Stream.Cursor;
   end Read;

   procedure Read_Int
 (Stream : not null access Root_Stream_Type'Class;
  Item   : out Int)
   is
   begin
  Integer'Read (Stream, Integer (Item));
   end Read_Int;

   overriding procedure Write
 (Stream : in out Pipe;
  Item   : Stream_Element_Array)
   is
  Item_Length : constant Stream_Element_Offset := Item'Length;

   begin
  if Item_Length > Stream.Capacity then
 raise Storage_Error;
  end if;

  Stream.Buffer (1 .. Item_Length) := Item;
  Stream.Cursor := Item_Length;
   end Write;

   procedure Write_Int
 (Stream : not null access Root_Stream_Type'Class;
  Item   : Int)
   is
   begin
  Integer'Write (Stream, Integer (Item));
   end Write_Int;
end Types;

--  main.adb

with Types; use Types;

procedure Main is
   Small_Obj : Small_Int;
   Stream: aliased Pipe (16);

begin
   Int'Write (Stream'Access, 16);
   Small_Int'Read (Stream'Access, Small_Obj);
end Main;


-- Compilation and output --


$ gnatmake -q main.adb
$ ./main
raised CONSTRAINT_ERROR : main.adb:9 range check failed

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-06  Hristian Kirtchev  

* exp_attr.adb (Rewrite_Stream_Proc_Call): Use
an unchecked type conversion when performing a view conversion
to/from a private type. In all other cases use a regular type
conversion to ensure that any relevant checks are properly
installed.

Index: exp_attr.adb
===
--- exp_attr.adb(revision 244124)
+++ exp_attr.adb(working copy)
@@ -1568,9 +1568,10 @@
 
   procedure Rewrite_Stream_Proc_Call (Pname : Entity_Id) is
  Item   : constant Node_Id   := Next (First (Exprs));
+ Item_Typ   : constant Entity_Id := Etype (Item);
  Formal : constant Entity_Id := Next_Formal (First_Formal (Pname));
  Formal_Typ : constant Entity_Id := Etype (Formal);
- Is_Written : constant Boolean   := (Ekind (Formal) /= E_In_Parameter);
+ Is_Written : constant Boolean   := Ekind (Formal) /= E_In_Parameter;
 
   begin
  --  The expansion depends on Item, the second actual, which is
@@ -1583,7 +1584,7 @@
 
  if Nkind (Item) = N_Indexed_Component
and then Is_Packed (Base_Type (Etype (Prefix (Item
-   and then Base_Type (Etype (Item)) /= Base_Type (Formal_Typ)
+   and then Base_Type (Item_Typ) /= Base_Type (Formal_Typ)
and then Is_Written
  then
 declare
@@ -1595,23 +1596,22 @@
Decl :=
  Make_Object_Declaration (Loc,
Defining_Identifier => Temp,
-   Object_Definition=>
- New_Occurrence_Of (Formal_Typ, Loc));
+   Object_Definition   => New_Occurrence_Of (Formal_Typ, Loc));
Set_Etype (Temp, Formal_Typ);
 
Assn :=
  Make_Assignment_Statement (Loc,
-   Name => New_Copy_Tree (Item),
+   Name   => New_Copy_Tree (Item),
Expression =>
  Unchecked_Convert_To
-   (Etype (Item), New_Occurrence_Of (Temp, Loc)));
+   (Item_Typ, New_Occurrence_Of (Temp, Loc)));
 
Rewrite (Item, New_Occurrence_Of (Temp, Loc));
Insert_Ac

[Ada] Implicit Elaborate_All(P) in P

[Arnaud Charlet]

This patch fixes a bug where the compiler would add an implicit pragma
Elaborate_All(P) to the body of P itself, causing gnatbind to find a
spurious elaboration cycle.

The following test must build quietly.

gnatmake -q -f main.adb

with Ada.Finalization;
package Ctrl is
type T (Object : access Boolean := null) is
new Ada.Finalization.Limited_Controlled
with null record;
procedure Initialize (X : in out T);
end Ctrl;
package body Ctrl is
procedure Initialize (X : in out T) is
begin
   null;
end Initialize;
end;
generic
package G is
pragma Elaborate_Body;
end;
with Ctrl;
package body G is
X : Ctrl.T;
end;
package Parent is
procedure Require_Body;
end Parent;
with G;
with Parent;
package body Parent is
package Instantiation is new G;
procedure Require_Body is null;
end Parent;
with Parent;
procedure Main is
begin
null;
end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-06  Bob Duff  

* sem_elab.adb (Activate_Elaborate_All_Desirable): Don't add
Elaborate_All(P) to P itself. That could happen in obscure cases,
and always introduced a cycle (P body must be elaborated before
P body).
* lib-writ.ads: Comment clarification.
* ali-util.ads: Minor comment fix.
* ali.adb: Minor reformatting.

Index: lib-writ.ads
===
--- lib-writ.ads(revision 244124)
+++ lib-writ.ads(working copy)
@@ -649,8 +649,10 @@
--AD  Elaborate_All_Desirable set for this unit, which means that
--there is no Elaborate_All, but the analysis suggests that
--Program_Error may be raised if the Elaborate_All conditions
-   --cannot be satisfied. The binder will attempt to treat AD as
-   --EA if it can.
+   --cannot be satisfied. In dynamic elaboration mode, the binder
+   --will attempt to treat AD as EA if it can. In static
+   --elaboration mode, the binder will treat AD as EA, even if it
+   --introduces cycles.
 
--  The parameter source-name and lib-name are omitted for the case of a
--  generic unit compiled with earlier versions of GNAT which did not
Index: ali-util.ads
===
--- ali-util.ads(revision 244124)
+++ ali-util.ads(working copy)
@@ -24,7 +24,7 @@
 --
 
 --  This child unit provides utility data structures and procedures used
---  for manipulation of ALI data by the gnatbind and gnatmake.
+--  for manipulation of ALI data by gnatbind and gnatmake.
 
 package ALI.Util is
 
Index: sem_elab.adb
===
--- sem_elab.adb(revision 244124)
+++ sem_elab.adb(working copy)
@@ -446,6 +446,15 @@
  return;
   end if;
 
+  --  If an instance of a generic package contains a controlled object (so
+  --  we're calling Initialize at elaboration time), and the instance is in
+  --  a package body P that says "with P;", then we need to return without
+  --  adding "pragma Elaborate_All (P);" to P.
+
+  if U = Main_Unit_Entity then
+ return;
+  end if;
+
   Itm := First (CI);
   while Present (Itm) loop
  if Nkind (Itm) = N_With_Clause then
@@ -495,10 +504,8 @@
   end if;
 
   --  Here if we do not find with clause on spec or body. We just ignore
-  --  this case, it means that the elaboration involves some other unit
+  --  this case; it means that the elaboration involves some other unit
   --  than the unit being compiled, and will be caught elsewhere.
-
-  null;
end Activate_Elaborate_All_Desirable;
 
--
@@ -528,7 +535,7 @@
--  Generate a call to Error_Msg_NE with parameters Msg_D or Msg_S (for
--  dynamic or static elaboration model), N and Ent. Msg_D is a real
--  warning (output if Msg_D is non-null and Elab_Warnings is set),
-   --  Msg_S is an info message (output if Elab_Info_Messages is set.
+   --  Msg_S is an info message (output if Elab_Info_Messages is set).
 
   function Find_W_Scope return Entity_Id;
   --  Find top-level scope for called entity (not following renamings
Index: ali.adb
===
--- ali.adb (revision 244124)
+++ ali.adb (working copy)
@@ -2056,8 +2056,7 @@
 --  Store AD indication unless ignore required
 
 if not Ignore_ED then
-   Withs.Table (Withs.Last).Elab_All_Desirable :=
- True;
+   Withs.Table (Withs.Last).Elab_All_Desirable := True;
 end if;
 
  elsif Nextc = 'E' then

[Ada] Support for new socket options

[Arnaud Charlet]

Make Linux specific option SO_BUSY_POLL accessable as Busy_Polling
option. Also offer a generic API to set options that were not available
at compiler build time.

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-06  Thomas Quinot  

* s-oscons-tmplt.c, g-socket.adb, g-socket.ads, g-sothco.ads:
(GNAT.Socket): Add support for Busy_Polling and Generic_Option

Index: s-oscons-tmplt.c
===
--- s-oscons-tmplt.c(revision 244124)
+++ s-oscons-tmplt.c(working copy)
@@ -7,7 +7,7 @@
 --  --
 -- S p e c  --
 --  --
---  Copyright (C) 2000-2015, Free Software Foundation, Inc. --
+--  Copyright (C) 2000-2016, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -1264,6 +1264,11 @@
 #endif
 CND(SO_ERROR, "Get/clear error status")
 
+#ifndef SO_BUSY_POLL
+# define SO_BUSY_POLL -1
+#endif
+CND(SO_BUSY_POLL, "Busy polling")
+
 #ifndef IP_MULTICAST_IF
 # define IP_MULTICAST_IF -1
 #endif
Index: g-socket.adb
===
--- g-socket.adb(revision 244124)
+++ g-socket.adb(working copy)
@@ -50,8 +50,6 @@
 
package C renames Interfaces.C;
 
-   use type C.int;
-
ENOERROR : constant := 0;
 
Netdb_Buffer_Size : constant := SOSC.Need_Netdb_Buffer * 1024;
@@ -82,7 +80,7 @@
 (Non_Blocking_IO => SOSC.FIONBIO,
  N_Bytes_To_Read => SOSC.FIONREAD);
 
-   Options : constant array (Option_Name) of C.int :=
+   Options : constant array (Specific_Option_Name) of C.int :=
(Keep_Alive  => SOSC.SO_KEEPALIVE,
 Reuse_Address   => SOSC.SO_REUSEADDR,
 Broadcast   => SOSC.SO_BROADCAST,
@@ -98,7 +96,8 @@
 Multicast_Loop  => SOSC.IP_MULTICAST_LOOP,
 Receive_Packet_Info => SOSC.IP_PKTINFO,
 Send_Timeout=> SOSC.SO_SNDTIMEO,
-Receive_Timeout => SOSC.SO_RCVTIMEO);
+Receive_Timeout => SOSC.SO_RCVTIMEO,
+Busy_Polling=> SOSC.SO_BUSY_POLL);
--  ??? Note: for OpenSolaris, Receive_Packet_Info should be IP_RECVPKTINFO,
--  but for Linux compatibility this constant is the same as IP_PKTINFO.
 
@@ -1140,9 +1139,10 @@
---
 
function Get_Socket_Option
- (Socket : Socket_Type;
-  Level  : Level_Type := Socket_Level;
-  Name   : Option_Name) return Option_Type
+ (Socket  : Socket_Type;
+  Level   : Level_Type := Socket_Level;
+  Name: Option_Name;
+  Optname : Interfaces.C.int := -1) return Option_Type
is
   use SOSC;
   use type C.unsigned_char;
@@ -1155,8 +1155,19 @@
   Add : System.Address;
   Res : C.int;
   Opt : Option_Type (Name);
+  Onm : Interfaces.C.int;
 
begin
+  if Name in Specific_Option_Name then
+ Onm := Options (Name);
+
+  elsif Optname = -1 then
+ raise Socket_Error with "optname must be specified";
+
+  else
+ Onm := Optname;
+  end if;
+
   case Name is
  when Multicast_Loop  |
   Multicast_TTL   |
@@ -1164,14 +1175,16 @@
 Len := V1'Size / 8;
 Add := V1'Address;
 
- when Keep_Alive  |
-  Reuse_Address   |
-  Broadcast   |
-  No_Delay|
-  Send_Buffer |
-  Receive_Buffer  |
-  Multicast_If|
-  Error   =>
+ when Generic_Option |
+  Keep_Alive |
+  Reuse_Address  |
+  Broadcast  |
+  No_Delay   |
+  Send_Buffer|
+  Receive_Buffer |
+  Multicast_If   |
+  Error  |
+  Busy_Polling   =>
 Len := V4'Size / 8;
 Add := V4'Address;
 
@@ -1203,7 +1216,7 @@
 C_Getsockopt
   (C.int (Socket),
Levels (Level),
-   Options (Name),
+   Onm,
Add, Len'Access);
 
   if Res = Failure then
@@ -1211,12 +1224,19 @@
   end if;
 
   case Name is
- when Keep_Alive  |
-  Reuse_Address   |
-  Broadcast   |
-  No_Delay=>
+ when Generic_Option =>
+Opt.Optname := Onm;
+Opt.Optval  := V4;
+
+ when Keep_Alive|
+  Reuse_Address |
+  Broadcast |
+  No

[Ada] Missing finalization on function result

[Arnaud Charlet]

This patch updates the funalization mechanism to correctly recognize a
redefined unary operator which returns an interface class-wide type. Such
objects require finalization actions.


-- Source --


--  types.ads

with Ada.Finalization; use Ada.Finalization;

package Types is
   type One is interface;

   type Int_Access is access Integer;

   type Managed is new Controlled with record
  X : Int_Access;
   end record;

   overriding procedure Adjust   (M : in out Managed);
   overriding procedure Finalize (M : in out Managed);

   function Build (I : Integer) return Managed;

   type Two is new One with record
  M : Managed := Build (1);
   end record;
end Types;

--  types.adb

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Unchecked_Deallocation;

package body Types is
   procedure Free is new Ada.Unchecked_Deallocation (Integer, Int_Access);

   overriding procedure Adjust (M : in out Managed) is
  Old_Val : Integer;
  New_Val : Integer;
  Val_Ptr : Int_Access renames M.X;

   begin
  if Val_Ptr = null then
 Put_Line ("adj: null");

  else
 Old_Val := Val_Ptr.all;
 New_Val := Old_Val + 1;

 Put_Line ("adj:" & Old_Val'Img & " ->" & New_Val'Img);

 Val_Ptr := new Integer'(New_Val);
  end if;
   end Adjust;

   function Build (I : Integer) return Managed is
   begin
  return Managed'(Controlled with X => new Integer'(I));
   end Build;

   overriding procedure Finalize (M : in out Managed) is
  Val_Ptr : Int_Access renames M.X;

   begin
  if Val_Ptr = null then
 Put_Line ("fin: null");

  else
 Put_Line ("fin:" & Val_Ptr.all'Img);
 Free (Val_Ptr);
  end if;
   end Finalize;
end Types;

--  leak.adb

with Ada.Text_IO; use Ada.Text_IO;
with Types;   use Types;

procedure Leak is
   function Pass  (X : Two'Class) return One'Class is (X);
   function "not" (X : Two'Class) return One'Class is (X);

   Obj_1 : Two;

begin
   Obj_1.M := Build (1);
   Put_Line ("start");

   for I in 1 .. 3 loop
  Put_Line ("spart Pass");
  declare
 Obj_2 : One'Class := Pass (Obj_1);
  begin null; end;
  Put_Line ("end Pass");

  Put_Line ("start not");
  declare
 Obj_3 : One'Class := not Obj_1;
  begin null; end;
  Put_Line ("end not");
   end loop;

   Put_Line ("end");
end Leak;


-- Compilation and output --


$ gnatmake -q leak.adb -largs -lgmem
$ ./leak
$ gnatmem ./leak > leaks.txt
$ grep -c "Number of non freed allocations" leaks.txt
dj: 1 -> 2
fin: 1
adj: 2 -> 3
fin: 2
adj: 1 -> 2
fin: 1
fin: 3
adj: 2 -> 3
fin: 2
start
spart Pass
adj: 3 -> 4
adj: 4 -> 5
fin: 4
fin: 5
end Pass
start not
adj: 3 -> 4
adj: 4 -> 5
fin: 4
fin: 5
end not
spart Pass
adj: 3 -> 4
adj: 4 -> 5
fin: 4
fin: 5
end Pass
start not
adj: 3 -> 4
adj: 4 -> 5
fin: 4
fin: 5
end not
spart Pass
adj: 3 -> 4
adj: 4 -> 5
fin: 4
fin: 5
end Pass
start not
adj: 3 -> 4
adj: 4 -> 5
fin: 4
fin: 5
end not
end
fin: 3
0

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-06  Hristian Kirtchev  

* exp_util.adb (Is_Controlled_Function_Call):
Reimplemented. Consider any node which has an entity as the
function call may appear in various ways.

Index: exp_util.adb
===
--- exp_util.adb(revision 244124)
+++ exp_util.adb(working copy)
@@ -4912,35 +4912,28 @@
  --Obj.Func (Formal => Actual) N_Function_Call, whose Name is an
  --N_Selected_Component
 
- case Nkind (Expr) is
-when N_Function_Call =>
+ loop
+if Nkind (Expr) = N_Function_Call then
Expr := Name (Expr);
 
-   --  Check for "Obj.Func (Formal => Actual)" case
-
-   if Nkind (Expr) = N_Selected_Component then
-  Expr := Selector_Name (Expr);
-   end if;
-
 --  "Obj.Func (Actual)" case
 
-when N_Indexed_Component =>
+elsif Nkind (Expr) = N_Indexed_Component then
Expr := Prefix (Expr);
 
-   if Nkind (Expr) = N_Selected_Component then
-  Expr := Selector_Name (Expr);
-   end if;
+--  "Obj.Func" or "Obj.Func (Formal => Actual) case
 
---  "Obj.Func" case
-
-when N_Selected_Component =>
+elsif Nkind (Expr) = N_Selected_Component then
Expr := Selector_Name (Expr);
 
-when others => null;
- end case;
+else
+   exit;
+end if;
+ end loop;
 
  return
-   Nkind_In (Expr, N_Expanded_Name, N_Identifier)
+   Nkind (Expr) in N_Has_Entity
+ and then Present (Entity (Expr))
  and then Ekind (Entity (Expr)) = E_Function
  and then Needs_Finalization (Etype (

[Ada] Max_Queue_Length aspect for protected entries

[Arnaud Charlet]

This patch implements the semantics of aspect/pragma Max_Queue_Length
which restricts the entry queue length for protected entries by allowing
the aspect and pragma Max_Queue_Length to appear directly after protected
entries followed by a single argument -- a positive integer.

To achieve the runtime support all entry queue maximums are collected into
an array of natural integers (zero denoting no maximum specified) which then
gets passed to Initialize_Protection_Entry or Initialize_Protection_Entries
in System.Tasking.Protected_Objects.Single_Entry or
System.Tasking.Protected_Objects.Entries respectivly.


-- Source --


--  pass.ads

with System;
package Pass is

   SOMETHING : constant Integer := 5;
   Variable : Boolean := False;

   protected type Protected_Example is

  entry A (Item : Integer)
 with Max_Queue_Length => 2;--  OK

  entry B (Item : Integer);
  pragma Max_Queue_Length (SOMETHING);  --  OK

  entry C (Item : Integer); --  OK

  entry D (Item : Integer)
 with Max_Queue_Length => 4;--  OK

  entry D (Item : Integer; Item_B : Integer)
 with Max_Queue_Length => Float'Digits; --  OK

  entry E (Item : Integer);
  pragma Max_Queue_Length (SOMETHING * 2);  --  OK

  entry E (Item : Integer; Item_B : Integer);
  pragma Max_Queue_Length (11); --  OK

  entry F (Item : Integer; Item_B : Integer);
  pragma Pre (Variable = True);
  pragma Max_Queue_Length (11); --  OK

  entry G (Item : Integer; Item_B : Integer)
 with Pre => (Variable = True),
  Max_Queue_Length => 11;   --  OK

   private
  Data : Boolean := True;
   end Protected_Example;

   Prot_Ex  : Protected_Example;

end Pass;

--  fail.ads

package Fail is

   --  Not near entry

   pragma Max_Queue_Length (40);--  ERROR

   --  Task type

   task type Task_Example is

  entry Insert (Item : in Integer)
 with Max_Queue_Length => 10;   --  ERROR

  -- Entry family in task type

  entry A (Positive) (Item : in Integer)
 with Max_Queue_Length => 10;   --  ERROR

   end Task_Example;

   Task_Ex : Task_Example;

   --  Aspect applied to protected type

   protected type Protected_Failure_0
  with Max_Queue_Length => 50 is--  ERROR

  entry A (Item : Integer);
   private
  Data : Integer := 0;
   end Protected_Failure_0;

   Protected_Failure_0_Ex : Protected_Failure_0;

   protected type Protected_Failure is
  pragma Max_Queue_Length (10); --  ERROR

  --  Duplicates

  entry A (Item : Integer)
 with Max_Queue_Length => 10;   --  OK
  pragma Max_Queue_Length (4);  --  ERROR

  entry B (Item : Integer);
  pragma Max_Queue_Length (40); --  OK
  pragma Max_Queue_Length (4);  --  ERROR

  entry C (Item : Integer)
 with Max_Queue_Length => 10,   --  OK
  Max_Queue_Length => 40;   --  ERROR

  -- Duplicates with the same value

  entry AA (Item : Integer)
 with Max_Queue_Length => 10;   --  OK
  pragma Max_Queue_Length (10); --  ERROR

  entry BB (Item : Integer);
  pragma Max_Queue_Length (40); --  OK
  pragma Max_Queue_Length (40); --  ERROR

  entry CC (Item : Integer)
 with Max_Queue_Length => 10,   --  OK
  Max_Queue_Length => 10;   --  ERROR

  --  On subprogram

  procedure D (Item : Integer)
 with Max_Queue_Length => 10;   --  ERROR

  procedure E (Item : Integer);
  pragma Max_Queue_Length (4);  --  ERROR

  function F (Item : Integer) return Integer
 with Max_Queue_Length => 10;   --  ERROR

  function G (Item : Integer) return Integer;
  pragma Max_Queue_Length (4);  --  ERROR

  --  Bad parameters

  entry H (Item : Integer)
 with Max_Queue_Length => 0;--  ERROR

  entry I (Item : Integer)
 with Max_Queue_Length => -1;   --  ERROR

  entry J (Item : Integer)
 with Max_Queue_Length => 16#____#; --  ERROR

  entry K (Item : Integer)
 with Max_Queue_Length => False;--  ERROR

  entry L (Item : Integer)
 with Max_Queue_Length => "JUNK";   --  ERROR

  entry M (Item : Integer)
 with Max_Queue_Length => 1.0; 

Re: [PATCH] PR78255: Make postreload aware of NO_FUNCTION_CSE

[Andre Vieira (lists)]

On 09/12/16 16:31, Bernd Schmidt wrote:
> On 12/09/2016 05:16 PM, Andre Vieira (lists) wrote:
> 
>> Regardless, 'reload_cse_simplify' would never perform the opposite
>> transformation.  It checks whether it can replace anything within the
>> first argument INSN, with the second argument TESTREG. As the name
>> implies this will always be a register. I double checked, the function
>> is only called in 'reload_cse_regs' and 'testreg' is created using
>> 'gen_rtx_REG'.
> 
> Ok, let's go ahead with it.
> 
> 
> Bernd
> 
Hello,

Is it OK to backport this (including the testcase fix) to gcc-6-branch?

Patches apply cleanly and full bootstrap and regression tests for
aarch64- and arm-none-linux-gnueabihf. Regression tested for arm-none-eabi.

Cheers,
Andre

[Ada] Create new attribute Finalization_Size for header of control objects

[Arnaud Charlet]

This patch creates a new attribute Finalization_Size for all objects. Its
result is an integer which represents the internal header size (including
padding) required by the object's type to store the additional data used
during finalization.


-- Source --


--  fail.ads

with Ada.Text_IO;
package Fail is
   type T is new Integer;
   package Integer_IO is new Ada.Text_IO.Integer_IO (T);
   Error_1 : Integer := 5'Finalization_Size;  --  ERROR
   Error_2 : Integer := (5 + 31)'Finalization_Size;   --  ERROR
   Error_3 : Integer := Integer_IO'Finalization_Size; --  ERROR
end Fail;

--  fail_second_pass.ads

package Fail_Second_Pass is
  type T2 is new Integer;
  Error : Integer := T2'Finalization_Size; --  ERROR
end Fail_Second_Pass;

--  pass.adb

with Ada.Finalization; use Ada.Finalization;
with Simple_Storage_Pools; use Simple_Storage_Pools;
with Ada.Text_IO;  use Ada.Text_IO;
procedure Pass is
   type Parent is tagged null record;

   type Non_Ctrl_Child is new Parent with record
  Comp : Integer;
   end record;

   type Ctrl is new Controlled with null record;

   type Ctrl_Child is new Parent with record
  Comp : Ctrl;
   end record;

   type Grand_Child is new Ctrl_Child with null record;

   type Limited_Child is new Limited_Controlled with null record;

   type Array_Child is array (1..50) of Ctrl_Child;

   type Unconst_Array_Child is array (Integer range <>) of Ctrl_Child;

   protected type Prot_Type is
  entry Test;
   private
  Internal : Integer := 0;
   end Prot_Type;

   task type Task_Type is
  entry Test;
   end Task_Type;

   protected body Prot_Type is
 entry Test when True is begin null; end;
   end Prot_Type;

   task body Task_Type is
   begin
  accept Test do null; end Test;
   end Task_Type;

   function Make_Any_Parent
 (Is_Controlled : Boolean) return Parent'Class
   is
   begin
  if Is_Controlled then
 return Result : Ctrl_Child;
  else
 return Result : Non_Ctrl_Child;
  end if;
   end Make_Any_Parent;

   procedure Test (Id : String; Got : Integer; Expect : Integer) is
   begin
 if Expect /= Got then
Put_Line ("ERROR For " & Id & ", expected value " & Expect'Img &
  " does not match the recieved value " & Got'Img);
 end if;
   end Test;

   P  : Parent;
   CC : Ctrl_Child;
   NCC: Non_Ctrl_Child;
   Grand_Child_Inst   : Grand_Child;
   Array_Child_Inst   : Array_Child;
   Pool_Inst  : Simple_Pool;
   Unconst_Array_Inst : Unconst_Array_Child (1..100);
   Prot_Type_Inst : Prot_Type;
   Task_Type_Inst : Task_Type;
   Limited_Child_Inst : Limited_Child;
   F_Size : Integer := CC'Finalization_Size;

begin
   Test ("CC vs Controlled", --  OK
   Make_Any_Parent (True)'Finalization_Size,
   CC'Finalization_Size);  
   Test ("NCC vs Non-Controlled",--  OK
   Make_Any_Parent (False)'Finalization_Size, NCC'Finalization_Size);
   Test ("Non-Controlled parent", P'Finalization_Size, 0);   --  OK
   Test ("Task", Task_Type_Inst'Finalization_Size, 0);   --  OK
   Test ("Grand child", Grand_Child_Inst'Finalization_Size, F_Size); --  OK
   Test ("Array child", Array_Child_Inst'Finalization_Size, F_Size); --  OK
   Test ("Pool inst", Pool_Inst'Finalization_Size, F_Size);  --  OK
   Test ("Uconst array", Unconst_Array_Inst'Finalization_Size, F_Size);  --  OK
   Test ("Protected type", Prot_Type_Inst'Finalization_Size, F_Size);--  OK
   Test ("Limited child", Limited_Child_Inst'Finalization_Size, F_Size); --  OK
   Task_Type_Inst.Test;
end Pass;


-- Compilation and output --


$ gcc -c fail.ads
$ gcc -c fail_second_pass.ads
$ gnatmake -gnatws -q pass.adb
$ pass
fail.ads:5:26: prefix of attribute must be a name
fail.ads:5:26: qualify expression to turn it into a name
fail.ads:6:33: prefix of attribute must be a name
fail.ads:6:33: qualify expression to turn it into a name
fail_second_pass.ads:3:22: invalid use of subtype mark in expression or call

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-06  Justin Squirek  

* exp_attr.adb (Expand_N_Attribute_Reference): Add entry for
expansion of Finalization_Size attribute.
* sem_attr.adb (Analyze_Attribute): Add entry to check the
semantics of Finalization_Size.
(Eval_Attribute): Add null entry for Finalization_Size.
* sem_attr.ads: Add Finalization_Size to the implementation
dependent attribute list.
* snames.ads-tmpl: Add name entry for Finalization_Size attribute.

Index: exp_attr.adb
===
--- exp_attr.adb(revision 244125)
+++ exp_attr.adb(working cop

[Ada] Spurious error on case statement with conversion and static predicate

[Arnaud Charlet]

This patch fixes a spurious error on a case statement whose expression is a
type conversion of a variable whose initial value is known, and whose type
has a static predicate.

Executing:

   gnatmake -q static_predicate_example
   static_predicate_example
   gnatmake -q -f -gnata static_predicate_example
   static_predicate_example

must yield:

   woof
   woof
   woof
   woof

---
with Ada.Text_Io;

procedure Static_Predicate_Example is

  type Animal_Type is (Bear, Cat, Dog, Horse, Wolf);

  subtype Pet_Type is Animal_Type with Static_Predicate =>
(case Pet_Type is
   when Cat | Dog | Horse => True,
   when Bear | Wolf   => False);

My_Animal   : Animal_Type := Dog;
My_Animal_Converted : Pet_Type:= Pet_Type (My_Animal);
begin
  if My_Animal in Pet_Type then
case Pet_Type (My_Animal) is
  when Cat   => Ada.Text_Io.Put_Line ("meow");
  when Dog   => Ada.Text_Io.Put_Line ("woof");
  when Horse => Ada.Text_Io.Put_Line ("eeehehe");
end case;
  end if;

  case My_Animal_Converted is
when Cat   => Ada.Text_Io.Put_Line ("meow");
when Dog   => Ada.Text_Io.Put_Line ("woof");
when Horse => Ada.Text_Io.Put_Line ("eeehehe");
  end case;
end Static_Predicate_Example;

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-06  Ed Schonberg  

* sem_eval.adb (Check_Expression_Against_Static_Predicate):
If expression is compile-time known and obeys a static predicate
it must be labelled as static, to prevent spurious warnings and
run-time errors, e.g. in case statements. This is relevant when
the expression is the result of constant-folding a type conversion
whose expression is a variable with a known static value.

Index: sem_eval.adb
===
--- sem_eval.adb(revision 244124)
+++ sem_eval.adb(working copy)
@@ -347,7 +347,11 @@
 
   --  Here we have a static predicate (note that it could have arisen from
   --  an explicitly specified Dynamic_Predicate whose expression met the
-  --  rules for being predicate-static).
+  --  rules for being predicate-static). If the expression is known at
+  --  compile time and obeys the predicate, then it is static and must be
+  --  labeled as such, which matters e.g. for case statements. The original
+  --  expression may be a type conversion of a variable with a known value,
+  --  which might otherwise not be marked static.
 
   --  Case of real static predicate
 
@@ -356,6 +360,7 @@
   (Val => Make_Real_Literal (Sloc (Expr), Expr_Value_R (Expr)),
Typ => Typ)
  then
+Set_Is_Static_Expression (Expr);
 return;
  end if;
 
@@ -365,6 +370,7 @@
  if Real_Or_String_Static_Predicate_Matches
   (Val => Expr_Value_S (Expr), Typ => Typ)
  then
+Set_Is_Static_Expression (Expr);
 return;
  end if;
 
@@ -376,6 +382,7 @@
  --  If static predicate matches, nothing to do
 
  if Choices_Match (Expr, Static_Discrete_Predicate (Typ)) = Match then
+Set_Is_Static_Expression (Expr);
 return;
  end if;
   end if;

[Ping~][AArch64] Add commandline support for -march=armv8.3-a

[Jiong Wang]

On 11/11/16 18:22, Jiong Wang wrote:

This patch add command line support for ARMv8.3-A through new architecture:

   -march=armv8.3-a

ARMv8.3-A implies all default features of ARMv8.2-A and meanwhile it includes
the new pointer authentication extension.


gcc/
2016-11-08  Jiong Wang

 * config/aarch64/aarch64-arches.def: New entry for "armv8.3-a".
 * config/aarch64/aarch64.h (AARCH64_FL_PAUTH, AARCH64_FL_V8_3,
 AARCH64_FL_FOR_ARCH8_3, AARCH64_ISA_PAUTH, AARCH64_ISA_V8_3,
 TARGET_PAUTH, TARGET_ARMV8_3): New.
 * doc/invoke.texi (AArch64 Options): Document "armv8.3-a".


Ping ~

As pointer authentication extension is defined to be mandatory extension on
ARMv8.3-A and is not optional, I adjusted the patch slightly.

This also let GCC treating pointer authentication extension in consistent way
with Binutils.

OK for trunk?

gcc/
2017-01-06  Jiong Wang  

* config/aarch64/aarch64-arches.def: New entry for "armv8.3-a".
* config/aarch64/aarch64.h (AARCH64_FL_V8_3, AARCH64_FL_FOR_ARCH8_3,
AARCH64_ISA_V8_3, TARGET_ARMV8_3): New.
* doc/invoke.texi (AArch64 Options): Document "armv8.3-a".


diff --git a/gcc/config/aarch64/aarch64-arches.def b/gcc/config/aarch64/aarch64-arches.def
index 830a7cf545532c050847a8c915d21bef12152388..ce6f73b3e5853b3d40e07545b9581298c768edca 100644
--- a/gcc/config/aarch64/aarch64-arches.def
+++ b/gcc/config/aarch64/aarch64-arches.def
@@ -33,5 +33,6 @@
 AARCH64_ARCH("armv8-a",	  generic,	 8A,	8,  AARCH64_FL_FOR_ARCH8)
 AARCH64_ARCH("armv8.1-a", generic,	 8_1A,	8,  AARCH64_FL_FOR_ARCH8_1)
 AARCH64_ARCH("armv8.2-a", generic,	 8_2A,	8,  AARCH64_FL_FOR_ARCH8_2)
+AARCH64_ARCH("armv8.3-a", generic,	 8_3A,	8,  AARCH64_FL_FOR_ARCH8_3)
 
 #undef AARCH64_ARCH
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 584ff5c43afcd1a7918019b09165371bb88bfda1..51916c95a736ade697a823f15d483336651ac99a 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -138,6 +138,8 @@ extern unsigned aarch64_architecture_version;
 /* ARMv8.2-A architecture extensions.  */
 #define AARCH64_FL_V8_2	  (1 << 8)  /* Has ARMv8.2-A features.  */
 #define AARCH64_FL_F16	  (1 << 9)  /* Has ARMv8.2-A FP16 extensions.  */
+/* ARMv8.3-A architecture extensions.  */
+#define AARCH64_FL_V8_3	  (1 << 10)  /* Has ARMv8.3-A features.  */
 
 /* Has FP and SIMD.  */
 #define AARCH64_FL_FPSIMD (AARCH64_FL_FP | AARCH64_FL_SIMD)
@@ -151,6 +153,8 @@ extern unsigned aarch64_architecture_version;
   (AARCH64_FL_FOR_ARCH8 | AARCH64_FL_LSE | AARCH64_FL_CRC | AARCH64_FL_V8_1)
 #define AARCH64_FL_FOR_ARCH8_2			\
   (AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_V8_2)
+#define AARCH64_FL_FOR_ARCH8_3			\
+  (AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_V8_3)
 
 /* Macros to test ISA flags.  */
 
@@ -162,6 +166,7 @@ extern unsigned aarch64_architecture_version;
 #define AARCH64_ISA_RDMA	   (aarch64_isa_flags & AARCH64_FL_V8_1)
 #define AARCH64_ISA_V8_2	   (aarch64_isa_flags & AARCH64_FL_V8_2)
 #define AARCH64_ISA_F16		   (aarch64_isa_flags & AARCH64_FL_F16)
+#define AARCH64_ISA_V8_3	   (aarch64_isa_flags & AARCH64_FL_V8_3)
 
 /* Crypto is an optional extension to AdvSIMD.  */
 #define TARGET_CRYPTO (TARGET_SIMD && AARCH64_ISA_CRYPTO)
@@ -176,6 +181,9 @@ extern unsigned aarch64_architecture_version;
 #define TARGET_FP_F16INST (TARGET_FLOAT && AARCH64_ISA_F16)
 #define TARGET_SIMD_F16INST (TARGET_SIMD && AARCH64_ISA_F16)
 
+/* ARMv8.3-A features.  */
+#define TARGET_ARMV8_3	(AARCH64_ISA_V8_3)
+
 /* Make sure this is always defined so we don't have to check for ifdefs
but rather use normal ifs.  */
 #ifndef TARGET_FIX_ERR_A53_835769_DEFAULT
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8e2f46617b8e44ccf16941c31029ab5625322867..791718831d7089c44dfadb137f5e93caa9cd05f0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -13874,7 +13874,10 @@ more feature modifiers.  This option has the form
 @option{-march=@var{arch}@r{@{}+@r{[}no@r{]}@var{feature}@r{@}*}}.
 
 The permissible values for @var{arch} are @samp{armv8-a},
-@samp{armv8.1-a}, @samp{armv8.2-a} or @var{native}.
+@samp{armv8.1-a}, @samp{armv8.2-a}, @samp{armv8.3-a} or @var{native}.
+
+The value @samp{armv8.3-a} implies @samp{armv8.2-a} and enables compiler
+support for the ARMv8.3-A architecture extensions.
 
 The value @samp{armv8.2-a} implies @samp{armv8.1-a} and enables compiler
 support for the ARMv8.2-A architecture extensions.

Re: [bootstrap-O3,fortran] silence warning in simplify_transformation_to_array

[Christophe Lyon]

On 6 January 2017 at 11:21, Jakub Jelinek  wrote:
> On Fri, Jan 06, 2017 at 09:34:46AM +0100, Christophe Lyon wrote:
>> I makes my aarch64*linux* and arm*linux* builds for fail, because:
>> gcc/fortran/simplify.c:613: error: #pragma GCC diagnostic not allowed
>> inside functions
>> gcc/fortran/simplify.c:620: error: #pragma GCC diagnostic not allowed
>> inside functions
>> gcc/fortran/simplify.c:624: error: #pragma GCC diagnostic not allowed
>> inside functions
>>
>> My host compiler is RHEL6's, that is 4.4.7
>>
>> I'm not sure what current minimum gcc version is required to build gcc?
>
> So, do we want something like (untested) following patch then, so that we
> use the pragmas only on recent GCC versions?
>
I would say so, RHEL6 is not that old, is it?
I think we want to be able to build GCC on reasonably old machines.

Christophe

> 2017-01-06  Jakub Jelinek  
>
> * system.h (GCC_DIAGNOSTIC_PUSH_IGNORED, GCC_DIAGNOSTIC_POP,
> GCC_DIAGNOSTIC_STRINGIFY): Define.
>
> * simplify.c (simplify_transformation_to_array): Use
> GCC_DIAGNOSTIC_PUSH_IGNORED and GCC_DIAGNOSTIC_POP instead of
> #pragma GCC diagnostic {push,ignored,pop}.
>
> --- gcc/system.h.jj 2017-01-01 12:45:36.0 +0100
> +++ gcc/system.h2017-01-06 11:14:02.576406680 +0100
> @@ -1140,6 +1140,18 @@ helper_const_non_const_cast (const char
>  #define VALGRIND_FREELIKE_BLOCK(x,y)
>  #endif
>
> +/* Macros to temporarily ignore some warnings.  */
> +#if GCC_VERSION >= 6000
> +#define GCC_DIAGNOSTIC_STRINGIFY(x) #x
> +#define GCC_DIAGNOSTIC_PUSH_IGNORED(x) \
> +  _Pragma ("GCC diagnostic push") \
> +  _Pragma (GCC_DIAGNOSTIC_STRINGIFY (GCC diagnostic ignored #x))
> +#define GCC_DIAGNOSTIC_POP _Pragma ("GCC diagnostic pop")
> +#else
> +#define GCC_DIAGNOSTIC_PUSH_IGNORED(x)
> +#define GCC_DIAGNOSTIC_POP
> +#endif
> +
>  /* In LTO -fwhole-program build we still want to keep the debug functions 
> available
> for debugger.  Mark them as used to prevent removal.  */
>  #if (GCC_VERSION > 4000)
> --- gcc/fortran/simplify.c.jj   2017-01-06 09:23:31.0 +0100
> +++ gcc/fortran/simplify.c  2017-01-06 11:15:01.003630017 +0100
> @@ -610,18 +610,17 @@ simplify_transformation_to_array (gfc_ex
>   n++;
>   if (n < result->rank)
> {
> -#pragma GCC diagnostic push
>   /* If the nested loop is unrolled GFC_MAX_DIMENSIONS
>  times, we'd warn for the last iteration, because the
>  array index will have already been incremented to the
>  array sizes, and we can't tell that this must make
>  the test against result->rank false, because ranks
>  must not exceed GFC_MAX_DIMENSIONS.  */
> -#pragma GCC diagnostic ignored "-Warray-bounds"
> + GCC_DIAGNOSTIC_PUSH_IGNORED (-Warray-bounds)
>   count[n]++;
>   base += sstride[n];
>   dest += dstride[n];
> -#pragma GCC diagnostic pop
> + GCC_DIAGNOSTIC_POP
> }
>   else
> done = true;
>
> Jakub

Re: [bootstrap-O3,fortran] silence warning in simplify_transformation_to_array

[Richard Biener]

On January 6, 2017 11:21:44 AM GMT+01:00, Jakub Jelinek  
wrote:
>On Fri, Jan 06, 2017 at 09:34:46AM +0100, Christophe Lyon wrote:
>> I makes my aarch64*linux* and arm*linux* builds for fail, because:
>> gcc/fortran/simplify.c:613: error: #pragma GCC diagnostic not allowed
>> inside functions
>> gcc/fortran/simplify.c:620: error: #pragma GCC diagnostic not allowed
>> inside functions
>> gcc/fortran/simplify.c:624: error: #pragma GCC diagnostic not allowed
>> inside functions
>> 
>> My host compiler is RHEL6's, that is 4.4.7
>> 
>> I'm not sure what current minimum gcc version is required to build
>gcc?
>
>So, do we want something like (untested) following patch then, so that
>we
>use the pragmas only on recent GCC versions?

Works for me.

Richard.

>2017-01-06  Jakub Jelinek  
>
>   * system.h (GCC_DIAGNOSTIC_PUSH_IGNORED, GCC_DIAGNOSTIC_POP,
>   GCC_DIAGNOSTIC_STRINGIFY): Define.
>
>   * simplify.c (simplify_transformation_to_array): Use
>   GCC_DIAGNOSTIC_PUSH_IGNORED and GCC_DIAGNOSTIC_POP instead of
>   #pragma GCC diagnostic {push,ignored,pop}.
>
>--- gcc/system.h.jj2017-01-01 12:45:36.0 +0100
>+++ gcc/system.h   2017-01-06 11:14:02.576406680 +0100
>@@ -1140,6 +1140,18 @@ helper_const_non_const_cast (const char
> #define VALGRIND_FREELIKE_BLOCK(x,y)
> #endif
> 
>+/* Macros to temporarily ignore some warnings.  */
>+#if GCC_VERSION >= 6000
>+#define GCC_DIAGNOSTIC_STRINGIFY(x) #x
>+#define GCC_DIAGNOSTIC_PUSH_IGNORED(x) \
>+  _Pragma ("GCC diagnostic push") \
>+  _Pragma (GCC_DIAGNOSTIC_STRINGIFY (GCC diagnostic ignored #x))
>+#define GCC_DIAGNOSTIC_POP _Pragma ("GCC diagnostic pop")
>+#else
>+#define GCC_DIAGNOSTIC_PUSH_IGNORED(x)
>+#define GCC_DIAGNOSTIC_POP
>+#endif
>+
>/* In LTO -fwhole-program build we still want to keep the debug
>functions available
>for debugger.  Mark them as used to prevent removal.  */
> #if (GCC_VERSION > 4000)
>--- gcc/fortran/simplify.c.jj  2017-01-06 09:23:31.0 +0100
>+++ gcc/fortran/simplify.c 2017-01-06 11:15:01.003630017 +0100
>@@ -610,18 +610,17 @@ simplify_transformation_to_array (gfc_ex
> n++;
> if (n < result->rank)
>   {
>-#pragma GCC diagnostic push
> /* If the nested loop is unrolled GFC_MAX_DIMENSIONS
>times, we'd warn for the last iteration, because the
>array index will have already been incremented to the
>array sizes, and we can't tell that this must make
>the test against result->rank false, because ranks
>must not exceed GFC_MAX_DIMENSIONS.  */
>-#pragma GCC diagnostic ignored "-Warray-bounds"
>+GCC_DIAGNOSTIC_PUSH_IGNORED (-Warray-bounds)
> count[n]++;
> base += sstride[n];
> dest += dstride[n];
>-#pragma GCC diagnostic pop
>+GCC_DIAGNOSTIC_POP
>   }
> else
>   done = true;
>
>   Jakub

[1/5][AArch64] Return address protection on AArch64

[Jiong Wang]

On 11/11/16 18:22, Jiong Wang wrote:

As described in the cover letter, this patch implements return address signing
for AArch64, it's controlled by the new option:

   -msign-return-address=[none | non-leaf | all]

"none" means don't do return address signing at all on any function.  "non-leaf"
means only sign non-leaf function.  "all" means sign all functions.  Return
address signing is currently disabled on ILP32.  I haven't tested it.

The instructions added in the architecture are of 2 kinds.

* In the NOP instruction space, which allows binaries to run without any traps
on older versions of the architecture. This doesn't give any additional
protection on older hardware but allows for the same binary to be used on
earlier versions of the architecture and newer versions of the architecture.

* New instructions that are only valid for v8.3 and will trap if used on earlier
versions of the architecture.

At default, once return address signing is enabled, it will only generates NOP
instruction.

While if -march=armv8.3-a specified, GCC will try to use the most efficient
pointer authentication instruction as it can.

The architecture has 2 user invisible system keys for signing and creating
signed addresses as part of these instructions. For some use case, the user
might want to use difference key for different functions.  The new option
"-msign-return-address-key=key_name" let GCC select the key used for return
address signing.  Permissible values are "a_key" for A key and "b_key" for B
key, and this option are supported by function target attribute and LTO will
hopefully just work.



gcc/
2016-11-09  Jiong Wang

 * config/aarch64/aarch64-opts.h (aarch64_pauth_key_index): New enum.
 (aarch64_function_type): New enum.
 * config/aarch64/aarch64-protos.h (aarch64_output_sign_auth_reg): New
 declaration.
 * config/aarch64/aarch64.c (aarch64_expand_prologue): Sign return
 address before it's pushed onto stack.
 (aarch64_expand_epilogue): Authenticate return address fetched from
 stack.
 (aarch64_output_sign_auth_reg): New function.
 (aarch64_override_options): Sanity check for ILP32 and ISA level.
 (aarch64_attributes): New function attributes for 
"sign-return-address",
 "pauth-key".
 * config/aarch64/aarch64.md (UNSPEC_AUTH_REG, UNSPEC_AUTH_REG1716,
 UNSPEC_SIGN_REG, UNSPEC_SIGN_REG1716, UNSPEC_STRIP_REG_SIGN,
 UNSPEC_STRIP_X30_SIGN): New unspecs.
 ("*do_return"): Generate combined instructions according to key index.
 ("sign_reg", "sign_reg1716", "auth_reg", "auth_reg1716",
 "strip_reg_sign", "strip_lr_sign"): New.
 * config/aarch64/aarch64.opt (msign-return-address, mpauth-key): New.
 * config/aarch64/predicates.md (aarch64_const0_const1): New predicate.
 * doc/extend.texi (AArch64 Function Attributes): Documents
 "sign-return-address=", "pauth-key".
 * doc/invoke.texi (AArch64 Options): Documents 
"-msign-return-address=",
 "-pauth-key".

gcc/testsuite/
2016-11-09  Jiong Wang

 * gcc.target/aarch64/return_address_sign_1.c: New testcase.
 * gcc.target/aarch64/return_address_sign_scope_1.c: New testcase.


Update the patchset according to new DWARF proposal described at

  https://gcc.gnu.org/ml/gcc-patches/2016-11/msg03010.html

While A key support for return address signing using DW_CFA_GNU_window_save only
needs simple modifications on code and associated DWARF generation, B key
support is complexer, it needs multiple CIE support in GCC and Binutils, so
currently we fall back to DWARF value expression which fully works although
requires longer encodings. Value expression also requires a few changes on
AArch64 prologue and epilogue hooks that code review will not be easy.

Therefore I have removed all B key support code in the initial support patch 
set,
and will organize them into a seperate follow up patchset so that we can do A 
key
code review first.

This patch is an update on the return address signing code generation.

gcc/
2017-01-06  Jiong Wang  

* config/aarch64/aarch64-opts.h (aarch64_function_type): New enum.
* config/aarch64/aarch64-protos.h
(aarch64_return_address_signing_enabled): New declaration.
* config/aarch64/aarch64.c (aarch64_return_address_signing_enabled):
New function.
(aarch64_expand_prologue): Sign return address before it's pushed onto
stack.
(aarch64_expand_epilogue): Authenticate return address fetched from
stack.
(aarch64_override_options): Sanity check for ILP32 and ISA level.
(aarch64_attributes): New function attributes for "sign-return-address".
* config/aarch64/aarch64.md (UNSPEC_AUTI1716, UNSPEC_AUTISP,
UNSPEC_PACI1716, UNSPEC_PACISP, UNSPEC_XPACLRI): New unspecs.
("*do_return"): Generate combined instructions according to key index.
("sp", "ca

[2/5][AArch64] Generate dwarf information for -msign-return-address

[Jiong Wang]

On 11/11/16 18:22, Jiong Wang wrote:

This patch generate DWARF description for pointer authentication.  DWARF value
expression is used to describe the authentication action.

Please see the cover letter and AArch64 DWARF specification for the semantics
of AArch64 DWARF operations.

When authentication key index is A key, we use compact DWARF description which
can largely save DWARF frame size, otherwise we fallback to general operator.



Example
===

 int
 cal (int a, int b, int c)
 {
   return a + dec (b) + c;
 }

Compact DWARF description
(-march=armv8.3-a -msign-return-address)
===

   DW_CFA_advance_loc: 4 to 0004
   DW_CFA_val_expression: r30 (x30) (DW_OP_AARCH64_paciasp)
   DW_CFA_advance_loc: 4 to 0008
   DW_CFA_val_expression: r30 (x30) (DW_OP_AARCH64_paciasp_deref: -24)

General DWARF description
===
(-march=armv8.3-a -msign-return-address -mpauth-key=b_key)

   DW_CFA_advance_loc: 4 to 0004
   DW_CFA_val_expression: r30 (x30) (DW_OP_breg30 (x30): 0; 
DW_OP_AARCH64_pauth: 18)
   DW_CFA_advance_loc: 4 to 0008
   DW_CFA_val_expression: r30 (x30) (DW_OP_dup; DW_OP_const1s: -24; DW_OP_plus; 
DW_OP_deref; DW_OP_AARCH64_pauth: 18)

 From Linux kernel testing, -msign-return-address will introduce +24%
.debug_frame size increase when signing all functions and using compact
description, and about +45% .debug_frame size increase if using general
description.


gcc/
2016-11-11  Jiong Wang

 * config/aarch64/aarch64.h (aarch64_pauth_action_type): New enum.
 * config/aarch64/aarch64.c (aarch64_attach_ra_auth_dwarf_note): New 
function.
 (aarch64_attach_ra_auth_dwarf_general): New function.
 (aarch64_attach_ra_auth_dwarf_shortcut): New function.
 (aarch64_save_callee_saves): Generate dwarf information if LR is 
signed.
 (aarch64_expand_prologue): Likewise.
 (aarch64_expand_epilogue): Likewise.


This patch is an update on DWARF generation for return address signing.

According to new proposal, we simply needs to generate REG_CFA_WINDOW_SAVE
annotation.

gcc/

2017-01-06  Jiong Wang  

* config/aarch64/aarch64.c (aarch64_expand_prologue): Generate dwarf
annotation (REG_CFA_WINDOW_SAVE) for return address signing.
(aarch64_expand_epilogue): Likewise.


diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 002895a167ce0deb45a5c1726527651af18bb4df..20ed79e5690f45ec121ef516245c686cc0cc82b5 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -3553,7 +3553,11 @@ aarch64_expand_prologue (void)
 
   /* Sign return address for functions.  */
   if (aarch64_return_address_signing_enabled ())
-emit_insn (gen_pacisp ());
+{
+  insn = emit_insn (gen_pacisp ());
+  add_reg_note (insn, REG_CFA_WINDOW_SAVE, const0_rtx);
+  RTX_FRAME_RELATED_P (insn) = 1;
+}
 
   if (flag_stack_usage_info)
 current_function_static_stack_size = frame_size;
@@ -3698,7 +3702,11 @@ aarch64_expand_epilogue (bool for_sibcall)
  want to use the CFA of the function which calls eh_return.  */
   if (aarch64_return_address_signing_enabled ()
   && (for_sibcall || !TARGET_ARMV8_3 || crtl->calls_eh_return))
-emit_insn (gen_autisp ());
+{
+  insn = emit_insn (gen_autisp ());
+  add_reg_note (insn, REG_CFA_WINDOW_SAVE, const0_rtx);
+  RTX_FRAME_RELATED_P (insn) = 1;
+}
 
   /* Stack adjustment for exception handler.  */
   if (crtl->calls_eh_return)

[5/5][AArch64, libgcc] Runtime support for AArch64 DWARF operations

[Jiong Wang]

On 11/11/16 18:22, Jiong Wang wrote:

This patch add AArch64 specific runtime EH unwinding support for
DW_OP_AARCH64_pauth, DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref.

The semantics of them are described at the specification in patch [1/9].

The support includes:
   * Parsing these DWARF operations.  Perform unwinding actions according to
 their semantics.

   * Handling eh_return multi return paths.
 Function calling __builtin_eh_return (_Unwind_RaiseException*) will have
 multiple return paths.  One is for normal exit, the other is for install
 EH handler.  If the _Unwind_RaiseException itself is return address signed,
 then there will always be return address authentication before return,
 however, if the return path in _Unwind_RaiseException if from installing EH
 handler the address of which has already been authenticated during
 unwinding,  then we need to re-sign that address, so when the execution 
flow
 continues at _Unwind_RaiseException's epilogue, the authentication still
 works correctly.


OK for trunk?

libgcc/
2016-11-11  Jiong Wang

 * config/aarch64/unwind-aarch64.c (RA_SIGN_BIT): New flag to indicate
 one frame is return address signed.
 (execute_stack_op): Handle DW_OP_AARCH64_pauth, DW_OP_AARCH64_paciasp,
 DW_OP_AARCH64_paciasp_deref.
 (uw_init_context): Call aarch64_uw_init_context_1.
 (uw_init_context_1): Rename to aarch64_uw_init_context_1.  Strip
 signature for seed address.
 (uw_install_context): Re-sign handler's address so it works correctly
 with caller's context.
 (uw_install_context_1): by_value[LR] can be true, after return address
 signing LR will come from DWARF value expression rule which is a
 by_value true rule.



This is the update on libgcc unwinder support according to new DWARF proposal.

As Joseph commented, duplication of unwind-dw2.c is not encouraged in libgcc,
But from this patch, you can see there are a few places we need to modify for
AArch64 in unwind-aarch64.c, so the file duplication approach is acceptable?


libgcc/

2017-01-06  Jiong Wang  

* config/aarch64/unwind-aarch64.c (DWARF_REGNUM_AARCH64_RA_STATE,
RA_A_SIGNED_BIT): New macros.
(execute_cfa_program): Multiplex DW_CFA_GNU_window_save on AArch64.
(uw_frame_state_for): Clear bit[0] of DWARF_REGNUM_AARCH64_RA_STATE.
(uw_update_context): Authenticate return address according to
DWARF_REGNUM_AARCH64_RA_STATE.
(uw_init_context_1): Strip signature of seed address.
(uw_install_context): Re-authenticate EH handler's address.

diff --git a/libgcc/config/aarch64/unwind-aarch64.c b/libgcc/config/aarch64/unwind-aarch64.c
index 1fb6026d123f8e7fc676f5e95e8e66caccf3d6ff..11e3c9f724c9bc5796103a0d973bfe769d23b6e7 100644
--- a/libgcc/config/aarch64/unwind-aarch64.c
+++ b/libgcc/config/aarch64/unwind-aarch64.c
@@ -37,6 +37,9 @@
 #include "gthr.h"
 #include "unwind-dw2.h"
 
+/* This is a copy of libgcc/unwind-dw2.c with AArch64 return address signing
+   support.  */
+
 #ifdef HAVE_SYS_SDT_H
 #include 
 #endif
@@ -55,6 +58,8 @@
 #define PRE_GCC3_DWARF_FRAME_REGISTERS __LIBGCC_DWARF_FRAME_REGISTERS__
 #endif
 
+#define DWARF_REGNUM_AARCH64_RA_STATE 32
+
 /* ??? For the public function interfaces, we tend to gcc_assert that the
column numbers are in range.  For the dwarf2 unwind info this does happen,
although so far in a case that doesn't actually matter.
@@ -136,6 +141,8 @@ struct _Unwind_Context
 #define SIGNAL_FRAME_BIT ((~(_Unwind_Word) 0 >> 1) + 1)
   /* Context which has version/args_size/by_value fields.  */
 #define EXTENDED_CONTEXT_BIT ((~(_Unwind_Word) 0 >> 2) + 1)
+  /* Return address has been signed with A key.  */
+#define RA_A_SIGNED_BIT ((~(_Unwind_Word) 0 >> 3) + 1)
   _Unwind_Word flags;
   /* 0 for now, can be increased when further fields are added to
  struct _Unwind_Context.  */
@@ -1185,13 +1192,9 @@ execute_cfa_program (const unsigned char *insn_ptr,
 	  break;
 
 	case DW_CFA_GNU_window_save:
-	  /* ??? Hardcoded for SPARC register window configuration.  */
-	  if (__LIBGCC_DWARF_FRAME_REGISTERS__ >= 32)
-	for (reg = 16; reg < 32; ++reg)
-	  {
-		fs->regs.reg[reg].how = REG_SAVED_OFFSET;
-		fs->regs.reg[reg].loc.offset = (reg - 16) * sizeof (void *);
-	  }
+	  /* This CFA is multiplexed with Sparc.  On AArch64 it's used to toggle
+	 return address signing status.  */
+	  fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1;
 	  break;
 
 	case DW_CFA_GNU_args_size:
@@ -1263,6 +1266,8 @@ uw_frame_state_for (struct _Unwind_Context *context, _Unwind_FrameState *fs)
   /* First decode all the insns in the CIE.  */
   end = (const unsigned char *) next_fde ((const struct dwarf_fde *) cie);
   execute_cfa_program (insn, end, context, fs);
+  /* Clear bit 0 of RA_STATE pseudo register.  */
+  fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset &= ~0x1;
 

[4/5][AArch64, libgcc] Let AArch64 use customized unwinder file

[Jiong Wang]

On 11/11/16 18:22, Jiong Wang wrote:

We need customized EH unwinder support for AArch64 DWARF operations introduced
earlier in this patchset, these changes mostly need to be done in the generic
file unwind-dw2.c.

There are two ways of introducing these AArch64 support:
   * Introducing a few target macros so we can customize functions like
 uw_init_context, uw_install_context etc.
   * Use target private unwind-dw2 implementation, i.e duplicate the generic
 unwind-dw2.c into target config directory and use it instead of generic 
one.
 This is current used by IA64 and CR16 is using.

I am not sure which approach is the convention in libgcc, Ian, any comments on 
this?
Thanks.

This patch is the start of using approach 2 includes necessary Makefile support
and copying of original unwind-dw2.c.

A follow up patch will implement those AArch64 specific stuff so the change will
be very clear.

OK for trunk?

libgcc/
2016-11-08  Jiong Wang

 * config.host (aarch64*-*-elf, aarch64*-*-rtems*, aarch64*-*-linux*):
 Include new AArch64 EH makefile.
 * config/aarch64/t-eh-aarch64: New EH makefile.
 * config/aarch64/unwind-aarch64.c: New EH unwinder implementation,
 copied from unwind-dw2.c.


Ping ~
No change on this patch for new DWARF proposal.

[3/5][AArch64] New builtins required by libgcc unwinder

[Jiong Wang]

On 11/11/16 18:22, Jiong Wang wrote:

This patch implements a few ARMv8.3-A new builtins for pointer sign and
authentication instructions.

Currently, these builtins are supposed to be used by libgcc EH unwinder
only.  They are not public interface to external user.

OK to install?

gcc/
2016-11-11  Jiong Wang

 * config/aarch64/aarch64-builtins.c (enum aarch64_builtins): New 
entries
 for AARCH64_PAUTH_BUILTIN_PACI1716, AARCH64_PAUTH_BUILTIN_AUTIA1716,
 AARCH64_PAUTH_BUILTIN_AUTIB1716, AARCH64_PAUTH_BUILTIN_XPACLRI.
 (aarch64_init_v8_3_builtins): New.
 (aarch64_init_builtins): Call aarch64_init_builtins.
 (arch64_expand_builtin): Expand new builtins.



This patch is an update on builtins support.  All these builtins are to be
internally used by libgcc only, so the updates only keeps those used.

OK for trunk?

gcc/

2017-01-06  Jiong Wang  

* config/aarch64/aarch64-builtins.c (enum aarch64_builtins): New entries
for AARCH64_PAUTH_BUILTIN_XPACLRI, AARCH64_PAUTH_BUILTIN_PACIA1716,
AARCH64_PAUTH_BUILTIN_AUTIA1716);
(aarch64_init_pauth_hint_builtins): New.
(aarch64_init_builtins): Call aarch64_init_pauth_hint_builtins.
(aarch64_expand_builtin): Expand new builtins.

diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index 69fb756f0fbdc016f35ce1d08f2aaf092a034704..9ae9d9afc9c141235d7eee037d5571b9f35edc31 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -376,6 +376,10 @@ enum aarch64_builtins
   AARCH64_CRC32_BUILTIN_BASE,
   AARCH64_CRC32_BUILTINS
   AARCH64_CRC32_BUILTIN_MAX,
+  /* ARMv8.3-A Pointer Authentication Builtins.  */
+  AARCH64_PAUTH_BUILTIN_AUTIA1716,
+  AARCH64_PAUTH_BUILTIN_PACIA1716,
+  AARCH64_PAUTH_BUILTIN_XPACLRI,
   AARCH64_BUILTIN_MAX
 };
 
@@ -923,6 +927,33 @@ aarch64_init_fp16_types (void)
   aarch64_fp16_ptr_type_node = build_pointer_type (aarch64_fp16_type_node);
 }
 
+/* Pointer authentication builtins that will become NOP on legacy platform.
+   Currently, these builtins are for internal use only (libgcc EH unwinder).  */
+
+void
+aarch64_init_pauth_hint_builtins (void)
+{
+  /* Pointer Authentication builtins.  */
+  tree ftype_pointer_auth
+= build_function_type_list (ptr_type_node, ptr_type_node,
+unsigned_intDI_type_node, NULL_TREE);
+  tree ftype_pointer_strip
+= build_function_type_list (ptr_type_node, ptr_type_node, NULL_TREE);
+
+  aarch64_builtin_decls[AARCH64_PAUTH_BUILTIN_AUTIA1716]
+= add_builtin_function ("__builtin_aarch64_autia1716", ftype_pointer_auth,
+			AARCH64_PAUTH_BUILTIN_AUTIA1716, BUILT_IN_MD, NULL,
+			NULL_TREE);
+  aarch64_builtin_decls[AARCH64_PAUTH_BUILTIN_PACIA1716]
+= add_builtin_function ("__builtin_aarch64_pacia1716", ftype_pointer_auth,
+			AARCH64_PAUTH_BUILTIN_PACIA1716, BUILT_IN_MD, NULL,
+			NULL_TREE);
+  aarch64_builtin_decls[AARCH64_PAUTH_BUILTIN_XPACLRI]
+= add_builtin_function ("__builtin_aarch64_xpaclri", ftype_pointer_strip,
+			AARCH64_PAUTH_BUILTIN_XPACLRI, BUILT_IN_MD, NULL,
+			NULL_TREE);
+}
+
 void
 aarch64_init_builtins (void)
 {
@@ -951,6 +982,10 @@ aarch64_init_builtins (void)
 
   aarch64_init_crc32_builtins ();
   aarch64_init_builtin_rsqrt ();
+
+/* Initialize pointer authentication builtins which are backed by instructions
+   in NOP encoding space.  */
+  aarch64_init_pauth_hint_builtins ();
 }
 
 tree
@@ -1293,6 +1328,43 @@ aarch64_expand_builtin (tree exp,
 	}
   emit_insn (pat);
   return target;
+case AARCH64_PAUTH_BUILTIN_AUTIA1716:
+case AARCH64_PAUTH_BUILTIN_PACIA1716:
+case AARCH64_PAUTH_BUILTIN_XPACLRI:
+  arg0 = CALL_EXPR_ARG (exp, 0);
+  op0 = force_reg (Pmode, expand_normal (arg0));
+
+  if (!target)
+	target = gen_reg_rtx (Pmode);
+  else
+	target = force_reg (Pmode, target);
+
+  emit_move_insn (target, op0);
+
+  if (fcode == AARCH64_PAUTH_BUILTIN_XPACLRI)
+	{
+	  rtx lr = gen_rtx_REG (Pmode, R30_REGNUM);
+	  icode = CODE_FOR_xpaclri;
+	  emit_move_insn (lr, op0);
+	  emit_insn (GEN_FCN (icode) ());
+	  emit_move_insn (target, lr);
+	}
+  else
+	{
+	  tree arg1 = CALL_EXPR_ARG (exp, 1);
+	  rtx op1 = force_reg (Pmode, expand_normal (arg1));
+	  icode = (fcode == AARCH64_PAUTH_BUILTIN_PACIA1716
+		   ? CODE_FOR_paci1716 : CODE_FOR_auti1716);
+
+	  rtx x16_reg = gen_rtx_REG (Pmode, R16_REGNUM);
+	  rtx x17_reg = gen_rtx_REG (Pmode, R17_REGNUM);
+	  emit_move_insn (x17_reg, op0);
+	  emit_move_insn (x16_reg, op1);
+	  emit_insn (GEN_FCN (icode) ());
+	  emit_move_insn (target, x17_reg);
+	}
+
+  return target;
 }
 
   if (fcode >= AARCH64_SIMD_BUILTIN_BASE && fcode <= AARCH64_SIMD_BUILTIN_MAX)

[PATCH][ARM] PR target/71270 fix neon_valid_immediate for big-endian

[Kyrill Tkachov]

Hi all,

In this wrong-code issue the RTL tries to load a const_vector:
(const_vector:V8QI [
(const_int 1 [0x1])
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 0 [0])
])

into a NEON register. The logic for that is in neon_valid_immediate which does 
a number of tricks
to decide what value and of what size to do a VMOV on to load the correct 
vector immediate into the register.
It goes wrong on big-endian. On both big and little-endian this outputs:
vmov.i16d18, #0x1

This is wrong on big-endian. The vector layout has to be such as if loaded from 
memory.
I've tried various approaches of fixing neon_valid_immediate to generate the 
correct immediate but have been unsuccessful,
resulting in regressions in various parts of the testsuite or making a big mess 
of the function.

Given that armeb is not a target of major concern I believe the safest route at 
this stage is to only allow vector constants
that will obviously work on big-endian, that is the ones that are just a single 
element duplicated in all lanes.

This patch fixes the execution failures:
FAIL: gfortran.dg/intrinsic_pack_1.f90
FAIL: gfortran.dg/c_f_pointer_logical.f03
FAIL: gcc.dg/torture/pr60183.c
FAIL: gcc.dg/vect/pr51581-4.c

on armeb-none-eabi.

Ok for trunk?

Thanks,
Kyrill

2017-01-06  Kyrylo Tkachov  

PR target/71270
* config/arm/arm.c (neon_valid_immediate): Reject vector constants
in big-endian mode when they are not a single duplicated value.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 45e0a3cd11fa650f456f7382ffbbcd1c932b95eb..2beee8ebe94eeadd6fb1d5b119e3b474e1ab902a 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -11542,6 +11542,12 @@ neon_valid_immediate (rtx op, machine_mode mode, int inverse,
 	return 18;
 }
 
+  /* The tricks done in the code below apply for little-endian vector layout.
+ For big-endian vectors only allow vectors of the form { a, a, a..., a }.
+ FIXME: Implement logic for big-endian vectors.  */
+  if (BYTES_BIG_ENDIAN && vector && !const_vec_duplicate_p (op))
+return -1;
+
   /* Splat vector constant out into a byte vector.  */
   for (i = 0; i < n_elts; i++)
 {

[Ada] pragma Rename_Pragma

[Arnaud Charlet]

This patch implements a new GNAT-specific pragma Rename_Pragma, which is
helpful when porting code from other compilers that have similar pragmas but
with different names.

pragma Rename_Pragma
  (New_Name => Inline_Only,
   Renamed  => Inline_Always);

causes GNAT to treat "pragma Inline_Only ..." as if you had written "pragma
Inline_Always ...".

The following test must compile quietly:

-- gnat.adc:

pragma Rename_Pragma (New_Name => Inline_Only, Renamed => Inline_Always);

-- rename_pragma.ads:

package Rename_Pragma is
   pragma Pure;

   procedure P;
   pragma INLINE_ONLY (P);
end Rename_Pragma;

-- rename_pragma.adb:

package body Rename_Pragma is
   procedure P is begin null; end;
end Rename_Pragma;

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-06  Bob Duff  

* snames.ads-tmpl (Renamed): New name for the pragma argument.
* par-ch2.adb: Allow the new pragma (with analysis deferred
to Sem_Prag).
* sinfo.ads, sinfo.adb (Map_Pragma_Name, Pragma_Name_Mapped):
Keep a mapping from new pragma names to old names.
* sem_prag.adb: Check legality of pragma Rename_Pragma, and
implement it by calling Map_Pragma_Name.
* checks.adb, contracts.adb, einfo.adb, errout.adb,
* exp_attr.adb, exp_ch3.adb, exp_ch6.adb, exp_ch7.adb, exp_ch9.adb,
* exp_prag.adb, exp_util.adb, freeze.adb, frontend.adb, ghost.adb,
* inline.adb, lib-writ.adb, scans.adb, scans.ads, sem_attr.adb,
* sem_aux.adb, sem_ch10.adb, sem_ch13.adb, sem_ch6.adb, sem_ch9.adb,
* sem_elab.adb, sem_res.adb, sem_util.adb, sem_util.ads,
* sem_warn.adb: Call Pragma_Name_Mapped instead of Pragma_Name
as appropriate.

Index: checks.adb
===
--- checks.adb  (revision 244136)
+++ checks.adb  (working copy)
@@ -2412,8 +2412,7 @@
  begin
 Prag :=
   Make_Pragma (Loc,
-Pragma_Identifier=>
-  Make_Identifier (Loc, Prag_Nam),
+Chars => Prag_Nam,
 Pragma_Argument_Associations => New_List (
   Make_Pragma_Argument_Association (Loc,
 Chars  => Name_Check,
Index: contracts.adb
===
--- contracts.adb   (revision 244124)
+++ contracts.adb   (working copy)
@@ -115,16 +115,14 @@
 
   --  Local variables
 
-  Prag_Nam : Name_Id;
-
-   --  Start of processing for Add_Contract_Item
-
-   begin
   --  A contract must contain only pragmas
 
   pragma Assert (Nkind (Prag) = N_Pragma);
-  Prag_Nam := Pragma_Name (Prag);
+  Prag_Nam : constant Name_Id := Pragma_Name_Mapped (Prag);
 
+   --  Start of processing for Add_Contract_Item
+
+   begin
   --  Create a new contract when adding the first item
 
   if No (Items) then
@@ -577,7 +575,7 @@
 
  Prag := Contract_Test_Cases (Items);
  while Present (Prag) loop
-Prag_Nam := Pragma_Name (Prag);
+Prag_Nam := Pragma_Name_Mapped (Prag);
 
 if Prag_Nam = Name_Contract_Cases then
 
@@ -606,7 +604,7 @@
 
  Prag := Classifications (Items);
  while Present (Prag) loop
-Prag_Nam := Pragma_Name (Prag);
+Prag_Nam := Pragma_Name_Mapped (Prag);
 
 if Prag_Nam = Name_Depends then
Depends := Prag;
@@ -1021,7 +1019,7 @@
 
  Prag := Classifications (Items);
  while Present (Prag) loop
-Prag_Nam := Pragma_Name (Prag);
+Prag_Nam := Pragma_Name_Mapped (Prag);
 
 if Prag_Nam = Name_Initial_Condition then
Init_Cond := Prag;
@@ -1787,7 +1785,7 @@
 if Present (Items) then
Prag := Contract_Test_Cases (Items);
while Present (Prag) loop
-  if Pragma_Name (Prag) = Name_Contract_Cases then
+  if Pragma_Name_Mapped (Prag) = Name_Contract_Cases then
  Expand_Pragma_Contract_Cases
(CCs => Prag,
 Subp_Id => Subp_Id,
@@ -1840,7 +1838,7 @@
 if Present (Items) then
Prag := Pre_Post_Conditions (Items);
while Present (Prag) loop
-  if Pragma_Name (Prag) = Post_Nam then
+  if Pragma_Name_Mapped (Prag) = Post_Nam then
  Append_Enabled_Item
(Item => Build_Pragma_Check_Equivalent (Prag),
 List => Stmts);
@@ -1862,7 +1860,7 @@
   --  Note that non-matching pragmas are skipped
 
   if Nkind (Decl) = N_Pragma then
- if Pragma_Name (Decl) = Post_Nam then
+ if Pragma_Name_Mapped (Decl) = Post_Nam then
 Append_Enabled_Item
   (Item => Build_Pragma

[Ada] Add Flush to Sequential_IO and Direct_IO.

[Arnaud Charlet]

This Flush routine is equivalent to the one found in the Text_IO
package for example.

The Flush procedure synchronizes the external file with the internal
file (by flushing any internal buffers) without closing the file.

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-06  Pascal Obry  

* a-direio.adb, a-direio.ads, a-sequio.adb, a-sequio.ads: Add Flush to
Sequential_IO and Direct_IO.

Index: a-direio.adb
===
--- a-direio.adb(revision 244124)
+++ a-direio.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2012, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2016, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -108,6 +108,15 @@
   return DIO.End_Of_File (FP (File));
end End_Of_File;
 
+   ---
+   -- Flush --
+   ---
+
+   procedure Flush (File : File_Type) is
+   begin
+  FIO.Flush (AP (File));
+   end Flush;
+
--
-- Form --
--
Index: a-direio.ads
===
--- a-direio.ads(revision 244124)
+++ a-direio.ads(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- S p e c  --
 --  --
---  Copyright (C) 1992-2009, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2016, Free Software Foundation, Inc. --
 --  --
 -- This specification is derived from the Ada Reference Manual for use with --
 -- GNAT. The copyright notice above, and the license provisions that follow --
@@ -94,6 +94,8 @@
 
function Is_Open (File : File_Type) return Boolean;
 
+   procedure Flush (File : File_Type);
+
-
-- Input and Output Operations --
-
Index: a-sequio.adb
===
--- a-sequio.adb(revision 244124)
+++ a-sequio.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2013, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2016, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -121,6 +121,15 @@
   return FIO.End_Of_File (AP (File));
end End_Of_File;
 
+   ---
+   -- Flush --
+   ---
+
+   procedure Flush (File : File_Type) is
+   begin
+  FIO.Flush (AP (File));
+   end Flush;
+
--
-- Form --
--
Index: a-sequio.ads
===
--- a-sequio.ads(revision 244124)
+++ a-sequio.ads(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- S p e c  --
 --  --
---  Copyright (C) 1992-2009, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2016, Free Software Foundation, Inc. --
 --  --
 -- This specification is derived from the Ada Reference Manual for use with --
 -- GNAT. The copyright notice above, and the license provisions that follow --
@@ -90,6 +90,8 @@
 
function Is_Open (File : File_Type) return Boolean;
 
+   procedure Flush (File : File_Type);
+
-
-- Input and output operations --
-

[Ada] Allow task-type specific secondary-stack size definition

[Arnaud Charlet]

This patch provides a GNAT specific aspect and pragma Secondary_Stack_Size
that enables users to specify the size of the secondary stack for each
task type. On targets that use dynamic secondary stack size allocation,
this pragma defines the initial size of the secondary stack. On targets
using fixed secondary stack allocation, such as bare boards, the pragma
defines the amount of primary stack that will be reserved for secondary
stack.

When the restriction No_Secondary_Stack is in place, this patch now
suppresses the allocation of secondary stacks on targets using fixed
secondary stacks (except for the environment task where
System.Secondary_Stack.Default_Secondary_Stack_Size must be changed instead).

Tested on x86_64-pc-linux-gnu, committed on trunk

2017-01-06  Patrick Bernardi  

* aspect.adb, aspect.ads: Added new aspect Secondary_Stack_Size.
* exp_ch3.adb (Build_Init_Statements): As part of initialising
the value record of a task, set its _Secondary_Stack_Size field
if present.
* exp_ch9.adb (Expand_N_Task_Type_Declaration): Create
a _Secondary_Stack_Size field in the value record of
the task if a Secondary_Stack_Size rep item is present.
(Make_Task_Create_Call): Include secondary stack size
parameter. If No_Secondary_Stack restriction is in place, passes
stack size of 0.
* par-prag.adb, sem_prag.adb, sem_prag.ads: Added new pragma
Secondary_Stack_Size.
* s-secsta.adb, s-secsta.ads (Minimum_Secondary_Stack_Size): New
function to define the overhead of the secondary stack.
* s-tarest.adb (Create_Restricted_Task,
Create_Restricted_Task_Sequential): Functions now include
Secondary_Stack_Size parameter to pass to Initialize_ATCB.
* s-tarest.adb (Create_Restricted_Task,
Create_Restricted_Task_Sequential): Calls to Initialize_ATCB
now include Secondary_Stack_Size parameter.
(Task_Wrapper):
Secondary stack now allocated to the size specified by the
Secondary_Stack_Size parameter in the task's ATCB.
* s-taskin.adb, s-taskin.adb (Common_ATCB, Initialise_ATCB): New
Secondary_Stack_Size component.
* s-tassta.adb, s-tassta.ads (Create_Restricted_Task,
Create_Restricted_Task_Sequential): Function now include
Secondary_Stack_Size parameter.
(Task_Wrapper): Secondary stack
now allocated to the size specified by the Secondary_Stack_Size
parameter in the task's ATCB.
* sem_ch13.adb (Analyze_Aspect_Specification): Add support
for Secondary_Stack_Size aspect, turning the aspect into its
corresponding internal attribute.
(Analyze_Attribute_Definition):
Process Secondary_Stack_Size attribute.
* snames.adb-tmpl, snames.ads-tmpl: Added names
Name_Secondary_Stack_Size, Name_uSecondary_Stack_Size,
Attribute_Secondary_Stack_Size and Pragma_Secondary_Stack_Size.

Index: exp_ch9.adb
===
--- exp_ch9.adb (revision 244144)
+++ exp_ch9.adb (working copy)
@@ -11553,14 +11553,15 @@
--  values of this task. The general form of this type declaration is
 
--type taskV (discriminants) is record
-   --  _Task_Id   : Task_Id;
-   --  entry_family   : array (bounds) of Void;
-   --  _Priority  : Integer:= priority_expression;
-   --  _Size  : Size_Type  := size_expression;
-   --  _Task_Info : Task_Info_Type := task_info_expression;
-   --  _CPU   : Integer:= cpu_range_expression;
-   --  _Relative_Deadline : Time_Span  := time_span_expression;
-   --  _Domain: Dispatching_Domain := dd_expression;
+   --  _Task_Id  : Task_Id;
+   --  entry_family  : array (bounds) of Void;
+   --  _Priority : Integer:= priority_expression;
+   --  _Size : Size_Type  := size_expression;
+   --  _Secondary_Stack_Size : Size_Type  := size_expression;
+   --  _Task_Info: Task_Info_Type := task_info_expression;
+   --  _CPU  : Integer:= cpu_range_expression;
+   --  _Relative_Deadline: Time_Span  := time_span_expression;
+   --  _Domain   : Dispatching_Domain := dd_expression;
--end record;
 
--  The discriminants are present only if the corresponding task type has
@@ -11584,6 +11585,13 @@
--  in the pragma, and is used to override the task stack size otherwise
--  associated with the task type.
 
+   --  The _Secondary_Stack_Size field is present only the task entity has a
+   --  Secondary_Stack_Size rep item. It will be filled at the freeze point,
+   --  when the record init proc is built, to capture the expression of the
+   --  rep item (se

Re: [PATCH v2] Add mcpu flag for Qualcomm falkor core

[Siddhesh Poyarekar]

On 5 January 2017 at 05:00, Gerald Pfeifer  wrote:
> In case you are wondering, Siddhesh, Richard was referring
> to https://gcc.gnu.org/gcc-7/changes.html and at
> https://gcc.gnu.org/about.html you'll find some documentation
> on how to go about updating that.


I did post a patch and you reviewed it too:

https://patchwork.ozlabs.org/patch/693452/

but it looks like it never got pushed since I don't have commit access
to gcc.  I'll post an updated one shortly since it looks like the old
patch won't apply anymore.

Siddhesh

[PATCH, gcc, wwwdocs] Document upcoming Qualcomm Falkor processor support

[Siddhesh Poyarekar]

Hi,

This patch documents the newly added flag in gcc 7 for the upcoming
Qualcomm Falkor processor core.

Siddhesh

Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.33
diff -u -r1.33 changes.html
--- htdocs/gcc-7/changes.html   3 Jan 2017 10:55:03 -   1.33
+++ htdocs/gcc-7/changes.html   6 Jan 2017 12:09:53 -
@@ -390,7 +390,8 @@
  
Support has been added for the following processors
(GCC identifiers in parentheses): ARM Cortex-A73
-   (cortex-a73) and Broadcom Vulcan (vulcan).
+   (cortex-a73), Broadcom Vulcan (vulcan) and
+   Qualcomm Falkor (falkor).
The GCC identifiers can be used
as arguments to the -mcpu or -mtune options,
for example: -mcpu=cortex-a73 or

[PATCH] Don't redefine _GLIBCXX_ASSERTIONS if already defined

[Jonathan Wakely]

This avoids a potential redefinition warning if users define both
_GLIBCXX_DEBUG and _GLIBCXX_ASSERTIONS.

* include/bits/c++config (_GLIBCXX_ASSERTIONS): Avoid redefinition.

Tested powerpc64le-linux, committed to trunk.

commit e6b4586112080ac1912d336451207cba963a2c48
Author: Jonathan Wakely 
Date:   Fri Jan 6 11:30:25 2017 +

Don't redefine _GLIBCXX_ASSERTIONS if already defined

* include/bits/c++config (_GLIBCXX_ASSERTIONS): Avoid redefinition.

diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index b2eea3c..0cc1865 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -423,7 +423,7 @@ namespace std
 #endif
 
 // Debug Mode implies checking assertions.
-#ifdef _GLIBCXX_DEBUG
+#if defined(_GLIBCXX_DEBUG) && !defined(_GLIBCXX_ASSERTIONS)
 # define _GLIBCXX_ASSERTIONS 1
 #endif
 

[PATCH] PR78991 make __gnu_cxx::__ops constructors explicit

[Jonathan Wakely]

This solves a problem when using libstdc++ with Clang, due to Clang
more eagerly instantiating constexpr function templates during
argument deduction. G++ has some shortcuts to avoid this problem, but
Clang doesn't, and it's not clear that it's strictly speaking a bug in
Clang or if it's following the standard. By making these constructors
explicit we stop them being considered by overload resolution for
copying these functors, which stops us ending up back in the
std::function SFINAE checks.

I'm also using _GLIBCXX_MOVE to turn some internal copies into moves,
because otherwise using something like std::function with 
results in a number of potentially expensive copies.

PR libstdc++/78991
* include/bits/predefined_ops.h (_Iter_comp_iter, _Iter_comp_val)
(_Val_comp_iter, _Iter_equals_val, _Iter_pred, _Iter_comp_to_val)
(_Iter_comp_to_iter, _Iter_negate): Make constructors explicit and
move function objects.
(__iter_comp_iter, __iter_comp_val, __val_comp_iter, __pred_iter)
(__iter_comp_val, __iter_comp_iter, __negate): Move function objects.
* testsuite/25_algorithms/sort/78991.cc: New test.

Tested powerpc64le-linux, committed to trunk.

I'll backport  the 'explicit' constructors (but not the _GLIBCXX_MOVE
changes) to the branches too.

commit 882c06f293550aa080f07cfcb8de1411e4b86121
Author: Jonathan Wakely 
Date:   Fri Jan 6 11:22:21 2017 +

PR78991 make __gnu_cxx::__ops constructors explicit

PR libstdc++/78991
* include/bits/predefined_ops.h (_Iter_comp_iter, _Iter_comp_val)
(_Val_comp_iter, _Iter_equals_val, _Iter_pred, _Iter_comp_to_val)
(_Iter_comp_to_iter, _Iter_negate): Make constructors explicit and
move function objects.
(__iter_comp_iter, __iter_comp_val, __val_comp_iter, __pred_iter)
(__iter_comp_val, __iter_comp_iter, __negate): Move function objects.
* testsuite/25_algorithms/sort/78991.cc: New test.

diff --git a/libstdc++-v3/include/bits/predefined_ops.h 
b/libstdc++-v3/include/bits/predefined_ops.h
index 92feef3..2742984 100644
--- a/libstdc++-v3/include/bits/predefined_ops.h
+++ b/libstdc++-v3/include/bits/predefined_ops.h
@@ -42,6 +42,7 @@ namespace __ops
   operator()(_Iterator1 __it1, _Iterator2 __it2) const
   { return *__it1 < *__it2; }
   };
+
   _GLIBCXX14_CONSTEXPR
   inline _Iter_less_iter
   __iter_less_iter()
@@ -53,7 +54,7 @@ namespace __ops
   bool
   operator()(_Iterator __it, _Value& __val) const
   { return *__it < __val; }
-};
+  };
 
   inline _Iter_less_val
   __iter_less_val()
@@ -69,7 +70,7 @@ namespace __ops
   bool
   operator()(_Value& __val, _Iterator __it) const
   { return __val < *__it; }
-};
+  };
 
   inline _Val_less_iter
   __val_less_iter()
@@ -85,7 +86,7 @@ namespace __ops
   bool
   operator()(_Iterator1 __it1, _Iterator2 __it2) const
   { return *__it1 == *__it2; }
-};
+  };
 
   inline _Iter_equal_to_iter
   __iter_equal_to_iter()
@@ -97,7 +98,7 @@ namespace __ops
   bool
   operator()(_Iterator __it, _Value& __val) const
   { return *__it == __val; }
-};
+  };
 
   inline _Iter_equal_to_val
   __iter_equal_to_val()
@@ -111,9 +112,10 @@ namespace __ops
 struct _Iter_comp_iter
 {
   _Compare _M_comp;
-  _GLIBCXX14_CONSTEXPR
+
+  explicit _GLIBCXX14_CONSTEXPR
   _Iter_comp_iter(_Compare __comp)
-   : _M_comp(__comp)
+   : _M_comp(_GLIBCXX_MOVE(__comp))
   { }
 
   template
@@ -127,15 +129,16 @@ namespace __ops
 _GLIBCXX14_CONSTEXPR
 inline _Iter_comp_iter<_Compare>
 __iter_comp_iter(_Compare __comp)
-{ return _Iter_comp_iter<_Compare>(__comp); }
+{ return _Iter_comp_iter<_Compare>(_GLIBCXX_MOVE(__comp)); }
 
   template
 struct _Iter_comp_val
 {
   _Compare _M_comp;
 
+  explicit
   _Iter_comp_val(_Compare __comp)
-   : _M_comp(__comp)
+   : _M_comp(_GLIBCXX_MOVE(__comp))
   { }
 
   template
@@ -147,20 +150,21 @@ namespace __ops
   template
inline _Iter_comp_val<_Compare>
 __iter_comp_val(_Compare __comp)
-{ return _Iter_comp_val<_Compare>(__comp); }
+{ return _Iter_comp_val<_Compare>(_GLIBCXX_MOVE(__comp)); }
 
   template
 inline _Iter_comp_val<_Compare>
 __iter_comp_val(_Iter_comp_iter<_Compare> __comp)
-{ return _Iter_comp_val<_Compare>(__comp._M_comp); }
+{ return _Iter_comp_val<_Compare>(_GLIBCXX_MOVE(__comp._M_comp)); }
 
   template
 struct _Val_comp_iter
 {
   _Compare _M_comp;
 
+  explicit
   _Val_comp_iter(_Compare __comp)
-   : _M_comp(__comp)
+   : _M_comp(_GLIBCXX_MOVE(__comp))
   { }
 
   template
@@ -172,18 +176,19 @@ namespace __ops
   template
 inline _Val_comp_iter<_Compare>
 __val_comp_iter(_Compare __comp)
-{ return _Val_comp_iter<_Compare>(__comp); }
+{ return _Val_comp_iter<_Compare>(_GLIBCXX_MOVE(__comp)); }
 
   template
 inline _Val_co

[PATCH] Fix lto-bootstrap (PR bootstrap/79003).

[Martin Liška]

Hello.

This enables doable LTO bootstrap w/o -disable-werror. First change is mentioned
in the PR, second is adding -fno-lto to libdecnumber. Honza told me that proper
fix would take more effort as it's an old library. Last needed hunk handles 
-Wmaybe-uninitialized,
as described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79003#c4.

Patch LTO bootstraps on x86_64-linux-gnu, can bootstrap on ppc64le-redhat-linux
and survives regression tests.

Ready to be installed?
Martin
>From 67a3ccd99963ac19cbaebf17453cb51819c7bf1d Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 5 Jan 2017 17:18:27 +0100
Subject: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

gcc/ChangeLog:

2017-01-05  Martin Liska  

	PR bootstrap/79003
	* lra-constraints.c: Rename invariant to lra_invariant.
	* predict.c (set_even_probabilities): Initialize e to NULL.

libdecnumber/ChangeLog:

2017-01-05  Martin Liska  

	PR bootstrap/79003
	* Makefile.in: Add -fno-lto to {C,CPP,LD}FLAGS.
---
 gcc/lra-constraints.c| 9 +
 gcc/predict.c| 2 +-
 libdecnumber/Makefile.in | 6 +++---
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 61991280373..5ada67a36ba 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -4749,7 +4749,7 @@ lra_constraints_finish (void)
 
 
 /* Structure describes invariants for ineheritance.  */
-struct invariant
+struct lra_invariant
 {
   /* The order number of the invariant.  */
   int num;
@@ -4759,7 +4759,7 @@ struct invariant
   rtx_insn *insn;
 };
 
-typedef struct invariant invariant_t;
+typedef lra_invariant invariant_t;
 typedef invariant_t *invariant_ptr_t;
 typedef const invariant_t *const_invariant_ptr_t;
 
@@ -4767,7 +4767,7 @@ typedef const invariant_t *const_invariant_ptr_t;
 static vec invariants;
 
 /* Allocation pool for the invariants.  */
-static object_allocator *invariants_pool;
+static object_allocator *invariants_pool;
 
 /* Hash table for the invariants.  */
 static htab_t invariant_table;
@@ -4817,7 +4817,8 @@ static void
 initiate_invariants (void)
 {
   invariants.create (100);
-  invariants_pool = new object_allocator ("Inheritance invariants");
+  invariants_pool
+= new object_allocator ("Inheritance invariants");
   invariant_table = htab_create (100, invariant_hash, invariant_eq_p, NULL);
 }
 
diff --git a/gcc/predict.c b/gcc/predict.c
index e85573bc51d..f851e14b4ed 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -795,7 +795,7 @@ set_even_probabilities (basic_block bb,
 			hash_set *unlikely_edges = NULL)
 {
   unsigned nedges = 0;
-  edge e;
+  edge e = NULL;
   edge_iterator ei;
 
   FOR_EACH_EDGE (e, ei, bb->succs)
diff --git a/libdecnumber/Makefile.in b/libdecnumber/Makefile.in
index 02c327a59c4..2cfc5f48720 100644
--- a/libdecnumber/Makefile.in
+++ b/libdecnumber/Makefile.in
@@ -31,13 +31,13 @@ ACLOCAL = @ACLOCAL@
 AUTOCONF = @AUTOCONF@
 AUTOHEADER = @AUTOHEADER@
 CC = @CC@
-CFLAGS = @CFLAGS@
+CFLAGS = @CFLAGS@ -fno-lto
 WARN_CFLAGS = @WARN_CFLAGS@ @WARN_PEDANTIC@ @WERROR@
 CPP = @CPP@
-CPPFLAGS = @CPPFLAGS@
+CPPFLAGS = @CPPFLAGS@ -fno-lto
 INSTALL_DATA = @INSTALL_DATA@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
-LDFLAGS = @LDFLAGS@
+LDFLAGS = @LDFLAGS@ -fno-lto
 LIBICONV = @LIBICONV@
 PACKAGE = @PACKAGE@
 PICFLAG = @PICFLAG@
-- 
2.11.0

Re: [committed] Introduce RTL function reader

[Rainer Orth]

Hi David,

> The various parts of patch 8 appear to now have been approved, so
> I've committed it (along with "Add ASSERT_RTX_PTR_EQ", which it
> requires and is required by) to trunk as r244110, having rebased,
> and bootstrapped & regrtested on x86_64-pc-linux-gnu, and tested
> stage 1's selftests for aarch64-linux-gnu.

this patch thoroughly broke bootstrap on every 32-bit target, it seems:

In file included from /vol/gcc/src/hg/trunk/local/gcc/read-rtl.c:31:0:
/vol/gcc/src/hg/trunk/local/gcc/read-rtl.c: In member function 'rtx_def* 
rtx_reader::read_rtx_code(const char*)':
/vol/gcc/src/hg/trunk/local/gcc/read-rtl.c:1260:23: error: comparison between 
signed and unsigned integer expressions [-Werror=sign-compare]
   gcc_assert (idx < m_reuse_rtx_by_id.length ());
   ^
/vol/gcc/src/hg/trunk/local/gcc/system.h:731:14: note: in definition of macro 
'gcc_assert'
((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0 : 0))
  ^~~~

Seen on i386-pc-solaris2.*, sparc-sun-solaris2.*, and i686-pc-linux-gnu.

The following fix works for me, at least an i686-pc-linux-gnu bootstrap
is now into building target libraries.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2017-01-06  Rainer Orth  

* read-rtl.c (rtx_reader::read_rtx_code): Cast idx to unsigned.

diff --git a/gcc/read-rtl.c b/gcc/read-rtl.c
--- a/gcc/read-rtl.c
+++ b/gcc/read-rtl.c
@@ -1257,7 +1257,7 @@ rtx_reader::read_rtx_code (const char *c
   read_name (&name);
   long idx = atoi (name.string);
   /* Look it up by ID.  */
-  gcc_assert (idx < m_reuse_rtx_by_id.length ());
+  gcc_assert ((unsigned) idx < m_reuse_rtx_by_id.length ());
   return_rtx = m_reuse_rtx_by_id[idx];
   return return_rtx;
 }

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 01:41:15PM +0100, Martin Liška wrote:
> Hello.
> 
> This enables doable LTO bootstrap w/o -disable-werror. First change is 
> mentioned
> in the PR, second is adding -fno-lto to libdecnumber. Honza told me that 
> proper
> fix would take more effort as it's an old library. Last needed hunk handles 
> -Wmaybe-uninitialized,
> as described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79003#c4.
> 
> Patch LTO bootstraps on x86_64-linux-gnu, can bootstrap on 
> ppc64le-redhat-linux
> and survives regression tests.
> 
> Ready to be installed?
> Martin

> >From 67a3ccd99963ac19cbaebf17453cb51819c7bf1d Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Thu, 5 Jan 2017 17:18:27 +0100
> Subject: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).
> 
> gcc/ChangeLog:
> 
> 2017-01-05  Martin Liska  
> 
>   PR bootstrap/79003
>   * lra-constraints.c: Rename invariant to lra_invariant.
>   * predict.c (set_even_probabilities): Initialize e to NULL.
> 
> libdecnumber/ChangeLog:
> 
> 2017-01-05  Martin Liska  
> 
>   PR bootstrap/79003
>   * Makefile.in: Add -fno-lto to {C,CPP,LD}FLAGS.

Ok, thanks.

Jakub

Re: [PATCH] improve string find algorithm

[Jonathan Wakely]

On 07/12/16 11:46 -0600, Aditya Kumar wrote:

Here is an improved version of basic_string::find. The idea is to
split the string find in two parts:
1. search for the first match by using traits_type::find (this gets converted 
to memchr for x86)
2. see if there is a match (this gets converted to memcmp for x86)

Passes bootstrap on x86-64.

The patch results in good improvements on a synthetic test case I wrote using 
the google-benchmark.
following are the results.


Branch: master without patch
$ ./bin/string.libcxx.out
Run on (24 X 1899.12 MHz CPU s)
2016-12-06 16:41:55
***WARNING*** CPU scaling is enabled, the benchmark real time measurements may 
be noisy and will incur extra overhead.
Benchmark   Time   CPU Iterations
-
BM_StringFindNoMatch/10 8 ns  8 ns   81880927
BM_StringFindNoMatch/6452 ns 52 ns   13235018
BM_StringFindNoMatch/512  355 ns355 ns1962488
BM_StringFindNoMatch/4k  2769 ns   2772 ns 249090
BM_StringFindNoMatch/32k22598 ns  22619 ns  30984
BM_StringFindNoMatch/128k   89745 ns  89830 ns   7996
BM_StringFindAllMatch/1 7 ns  7 ns  102893835
BM_StringFindAllMatch/8 9 ns  9 ns   75403364
BM_StringFindAllMatch/64   12 ns 12 ns   60766893
BM_StringFindAllMatch/512  31 ns 31 ns   23163999
BM_StringFindAllMatch/4k  141 ns141 ns4980386
BM_StringFindAllMatch/32k1402 ns   1403 ns 483581
BM_StringFindAllMatch/128k   5604 ns   5609 ns 126123
BM_StringFindMatch1/1   44430 ns  44473 ns  15804
BM_StringFindMatch1/8   44315 ns  44357 ns  15741
BM_StringFindMatch1/64  44689 ns  44731 ns  15712
BM_StringFindMatch1/512 44247 ns  44290 ns  15724
BM_StringFindMatch1/4k  45010 ns  45053 ns  15678
BM_StringFindMatch1/32k 45717 ns  45761 ns  15278
BM_StringFindMatch2/1   44307 ns  44349 ns  15730
BM_StringFindMatch2/8   44631 ns  44674 ns  15721
BM_StringFindMatch2/64  44300 ns  44342 ns  15750
BM_StringFindMatch2/512 44239 ns  44281 ns  15713
BM_StringFindMatch2/4k  44886 ns  44928 ns  15787

Branch: master with patch
$ ./bin/string.libcxx.out
Run on (24 X 2892.28 MHz CPU s)
2016-12-06 18:51:38
***WARNING*** CPU scaling is enabled, the benchmark real time measurements may 
be noisy and will incur extra overhead.
Benchmark   Time   CPU Iterations
-
BM_StringFindNoMatch/1011 ns 11 ns   63049677
BM_StringFindNoMatch/6412 ns 12 ns   57259381
BM_StringFindNoMatch/512   27 ns 27 ns   25495432
BM_StringFindNoMatch/4k   130 ns130 ns5301301
BM_StringFindNoMatch/32k  858 ns859 ns 824048
BM_StringFindNoMatch/128k4091 ns   4095 ns 171493
BM_StringFindAllMatch/114 ns 14 ns   53023977
BM_StringFindAllMatch/814 ns 14 ns   51516536
BM_StringFindAllMatch/64   17 ns 17 ns   40992668
BM_StringFindAllMatch/512  37 ns 37 ns   18503267
BM_StringFindAllMatch/4k  153 ns153 ns4494458
BM_StringFindAllMatch/32k1460 ns   1461 ns 483380
BM_StringFindAllMatch/128k   5801 ns   5806 ns 120680
BM_StringFindMatch1/12062 ns   2064 ns 333144
BM_StringFindMatch1/82057 ns   2059 ns 335496
BM_StringFindMatch1/64   2083 ns   2085 ns 341469
BM_StringFindMatch1/512  2134 ns   2136 ns 336880
BM_StringFindMatch1/4k   2309 ns   2312 ns 308745
BM_StringFindMatch1/32k  3413 ns   3417 ns 208206
BM_StringFindMatch2/12053 ns   2055 ns 341523
BM_StringFindMatch2/82061 ns   2063 ns 343999
BM_StringFindMatch2/64   2075 ns   2077 ns 338479
BM_StringFindMatch2/512  2102 ns   2104 ns 332276
BM_StringFindMatch2/4k   2286 ns   2288 ns 300416
BM_StringFindMatch2/32k  3385 ns   3388 ns 204158


ChangeLog:

2016-12-07  Aditya Kumar 
  * include/bits/basic_string.tcc(find(const _CharT* __s, size_type
  __pos, size_type __n) const)): Improve the algorithm


---
libstdc++-v3/include/bits/basic_string.tcc | 31 ++
1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/libstdc++-v3/include/bits/basic_string.tcc 
b/libstdc++-v3/include/bits/basic_string.tcc
index df1e8dd..7942ee6 100644
--- a/libstdc++-v3/include/bits/basic_string.tcc
+++ b/libstdc++-v3/include/bits/basic_string.tcc
@@ -1194,14 +1194,29 @@ _GLIBCXX_BEGIN_

[PATCH] ipa/lto formatting

[Nathan Sidwell]

In debugging an lto problem, I fixed up some comments and formatting I 
stumbled across.


Committed as obvious.

nathan
--
Nathan Sidwell
2017-01-06  Nathan Sidwell  

	gcc/
	* ipa-visibility.c (function_and_variable_visibility): Reformat
	comments and long lines.  Remove extrneous if.
	* symtab.c (symtab_node::make_decl_local): Fix code format.
	(symtab_node::set_section_for_node): Fix comment typo.

	gcc/lto/
	* lto-partition.c (lto_balanced_map): Reformat/respell comment.
	(may_need_named_section_p): Likewise.
	(rename_statics): Likewise.
	(lto_promote_cross_file_statics): Likewise.

Index: ipa-visibility.c
===
--- ipa-visibility.c	(revision 244151)
+++ ipa-visibility.c	(working copy)
@@ -553,9 +553,9 @@ function_and_variable_visibility (bool w
 	  DECL_STATIC_DESTRUCTOR (node->decl) = 0;
 	}
 
-  /* Frontends and alias code marks nodes as needed before parsing is finished.
-	 We may end up marking as node external nodes where this flag is meaningless
-	 strip it.  */
+  /* Frontends and alias code marks nodes as needed before parsing
+	 is finished.  We may end up marking as node external nodes
+	 where this flag is meaningless strip it.  */
   if (DECL_EXTERNAL (node->decl) || !node->definition)
 	{
 	  node->force_output = 0;
@@ -609,35 +609,36 @@ function_and_variable_visibility (bool w
 	{
 	  gcc_assert (whole_program || in_lto_p
 		  || !TREE_PUBLIC (node->decl));
-	  node->unique_name |= ((node->resolution == LDPR_PREVAILING_DEF_IRONLY
- || node->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP)
-&& TREE_PUBLIC (node->decl)
-&& !flag_incremental_link);
+	  node->unique_name
+	|= ((node->resolution == LDPR_PREVAILING_DEF_IRONLY
+		 || node->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP)
+		&& TREE_PUBLIC (node->decl)
+		&& !flag_incremental_link);
 	  node->resolution = LDPR_PREVAILING_DEF_IRONLY;
 	  if (node->same_comdat_group && TREE_PUBLIC (node->decl))
 	{
 	  symtab_node *next = node;
 
 	  /* Set all members of comdat group local.  */
-	  if (node->same_comdat_group)
-		for (next = node->same_comdat_group;
-		 next != node;
-		 next = next->same_comdat_group)
+	  for (next = node->same_comdat_group;
+		   next != node;
+		   next = next->same_comdat_group)
 		{
 		  next->set_comdat_group (NULL);
 		  if (!next->alias)
 		next->set_section (NULL);
 		  if (!next->transparent_alias)
 		next->make_decl_local ();
-		  next->unique_name |= ((next->resolution == LDPR_PREVAILING_DEF_IRONLY
-	 || next->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP)
-&& TREE_PUBLIC (next->decl)
-	&& !flag_incremental_link);
+		  next->unique_name
+		|= ((next->resolution == LDPR_PREVAILING_DEF_IRONLY
+			 || next->resolution == LDPR_PREVAILING_DEF_IRONLY_EXP)
+			&& TREE_PUBLIC (next->decl)
+			&& !flag_incremental_link);
 		}
-	  /* cgraph_externally_visible_p has already checked all other nodes
-	 in the group and they will all be made local.  We need to
-	 dissolve the group at once so that the predicate does not
-	 segfault though. */
+	  /* cgraph_externally_visible_p has already checked all
+	 other nodes in the group and they will all be made
+	 local.  We need to dissolve the group at once so that
+	 the predicate does not segfault though. */
 	  node->dissolve_same_comdat_group_list ();
 	}
 	  if (TREE_PUBLIC (node->decl))
Index: lto/lto-partition.c
===
--- lto/lto-partition.c	(revision 244151)
+++ lto/lto-partition.c	(working copy)
@@ -668,8 +668,9 @@ lto_balanced_map (int n_lto_partitions,
 
 		vnode = dyn_cast  (ref->referring);
 		gcc_assert (vnode->definition);
-		/* It is better to couple variables with their users, because it allows them
-		   to be removed.  Coupling with objects they refer to only helps to reduce
+		/* It is better to couple variables with their users,
+		   because it allows them to be removed.  Coupling
+		   with objects they refer to only helps to reduce
 		   number of symbols promoted to hidden.  */
 		if (!symbol_partitioned_p (vnode) && flag_toplevel_reorder
 		&& !vnode->no_reorder
@@ -1008,10 +1009,11 @@ promote_symbol (symtab_node *node)
 	"Promoting as hidden: %s\n", node->name ());
 }
 
-/* Return true if NODE needs named section even if it won't land in the partition
-   symbol table.
-   FIXME: we should really not use named sections for inline clones and master
-   clones.  */
+/* Return true if NODE needs named section even if it won't land in
+   the partition symbol table.
+
+   FIXME: we should really not use named sections for inline clones
+   and master clones.  */
 
 static bool
 may_need_named_section_p (lto_symtab_encoder_t encoder, symtab_node *node)
@@ -1089,7 +1091,8 @@ rename_statics (lto_symtab_encoder_t enc
 	|| lto_symtab_encoder_lookup (encoder, s) != LCC_NOT_

[LTO PATCH] Improve dumping

[Nathan Sidwell]

This patch helped me diagnose the LTO bug I'm working on.  It adds 
dumping of alias promotion, just after the symbol they alias.


committed as obvious.

nathan
--
Nathan Sidwell
2017-01-06  Nathan Sidwell  

	* lto-partition.c (promote_symbol): Write to dump file sooner,
	include alias promoting too.

Index: lto/lto-partition.c
===
--- lto/lto-partition.c	(revision 244158)
+++ lto/lto-partition.c	(working copy)
@@ -987,11 +987,15 @@ promote_symbol (symtab_node *node)
   TREE_PUBLIC (node->decl) = 1;
   DECL_VISIBILITY (node->decl) = VISIBILITY_HIDDEN;
   DECL_VISIBILITY_SPECIFIED (node->decl) = true;
-  ipa_ref *ref;
+  if (symtab->dump_file)
+fprintf (symtab->dump_file,
+	 "Promoting as hidden: %s (%s)\n", node->name (),
+	 IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (node->decl)));
 
-  /* Promoting a symbol also promotes all trasparent aliases with exception
+  /* Promoting a symbol also promotes all transparent aliases with exception
  of weakref where the visibility flags are always wrong and set to 
  !PUBLIC.  */
+  ipa_ref *ref;
   for (unsigned i = 0; node->iterate_direct_aliases (i, ref); i++)
 {
   struct symtab_node *alias = ref->referring;
@@ -1000,13 +1004,13 @@ promote_symbol (symtab_node *node)
 	  TREE_PUBLIC (alias->decl) = 1;
 	  DECL_VISIBILITY (alias->decl) = VISIBILITY_HIDDEN;
 	  DECL_VISIBILITY_SPECIFIED (alias->decl) = true;
+	  if (symtab->dump_file)
+	fprintf (symtab->dump_file,
+		 "Promoting alias as hidden: %s\n",
+		 IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (node->decl)));
 	}
   gcc_assert (!alias->weakref || TREE_PUBLIC (alias->decl));
 }
-
-  if (symtab->dump_file)
-fprintf (symtab->dump_file,
-	"Promoting as hidden: %s\n", node->name ());
 }
 
 /* Return true if NODE needs named section even if it won't land in

Re: [build, libgo, libstdc++] Build libgo with -Wa,-nH if possible (PR go/78978)

[Ian Lance Taylor]

On Thu, Jan 5, 2017 at 1:20 AM, Rainer Orth  
wrote:
> As could have been expected, the static libgo.a causes the same problem
> with hardware capabilities on Solaris/x86 as was solved for libgo.so
> with
>
> https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00726.html
>
> Instead of trying to pass -mclear-hwcap with -static-libgo, it was
> deemed easier to solve both problems the same way and disable hwcaps
> support in the assembler in the first place.
>
> This has already been done in libstdc++, so I've moved the corresponding
> autoconf macro to config/hwcaps.m4 and adapted it to set HWCAP_CFLAGS
> instead of HWCAP_FLAGS to better differntiate from HWCAP_LDFLAGS.
> Everything else is straightforward, I believe.
>
> Bootstrapped without regressions on i386-pc-solaris2.1[02] with as/ld
> (where as supports -nH) and sparc-sun-solaris2.12 with as/ld (where as
> doesn't, or rather it's called -hwcap={1|0}), and the libgo
> runtime/pprof failure is gone.
>
> Ok for mainline?
>
> Once approved, how should we proceed with checking?  Ian, will you take
> care of the libgo part once the rest is in?

This patch is OK.  Yes, please commit the config and libstdc++
portions.  Then I will commit the libgo portions to the external repo
and mirror them in.  Thanks.

Ian

Re: [PATCH 2/6][ARM] Move CRC builtins to refactored framework

[Andre Vieira (lists)]

On 05/01/17 10:27, Kyrill Tkachov wrote:
> 
> On 05/12/16 15:05, Andre Vieira (lists) wrote:
>> On 01/12/16 17:25, Andre Vieira (lists) wrote:
>>> On 09/11/16 10:11, Andre Vieira (lists) wrote:
 Hi,

 This patch refactors the implementation of the ARM ACLE CRC builtins to
 use the builtin framework.

 Is this OK for trunk?

 Regards,
 Andre

 gcc/ChangeLog
 2016-11-09  Andre Vieira  

* config/arm/arm-builtins.c (arm_unsigned_binop_qualifiers): New.
(UBINOP_QUALIFIERS): New.
(si_UP): Define.
(acle_builtin_data): New. Change comment.
(arm_builtins): Remove ARM_BUILTIN_CRC32B, ARM_BUILTIN_CRC32H,
ARM_BUILTIN_CRC32W, ARM_BUILTIN_CRC32CB, ARM_BUILTIN_CRC32CH,
ARM_BUILTIN_CRC32CW. Add ARM_BUILTIN_ACLE_BASE and include
arm_acle_builtins.def.
(ARM_BUILTIN_ACLE_PATTERN_START): Define.
(arm_init_acle_builtins): New.
(CRC32_BUILTIN): Remove.
(bdesc_2arg): Remove entries for crc32b, crc32h, crc32w,
crc32cb, crc32ch and crc32cw.
(arm_init_crc32_builtins): Remove.
(arm_init_builtins): Use arm_init_acle_builtins rather
than arm_init_crc32_builtins.
(arm_expand_acle_builtin): New.
(arm_expand_builtin): Use 'arm_expand_acle_builtin'.
* config/arm/arm_acle_builtins.def: New.

>>> Hi,
>>>
>>> Reworked this patch based on the changes made in [1/6]. No changes to
>>> ChangeLog.
>>>
>>> Is this OK?
> 
> Ok assuming normal bootstrap and regtest on an arm-none-linux-gnueabihf
> target.
> Thanks,
> Kyrill
> 
>>> Cheers,
>>> Andre
>>>
>> Hi,
>>
>> I had a typo in one of the range checks was using ARM_BUILTIN_ACLE_MAX
>> where it should've been ARM_BUILTIN_ACLE_BASE.
>>
>> Cheers,
>> Andre
> 
Hi,

I rebased the series, the first patch only had whitespace changes, this
one has a context change, so I thought I'd send it upstream in case you
want to apply them locally.

Cheers,
Andre
diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index 
9101ad216eb70fb64ef90d225474520b8113fd3f..febbec9fca079ac03b93edec970ebc537e25309b
 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -158,6 +158,13 @@ arm_load1_lane_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   qualifier_none, qualifier_struct_load_store_lane_index };
 #define LOAD1LANE_QUALIFIERS (arm_load1_lane_qualifiers)
 
+/* unsigned T (unsigned T, unsigned T, unsigned T).  */
+static enum arm_type_qualifiers
+arm_unsigned_binop_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_unsigned, qualifier_unsigned, qualifier_unsigned,
+  qualifier_unsigned };
+#define UBINOP_QUALIFIERS (arm_unsigned_binop_qualifiers)
+
 /* The first argument (return type) of a store should be void type,
which we represent with qualifier_void.  Their first operand will be
a DImode pointer to the location to store to, so we must use
@@ -243,17 +250,16 @@ typedef struct {
   VAR11 (T, N, A, B, C, D, E, F, G, H, I, J, K) \
   VAR1 (T, N, L)
 
-/* The builtin data can be found in arm_neon_builtins.def,
-   arm_vfp_builtins.def.  The entries in arm_neon_builtins.def require
-   TARGET_NEON to be true.  The feature tests are checked when the
-   builtins are expanded.
+/* The builtin data can be found in arm_neon_builtins.def, arm_vfp_builtins.def
+   and arm_acle_builtins.def.  The entries in arm_neon_builtins.def require
+   TARGET_NEON to be true.  The feature tests are checked when the builtins are
+   expanded.
 
-   The mode entries in the following table correspond to the "key"
-   type of the instruction variant, i.e. equivalent to that which
-   would be specified after the assembler mnemonic, which usually
-   refers to the last vector operand.  The modes listed per
-   instruction should be the same as those defined for that
-   instruction's pattern, for instance in neon.md.  */
+   The mode entries in the following table correspond to the "key" type of the
+   instruction variant, i.e. equivalent to that which would be specified after
+   the assembler mnemonic for neon instructions, which usually refers to the
+   last vector operand.  The modes listed per instruction should be the same as
+   those defined for that instruction's pattern, for instance in neon.md.  */
 
 static arm_builtin_datum vfp_builtin_data[] =
 {
@@ -267,6 +273,15 @@ static arm_builtin_datum neon_builtin_data[] =
 
 #undef CF
 #undef VAR1
+#define VAR1(T, N, A) \
+  {#N, UP (A), CODE_FOR_##N, 0, T##_QUALIFIERS},
+
+static arm_builtin_datum acle_builtin_data[] =
+{
+#include "arm_acle_builtins.def"
+};
+
+#undef VAR1
 
 #define VAR1(T, N, X) \
   ARM_BUILTIN_NEON_##N##X,
@@ -519,13 +534,6 @@ enum arm_builtins
 
   ARM_BUILTIN_WMERGE,
 
-  ARM_BUILTIN_CRC32B,
-  ARM_BUILTIN_CRC32H,
-  ARM_BUILTIN_CRC32W,
-  ARM_BUILTIN_CRC32CB,
-  ARM_BUILTIN_CRC32CH,
-  ARM_BUILTIN_CRC32CW,
-
   ARM_BUILTIN_GET_FPSCR,
   ARM_BUILTIN_SET_FPSCR,
 
@@ -559,6 +567,14 @@ enum arm_builtins
 
 

Re: [PATCH 3/6][ARM] Implement support for ACLE Coprocessor CDP intrinsics

[Andre Vieira (lists)]

On 05/01/17 10:44, Kyrill Tkachov wrote:
> Hi Andre,
> 
> On 09/11/16 10:11, Andre Vieira (lists) wrote:
>> Hi,
>>
>> This patch implements support for the ARM ACLE Coprocessor CDP
>> intrinsics. See below a table mapping the intrinsics to their respective
>> instructions:
>>
>> ++--+
>>
>> | Intrinsic signature| Instruction
>> pattern  |
>> ++--+
>>
>> |void __arm_cdp(coproc, opc1, CRd, CRn, CRm, opc2)   |CDP coproc, opc1,
>> CRd, CRn, CRm, opc2 |
>> ++--+
>>
>> |void __arm_cdp2(coproc, opc1, CRd, CRn, CRm, opc2)  |CDP2 coproc, opc1,
>> CRd, CRn, CRm, opc2|
>> ++--+
>>
>> Note that any untyped variable in the intrinsic signature is required to
>> be a compiler-time constant and has the type 'unsigned int'.  We do some
>> boundary checks for coproc:[0-15], opc1:[0-15], CR*:[0-31], opc2:[0-7].
>> If either of these requirements are not met a diagnostic is issued.
>>
>> I renamed neon_const_bounds in this patch, to arm_const_bounds, simply
>> because it is also used in the Coprocessor intrinsics.  It also requires
>> the expansion of the builtin frame work such that it accepted 'void'
>> modes and intrinsics with 6 arguments.
>>
>> I also changed acle.exp to run tests for multiple options, where all lto
>> option sets are appended with -ffat-objects to allow for assembly scans.
>>
>> Is this OK for trunk?
> 
> This is okay if bootstrap and testing is ok (as part of the whole series)
> modulo a couple of nits in the documentation below.
> 
> Thanks,
> Kyrill
> 
>> Regards,
>> Andre
>>
>> gcc/ChangeLog:
>> 2016-11-09  Andre Vieira  
>>
>>* config/arm/arm.md (): New.
>>* config/arm/arm.c (neon_const_bounds): Rename this ...
>>(arm_const_bounds): ... this.
>>(arm_coproc_builtin_available): New.
>>* config/arm/arm-builtins.c (SIMD_MAX_BUILTIN_ARGS): Increase.
>>(arm_type_qualifiers): Add 'qualifier_unsigned_immediate'.
>>(CDP_QUALIFIERS): Define to...
>>(arm_cdp_qualifiers): ... this. New.
>>(void_UP): Define.
>>(arm_expand_builtin_args): Add case for 6 arguments.
>>* config/arm/arm-protos.h (neon_const_bounds): Rename this ...
>>(arm_const_bounds): ... this.
>>(arm_coproc_builtin_available): New.
>>* config/arm/arm_acle.h (__arm_cdp): New.
>>(__arm_cdp2): New.
>>* config/arm/arm_acle_builtins.def (cdp): New.
>>(cdp2): New.
>>* config/arm/iterators.md (CDPI,CDP,cdp): New.
>>* config/arm/neon.md: Rename all 'neon_const_bounds' to
>>'arm_const_bounds'.
>>* config/arm/types.md (coproc): New.
>>* config/arm/unspecs.md (VUNSPEC_CDP, VUNSPEC_CDP2): New.
>>* gcc/doc/extend.texi (ACLE): Add a mention of Coprocessor intrinsics.
>>
>> gcc/testsuite/ChangeLog:
>> 2016-11-09  Andre Vieira  
>>
>>* gcc.target/arm/acle/acle.exp: Run tests for different options
>>and make sure fat-lto-objects is used such that we can still do
>>assemble scans.
>>* gcc.target/arm/acle/cdp.c: New.
>>* gcc.target/arm/acle/cdp2.c: New.
>>* lib/target-supports.exp (check_effective_target_arm_coproc1_ok):
>> New.
>>(check_effective_target_arm_coproc1_ok_nocache): New.
>>(check_effective_target_arm_coproc2_ok): New.
>>(check_effective_target_arm_coproc2_ok_nocache): New.
>>(check_effective_target_arm_coproc3_ok): New.
>>(check_effective_target_arm_coproc3_ok_nocache): New.
> 
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -1675,6 +1675,21 @@ and @code{MOVT} instructions available.
>  ARM target generates Thumb-1 code for @code{-mthumb} with
>  @code{CBZ} and @code{CBNZ} instructions available.
>  
> +@item arm_coproc1_ok
> +@anchor{arm_coproc1_ok}
> +ARM target supports the following coprocessor instruction: @code{CDP},
> +@code{LDC}, @code{STC}, @code{MCR} and @code{MRC}.
> 
> 
> s/instruction/instructions/
> 
> 
> +@item arm_coproc2_ok
> +@anchor{arm_coproc2_ok}
> +ARM target supports the all the coprocessor instructions also listed as
> +supported in @ref{arm_coproc1_ok} and the following: @code{CDP2},
> @code{LDC2},
> +@code{LDC2l}, @code{STC2}, @code{STC2l}, @code{MCR2} and @code{MRC2}.
> +
> 
> s/the all the/all the/.
> Also, I'd prefer to say "in addition to the following" rather than "and
> the following"
> 
>  +@item arm_coproc3_ok
> +ARM target supports the all the coprocessor instructions also listed as
> +supported in @ref{arm_coproc2_ok} and the following: @code{MCRR},
> @code{MCRR2},
> +@code{MRRC}, and @code{MRRC2}.
> 
> Likewise.
> 
Hi,

I reworked this patch after comments, rebased and noticed I had grouped
MCRR/MRRC and MCRR2/MRRC2 together, the first two are supported in
ARMv5TE but 

Re: [PATCH 4/6][ARM] Implement support for ACLE Coprocessor LDC and STC intrinsics

[Andre Vieira (lists)]

On 05/01/17 11:02, Kyrill Tkachov wrote:
> Hi Andre,
> 
> On 09/11/16 10:12, Andre Vieira (lists) wrote:
>> Hi,
>>
>> This patch implements support for the ARM ACLE Coprocessor LDC and STC
>> intrinsics. See below a table mapping the intrinsics to their respective
>> instructions:
>>
>> ++--+
>>
>> | Intrinsic signature| Instruction
>> pattern  |
>> ++--+
>>
>> |void __arm_ldc(coproc, CRd, const void* p)  |LDC coproc, CRd,
>> [...]|
>> ++--+
>>
>> |void __arm_ldcl(coproc, CRd, const void* p) |LDCL coproc, CRd,
>> [...]   |
>> ++--+
>>
>> |void __arm_ldc2(coproc, CRd, const void* p) |LDC2 coproc, CRd,
>> [...]   |
>> ++--+
>>
>> |void __arm_ldc2l(coproc, CRd, const void* p)|LDC2L coproc, CRd,
>> [...]  |
>> ++--+
>>
>> |void __arm_stc(coproc, CRd, void* p)|STC coproc, CRd,
>> [...]|
>> ++--+
>>
>> |void __arm_stcl(coproc, CRd, void* p)   |STCL coproc, CRd,
>> [...]   |
>> ++--+
>>
>> |void __arm_stc2(coproc, CRd, void* p)   |STC2 coproc, CRd,
>> [...]   |
>> ++--+
>>
>> |void __arm_stc2l(coproc, CRd, void* p)  |STC2L coproc, CRd,
>> [...]  |
>> ++--+
>>
>> Note that any untyped variable in the intrinsic signature is required to
>> be a compiler-time constant and has the type 'unsigned int'.  We do some
>> boundary checks for coproc:[0-15], CR*:[0-31]. If either of these
>> requirements are not met a diagnostic is issued.
>>
>>
>> Is this ok for trunk?
> 
> I have a few comments below...
> 
>> Regards,
>> Andre
>>
>> gcc/ChangeLog:
>> 2016-11-09  Andre Vieira  
>>
>>* config/arm/arm.md (*ldcstc): New.
>>(): New.
>>* config/arm/arm.c (arm_coproc_builtin_available): Add
>>support for ldc,ldcl,stc,stcl,ldc2,ldc2l,stc2 and stc2l.
>>(arm_coproc_ldc_stc_legitimate_address): New.
>>* config/arm/arm-builtins.c (arm_type_qualifiers): Add
>>'qualifier_const_pointer'.
>>(LDC_QUALIFIERS): Define to...
>>(arm_ldc_qualifiers): ... this. New.
>>(STC_QUALIFIERS): Define to...
>>(arm_stc_qualifiers): ... this. New.
>>* config/arm/arm-protos.h
>>(arm_coproc_ldc_stc_legitimate_address): New.
>>* config/arm/arm_acle.h (__arm_ldc, __arm_ldcl, __arm_stc,
>>__arm_stcl, __arm_ldc2, __arm_ldc2l, __arm_stc2, __arm_stc2l): New.
>>* config/arm/arm_acle_builtins.def (ldc, ldc2, ldcl, ldc2l, stc,
>>stc2, stcl, stc2l): New.
>>* config/arm/constraints.md (Uz): New.
>>* config/arm/iterators.md (LDCSTCI, ldcstc, LDCSTC): New.
>>* config/arm/unspecs.md (VUNSPEC_LDC, VUNSPEC_LDC2, VUNSPEC_LDCL,
>>VUNSPEC_LDC2L, VUNSPEC_STC, VUNSPEC_STC2, VUNSPEC_STCL,
>>VUNSPEC_STC2L): New.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2016-11-09  Andre Vieira  
>>
>>* gcc.target/arm/acle/ldc: New.
>>* gcc.target/arm/acle/ldc2: New.
>>* gcc.target/arm/acle/ldcl: New.
>>* gcc.target/arm/acle/ldc2l: New.
>>* gcc.target/arm/acle/stc: New.
>>* gcc.target/arm/acle/stc2: New.
>>* gcc.target/arm/acle/stcl: New.
>>* gcc.target/arm/acle/stc2l: New.
> 
> +  /* const T * foo */
> +  qualifier_const_pointer = 0x6,
> 
> Nit: full stop at end of comment.
> 
> +
> +/* This function returns true if OP is a valid memory operand for the
> ldc and
> +   stc coprocessor instructions and false otherwise.  */
> +
> +bool arm_coproc_ldc_stc_legitimate_address (rtx op)
> +{
> 
> type and function name should be on separate lines.
> 
> +  int range;
> +  /* Has to be a memory operand.  */
> +  if (!MEM_P (op))
> +return false;
> 
> +  /* Within the range of [-1020,1020].  */
> +  if (range < -1020 || range > 1020)
> +return false;
> 
> Use !IN_RANGE (-1020, 1020), also make 'range' a HOST_WIDE_INT (that is
> what INTVAL returns).
> 
> --- a/gcc/config/arm/arm.md
> +++ b/gcc/config/arm/arm.md
> @@ -11858,6 +11858,25 @@
>[(set_attr "length" "4")
> (set_attr "type" "coproc")])
>  
> +(define_insn "*ldcstc"
> +  [(unspec_volatile [(match_operand:SI 0 "immedi

Re: [PATCH 5/6][ARM] Implement support for ACLE Coprocessor MCR and MRC intrinsics

[Andre Vieira (lists)]

On 05/01/17 11:08, Kyrill Tkachov wrote:
> 
> On 09/11/16 10:12, Andre Vieira (lists) wrote:
>> Hi,
>>
>> This patch implements support for the ARM ACLE Coprocessor MCR and MRC
>> intrinsics. See below a table mapping the intrinsics to their respective
>> instructions:
>>
>> +---+---+
>>
>> | Intrinsic signature   |
>> Instruction pattern   |
>> +---+---+
>>
>> |void __arm_mcr(coproc, opc1, uint32_t value, CRn, CRm, opc2)   |
>> MCR coproc, opc1, Rt, CRn, CRm, opc2  |
>> +---+---+
>>
>> |void __arm_mcr2(coproc, opc1, uint32_t value, CRn, CRm, opc2)  |
>> MCR2 coproc, opc1, Rt, CRn, CRm, opc2 |
>> +---+---+
>>
>> |uint32_t __arm_mrc(coproc, opc1, CRn, CRm, opc2)   |
>> MRC coproc, opc1, Rt, CRn, CRm, opc2  |
>> +---+---+
>>
>> |uint32_t __arm_mrc2(coproc, opc1, CRn, CRm, opc2)  |
>> MRC2 coproc, opc1, Rt, CRn, CRm, opc2 |
>> +---+---+
>>
>> Note that any untyped variable in the intrinsic signature is required to
>> be a compiler-time constant and has the type 'unsigned int'.  We do some
>> boundary checks for coproc:[0-15], opc1[0-7] CR*:[0-31],opc2:[0-7].  If
>> either of these requirements are not met a diagnostic is issued.
>>
>> Is this OK for trunk?
>>
>> Regards,
>> Andre
>>
>> gcc/ChangeLog:
>> 2016-11-09  Andre Vieira  
>>
>>* config/arm/arm.md (): New.
>>(): New.
>>* config/arm/arm.c (arm_coproc_builtin_available): Add
>>support for mcr, mrc, mcr2 and mrc2.
>>* config/arm/arm-builtins.c (MCR_QUALIFIERS): Define to...
>>(arm_mcr_qualifiers): ... this. New.
>>(MRC_QUALIFIERS): Define to ...
>>(arm_mrc_qualifiers): ... this. New.
>>(MCR_QUALIFIERS): Define to ...
>>(arm_mcr_qualifiers): ... this. New.
>>* config/arm/arm_acle.h (__arm_mcr, __arm_mrc, __arm_mcr2,
>>__arm_mrc2): New.
>>* config/arm/arm_acle_builtins.def (mcr, mcr2, mrc, mrc2): New.
>>* config/arm/iterators.md (MCRI, mcr, MCR, MRCI, mrc, MRC): New.
>>* config/arm/unspecs.md (VUNSPEC_MCR, VUNSPEC_MCR2, VUNSPEC_MRC,
>>VUNSPEC_MRC2): New.
>>
>>
>> gcc/ChangeLog:
>> 2016-11-09  Andre Vieira  
>>
>>* gcc.target/arm/acle/mcr.c: New.
>>* gcc.target/arm/acle/mrc.c: New.
>>* gcc.target/arm/acle/mcr2.c: New.
>>* gcc.target/arm/acle/mrc2.c: New.
> 
> +(define_insn ""
> +  [(unspec_volatile [(match_operand:SI 0 "immediate_operand")
> + (match_operand:SI 1 "immediate_operand")
> + (match_operand:SI 2 "s_register_operand")
> + (match_operand:SI 3 "immediate_operand")
> + (match_operand:SI 4 "immediate_operand")
> + (match_operand:SI 5 "immediate_operand")] MCRI)
> +   (use (match_dup 2))]
> +  "arm_coproc_builtin_available (VUNSPEC_)"
> +{
> +  arm_const_bounds (operands[0], 0, 16);
> +  arm_const_bounds (operands[1], 0, 8);
> +  arm_const_bounds (operands[3], 0, (1 << 5));
> +  arm_const_bounds (operands[4], 0, (1 << 5));
> +  arm_const_bounds (operands[5], 0, 8);
> +  return "\\tp%c0, %1, %2, CR%c3, CR%c4, %5";
> +}
> +  [(set_attr "length" "4")
> +   (set_attr "type" "coproc")])
> +
> +(define_insn ""
> +  [(set (match_operand:SI 0 "s_register_operand")
> +(unspec_volatile [(match_operand:SI 1 "immediate_operand")
> +  (match_operand:SI 2 "immediate_operand")
> +  (match_operand:SI 3 "immediate_operand")
> +  (match_operand:SI 4 "immediate_operand")
> +  (match_operand:SI 5 "immediate_operand")] MRCI))]
> +  "arm_coproc_builtin_available (VUNSPEC_)"
> +{
> +  arm_const_bounds (operands[1], 0, 16);
> +  arm_const_bounds (operands[2], 0, 8);
> +  arm_const_bounds (operands[3], 0, (1 << 5));
> +  arm_const_bounds (operands[4], 0, (1 << 5));
> +  arm_const_bounds (operands[5], 0, 8);
> +  return "\\tp%c1, %2, %0, CR%c3, CR%c4, %5";
> +}
> +  [(set_attr "length" "4")
> +   (set_attr "type" "coproc")])
> 
> Same as the previous patch, these operands need constraints.
> The MRC ones in particular need a '=' in their constraint string.
Hi,

Reworked comments and rebased.

Is this OK for trunk?

Regards,
Andre

gcc/ChangeLog:
2017-01-xx  Andre Vieira  

  * config/arm/arm.md (): New.
  (): New.
  * config/arm/arm.c (arm_coproc_builtin_available): Add
  support for mcr, mrc, mcr2 and mrc2.
  * config/arm/arm-builtins.c (MCR_QUALIFIERS): Define to...
  (arm_mcr_qualifiers): ... this. N

Re: [build, libgo, libstdc++] Build libgo with -Wa,-nH if possible (PR go/78978)

[Rainer Orth]

Hi Ian,

> On Thu, Jan 5, 2017 at 1:20 AM, Rainer Orth  
> wrote:
>> As could have been expected, the static libgo.a causes the same problem
>> with hardware capabilities on Solaris/x86 as was solved for libgo.so
>> with
>>
>> https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00726.html
>>
>> Instead of trying to pass -mclear-hwcap with -static-libgo, it was
>> deemed easier to solve both problems the same way and disable hwcaps
>> support in the assembler in the first place.
>>
>> This has already been done in libstdc++, so I've moved the corresponding
>> autoconf macro to config/hwcaps.m4 and adapted it to set HWCAP_CFLAGS
>> instead of HWCAP_FLAGS to better differntiate from HWCAP_LDFLAGS.
>> Everything else is straightforward, I believe.
>>
>> Bootstrapped without regressions on i386-pc-solaris2.1[02] with as/ld
>> (where as supports -nH) and sparc-sun-solaris2.12 with as/ld (where as
>> doesn't, or rather it's called -hwcap={1|0}), and the libgo
>> runtime/pprof failure is gone.
>>
>> Ok for mainline?
>>
>> Once approved, how should we proceed with checking?  Ian, will you take
>> care of the libgo part once the rest is in?
>
> This patch is OK.  Yes, please commit the config and libstdc++
> portions.  Then I will commit the libgo portions to the external repo
> and mirror them in.  Thanks.

done, thanks.  While preparing the partial commit, I noticed that I'd
created the libgo part of the patch on top of a tree that contained a
workaround for PR go/64900.

Here's the libgo part again, this time on top of a vanilla tree.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


diff --git a/libgo/Makefile.am b/libgo/Makefile.am
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -42,14 +42,12 @@ ACLOCAL_AMFLAGS = -I ./config -I ../conf
 
 AM_CFLAGS = -fexceptions -fnon-call-exceptions -fplan9-extensions \
 	$(SPLIT_STACK) $(WARN_CFLAGS) \
-	$(STRINGOPS_FLAG) $(OSCFLAGS) \
+	$(STRINGOPS_FLAG) $(HWCAP_CFLAGS) $(OSCFLAGS) \
 	-I $(srcdir)/../libgcc -I $(srcdir)/../libbacktrace \
 	-I $(MULTIBUILDTOP)../../gcc/include
 
-AM_LDFLAGS = $(HWCAP_LDFLAGS)
-
 if USING_SPLIT_STACK
-AM_LDFLAGS += -XCClinker $(SPLIT_STACK)
+AM_LDFLAGS = -XCClinker $(SPLIT_STACK)
 endif
 
 # Multilib support.
diff --git a/libgo/configure.ac b/libgo/configure.ac
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -421,8 +421,8 @@ case "$target" in
 esac
 AC_SUBST(OSCFLAGS)
 
-dnl Check linker hardware capability support.
-GCC_CHECK_LINKER_HWCAP
+dnl Check if assembler supports disabling hardware capability support.
+GCC_CHECK_ASSEMBLER_HWCAP
 
 dnl Use -fsplit-stack when compiling C code if available.
 AC_CACHE_CHECK([whether -fsplit-stack is supported],

RE: [PATCH] improve string find algorithm

[Aditya Kumar]

Yes, we do.
Sorry for the mistake, it happened because I first wrote this for
libcxx (https://reviews.llvm.org/D27068) and while porting that line
got missed.

Thanks,
-Aditya


diff --git a/libstdc++-v3/include/bits/basic_string.tcc
b/libstdc++-v3/include/bits/basic_string.tcc
index df1e8dd..7942ee6 100644
--- a/libstdc++-v3/include/bits/basic_string.tcc
+++ b/libstdc++-v3/include/bits/basic_string.tcc
@@ -1194,14 +1194,29 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   if (__n == 0)
 return __pos <= __size ? __pos : npos;
 
-  if (__n <= __size)
-   {
- for (; __pos <= __size - __n; ++__pos)
-   if (traits_type::eq(__data[__pos], __s[0])
-   && traits_type::compare(__data + __pos + 1,
-   __s + 1, __n - 1) == 0)
- return __pos;
-   }
+  if (__n > __size)
+   return npos;
+
+  const _CharT __elem0 = __s[0];
+  const _CharT* __first1 = __data;
+  const _CharT* __first2 = __s;
+  const _CharT* __last1 = __data + __size;
+  ptrdiff_t __len2 = __n -  __pos;
+
+  while (true) {
+ptrdiff_t __len1 = __last1 - __first1;
+   if (__len1 < __len2)
+ return npos;
+
+   // Find the first match.
+   __first1 = traits_type::find(__first1, __len1 - __len2 + 1,
__elem0);
+   if (__first1 == 0)
+ return npos;
+   // Compare the full string when first match is found.
+if (traits_type::compare(__first1, __first2, __len2) == 0)
+  return __first1 - __data;
+
+++__first1;
+  }
+
   return npos;
 }
 
-- 
2.6.3




-Original Message-
From: Jonathan Wakely [mailto:jwak...@redhat.com] 
Sent: Friday, January 06, 2017 7:35 AM
To: Aditya Kumar
Cc: libstd...@gcc.gnu.org; gcc-patches@gcc.gnu.org; hiradi...@msn.com
Subject: Re: [PATCH] improve string find algorithm

On 07/12/16 11:46 -0600, Aditya Kumar wrote:
>Here is an improved version of basic_string::find. The idea is to
>split the string find in two parts:
>1. search for the first match by using traits_type::find (this gets
converted to memchr for x86)
>2. see if there is a match (this gets converted to memcmp for x86)
>
>Passes bootstrap on x86-64.
>
>The patch results in good improvements on a synthetic test case I
wrote using the google-benchmark.
>following are the results.
>
>
>Branch: master without patch
>$ ./bin/string.libcxx.out
>Run on (24 X 1899.12 MHz CPU s)
>2016-12-06 16:41:55
>***WARNING*** CPU scaling is enabled, the benchmark real time
measurements may be noisy and will incur extra overhead.
>Benchmark   Time   CPU Iterations
>-
>BM_StringFindNoMatch/10 8 ns  8 ns   81880927
>BM_StringFindNoMatch/6452 ns 52 ns   13235018
>BM_StringFindNoMatch/512  355 ns355 ns1962488
>BM_StringFindNoMatch/4k  2769 ns   2772 ns 249090
>BM_StringFindNoMatch/32k22598 ns  22619 ns  30984
>BM_StringFindNoMatch/128k   89745 ns  89830 ns   7996
>BM_StringFindAllMatch/1 7 ns  7 ns  102893835
>BM_StringFindAllMatch/8 9 ns  9 ns   75403364
>BM_StringFindAllMatch/64   12 ns 12 ns   60766893
>BM_StringFindAllMatch/512  31 ns 31 ns   23163999
>BM_StringFindAllMatch/4k  141 ns141 ns4980386
>BM_StringFindAllMatch/32k1402 ns   1403 ns 483581
>BM_StringFindAllMatch/128k   5604 ns   5609 ns 126123
>BM_StringFindMatch1/1   44430 ns  44473 ns  15804
>BM_StringFindMatch1/8   44315 ns  44357 ns  15741
>BM_StringFindMatch1/64  44689 ns  44731 ns  15712
>BM_StringFindMatch1/512 44247 ns  44290 ns  15724
>BM_StringFindMatch1/4k  45010 ns  45053 ns  15678
>BM_StringFindMatch1/32k 45717 ns  45761 ns  15278
>BM_StringFindMatch2/1   44307 ns  44349 ns  15730
>BM_StringFindMatch2/8   44631 ns  44674 ns  15721
>BM_StringFindMatch2/64  44300 ns  44342 ns  15750
>BM_StringFindMatch2/512 44239 ns  44281 ns  15713
>BM_StringFindMatch2/4k  44886 ns  44928 ns  15787
>
>Branch: master with patch
>$ ./bin/string.libcxx.out
>Run on (24 X 2892.28 MHz CPU s)
>2016-12-06 18:51:38
>***WARNING*** CPU scaling is enabled, the benchmark real time
measurements may be noisy and will incur extra overhead.
>Benchmark   Time   CPU Iterations
>-
>BM_StringFindNoMatch/1011 ns 11 ns   63049677
>BM_StringFindNoMatch/6412 ns 12 ns   57259381
>BM_StringFindNoMatch/512   27 ns 27 ns   25495432
>BM_StringFindNoMatch/4k   130 ns130 ns5301301
>BM_StringFindNoMatch/32k  858

Re: [PATCH 6/6][ARM] Implement support for ACLE Coprocessor MCRR and MRRC intrinsics

[Andre Vieira (lists)]

On 05/01/17 11:11, Kyrill Tkachov wrote:
> Hi Andre,
> 
> On 09/11/16 10:12, Andre Vieira (lists) wrote:
>> Hi,
>>
>> This patch implements support for the ARM ACLE Coprocessor MCR and MRC
>> intrinsics. See below a table mapping the intrinsics to their respective
>> instructions:
>>
>> +---+---+
>>
>> | Intrinsic signature   |
>> Instruction pattern   |
>> +---+---+
>>
>> |void __arm_mcrr(coproc, opc1, uint64_t value, CRm) |
>> MCRR coproc, opc1, Rt, Rt2, CRm   |
>> +---+---+
>>
>> |void __arm_mcrr2(coproc, opc1, uint64_t value, CRm)|
>> MCRR2 coproc, opc1, Rt, Rt2, CRm  |
>> +---+---+
>>
>> |uint64_t __arm_mrrc(coproc, opc1, CRm) |
>> MRRC coproc, opc1, Rt, Rt2, CRm   |
>> +---+---+
>>
>> |uint64_t __arm_mrrc2(coproc, opc1, CRm)|
>> MRRC2 coproc, opc1, Rt, Rt2, CRm  |
>> +---+---+
>>
>> Note that any untyped variable in the intrinsic signature is required to
>> be a compiler-time constant and has the type 'unsigned int'.  We do some
>> boundary checks for coproc:[0-15], opc1[0-7] CR*:[0-31]. If either of
>> these requirements are not met a diagnostic is issued.
>>
>> I added a new arm_arch variable for ARMv5TE to use when deciding whether
>> or not the MCRR and MRCC intrinsics are available.
>>
>> Is this OK for trunk?
> 
> Same as with the previous two patches the define_insns need constraints
> and also I believe you'll want to rebase this patch on top of Richard's
> rework of the
> architecture feature bits for the ARMv5TE hunk.
> 
> Thanks,
> Kyrill
> 
>> Regards,
>> Andre
>>
>> gcc/ChangeLog:
>> 2016-11-09  Andre Vieira  
>>
>>* config/arm/arm.md (): New.
>>(): New.
>>* config/arm/arm.c (arm_arch5te): New.
>>(arm_option_override): Set arm_arch5te.
>>(arm_coproc_builtin_available): Add support for mcrr, mcrr2, mrrc
>>and mrrc2.
>>* config/arm/arm-builtins.c (MCRR_QUALIFIERS): Define to...
>>(arm_mcrr_qualifiers): ... this. New.
>>(MRRC_QUALIFIERS): Define to...
>>(arm_mrrc_qualifiers): ... this. New.
>>* config/arm/arm_acle.h (__arm_mcrr, __arm_mcrr2, __arm_mrrc,
>>__arm_mrrc2): New.
>>* config/arm/arm_acle_builtins.def (mcrr, mcrr2, mrrc, mrrc2): New.
>>* config/arm/iterators.md (MCRRI, mcrr, MCRR): New.
>>(MRRCI, mrrc, MRRC): New.
>>* config/arm/unspecs.md (VUNSPEC_MCRR, VUNSPEC_MCRR2, VUNSPEC_MRRC,
>>VUNSPEC_MRRC2): New.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2016-11-09  Andre Vieira  
>>
>>* gcc.target/arm/acle/mcrr: New.
>>* gcc.target/arm/acle/mcrr2: New.
>>* gcc.target/arm/acle/mrrc: New.
>>* gcc.target/arm/acle/mrrc2: New.
>>
> 
Hi,

Reworked this patch according to comments, rebased and fixed the
availability of MCRR2/MRRC2 to only be available for ARMv6 and later.

Is this OK for trunk?

Regards,
Andre

gcc/ChangeLog:
2017-01-xx  Andre Vieira  

  * config/arm/arm.md (): New.
  (): New.
  * config/arm/arm.c (arm_arch5te): New.
  (arm_option_override): Set arm_arch5te.
  (arm_coproc_builtin_available): Add support for mcrr, mcrr2, mrrc
  and mrrc2.
  * config/arm/arm-builtins.c (MCRR_QUALIFIERS): Define to...
  (arm_mcrr_qualifiers): ... this. New.
  (MRRC_QUALIFIERS): Define to...
  (arm_mrrc_qualifiers): ... this. New.
  * config/arm/arm_acle.h (__arm_mcrr, __arm_mcrr2, __arm_mrrc,
  __arm_mrrc2): New.
  * config/arm/arm_acle_builtins.def (mcrr, mcrr2, mrrc, mrrc2): New.
  * config/arm/iterators.md (MCRRI, mcrr, MCRR): New.
  (MRRCI, mrrc, MRRC): New.
  * config/arm/unspecs.md (VUNSPEC_MCRR, VUNSPEC_MCRR2, VUNSPEC_MRRC,
  VUNSPEC_MRRC2): New.

gcc/testsuite/ChangeLog:

2017-01-xx  Andre Vieira  

  * gcc.target/arm/acle/mcrr: New.
  * gcc.target/arm/acle/mcrr2: New.
  * gcc.target/arm/acle/mrrc: New.
  * gcc.target/arm/acle/mrrc2: New.
diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index 
1a983b27961e96cfab651244af3ba1fb44b87d2e..689219c1923bc0f720f70870bfde8b60f7514167
 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -217,6 +217,24 @@ arm_mrc_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   qualifier_unsigned_immediate, qualifier_unsigned_immediate };
 #define MRC_QUALIFIERS \
   (arm_mrc_qualifiers)
+
+/* void (unsigned immediate, unsigned immediate,  T, unsigned immediate).  */
+static enum arm_type_qual

Re: [PATCH] improve string find algorithm

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 08:42:15AM -0600, Aditya Kumar wrote:
> Yes, we do.
> Sorry for the mistake, it happened because I first wrote this for
> libcxx (https://reviews.llvm.org/D27068) and while porting that line
> got missed.

Shouldn't find at least in the case where it is narrow char string
just use C library memmem?  That implements a Two-Way searching algorithm
with some improvements from Boyer-Moore.
Otherwise, consider what even your modified version will do for

#include 
int main() {
 (std::string(1000, 'a')+"b").find(std::string(100, 'a')+"b");
}

Or does the C++ library need to reinvent everything implemented in the C
library?

Jakub

Re: [PATCH] improve string find algorithm

[Jonathan Wakely]

On 06/01/17 16:09 +0100, Jakub Jelinek wrote:

On Fri, Jan 06, 2017 at 08:42:15AM -0600, Aditya Kumar wrote:

Yes, we do.
Sorry for the mistake, it happened because I first wrote this for
libcxx (https://reviews.llvm.org/D27068) and while porting that line
got missed.


Shouldn't find at least in the case where it is narrow char string
just use C library memmem?  That implements a Two-Way searching algorithm
with some improvements from Boyer-Moore.
Otherwise, consider what even your modified version will do for

#include 
int main() {
(std::string(1000, 'a')+"b").find(std::string(100, 'a')+"b");
}


Yes, I have an incomplete local patch that checks for memmem and uses
it where possible. This change would still be valuable for non-GNU
targets though.


Or does the C++ library need to reinvent everything implemented in the C
library?


In this case yes, because strstr doesn't take the length of the
strings into account, and memmem isn't standard. Because std::string
knows its length we can do better than strstr for some cases, such as
std::string(1000, 'a').find(std::string(1001, 'a')).

Re: [PATCH 3/6][ARM] Implement support for ACLE Coprocessor CDP intrinsics

[Kyrill Tkachov]

On 06/01/17 14:17, Andre Vieira (lists) wrote:

On 05/01/17 10:44, Kyrill Tkachov wrote:

Hi Andre,

On 09/11/16 10:11, Andre Vieira (lists) wrote:

Hi,

This patch implements support for the ARM ACLE Coprocessor CDP
intrinsics. See below a table mapping the intrinsics to their respective
instructions:

++--+

| Intrinsic signature| Instruction
pattern  |
++--+

|void __arm_cdp(coproc, opc1, CRd, CRn, CRm, opc2)   |CDP coproc, opc1,
CRd, CRn, CRm, opc2 |
++--+

|void __arm_cdp2(coproc, opc1, CRd, CRn, CRm, opc2)  |CDP2 coproc, opc1,
CRd, CRn, CRm, opc2|
++--+

Note that any untyped variable in the intrinsic signature is required to
be a compiler-time constant and has the type 'unsigned int'.  We do some
boundary checks for coproc:[0-15], opc1:[0-15], CR*:[0-31], opc2:[0-7].
If either of these requirements are not met a diagnostic is issued.

I renamed neon_const_bounds in this patch, to arm_const_bounds, simply
because it is also used in the Coprocessor intrinsics.  It also requires
the expansion of the builtin frame work such that it accepted 'void'
modes and intrinsics with 6 arguments.

I also changed acle.exp to run tests for multiple options, where all lto
option sets are appended with -ffat-objects to allow for assembly scans.

Is this OK for trunk?

This is okay if bootstrap and testing is ok (as part of the whole series)
modulo a couple of nits in the documentation below.

Thanks,
Kyrill


Regards,
Andre

gcc/ChangeLog:
2016-11-09  Andre Vieira  

* config/arm/arm.md (): New.
* config/arm/arm.c (neon_const_bounds): Rename this ...
(arm_const_bounds): ... this.
(arm_coproc_builtin_available): New.
* config/arm/arm-builtins.c (SIMD_MAX_BUILTIN_ARGS): Increase.
(arm_type_qualifiers): Add 'qualifier_unsigned_immediate'.
(CDP_QUALIFIERS): Define to...
(arm_cdp_qualifiers): ... this. New.
(void_UP): Define.
(arm_expand_builtin_args): Add case for 6 arguments.
* config/arm/arm-protos.h (neon_const_bounds): Rename this ...
(arm_const_bounds): ... this.
(arm_coproc_builtin_available): New.
* config/arm/arm_acle.h (__arm_cdp): New.
(__arm_cdp2): New.
* config/arm/arm_acle_builtins.def (cdp): New.
(cdp2): New.
* config/arm/iterators.md (CDPI,CDP,cdp): New.
* config/arm/neon.md: Rename all 'neon_const_bounds' to
'arm_const_bounds'.
* config/arm/types.md (coproc): New.
* config/arm/unspecs.md (VUNSPEC_CDP, VUNSPEC_CDP2): New.
* gcc/doc/extend.texi (ACLE): Add a mention of Coprocessor intrinsics.

gcc/testsuite/ChangeLog:
2016-11-09  Andre Vieira  

* gcc.target/arm/acle/acle.exp: Run tests for different options
and make sure fat-lto-objects is used such that we can still do
assemble scans.
* gcc.target/arm/acle/cdp.c: New.
* gcc.target/arm/acle/cdp2.c: New.
* lib/target-supports.exp (check_effective_target_arm_coproc1_ok):
New.
(check_effective_target_arm_coproc1_ok_nocache): New.
(check_effective_target_arm_coproc2_ok): New.
(check_effective_target_arm_coproc2_ok_nocache): New.
(check_effective_target_arm_coproc3_ok): New.
(check_effective_target_arm_coproc3_ok_nocache): New.

--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1675,6 +1675,21 @@ and @code{MOVT} instructions available.
  ARM target generates Thumb-1 code for @code{-mthumb} with
  @code{CBZ} and @code{CBNZ} instructions available.
  
+@item arm_coproc1_ok

+@anchor{arm_coproc1_ok}
+ARM target supports the following coprocessor instruction: @code{CDP},
+@code{LDC}, @code{STC}, @code{MCR} and @code{MRC}.


s/instruction/instructions/


+@item arm_coproc2_ok
+@anchor{arm_coproc2_ok}
+ARM target supports the all the coprocessor instructions also listed as
+supported in @ref{arm_coproc1_ok} and the following: @code{CDP2},
@code{LDC2},
+@code{LDC2l}, @code{STC2}, @code{STC2l}, @code{MCR2} and @code{MRC2}.
+

s/the all the/all the/.
Also, I'd prefer to say "in addition to the following" rather than "and
the following"

  +@item arm_coproc3_ok
+ARM target supports the all the coprocessor instructions also listed as
+supported in @ref{arm_coproc2_ok} and the following: @code{MCRR},
@code{MCRR2},
+@code{MRRC}, and @code{MRRC2}.

Likewise.


Hi,

I reworked this patch after comments, rebased and noticed I had grouped
MCRR/MRRC and MCRR2/MRRC2 together, the first two are supported in
ARMv5TE but the latter only in ARMv6 and onwards.  So I fixed the
testsuite checks in this patch and the generation in the latter patch.

I ran the patch series through a bootstrap and full regression on
arm-none-linux-gnueabihf.

Is t

Re: [PATCH 6/6][ARM] Implement support for ACLE Coprocessor MCRR and MRRC intrinsics

[Kyrill Tkachov]

On 06/01/17 14:58, Andre Vieira (lists) wrote:

On 05/01/17 11:11, Kyrill Tkachov wrote:

Hi Andre,

On 09/11/16 10:12, Andre Vieira (lists) wrote:

Hi,

This patch implements support for the ARM ACLE Coprocessor MCR and MRC
intrinsics. See below a table mapping the intrinsics to their respective
instructions:

+---+---+

| Intrinsic signature   |
Instruction pattern   |
+---+---+

|void __arm_mcrr(coproc, opc1, uint64_t value, CRm) |
MCRR coproc, opc1, Rt, Rt2, CRm   |
+---+---+

|void __arm_mcrr2(coproc, opc1, uint64_t value, CRm)|
MCRR2 coproc, opc1, Rt, Rt2, CRm  |
+---+---+

|uint64_t __arm_mrrc(coproc, opc1, CRm) |
MRRC coproc, opc1, Rt, Rt2, CRm   |
+---+---+

|uint64_t __arm_mrrc2(coproc, opc1, CRm)|
MRRC2 coproc, opc1, Rt, Rt2, CRm  |
+---+---+

Note that any untyped variable in the intrinsic signature is required to
be a compiler-time constant and has the type 'unsigned int'.  We do some
boundary checks for coproc:[0-15], opc1[0-7] CR*:[0-31]. If either of
these requirements are not met a diagnostic is issued.

I added a new arm_arch variable for ARMv5TE to use when deciding whether
or not the MCRR and MRCC intrinsics are available.

Is this OK for trunk?

Same as with the previous two patches the define_insns need constraints
and also I believe you'll want to rebase this patch on top of Richard's
rework of the
architecture feature bits for the ARMv5TE hunk.

Thanks,
Kyrill


Regards,
Andre

gcc/ChangeLog:
2016-11-09  Andre Vieira  

* config/arm/arm.md (): New.
(): New.
* config/arm/arm.c (arm_arch5te): New.
(arm_option_override): Set arm_arch5te.
(arm_coproc_builtin_available): Add support for mcrr, mcrr2, mrrc
and mrrc2.
* config/arm/arm-builtins.c (MCRR_QUALIFIERS): Define to...
(arm_mcrr_qualifiers): ... this. New.
(MRRC_QUALIFIERS): Define to...
(arm_mrrc_qualifiers): ... this. New.
* config/arm/arm_acle.h (__arm_mcrr, __arm_mcrr2, __arm_mrrc,
__arm_mrrc2): New.
* config/arm/arm_acle_builtins.def (mcrr, mcrr2, mrrc, mrrc2): New.
* config/arm/iterators.md (MCRRI, mcrr, MCRR): New.
(MRRCI, mrrc, MRRC): New.
* config/arm/unspecs.md (VUNSPEC_MCRR, VUNSPEC_MCRR2, VUNSPEC_MRRC,
VUNSPEC_MRRC2): New.

gcc/testsuite/ChangeLog:

2016-11-09  Andre Vieira  

* gcc.target/arm/acle/mcrr: New.
* gcc.target/arm/acle/mcrr2: New.
* gcc.target/arm/acle/mrrc: New.
* gcc.target/arm/acle/mrrc2: New.


Hi,

Reworked this patch according to comments, rebased and fixed the
availability of MCRR2/MRRC2 to only be available for ARMv6 and later.

Is this OK for trunk?


Ok.
Thanks,
Kyrill


Regards,
Andre

gcc/ChangeLog:
2017-01-xx  Andre Vieira  

   * config/arm/arm.md (): New.
   (): New.
   * config/arm/arm.c (arm_arch5te): New.
   (arm_option_override): Set arm_arch5te.
   (arm_coproc_builtin_available): Add support for mcrr, mcrr2, mrrc
   and mrrc2.
   * config/arm/arm-builtins.c (MCRR_QUALIFIERS): Define to...
   (arm_mcrr_qualifiers): ... this. New.
   (MRRC_QUALIFIERS): Define to...
   (arm_mrrc_qualifiers): ... this. New.
   * config/arm/arm_acle.h (__arm_mcrr, __arm_mcrr2, __arm_mrrc,
   __arm_mrrc2): New.
   * config/arm/arm_acle_builtins.def (mcrr, mcrr2, mrrc, mrrc2): New.
   * config/arm/iterators.md (MCRRI, mcrr, MCRR): New.
   (MRRCI, mrrc, MRRC): New.
   * config/arm/unspecs.md (VUNSPEC_MCRR, VUNSPEC_MCRR2, VUNSPEC_MRRC,
   VUNSPEC_MRRC2): New.

gcc/testsuite/ChangeLog:

2017-01-xx  Andre Vieira  

   * gcc.target/arm/acle/mcrr: New.
   * gcc.target/arm/acle/mcrr2: New.
   * gcc.target/arm/acle/mrrc: New.
   * gcc.target/arm/acle/mrrc2: New.

Re: [PATCH 5/6][ARM] Implement support for ACLE Coprocessor MCR and MRC intrinsics

[Kyrill Tkachov]

On 06/01/17 14:18, Andre Vieira (lists) wrote:

On 05/01/17 11:08, Kyrill Tkachov wrote:

On 09/11/16 10:12, Andre Vieira (lists) wrote:

Hi,

This patch implements support for the ARM ACLE Coprocessor MCR and MRC
intrinsics. See below a table mapping the intrinsics to their respective
instructions:

+---+---+

| Intrinsic signature   |
Instruction pattern   |
+---+---+

|void __arm_mcr(coproc, opc1, uint32_t value, CRn, CRm, opc2)   |
MCR coproc, opc1, Rt, CRn, CRm, opc2  |
+---+---+

|void __arm_mcr2(coproc, opc1, uint32_t value, CRn, CRm, opc2)  |
MCR2 coproc, opc1, Rt, CRn, CRm, opc2 |
+---+---+

|uint32_t __arm_mrc(coproc, opc1, CRn, CRm, opc2)   |
MRC coproc, opc1, Rt, CRn, CRm, opc2  |
+---+---+

|uint32_t __arm_mrc2(coproc, opc1, CRn, CRm, opc2)  |
MRC2 coproc, opc1, Rt, CRn, CRm, opc2 |
+---+---+

Note that any untyped variable in the intrinsic signature is required to
be a compiler-time constant and has the type 'unsigned int'.  We do some
boundary checks for coproc:[0-15], opc1[0-7] CR*:[0-31],opc2:[0-7].  If
either of these requirements are not met a diagnostic is issued.

Is this OK for trunk?

Regards,
Andre

gcc/ChangeLog:
2016-11-09  Andre Vieira  

* config/arm/arm.md (): New.
(): New.
* config/arm/arm.c (arm_coproc_builtin_available): Add
support for mcr, mrc, mcr2 and mrc2.
* config/arm/arm-builtins.c (MCR_QUALIFIERS): Define to...
(arm_mcr_qualifiers): ... this. New.
(MRC_QUALIFIERS): Define to ...
(arm_mrc_qualifiers): ... this. New.
(MCR_QUALIFIERS): Define to ...
(arm_mcr_qualifiers): ... this. New.
* config/arm/arm_acle.h (__arm_mcr, __arm_mrc, __arm_mcr2,
__arm_mrc2): New.
* config/arm/arm_acle_builtins.def (mcr, mcr2, mrc, mrc2): New.
* config/arm/iterators.md (MCRI, mcr, MCR, MRCI, mrc, MRC): New.
* config/arm/unspecs.md (VUNSPEC_MCR, VUNSPEC_MCR2, VUNSPEC_MRC,
VUNSPEC_MRC2): New.


gcc/ChangeLog:
2016-11-09  Andre Vieira  

* gcc.target/arm/acle/mcr.c: New.
* gcc.target/arm/acle/mrc.c: New.
* gcc.target/arm/acle/mcr2.c: New.
* gcc.target/arm/acle/mrc2.c: New.

+(define_insn ""
+  [(unspec_volatile [(match_operand:SI 0 "immediate_operand")
+ (match_operand:SI 1 "immediate_operand")
+ (match_operand:SI 2 "s_register_operand")
+ (match_operand:SI 3 "immediate_operand")
+ (match_operand:SI 4 "immediate_operand")
+ (match_operand:SI 5 "immediate_operand")] MCRI)
+   (use (match_dup 2))]
+  "arm_coproc_builtin_available (VUNSPEC_)"
+{
+  arm_const_bounds (operands[0], 0, 16);
+  arm_const_bounds (operands[1], 0, 8);
+  arm_const_bounds (operands[3], 0, (1 << 5));
+  arm_const_bounds (operands[4], 0, (1 << 5));
+  arm_const_bounds (operands[5], 0, 8);
+  return "\\tp%c0, %1, %2, CR%c3, CR%c4, %5";
+}
+  [(set_attr "length" "4")
+   (set_attr "type" "coproc")])
+
+(define_insn ""
+  [(set (match_operand:SI 0 "s_register_operand")
+(unspec_volatile [(match_operand:SI 1 "immediate_operand")
+  (match_operand:SI 2 "immediate_operand")
+  (match_operand:SI 3 "immediate_operand")
+  (match_operand:SI 4 "immediate_operand")
+  (match_operand:SI 5 "immediate_operand")] MRCI))]
+  "arm_coproc_builtin_available (VUNSPEC_)"
+{
+  arm_const_bounds (operands[1], 0, 16);
+  arm_const_bounds (operands[2], 0, 8);
+  arm_const_bounds (operands[3], 0, (1 << 5));
+  arm_const_bounds (operands[4], 0, (1 << 5));
+  arm_const_bounds (operands[5], 0, 8);
+  return "\\tp%c1, %2, %0, CR%c3, CR%c4, %5";
+}
+  [(set_attr "length" "4")
+   (set_attr "type" "coproc")])

Same as the previous patch, these operands need constraints.
The MRC ones in particular need a '=' in their constraint string.

Hi,

Reworked comments and rebased.

Is this OK for trunk?


Ok.
Thanks,
Kyrill


Regards,
Andre

gcc/ChangeLog:
2017-01-xx  Andre Vieira  

   * config/arm/arm.md (): New.
   (): New.
   * config/arm/arm.c (arm_coproc_builtin_available): Add
   support for mcr, mrc, mcr2 and mrc2.
   * config/arm/arm-builtins.c (MCR_QUALIFIERS): Define to...
   (arm_mcr_qualifiers): ... this. New.
   (MRC_QUALIFIERS): Define to ...
   (arm_mrc_qualifiers): ... this. New.
   (MCR_QUALIFIERS): Define to ...
   (arm_mcr_qualifiers): ... this. New.
   * config/arm/a

Re: [PATCH 4/6][ARM] Implement support for ACLE Coprocessor LDC and STC intrinsics

[Kyrill Tkachov]

On 06/01/17 14:18, Andre Vieira (lists) wrote:

On 05/01/17 11:02, Kyrill Tkachov wrote:

Hi Andre,

On 09/11/16 10:12, Andre Vieira (lists) wrote:

Hi,

This patch implements support for the ARM ACLE Coprocessor LDC and STC
intrinsics. See below a table mapping the intrinsics to their respective
instructions:

++--+

| Intrinsic signature| Instruction
pattern  |
++--+

|void __arm_ldc(coproc, CRd, const void* p)  |LDC coproc, CRd,
[...]|
++--+

|void __arm_ldcl(coproc, CRd, const void* p) |LDCL coproc, CRd,
[...]   |
++--+

|void __arm_ldc2(coproc, CRd, const void* p) |LDC2 coproc, CRd,
[...]   |
++--+

|void __arm_ldc2l(coproc, CRd, const void* p)|LDC2L coproc, CRd,
[...]  |
++--+

|void __arm_stc(coproc, CRd, void* p)|STC coproc, CRd,
[...]|
++--+

|void __arm_stcl(coproc, CRd, void* p)   |STCL coproc, CRd,
[...]   |
++--+

|void __arm_stc2(coproc, CRd, void* p)   |STC2 coproc, CRd,
[...]   |
++--+

|void __arm_stc2l(coproc, CRd, void* p)  |STC2L coproc, CRd,
[...]  |
++--+

Note that any untyped variable in the intrinsic signature is required to
be a compiler-time constant and has the type 'unsigned int'.  We do some
boundary checks for coproc:[0-15], CR*:[0-31]. If either of these
requirements are not met a diagnostic is issued.


Is this ok for trunk?

I have a few comments below...


Regards,
Andre

gcc/ChangeLog:
2016-11-09  Andre Vieira  

* config/arm/arm.md (*ldcstc): New.
(): New.
* config/arm/arm.c (arm_coproc_builtin_available): Add
support for ldc,ldcl,stc,stcl,ldc2,ldc2l,stc2 and stc2l.
(arm_coproc_ldc_stc_legitimate_address): New.
* config/arm/arm-builtins.c (arm_type_qualifiers): Add
'qualifier_const_pointer'.
(LDC_QUALIFIERS): Define to...
(arm_ldc_qualifiers): ... this. New.
(STC_QUALIFIERS): Define to...
(arm_stc_qualifiers): ... this. New.
* config/arm/arm-protos.h
(arm_coproc_ldc_stc_legitimate_address): New.
* config/arm/arm_acle.h (__arm_ldc, __arm_ldcl, __arm_stc,
__arm_stcl, __arm_ldc2, __arm_ldc2l, __arm_stc2, __arm_stc2l): New.
* config/arm/arm_acle_builtins.def (ldc, ldc2, ldcl, ldc2l, stc,
stc2, stcl, stc2l): New.
* config/arm/constraints.md (Uz): New.
* config/arm/iterators.md (LDCSTCI, ldcstc, LDCSTC): New.
* config/arm/unspecs.md (VUNSPEC_LDC, VUNSPEC_LDC2, VUNSPEC_LDCL,
VUNSPEC_LDC2L, VUNSPEC_STC, VUNSPEC_STC2, VUNSPEC_STCL,
VUNSPEC_STC2L): New.

gcc/testsuite/ChangeLog:

2016-11-09  Andre Vieira  

* gcc.target/arm/acle/ldc: New.
* gcc.target/arm/acle/ldc2: New.
* gcc.target/arm/acle/ldcl: New.
* gcc.target/arm/acle/ldc2l: New.
* gcc.target/arm/acle/stc: New.
* gcc.target/arm/acle/stc2: New.
* gcc.target/arm/acle/stcl: New.
* gcc.target/arm/acle/stc2l: New.

+  /* const T * foo */
+  qualifier_const_pointer = 0x6,

Nit: full stop at end of comment.

+
+/* This function returns true if OP is a valid memory operand for the
ldc and
+   stc coprocessor instructions and false otherwise.  */
+
+bool arm_coproc_ldc_stc_legitimate_address (rtx op)
+{

type and function name should be on separate lines.

+  int range;
+  /* Has to be a memory operand.  */
+  if (!MEM_P (op))
+return false;

+  /* Within the range of [-1020,1020].  */
+  if (range < -1020 || range > 1020)
+return false;

Use !IN_RANGE (-1020, 1020), also make 'range' a HOST_WIDE_INT (that is
what INTVAL returns).

--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -11858,6 +11858,25 @@
[(set_attr "length" "4")
 (set_attr "type" "coproc")])
  
+(define_insn "*ldcstc"

+  [(unspec_volatile [(match_operand:SI 0 "immediate_operand")
+ (match_operand:SI 1 "immediate_operand")
+ (match_operand:SI 2 "memory_operand" "Uz")] LDCSTCI)]
+  "arm_coproc_builtin_available (VUNSPEC_)"

You're missing constraints for operands 1 and 2? (just the general 'n'

Re: [PR tree-optimization/67955] Exploit PTA in DSE

[Christophe Lyon]

Hi Jeff,


On 5 January 2017 at 09:34, Richard Biener  wrote:
> On Wed, Jan 4, 2017 at 8:24 PM, Jeff Law  wrote:
>> On 01/04/2017 11:55 AM, Jeff Law wrote:
>>>
>>> On 12/09/2016 01:28 AM, Richard Biener wrote:

 On Wed, Dec 7, 2016 at 12:18 AM, Jeff Law  wrote:
>
>
>
> So I was going through the various DSE related bugs as stumbled across
> 67955.
>
> The basic issue in 67955 is that DSE is too simplistic when trying to
> determine if two writes hit the same memory address.  There are cases
> were
> PTA analysis can get us that information.
>
> The unfortunate problem is that PTA can generate a single points-to
> set for
> pointers to different elements in the same array.  So we can only
> exploit a
> special case.  Namely when we get a PTA singleton and the size of the
> store
> is the same size of the pointed-to object.
>
> That doesn't happen in a bootstrap, but it does happen for the
> testcase in
> the BZ as well as a handful of tests in the testsuite -- Tom reported 6
> unique tests where it triggered, I ran my own tests where two more
> were spit
> out.  Not huge.  But the cost is low.
>
> All that I've done with Tom's patch is update the call into the PTA
> system.
> It's very clearly Tom's work.
>
> Bootstrapped and regression tested on x86_64-linux-gnu.  Installing
> on the
> trunk.


 Just double-checked it doesn't break

 int foo (int *p, int b)
 {
   int *q;
   int i = 1;
   if (b)
 q = &i;
   else
 q = (void *)0;
   *q = 2;
   return i;
 }
>>>
>>> Right.  ISTM this shouldn't have a singleton points-to set and thus
>>> shouldn't change behavior.But looking at things more closely, it
>>> looks like points-to-null is distinct from the points-to variables.  ie,
>>> we want to know if its a singleton and ! null.  Thus we have to check
>>> pt_solution_singleton_or_null_p (pi->pt, &pt_uid) && !pi->pt->null
>>>
>>> I think it's working for you because the path isolation code splits off
>>> the NULL dereference path.  Adding
>>> -fno-isolate-erroneous-paths-dereference to the switches shows DSE2,
>>> incorrectly IMHO, removing the i = 1 store.
>>>
>>> Thoughts?
>>
>> The more I think about this the more I'm sure we need to verify pt.null is
>> not in the points-to set.I've taken the above testcase and added it as a
>> negative test.  Bootstrapped, regression tested and committed to the trunk
>> along with the other minor cleanups you pointed out.
>
> Note disabling this for pt.null == 1 makes it pretty useless given we compute
> that conservatively to always 1 in points-to analysis (and only VRP ever sets
> it to zero).  See PTAs find_what_p_points_to.  This is because PTA does
> not conservatively compute whether a pointer may be NULL (all bugs, I have
> partly fixed some and have an incomplete patch to fix others -- at the point
> I looked into this we had no users of pt.null info and thus I decided the
> extra constraints and complexity wasn't worth the compile-time/memory-use).
>
> Without -fnon-call-exceptions removing the *0 = 2 store is IMHO ok, so we
> only have to make sure to not break the exception case.
>
> For
>
> int foo (int *p, int b)
> {
>   int *q;
>   int i = 1;
>   if (b)
> q = &i;
>   else
> q = (void *)0;
>   *q = 2;
>   i = 3;
>   return *q;
> }
>
> we remove all stores but the last store to i and the load from q (but we don't
> replace q with &i here, a missed optimization if removing the other stores is
> valid).
>
> So for
>
> int foo (int *p, int b)
> {
>   int i = 1;
>   try {
>   int *q;
>   if (b)
> q = &i;
>   else
> q = (int *)0;
>   *q = 2;
>   } catch (...) {
>   return 0;
>   }
>   return i;
> }
>
> we do not remove the store to i with -fnon-call-exceptions.  Which means we 
> are
> fine not testing for pt.null != 1.
>
> ?
>
> Richard.
>
>> Thanks,
>>
>> Jeff
>>
>>
>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>> index d43c9bc..3a7ad9d 100644
>> --- a/gcc/ChangeLog
>> +++ b/gcc/ChangeLog
>> @@ -1,3 +1,11 @@
>> +2017-01-04  Jeff Law  
>> +
>> +   PR tree-optimizatin/67955
>> +   * tree-ssa-alias.c (same_addr_size_stores_p): Check offsets first.
>> +   Allow any SSA_VAR_P as the base objects.  Use integer_zerop.  Verify
>> +   the points-to solution does not include pt_null.  Use DECL_PT_UID
>> +   unconditionally.
>> +
>>  2017-01-04  Uros Bizjak  
>>
>> * config/i386/i386.md (HI/SImode test with imm to QImode splitters):
>> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
>> index d8ff32f..0cbc8cc 100644
>> --- a/gcc/testsuite/ChangeLog
>> +++ b/gcc/testsuite/ChangeLog
>> @@ -1,3 +1,8 @@
>> +2017-01-03  Jeff Law  
>> +
>> +   PR tree-optimization/67955
>> +   * gcc.dg/tree-ssa/ssa-dse-28.c: New test.
>> +

Since you committed this patch (r244067), I have noticed that
gcc.dg/tree-ssa/dse

Re: [PATCH] Implement no_sanitize function attribute

[Martin Liška]

PING^1

On 12/22/2016 02:38 PM, Martin Liška wrote:
> Hello.
> 
> As I previously agreed with Jakub, I prepared patch which adds
> no_sanitize function attribute (same what clang support).
> 
> That encompasses following changes:
> 1) all no_sanitize_* function attributes are parsed and stored to 
> no_sanitize_flags
> in DECL_ATTRIBUTES
> 2) instead of flag_sanitize & X, let's call sanitize_flags_p (X), where the 
> DECL_ATTRIBUTES
> are checked within the function
> 3) I prepared many test-cases which test every (almost) single sub-option of 
> UBSAN and all
> functions are decorated with no_sanitize attribute disabling all sanitization 
> except the one
> tested in a particular test
> 4) documentation entry is introduced
> 
> Misc changes:
> a) I would like to rename SANITIZE_NONDEFAULT to SANITIZE_UNDEFINED_NONDEFAULT
> b) Documentation fix for -sanitize=bounds-strict is added
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> 
> Martin
> 

Re: [Patch] [add changelog] reduce template instantiation depth in

[Jonathan Wakely]

On 23/12/16 01:20 +, Jonathan Wakely wrote:

On 22/12/16 19:06 -0600, Barrett Adair wrote:

On Tue, Dec 6, 2016 at 1:24 PM, Tim Shen  wrote:

On Tue, Dec 6, 2016 at 4:35 AM, Jonathan Wakely  wrote:

I've rebased Barrett's patch against the latest variant code
(attached).

Tim, do we want to make this change? A variant of 400 alternatives
seems pretty extreme, but if we can support it without much trouble
then maybe it's good to do so.



Yes, go ahead.

Thanks!


--
Regards,
Tim Shen


Did this make it into a branch? I'm not seeing this in the trunk.


No, it hasn't been done yet.


Here's what I've committed to trunk.

Tested powerpc64le-linux.

commit 0d54934b56a44b1c26510e98a57cd2663153f51c
Author: Jonathan Wakely 
Date:   Fri Jan 6 14:47:48 2017 +

Use fold expressions to reduce std::variant instantiation depth

2017-01-06  Barrett Adair  
	Jonathan Wakely  

	* include/std/variant (variant, swap): Replace __and_ usage with fold
	expressions.

diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 1803315..3d025a7 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -396,7 +396,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
   _Variant_base(_Variant_base&& __rhs)
-  noexcept(__and_...>::value)
+  noexcept((is_nothrow_move_constructible_v<_Types> && ...))
   {
 	if (__rhs._M_valid())
 	  {
@@ -459,8 +459,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   _Variant_base&
   operator=(_Variant_base&& __rhs)
-  noexcept(__and_...,
-		  is_nothrow_move_assignable<_Types>...>::value)
+  noexcept((is_nothrow_move_constructible_v<_Types> && ...)
+	  && (is_nothrow_move_assignable_v<_Types> && ...))
   {
 	if (this->_M_index == __rhs._M_index)
 	  {
@@ -865,8 +865,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { __lhs.swap(__rhs); }
 
   template
-enable_if_t...,
-			is_swappable<_Types>...>::value>
+enable_if_t && ...)
+		   && (is_swappable_v<_Types> && ...))>
 swap(variant<_Types...>&, variant<_Types...>&) = delete;
 
   class bad_variant_access : public exception
@@ -895,13 +895,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	is_default_constructible_v<
 	  variant_alternative_t<0, variant<_Types...>>>, variant<_Types...>>,
   private _Enable_copy_move<
-	__and_...>::value,
-	__and_...,
-	   is_move_constructible<_Types>...,
-	   is_copy_assignable<_Types>...>::value,
-	__and_...>::value,
-	__and_...,
-	   is_move_assignable<_Types>...>::value,
+	(is_copy_constructible_v<_Types> && ...),
+	(is_copy_constructible_v<_Types> && ...)
+	 && (is_move_constructible_v<_Types> && ...)
+	 && (is_copy_assignable_v<_Types> && ...),
+	(is_move_constructible_v<_Types> && ...),
+	(is_move_constructible_v<_Types> && ...)
+	 && (is_move_assignable_v<_Types> && ...),
 	variant<_Types...>>
 {
 private:
@@ -948,8 +948,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   noexcept(is_nothrow_default_constructible_v<__to_type<0>>) = default;
   variant(const variant&) = default;
   variant(variant&&)
-  noexcept(__and_<
-	is_nothrow_move_constructible<_Types>...>::value) = default;
+  noexcept((is_nothrow_move_constructible_v<_Types> && ...)) = default;
 
   template>
@@ -1003,8 +1002,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   variant& operator=(const variant&) = default;
   variant& operator=(variant&&)
-  noexcept(__and_...,
-		  is_nothrow_move_assignable<_Types>...>::value) = default;
+  noexcept((is_nothrow_move_constructible_v<_Types> && ...)
+	  && (is_nothrow_move_assignable_v<_Types> && ...)) = default;
 
   template
 	enable_if_t<__exactly_once<__accepted_type<_Tp&&>>
@@ -1091,7 +1090,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   void
   swap(variant& __rhs)
-  noexcept(__and_<__is_nothrow_swappable<_Types>...>::value
+  noexcept((__is_nothrow_swappable<_Types>::value && ...)
 	   && is_nothrow_move_constructible_v)
   {
 	if (this->index() == __rhs.index())

Re: [PATCH] improve string find algorithm

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 03:16:12PM +, Jonathan Wakely wrote:
> On 06/01/17 16:09 +0100, Jakub Jelinek wrote:
> > On Fri, Jan 06, 2017 at 08:42:15AM -0600, Aditya Kumar wrote:
> > > Yes, we do.
> > > Sorry for the mistake, it happened because I first wrote this for
> > > libcxx (https://reviews.llvm.org/D27068) and while porting that line
> > > got missed.
> > 
> > Shouldn't find at least in the case where it is narrow char string
> > just use C library memmem?  That implements a Two-Way searching algorithm
> > with some improvements from Boyer-Moore.
> > Otherwise, consider what even your modified version will do for
> > 
> > #include 
> > int main() {
> > (std::string(1000, 'a')+"b").find(std::string(100, 'a')+"b");
> > }
> 
> Yes, I have an incomplete local patch that checks for memmem and uses
> it where possible. This change would still be valuable for non-GNU
> targets though.

The description of Two-Way algorithm is in
http://www-igm.univ-mlv.fr/~lecroq/string/node26.html#SECTION00260
Boyer-Moore in
http://en.wikipedia.org/wiki/Boyer-Moore_string_search_algorithm

Of course, as you know the lengths of both strings, you can quite cheaply
decide whether it is worth spending some time building data structures
to speed up the following search or not (but so does memmem already,
e.g. handle with no searching zero length needle, or needle longer than
haystack).  Or for short needles start with memchr of the first char, while
for longer needles don't do that etc.

> > Or does the C++ library need to reinvent everything implemented in the C
> > library?
> 
> In this case yes, because strstr doesn't take the length of the
> strings into account, and memmem isn't standard. Because std::string
> knows its length we can do better than strstr for some cases, such as
> std::string(1000, 'a').find(std::string(1001, 'a')).

Jakub

Re: [PATCH] improve string find algorithm

[Jonathan Wakely]

On 06/01/17 16:26 +0100, Jakub Jelinek wrote:

On Fri, Jan 06, 2017 at 03:16:12PM +, Jonathan Wakely wrote:

On 06/01/17 16:09 +0100, Jakub Jelinek wrote:
> On Fri, Jan 06, 2017 at 08:42:15AM -0600, Aditya Kumar wrote:
> > Yes, we do.
> > Sorry for the mistake, it happened because I first wrote this for
> > libcxx (https://reviews.llvm.org/D27068) and while porting that line
> > got missed.
>
> Shouldn't find at least in the case where it is narrow char string
> just use C library memmem?  That implements a Two-Way searching algorithm
> with some improvements from Boyer-Moore.
> Otherwise, consider what even your modified version will do for
>
> #include 
> int main() {
> (std::string(1000, 'a')+"b").find(std::string(100, 'a')+"b");
> }

Yes, I have an incomplete local patch that checks for memmem and uses
it where possible. This change would still be valuable for non-GNU
targets though.


The description of Two-Way algorithm is in
http://www-igm.univ-mlv.fr/~lecroq/string/node26.html#SECTION00260
Boyer-Moore in
http://en.wikipedia.org/wiki/Boyer-Moore_string_search_algorithm


And in std::boyer_moore_searcher in  :-)
We also have std::boyer_moore_horspool_searcher in .

We could try allocating memory in std::string::find() and fall back to
the dumb algorithm if it fails, but we don't want to throw bad_alloc.

Re: [PATCH] improve string find algorithm

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 03:34:22PM +, Jonathan Wakely wrote:
> > The description of Two-Way algorithm is in
> > http://www-igm.univ-mlv.fr/~lecroq/string/node26.html#SECTION00260
> > Boyer-Moore in
> > http://en.wikipedia.org/wiki/Boyer-Moore_string_search_algorithm
> 
> And in std::boyer_moore_searcher in  :-)
> We also have std::boyer_moore_horspool_searcher in .
> 
> We could try allocating memory in std::string::find() and fall back to
> the dumb algorithm if it fails, but we don't want to throw bad_alloc.

glibc memmem algorithm doesn't allocate any memory for short needles (< 32
chars) and for longer needles uses size_t shift_table[1U << CHAR_BIT];
automatic array (i.e. 1KB on 32-bits, 2KB on 64-bits).

Jakub

Re: [bootstrap-O3,fortran] silence warning in simplify_transformation_to_array

[Jeff Law]

On 01/06/2017 04:34 AM, Christophe Lyon wrote:

On 6 January 2017 at 11:21, Jakub Jelinek  wrote:

On Fri, Jan 06, 2017 at 09:34:46AM +0100, Christophe Lyon wrote:

I makes my aarch64*linux* and arm*linux* builds for fail, because:
gcc/fortran/simplify.c:613: error: #pragma GCC diagnostic not allowed
inside functions
gcc/fortran/simplify.c:620: error: #pragma GCC diagnostic not allowed
inside functions
gcc/fortran/simplify.c:624: error: #pragma GCC diagnostic not allowed
inside functions

My host compiler is RHEL6's, that is 4.4.7

I'm not sure what current minimum gcc version is required to build gcc?


So, do we want something like (untested) following patch then, so that we
use the pragmas only on recent GCC versions?


I would say so, RHEL6 is not that old, is it?
I think we want to be able to build GCC on reasonably old machines.
Well, the gcc-4.4.x series is roughly 8 years old now.  I call that 
ancient :-)  But it's in widespread use, so we probably ought to support 
bootstrapping from compilers of that era.



jeff

Re: [bootstrap-O3,fortran] silence warning in simplify_transformation_to_array

[Jeff Law]

On 01/06/2017 04:39 AM, Richard Biener wrote:

On January 6, 2017 11:21:44 AM GMT+01:00, Jakub Jelinek  
wrote:

On Fri, Jan 06, 2017 at 09:34:46AM +0100, Christophe Lyon wrote:

I makes my aarch64*linux* and arm*linux* builds for fail, because:
gcc/fortran/simplify.c:613: error: #pragma GCC diagnostic not allowed
inside functions
gcc/fortran/simplify.c:620: error: #pragma GCC diagnostic not allowed
inside functions
gcc/fortran/simplify.c:624: error: #pragma GCC diagnostic not allowed
inside functions

My host compiler is RHEL6's, that is 4.4.7

I'm not sure what current minimum gcc version is required to build

gcc?

So, do we want something like (untested) following patch then, so that
we
use the pragmas only on recent GCC versions?


Works for me.

Likewise.
jeff

Re: [PATCH] PR78255: Make postreload aware of NO_FUNCTION_CSE

[Jeff Law]

On 01/06/2017 03:53 AM, Andre Vieira (lists) wrote:

On 09/12/16 16:31, Bernd Schmidt wrote:

On 12/09/2016 05:16 PM, Andre Vieira (lists) wrote:


Regardless, 'reload_cse_simplify' would never perform the opposite
transformation.  It checks whether it can replace anything within the
first argument INSN, with the second argument TESTREG. As the name
implies this will always be a register. I double checked, the function
is only called in 'reload_cse_regs' and 'testreg' is created using
'gen_rtx_REG'.


Ok, let's go ahead with it.


Bernd


Hello,

Is it OK to backport this (including the testcase fix) to gcc-6-branch?

Patches apply cleanly and full bootstrap and regression tests for
aarch64- and arm-none-linux-gnueabihf. Regression tested for arm-none-eabi.

Yes, that should be fine to backport to the active release branches.

jeff

Re: [build, libgo, libstdc++] Build libgo with -Wa,-nH if possible (PR go/78978)

[Ian Lance Taylor]

On Fri, Jan 6, 2017 at 6:35 AM, Rainer Orth  
wrote:
> Hi Ian,
>
>> On Thu, Jan 5, 2017 at 1:20 AM, Rainer Orth  
>> wrote:
>>> As could have been expected, the static libgo.a causes the same problem
>>> with hardware capabilities on Solaris/x86 as was solved for libgo.so
>>> with
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00726.html
>>>
>>> Instead of trying to pass -mclear-hwcap with -static-libgo, it was
>>> deemed easier to solve both problems the same way and disable hwcaps
>>> support in the assembler in the first place.
>>>
>>> This has already been done in libstdc++, so I've moved the corresponding
>>> autoconf macro to config/hwcaps.m4 and adapted it to set HWCAP_CFLAGS
>>> instead of HWCAP_FLAGS to better differntiate from HWCAP_LDFLAGS.
>>> Everything else is straightforward, I believe.
>>>
>>> Bootstrapped without regressions on i386-pc-solaris2.1[02] with as/ld
>>> (where as supports -nH) and sparc-sun-solaris2.12 with as/ld (where as
>>> doesn't, or rather it's called -hwcap={1|0}), and the libgo
>>> runtime/pprof failure is gone.
>>>
>>> Ok for mainline?
>>>
>>> Once approved, how should we proceed with checking?  Ian, will you take
>>> care of the libgo part once the rest is in?
>>
>> This patch is OK.  Yes, please commit the config and libstdc++
>> portions.  Then I will commit the libgo portions to the external repo
>> and mirror them in.  Thanks.
>
> done, thanks.  While preparing the partial commit, I noticed that I'd
> created the libgo part of the patch on top of a tree that contained a
> workaround for PR go/64900.
>
> Here's the libgo part again, this time on top of a vanilla tree.

Thanks.  Committed.

Ian

[PATCH][M68K] allow long offsets in jump tables (wrong-code PR target/57583)

[Mikael Pettersson]

This fixes / works-around the wrong-code PR57583 on M68K, caused by
overflowing the 16-bit jump table offsets the backend uses.

Ideally the backend should define CASE_VECTOR_SHORTEN_MODE, but that
AFAIK needs insn length attributes, which the backend only has for CF
but not for classic M68K.

Instead this patch adds an -mlong-jump-table-offsets option, and adjusts
the code for emitting and using jump table offsets to handle both short
and long offsets.  As long as the option is not selected, the backend
behaves exactly as before.

John Paul Adrian Glaubitz tested this patch by compiling "mednafen"
with it, which previously failed; I also tested earlier versions.

Is this Ok for trunk?

/Mikael


gcc/

2017-01-06  Mikael Pettersson  

PR target/57583
* config/m68k/m68k.opt (LONG_JUMP_TABLE_OFFSETS): New option.
* config/m68k/linux.h (ASM_RETURN_CASE_JUMP): Handle
TARGET_LONG_JUMP_TABLE_OFFSETS.
* config/m68k/m68kelf.h (ASM_RETURN_CASE_JUMP): Likewise.
* config/m68k/netbsd-elf.h (ASM_RETURN_CASE_JUMP): Likewise.
* config/m68k/m68k.h (CASE_VECTOR_MODE): Likewise.
(ASM_OUTPUT_ADDR_DIFF_ELF): Likewise.
* config/m68k/m68k.md (tablejump expander): Likewise.
(*tablejump_pcrel_hi): Renamed from unnamed insn, reject
TARGET_LONG_JUMP_TABLE_OFFSETS.
(*tablejump_pcrel_si): New insn, handle TARGET_LONG_JUMP_TABLE_OFFSETS.
* doc/invoke.texi (M68K options): Add -mlong-jump-table-offsets.

--- gcc-7-20170101/gcc/config/m68k/linux.h.~1~  2017-01-01 13:07:43.0 
+0100
+++ gcc-7-20170101/gcc/config/m68k/linux.h  2017-01-06 14:36:37.366245875 
+0100
@@ -98,9 +98,13 @@ along with GCC; see the file COPYING3.
   {\
if (ADDRESS_REG_P (operands[0]))\
  return "jmp %%pc@(2,%0:l)";   \
+   else if (TARGET_LONG_JUMP_TABLE_OFFSETS)\
+ return "jmp %%pc@(2,%0:l)";   \
else\
  return "ext%.l %0\n\tjmp %%pc@(2,%0:l)";  \
   }\
+else if (TARGET_LONG_JUMP_TABLE_OFFSETS)   \
+  return "jmp %%pc@(2,%0:l)";  \
 else   \
   return "jmp %%pc@(2,%0:w)";  \
   } while (0)
--- gcc-7-20170101/gcc/config/m68k/m68k.h.~1~   2017-01-01 13:07:43.0 
+0100
+++ gcc-7-20170101/gcc/config/m68k/m68k.h   2017-01-06 14:36:37.366245875 
+0100
@@ -675,7 +675,7 @@ __transfer_from_trampoline ()   
\
 
 /* This address is OK as it stands.  */
 #define PIC_CASE_VECTOR_ADDRESS(index) index
-#define CASE_VECTOR_MODE HImode
+#define CASE_VECTOR_MODE (TARGET_LONG_JUMP_TABLE_OFFSETS ? SImode : HImode)
 #define CASE_VECTOR_PC_RELATIVE 1
 
 #define DEFAULT_SIGNED_CHAR 1
@@ -857,7 +857,11 @@ do { if (cc_prev_status.flags & CC_IN_68
   asm_fprintf (FILE, "\t.long %LL%d\n", VALUE)
 
 #define ASM_OUTPUT_ADDR_DIFF_ELT(FILE, BODY, VALUE, REL)  \
-  asm_fprintf (FILE, "\t.word %LL%d-%LL%d\n", VALUE, REL)
+  asm_fprintf (FILE,   \
+  TARGET_LONG_JUMP_TABLE_OFFSETS   \
+  ? "\t.long %LL%d-%LL%d\n"\
+  : "\t.word %LL%d-%LL%d\n",   \
+  VALUE, REL)
 
 /* We don't have a way to align to more than a two-byte boundary, so do the
best we can and don't complain.  */
--- gcc-7-20170101/gcc/config/m68k/m68k.md.~1~  2017-01-01 13:07:43.0 
+0100
+++ gcc-7-20170101/gcc/config/m68k/m68k.md  2017-01-06 14:36:37.366245875 
+0100
@@ -6695,7 +6695,9 @@ (define_expand "tablejump"
 {
 #if CASE_VECTOR_PC_RELATIVE
 operands[0] = gen_rtx_PLUS (SImode, pc_rtx,
-   gen_rtx_SIGN_EXTEND (SImode, operands[0]));
+   TARGET_LONG_JUMP_TABLE_OFFSETS
+   ? operands[0]
+   : gen_rtx_SIGN_EXTEND (SImode, operands[0]));
 #endif
 })
 
@@ -6710,12 +6712,36 @@ (define_insn "*tablejump_internal"
   [(set_attr "type" "jmp")])
 
 ;; Jump to variable address from dispatch table of relative addresses.
-(define_insn ""
+(define_insn "*tablejump_pcrel_si"
+  [(set (pc)
+   (plus:SI (pc)
+(match_operand:SI 0 "register_operand" "r")))
+   (use (label_ref (match_operand 1 "" "")))]
+  "TARGET_LONG_JUMP_TABLE_OFFSETS"
+{
+#ifdef ASM_RETURN_CASE_JUMP
+  ASM_RETURN_CASE_JUMP;
+#else
+  if (TARGET_COLDFIRE)
+{
+  if (ADDRESS_REG_P (operands[0]))
+   return MOTOROLA ? "jmp (2,pc,%0.l)" : "jmp pc@(2,%0:l)";
+  else if (MOTOROLA)
+   return "jmp (2,pc,%0.l)";
+  else
+   return "jmp pc@(2,%0:l)";
+}
+  else
+return MOTOROLA ? "jmp (2,pc,%0.l)" : "jmp pc@(2,%0:l)";
+#endif
+})
+

Fix direction of polymorphic call predictor

[Jan Hubicka]

Hi,
this is next patch to tweak call predictors.  It fixes bug in the direction of
predictor (like normal calls, polymorphic calls are usually not taken when
there is if guariding them) and feeds in correct data from Martin's table.

Bootstrapped/regtested x86_64-linux, comitted.
I will fix the indirect call predictor next after periodic testers pick up the
change.

Honza

Index: ChangeLog
===
--- ChangeLog   (revision 244166)
+++ ChangeLog   (working copy)
@@ -1,3 +1,10 @@
+2017-01-01  Jan Hubicka  
+
+   PR middle-end/77484
+   * predict.def (PRED_POLYMORPHIC_CALL): Set to 58
+   * predict.c (tree_estimate_probability_bb): Reverse direction of
+   polymorphic call predictor.
+
 2017-01-06  David Malcolm  
 
* passes.c (execute_one_pass): Split out pass-skipping logic
Index: predict.c
===
--- predict.c   (revision 244166)
+++ predict.c   (working copy)
@@ -2789,7 +2789,7 @@ tree_estimate_probability_bb (basic_bloc
  if (gimple_call_fndecl (stmt))
predict_edge_def (e, PRED_CALL, NOT_TAKEN);
  else if (virtual_method_call_p (gimple_call_fn (stmt)))
-   predict_edge_def (e, PRED_POLYMORPHIC_CALL, TAKEN);
+   predict_edge_def (e, PRED_POLYMORPHIC_CALL, NOT_TAKEN);
  else
predict_edge_def (e, PRED_INDIR_CALL, TAKEN);
  break;
Index: predict.def
===
--- predict.def (revision 244166)
+++ predict.def (working copy)
@@ -122,7 +122,7 @@ DEF_PREDICTOR (PRED_CALL, "call", HITRAT
less reliable for indirect calls and polymorphic calls.  For spec2k6
the predictio nis slightly in the direction of taking the call.  */
 DEF_PREDICTOR (PRED_INDIR_CALL, "indirect call", HITRATE (51), 0)
-DEF_PREDICTOR (PRED_POLYMORPHIC_CALL, "polymorphic call", HITRATE (58), 0)
+DEF_PREDICTOR (PRED_POLYMORPHIC_CALL, "polymorphic call", HITRATE (59), 0)
 
 /* Recursive calls are usually not taken or the function will recurse
indefinitely.  */

Re: [bootstrap-O3,fortran] silence warning in simplify_transformation_to_array

[Christophe Lyon]

On 6 January 2017 at 12:39, Richard Biener  wrote:
> On January 6, 2017 11:21:44 AM GMT+01:00, Jakub Jelinek  
> wrote:
>>On Fri, Jan 06, 2017 at 09:34:46AM +0100, Christophe Lyon wrote:
>>> I makes my aarch64*linux* and arm*linux* builds for fail, because:
>>> gcc/fortran/simplify.c:613: error: #pragma GCC diagnostic not allowed
>>> inside functions
>>> gcc/fortran/simplify.c:620: error: #pragma GCC diagnostic not allowed
>>> inside functions
>>> gcc/fortran/simplify.c:624: error: #pragma GCC diagnostic not allowed
>>> inside functions
>>>
>>> My host compiler is RHEL6's, that is 4.4.7
>>>
>>> I'm not sure what current minimum gcc version is required to build
>>gcc?
>>
>>So, do we want something like (untested) following patch then, so that
>>we
>>use the pragmas only on recent GCC versions?
>
> Works for me.
>
Me too.

> Richard.
>
>>2017-01-06  Jakub Jelinek  
>>
>>   * system.h (GCC_DIAGNOSTIC_PUSH_IGNORED, GCC_DIAGNOSTIC_POP,
>>   GCC_DIAGNOSTIC_STRINGIFY): Define.
>>
>>   * simplify.c (simplify_transformation_to_array): Use
>>   GCC_DIAGNOSTIC_PUSH_IGNORED and GCC_DIAGNOSTIC_POP instead of
>>   #pragma GCC diagnostic {push,ignored,pop}.
>>
>>--- gcc/system.h.jj2017-01-01 12:45:36.0 +0100
>>+++ gcc/system.h   2017-01-06 11:14:02.576406680 +0100
>>@@ -1140,6 +1140,18 @@ helper_const_non_const_cast (const char
>> #define VALGRIND_FREELIKE_BLOCK(x,y)
>> #endif
>>
>>+/* Macros to temporarily ignore some warnings.  */
>>+#if GCC_VERSION >= 6000
>>+#define GCC_DIAGNOSTIC_STRINGIFY(x) #x
>>+#define GCC_DIAGNOSTIC_PUSH_IGNORED(x) \
>>+  _Pragma ("GCC diagnostic push") \
>>+  _Pragma (GCC_DIAGNOSTIC_STRINGIFY (GCC diagnostic ignored #x))
>>+#define GCC_DIAGNOSTIC_POP _Pragma ("GCC diagnostic pop")
>>+#else
>>+#define GCC_DIAGNOSTIC_PUSH_IGNORED(x)
>>+#define GCC_DIAGNOSTIC_POP
>>+#endif
>>+
>>/* In LTO -fwhole-program build we still want to keep the debug
>>functions available
>>for debugger.  Mark them as used to prevent removal.  */
>> #if (GCC_VERSION > 4000)
>>--- gcc/fortran/simplify.c.jj  2017-01-06 09:23:31.0 +0100
>>+++ gcc/fortran/simplify.c 2017-01-06 11:15:01.003630017 +0100
>>@@ -610,18 +610,17 @@ simplify_transformation_to_array (gfc_ex
>> n++;
>> if (n < result->rank)
>>   {
>>-#pragma GCC diagnostic push
>> /* If the nested loop is unrolled GFC_MAX_DIMENSIONS
>>times, we'd warn for the last iteration, because the
>>array index will have already been incremented to the
>>array sizes, and we can't tell that this must make
>>the test against result->rank false, because ranks
>>must not exceed GFC_MAX_DIMENSIONS.  */
>>-#pragma GCC diagnostic ignored "-Warray-bounds"
>>+GCC_DIAGNOSTIC_PUSH_IGNORED (-Warray-bounds)
>> count[n]++;
>> base += sstride[n];
>> dest += dstride[n];
>>-#pragma GCC diagnostic pop
>>+GCC_DIAGNOSTIC_POP
>>   }
>> else
>>   done = true;
>>
>>   Jakub
>

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

[Christophe Lyon]

Hi,


On 6 January 2017 at 13:54, Jakub Jelinek  wrote:
> On Fri, Jan 06, 2017 at 01:41:15PM +0100, Martin Liška wrote:
>> Hello.
>>
>> This enables doable LTO bootstrap w/o -disable-werror. First change is 
>> mentioned
>> in the PR, second is adding -fno-lto to libdecnumber. Honza told me that 
>> proper
>> fix would take more effort as it's an old library. Last needed hunk handles 
>> -Wmaybe-uninitialized,
>> as described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79003#c4.
>>
>> Patch LTO bootstraps on x86_64-linux-gnu, can bootstrap on 
>> ppc64le-redhat-linux
>> and survives regression tests.
>>
>> Ready to be installed?
>> Martin
>
>> >From 67a3ccd99963ac19cbaebf17453cb51819c7bf1d Mon Sep 17 00:00:00 2001
>> From: marxin 
>> Date: Thu, 5 Jan 2017 17:18:27 +0100
>> Subject: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).
>>
>> gcc/ChangeLog:
>>
>> 2017-01-05  Martin Liska  
>>
>>   PR bootstrap/79003
>>   * lra-constraints.c: Rename invariant to lra_invariant.
>>   * predict.c (set_even_probabilities): Initialize e to NULL.
>>
>> libdecnumber/ChangeLog:
>>
>> 2017-01-05  Martin Liska  
>>
>>   PR bootstrap/79003
>>   * Makefile.in: Add -fno-lto to {C,CPP,LD}FLAGS.
>
> Ok, thanks.
>
> Jakub


This makes all my builds fail.
(The *linux* ones are broken after Alexandre's pragma, and
this commit breaks the remaining bare-metal configurations).
make[2]: Entering directory
`/tmp/3119026_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc1/libdecnumber'
source='/tmp/3119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber/decNumber.c'
object='decNumber.o' libtool=no gcc  -I/tmp/3
119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber -I.
-fno-lto -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissi
ng-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wcast-qual -pedantic -Wno-long-long
-I/tmp/3119026_6.tmpdir/aci-gcc-fs
f/sources/gcc-fsf/gccsrc/libdecnumber -I. -fno-lto  -c
/tmp/3119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber/decNumber.c
cc1: error: unrecognized command line option "-fno-lto"
cc1: error: unrecognized command line option "-fno-lto"

Still using gcc-4.4.7 on RHEL6

Christophe

Re: Fix direction of polymorphic call predictor

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 05:11:51PM +0100, Jan Hubicka wrote:
> Index: ChangeLog
> ===
> --- ChangeLog (revision 244166)
> +++ ChangeLog (working copy)
> @@ -1,3 +1,10 @@
> +2017-01-01  Jan Hubicka  
> +
> + PR middle-end/77484
> + * predict.def (PRED_POLYMORPHIC_CALL): Set to 58

Missing . at the end.  More importantly, you say 58 here, while

> --- predict.def   (revision 244166)
> +++ predict.def   (working copy)
> @@ -122,7 +122,7 @@ DEF_PREDICTOR (PRED_CALL, "call", HITRAT
> less reliable for indirect calls and polymorphic calls.  For spec2k6
> the predictio nis slightly in the direction of taking the call.  */
>  DEF_PREDICTOR (PRED_INDIR_CALL, "indirect call", HITRATE (51), 0)
> -DEF_PREDICTOR (PRED_POLYMORPHIC_CALL, "polymorphic call", HITRATE (58), 0)
> +DEF_PREDICTOR (PRED_POLYMORPHIC_CALL, "polymorphic call", HITRATE (59), 0)
>  
>  /* Recursive calls are usually not taken or the function will recurse
> indefinitely.  */

you've actually changed it from 58 to 59.  So is the predict.def change
intent and ChangeLog just stale, something else?

Jakub

Re: Fix direction of polymorphic call predictor

[Jan Hubicka]

> On Fri, Jan 06, 2017 at 05:11:51PM +0100, Jan Hubicka wrote:
> > Index: ChangeLog
> > ===
> > --- ChangeLog   (revision 244166)
> > +++ ChangeLog   (working copy)
> > @@ -1,3 +1,10 @@
> > +2017-01-01  Jan Hubicka  
> > +
> > +   PR middle-end/77484
> > +   * predict.def (PRED_POLYMORPHIC_CALL): Set to 58
> 
> Missing . at the end.  More importantly, you say 58 here, while
> 
> > --- predict.def (revision 244166)
> > +++ predict.def (working copy)
> > @@ -122,7 +122,7 @@ DEF_PREDICTOR (PRED_CALL, "call", HITRAT
> > less reliable for indirect calls and polymorphic calls.  For spec2k6
> > the predictio nis slightly in the direction of taking the call.  */
> >  DEF_PREDICTOR (PRED_INDIR_CALL, "indirect call", HITRATE (51), 0)
> > -DEF_PREDICTOR (PRED_POLYMORPHIC_CALL, "polymorphic call", HITRATE (58), 0)
> > +DEF_PREDICTOR (PRED_POLYMORPHIC_CALL, "polymorphic call", HITRATE (59), 0)
> >  
> >  /* Recursive calls are usually not taken or the function will recurse
> > indefinitely.  */
> 
> you've actually changed it from 58 to 59.  So is the predict.def change
> intent and ChangeLog just stale, something else?

Ah, sorry. I will update the changelog entry.  It probably does not really mater
if there is 58 or 59, but it is better to stay consistent with experimental 
data where
we can.

Honza
> 
>   Jakub

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

[Jeff Law]

On 01/05/2017 08:52 PM, Martin Sebor wrote:

So Richi asked for removal of the VR_ANTI_RANGE handling, which would
imply removal of operand_signed_p.

What are the implications if we do that?


I just got back to this yesterday.  The implications of the removal
of the anti-range handling are a number of false negatives in the
test suite:

I was thinking more at a higher level.  ie, are the warnings still
useful if we don't have the anti-range handling?  I suspect so, but
would like to hear your opinion.

...

  n = ~[-4, MAX];   (I.e., n is either negative or too big.)
  p = malloc (n);

Understood.  The low level question is do we get these kinds of ranges
often enough in computations leading to allocation sizes?


My intuition tells me that they are likely common enough not to
disregard but I don't have a lot of data to back it up with.  In
a Bash build a full 23% of all checked calls are of this kind (24
out of 106).  In a Binutils build only 4% are (9 out of 228).  In
Glibc, a little under 3%.  My guess is that the number will be
inversely proportional to the quality of the code.

23% for bash is definitely concerning.




  m = [-3, 7];
  n = [-5, 11];
  p = calloc (m, n);

which I suspect are common in the wild as well.

I must be missing something, given those ranges I wouldn't think we have
a false positive.The resulting size computation is going to have a
range [-35, 88], right?  ISTM that we'd really want to warn for that.  I
must be missing something.


The warning is meant to trigger only for cases of arguments that
are definitely too big (i.e., it's not a -Wmaybe-alloc-size-larger-
than type of warning).
OK.  That's probably what I was missing.  I guess I should have gone 
back to the option documentation first.


So IIRC the range for any multiply is produced from the 4 cross 
products.  If you clamp the lower bound at 0, then 3 cross products drop 
to 0 and you get a range [0, u0 * u1]


And in that case you're not warning because we don't know it's 
definitely too big, right?


Let me ponder a bit too :-)



The tradeoff, of course, is false negatives.  In the -Walloc-larger-
than case it can be mitigated by setting a lower threshold (I think
we might want to consider lowering the default to something less
liberal than PTRDIFF_MAX -- it seems very unlikely that a program
would try to allocate that much memory, especially in LP64).
Yea, the trick (of course) is finding a suitable value other than 
PTRDIFF_MAX.


jeff

Re: [committed] Introduce RTL function reader

[Jakub Jelinek]

On Thu, Jan 05, 2017 at 03:20:26PM -0500, David Malcolm wrote:
> +  /* Handle "reuse_rtx".  */
> +  if (strcmp (code_name, "reuse_rtx") == 0)
> +{
> +  read_name (&name);
> +  long idx = atoi (name.string);
> +  /* Look it up by ID.  */
> +  gcc_assert (idx < m_reuse_rtx_by_id.length ());
> +  return_rtx = m_reuse_rtx_by_id[idx];
> +  return return_rtx;
> +}

This broke bootstrap on i686-linux (and other ILP32 hosts), because
vec.h length () returns unsigned.

Is the following ok for trunk if it passes bootstrap/regtest?

2017-01-06  Jakub Jelinek  

* read-rtl.c (rtx_reader::read_rtx_code): Avoid -Wsign-compare
warning.

--- gcc/read-rtl.c.jj   2017-01-06 16:58:43.0 +0100
+++ gcc/read-rtl.c  2017-01-06 17:22:32.105744812 +0100
@@ -1255,7 +1255,7 @@ rtx_reader::read_rtx_code (const char *c
   if (strcmp (code_name, "reuse_rtx") == 0)
 {
   read_name (&name);
-  long idx = atoi (name.string);
+  unsigned idx = atoi (name.string);
   /* Look it up by ID.  */
   gcc_assert (idx < m_reuse_rtx_by_id.length ());
   return_rtx = m_reuse_rtx_by_id[idx];


Jakub

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 05:12:54PM +0100, Christophe Lyon wrote:
> This makes all my builds fail.
> (The *linux* ones are broken after Alexandre's pragma, and
> this commit breaks the remaining bare-metal configurations).
> make[2]: Entering directory
> `/tmp/3119026_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc1/libdecnumber'
> source='/tmp/3119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber/decNumber.c'
> object='decNumber.o' libtool=no gcc  -I/tmp/3
> 119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber -I.
> -fno-lto -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissi
> ng-prototypes -Wold-style-definition -Wmissing-format-attribute
> -Wcast-qual -pedantic -Wno-long-long
> -I/tmp/3119026_6.tmpdir/aci-gcc-fs
> f/sources/gcc-fsf/gccsrc/libdecnumber -I. -fno-lto  -c
> /tmp/3119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber/decNumber.c
> cc1: error: unrecognized command line option "-fno-lto"
> cc1: error: unrecognized command line option "-fno-lto"
> 
> Still using gcc-4.4.7 on RHEL6

Actually, I'm surprised it is doing anything, because the toplevel
Makefile should be doing:
$(HOST_EXPORTS)  \
(cd $(HOST_SUBDIR)/libdecnumber && \
  $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) 
$(STAGE1_FLAGS_TO_PASS)  \
$(TARGET-libdecnumber))
and both HOST_EXPORTS and BASE_FLAGS_TO_PASS include
"CFLAGS=$(CFLAGS)" \
"CXXFLAGS=$(CXXFLAGS)" \
"LDFLAGS=$(LDFLAGS)" \
so it should override the libdecnumber/Makefile vars that way.
In any case, I think libdecnumber/configure* should check for whether
-fno-lto works and if yes, should substitute it into some var that is then
CFLAGS += $(NO_LTO)
CXXFLAGS += $(NO_LTO)
LDFLAGS += $(NO_LTO)

Jakub

Re: Make MicroBlaze support DWARF EH (old Xilinx patch, needed for glibc build)

[Michael Eager]

On 01/06/2017 01:34 AM, Edgar E. Iglesias wrote:

On Thu, Jan 05, 2017 at 05:58:01PM +, Joseph Myers wrote:

On Thu, 5 Jan 2017, Michael Eager wrote:


 On multiple occasions, I have asked Xilinx to submit patches such
 as this one directly to the GCC/Binutils projects (assuming that
 they have a current FSF Copyright Assignment), or to give me
 explicit permission to do so on their behalf, as was the case when
 I originally submitted the MicroBlaze port to these projects.  For
 whatever reason, neither has occurred.


copyright.list shows assignments from Xilinx for GCC, binutils, GDB and
glibc, with no indication that they are not current, or of any restriction
on who at Xilinx can contribute changes.

Thus, I presume we simply need someone at Xilinx to approve the
contribution of this patch to GCC.  The last patch sent to gcc-patches by
someone @xilinx.com appears to have been
; author and
other @xilinx.com people from that discussion CC:ed on this message.


Hi Joseph,

There's no problem from our side.
In fact, a version of this patch has already been posted to gcc-patches:
https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00657.html

I don't do any work on the toolchain anymore and don't have the setup to
run the testsuite. Ajit or Nagaraju are might be able to help resolve
any issues.

Cheers,
Edgar




--
Joseph S. Myers
jos...@codesourcery.com




OK to apply.

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [committed] Introduce RTL function reader

[David Malcolm]

On Fri, 2017-01-06 at 17:25 +0100, Jakub Jelinek wrote:
> On Thu, Jan 05, 2017 at 03:20:26PM -0500, David Malcolm wrote:
> > +  /* Handle "reuse_rtx".  */
> > +  if (strcmp (code_name, "reuse_rtx") == 0)
> > +{
> > +  read_name (&name);
> > +  long idx = atoi (name.string);
> > +  /* Look it up by ID.  */
> > +  gcc_assert (idx < m_reuse_rtx_by_id.length ());
> > +  return_rtx = m_reuse_rtx_by_id[idx];
> > +  return return_rtx;
> > +}
> 
> This broke bootstrap on i686-linux (and other ILP32 hosts), because
> vec.h length () returns unsigned.

Sorry about the breakage.

I'm not able to approve the patch, but the fix looks to me like it
would be covered under the "obvious" rule.

> Is the following ok for trunk if it passes bootstrap/regtest?
> 
> 2017-01-06  Jakub Jelinek  
> 
>   * read-rtl.c (rtx_reader::read_rtx_code): Avoid -Wsign-compare
>   warning.
> 
> --- gcc/read-rtl.c.jj 2017-01-06 16:58:43.0 +0100
> +++ gcc/read-rtl.c2017-01-06 17:22:32.105744812 +0100
> @@ -1255,7 +1255,7 @@ rtx_reader::read_rtx_code (const char *c
>if (strcmp (code_name, "reuse_rtx") == 0)
>  {
>read_name (&name);
> -  long idx = atoi (name.string);
> +  unsigned idx = atoi (name.string);
>/* Look it up by ID.  */
>gcc_assert (idx < m_reuse_rtx_by_id.length ());
>return_rtx = m_reuse_rtx_by_id[idx];
> 
> 
>   Jakub

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

[Jeff Law]

On 01/05/2017 08:52 PM, Martin Sebor wrote:

So Richi asked for removal of the VR_ANTI_RANGE handling, which would
imply removal of operand_signed_p.

What are the implications if we do that?


I just got back to this yesterday.  The implications of the removal
of the anti-range handling are a number of false negatives in the
test suite:

I was thinking more at a higher level.  ie, are the warnings still
useful if we don't have the anti-range handling?  I suspect so, but
would like to hear your opinion.

...

  n = ~[-4, MAX];   (I.e., n is either negative or too big.)
  p = malloc (n);

Understood.  The low level question is do we get these kinds of ranges
often enough in computations leading to allocation sizes?


My intuition tells me that they are likely common enough not to
disregard but I don't have a lot of data to back it up with.  In
a Bash build a full 23% of all checked calls are of this kind (24
out of 106).  In a Binutils build only 4% are (9 out of 228).  In
Glibc, a little under 3%.  My guess is that the number will be
inversely proportional to the quality of the code.
So I think you've made a case that we do want to handle this case.  So 
what's left is how best to avoid the infinite recursion and mitigate the 
pathological cases.


What you're computing seems to be "this object may have been derived 
from a signed type".  Right?  It's a property we can compute for any 
given SSA_NAME and it's not context/path specific beyond the 
context/path information encoded by the SSA graph.


So just thinking out load here, could we walk the IL once to identify 
call sites and build a worklist of SSA_NAMEs we care about.  Then we 
iterate on the worklist much like Aldy's code he's working on for the 
unswitching vs uninitialized variable issue?


Jeff

Re: [PATCH][tree-ssa-address] Use simplify_gen_binary in gen_addr_rtx

[Kyrill Tkachov]

On 05/01/17 12:09, Kyrill Tkachov wrote:


On 05/01/17 12:01, Richard Biener wrote:

On Wed, Jan 4, 2017 at 4:07 PM, Kyrill Tkachov
 wrote:

On 04/01/17 14:19, Richard Biener wrote:

On Wed, Dec 21, 2016 at 10:40 AM, Kyrill Tkachov
 wrote:

On 20/12/16 17:30, Richard Biener wrote:

On December 20, 2016 5:01:19 PM GMT+01:00, Kyrill Tkachov
 wrote:

Hi all,

The testcase in this patch generates bogus assembly for arm with -O1
-mfloat-abi=soft:
  strdr4, [#0, r3]

This is due to non-canonical RTL being generated during expansion:
(set (mem:DI (plus:SI (const_int 0 [0])
 (reg/f:SI 153)) [0 MEM[symbol: a, index: _26, offset: 0B]+0 S8
A64])
   (reg:DI 154))

Note the (plus (const_int 0) (reg)). This is being generated in
gen_addr_rtx in tree-ssa-address.c
where it creates an explicit PLUS rtx through gen_rtx_PLUS, which
doesn't try to canonicalise its arguments
or simplify. The correct thing to do is to use simplify_gen_binary that
will handle all this properly.

But it has to match up the validity check which passes down exactly the
same RTL(?)  Or does this stem from propagation simplifying a MEM after
IVOPTs?


You mean TARGET_LEGITIMATE_ADDRESS_P? Yes, it gets passed on to that, but
the arm implementation of that
doesn't try to handle non-canonical RTL (plus (const0_rtx) (reg) is not
canonical).
Or do you mean some other check?

Ok, now looking at the actual patch and the code in question.  For your
testcase
it happens that symbol == const0_rtx?  In this case please amend the
if (symbol) check like we do for the base, thus

 if (symbol && symbol != const0_rtx)


No, symbol is not const0_rtx (it's just a symbol_ref).
index is const0_rtx and so gets assigned to *addr at the beginning of the
function.
base and step are NULL_RTX.
So at the time of the check:
if (*addr)
  *addr = gen_rtx_PLUS (address_mode, *addr, act_elem);
else
  *addr = act_elem;

*addr is const0_rtx. Do you want to amend that check to:
 if (*addr && *addr != const0_rtx) ?

Hmm, I guess given the if (step) in if (index) *addr can end up being
a not simplified mult.  So instead do

if (index && index != const0_rtx)


That works, I'll test a patch for this.



Here it is. Bootstrapped and tested on arm-none-linux-gnueabihf and 
aarch64-none-linux-gnu.
Ok?

Thanks,
Kyrill

2017-01-06  Kyrylo Tkachov  

* tree-ssa-address.c (gen_addr_rtx): Don't handle index if it
is const0_rtx.

2017-01-06  Kyrylo Tkachov  

* gcc.dg/20161219.c: New test.


I haven't looked where the const0_rtx index comes from, so I don't know if
it
could have other CONST_INT values that may cause trouble.

Usually this happens when constant folding / propagation happens after
IVOPTs generates the TARGET_MEM_REF.  We do have some canonicalization
foldings for TMR, see maybe_fold_tmr, but that should have made index NULL
if it was constant...  So maybe we fail to fold a stmt at some point.

Btw, I fail to see the bogus asm with my arm-non-eabi cross with -O
-mfloat-abi=soft
so I can't tell how the TMR arrives at RTL expansion.


You'll also want to specify -marm (this doesn't trigger on Thumb) and perhaps 
-march=armv7-a.

Thanks,
Kyrill


Richard.


Kyrill



Richard.


Thanks,
Kyrill



I didn't change the other gen_rtx_PLUS calls in this function as their
results is later used in XEXP operations
that seem to rely on a PLUS expression being explicitly produced, but
this particular call doesn't, so it's okay
to change it. With this patch the sane assembly is generated:
   strdr4, [r3]

Bootstrapped and tested on arm-none-linux-gnueabihf, x86_64,
aarch64-none-linux-gnu.

Ok for trunk?

Thanks,
Kyrill

2016-12-20  Kyrylo Tkachov 

  * tree-ssa-address.c (gen_addr_rtx): Use simplify_gen_binary to
add
   *addr to act_elem.

2016-12-20  Kyrylo Tkachov 

   * gcc.dg/20161219.c: New test.






diff --git a/gcc/testsuite/gcc.dg/20161219.c b/gcc/testsuite/gcc.dg/20161219.c
new file mode 100644
index ..93ea8d2364d9ab54704a84e6c0bff0427df82db8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/20161219.c
@@ -0,0 +1,30 @@
+/* { dg-do assemble } */
+/* { dg-options "-O1 -w" } */
+
+static long long a[9];
+int b, c, d, e, g;
+
+static int
+fn1 (int *p1)
+{
+  b = 1;
+  for (; b >= 0; b--)
+{
+  d = 0;
+  for (;; d++)
+	{
+	  e && (a[d] = 0);
+	  if (*p1)
+	break;
+	  c = (int) a;
+	}
+}
+  return 0;
+}
+
+int
+main ()
+{
+  int f = fn1 ((int *) f);
+  return f;
+}
diff --git a/gcc/tree-ssa-address.c b/gcc/tree-ssa-address.c
index 3e3cad150b64e813509e079f9ea91d65806e414a..8d46a3e67337dd7639d0b17ca888f50009d65b93 100644
--- a/gcc/tree-ssa-address.c
+++ b/gcc/tree-ssa-address.c
@@ -115,7 +115,7 @@ gen_addr_rtx (machine_mode address_mode,
   if (offset_p)
 *offset_p = NULL;
 
-  if (index)
+  if (index && index != const0_rtx)
 {
   act_elem = index;
   if (step)

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 05:33:03PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 06, 2017 at 05:12:54PM +0100, Christophe Lyon wrote:
> > This makes all my builds fail.
> > (The *linux* ones are broken after Alexandre's pragma, and
> > this commit breaks the remaining bare-metal configurations).
> > make[2]: Entering directory
> > `/tmp/3119026_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc1/libdecnumber'
> > source='/tmp/3119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber/decNumber.c'
> > object='decNumber.o' libtool=no gcc  -I/tmp/3
> > 119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber -I.
> > -fno-lto -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissi
> > ng-prototypes -Wold-style-definition -Wmissing-format-attribute
> > -Wcast-qual -pedantic -Wno-long-long
> > -I/tmp/3119026_6.tmpdir/aci-gcc-fs
> > f/sources/gcc-fsf/gccsrc/libdecnumber -I. -fno-lto  -c
> > /tmp/3119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber/decNumber.c
> > cc1: error: unrecognized command line option "-fno-lto"
> > cc1: error: unrecognized command line option "-fno-lto"
> > 
> > Still using gcc-4.4.7 on RHEL6
> 
> Actually, I'm surprised it is doing anything, because the toplevel
> Makefile should be doing:
> $(HOST_EXPORTS)  \
> (cd $(HOST_SUBDIR)/libdecnumber && \
>   $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) 
> $(STAGE1_FLAGS_TO_PASS)  \
> $(TARGET-libdecnumber))
> and both HOST_EXPORTS and BASE_FLAGS_TO_PASS include
> "CFLAGS=$(CFLAGS)" \
> "CXXFLAGS=$(CXXFLAGS)" \
> "LDFLAGS=$(LDFLAGS)" \
> so it should override the libdecnumber/Makefile vars that way.
> In any case, I think libdecnumber/configure* should check for whether
> -fno-lto works and if yes, should substitute it into some var that is then
> CFLAGS += $(NO_LTO)
> CXXFLAGS += $(NO_LTO)
> LDFLAGS += $(NO_LTO)

Trying now:

2017-01-06  Jakub Jelinek  

* Makefile.in (CFLAGS, CPPFLAGS, LDFLAGS): Remove -fno-lto.
(NOLTO_FLAGS): New variable.
(ALL_CFLAGS): Use it.
* configure.ac (nolto_flags): New ACX_PROG_CC_WARNING_OPTS,
check for whether -fno-lto works.
* configure: Regenerated.

--- libdecnumber/Makefile.in.jj 2017-01-06 16:58:42.0 +0100
+++ libdecnumber/Makefile.in2017-01-06 17:40:31.520582350 +0100
@@ -31,19 +31,20 @@ ACLOCAL = @ACLOCAL@
 AUTOCONF = @AUTOCONF@
 AUTOHEADER = @AUTOHEADER@
 CC = @CC@
-CFLAGS = @CFLAGS@ -fno-lto
+CFLAGS = @CFLAGS@
 WARN_CFLAGS = @WARN_CFLAGS@ @WARN_PEDANTIC@ @WERROR@
 CPP = @CPP@
-CPPFLAGS = @CPPFLAGS@ -fno-lto
+CPPFLAGS = @CPPFLAGS@
 INSTALL_DATA = @INSTALL_DATA@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
-LDFLAGS = @LDFLAGS@ -fno-lto
+LDFLAGS = @LDFLAGS@
 LIBICONV = @LIBICONV@
 PACKAGE = @PACKAGE@
 PICFLAG = @PICFLAG@
 RANLIB = @RANLIB@
 SHELL = @SHELL@
 objext = @OBJEXT@
+NOLTO_FLAGS = @nolto_flags@
 
 datarootdir = @datarootdir@
 datadir = @datadir@
@@ -58,7 +59,8 @@ enable_decimal_float= @enable_decimal_fl
 
 INCLUDES = -I$(srcdir) -I.
 
-ALL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(INCLUDES) $(CPPFLAGS) $(PICFLAG)
+ALL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(NOLTO_FLAGS) $(INCLUDES) $(CPPFLAGS) \
+$(PICFLAG)
 
 bid_OBJS = bid2dpd_dpd2bid.$(objext) host-ieee32.$(objext) \
host-ieee64.$(objext) host-ieee128.$(objext)
--- libdecnumber/configure.ac.jj2017-01-02 18:15:32.0 +0100
+++ libdecnumber/configure.ac   2017-01-06 17:38:37.391078242 +0100
@@ -43,6 +43,8 @@ ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wwri
  -Wmissing-format-attribute -Wcast-qual])
 ACX_PROG_CC_WARNING_ALMOST_PEDANTIC([-Wno-long-long])
 
+ACX_PROG_CC_WARNING_OPTS([-fno-lto], [nolto_flags])
+
 # Only enable with --enable-werror-always until existing warnings are
 # corrected.
 ACX_PROG_CC_WARNINGS_ARE_ERRORS([manual])
--- libdecnumber/configure.jj   2016-11-16 16:38:07.0 +0100
+++ libdecnumber/configure  2017-01-06 17:41:44.430626719 +0100
@@ -613,6 +613,7 @@ EGREP
 GREP
 CPP
 WERROR
+nolto_flags
 WARN_PEDANTIC
 WARN_CFLAGS
 AUTOHEADER
@@ -3377,6 +3378,64 @@ fi
 ac_ext=c
 ac_cpp='$CPP $CPPFLAGS'
 ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext 
$LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+
+
+ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext 
$LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+nolto_flags=
+save_CFLAGS="$CFLAGS"
+for real_option in -fno-lto; do
+  # Do the check with the no- prefix removed since gcc silently
+  # accepts any -Wno-* option on purpose
+  case $real_option in
+-Wno-*) option=-W`expr x$real_option : 'x-Wno-\(.*\)'` ;;
+*) option=$real_option ;;
+  esac
+  as_acx_Woption=`$as_echo "acx_cv_prog_cc_warning_$option" | $as_tr_sh`
+
+  { $as_echo "$as_me:${as_li

Ping! Re: [PATCH, Fortran, pr78781, v1] [7 Regression] [Coarray] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1588

[Andre Vehreschild]

Ping!

On Wed, 28 Dec 2016 20:31:16 +0100
Andre Vehreschild  wrote:

> Hi all,
> 
> attached patch fixes and implements pointer components in derived typed
> coarrays. The testcase in the description also has a class coarray, which is
> still not implemented but tracked by pr77961. Therefore only the test in
> comment #2 now passes.

Also fixes pr78935.

Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?

Regards,
Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/fortran/ChangeLog:

2016-12-28  Andre Vehreschild  

PR fortran/78781
* expr.c (gfc_check_pointer_assign): Return the same error message for
rewritten coarray pointer assignments like for plain ones.
* gfortran.h: Change prototype.
* primary.c (caf_variable_attr): Set attributes used ones only only
ones.  Add setting of pointer_comp attribute.
(gfc_caf_attr): Add setting of pointer_comp attribute.
* trans-array.c (gfc_array_allocate): Add flag that the component to
allocate is not an ultimate coarray component.  Add allocation of
pointer arrays.
(structure_alloc_comps): Extend nullify to treat pointer components in
coarrays correctly.  Restructure nullify to remove redundant code.
(gfc_nullify_alloc_comp): Allow setting caf_mode flags.
* trans-array.h: Change prototype of gfc_nullify_alloc_comp ().
* trans-decl.c (generate_coarray_sym_init): Call nullify_alloc_comp for
derived type coarrays with pointer components.
* trans-expr.c (gfc_trans_structure_assign): Also treat pointer
components.
(trans_caf_token_assign): Handle assignment of token of scalar pointer
components.
(gfc_trans_pointer_assignment): Call above routine.
* trans-intrinsic.c (conv_expr_ref_to_caf_ref): Add treating pointer
components.
(gfc_conv_intrinsic_caf_get): Likewise.
(conv_caf_send): Likewise.
* trans-stmt.c (gfc_trans_allocate): After allocating a derived type in
a coarray pre-register the tokens.
(gfc_trans_deallocate): Simply determining the coarray type (scalar or
array) and deregistering it correctly.
* trans-types.c (gfc_typenode_for_spec): Replace in_coarray flag by the
actual codim to allow lookup of array types in the cache.
(gfc_build_array_type): Likewise.
(gfc_get_array_descriptor_base): Likewise.
(gfc_get_array_type_bounds): Likewise.
(gfc_get_derived_type): Likewise.
* trans-types.h: Likewise.
* trans.c (gfc_deallocate_with_status): Enable deregistering of all kind
of coarray components.
(gfc_deallocate_scalar_with_status): Use free() in fcoarray_single mode
instead of caf_deregister.

libgfortran/ChangeLog:

2016-12-28  Andre Vehreschild  

* caf/single.c (send_by_ref): Fix addressing of non-allocatable scalar
destination components.


gcc/testsuite/ChangeLog:

2016-12-28  Andre Vehreschild  

* gfortran.dg/coarray/ptr_comp_1.f08: New test.
* gfortran.dg/coarray/ptr_comp_2.f08: New test.
* gfortran.dg/coarray/ptr_comp_3.f08: New test.
* gfortran.dg/coarray/ptr_comp_4.f08: New test.
* gfortran.dg/coarray_ptr_comp_1.f08: New test.
* gfortran.dg/coarray_ptr_comp_2.f08: New test.
* gfortran.dg/coarray_ptr_comp_3.f08: New test.

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 3c221eb..7b95d20 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3708,9 +3708,20 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue)
 
   if (rvalue->expr_type == EXPR_FUNCTION && !attr.pointer)
 {
-  gfc_error ("Target expression in pointer assignment "
-		 "at %L must deliver a pointer result",
-		 &rvalue->where);
+  /* F2008, C725.  For PURE also C1283.  Sometimes rvalue is a function call
+	 to caf_get.  Map this to the same error message as below when it is
+	 still a variable expression.  */
+  if (rvalue->value.function.isym
+	  && rvalue->value.function.isym->id == GFC_ISYM_CAF_GET)
+	/* The test above might need to be extend when F08, Note 5.4 has to be
+	   interpreted in the way that target and pointer with the same coindex
+	   are allowed.  */
+	gfc_error ("Data target at %L shall not have a coindex",
+		   &rvalue->where);
+  else
+	gfc_error ("Target expression in pointer assignment "
+		   "at %L must deliver a pointer result",
+		   &rvalue->where);
   return false;
 }
 
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index d168138..f01a290 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2836,7 +2836,7 @@ int gfc_validate_kind (bt, int, bool);
 int gfc_get_int_kind_from_width_isofortranenv (int size);
 int gfc_get_real_kind_from_width_isofortranenv (int size);
 tree gfc_get_union_type (gfc_symbol *);
-tree gfc_get_derived_type (gfc_symbol * derived, bool in_coarr

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

[Christophe Lyon]

On 6 January 2017 at 17:46, Jakub Jelinek  wrote:
> On Fri, Jan 06, 2017 at 05:33:03PM +0100, Jakub Jelinek wrote:
>> On Fri, Jan 06, 2017 at 05:12:54PM +0100, Christophe Lyon wrote:
>> > This makes all my builds fail.
>> > (The *linux* ones are broken after Alexandre's pragma, and
>> > this commit breaks the remaining bare-metal configurations).
>> > make[2]: Entering directory
>> > `/tmp/3119026_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc1/libdecnumber'
>> > source='/tmp/3119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber/decNumber.c'
>> > object='decNumber.o' libtool=no gcc  -I/tmp/3
>> > 119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber -I.
>> > -fno-lto -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissi
>> > ng-prototypes -Wold-style-definition -Wmissing-format-attribute
>> > -Wcast-qual -pedantic -Wno-long-long
>> > -I/tmp/3119026_6.tmpdir/aci-gcc-fs
>> > f/sources/gcc-fsf/gccsrc/libdecnumber -I. -fno-lto  -c
>> > /tmp/3119026_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libdecnumber/decNumber.c
>> > cc1: error: unrecognized command line option "-fno-lto"
>> > cc1: error: unrecognized command line option "-fno-lto"
>> >
>> > Still using gcc-4.4.7 on RHEL6
>>
>> Actually, I'm surprised it is doing anything, because the toplevel
>> Makefile should be doing:
>> $(HOST_EXPORTS)  \
>> (cd $(HOST_SUBDIR)/libdecnumber && \
>>   $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) 
>> $(STAGE1_FLAGS_TO_PASS)  \
>> $(TARGET-libdecnumber))
>> and both HOST_EXPORTS and BASE_FLAGS_TO_PASS include
>> "CFLAGS=$(CFLAGS)" \
>> "CXXFLAGS=$(CXXFLAGS)" \
>> "LDFLAGS=$(LDFLAGS)" \
>> so it should override the libdecnumber/Makefile vars that way.
The actual invocation does not appear in the logs, so I can't see
what is actually wrong.

>> In any case, I think libdecnumber/configure* should check for whether
>> -fno-lto works and if yes, should substitute it into some var that is then
>> CFLAGS += $(NO_LTO)
>> CXXFLAGS += $(NO_LTO)
>> LDFLAGS += $(NO_LTO)
>
> Trying now:
>
> 2017-01-06  Jakub Jelinek  
>
> * Makefile.in (CFLAGS, CPPFLAGS, LDFLAGS): Remove -fno-lto.
> (NOLTO_FLAGS): New variable.
> (ALL_CFLAGS): Use it.
> * configure.ac (nolto_flags): New ACX_PROG_CC_WARNING_OPTS,
> check for whether -fno-lto works.
> * configure: Regenerated.
>
OK thanks for the prompt fix, I'll let you know if it doesn't work.

Christophe

> --- libdecnumber/Makefile.in.jj 2017-01-06 16:58:42.0 +0100
> +++ libdecnumber/Makefile.in2017-01-06 17:40:31.520582350 +0100
> @@ -31,19 +31,20 @@ ACLOCAL = @ACLOCAL@
>  AUTOCONF = @AUTOCONF@
>  AUTOHEADER = @AUTOHEADER@
>  CC = @CC@
> -CFLAGS = @CFLAGS@ -fno-lto
> +CFLAGS = @CFLAGS@
>  WARN_CFLAGS = @WARN_CFLAGS@ @WARN_PEDANTIC@ @WERROR@
>  CPP = @CPP@
> -CPPFLAGS = @CPPFLAGS@ -fno-lto
> +CPPFLAGS = @CPPFLAGS@
>  INSTALL_DATA = @INSTALL_DATA@
>  INSTALL_PROGRAM = @INSTALL_PROGRAM@
> -LDFLAGS = @LDFLAGS@ -fno-lto
> +LDFLAGS = @LDFLAGS@
>  LIBICONV = @LIBICONV@
>  PACKAGE = @PACKAGE@
>  PICFLAG = @PICFLAG@
>  RANLIB = @RANLIB@
>  SHELL = @SHELL@
>  objext = @OBJEXT@
> +NOLTO_FLAGS = @nolto_flags@
>
>  datarootdir = @datarootdir@
>  datadir = @datadir@
> @@ -58,7 +59,8 @@ enable_decimal_float= @enable_decimal_fl
>
>  INCLUDES = -I$(srcdir) -I.
>
> -ALL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(INCLUDES) $(CPPFLAGS) $(PICFLAG)
> +ALL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(NOLTO_FLAGS) $(INCLUDES) $(CPPFLAGS) 
> \
> +$(PICFLAG)
>
>  bid_OBJS = bid2dpd_dpd2bid.$(objext) host-ieee32.$(objext) \
> host-ieee64.$(objext) host-ieee128.$(objext)
> --- libdecnumber/configure.ac.jj2017-01-02 18:15:32.0 +0100
> +++ libdecnumber/configure.ac   2017-01-06 17:38:37.391078242 +0100
> @@ -43,6 +43,8 @@ ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wwri
>   -Wmissing-format-attribute -Wcast-qual])
>  ACX_PROG_CC_WARNING_ALMOST_PEDANTIC([-Wno-long-long])
>
> +ACX_PROG_CC_WARNING_OPTS([-fno-lto], [nolto_flags])
> +
>  # Only enable with --enable-werror-always until existing warnings are
>  # corrected.
>  ACX_PROG_CC_WARNINGS_ARE_ERRORS([manual])
> --- libdecnumber/configure.jj   2016-11-16 16:38:07.0 +0100
> +++ libdecnumber/configure  2017-01-06 17:41:44.430626719 +0100
> @@ -613,6 +613,7 @@ EGREP
>  GREP
>  CPP
>  WERROR
> +nolto_flags
>  WARN_PEDANTIC
>  WARN_CFLAGS
>  AUTOHEADER
> @@ -3377,6 +3378,64 @@ fi
>  ac_ext=c
>  ac_cpp='$CPP $CPPFLAGS'
>  ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
> +ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS 
> conftest.$ac_ext $LIBS >&5'
> +ac_compiler_gnu=$ac_cv_c_compiler_gnu
> +
> +
> +
> +ac_ext=c
> +ac_cpp='$CPP $CPPFLAGS'
> +ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
> +ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS 
> conftest.$ac_ext $LIBS >&5'
> +ac_compiler_gnu=$ac_cv_c_compi

Re: [PATCH] PR78968 add configure check for __cxa_thread_atexit in libc

[Jonathan Wakely]

On 04/01/17 15:42 +, Jonathan Wakely wrote:

FreeBSD 11 adds __cxa_thread_atexit to libc, so we should use that
instead of defining our own inferior version. This also avoids
multiple definitions of the symbol.

PR libstdc++/78968
* config.h.in: Regenerate.
* configure: Likewise.
* configure.ac: Check for __cxa_thread_atexit.
* libsupc++/atexit_thread.cc [_GLIBCXX_HAVE___CXA_THREAD_ATEXIT]:
Don't define __cxa_thread_atexit if libc provides it.

Tested powerpc64le-linux, committed to trunk.


This adds the check for freebsd cross-compilers. Tested by building
x86_64-unknown-freebsd11.0 on x86_64-uknown-linux-gnu.

Committed to trunk.

commit 5d92bb5541b2d21a8c4e76d9f64f4c1a865e2e92
Author: Jonathan Wakely 
Date:   Fri Jan 6 17:05:32 2017 +

Check for __cxa_thread_atexit for freebsd crosses

	PR libstdc++/78968
	* crossconfig.m4: Check for __cxa_thread_atexit on *-*-freebsd*.
	* configure: Regenerate.

diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index 8cc788c..a765a18 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -132,6 +132,7 @@ case "${host}" in
   AC_DEFINE(HAVE_ISINFL)
   AC_DEFINE(HAVE_ISNANL)
 fi
+AC_CHECK_FUNCS(__cxa_thread_atexit)
 ;;
   *-hpux*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'

Re: [PATCH] avoid infinite recursion in maybe_warn_alloc_args_overflow (pr 78775)

[Jeff Law]

Another approach would be to walk the SSA_NAME list and generate a 
bitmap of all the names which have a signed type or which were defined 
by a conversion to an unsigned type from a signed type.


At that point what's left is just the PHIs.  So we'd walk the dominator 
tree in RPO order to process the PHIs.  You don't have to recurse on the 
actual PHI arguments, just look at each one and see if it was already 
marked as being signed or derived from a signed type.  If all the args 
are marked as signed or derived from a signed type, then the PHI can be 
marked as well.


That may be more costly in the common case,  but should avoid the 
pathological cases Richi is worried about.


jeff

Re: [PATCH][M68K] allow long offsets in jump tables (wrong-code PR target/57583)

[Jeff Law]

On 01/06/2017 09:08 AM, Mikael Pettersson wrote:

This fixes / works-around the wrong-code PR57583 on M68K, caused by
overflowing the 16-bit jump table offsets the backend uses.

Ideally the backend should define CASE_VECTOR_SHORTEN_MODE, but that
AFAIK needs insn length attributes, which the backend only has for CF
but not for classic M68K.

Instead this patch adds an -mlong-jump-table-offsets option, and adjusts
the code for emitting and using jump table offsets to handle both short
and long offsets.  As long as the option is not selected, the backend
behaves exactly as before.

John Paul Adrian Glaubitz tested this patch by compiling "mednafen"
with it, which previously failed; I also tested earlier versions.

Is this Ok for trunk?

/Mikael


gcc/

2017-01-06  Mikael Pettersson  

PR target/57583
* config/m68k/m68k.opt (LONG_JUMP_TABLE_OFFSETS): New option.
* config/m68k/linux.h (ASM_RETURN_CASE_JUMP): Handle
TARGET_LONG_JUMP_TABLE_OFFSETS.
* config/m68k/m68kelf.h (ASM_RETURN_CASE_JUMP): Likewise.
* config/m68k/netbsd-elf.h (ASM_RETURN_CASE_JUMP): Likewise.
* config/m68k/m68k.h (CASE_VECTOR_MODE): Likewise.
(ASM_OUTPUT_ADDR_DIFF_ELF): Likewise.
* config/m68k/m68k.md (tablejump expander): Likewise.
(*tablejump_pcrel_hi): Renamed from unnamed insn, reject
TARGET_LONG_JUMP_TABLE_OFFSETS.
(*tablejump_pcrel_si): New insn, handle TARGET_LONG_JUMP_TABLE_OFFSETS.
* doc/invoke.texi (M68K options): Add -mlong-jump-table-offsets.

Can't tablejump_pcrel_si be simplified?  Isn't the output pattern just:

#ifdef ASM_RETURN_CASE_JUMP
  ASM_RETURN_CASE_JUMP;
#else
  return MOTOROLA ? "jmp (2,pc,%0.l)" : "jmp pc@(2,%0:l)";
#endif

With that simplification I think this will be fine.

jeff

Re: [committed] Introduce RTL function reader

[Jeff Law]

On 01/06/2017 09:43 AM, David Malcolm wrote:

On Fri, 2017-01-06 at 17:25 +0100, Jakub Jelinek wrote:

On Thu, Jan 05, 2017 at 03:20:26PM -0500, David Malcolm wrote:

+  /* Handle "reuse_rtx".  */
+  if (strcmp (code_name, "reuse_rtx") == 0)
+{
+  read_name (&name);
+  long idx = atoi (name.string);
+  /* Look it up by ID.  */
+  gcc_assert (idx < m_reuse_rtx_by_id.length ());
+  return_rtx = m_reuse_rtx_by_id[idx];
+  return return_rtx;
+}


This broke bootstrap on i686-linux (and other ILP32 hosts), because
vec.h length () returns unsigned.


Sorry about the breakage.

I'm not able to approve the patch, but the fix looks to me like it
would be covered under the "obvious" rule.
Can't the code string be "-1" for an insn that hasn't passed through 
recog yet?  You can probably get those in a dump at various times.


Jeff

Re: [committed] Introduce RTL function reader

[David Malcolm]

On Fri, 2017-01-06 at 10:25 -0700, Jeff Law wrote:
> On 01/06/2017 09:43 AM, David Malcolm wrote:
> > On Fri, 2017-01-06 at 17:25 +0100, Jakub Jelinek wrote:
> > > On Thu, Jan 05, 2017 at 03:20:26PM -0500, David Malcolm wrote:
> > > > +  /* Handle "reuse_rtx".  */
> > > > +  if (strcmp (code_name, "reuse_rtx") == 0)
> > > > +{
> > > > +  read_name (&name);
> > > > +  long idx = atoi (name.string);
> > > > +  /* Look it up by ID.  */
> > > > +  gcc_assert (idx < m_reuse_rtx_by_id.length ());
> > > > +  return_rtx = m_reuse_rtx_by_id[idx];
> > > > +  return return_rtx;
> > > > +}
> > > 
> > > This broke bootstrap on i686-linux (and other ILP32 hosts),
> > > because
> > > vec.h length () returns unsigned.
> > 
> > Sorry about the breakage.
> > 
> > I'm not able to approve the patch, but the fix looks to me like it
> > would be covered under the "obvious" rule.
> Can't the code string be "-1" for an insn that hasn't passed through 
> recog yet?  You can probably get those in a dump at various times.

This is a different kind of ID, for handling identity of SCRATCH
instances within a dump; see the discussion here:
  https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01801.html

They're all non-negative (see class rtx_reuse_manager, though I see now
that I used an "int" rather than an "unsigned" for them - but they
start at zero and go up).

Re: Short-circuit alt_fail case in record_reg_classes

[Jeff Law]

On 12/23/2016 10:50 AM, Richard Sandiford wrote:

record_reg_classes is often the hottest function when generating
unoptimised output.  It seems typical for over 60% of the instructions
it handles to be moves, and of course moves tend to be the instructions
with the longest constraint strings.

Maybe we should avoid using move constraints to set costs in unoptimised
output and instead use the "natural" class for the mode being moved.
That's too invasive for stage 3 though.

However, seeing so many moves means that we see many "failing"
alternatives, usually because of '*' or because of hard registers
in function call sequences.  The frequency of alternatives that are
detected as failures after the first operand tends again to be more
than 60%.  Previously we would continue to process the other operands
of the alternative regardless.  This patch instead adds a short-cut.

As well as avoiding unnecessary work, it means that the alt_fail
variable can be jump-threaded away.

Tested on aach64-linux-gnu and x86_64-linux-gnu.  It reduces compile
time by about 1% on some tests with "-g -O0".  OK to install?

Thanks,
Richard


gcc/
* ira-costs.c (record_reg_classes): Break from the inner loop
early once alt_fail is known to be true.  Update outer loop
handling accordingly.

OK.
jeff

[PATCH] Add missing include to testcase

[Jonathan Wakely]

This performance test has been broken since we modified VERIFY to not
depend on assert. This fixes it.

* testsuite/util/performance/priority_queue/mem_usage/pop_test.hpp:
Include  header.

Tested x86_64-linux. Committed to trunk.

commit d89e1655fd1475a16a4a2b338f679451206d792c
Author: Jonathan Wakely 
Date:   Fri Jan 6 17:11:40 2017 +

Add missing  include to testcase

* testsuite/util/performance/priority_queue/mem_usage/pop_test.hpp:
Include  header.

diff --git 
a/libstdc++-v3/testsuite/util/performance/priority_queue/mem_usage/pop_test.hpp 
b/libstdc++-v3/testsuite/util/performance/priority_queue/mem_usage/pop_test.hpp
index f9ed1db..15c0552 100644
--- 
a/libstdc++-v3/testsuite/util/performance/priority_queue/mem_usage/pop_test.hpp
+++ 
b/libstdc++-v3/testsuite/util/performance/priority_queue/mem_usage/pop_test.hpp
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 namespace __gnu_pbds
 {

Re: [PATCH][tree-ssa-address] Use simplify_gen_binary in gen_addr_rtx

[Richard Biener]

On January 6, 2017 5:45:46 PM GMT+01:00, Kyrill Tkachov 
 wrote:
>
>On 05/01/17 12:09, Kyrill Tkachov wrote:
>>
>> On 05/01/17 12:01, Richard Biener wrote:
>>> On Wed, Jan 4, 2017 at 4:07 PM, Kyrill Tkachov
>>>  wrote:
 On 04/01/17 14:19, Richard Biener wrote:
> On Wed, Dec 21, 2016 at 10:40 AM, Kyrill Tkachov
>  wrote:
>> On 20/12/16 17:30, Richard Biener wrote:
>>> On December 20, 2016 5:01:19 PM GMT+01:00, Kyrill Tkachov
>>>  wrote:
 Hi all,

 The testcase in this patch generates bogus assembly for arm
>with -O1
 -mfloat-abi=soft:
   strdr4, [#0, r3]

 This is due to non-canonical RTL being generated during
>expansion:
 (set (mem:DI (plus:SI (const_int 0 [0])
  (reg/f:SI 153)) [0 MEM[symbol: a, index: _26, offset:
>0B]+0 S8
 A64])
(reg:DI 154))

 Note the (plus (const_int 0) (reg)). This is being generated in
 gen_addr_rtx in tree-ssa-address.c
 where it creates an explicit PLUS rtx through gen_rtx_PLUS,
>which
 doesn't try to canonicalise its arguments
 or simplify. The correct thing to do is to use
>simplify_gen_binary that
 will handle all this properly.
>>> But it has to match up the validity check which passes down
>exactly the
>>> same RTL(?)  Or does this stem from propagation simplifying a
>MEM after
>>> IVOPTs?
>>
>> You mean TARGET_LEGITIMATE_ADDRESS_P? Yes, it gets passed on to
>that, but
>> the arm implementation of that
>> doesn't try to handle non-canonical RTL (plus (const0_rtx) (reg)
>is not
>> canonical).
>> Or do you mean some other check?
> Ok, now looking at the actual patch and the code in question.  For
>your
> testcase
> it happens that symbol == const0_rtx?  In this case please amend
>the
> if (symbol) check like we do for the base, thus
>
>  if (symbol && symbol != const0_rtx)

 No, symbol is not const0_rtx (it's just a symbol_ref).
 index is const0_rtx and so gets assigned to *addr at the beginning
>of the
 function.
 base and step are NULL_RTX.
 So at the time of the check:
 if (*addr)
   *addr = gen_rtx_PLUS (address_mode, *addr, act_elem);
 else
   *addr = act_elem;

 *addr is const0_rtx. Do you want to amend that check to:
  if (*addr && *addr != const0_rtx) ?
>>> Hmm, I guess given the if (step) in if (index) *addr can end up
>being
>>> a not simplified mult.  So instead do
>>>
>>> if (index && index != const0_rtx)
>>
>> That works, I'll test a patch for this.
>>
>
>Here it is. Bootstrapped and tested on arm-none-linux-gnueabihf and
>aarch64-none-linux-gnu.
>Ok?

OK.

Richard.

>Thanks,
>Kyrill
>
>2017-01-06  Kyrylo Tkachov  
>
> * tree-ssa-address.c (gen_addr_rtx): Don't handle index if it
> is const0_rtx.
>
>2017-01-06  Kyrylo Tkachov  
>
> * gcc.dg/20161219.c: New test.
>
 I haven't looked where the const0_rtx index comes from, so I don't
>know if
 it
 could have other CONST_INT values that may cause trouble.
>>> Usually this happens when constant folding / propagation happens
>after
>>> IVOPTs generates the TARGET_MEM_REF.  We do have some
>canonicalization
>>> foldings for TMR, see maybe_fold_tmr, but that should have made
>index NULL
>>> if it was constant...  So maybe we fail to fold a stmt at some
>point.
>>>
>>> Btw, I fail to see the bogus asm with my arm-non-eabi cross with -O
>>> -mfloat-abi=soft
>>> so I can't tell how the TMR arrives at RTL expansion.
>>
>> You'll also want to specify -marm (this doesn't trigger on Thumb) and
>perhaps -march=armv7-a.
>>
>> Thanks,
>> Kyrill
>>
>>> Richard.
>>>
 Kyrill


> Richard.
>
>> Thanks,
>> Kyrill
>>
>>
 I didn't change the other gen_rtx_PLUS calls in this function
>as their
 results is later used in XEXP operations
 that seem to rely on a PLUS expression being explicitly
>produced, but
 this particular call doesn't, so it's okay
 to change it. With this patch the sane assembly is generated:
strdr4, [r3]

 Bootstrapped and tested on arm-none-linux-gnueabihf, x86_64,
 aarch64-none-linux-gnu.

 Ok for trunk?

 Thanks,
 Kyrill

 2016-12-20  Kyrylo Tkachov 

   * tree-ssa-address.c (gen_addr_rtx): Use
>simplify_gen_binary to
 add
*addr to act_elem.

 2016-12-20  Kyrylo Tkachov 

* gcc.dg/20161219.c: New test.
>>>
>>

Re: [PATCH, rs6000] pr65479 Add -fasynchronous-unwind-tables when the -fsanitize=address option is seen.

[Bill Seurer]

On 01/06/2017 01:48 AM, Segher Boessenkool wrote:

On Thu, Jan 05, 2017 at 01:21:40PM -0600, Bill Seurer wrote:

(backport from trunk to gcc 6)

This patch adds the -fasynchronous-unwind-tables option to compilations when
the -fsanitize=address option is seen but not if any
-fasynchronous-unwind-tables options were already specified.
-fasynchronous-unwind-tables causes a full strack trace to be produced when
the sanitizer detects an error.  Without the full trace several of the asan
test cases fail on powerpc.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu,
powerpc64be-unknown-linux-gnu, and x86_64-pc-linux-gnu with no regressions.
Is this ok for trunk?


It already is on trunk...  You mean the branches :-)  It is okay for all
open release branches (i.e., 5 and 6).  Or does it not apply to GCC 5?

Thanks,


Segher


Yes, I meant the 6 branch.  I only tried it on 6 but it should be fine 
for 5 too.




2017-01-05  Bill Seurer  

PR sanitizer/65479
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
-fasynchronous-unwind-tables option when -fsanitize=address is
specified.





--

-Bill Seurer

Re: [PR78365] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[Martin Jambor]

Hi,

On Wed, Dec 14, 2016 at 01:12:11PM +0100, Richard Biener wrote:
> On Wed, Dec 14, 2016 at 11:15 AM, Martin Jambor  wrote:

> > ...

> > +/* Emulate effects of unary OPERATION and/or conversion from SRC_TYPE to
> > +   DST_TYPE on value range in SRC_VR and store it to DST_VR.  Return true 
> > if
> > +   the result is a range or an anti-range.  */
> > +
> > +static bool
> > +ipa_vr_operation_and_type_effects (value_range *dst_vr, value_range 
> > *src_vr,
> > +  enum tree_code operation,
> > +  tree dst_type, tree src_type)
> > +{
> > +  memset (dst_vr, 0, sizeof (*dst_vr));
> 
> The memset is not necessary.

Apparently it is.  Without it, I ended up with corrupted
dst->vr_bitmup.  I got ICEs when I removed the memset and tracked it
down to:

(gdb) p dst_vr->equiv->first->next
$14 = (bitmap_element *) 0x16

after extract_range_from_unary_expr returns.

> 
> > +  extract_range_from_unary_expr (dst_vr, operation, dst_type, src_vr, 
> > src_type);
> > +  if (dst_vr->type == VR_RANGE || dst_vr->type == VR_ANTI_RANGE)
> > +return true;
> > +  else
> > +return false;
> > +}
> > +
> >  /* Propagate value range across jump function JFUNC that is associated with
> > edge CS with param of callee of PARAM_TYPE and update DEST_PLATS
> > accordingly.  */
> > @@ -1849,7 +1866,6 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
> > struct ipcp_param_lattices *dest_plats,
> > tree param_type)
> >  {
> > -  struct ipcp_param_lattices *src_lats;
> >ipcp_vr_lattice *dest_lat = &dest_plats->m_value_range;
> >
> >if (dest_lat->bottom_p ())
> > @@ -1862,31 +1878,23 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
> >
> >if (jfunc->type == IPA_JF_PASS_THROUGH)
> >  {
> > -  struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
> > -  int src_idx = ipa_get_jf_pass_through_formal_id (jfunc);
> > -  src_lats = ipa_get_parm_lattices (caller_info, src_idx);
> > +  enum tree_code operation = ipa_get_jf_pass_through_operation (jfunc);
> >
> > -  if (ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
> > -   return dest_lat->meet_with (src_lats->m_value_range);
> > -  else if (param_type
> > -  && (TREE_CODE_CLASS (ipa_get_jf_pass_through_operation 
> > (jfunc))
> > -  == tcc_unary))
> > +  if (TREE_CODE_CLASS (operation) == tcc_unary)
> > {
> > - value_range vr;
> > - memset (&vr, 0, sizeof (vr));
> > + struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
> > + int src_idx = ipa_get_jf_pass_through_formal_id (jfunc);
> >   tree operand_type = ipa_get_type (caller_info, src_idx);
> > - enum tree_code operation = ipa_get_jf_pass_through_operation 
> > (jfunc);
> > + struct ipcp_param_lattices *src_lats
> > +   = ipa_get_parm_lattices (caller_info, src_idx);
> >
> >   if (src_lats->m_value_range.bottom_p ())
> > return dest_lat->set_to_bottom ();
> > -
> > - extract_range_from_unary_expr (&vr,
> > -operation,
> > -param_type,
> > -&src_lats->m_value_range.m_vr,
> > -operand_type);
> > - if (vr.type == VR_RANGE
> > - || vr.type == VR_ANTI_RANGE)
> > + value_range vr;
> > + if (ipa_vr_operation_and_type_effects (&vr,
> > +
> > &src_lats->m_value_range.m_vr,
> > +operation, param_type,
> > +operand_type))
> > return dest_lat->meet_with (&vr);
> > }
> >  }
> > @@ -1906,8 +1914,11 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
> > }
> >  }
> >
> > -  if (jfunc->vr_known)
> > -return dest_lat->meet_with (&jfunc->m_vr);
> > +  value_range vr;
> > +  if (jfunc->vr_known
> > +  && ipa_vr_operation_and_type_effects (&vr, &jfunc->m_vr, NOP_EXPR,
> > +   param_type, jfunc->passed_type))
> 
> but instead of a new jfunc->passed_type you can use TREE_TYPE 
> (jfunc->m_vr.min)
> for example.

Great, thanks a lot for this suggestion.  I have used that and removed
the new field addition from the patch and used your suggestion
instead.

> 
> I notice that ipa_jump_func is badly laid out:
> 
> struct GTY (()) ipa_jump_func
> {
>   /* Aggregate contants description.  See struct ipa_agg_jump_function and its
>  description.  */
>   struct ipa_agg_jump_function agg;
> 
>   /* Information about zero/non-zero bits.  */
>   struct ipa_bits bits;
> 
>   /* Information about value range.  */
>   bool vr_known;
>   value_range m_vr;
> 
>   enum jump_func_type type;
>   /* R

Re: [PATCH] Add testcases to test builtin-expansion of memcmp and strncmp

[Aaron Sawdey]

Jeff,
  Thanks for the review. Committed as 244177 with requested changes.

2017-01-06  Aaron Sawdey  
* gcc.dg/memcmp-1.c: New.
* gcc.dg/strncmp-1.c: New.

Aaron

Re: [PATCH] better handling of ranges (PR 78703)

[Jeff Law]

On 12/23/2016 02:25 PM, Martin Sebor wrote:

Bug 78703 points out that the decimal point character in floating
directives can be longer than just one byte (in locales where the
decimal point is a multibyte character).  The decimal point can
result in anywhere between 1 and MB_LEN_MAX bytes.  This is unlikely
but locales with two-byte decimal point are known to exist, and
the gimple-ssa-sprintf pass must handle them correctly.

In a comment on the bug Jakub suggests that while printf return
value optimization must correctly deal with the worst case (i.e.,
MB_LEN_MAX of 6 for UTF-8), reflecting the worst case in the text
of warnings could be confusing to users most of whom expect
a single byte decimal point.

Finally, a limitation of the gimple-ssa-sprintf pass has been that
it only understands constant width and precision and treats others
as essentially unlimited even if they are constrained to a limited
range of values.  This results in false positives and negatives
that can be avoided.

The attached patch enhances the pass to overcome both of these
limitations.  It does that by first replacing the exact byte counter
with two other counters: 1) a likely counter that tracks the number
of bytes a directive is likely to result in, and 2) an "unlikely"
byte for lack of a better name, that tracks the unlikely maximum
byte count in cases like multibyte decimal point, and second by
adding range handling for width and precision specified by the
asterisk (such as in sprintf("%*.*i", w, p, i)).

The patch resulted in more extensive changes than I initially
intended but the result is a simplified implementation.  A good
amount of the changes is factoring code out into more general
functions that can be shared throughout the pass.

With these enhancements, although the support for ranges in the
pass is complete, it's not as robust as it could be.  I think
having the pass run later could improve things.

The pass does produce a fair number of warnings for calls to
snprintf in the linux kernel.  Some of these I suspect will be
considered false positives.  I think it might be worth splitting
up the snprintf warning from -Wformat-length and adding a separate
option to control it.

Martin

gcc-78703.diff


PR middle-end/78703 -  -fprintf-return-value floating point handling incorrect 
in locales with a mulltibyte decimal point

gcc/ChangeLog:

PR middle-end/78703
* gimple-ssa-sprintf.c (get_int_range): New function.
(struct result_range): Add members.
(struct format_result): Replace number_chars, number_chars_min, and
number_chars_max, with struct result_ramge.  Remove constant.

s/result_ramge/result_range/


(format_result::operator+=): Update and define out of class.
(struct fmtresult): Add constructors.  Remove constant and bounded
members.
(format_result::type_max_digits): New function.
(format_result::adjust_for_width_and_precision): New function.
(struct conversion_spec): Rename...
(struct directive): ...to this.
(struct directive): Add new data members.
(directive::set_width, directive::set_precison): New functions.
(bytes_remaining, get_int_range, format_character, format_plain): Same.
(should_warn_p, maybe_warn, parse_directive): Same.
(min_bytes_remaining, add_bytes): Remove.
(format_percent, get_string_length): Simplify.
(format_integer): Handle width and precision ranges.
(format_floating): Same.
(get_mpfr_format_length): Work around MPFR bugs and simplify.
(format_string): Factor single character handling into
format_character.  Handle width and precision ranges.
(format_directive): Factor out most warning code into maybe_warn.
(pass_sprintf_length::compute_format_length): Factor out parsing
into parse_directive.
(try_substitute_return_value): Handle unlikely maximum byte counter.
Simplify for better clarity.

gcc/testsuite/ChangeLog:

PR middle-end/78703
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Adjust.
* gcc.dg/tree-ssa/builtin-sprintf-5.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-9.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf.c: Adjust.
* gcc.dg/format/pr78569.c: Same.
You weren't kidding when you mentioned this patch was going to be 
painful to review.  Glad this is the last mega-patch in this space and 
that we'll be breaking them down into more manageable stuff from here out.


As I mentioned on the phone, you know the space better than I, so I'm 
largely going to assume the low level technical bits are correct and 
focus more on the higher level 

[PATCH] Outer vs. inner loop ifcvt (PR tree-optimization/78899)

[Jakub Jelinek]

Hi!

If-conversion can't easily predict whether outer loop vectorization will be
successful or not.  In GCC 6, we'd version and guard with LOOP_VECTORIZED
only the inner loop, which is beneficial if the outer loop vectorization
isn't successful, but inner loop vectorization is.
This changed last year, and now we sometimes version the outer loop instead.
The problem with that is that it regresses according to the PR some
important benchmarks where the outer loop can't be really vectorized but
if-conv doesn't know that, but because the inner loop needs masked
loads/stores, the inner loop isn't vectorized either.

The following patch tweaks tree-if-conv.c so that when it wants to version
an outer loop, it actually transforms:
  loop1
loop2
into:
  if (LOOP_VECTORIZED (1, 3))
{
  loop1
loop2
}
  else
loop3 (copy of loop1)
  if (LOOP_VECTORIZED (4, 5))
loop4 (copy of loop2)
  else
loop5 (copy of loop4)
and tweaks the vectorizer, so that it attempts to vectorize always the
outer loop (i.e. loop1) in this case first.  If that is successful,
it marks loop4 as non-vectorizable and folds the latter LOOP_VECTORIZED,
so that in the copies of the scalar loop the inner loop isn't vectorized.
If outer loop vectorization fails, loop1/loop2 are thrown away and we get
loop3 non-vectorized with either loop4 vectorized, or if even that fails,
with loop5 inside of it.

I think vectorization in the scalar loop of the outer loop is code size
waste, it will be just very small number of iterations of the outer loop.
If you think we should vectorize even there, we'd need other changes
- handle LOOP_VECTORIZED ifn during copying of loops in
tree-vect-loop-manip.c and ensure we'd run the vectorizer even on the
copied loops - right now the vectorizer runs only on the loops created
before vectorization starts (except for epilogue vectorization).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2017-01-06  Jakub Jelinek  

PR tree-optimization/78899
* tree-if-conv.c (version_loop_for_if_conversion): Instead of
returning bool return struct loop *, NULL for failure and the new
loop on success.
(versionable_outer_loop_p): Don't version outer loop if it has
dont_vectorized bit set.
(tree_if_conversion): When versioning outer loop, ensure
tree_if_conversion is performed also on the inner loop of the
non-vectorizable outer loop copy.
* tree-vectorizer.c (set_uid_loop_bbs): Formatting fix.  Fold
LOOP_VECTORIZED in inner loop of the scalar outer loop and
prevent vectorization of it.
(vectorize_loops): For outer + inner LOOP_VECTORIZED, ensure
the outer loop vectorization of the non-scalar version is attempted
before vectorization of the inner loop in scalar version.
* tree-vect-loop-manip.c (rename_variables_in_bb): If outer_loop
has 2 inner loops, rename also on edges from bb whose single pred
is outer_loop->header.  Fix typo in function comment.

* gcc.target/i386/pr78899.c: New test.
* gcc.dg/pr71077.c: New test.
* gcc.dg/gomp/pr68128-1.c: Adjust allowed number of vectorized
loops.

--- gcc/tree-if-conv.c.jj   2017-01-04 18:12:50.180878924 +0100
+++ gcc/tree-if-conv.c  2017-01-06 09:24:08.410557481 +0100
@@ -2535,7 +2535,7 @@ combine_blocks (struct loop *loop)
loop to execute.  The vectorizer pass will fold this
internal call into either true or false.  */
 
-static bool
+static struct loop *
 version_loop_for_if_conversion (struct loop *loop)
 {
   basic_block cond_bb;
@@ -2566,7 +2566,7 @@ version_loop_for_if_conversion (struct l
 ifc_bbs[i]->aux = saved_preds[i];
 
   if (new_loop == NULL)
-return false;
+return NULL;
 
   new_loop->dont_vectorize = true;
   new_loop->force_vectorize = false;
@@ -2574,7 +2574,7 @@ version_loop_for_if_conversion (struct l
   gimple_call_set_arg (g, 1, build_int_cst (integer_type_node, new_loop->num));
   gsi_insert_before (&gsi, g, GSI_SAME_STMT);
   update_ssa (TODO_update_ssa);
-  return true;
+  return new_loop;
 }
 
 /* Return true when LOOP satisfies the follow conditions that will
@@ -2594,6 +2594,7 @@ static bool
 versionable_outer_loop_p (struct loop *loop)
 {
   if (!loop_outer (loop)
+  || loop->dont_vectorize
   || !loop->inner
   || loop->inner->next
   || !single_exit (loop)
@@ -2602,7 +2603,7 @@ versionable_outer_loop_p (struct loop *l
   || !single_pred_p (loop->latch)
   || !single_pred_p (loop->inner->latch))
 return false;
-  
+
   basic_block outer_exit = single_pred (loop->latch);
   basic_block inner_exit = single_pred (loop->inner->latch);
 
@@ -2789,7 +2790,10 @@ tree_if_conversion (struct loop *loop)
 {
   unsigned int todo = 0;
   b

Re: [committed] Introduce RTL function reader

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 12:34:01PM -0500, David Malcolm wrote:
> On Fri, 2017-01-06 at 10:25 -0700, Jeff Law wrote:
> > On 01/06/2017 09:43 AM, David Malcolm wrote:
> > > On Fri, 2017-01-06 at 17:25 +0100, Jakub Jelinek wrote:
> > > > On Thu, Jan 05, 2017 at 03:20:26PM -0500, David Malcolm wrote:
> > > > > +  /* Handle "reuse_rtx".  */
> > > > > +  if (strcmp (code_name, "reuse_rtx") == 0)
> > > > > +{
> > > > > +  read_name (&name);
> > > > > +  long idx = atoi (name.string);
> > > > > +  /* Look it up by ID.  */
> > > > > +  gcc_assert (idx < m_reuse_rtx_by_id.length ());
> > > > > +  return_rtx = m_reuse_rtx_by_id[idx];
> > > > > +  return return_rtx;
> > > > > +}
> > > > 
> > > > This broke bootstrap on i686-linux (and other ILP32 hosts),
> > > > because
> > > > vec.h length () returns unsigned.
> > > 
> > > Sorry about the breakage.
> > > 
> > > I'm not able to approve the patch, but the fix looks to me like it
> > > would be covered under the "obvious" rule.
> > Can't the code string be "-1" for an insn that hasn't passed through 
> > recog yet?  You can probably get those in a dump at various times.
> 
> This is a different kind of ID, for handling identity of SCRATCH
> instances within a dump; see the discussion here:
>   https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01801.html
> 
> They're all non-negative (see class rtx_reuse_manager, though I see now
> that I used an "int" rather than an "unsigned" for them - but they
> start at zero and go up).

Note, I've already committed the patch.

Another option would be to print it as unsigned and read it as unsigned
using strtoul.  But even the printing of unsigned value as int and
atoi + cast to unsigned should work right.

Jakub

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

[Jakub Jelinek]

On Fri, Jan 06, 2017 at 05:58:05PM +0100, Christophe Lyon wrote:
> > Trying now:
> >
> > 2017-01-06  Jakub Jelinek  
> >
> > * Makefile.in (CFLAGS, CPPFLAGS, LDFLAGS): Remove -fno-lto.
> > (NOLTO_FLAGS): New variable.
> > (ALL_CFLAGS): Use it.
> > * configure.ac (nolto_flags): New ACX_PROG_CC_WARNING_OPTS,
> > check for whether -fno-lto works.
> > * configure: Regenerated.
> >
> OK thanks for the prompt fix, I'll let you know if it doesn't work.

The patch passed bootstrap (non- bootstrap-lto) on x86_64-linux and
i686-linux and I see -fno-lto being used everywhere I expected (with
bootstrap compiler that does support -fno-lto).
Ok for trunk, if it works even for Christophe?

Jakub

New French PO file for 'gcc' (version 7.1-b20170101)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the French team of translators.  The file is available at:

http://translationproject.org/latest/gcc/fr.po

(This file, 'gcc-7.1-b20170101.fr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH][M68K] allow long offsets in jump tables (wrong-code PR target/57583)

[Mikael Pettersson]

Jeff Law writes:
 > On 01/06/2017 09:08 AM, Mikael Pettersson wrote:
 > > This fixes / works-around the wrong-code PR57583 on M68K, caused by
 > > overflowing the 16-bit jump table offsets the backend uses.
 > >
 > > Ideally the backend should define CASE_VECTOR_SHORTEN_MODE, but that
 > > AFAIK needs insn length attributes, which the backend only has for CF
 > > but not for classic M68K.
 > >
 > > Instead this patch adds an -mlong-jump-table-offsets option, and adjusts
 > > the code for emitting and using jump table offsets to handle both short
 > > and long offsets.  As long as the option is not selected, the backend
 > > behaves exactly as before.
 > >
 > > John Paul Adrian Glaubitz tested this patch by compiling "mednafen"
 > > with it, which previously failed; I also tested earlier versions.
 > >
 > > Is this Ok for trunk?
 > >
 > > /Mikael
 > >
 > >
 > > gcc/
 > >
 > > 2017-01-06  Mikael Pettersson  
 > >
 > >PR target/57583
 > >* config/m68k/m68k.opt (LONG_JUMP_TABLE_OFFSETS): New option.
 > >* config/m68k/linux.h (ASM_RETURN_CASE_JUMP): Handle
 > >TARGET_LONG_JUMP_TABLE_OFFSETS.
 > >* config/m68k/m68kelf.h (ASM_RETURN_CASE_JUMP): Likewise.
 > >* config/m68k/netbsd-elf.h (ASM_RETURN_CASE_JUMP): Likewise.
 > >* config/m68k/m68k.h (CASE_VECTOR_MODE): Likewise.
 > >(ASM_OUTPUT_ADDR_DIFF_ELF): Likewise.
 > >* config/m68k/m68k.md (tablejump expander): Likewise.
 > >(*tablejump_pcrel_hi): Renamed from unnamed insn, reject
 > >TARGET_LONG_JUMP_TABLE_OFFSETS.
 > >(*tablejump_pcrel_si): New insn, handle TARGET_LONG_JUMP_TABLE_OFFSETS.
 > >* doc/invoke.texi (M68K options): Add -mlong-jump-table-offsets.
 > Can't tablejump_pcrel_si be simplified?  Isn't the output pattern just:
 > 
 > #ifdef ASM_RETURN_CASE_JUMP
 >ASM_RETURN_CASE_JUMP;
 > #else
 >return MOTOROLA ? "jmp (2,pc,%0.l)" : "jmp pc@(2,%0:l)";
 > #endif
 > 
 > With that simplification I think this will be fine.
 > 
 > jeff

Indeed, good catch.  Revised patch below.   /Mikael

gcc/

2017-01-06  Mikael Pettersson  

PR target/57583
* config/m68k/m68k.opt (LONG_JUMP_TABLE_OFFSETS): New option.
* config/m68k/linux.h (ASM_RETURN_CASE_JUMP): Handle
TARGET_LONG_JUMP_TABLE_OFFSETS.
* config/m68k/m68kelf.h (ASM_RETURN_CASE_JUMP): Likewise.
* config/m68k/netbsd-elf.h (ASM_RETURN_CASE_JUMP): Likewise.
* config/m68k/m68k.h (CASE_VECTOR_MODE): Likewise.
(ASM_OUTPUT_ADDR_DIFF_ELF): Likewise.
* config/m68k/m68k.md (tablejump expander): Likewise.
(*tablejump_pcrel_hi): Renamed from unnamed insn, reject
TARGET_LONG_JUMP_TABLE_OFFSETS.
(*tablejump_pcrel_si): New insn, handle TARGET_LONG_JUMP_TABLE_OFFSETS.
* doc/invoke.texi (M68K options): Add -mlong-jump-table-offsets.

--- gcc-7-20170101/gcc/config/m68k/linux.h.~1~  2017-01-01 13:07:43.0 
+0100
+++ gcc-7-20170101/gcc/config/m68k/linux.h  2017-01-06 20:16:25.278132607 
+0100
@@ -98,9 +98,13 @@ along with GCC; see the file COPYING3.
   {\
if (ADDRESS_REG_P (operands[0]))\
  return "jmp %%pc@(2,%0:l)";   \
+   else if (TARGET_LONG_JUMP_TABLE_OFFSETS)\
+ return "jmp %%pc@(2,%0:l)";   \
else\
  return "ext%.l %0\n\tjmp %%pc@(2,%0:l)";  \
   }\
+else if (TARGET_LONG_JUMP_TABLE_OFFSETS)   \
+  return "jmp %%pc@(2,%0:l)";  \
 else   \
   return "jmp %%pc@(2,%0:w)";  \
   } while (0)
--- gcc-7-20170101/gcc/config/m68k/m68k.h.~1~   2017-01-01 13:07:43.0 
+0100
+++ gcc-7-20170101/gcc/config/m68k/m68k.h   2017-01-06 20:16:25.278132607 
+0100
@@ -675,7 +675,7 @@ __transfer_from_trampoline ()   
\
 
 /* This address is OK as it stands.  */
 #define PIC_CASE_VECTOR_ADDRESS(index) index
-#define CASE_VECTOR_MODE HImode
+#define CASE_VECTOR_MODE (TARGET_LONG_JUMP_TABLE_OFFSETS ? SImode : HImode)
 #define CASE_VECTOR_PC_RELATIVE 1
 
 #define DEFAULT_SIGNED_CHAR 1
@@ -857,7 +857,11 @@ do { if (cc_prev_status.flags & CC_IN_68
   asm_fprintf (FILE, "\t.long %LL%d\n", VALUE)
 
 #define ASM_OUTPUT_ADDR_DIFF_ELT(FILE, BODY, VALUE, REL)  \
-  asm_fprintf (FILE, "\t.word %LL%d-%LL%d\n", VALUE, REL)
+  asm_fprintf (FILE,   \
+  TARGET_LONG_JUMP_TABLE_OFFSETS   \
+  ? "\t.long %LL%d-%LL%d\n"\
+  : "\t.word %LL%d-%LL%d\n",   \
+  VALUE, REL)
 
 /* We don't have a way to align to more than a two-byte boundary, so do the
best we can and don't complain.  */
--- gcc-7-20170101/gcc/config/m68k/m68k.md.~1~  2017-

Re: [patch,avr] PR78883: Implement a dummy scheduler

[Georg-Johann Lay]

Richard Sandiford schrieb:

Segher Boessenkool  writes:

On Wed, Jan 04, 2017 at 04:39:36PM +0100, Georg-Johann Lay wrote:

Well, if it can be done in the back-end, then that's generally my strong
preference.  And the blocker for LRA is that it doesn't support cc0,
hence LRA will require an almost complete rewrite of the avr back-end...

Heh, getting rid of cc0 isn't *that* dramatic a change.  It does require
knowing the target really well (or some serious time with arch manuals).

One day all cc0 support will be removed, and it's advantageous to use the
newer code instead anyway...


+// Currently, the only purpose of the insn scheduler is to work
+// around PR78883, i.e. we only need the side effect of defining
+// INSN_SCHEDULING.  Even with a dummy scheduler we will see reodering
+// of instructions, which is not wanted if not actually needed.
+{ OPT_LEVELS_ALL, OPT_fschedule_insns, NULL, 0 },
+{ OPT_LEVELS_ALL, OPT_fschedule_insns2, NULL, 0 },
+;; Notice that we disable -fschedule-insns and -fschedule-insns2 in
+;; avr-common.c::TARGET_OPTION_OPTIMIZATION_TABLE because some "random"
+;; reordering of instructions is not wanted.
+
+(define_automaton "avr_dfa")
+
+(define_cpu_unit "avr_cpu" "avr_dfa")
+
+(define_insn_reservation "avr_cpu_reserve" 1
+  (const_int 1)
+  "avr_cpu")

I think you won't see this "random" reordering if you use (const_int 0)


Unfortunately, not.  I tried that before switching off the schedulers.


for the condition instead, i.e. the reservation will never match (instead
of always as you have now).


Both ways feel wrong to me TBH.  The sequence that led to this patch is:

1. reload has a bug that no-one really wants to fix (understandable)
2. the bug is triggered by paradoxical subregs of mems
3. those subregs are normally disabled on targets that support insn
   scheduling
4. therefore, define an insn scheduler
5. we don't actually want insn scheduling, so either
   (a) make sure the insn scheduler is never actually used for insn
   scheduling, or
   (b) allow the insn scheduler to run anyway but encourage it to do nothing
   (other than take compile time)

(4) and (5) feel like too much of a hack to me.  They're going to have
other consequences, e.g. we'll no longer give the warning:

  instruction scheduling not supported on this target machine

if users try to use -fschedule-insns.  And since we don't support


Good catch.  I never saw a user setting -fschedule-*.  The only "user"
that actually would set it would be the testsuite.


meaningful insn scheduling even after this patch, giving the warning
seems more user-friendly than dropping it.


I actually considered implementing a scheduler, not because AVR
had a pipeline (it don't) but to reorder code by some of the
sched hooks and increase peep2 odds to combine 2 MOVs to one MOVW.


I think the consensus is that we don't want these subregs for AVR
regardless of whether scheduling is used, and probably wouldn't want
them even without this bug.  So why not instead change the condition
used by general_operand, like we were talking about yesterday?
It seems simpler and more direct.


As #if or #ifdefi guess? because hookizing such hot code is not
wanted.

Johann

Re: [PATCH] move snprintf truncation warnings under own option ()

[Jeff Law]

On 01/03/2017 05:04 PM, Martin Sebor wrote:

The -Wformat-length option warns about both overflow and truncation.
I had initially debated introducing two options, one for each of
the two kinds of problems, but decided to go with just one and
consider breaking it up based on feedback.

I feel that there has now been sufficient feedback (e.g., bugs 77708
and 78913) to justify breaking up the checkers and providing a new
option to control truncation independently.

The attached patch adds a new option, -Wformat-truncation=level that
accomplishes this.  At level 1 the new option only warns on certain
truncation, or on likely truncation in snprintf calls whose return
value is unused (using the return value suppresses the warning in
these cases).

This change eliminates the -Wformat-length warnings from a build
of the Linux kernel, replacing their 43 instances with 32 of the
-Wformat-truncation warning.  With one exception, they're all for
snprintf calls whose return values is unused (and thus possible
sources of bugs).

If/when this patch is approved I'd like to rename -Wformat-length
to -Wformat-overflow to make the option's refined purpose clear,
and for consistency with the -Wstringop-overflow option.

Martin

gcc-78913.diff


PR tree-optimization/78913 - Probably misleading error reported by 
-Wformat-length
PR middle-end/77708 - -Wformat-length %s warns for snprintf

gcc/c-family/ChangeLog:

PR tree-optimization/78913
PR middle-end/77708
* c.opt (-Wformat-truncation): New option.

gcc/testsuite/ChangeLog:

PR tree-optimization/78913
PR middle-end/77708
* gcc.dg/tree-ssa/builtin-snprintf-warn-1.c: New test.
* gcc.dg/tree-ssa/builtin-snprintf-warn-2.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: XFAIL test cases failing
due to bug 78969.

gcc/ChangeLog:

PR tree-optimization/78913
PR middle-end/77708
* doc/invoke.texi (Warning Options): Document -Wformat-truncation.
* gimple-ssa-sprintf.c (call_info::reval_used, call_info::warnopt):
New member functions.
(format_directive): Used them.
(add_bytes): Same.
(pass_sprintf_length::handle_gimple_call): Same.

OK.

jeff