Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Eric Botcazou]

> My apologies for the delay.  I have finally committed this patch.
> Before doing so, I merged with trunk and re-tested (x86-64 Linux) just
> in case.  There were no regressions.

Can you rename the testcases?  Git doesn't like the names:

*** These collisions happen when the name of two or more files
*** differ in casing only (Eg: "hello.txt" and "Hello.txt").
*** Please re-do your commit, chosing names that do not collide.
*** 
*** Commit: 09b6f37fdbc6b8955a13bce336f4679bb0da78d7
*** Subject: Manual merge of 'origin/fsf-gcc-head-branch' into gcc-head 
(no-tn-check).
*** 
*** The matching files are:
*** 
*** gcc/testsuite/gcc.dg/Wvla-2.c
*** gcc/testsuite/gcc.dg/wvla-2.c
*** 
*** gcc/testsuite/gcc.dg/Wvla-1.c
*** gcc/testsuite/gcc.dg/wvla-1.c
*** 
*** gcc/testsuite/gcc.dg/Wvla-3.c
*** gcc/testsuite/gcc.dg/wvla-3.c)

-- 
Eric Botcazou

Re: [Patch, fortran] PR69566 - Failure of SELECT TYPE with unlimited polymorphic function result

[Paul Richard Thomas]

Dear Andre,

Following our exchange yesterday, I have eliminated the modification
to trans_associate_var and have corrected the offending expressions in
resolve.c(fixup_array_ref).

Please find attached the corrected patch.

Cheers

Paul

2016-10-19  Paul Thomas  

PR fortran/69566
* resolve.c (fixup_array_ref): New function.
(resolve_select_type): Gather up the rank and array reference,
if any, from the selector. Fix up the 'associate name' and the
'associate entities' as necessary.
* trans-expr.c (gfc_conv_class_to_class): If the symbol backend
decl is a FUNCTION_DECL, use the 'fake_result_decl' instead.

2016-10-19  Paul Thomas  

PR fortran/69566
* gfortran.dg/select_type_37.f03: New test.

On 18 October 2016 at 18:16, Andre Vehreschild  wrote:
> Hi Paul,
>
>> For reasons I don't understand, sometimes the expression type comes
>> through as BT_DERIVED, whilst the symbol is BT_CLASS. I could repair
>> this in resolve.c(fixup_array_ref) if you think that would be cleaner.
>
> I think that I figured the rule:
>
> - when no _class-ref is present, then the type is BT_CLASS,
> - as soon as a _class-ref is present the type is BT_DERIVED.
>
> There is an attr.is_class. Would that be an alternative? I don't know how
> reliable it is set.
>
>> > I am regression testing my polymorhpic class patch at the moment, therefore
>> > I can't test.
>>
>> OK - I can wait. I have quite a few other things to do :-(
>
> I found an error in my patch that only manifests itself with an optimization
> level great than 0. Now I am searching, never having done anything there.
>
> - Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 241326)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_assoc_var (gfc_symbol* sym, bool
*** 8327,8332 
--- 8327,8374 
  }
  
  
+ /* Ensure that SELECT TYPE expressions have the correct rank and a full
+array reference, where necessary.  The symbols are artificial and so
+the dimension attribute and arrayspec can also be set.  In addition,
+sometimes the expr1 arrives as BT_DERIVED, when the symbol is BT_CLASS.
+This is corrected here as well.*/
+ 
+ static void
+ fixup_array_ref (gfc_expr **expr1, gfc_expr *expr2,
+int rank, gfc_ref *ref)
+ {
+   gfc_ref *nref = (*expr1)->ref;
+   gfc_symbol *sym1 = (*expr1)->symtree->n.sym;
+   gfc_symbol *sym2 = expr2 ? expr2->symtree->n.sym : NULL;
+   (*expr1)->rank = rank;
+   if (sym1->ts.type == BT_CLASS)
+ {
+   if ((*expr1)->ts.type != BT_CLASS)
+   (*expr1)->ts = sym1->ts;
+ 
+   CLASS_DATA (sym1)->attr.dimension = 1;
+   if (CLASS_DATA (sym1)->as == NULL && sym2)
+   CLASS_DATA (sym1)->as
+   = gfc_copy_array_spec (CLASS_DATA (sym2)->as);
+ }
+   else
+ {
+   sym1->attr.dimension = 1;
+   if (sym1->as == NULL && sym2)
+   sym1->as = gfc_copy_array_spec (sym2->as);
+ }
+ 
+   for (; nref; nref = nref->next)
+ if (nref->next == NULL)
+   break;
+ 
+   if (ref && nref && nref->type != REF_ARRAY)
+ nref->next = gfc_copy_ref (ref);
+   else if (ref && !nref)
+ (*expr1)->ref = gfc_copy_ref (ref);
+ }
+ 
+ 
  /* Resolve a SELECT TYPE statement.  */
  
  static void
*** resolve_select_type (gfc_code *code, gfc
*** 8341,8346 
--- 8383,8390 
gfc_namespace *ns;
int error = 0;
int charlen = 0;
+   int rank = 0;
+   gfc_ref* ref = NULL;
  
ns = code->ext.block.ns;
gfc_resolve (ns);
*** resolve_select_type (gfc_code *code, gfc
*** 8468,8473 
--- 8512,8542 
else
  code->ext.block.assoc = NULL;
  
+   /* Ensure that the selector rank and arrayspec are available to
+  correct expressions in which they might be missing.  */
+   if (code->expr2 && code->expr2->rank)
+ {
+   rank = code->expr2->rank;
+   for (ref = code->expr2->ref; ref; ref = ref->next)
+   if (ref->next == NULL)
+ break;
+   if (ref && ref->type == REF_ARRAY)
+   ref = gfc_copy_ref (ref);
+ 
+   /* Fixup expr1 if necessary.  */
+   if (rank)
+   fixup_array_ref (&code->expr1, code->expr2, rank, ref);
+ }
+   else if (code->expr1->rank)
+ {
+   rank = code->expr1->rank;
+   for (ref = code->expr1->ref; ref; ref = ref->next)
+   if (ref->next == NULL)
+ break;
+   if (ref && ref->type == REF_ARRAY)
+   ref = gfc_copy_ref (ref);
+ }
+ 
/* Add EXEC_SELECT to switch on type.  */
new_st = gfc_get_code (code->op);
new_st->expr1 = code->expr1;
*** resolve_select_type (gfc_code *code, gfc
*** 8533,8539 
st->n.sym->assoc->target = gfc_get_variable_expr (code->expr1->symtree);
st->n.sym->assoc->target->where = cod

Re: [PATCH] Make EVRP propagate into PHIs and remove dead stmts

[Richard Biener]

On Tue, 18 Oct 2016, Richard Biener wrote:

> On Tue, 18 Oct 2016, Trevor Saunders wrote:
> 
> > On Tue, Oct 18, 2016 at 02:34:58PM +0200, Richard Biener wrote:
> > > 
> > > The following patch makes EVRP remove stmts that will become dead
> > > after propagation.  For this to work we have to propagate into PHIs
> > > (sth we missed as well).
> > > 
> > > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> > > 
> > > Richard.
> > > 
> > > 2016-10-18  Richard Biener  
> > > 
> > >   * tree-vrp.c (evrp_dom_walker::evrp_dom_walker): Initialize
> > >   stmts_to_remove.
> > >   (evrp_dom_walker::~evrp_dom_walker): Free it.
> > >   (evrp_dom_walker::stmts_to_remove): Add.
> > >   (evrp_dom_walker::before_dom_children): Mark PHIs and stmts
> > >   whose output we fully propagate for removal.  Propagate
> > >   into BB destination PHI arguments.
> > >   (execute_early_vrp): Remove queued stmts.  Dump value ranges
> > >   before stmt removal.
> > > 
> > > Index: gcc/tree-vrp.c
> > > ===
> > > --- gcc/tree-vrp.c(revision 241302)
> > > +++ gcc/tree-vrp.c(working copy)
> > > @@ -10643,11 +10643,13 @@ public:
> > >  : dom_walker (CDI_DOMINATORS), stack (10)
> > >  {
> > >stmts_to_fixup.create (0);
> > > +  stmts_to_remove.create (0);
> > >need_eh_cleanup = BITMAP_ALLOC (NULL);
> > >  }
> > >~evrp_dom_walker ()
> > >  {
> > >stmts_to_fixup.release ();
> > > +  stmts_to_remove.release ();
> > >BITMAP_FREE (need_eh_cleanup);
> > >  }
> > >virtual edge before_dom_children (basic_block);
> > > @@ -10660,6 +10662,7 @@ public:
> > >auto_vec > stack;
> > >bitmap need_eh_cleanup;
> > >vec stmts_to_fixup;
> > > +  vec stmts_to_remove;
> > 
> > That might as well be an auto_vec right?
> > 
> > >  };
> > >  
> > >  
> > > @@ -10769,6 +10772,15 @@ evrp_dom_walker::before_dom_children (ba
> > >else
> > >   set_value_range_to_varying (&vr_result);
> > >update_value_range (lhs, &vr_result);
> > > +
> > > +  /* Mark PHIs whose lhs we fully propagate for removal.  */
> > > +  tree val;
> > > +  if ((val = op_with_constant_singleton_value_range (lhs))
> > > +   && may_propagate_copy (lhs, val))
> > 
> > wouldn't it be clearer to write that as
> > 
> > tree val = op_with_constant_singleton_value_range (lhs);
> > if (val && may_propagate_copy (lhs, val))
> > 
> > > + {
> > > +   stmts_to_remove.safe_push (phi);
> > > +   continue;
> > > + }
> > >  }
> > >  
> > >edge taken_edge = NULL;
> > > @@ -10806,7 +10818,6 @@ evrp_dom_walker::before_dom_children (ba
> > > update_value_range (output, &vr);
> > > vr = *get_value_range (output);
> > >  
> > > -
> > > /* Set the SSA with the value range.  */
> > > if (INTEGRAL_TYPE_P (TREE_TYPE (output)))
> > >   {
> > > @@ -10824,6 +10835,17 @@ evrp_dom_walker::before_dom_children (ba
> > >  && range_includes_zero_p (vr.min,
> > >vr.max) == 1)))
> > >   set_ptr_nonnull (output);
> > > +
> > > +   /* Mark stmts whose output we fully propagate for removal.  */
> > > +   tree val;
> > > +   if ((val = op_with_constant_singleton_value_range (output))
> > > +   && may_propagate_copy (output, val)
> > > +   && !stmt_could_throw_p (stmt)
> > > +   && !gimple_has_side_effects (stmt))
> > 
> > similar.
> 
> Fixed.  Testing the following.

Turns out I need to fix gcc.dg/tree-ssa/pr61839_2.c which didn't test
what it was supposed to anyway.

Committed to trunk.

Richard.

Re: [PATCH] Simplify conditions in EVRP, handle taken edge

[Christophe Lyon]

On 18 October 2016 at 09:34, Richard Biener  wrote:
> On Mon, 17 Oct 2016, Richard Biener wrote:
>
>>
>> This refactors propagation vs. substitution and handles condition
>> simplification properly as well as passing a known taken edge down
>> to the DOM walker (avoiding useless work and properly handling PHIs).
>>
>> If we do all the work it's stupid to not fold away dead code...
>>
>> Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
>
> The following is what I applied, also fixing a spelling mistake noticed
> by Bernhard.
>
Hi Richard,

This patch is causing regressions on aarch64. These tests now fail:
  gcc.target/aarch64/test_frame_12.c scan-assembler-times ldp\tx29,
x30, \\[sp, [0-9]+\\] 1
  gcc.target/aarch64/test_frame_12.c scan-assembler-times sub\tsp, sp, #[0-9]+ 1
  gcc.target/aarch64/test_frame_15.c scan-assembler-times stp\tx29,
x30, \\[sp, [0-9]+\\] 1
  gcc.target/aarch64/test_frame_15.c scan-assembler-times sub\tsp, sp, #[0-9]+ 1
  gcc.target/aarch64/test_frame_8.c scan-assembler-times ldr\tx30,
\\[sp, [0-9]+\\] 1
  gcc.target/aarch64/test_frame_8.c scan-assembler-times str\tx30,
\\[sp, [0-9]+\\] 1

Christophe

> Richard.
>
> 2016-10-18  Richard Biener  
>
> * tree-vrp.c (evrp_dom_walker::before_dom_children): Handle
> not visited but non-executable predecessors.  Return taken edge.
> Simplify conditions and refactor propagation vs. folding step.
>
> * gcc.dg/tree-ssa/pr20318.c: Disable EVRP.
> * gcc.dg/tree-ssa/pr21001.c: Likewise.
> * gcc.dg/tree-ssa/pr21090.c: Likewise.
> * gcc.dg/tree-ssa/pr21294.c: Likewise.
> * gcc.dg/tree-ssa/pr21563.c: Likewise.
> * gcc.dg/tree-ssa/pr23744.c: Likewise.
> * gcc.dg/tree-ssa/pr25382.c: Likewise.
> * gcc.dg/tree-ssa/pr68431.c: Likewise.
> * gcc.dg/tree-ssa/vrp03.c: Likewise.
> * gcc.dg/tree-ssa/vrp06.c: Likewise.
> * gcc.dg/tree-ssa/vrp07.c: Likewise.
> * gcc.dg/tree-ssa/vrp09.c: Likewise.
> * gcc.dg/tree-ssa/vrp19.c: Likewise.
> * gcc.dg/tree-ssa/vrp20.c: Likewise.
> * gcc.dg/tree-ssa/vrp92.c: Likewise.
> * gcc.dg/pr68217.c: Likewise.
> * gcc.dg/predict-9.c: Likewise.
> * gcc.dg/tree-prof/val-prof-5.c: Adjust.
> * gcc.dg/predict-1.c: Likewise.
>
>
>
> Index: gcc/tree-vrp.c
> ===
> --- gcc/tree-vrp.c  (revision 241242)
> +++ gcc/tree-vrp.c  (working copy)
> @@ -10741,12 +10741,13 @@ evrp_dom_walker::before_dom_children (ba
>gimple_stmt_iterator gsi;
>edge e;
>edge_iterator ei;
> -  bool has_unvisived_preds = false;
> +  bool has_unvisited_preds = false;
>
>FOR_EACH_EDGE (e, ei, bb->preds)
> -if (!(e->src->flags & BB_VISITED))
> +if (e->flags & EDGE_EXECUTABLE
> +   && !(e->src->flags & BB_VISITED))
>{
> -   has_unvisived_preds = true;
> +   has_unvisited_preds = true;
> break;
>}
>
> @@ -10756,7 +10757,7 @@ evrp_dom_walker::before_dom_children (ba
>gphi *phi = gpi.phi ();
>tree lhs = PHI_RESULT (phi);
>value_range vr_result = VR_INITIALIZER;
> -  if (!has_unvisived_preds
> +  if (!has_unvisited_preds
>   && stmt_interesting_for_vrp (phi))
> extract_range_from_phi_node (phi, &vr_result);
>else
> @@ -10764,81 +10765,90 @@ evrp_dom_walker::before_dom_children (ba
>update_value_range (lhs, &vr_result);
>  }
>
> +  edge taken_edge = NULL;
> +
>/* Visit all other stmts and discover any new VRs possible.  */
>for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>  {
>gimple *stmt = gsi_stmt (gsi);
> -  edge taken_edge;
>tree output = NULL_TREE;
>gimple *old_stmt = stmt;
>bool was_noreturn = (is_gimple_call (stmt)
>&& gimple_call_noreturn_p (stmt));
>
> -  /* TODO, if found taken_edge, we should visit (return it) and travel
> -again to improve VR as done in DOM/SCCVN optimizations.  It should
> -be done carefully as stmts might prematurely leave a BB like
> -in EH.  */
> -  if (stmt_interesting_for_vrp (stmt))
> +  if (gcond *cond = dyn_cast  (stmt))
> +   {
> + vrp_visit_cond_stmt (cond, &taken_edge);
> + if (taken_edge)
> +   {
> + if (taken_edge->flags & EDGE_TRUE_VALUE)
> +   gimple_cond_make_true (cond);
> + else if (taken_edge->flags & EDGE_FALSE_VALUE)
> +   gimple_cond_make_false (cond);
> + else
> +   gcc_unreachable ();
> +   }
> +   }
> +  else if (stmt_interesting_for_vrp (stmt))
> {
> + edge taken_edge;
>   value_range vr = VR_INITIALIZER;
>   extract_range_from_stmt (stmt, &taken_edge, &output, &vr);
>   if (output
>   && (vr.type == VR_RANGE || vr.type == VR_ANTI_RANGE))
> -

Re: [Ada] Set Always_Compatible_Rep to False everywhere

[Eric Botcazou]

> Agreed, let's do that for starters.

And a small follow-up change.


2016-10-19  Eric Botcazou  

* system-linux-armel.ads: Rename into...
* system-linux-arm.ads: ...this
* gcc-interface/Makefile.in (ARM/Android): Adjust to above renaming.
(ARM/Linux): Likewise.
(Aarch64/Linux): Likewise.

-- 
Eric BotcazouIndex: gcc-interface/Makefile.in
===
--- gcc-interface/Makefile.in	(revision 241326)
+++ gcc-interface/Makefile.in	(working copy)
@@ -1222,7 +1222,7 @@ ifeq ($(strip $(filter-out arm% linux-an
   s-tpopsp.adbhttp://www.gnu.org/licenses/>.  --
---  --
--- GNAT was originally developed  by the GNAT team at  New York University. --
--- Extensive contributions were provided by Ada Core Technologies Inc.  --
---  --
---
-
-package System is
-   pragma Pure;
-   --  Note that we take advantage of the implementation permission to make
-   --  this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada
-   --  2005, this is Pure in any case (AI-362).
-
-   pragma No_Elaboration_Code_All;
-   --  Allow the use of that restriction in units that WITH this unit
-
-   type Name is (SYSTEM_NAME_GNAT);
-   System_Name : constant Name := SYSTEM_NAME_GNAT;
-
-   --  System-Dependent Named Numbers
-
-   Min_Int   : constant := Long_Long_Integer'First;
-   Max_Int   : constant := Long_Long_Integer'Last;
-
-   Max_Binary_Modulus: constant := 2 ** Long_Long_Integer'Size;
-   Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1;
-
-   Max_Base_Digits   : constant := Long_Long_Float'Digits;
-   Max_Digits: constant := Long_Long_Float'Digits;
-
-   Max_Mantissa  : constant := 63;
-   Fine_Delta: constant := 2.0 ** (-Max_Mantissa);
-
-   Tick  : constant := 0.000_001;
-
-   --  Storage-related Declarations
-
-   type Address is private;
-   pragma Preelaborable_Initialization (Address);
-   Null_Address : constant Address;
-
-   Storage_Unit : constant := 8;
-   Word_Size: constant := Standard'Word_Size;
-   Memory_Size  : constant := 2 ** Word_Size;
-
-   --  Address comparison
-
-   function "<"  (Left, Right : Address) return Boolean;
-   function "<=" (Left, Right : Address) return Boolean;
-   function ">"  (Left, Right : Address) return Boolean;
-   function ">=" (Left, Right : Address) return Boolean;
-   function "="  (Left, Right : Address) return Boolean;
-
-   pragma Import (Intrinsic, "<");
-   pragma Import (Intrinsic, "<=");
-   pragma Import (Intrinsic, ">");
-   pragma Import (Intrinsic, ">=");
-   pragma Import (Intrinsic, "=");
-
-   --  Other System-Dependent Declarations
-
-   type Bit_Order is (High_Order_First, Low_Order_First);
-   Default_Bit_Order : constant Bit_Order := Low_Order_First;
-   pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning
-
-   --  Priority-related Declarations (RM D.1)
-
-   --  0 .. 98 corresponds to the system priority range 1 .. 99.
-   --
-   --  If the scheduling policy is SCHED_FIFO or SCHED_RR the runtime makes use
-   --  of the entire range provided by the system.
-   --
-   --  If the scheduling policy is SCHED_OTHER the only valid system priority
-   --  is 1 and other values are simply ignored.
-
-   Max_Priority   : constant Positive := 97;
-   Max_Interrupt_Priority : constant Positive := 98;
-
-   subtype Any_Priority   is Integer  range  0 .. 98;
-   subtype Priority   is Any_Priority range  0 .. 97;
-   subtype Interrupt_Priority is Any_Priority range 98 .. 98;
-
-   Default_Priority : constant Priority := 48;
-
-private
-
-   type Address is mod Memory_Size;
-   Null_Address : constant Address := 0;
-
-   --
-   -- System Implementation Parameters --
-   --
-
-   --  These parameters provide information about the target that is used
-   --  by the compiler. They are in the private part of System, where they
-   --  can be accessed using the special circuitry in the Targparm unit
-   --  whose source should be consulted for more detailed descriptions
-   --  of the individual switch values.
-
-   Backend_Divide_Checks : constant Boolean := False;
-   Backend_Overflow_Checks   : constant Boolean := True;
-   Command_Line_Args : constant Boolean := True;
-   Configurable_Run_Time : constant Boolean := False;
-   Denorm: constant Boolean := True;
-   Duration_32_Bits  : constant Boolean := False;
-   Exit_Status_Supported : constant Boolean := True;
-   Fractional_Fixed_Ops  : constant Boolean := False;
-   Frontend_Layout   : constan

Re: [RFC][IPA-VRP] ADDR_EXPR and nonnull

[Richard Biener]

On Wed, 19 Oct 2016, kugan wrote:

> Hi,
> 
> While computing jump function value range for pointer, I am wondering if we
> can assume that any tree with ADDR_EXPR will be nonnull.
> 
> That is, in cases like:
> 
> int arr[10];
> foo (&arr[1]);
> 
> OR
> 
> struct st
> {
>   int a;
>   int b;
> };
> struct st s2;
> foo (&s2.a);
> 
> Attached patch tries to do this. I am not sure if this can be wrong. Any
> thoughts?

It can be wrong for weak symbols for example.

Richard.

> Attached patch bootstraps and regression testing didn't introduce any new
> regressions.
> 
> Thanks,
> Kugan
> 
> 
> gcc/ChangeLog:
> 
> 2016-10-19  Kugan Vivekanandarajah  
> 
>   * ipa-prop.c (ipa_compute_jump_functions_for_edge): Set
>   value range to nonull for ADDR_EXPR.
> 
> gcc/testsuite/ChangeLog:
> 
> 2016-10-19  Kugan Vivekanandarajah  
> 
>   * gcc.dg/ipa/vrp5.c: New test.
>   * gcc.dg/ipa/vrp6.c: New test.
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: r241307 - in /trunk: gcc/go/gofrontend/MERGE li...

[Andreas Schwab]

../../../libgo/go/runtime/netpoll_epoll.go:52:49: error: integer constant 
overflow
  ev.events = _EPOLLIN | _EPOLLOUT | _EPOLLRDHUP | _EPOLLET
 ^

$ grep EPOLLET -r ia64-suse-linux/libgo
ia64-suse-linux/libgo/runtime_sysinfo.go:const _EPOLLET = -2147483648
ia64-suse-linux/libgo/gen-sysinfo.go:// unknowndefine EPOLLET EPOLLET
ia64-suse-linux/libgo/gen-sysinfo.go:const _EPOLLET = -2147483648
ia64-suse-linux/libgo/sysinfo.go:const _EPOLLET = -2147483648
ia64-suse-linux/libgo/sysinfo.go:const EPOLLET = _EPOLLET

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] Reduce stack usage in sha512 (PR target/77308)

[Kyrill Tkachov]

On 19/10/16 07:55, Christophe Lyon wrote:

On 18 October 2016 at 17:35, Christophe Lyon  wrote:

On 18 October 2016 at 16:45, Bernd Edlinger  wrote:

On 10/18/16 10:36, Christophe Lyon wrote:

I am seeing a lot of regressions since this patch was committed:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/241273/report-build-info.html

(you can click on "REGRESSED" to see the list of regressions, "sum"
and "log" to download
the corresponding .sum/.log)

Thanks,

Christophe


Oh, sorry, I have completely missed that.
Unfortunately I have tested one of the good combinations.

I have not considered the case that in and out could be
the same register.  But that happens here.


This should solve it.

Can you give it a try?


Sure, I have started the validations, it will take a few hours.


It looks OK, thanks.


Ok. Thanks for testing Christophe.
Sorry for not catching it in review.
Kyrill



Thanks
Bernd.

Re: [RFC][IPA-VRP] ADDR_EXPR and nonnull

[kugan]

Hi Richard,


On 19/10/16 19:23, Richard Biener wrote:

On Wed, 19 Oct 2016, kugan wrote:


Hi,

While computing jump function value range for pointer, I am wondering if we
can assume that any tree with ADDR_EXPR will be nonnull.

That is, in cases like:

int arr[10];
foo (&arr[1]);

OR

struct st
{
  int a;
  int b;
};
struct st s2;
foo (&s2.a);

Attached patch tries to do this. I am not sure if this can be wrong. Any
thoughts?


It can be wrong for weak symbols for example.
Would excluding weak symbols (I believe I can check DECL_WEAK for this) 
good enough. Or looking for acceptable subset would work?


Thanks,
Kugan



Richard.


Attached patch bootstraps and regression testing didn't introduce any new
regressions.

Thanks,
Kugan


gcc/ChangeLog:

2016-10-19  Kugan Vivekanandarajah  

* ipa-prop.c (ipa_compute_jump_functions_for_edge): Set
value range to nonull for ADDR_EXPR.

gcc/testsuite/ChangeLog:

2016-10-19  Kugan Vivekanandarajah  

* gcc.dg/ipa/vrp5.c: New test.
* gcc.dg/ipa/vrp6.c: New test.

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Christophe Lyon]

Hi,


On 18 October 2016 at 04:45, Steve Kargl
 wrote:
> On Mon, Oct 17, 2016 at 06:02:52PM -0700, Jerry DeLisle wrote:
>> Hi all,
>>
>> The attached patch enables the size= specifier in a READ statement to work 
>> with
>> child DTIO procedures. This is accomplished by moving the size_used variable
>> from the dtp structure to the gfc_unit structure so that the accumulation of
>> bytes during READ is carried across the procedures via the UNIT.
>>
>> As far as I know, this is the last DTIO patch needed for full implementation 
>> and
>> will close the PR.
>>
>> After this patch is committed I plan to prepare a clean up patch to 
>> reorganize
>> the dtp structure and clear at least one TODO related to stream IO. The
>> follow-on patch will bump the major version number of libgfortran to 4.
>>
>> Regression tested on x86-64-linux. New test case attached.
>>
>> OK for trunk?
>
> Lookd good to me.
>
>>   * transfer.c (read_sf_internal): Likewise. (read_sf): Likewise.
>>   (read_block_form): Likewise. (read_block_form4): Likewise.
>
>

Since this was committed (r241294), I'm seeing regressions on
arm and aarch64 targets.

The list is a bit long, so it's probably simpler you look at:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/241306/report-build-info.html
Then click on the red "REGRESSED" in the gfortran column.

Thanks,

Christophe


> You can simplify this by
>
> * transfer.c (read_sf_internal, read_sf, read_block_form,
> read_block_form4): Likewise.
>
> --
> Steve

Re: [RFC][IPA-VRP] ADDR_EXPR and nonnull

[Richard Biener]

On Wed, 19 Oct 2016, kugan wrote:

> Hi Richard,
> 
> 
> On 19/10/16 19:23, Richard Biener wrote:
> > On Wed, 19 Oct 2016, kugan wrote:
> > 
> > > Hi,
> > > 
> > > While computing jump function value range for pointer, I am wondering if
> > > we
> > > can assume that any tree with ADDR_EXPR will be nonnull.
> > > 
> > > That is, in cases like:
> > > 
> > > int arr[10];
> > > foo (&arr[1]);
> > > 
> > > OR
> > > 
> > > struct st
> > > {
> > >   int a;
> > >   int b;
> > > };
> > > struct st s2;
> > > foo (&s2.a);
> > > 
> > > Attached patch tries to do this. I am not sure if this can be wrong. Any
> > > thoughts?
> > 
> > It can be wrong for weak symbols for example.
> Would excluding weak symbols (I believe I can check DECL_WEAK for this) good
> enough. Or looking for acceptable subset would work?

I think we should add a symtab helper to tell if address_nonzero_p (if
that doesn't aleady exist).

Richard.

> Thanks,
> Kugan
> 
> > 
> > Richard.
> > 
> > > Attached patch bootstraps and regression testing didn't introduce any new
> > > regressions.
> > > 
> > > Thanks,
> > > Kugan
> > > 
> > > 
> > > gcc/ChangeLog:
> > > 
> > > 2016-10-19  Kugan Vivekanandarajah  
> > > 
> > >   * ipa-prop.c (ipa_compute_jump_functions_for_edge): Set
> > >   value range to nonull for ADDR_EXPR.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > > 2016-10-19  Kugan Vivekanandarajah  
> > > 
> > >   * gcc.dg/ipa/vrp5.c: New test.
> > >   * gcc.dg/ipa/vrp6.c: New test.
> > > 
> > 
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[PATCH] Fix std::experimental::shared_ptr SFINAE constraints

[Jonathan Wakely]

There are lots of SFINAE checks missing from experimental::shared_ptr,
and we even test that shared_ptr(new derived[1]) works, when
it should be ill-formed.

I implemented a new trait for std::shared_ptr to check the
conversions, but I'm not ready to commit that work yet, so this just
adds it to experimental::shared_ptr for now.

* include/experimental/bits/shared_ptr.h
(__shared_ptr<__libfund_v1<_Tp, false>, _Lp>::_Compatible): Just use
is_convertible for non-array specialization.
(__shared_ptr<__libfund_v1<_Tp, false>, _Lp>::_UniqCompatible): New
constraint for conversions from unique_ptr.
(__shared_ptr<__libfund_v1<_Tp, false>, _Lp>::__shared_ptr): Constrain.
(__shared_ptr<__libfund_v1<_Tp, false>, _Lp>::reset): Likewise.
(__sp_compatible_v): New variable template for trait.
(__sp_is_constructible): New trait to check shared_ptr constraints.
(__sp_is_constructible_v): New variable template for trait.
(__shared_ptr<__libfund_v1<_Tp, true>, _Lp>::_SafeConv): New
constraint for construction/reset, using __sp_is_constructible_v.
(__shared_ptr<__libfund_v1<_Tp, true>, _Lp>::_UniqCompatible): New
constraint for conversions from unique_ptr.
(__shared_ptr<__libfund_v1<_Tp, true>, _Lp>::__shared_ptr): Constrain.
(__shared_ptr<__libfund_v1<_Tp, true>, _Lp>::reset): Likewise.
(shared_ptr::_SafeConv): Constraint for checking constructors.
(shared_ptr(Tp1*), shared_ptr(_Tp1, _Deleter))
(shared_ptr(_Tp1, _Deleter, _Alloc)): Constrain with _SafeConv.
(shared_ptr(const weak_ptr<_Tp1>&)): Constrain with _Compatible.
(shared_ptr(auto_ptr<_Tp1>&&)): Fix, remove TODO.
* testsuite/experimental/memory/shared_ptr/cons/pointer_ctor.cc:
Remove tests using invalid conversions.
* testsuite/experimental/memory/shared_ptr/cons/pointer_ctor_neg.cc:
New test.
* testsuite/experimental/memory/shared_ptr/cons/torture.cc: New test.
* testsuite/experimental/memory/shared_ptr/modifiers/reset.cc: Remove
tests using invalid conversions.
* testsuite/experimental/memory/shared_ptr/modifiers/reset_neg.cc: New
test.
* testsuite/experimental/memory/shared_ptr/observers/use_count.cc:
Remove tests using invalid conversions.

Tested x86_64-linux, committed to trunk.

commit 53e60f9dc887807a070cacb5931ee2980455ce7e
Author: Jonathan Wakely 
Date:   Wed Oct 19 10:12:15 2016 +0100

Fix std::experimental::shared_ptr SFINAE constraints

* include/experimental/bits/shared_ptr.h
(__shared_ptr<__libfund_v1<_Tp, false>, _Lp>::_Compatible): Just use
is_convertible for non-array specialization.
(__shared_ptr<__libfund_v1<_Tp, false>, _Lp>::_UniqCompatible): New
constraint for conversions from unique_ptr.
(__shared_ptr<__libfund_v1<_Tp, false>, _Lp>::__shared_ptr): Constrain.
(__shared_ptr<__libfund_v1<_Tp, false>, _Lp>::reset): Likewise.
(__sp_compatible_v): New variable template for trait.
(__sp_is_constructible): New trait to check shared_ptr constraints.
(__sp_is_constructible_v): New variable template for trait.
(__shared_ptr<__libfund_v1<_Tp, true>, _Lp>::_SafeConv): New
constraint for construction/reset, using __sp_is_constructible_v.
(__shared_ptr<__libfund_v1<_Tp, true>, _Lp>::_UniqCompatible): New
constraint for conversions from unique_ptr.
(__shared_ptr<__libfund_v1<_Tp, true>, _Lp>::__shared_ptr): Constrain.
(__shared_ptr<__libfund_v1<_Tp, true>, _Lp>::reset): Likewise.
(shared_ptr::_SafeConv): Constraint for checking constructors.
(shared_ptr(Tp1*), shared_ptr(_Tp1, _Deleter))
(shared_ptr(_Tp1, _Deleter, _Alloc)): Constrain with _SafeConv.
(shared_ptr(const weak_ptr<_Tp1>&)): Constrain with _Compatible.
(shared_ptr(auto_ptr<_Tp1>&&)): Fix, remove TODO.
* testsuite/experimental/memory/shared_ptr/cons/pointer_ctor.cc:
Remove tests using invalid conversions.
* testsuite/experimental/memory/shared_ptr/cons/pointer_ctor_neg.cc:
New test.
* testsuite/experimental/memory/shared_ptr/cons/torture.cc: New test.
* testsuite/experimental/memory/shared_ptr/modifiers/reset.cc: Remove
tests using invalid conversions.
* testsuite/experimental/memory/shared_ptr/modifiers/reset_neg.cc: New
test.
* testsuite/experimental/memory/shared_ptr/observers/use_count.cc:
Remove tests using invalid conversions.

diff --git a/libstdc++-v3/include/experimental/bits/shared_ptr.h 
b/libstdc++-v3/include/experimental/bits/shared_ptr.h
index e0ec00c..2e3da62 100644
--- a/libstdc++-v3/include/experimental/bits/shared_ptr.h
+++ b/libstdc++-v3/include/experimental/bits/shared_ptr.h
@@ -69,53 +69,48 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template ::value>
 struct __libfund

Re: [PATCH] PR77990 refactor unique_ptr to encapsulate tuple

[Jonathan Wakely]

On 17/10/16 14:37 +0100, Jonathan Wakely wrote:

We are incorrectly requiring unique_ptr deleters to be copyable here:

explicit
unique_ptr(pointer __p) noexcept
: _M_t(__p, deleter_type())
{ }

We could just do:

explicit
unique_ptr(pointer __p) noexcept
: _M_t()
{ std::get<0>(_M_t) = __p; }

But having to deal directly with the std::tuple inside unique_ptr has
been bothering me for some time. The tuple is used so we get the empty
base-class optimisation for the deleter, but that implementation
detail

This patch refactors unique_ptr to put the std::tuple member into a
new type which provides named accessors for the tuple elements, so we
can stop using get<0> and get<1>. That new type can also provide a
single-argument constructor to fix the copyable requirement for
deleters. This also removes the code for deducing the pointer type
which is duplciated in unique_ptr and unique_ptr, and while in
the neighbourhood I changed it from old-school SFINAE using overloaded
functions to the new hotness with __void_t<>.

I intend to commit this to trunk, but on the branches I'll just fix
the constructor as shown above, as it's a smaller change.


PR libstdc++/77990
* include/bits/unique_ptr.h (__uniq_ptr_impl): New type to
encapsulate implementation details.
(unique_ptr::unique_ptr(_Up)): Don't copy deleter object.
(unique_ptr::get, unique_ptr::get_deleter, unique_ptr::release):
Call member functions of implementation object.
(unique_ptr): Likewise.
* python/libstdcxx/v6/printers.py (UniquePointerPrinter): Adjust for
new implementation.
* python/libstdcxx/v6/xmethods.py (UniquePtrGetWorker): Likewise.
* testsuite/20_util/unique_ptr/assign/48635_neg.cc: Adjust dg-error
lines.
* testsuite/20_util/unique_ptr/assign/cv_qual.cc: Likewise.
* testsuite/20_util/unique_ptr/cons/cv_qual.cc: Likewise.
* testsuite/20_util/unique_ptr/cons/77990.cc: New test.

Tested powerpc64le-linux.


Committed to trunk. Here's the smaller patch I'm committing to the
branches.


commit 81ea53cd80fe7aaa3a323dba58bdb2259d672be3
Author: Jonathan Wakely 
Date:   Wed Oct 19 10:21:58 2016 +0100

PR77990 fix unique_ptr for non-copyable deleters

	PR libstdc++/77990
	* include/bits/unique_ptr.h (unique_ptr::unique_ptr(pointer)): Set
	pointer member after value-initialization of tuple.
	* testsuite/20_util/unique_ptr/assign/48635_neg.cc: Adjust dg-errors.
	* testsuite/20_util/unique_ptr/cons/77990.cc: New test.
	* testsuite/20_util/unique_ptr/cons/cv_qual.cc: Adjust dg-error.

diff --git a/libstdc++-v3/include/bits/unique_ptr.h b/libstdc++-v3/include/bits/unique_ptr.h
index c4a6d2f..8e30287 100644
--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -168,9 +168,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*/
   explicit
   unique_ptr(pointer __p) noexcept
-  : _M_t(__p, deleter_type())
-  { static_assert(!is_pointer::value,
-		 "constructed with null function pointer deleter"); }
+  : _M_t()
+  {
+	std::get<0>(_M_t) = __p;
+	static_assert(!is_pointer::value,
+		 "constructed with null function pointer deleter");
+  }
 
   /** Takes ownership of a pointer.
*
diff --git a/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc b/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc
index 16ff8ae..785f9ad 100644
--- a/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc
@@ -43,10 +43,10 @@ void f()
   std::unique_ptr ud(nullptr, d);
   ub = std::move(ud); // { dg-error "no match" }
   ub2 = ud; // { dg-error "no match" }
-// { dg-error "no type" "" { target *-*-* } 269 }
+// { dg-error "no type" "" { target *-*-* } 272 }
 
   std::unique_ptr uba(nullptr, b);
   std::unique_ptr uda(nullptr, d);
   uba = std::move(uda); // { dg-error "no match" }
-// { dg-error "no type" "" { target *-*-* } 537 }
+// { dg-error "no type" "" { target *-*-* } 540 }
 }
diff --git a/libstdc++-v3/testsuite/20_util/unique_ptr/cons/77990.cc b/libstdc++-v3/testsuite/20_util/unique_ptr/cons/77990.cc
new file mode 100644
index 000..1acc313
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/unique_ptr/cons/77990.cc
@@ -0,0 +1,28 @@
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.

[PATCH v2][AArch32][NEON] Implementing vmaxnmQ_ST and vminnmQ_ST intrinsincs.

[Tamar Christina]

Hi All,

This patch implements the vmaxnmQ_ST and vminnmQ_ST intrinsics. The
current builtin registration code is deficient since it can't access
standard pattern names, to which vmaxnmQ_ST and vminnmQ_ST map
directly. Thus, to enable the vectoriser to have access to these
intrinsics, we implement them using builtin functions, which we 
expand to the proper standard pattern using a define_expand.

This patch also implements the __ARM_FEATURE_NUMERIC_MAXMIN macro, 
which is defined when __ARM_ARCH >= 8, and which enables the 
intrinsics.

Regression tested on arm-none-eabi and no regressions.

This patch is a rework of a previous patch:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01971.html

OK for trunk?

Thanks,
Tamar

---

gcc/

2016-10-19  Bilyan Borisov  
Tamar Christina 

* config/arm/arm-c.c (arm_cpu_builtins): New macro definition.
* config/arm/arm_neon.h (vmaxnm_f32): New intrinsinc.
(vmaxnmq_f32): Likewise.
(vminnm_f32): Likewise.
(vminnmq_f32): Likewise.
* config/arm/arm_neon_builtins.def (vmaxnm): New builtin.
(vminnm): Likewise.
* config/arm/neon.md (neon_, VCVTF): New
expander.

gcc/testsuite/

2016-10-19  Bilyan Borisov  

* gcc.target/arm/simd/vmaxnm_f32_1.c: New.
* gcc.target/arm/simd/vmaxnmq_f32_1.c: Likewise.
* gcc.target/arm/simd/vminnm_f32_1.c: Likewise.
* gcc.target/arm/simd/vminnmq_f32_1.c: Likewise.

diff --git a/gcc/config/arm/arm-c.c b/gcc/config/arm/arm-c.c
index 72837001d1011e366233236a6ba3d1e5775583b1..dcb883d750506a02257e6e2e49880f2d1b9888fa 100644
--- a/gcc/config/arm/arm-c.c
+++ b/gcc/config/arm/arm-c.c
@@ -86,6 +86,9 @@ arm_cpu_builtins (struct cpp_reader* pfile)
 		  ((TARGET_ARM_ARCH >= 5 && !TARGET_THUMB)
 		   || TARGET_ARM_ARCH_ISA_THUMB >=2));
 
+  def_or_undef_macro (pfile, "__ARM_FEATURE_NUMERIC_MAXMIN",
+		  TARGET_ARM_ARCH >= 8 && TARGET_NEON && TARGET_FPU_ARMV8);
+
   def_or_undef_macro (pfile, "__ARM_FEATURE_SIMD32", TARGET_INT_SIMD);
 
   builtin_define_with_int_value ("__ARM_SIZEOF_MINIMAL_ENUM",
diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 54bbc7dd83cf979b6fad7724ba1d4b327b311f5c..3898ff7302dc3f21e6b50a8a7b835033c1ae2021 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -2956,6 +2956,34 @@ vmaxq_f32 (float32x4_t __a, float32x4_t __b)
   return (float32x4_t)__builtin_neon_vmaxfv4sf (__a, __b);
 }
 
+#pragma GCC push_options
+#pragma GCC target ("fpu=neon-fp-armv8")
+__extension__ static __inline float32x2_t __attribute__ ((__always_inline__))
+vmaxnm_f32 (float32x2_t a, float32x2_t b)
+{
+  return (float32x2_t)__builtin_neon_vmaxnmv2sf (a, b);
+}
+
+__extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
+vmaxnmq_f32 (float32x4_t a, float32x4_t b)
+{
+  return (float32x4_t)__builtin_neon_vmaxnmv4sf (a, b);
+}
+
+__extension__ static __inline float32x2_t __attribute__ ((__always_inline__))
+vminnm_f32 (float32x2_t a, float32x2_t b)
+{
+  return (float32x2_t)__builtin_neon_vminnmv2sf (a, b);
+}
+
+__extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
+vminnmq_f32 (float32x4_t a, float32x4_t b)
+{
+  return (float32x4_t)__builtin_neon_vminnmv4sf (a, b);
+}
+#pragma GCC pop_options
+
+
 __extension__ static __inline uint8x16_t __attribute__ ((__always_inline__))
 vmaxq_u8 (uint8x16_t __a, uint8x16_t __b)
 {
diff --git a/gcc/config/arm/arm_neon_builtins.def b/gcc/config/arm/arm_neon_builtins.def
index b29aa91a64ecb85dfb5eb9661ed67d4fa326062f..58b10207c1f5c0380cb01fdb4a92a3f0b4dec591 100644
--- a/gcc/config/arm/arm_neon_builtins.def
+++ b/gcc/config/arm/arm_neon_builtins.def
@@ -147,12 +147,12 @@ VAR6 (BINOP, vmaxs, v8qi, v4hi, v2si, v16qi, v8hi, v4si)
 VAR6 (BINOP, vmaxu, v8qi, v4hi, v2si, v16qi, v8hi, v4si)
 VAR2 (BINOP, vmaxf, v2sf, v4sf)
 VAR2 (BINOP, vmaxf, v8hf, v4hf)
-VAR2 (BINOP, vmaxnm, v4hf, v8hf)
+VAR4 (BINOP, vmaxnm, v2sf, v4sf, v4hf, v8hf)
 VAR6 (BINOP, vmins, v8qi, v4hi, v2si, v16qi, v8hi, v4si)
 VAR6 (BINOP, vminu, v8qi, v4hi, v2si, v16qi, v8hi, v4si)
 VAR2 (BINOP, vminf, v2sf, v4sf)
 VAR2 (BINOP, vminf, v4hf, v8hf)
-VAR2 (BINOP, vminnm, v8hf, v4hf)
+VAR4 (BINOP, vminnm, v2sf, v4sf, v8hf, v4hf)
 
 VAR3 (BINOP, vpmaxs, v8qi, v4hi, v2si)
 VAR3 (BINOP, vpmaxu, v8qi, v4hi, v2si)
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 05323334ffd81aeff33ee407b96c788d123b3fe3..3ae4f6a3bf26032f4c34d83ff79e27b30d4000de 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -2841,6 +2841,18 @@
  [(set_attr "type" "neon_fp_minmax_s")]
 )
 
+;; Expander for vnm intrinsics.
+(define_expand "neon_"
+  [(unspec:VCVTF [(match_operand:VCVTF 0 "s_register_operand" "")
+   (match_operand:VCVTF 1 "s_register_operand" "")
+   (match_operand:VCVTF 2 "s_register_operand" "")]
+		  VMAXMINFNM)]
+  "TARGET_NEON && TARGET_FPU_ARMV8"
+{
+  emit_insn (gen_3 (operands[0], operands[1], operands[2]));
+  DONE;
+})
+
 ;; Vector forms f

Re: [patch] Fix PHI optimization issue with boolean types

[Richard Biener]

On Tue, Oct 18, 2016 at 4:10 PM, Jeff Law  wrote:
> On 10/18/2016 02:35 AM, Richard Biener wrote:
>>
>> On Tue, Oct 18, 2016 at 8:35 AM, Eric Botcazou 
>> wrote:
>>>
>>> Hi,
>>>
>>> this is a regression present on the mainline and 6 branch: the compiler
>>> now
>>> generates wrong code for the attached testcase at -O because of an
>>> internal
>>> conflict about boolean types.  The sequence is as follows.  In
>>> .mergephi3:
>>>
>>>   boolean _22;
>>>   p__enum res;
>>>
>>>   :
>>>   if (_22 != 0)
>>> goto ;
>>>   else
>>> goto ;
>>>
>>>   :
>>>
>>>   :
>>>   # res_17 = PHI <2(8), 0(9), 1(10)>
>>>
>>> is turned into:
>>>
>>> COND_EXPR in block 9 and PHI in block 11 converted to straightline code.
>>> PHI res_17 changed to factor conversion out from COND_EXPR.
>>> New stmt with CAST that defines res_17.
>>>
>>>   boolean _33;
>>>
>>>   :
>>>   # _33 = PHI <2(8), _22(9)>
>>>   res_17 = (p__enum) _33;
>>>
>>> [...]
>>>
>>>   :
>>>   if (res_17 != 0)
>>> goto ;
>>>   else
>>> goto ;
>>>
>>>   :
>>>   _12 = res_17 == 2;
>>>   _13 = (integer) _12
>>>
>>> in .phiopt1.  So boolean _33 can have value 2.  Later forwprop3
>>> propagates _33
>>> into the uses of res_17:
>>>
>>>   :
>>>   if (_33 != 0)
>>> goto ;
>>>   else
>>> goto ;
>>>
>>>   :
>>>   _12 = _33 == 2;
>>>   _13 = (integer) _12;
>>>
>>> and DOM3 deduces:
>>>
>>>   :
>>>   _12 = 0;
>>>   _13 = 0;
>>>
>>> because it computes that _33 has value 1 in BB 13 since it's a boolean.
>>>
>>> The problem was introduced by the new factor_out_conditional_conversion:
>>>
>>>   /* If arg1 is an INTEGER_CST, fold it to new type.  */
>>>   if (INTEGRAL_TYPE_P (TREE_TYPE (new_arg0))
>>>   && int_fits_type_p (arg1, TREE_TYPE (new_arg0)))
>>> {
>>>   if (gimple_assign_cast_p (arg0_def_stmt))
>>> new_arg1 = fold_convert (TREE_TYPE (new_arg0), arg1);
>>>   else
>>> return NULL;
>>> }
>>>   else
>>> return NULL
>>>
>>> int_fits_type_p is documented as taking only INTEGER_TYPE, but is invoked
>>> on constant 2 and a BOOLEAN_TYPE and returns true.
>>>
>>> BOOLEAN_TYPE is special in Ada: it has precision 8 and range [0;255] so
>>> the
>>> outcome of int_fits_type_p is not unreasonable.  But this goes against
>>> the
>>> various transformations applied to boolean types in the compiler, which
>>> all
>>> assume that they can only take values 0 or 1.
>>>
>>> Hence the attached fix (which should be a no-op except for Ada), tested
>>> on
>>> x86_64-suse-linux, OK for mainline and 6 branch?
>>
>>
>> Hmm, I wonder if the patch is a good approach as you are likely only
>> papering
>> over a single of possibly very many affected places (wi::fits_to_tree_p
>> comes
>> immediately to my mind).  I suppose a better way would be for Ada to not
>> lie about those types and not use BOOLEAN_TYPE but INTEGER_TYPE.
>> Because BOOLEAN_TYPE types only have two values as documented in
>> tree.def:
>>
>> /* Boolean type (true or false are the only values).  Looks like an
>>INTEGRAL_TYPE.  */
>> DEFTREECODE (BOOLEAN_TYPE, "boolean_type", tcc_type, 0)
>>
>> There are not many references to BOOLEAN_TYPE in ada/gcc-interface
>> thus it shouldn't be hard to change ... (looks like Ada might even prefer
>> ENUMERAL_TYPE here).
>>
>> Thanks,
>> Richard.
>>
>>>
>>> 2016-10-18  Eric Botcazou  
>>>
>>> * tree.c (int_fits_type_p): Accept only 0 and 1 for boolean
>>> types.
>
> Alternately we could check the precision/range in the optimizers.  We do
> that in various places because of this exact issue, I could well have missed
> one or more.

I don't think we do.  Instead we have various places that do

  if ((TREE_CODE (TREE_TYPE (rhs1)) == BOOLEAN_TYPE
   || (INTEGRAL_TYPE_P (TREE_TYPE (rhs1))
   && TYPE_PRECISION (TREE_TYPE (rhs1)) == 1))

which basically means BOOLEAN_TYPEs have two values only regardless of
their precision or mode.

> Though I would have a preference for fixing int_fits_type_p which seems like
> it'll catch the cases we care about without having to twiddle every
> optimizer.

It doesn't catch the above.  If BOOLEAN_TYPE is not special why do we have
it at all?

Richard.

> jeff
>

Re: Clear basic block flags before using BB_VISITED for OpenACC loops processing

[Richard Biener]

On Tue, Oct 18, 2016 at 9:52 PM, Thomas Schwinge
 wrote:
> Hi!
>
> On Mon, 17 Oct 2016 15:38:50 +0200, I wrote:
>> On Mon, 17 Oct 2016 14:08:44 +0200, Richard Biener 
>>  wrote:
>> > On Mon, Oct 17, 2016 at 1:47 PM, Thomas Schwinge
>> >  wrote:
>> > > On Mon, 17 Oct 2016 13:22:17 +0200, Richard Biener 
>> > >  wrote:
>> > >> On Mon, Oct 17, 2016 at 11:38 AM, Thomas Schwinge
>> > >>  wrote:
>> > >> > On Fri, 14 Oct 2016 13:06:59 +0200, Richard Biener 
>> > >> >  wrote:
>> > >> >> On Fri, Oct 14, 2016 at 1:00 PM, Nathan Sidwell  
>> > >> >> wrote:
>> > >> >> > On 10/14/16 05:28, Richard Biener wrote:
>> > >> >> >
>> > >> >> >> The BB_VISITED flag has indetermined state at the beginning of a 
>> > >> >> >> pass.
>> > >> >> >> You have to ensure it is cleared yourself.
>> > >> >> >
>> > >> >> >
>> > >> >> > In that case the openacc (&nvptx?) passes should be modified to 
>> > >> >> > clear the
>> > >> >> > flags at their start, rather than at their end.
>
> This already is a "conceptual acknowledgement" of my patch, so...
>
>> > >> > OK to commit the following?  Is such a test case appropriate (which 
>> > >> > would
>> > >> > have caught this issue right away), in particular the dg-final
>> > >> > scan-tree-dump line?
>> > >>
>> > >> Ugh.  Not worse to what we do in various dwarf scanning I guess.
>> > >
>> > > ;-|
>> > >
>> > >> Doesn't failure lead to a miscompile eventually?  So you could formulate
>> > >> this as a dg-do run test with a check for the desired outcome?
>> > >
>> > > No, unfortunately.  In this case the error is "benign" such that the
>> > > OpenACC loop processing machinery will decide to not parallelize loops
>> > > that ought to be parallelized.
>> >
>> > So you can scan for "loop parallelized" instead?
>>
>> The dump would still contain the outer loop's "Loop 0(0)" marker, so I'd
>> have to scan for "Head"/"Tail"/"UNIQUE" or similar instead -- but that
>> seems likewise fragile (for false negatives), and less useful than
>> scanning for the complete pattern.
>>
>> > I fear your pattern
>> > is quite fragile
>> > to maintain over time.
>>
>> Agreed -- but then, that's intentional: my idea for this new test case
>> has been to have it actually verify the expected OpenACC loop processing,
>> so it's clear that this pattern will need to be adjusted if changing the
>> OpenACC loop processing.
>>
>> > >  This won't generally cause any problem
>> > > (apart from performance regression, obviously); it just caused problems
>> > > in a few libgomp test cases that actually at run time test for
>> > > parallelized execution -- which will/did trigger only with nvptx
>> > > offloading enabled, which not too many people are testing.  The test case
>> > > I propose below will trigger also for non-offloading configurations.
>>
>> On IRC, Segher suggested to 'use {} instead of "" to avoid [all those
>> backslashes]' -- thanks, done.
>
> If you don't like the test case as-is (do we need multi-line tree dump
> scanning, just like we recently got for compiler diagnostics?), can I at
> least commit the OpenACC loops processing fix?  Here is the latest
> version, simplified after your r241296 IRA vs. BB_VISITED fixes:

Sure, I considered that approved already (it's even obvious).

Richard.

> commit 766cf9959b15a17e17e89a50e905b4c546893823
> Author: Thomas Schwinge 
> Date:   Mon Oct 17 15:33:09 2016 +0200
>
> Clear basic block flags before using BB_VISITED for OpenACC loops 
> processing
>
> gcc/
> * omp-low.c (oacc_loop_discovery): Call clear_bb_flags before, and
> don't clear BB_VISITED after processing.
>
> gcc/testsuite/
> * gcc.dg/goacc/loop-processing-1.c: New file.
> ---
>  gcc/omp-low.c  |  8 +++-
>  gcc/testsuite/gcc.dg/goacc/loop-processing-1.c | 18 ++
>  2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git gcc/omp-low.c gcc/omp-low.c
> index 77f89d5..3ef796f 100644
> --- gcc/omp-low.c
> +++ gcc/omp-low.c
> @@ -19236,7 +19236,9 @@ oacc_loop_sibling_nreverse (oacc_loop *loop)
>  static oacc_loop *
>  oacc_loop_discovery ()
>  {
> -  basic_block bb;
> +  /* Clear basic block flags, in particular BB_VISITED which we're going to 
> use
> + in the following.  */
> +  clear_bb_flags ();
>
>oacc_loop *top = new_oacc_loop_outer (current_function_decl);
>oacc_loop_discover_walk (top, ENTRY_BLOCK_PTR_FOR_FN (cfun));
> @@ -19245,10 +19247,6 @@ oacc_loop_discovery ()
>   that diagnostics come out in an unsurprising order.  */
>top = oacc_loop_sibling_nreverse (top);
>
> -  /* Reset the visited flags.  */
> -  FOR_ALL_BB_FN (bb, cfun)
> -bb->flags &= ~BB_VISITED;
> -
>return top;
>  }
>
> diff --git gcc/testsuite/gcc.dg/goacc/loop-processing-1.c 
> gcc/testsuite/gcc.dg/goacc/loop-processing-1.c
> new file mode 100644
> index 000..619576a
> --- /dev/null
> +++ gcc/testsuite/gcc.dg/goacc/loop-processing-1.c
> @@ -0,0 +1,18 @@
> +/* Make sure that OpenACC loop processing happen

[PATCH, OBVIOUS] Replace NULL with false as a return value

[Martin Liška]

Hello.

Replacing NULL with false in a method with the boolean return type should
be obvious.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Martin
>From 9071aa82e0203cf71fcc743f2e94aa7151986b6e Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 18 Oct 2016 17:59:33 +0200
Subject: [PATCH] Replace NULL with false as a return value

gcc/ChangeLog:

2016-10-18  Martin Liska  

	* cgraph.h (cgraph_edge::binds_to_current_def_p):
	Replace NULL with false as a return value.
---
 gcc/cgraph.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index ecafe63..cc730d2 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -3042,7 +3042,7 @@ cgraph_edge::binds_to_current_def_p ()
   if (callee)
 return callee->binds_to_current_def_p (caller);
   else
-return NULL;
+return false;
 }
 
 /* Return true if the TM_CLONE bit is set for a given FNDECL.  */
-- 
2.10.1

Re: [PATCH] PR77987 Fix unique_ptr::reset(U) for T != U

[Jonathan Wakely]

On 17/10/16 13:00 +0100, Jonathan Wakely wrote:

This is a very simple change, to allow conversions that are supposed
to be valid according to DR 2118. The fix was slightly complicated by
the tests being a bit of a mess. We had tests for this requirement,
but they were in files which mixed positive tests and negative tests.
I've split the tests so the invalid operations are in separate files
and all the valid operations are in files that should pass.

PR libstdc++/77987
* include/bits/unique_ptr.h (unique_ptr::reset(U)): Copy
value to pointer of the correct type to swap, to support conversions
allowed by LWG 2118 / N4089.
* testsuite/20_util/unique_ptr/assign/assign_neg.cc: Move test for
incompatible deleters from ...
* testsuite/20_util/unique_ptr/assign/cv_qual.cc: ... here.
* testsuite/20_util/unique_ptr/modifiers/cv_qual.cc: Move tests for
incompatible pointers to ...
* testsuite/20_util/unique_ptr/modifiers/reset_neg.cc: ... here. Move
destructor definition to base class. Test for invalid derived-to-base
conversion.

I'll also backport this to the branches.


Here's another case where we have positive and negative tests in the
same file. I'm splitting this one too, and fixing one of the tests to
match its comment.

Tested powerpc64le-linux, comitted to trunk.

commit 721248b4e099769f0c78d72bf951e7b2d7b8f95a
Author: Jonathan Wakely 
Date:   Wed Oct 19 11:05:26 2016 +0100

Move negative unique_ptr tests to new file

	* testsuite/20_util/unique_ptr/cons/cv_qual.cc: Move negative tests
	to new file.
	* testsuite/20_util/unique_ptr/cons/cv_qual_neg.cc: New file.  Fix
	test for incompatible deleters to not also use incompatible types.
	Add tests for incompatible array types.

diff --git a/libstdc++-v3/testsuite/20_util/unique_ptr/cons/cv_qual.cc b/libstdc++-v3/testsuite/20_util/unique_ptr/cons/cv_qual.cc
index 829d112..8d6847b 100644
--- a/libstdc++-v3/testsuite/20_util/unique_ptr/cons/cv_qual.cc
+++ b/libstdc++-v3/testsuite/20_util/unique_ptr/cons/cv_qual.cc
@@ -99,30 +99,4 @@ test07()
   std::unique_ptr cA2((A*)p);
   std::unique_ptr vA2((A*)p);
   std::unique_ptr cvA2((A*)p);
-  // Disallow conversions from user-defined pointer-like types
-  // for the array version
-  std::unique_ptr upA3(p); // { dg-error "no matching function" }
-  std::unique_ptr cA3(p); // { dg-error "no matching function" }
-  std::unique_ptr vA3(p); // { dg-error "no matching function" }
-  std::unique_ptr cvA3(p); // { dg-error "no matching function" }
-  // { dg-error "no type" "" { target *-*-* } 446 }
 }
-
-template
-struct deleter
-{
-  deleter() = default;
-  template
-deleter(const deleter) { }
-  typedef T pointer;
-  void operator()(T) const { }
-};
-
-void
-test08()
-{
-  // Disallow conversions from non-assignable deleter
-  std::unique_ptr> p;
-  std::unique_ptr> upA(std::move(p)); // { dg-error "no matching function" }
-}
-
diff --git a/libstdc++-v3/testsuite/20_util/unique_ptr/cons/cv_qual_neg.cc b/libstdc++-v3/testsuite/20_util/unique_ptr/cons/cv_qual_neg.cc
new file mode 100644
index 000..d744c1b
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/unique_ptr/cons/cv_qual_neg.cc
@@ -0,0 +1,72 @@
+// { dg-do compile { target c++11 } }
+
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// 20.7.1 Class template unique_ptr [unique.ptr]
+
+#include 
+
+struct A { virtual ~A() = default; };
+
+struct B : A { };
+
+// Construction from objects with different cv-qualification
+
+struct A_pointer { operator A*() const { return nullptr; } };
+
+void
+test07()
+{
+  A_pointer p;
+  // Disallow conversions from user-defined pointer-like types
+  // for the array version
+  std::unique_ptr upA3(p); // { dg-error "no matching function" }
+  std::unique_ptr cA3(p); // { dg-error "no matching function" }
+  std::unique_ptr vA3(p); // { dg-error "no matching function" }
+  std::unique_ptr cvA3(p); // { dg-error "no matching function" }
+  // { dg-error "no type" "" { target *-*-* } 446 }
+}
+
+template
+struct deleter
+{
+  deleter() = default;
+  template
+deleter(const deleter) { }
+  typedef T pointer;
+  void operator()(T) const { }
+};
+
+void
+test08()
+{
+  // Disallow conversio

Re: [PR63238] output alignment debug information

[Alexandre Oliva]

On Sep 23, 2016, Alexandre Oliva  wrote:

> On Aug 27, 2016, Alexandre Oliva  wrote:
>> Output DWARFv5+ DW_AT_alignment for non-default alignment of
>> variables, fields and types.

>> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok to install?

> Ping?

Ping?  (conflicts resolved, patch refreshed and retested)


Output DWARFv5+ DW_AT_alignment for non-default alignment of
variables, fields and types.

for gcc/ChangeLog

PR debug/63238
* dwarf2out.c (clone_as_declaration): Drop DW_AT_alignment.
(add_alignment_attribute): New.
(base_type_die): Add alignment attribute.
(subrange_type_die): Likewise.
(modified_type_die): Likewise.
(gen_array_type_die): Likewise.
(gen_descr_array_type_die: Likewise.
(gen_enumeration_type_die): Likewise.
(gen_subprogram_die): Likewise.
(gen_variable_die): Likewise.
(gen_field_die): Likewise.
(gen_ptr_to_mbr_type_die): Likewise.
(gen_struct_or_union_type_die): Likewise.
(gen_subroutine_type_die): Likewise.
(gen_typedef_die): Likewise.
(base_type_cmp): Compare alignment attribute.

for gcc/testsuite/ChangeLog

PR debug/63238
* gcc.dg/debug/dwarf2/align-1.c: New.
* gcc.dg/debug/dwarf2/align-2.c: New.
* gcc.dg/debug/dwarf2/align-3.c: New.
* gcc.dg/debug/dwarf2/align-4.c: New.
* gcc.dg/debug/dwarf2/align-5.c: New.
* gcc.dg/debug/dwarf2/align-6.c: New.
* gcc.dg/debug/dwarf2/align-as-1.c: New.
* g++.dg/debug/dwarf2/align-1.C: New.
* g++.dg/debug/dwarf2/align-2.C: New.
* g++.dg/debug/dwarf2/align-3.C: New.
* g++.dg/debug/dwarf2/align-4.C: New.
* g++.dg/debug/dwarf2/align-5.C: New.
* g++.dg/debug/dwarf2/align-6.C: New.
---
 gcc/dwarf2out.c|   76 ++--
 gcc/testsuite/g++.dg/debug/dwarf2/align-1.C|5 ++
 gcc/testsuite/g++.dg/debug/dwarf2/align-2.C|6 ++
 gcc/testsuite/g++.dg/debug/dwarf2/align-3.C|7 ++
 gcc/testsuite/g++.dg/debug/dwarf2/align-4.C|7 ++
 gcc/testsuite/g++.dg/debug/dwarf2/align-5.C|7 ++
 gcc/testsuite/g++.dg/debug/dwarf2/align-6.C|9 +++
 gcc/testsuite/gcc.dg/debug/dwarf2/align-1.c|5 ++
 gcc/testsuite/gcc.dg/debug/dwarf2/align-2.c|6 ++
 gcc/testsuite/gcc.dg/debug/dwarf2/align-3.c|7 ++
 gcc/testsuite/gcc.dg/debug/dwarf2/align-4.c|7 ++
 gcc/testsuite/gcc.dg/debug/dwarf2/align-5.c|7 ++
 gcc/testsuite/gcc.dg/debug/dwarf2/align-6.c|9 +++
 gcc/testsuite/gcc.dg/debug/dwarf2/align-as-1.c |5 ++
 14 files changed, 157 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/align-1.C
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/align-2.C
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/align-3.C
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/align-4.C
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/align-5.C
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/align-6.C
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/align-1.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/align-2.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/align-3.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/align-4.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/align-5.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/align-6.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/align-as-1.c

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index ba36310..afe7bfd 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3342,6 +3342,7 @@ static void add_bound_info (dw_die_ref, enum 
dwarf_attribute, tree,
const struct loc_descr_context *);
 static void add_subscript_info (dw_die_ref, tree, bool);
 static void add_byte_size_attribute (dw_die_ref, tree);
+static void add_alignment_attribute (dw_die_ref, tree);
 static inline void add_bit_offset_attribute (dw_die_ref, tree,
 struct vlr_context *);
 static void add_bit_size_attribute (dw_die_ref, tree);
@@ -7461,6 +7462,7 @@ clone_as_declaration (dw_die_ref die)
   add_dwarf_attr (clone, a);
   break;
 case DW_AT_byte_size:
+   case DW_AT_alignment:
 default:
   break;
 }
@@ -10986,6 +10988,8 @@ base_type_die (tree type, bool reverse)
 add_AT_unsigned (base_type_result, DW_AT_endianity,
 BYTES_BIG_ENDIAN ? DW_END_little : DW_END_big);
 
+  add_alignment_attribute (base_type_result, type);
+
   if (fpt_used)
 {
   switch (fpt_info.scale_factor_kind)
@@ -11149,6 +11153,8 @@ subrange_type_die (tree type, tree low, tree high, tree 
bias,
   add_AT_unsigned (subrange_die, DW_AT_byte_size, size_in_bytes);
 }
 
+  add_alignment_attribute (subrange_die, type);
+
   if (low)
 add_bound_info (subrange_die, DW_AT_lower

Re: [PR56974] output DWARF-5 markers for ref_qualifiers

[Alexandre Oliva]

On Sep 23, 2016, Alexandre Oliva  wrote:

> On Aug 12, 2016, Alexandre Oliva  wrote:
>> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok to install?

> Ping?

Ping?  (conflicts resolved, patch refreshed and retested)


When a method or a method or function type has a ref-qualifier, output
DW_AT_reference or DW_AT_rvalue_reference in the subprogram or
subroutine_type tag, as specified in DWARF version 5 drafts, see
.

Output pointer to member function types as DW_TAG_ptr_to_member_type,
as required by DWARF since version 2.

Output DW_TAG_use_location for pointers to data member types, as
specified in DWARF since version 2.

DW_TAG_use_location is allowed for pointers to member function types
as well, but the specification doesn't make much sense for them, so I'm
leaving it out until it is clarified.


for  gcc/ChangeLog

PR debug/56974
* dwarf2out.c (gen_subprogram_die): Add DW_AT_reference or
DW_AT_rvalue_reference to methods.
(gen_subroutine_type_die): Likewise to method types.
(gen_ptr_to_mbr_type_die): Take enclosing and member types.
Output DW_AT_use_location for pointers to data members.
(gen_type_die_with_usage): Don't drop rquals of METHOD_TYPEs.
Adjust OFFSET_TYPE handling.  Introduce RECORD_TYPE handling
of pointers to member functions.
* hooks.c (hook_tree_const_tree_int_null): New.
* hooks.h (hook_tree_const_tree_int_null): Declare.
* langhooks-def.h (LANG_HOOKS_GET_REF_QUALIFIER): Define.
(LANG_HOOKS_GET_PTRMEMFN_TYPE): Define.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Add them.
* langhooks.h (struct lang_hooks_for_types): Add
get_ref_qualifier and get_ptrmemfn_type.

for  gcc/cp/ChangeLog

PR debug/56974
* cp-objcp-common.c (cp_get_ref_qualifier): New.
(cp_get_ptrmemfn_type): New.
* cp-objcp-common.h: Declared them.
(LANG_HOOKS_GET_REF_QUALIFIER): Override.
(LANG_HOOKS_GET_PTRMEMFN_TYPE): Likewise.

for  gcc/testsuite/ChangeLog

PR debug/56974
* g++.dg/debug/dwarf2/refqual-1.C: New.
* g++.dg/debug/dwarf2/refqual-2.C: New.
* g++.dg/debug/dwarf2/ptrdmem-1.C: New.
---
 gcc/cp/cp-objcp-common.c  |   37 +++
 gcc/cp/cp-objcp-common.h  |9 ++-
 gcc/dwarf2out.c   |   87 ++---
 gcc/hooks.c   |8 ++
 gcc/hooks.h   |1 
 gcc/langhooks-def.h   |6 +-
 gcc/langhooks.h   |   10 +++
 gcc/testsuite/g++.dg/debug/dwarf2/ptrdmem-1.C |9 +++
 gcc/testsuite/g++.dg/debug/dwarf2/refqual-1.C |   17 +
 gcc/testsuite/g++.dg/debug/dwarf2/refqual-2.C |   17 +
 10 files changed, 189 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/ptrdmem-1.C
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/refqual-1.C
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/refqual-2.C

diff --git a/gcc/cp/cp-objcp-common.c b/gcc/cp/cp-objcp-common.c
index abcc1ca..78ffe8c 100644
--- a/gcc/cp/cp-objcp-common.c
+++ b/gcc/cp/cp-objcp-common.c
@@ -131,6 +131,43 @@ cxx_types_compatible_p (tree x, tree y)
   return same_type_ignoring_top_level_qualifiers_p (x, y);
 }
 
+/* Return 0 if TYPE is NOT a C++ method or function type with a
+   ref-qualifier, 1 if the ref-qualifier is '&', and 2 if it is
+   '&&'.  */
+
+int
+cp_get_ref_qualifier (const_tree type)
+{
+  if ((TREE_CODE (type) == METHOD_TYPE || TREE_CODE (type) == FUNCTION_TYPE)
+  && FUNCTION_REF_QUALIFIED (type))
+return FUNCTION_RVALUE_QUALIFIED (type) ? 2 : 1;
+  else
+return 0;
+}
+
+/* Return NULL if TYPE is NOT a C++ pointer to member function type.
+   Otherwise, return the class type when the selector is 0, or the
+   member function type when the selector is 1.  */
+
+tree
+cp_get_ptrmemfn_type (const_tree type, int selector)
+{
+  if (!TYPE_PTRMEMFUNC_P (type))
+return NULL_TREE;
+
+  switch (selector)
+{
+case 0:
+  return TYPE_PTRMEMFUNC_OBJECT_TYPE (type);
+
+case 1:
+  return TREE_TYPE (TYPE_PTRMEMFUNC_FN_TYPE (type));
+
+default:
+  gcc_unreachable ();
+}
+}
+
 /* Return -1 if dwarf ATTR shouldn't be added for DECL, or the attribute
value otherwise.  */
 int
diff --git a/gcc/cp/cp-objcp-common.h b/gcc/cp/cp-objcp-common.h
index 9dd847e..5cf0170 100644
--- a/gcc/cp/cp-objcp-common.h
+++ b/gcc/cp/cp-objcp-common.h
@@ -21,7 +21,10 @@ along with GCC; see the file COPYING3.  If not see
 #ifndef GCC_CP_OBJCP_COMMON
 #define GCC_CP_OBJCP_COMMON
 
-/* In cp/cp-lang.c and objcp/objcp-lang.c.  */
+/* In cp/objcp-common.c, cp/cp-lang.c and objcp/objcp-lang.c.  */
+
+extern int cp_get_ref_qualifier (const_tree);
+extern tree cp_get_ptrmemfn_type (const_tree, int);
 
 extern tree objcp_tsubst_copy_and_build (

Re: [PR59319] output friends in debug info

[Alexandre Oliva]

On Sep 23, 2016, Alexandre Oliva  wrote:

> On Aug 30, 2016, Alexandre Oliva  wrote:
>> Handling non-template friends is kind of easy, [...]

> Regstrapped on x86_64-linux-gnu and i686-linux-gnu, I'd failed to
> mention.

> Ping?

Ping?  (conflicts resolved, patch refreshed and retested)


Handling non-template friends is kind of easy, but it required a bit
of infrastructure in dwarf2out to avoid (i) forcing debug info for
unused types or functions: DW_TAG_friend DIEs are only emitted if
their DW_AT_friend DIE is emitted, and (ii) creating DIEs for such
types or functions just to have them discarded at the end.  To this
end, I introduced a list (vec, actually) of types with friends,
processed at the end of the translation unit, and a list of
DW_TAG_friend DIEs that, when we're pruning unused types, reference
DIEs that are still not known to be used, revisited after we finish
deciding all other DIEs, so that we prune DIEs that would have
referenced pruned types or functions.

Handling template friends turned out to be trickier: there's no
representation in DWARF for templates.  I decided to give debuggers as
much information as possible, enumerating all specializations of
friend templates and outputting DW_TAG_friend DIEs referencing them as
well.  I considered marking those as DW_AT_artificial, to indicate
they're not explicitly stated in the source code, but in the end we
decided that was not useful.  The greatest challenge was to enumerate
all specializations of a template.  It looked trivial at first, given
DECL_TEMPLATE_INSTANTIATIONS, but it won't list specializations of
class-scoped functions and of nested templates.  For other templates,
I ended up writing code to look for specializations in the hashtables
of decl or type specializations.  That's not exactly efficient, but it
gets the job done.


for gcc/ChangeLog

PR debug/59319
* dwarf2out.c (class_types_with_friends): New.
(gen_friend_tags_for_type, gen_friend_tags): New.
(gen_member_die): Record class types with friends.
(deferred_marks): New.
(prune_unused_types_defer_undecided_mark_p): New.
(prune_unused_types_defer_mark): New.
(prune_unused_types_deferred_walk): New.
(prune_unused_types_walk): Defer DW_TAG_friend.
(prune_unused_types): Check deferred marks is empty on entry,
empty it after processing.
(dwarf2out_finish): Generate friend tags.
(dwarf2out_early_finish): Likewise.
* langhooks-def.h (LANG_HOOKS_GET_FRIENDS): New.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Add it.
* langhooks.h (lang_hooks_for_types): Add get_friends.

for gcc/cp/ChangeLog

PR debug/59319
* cp-objcp-common.c (cp_get_friends): New.
* cp-objcp-common.h (cp_get_friends): Declare.
(LANG_HOOKS_GET_FRIENDS): Override.
* cp-tree.h (enumerate_friend_specializations): Declare.
* pt.c (optimize_friend_specialization_lookup_p): New.
(retrieve_friend_specialization): New.
(enumerate_friend_specializations): New.
(register_specialization): Update DECL_TEMPLATE_INSTANTIATIONS
for functions, even after definition, if we are emitting debug
info.

for gcc/testsuite/ChangeLog

PR debug/59319
* g++.dg/debug/dwarf2/friend-1.C: New.
* g++.dg/debug/dwarf2/friend-2.C: New.
* g++.dg/debug/dwarf2/friend-3.C: New.
* g++.dg/debug/dwarf2/friend-4.C: New.
* g++.dg/debug/dwarf2/friend-5.C: New.
* g++.dg/debug/dwarf2/friend-6.C: New.
* g++.dg/debug/dwarf2/friend-7.C: New.
* g++.dg/debug/dwarf2/friend-8.C: New.
* g++.dg/debug/dwarf2/friend-9.C: New.
* g++.dg/debug/dwarf2/friend-10.C: New.
* g++.dg/debug/dwarf2/friend-11.C: New.
* g++.dg/debug/dwarf2/friend-12.C: New.
* g++.dg/debug/dwarf2/friend-13.C: New.
* g++.dg/debug/dwarf2/friend-14.C: New.
* g++.dg/debug/dwarf2/friend-15.C: New.
* g++.dg/debug/dwarf2/friend-16.C: New.
* g++.dg/debug/dwarf2/friend-17.C: New.
* g++.dg/debug/dwarf2/friend-18.C: New.
---
 gcc/cp/cp-objcp-common.c  |  106 ++
 gcc/cp/cp-objcp-common.h  |3 
 gcc/cp/cp-tree.h  |1 
 gcc/cp/pt.c   |  194 +
 gcc/dwarf2out.c   |  165 +
 gcc/langhooks-def.h   |4 -
 gcc/langhooks.h   |   19 ++
 gcc/testsuite/g++.dg/debug/dwarf2/friend-1.C  |   10 +
 gcc/testsuite/g++.dg/debug/dwarf2/friend-10.C |   13 ++
 gcc/testsuite/g++.dg/debug/dwarf2/friend-11.C |   13 ++
 gcc/testsuite/g++.dg/debug/dwarf2/friend-12.C |   15 ++
 gcc/testsuite/g++.dg/debug/dwarf2/friend-13.C |   12 ++
 gcc/testsuite/g++.dg/debug/dwarf2/friend-14.C |   20 +++
 gcc/testsuite/g++.dg/debug/dwarf2/friend-15.C |   20 +++
 gc

Re: [libcc1] add support for C++

[Alexandre Oliva]

On Sep 23, 2016, Alexandre Oliva  wrote:

> This patchset adds support for the C++ language to libcc1.
> It updates a few patches for libcc1 by Jan Kratochvil, posted long ago
> but IIRC not reviewed; it updates a patch that adds support for
> representing aliases and trampolines in dwarf2+ debug info (useful for
> naming all cdtors clones), adding support for combined dwarf2 and vms
> debug output compared with the earlier version; and finally the actual
> extension of libcc1 to support the C++ language, with a few changes to
> the C++ front-end to make some functionality available to libcc1, to
> introduce symbol lookups through libcc1, to enable code snippets to be
> regarded as friends of every class, and other minor adjustments.

> Regstrapped on x86_64-linux-gnu and i686-linux-gnu; libcc1 was tested
> with GDB branch users/pmuldoon/c++compile, where GDB support for C++
> compile code is being developed.

> Ok to install?

Ping?

https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01744.html

> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02218.html
> include/ChangeLog
> 2015-05-24  Jan Kratochvil  

>   * gcc-interface.h (enum gcc_base_api_version): Add GCC_FE_VERSION_1.

> libcc1/ChangeLog
> 2015-05-24  Jan Kratochvil  

>   * libcc1.cc (vtable): Update to GCC_FE_VERSION_1.
>   (gcc_c_fe_context): Accept also GCC_FE_VERSION_1.



> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02219.html
> include/ChangeLog
> 2015-05-24  Jan Kratochvil  

>   * gcc-interface.h (enum gcc_base_api_version): Add comment to
>   GCC_FE_VERSION_1.
>   (struct gcc_base_vtable): Rename compile to compile_v0.  Update comment
>   for compile.  New methods set_verbose and compile.

> libcc1/ChangeLog
> 2015-05-24  Jan Kratochvil  

>   * libcc1.cc: Include intl.h.
>   (struct libcc1): Add field verbose.
>   (libcc1::libcc1): Initialize it.
>   (libcc1_set_verbose): New function.
>   (libcc1_set_arguments): Print messages for VERBOSE.
>   (libcc1_compile): Remove parameter verbose.  Use VERBOSE from SELF.
>   (libcc1_compile_v0): New function.
>   (vtable): Use libcc1_compile_v0 and add libcc1_compile and
>   libcc1_set_verbose.



> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02220.html
> include/ChangeLog
> 2015-05-24  Jan Kratochvil  

>   * gcc-interface.h (enum gcc_base_api_version): Update comment for
>   GCC_FE_VERSION_1.
>   (struct gcc_base_vtable): Rename set_arguments to set_arguments_v0.
>   Add set_arguments, set_triplet_regexp and set_driver_filename.

> libcc1/ChangeLog
> 2015-05-24  Jan Kratochvil  

>   * libcc1.cc (libcc1): Add class compiler with field compilerp, class
>   compiler_triplet_regexp and class compiler_driver_filename.
>   (libcc1::libcc1): Initialize compilerp.
>   (libcc1::~libcc1): Delete compilerp.
>   (libcc1::compiler::find, libcc1::compiler_triplet_regexp::find)
>   (libcc1::compiler_driver_filename::find): New methods.
>   (libcc1_set_arguments): Remove parameter triplet_regexp.
>   (libcc1_set_triplet_regexp, libcc1_set_driver_filename)
>   (libcc1_set_arguments_v0): New functions.
>   (vtable): Use libcc1_set_arguments_v0, add libcc1_set_arguments,
>   libcc1_set_triplet_regexp and libcc1_set_driver_filename.



> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02221.html
> libcc1/ChangeLog
> 2015-05-24  Jan Kratochvil  

>   * findcomp.cc: Include system.h.
>   (search_dir): Return absolute filename.




> Ping?  https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01407.html
> support aliases and trampolines in dwarf2

> for  gcc/ChangeLog

>   * debug.h (struct gcc_debug_hooks): Add aliased_decl and
>   trampoline_decl.
>   * dwarf2out.c (dwarf2out_aliased_decl): New.
>   (dwarf2out_trampoline_decl): New.
>   (dwarf2_debug_hooks): Add them.
>   (dwarf2_name): Skip leading '*' returned by langhook.
>   (dwarf2_lineno_debug_hooks): Add dummies.
>   * debug.c (do_nothing_debug_hooks): Likewise.
>   * dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Likewise.
>   * sdbout.c (sdb_debug_hooks): Likewise.
>   * vmsdbgout.c (vmsdbgout_aliased_decl): New.
>   (vmsdbgout_trampoline_decl): New.
>   (vmsdbg_debug_hooks): Add them.
>   * cgraph.h (cgraph_node::is_lang_trampoline): Declare.
>   * cgraphunit.c: Include demangle.h.
>   (cgraph_node::expand_thunk): Call function_decl debug_hook
>   after assembly expansion.  Do not mark thunk as ignored in
>   gimple expansion.
>   (cxx_cdtor_trampoline_p): New.
>   (cgraph_node::is_lang_trampoline): New.
>   (cgraph_node::assemble_thunks_and_aliases): Call the new
>   debug_hooks.
>   (symbol_table::output_weakrefs): Likewise.
>   * varpool.c (varpool_node::assemble_aliases): Likewise.

> for  gcc/cp/ChangeLog

>   * method.c (make_alias_for): Copy DECL_IGNORED_P.

> for  gcc/testsuite/ChangeLog

>   * g++.dg/debug/dwarf2/cdtor-1.C

Re: [PATCH v2][AArch32][NEON] Implementing vmaxnmQ_ST and vminnmQ_ST intrinsincs.

[Christophe Lyon]

On 19 October 2016 at 11:36, Tamar Christina  wrote:
> Hi All,
>
> This patch implements the vmaxnmQ_ST and vminnmQ_ST intrinsics. The
> current builtin registration code is deficient since it can't access
> standard pattern names, to which vmaxnmQ_ST and vminnmQ_ST map
> directly. Thus, to enable the vectoriser to have access to these
> intrinsics, we implement them using builtin functions, which we
> expand to the proper standard pattern using a define_expand.
>
> This patch also implements the __ARM_FEATURE_NUMERIC_MAXMIN macro,
> which is defined when __ARM_ARCH >= 8, and which enables the
> intrinsics.
>
> Regression tested on arm-none-eabi and no regressions.
>
> This patch is a rework of a previous patch:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01971.html
>
> OK for trunk?
>
> Thanks,
> Tamar
>
> ---
>
> gcc/
>
> 2016-10-19  Bilyan Borisov  
> Tamar Christina 
>
> * config/arm/arm-c.c (arm_cpu_builtins): New macro definition.
> * config/arm/arm_neon.h (vmaxnm_f32): New intrinsinc.
> (vmaxnmq_f32): Likewise.
> (vminnm_f32): Likewise.
> (vminnmq_f32): Likewise.
> * config/arm/arm_neon_builtins.def (vmaxnm): New builtin.
> (vminnm): Likewise.
> * config/arm/neon.md (neon_, VCVTF): New
> expander.
>
> gcc/testsuite/
>
> 2016-10-19  Bilyan Borisov  
>
> * gcc.target/arm/simd/vmaxnm_f32_1.c: New.
> * gcc.target/arm/simd/vmaxnmq_f32_1.c: Likewise.
> * gcc.target/arm/simd/vminnm_f32_1.c: Likewise.
> * gcc.target/arm/simd/vminnmq_f32_1.c: Likewise.
>

I think you forgot to attach the new tests.

Christophe

[PR tree-optimization/78024] Clear basic block flags before using BB_VISITED for OpenACC loops processing

[Thomas Schwinge]

Hi!

On Wed, 19 Oct 2016 12:07:13 +0200, Richard Biener  
wrote:
> On Tue, Oct 18, 2016 at 9:52 PM, Thomas Schwinge
>  wrote:
> > can I at
> > least commit the OpenACC loops processing fix?  Here is the latest
> > version, simplified after your r241296 IRA vs. BB_VISITED fixes:
> 
> Sure, I considered that approved already

I don't see such an approval anywhere?

> (it's even obvious).

I've been told to be very careful in GCC with declaring something
"obvious".  (Though, I will be happy to increase my autonomy in declaring
patches "obvious"/"ready for commit".  This will potentially save me from
wasting hours when keeping patches up-to-date, while repeatedly begging
for review, and so on.)

Anyway, without changes now committed in r241334:

commit b3e3b38b4b1ac65df70d98f7e7557a27947948c1
Author: tschwinge 
Date:   Wed Oct 19 10:19:24 2016 +

[PR tree-optimization/78024] Clear basic block flags before using 
BB_VISITED for OpenACC loops processing

gcc/
* omp-low.c (oacc_loop_discovery): Call clear_bb_flags before, and
don't clear BB_VISITED after processing.

gcc/testsuite/
* gcc.dg/goacc/loop-processing-1.c: New file.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241334 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog  |  6 ++
 gcc/omp-low.c  |  8 +++-
 gcc/testsuite/ChangeLog|  5 +
 gcc/testsuite/gcc.dg/goacc/loop-processing-1.c | 18 ++
 4 files changed, 32 insertions(+), 5 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index d5830d5..4117eb3 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,9 @@
+2016-10-19  Thomas Schwinge  
+
+   PR tree-optimization/78024
+   * omp-low.c (oacc_loop_discovery): Call clear_bb_flags before, and
+   don't clear BB_VISITED after processing.
+
 2016-10-19  Richard Biener  
 
* domwalk.c (dom_walker::walk): Use RPO order.
diff --git gcc/omp-low.c gcc/omp-low.c
index 77f89d5..3ef796f 100644
--- gcc/omp-low.c
+++ gcc/omp-low.c
@@ -19236,7 +19236,9 @@ oacc_loop_sibling_nreverse (oacc_loop *loop)
 static oacc_loop *
 oacc_loop_discovery ()
 {
-  basic_block bb;
+  /* Clear basic block flags, in particular BB_VISITED which we're going to use
+ in the following.  */
+  clear_bb_flags ();
   
   oacc_loop *top = new_oacc_loop_outer (current_function_decl);
   oacc_loop_discover_walk (top, ENTRY_BLOCK_PTR_FOR_FN (cfun));
@@ -19245,10 +19247,6 @@ oacc_loop_discovery ()
  that diagnostics come out in an unsurprising order.  */
   top = oacc_loop_sibling_nreverse (top);
 
-  /* Reset the visited flags.  */
-  FOR_ALL_BB_FN (bb, cfun)
-bb->flags &= ~BB_VISITED;
-
   return top;
 }
 
diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index df73022..ec875aa 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2016-10-19  Thomas Schwinge  
+
+   PR tree-optimization/78024
+   * gcc.dg/goacc/loop-processing-1.c: New file.
+
 2016-10-19  Richard Biener  
 
* gcc.dg/tree-ssa/pr61839_2.c: Fix testcase.
diff --git gcc/testsuite/gcc.dg/goacc/loop-processing-1.c 
gcc/testsuite/gcc.dg/goacc/loop-processing-1.c
new file mode 100644
index 000..619576a
--- /dev/null
+++ gcc/testsuite/gcc.dg/goacc/loop-processing-1.c
@@ -0,0 +1,18 @@
+/* Make sure that OpenACC loop processing happens.  */
+/* { dg-additional-options "-O2 -fdump-tree-oaccdevlow" } */
+
+extern int place ();
+
+void vector_1 (int *ary, int size)
+{
+#pragma acc parallel num_workers (32) vector_length(32) copy(ary[0:size]) 
firstprivate (size)
+  {
+#pragma acc loop gang
+for (int jx = 0; jx < 1; jx++)
+#pragma acc loop auto
+  for (int ix = 0; ix < size; ix++)
+   ary[ix] = place ();
+  }
+}
+
+/* { dg-final { scan-tree-dump {OpenACC loops.*Loop 0\(0\).*Loop 
14\(1\).*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_HEAD_MARK, 0, 1, 
20\);.*Head-0:.*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_HEAD_MARK, 0, 1, 
20\);.*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_FORK, \.data_dep\.[0-9_]+, 
0\);.*Tail-0:.*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_TAIL_MARK, 
\.data_dep\.[0-9_]+, 1\);.*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_JOIN, 
\.data_dep\.[0-9_]+, 0\);.*Loop 6\(4\).*\.data_dep\.[0-9_]+ = UNIQUE 
\(OACC_HEAD_MARK, 0, 1, 6\);.*Head-0:.*\.data_dep\.[0-9_]+ = UNIQUE 
\(OACC_HEAD_MARK, 0, 1, 6\);.*\.data_dep\.[0-9_]+ = UNIQUE \(OACC_FORK, 
\.data_dep\.[0-9_]+, 2\);.*Tail-0:.*\.data_dep\.[0-9_]+ = UNIQUE 
\(OACC_TAIL_MARK, \.data_dep\.[0-9_]+, 1\);.*\.data_dep\.[0-9_]+ = UNIQUE 
\(OACC_JOIN, \.data_dep\.[0-9_]+, 2\);} "oaccdevlow" } } */


Grüße
 Thomas

Re: [PATCH 0/8] NVPTX offloading to NVPTX: backend patches

[Alexander Monakov]

On Tue, 18 Oct 2016, Bernd Schmidt wrote:
> [...] but then I think we shouldn't repeat the mistakes we made with OpenACC

I think it would be good if you'd mention for posterity what, specifically,
the mistakes were, in particular if you want those not to be repeated in the
context of OpenMP offloading.

Alexander

Re: [PATCH 0/8] NVPTX offloading to NVPTX: backend patches

[Bernd Schmidt]

On 10/18/2016 06:58 PM, Alexander Monakov wrote:


The currently published OpenMP version of LULESH simply doesn't use openmp-simd
anywhere. This should make it obvious that it won't be anywhere near any
reasonable CUDA implementation, and also bound to be below host performance.
Besides, it's common for such benchmark suites to have very different levels of
hand tuning for the native-CUDA implementation vs OpenMP implementation,
sometimes to the point of significant algorithmic differences. So you're
making an invalid comparison here.


The information I have is that the LULESH code is representative of how 
at least some groups on the HPC side expect to write OpenMP code. It's 
the biggest real-world piece of code that I'm aware of that's available 
for testing, so it seemed like a good thing to try. If you have other 
real-world tests available, please let us know. If you can demonstrate 
good performance by modifying LULESH sources, that would also be a good 
step, although maybe not the ideal case. But I think it's not 
unreasonable to look for a demonstration that reasonable performance is 
achievable on something that isn't just a microbenchmark.


I'll refrain from any further comments on the topic. The ptx patches 
don't look unreasonable iff someone else decides that this version of 
OpenMP support should be merged and I'll look into them in more detail 
if that happens. Patch 2/8 is ok now.



Bernd

[PATCH PR78005]Fix miscompare issue by computing correct guard condition for vectorized loop

[Bin Cheng]

Hi,
This is the patch fixing spec mis-compare issue reported in PR78005.  In the 
original patch, boundary condition was mis-handled when generating guard 
checking if vectorized/scalar loop should be preferred.  This isn't an issue in 
general, but in cases we need to peel for gaps, as well as skipping branch of 
epilogue loop can be optimized out, it could result in more iterations being 
executed.  That's why the mis-compare issue happens.  This patch corrects the 
bug, also cleans up existing code that computes loop niters and its upper 
bound.  The refactoring improves niters bound information for epilogue loop, 
thus the patch adjusts related tests.  An execution test is also added.

With the patch, mis-compare issue is fixed.  Bootstrap and test on x86_64 and 
AArch64.  Is it OK?

Thanks,
bin

2016-10-18  Bin Cheng  

PR tree-optimization/78005
* tree-vect-loop-manip.c (vect_gen_prolog_loop_niters): Compute
upper (included) bound for niters of prolog loop.
(vect_gen_scalar_loop_niters): Change parameter VF to VFM1.
Compute niters of scalar loop above which vectorized loop is
preferred, as well as the upper (included) bound for the niters.
(vect_do_peeling): Record niter bound for loops accordingly.

gcc/testsuite/ChangeLog
2016-10-18  Bin Cheng  

PR tree-optimization/78005
* gcc.dg/vect/pr78005.c: New.
* gcc.target/i386/l_fma_float_1.c: Revise test.
* gcc.target/i386/l_fma_float_2.c: Ditto.
* gcc.target/i386/l_fma_float_3.c: Ditto.
* gcc.target/i386/l_fma_float_4.c: Ditto.
* gcc.target/i386/l_fma_float_5.c: Ditto.
* gcc.target/i386/l_fma_float_6.c: Ditto.
* gcc.target/i386/l_fma_double_1.c: Ditto.
* gcc.target/i386/l_fma_double_2.c: Ditto.
* gcc.target/i386/l_fma_double_3.c: Ditto.
* gcc.target/i386/l_fma_double_4.c: Ditto.
* gcc.target/i386/l_fma_double_5.c: Ditto.
* gcc.target/i386/l_fma_double_6.c: Ditto.diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 291ecd9..6bfd332 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -904,7 +904,7 @@ vect_update_ivs_after_vectorizer (loop_vec_info loop_vinfo,
is the inner type of the vectype)
 
The computations will be emitted at the end of BB.  We also compute and
-   store upper bound of the result in BOUND.
+   store upper bound (included) of the result in BOUND.
 
When the step of the data-ref in the loop is not 1 (as in interleaved data
and SLP), the number of iterations of the prolog must be divided by the step
@@ -941,7 +941,7 @@ vect_gen_prolog_loop_niters (loop_vec_info loop_vinfo,
  "known peeling = %d.\n", npeel);
 
   iters = build_int_cst (niters_type, npeel);
-  *bound = LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) + 1;
+  *bound = LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo);
 }
   else
 {
@@ -976,7 +976,7 @@ vect_gen_prolog_loop_niters (loop_vec_info loop_vinfo,
iters = fold_build2 (MINUS_EXPR, type, nelements_tree, elem_misalign);
   iters = fold_build2 (BIT_AND_EXPR, type, iters, nelements_minus_1);
   iters = fold_convert (niters_type, iters);
-  *bound = nelements;
+  *bound = nelements - 1;
 }
 
   if (dump_enabled_p ())
@@ -1090,43 +1090,47 @@ vect_build_loop_niters (loop_vec_info loop_vinfo)
 }
 }
 
-/* Calculate the number of iterations under which scalar loop will be
-   preferred than vectorized loop.  NITERS_PROLOG is the number of
-   iterations of prolog loop.  If it's integer const, the integer
-   number is also passed by INT_NITERS_PROLOG.  VF is vector factor;
-   TH is the threshold for vectorized loop if CHECK_PROFITABILITY is
-   true.  This function also store upper bound of the result in BOUND.  */
+/* Calculate the number of iterations above which vectorized loop will be
+   preferred than scalar loop.  NITERS_PROLOG is the number of iterations
+   of prolog loop.  If it's integer const, the integer number is also passed
+   in INT_NITERS_PROLOG.  BOUND_PROLOG is the upper bound (included) of
+   number of iterations of prolog loop.  VFM1 is vector factor minus one.
+   If CHECK_PROFITABILITY is true, TH is the threshold below which scalar
+   (rather than vectorized) loop will be executed.  This function stores
+   upper bound (included) of the result in BOUND_SCALAR.  */
 
 static tree
 vect_gen_scalar_loop_niters (tree niters_prolog, int int_niters_prolog,
-int bound_prolog, int vf, int th, int *bound,
-bool check_profitability)
+int bound_prolog, int vfm1, int th,
+int *bound_scalar, bool check_profitability)
 {
   tree type = TREE_TYPE (niters_prolog);
   tree niters = fold_build2 (PLUS_EXPR, type, niters_prolog,
-build_int_cst (type, vf));
+bui

Re: [PATCH v2][AArch32][NEON] Implementing vmaxnmQ_ST and vminnmQ_ST intrinsincs.

[Tamar Christina]

> I think you forgot to attach the new tests.

Ah, you're right! forgot an add.

New patch coming soon.

Thanks,
Tamar

Re: [PATCH PR78005]Fix miscompare issue by computing correct guard condition for vectorized loop

[Richard Biener]

On Wed, Oct 19, 2016 at 12:38 PM, Bin Cheng  wrote:
> Hi,
> This is the patch fixing spec mis-compare issue reported in PR78005.  In the 
> original patch, boundary condition was mis-handled when generating guard 
> checking if vectorized/scalar loop should be preferred.  This isn't an issue 
> in general, but in cases we need to peel for gaps, as well as skipping branch 
> of epilogue loop can be optimized out, it could result in more iterations 
> being executed.  That's why the mis-compare issue happens.  This patch 
> corrects the bug, also cleans up existing code that computes loop niters and 
> its upper bound.  The refactoring improves niters bound information for 
> epilogue loop, thus the patch adjusts related tests.  An execution test is 
> also added.
>
> With the patch, mis-compare issue is fixed.  Bootstrap and test on x86_64 and 
> AArch64.  Is it OK?

Ok.

Thanks,
Richard.

> Thanks,
> bin
>
> 2016-10-18  Bin Cheng  
>
> PR tree-optimization/78005
> * tree-vect-loop-manip.c (vect_gen_prolog_loop_niters): Compute
> upper (included) bound for niters of prolog loop.
> (vect_gen_scalar_loop_niters): Change parameter VF to VFM1.
> Compute niters of scalar loop above which vectorized loop is
> preferred, as well as the upper (included) bound for the niters.
> (vect_do_peeling): Record niter bound for loops accordingly.
>
> gcc/testsuite/ChangeLog
> 2016-10-18  Bin Cheng  
>
> PR tree-optimization/78005
> * gcc.dg/vect/pr78005.c: New.
> * gcc.target/i386/l_fma_float_1.c: Revise test.
> * gcc.target/i386/l_fma_float_2.c: Ditto.
> * gcc.target/i386/l_fma_float_3.c: Ditto.
> * gcc.target/i386/l_fma_float_4.c: Ditto.
> * gcc.target/i386/l_fma_float_5.c: Ditto.
> * gcc.target/i386/l_fma_float_6.c: Ditto.
> * gcc.target/i386/l_fma_double_1.c: Ditto.
> * gcc.target/i386/l_fma_double_2.c: Ditto.
> * gcc.target/i386/l_fma_double_3.c: Ditto.
> * gcc.target/i386/l_fma_double_4.c: Ditto.
> * gcc.target/i386/l_fma_double_5.c: Ditto.
> * gcc.target/i386/l_fma_double_6.c: Ditto.

Re: [PATCH] Reduce stack usage in sha512 (PR target/77308)

[Christophe Lyon]

On 19 October 2016 at 10:34, Kyrill Tkachov  wrote:
>
> On 19/10/16 07:55, Christophe Lyon wrote:
>>
>> On 18 October 2016 at 17:35, Christophe Lyon 
>> wrote:
>>>
>>> On 18 October 2016 at 16:45, Bernd Edlinger 
>>> wrote:

 On 10/18/16 10:36, Christophe Lyon wrote:
>
> I am seeing a lot of regressions since this patch was committed:
>
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/241273/report-build-info.html
>
> (you can click on "REGRESSED" to see the list of regressions, "sum"
> and "log" to download
> the corresponding .sum/.log)
>
> Thanks,
>
> Christophe
>
 Oh, sorry, I have completely missed that.
 Unfortunately I have tested one of the good combinations.

 I have not considered the case that in and out could be
 the same register.  But that happens here.


 This should solve it.

 Can you give it a try?

>>> Sure, I have started the validations, it will take a few hours.
>>>
>> It looks OK, thanks.
>
>
> Ok. Thanks for testing Christophe.
> Sorry for not catching it in review.
> Kyrill
>

Since it was painful to check that this 2nd patch fixed all the regressions
observed in all the configurations, I ran another validation with
the 2 patches combined, on top of r241272 to check the effect of the two
over the previous reference.

It turns out there is still a failure:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/241272-r241273-combined/report-build-info.html
gcc.c-torture/execute/pr34971.c   -O0  execution test
now fails on arm-none-linux-gnueabihf when using thumb mode, expect
when targeting cortex-a5.

Christophe


 Thanks
 Bernd.
>
>

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Andreas Schwab]

FAIL: gcc.dg/Walloca-1.c  (test for warnings, line 26)
FAIL: gcc.dg/Walloca-1.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-1.c:26:5: warning: 
unbounded use of 'alloca' [-Walloca-larger-than=]
FAIL: gcc.dg/Walloca-2.c  (test for warnings, line 34)
FAIL: gcc.dg/Walloca-2.c note (test for warnings, line 34)
FAIL: gcc.dg/Walloca-2.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-2.c:11:7: warning: 
unbounded use of 'alloca' [-Walloca-larger-than=]
/daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-2.c:34:9: warning: 
unbounded use of 'alloca' [-Walloca-larger-than=]

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[patch, libstdc++] Optimize selection sampling by using generator to get two values at once

[Eelis van der Weegen]

This is the same optimization as was recently applied to std::shuffle.

It reduces the runtime of the following program by 20% on my machine:

int main()
{
std::vector a(1), b(1000);
std::mt19937 gen;

uint64_t c = 0;

for (int i = 0; i != 1000; ++i)
{
std::sample(a.begin(), a.end(), b.begin(), b.size(), 
gen);
c += uint64_t(b[32]);
}

std::cout << c;
}
Index: bits/stl_algo.h
===
--- bits/stl_algo.h	(revision 241299)
+++ bits/stl_algo.h	(working copy)
@@ -3741,6 +3741,37 @@
 
 #ifdef _GLIBCXX_USE_C99_STDINT_TR1
   /**
+   *  @brief Generate two uniformly distributed integers using a
+   * single distribution invocation.
+   *  @param  __b0The upper bound for the first integer.
+   *  @param  __b1The upper bound for the second integer.
+   *  @param  __g A UniformRandomBitGenerator.
+   *  @return  A pair (i, j) with i and j uniformly distributed
+   *   over [0, __b0) and [0, __b1), respectively.
+   *
+   *  Requires: __b0 * __b1 <= __g.max() - __g.min().
+   *
+   *  Using uniform_int_distribution with a range that is very
+   *  small relative to the range of the generator ends up wasting
+   *  potentially expensively generated randomness, since
+   *  uniform_int_distribution does not store leftover randomness
+   *  between invocations.
+   *
+   *  If we know we want two integers in ranges that are sufficiently
+   *  small, we can compose the ranges, use a single distribution
+   *  invocation, and significantly reduce the waste.
+  */
+  template
+std::pair<_IntType, _IntType>
+__gen_two_uniform_ints(_IntType __b0, _IntType __b1,
+			   _UniformRandomBitGenerator&& __g)
+{
+  _IntType __x = uniform_int_distribution<_IntType>{0, (__b0 * __b1) - 1}(__g);
+  return std::make_pair(__x / __b1, __x % __b1);
+}
+
+  /**
*  @brief Shuffle the elements of a sequence using a uniform random
* number generator.
*  @ingroup mutating_algorithms
@@ -3801,13 +3832,12 @@
 	while (__i != __last)
 	{
 	  const __uc_type __swap_range = __uc_type(__i - __first) + 1;
-	  const __uc_type __comp_range = __swap_range * (__swap_range + 1);
 
-	  std::uniform_int_distribution<__uc_type> __d{0, __comp_range - 1};
-	  const __uc_type __pospos = __d(__g);
+	  const std::pair<__uc_type, __uc_type> __pospos =
+	__gen_two_uniform_ints(__swap_range, __swap_range + 1);
 
-	  std::iter_swap(__i++, __first + (__pospos % __swap_range));
-	  std::iter_swap(__i++, __first + (__pospos / __swap_range));
+	  std::iter_swap(__i++, __first + __pospos.first);
+	  std::iter_swap(__i++, __first + __pospos.second);
 	}
 
 	return;
@@ -5695,9 +5725,51 @@
 {
   using __distrib_type = uniform_int_distribution<_Size>;
   using __param_type = typename __distrib_type::param_type;
+  using _USize = typename std::make_unsigned<_Size>::type;
+  using _Gen = typename std::remove_reference<_UniformRandomBitGenerator>::type;
+  using __uc_type = typename std::common_type::type;
+
   __distrib_type __d{};
   _Size __unsampled_sz = std::distance(__first, __last);
-  for (__n = std::min(__n, __unsampled_sz); __n != 0; ++__first)
+  __n = std::min(__n, __unsampled_sz);
+
+  // If possible, we use __gen_two_uniform_ints to efficiently produce
+  // two random numbers using a single distribution invocation:
+
+  const __uc_type __urngrange = __g.max() - __g.min();
+  if (__urngrange / __uc_type(__unsampled_sz) >= __uc_type(__unsampled_sz))
+// I.e. (__urngrange >= __unsampled_sz * __unsampled_sz) but without wrap issues.
+{
+	  while (__n != 0 && __unsampled_sz >= 2)
+	{
+	  const std::pair<_Size, _Size> p =
+		__gen_two_uniform_ints(__unsampled_sz, __unsampled_sz - 1, __g);
+
+	  --__unsampled_sz;
+	  if (p.first < __n)
+		{
+		  *__out++ = *__first;
+		  --__n;
+		}
+
+	  ++__first;
+
+	  if (__n == 0) break;
+
+	  --__unsampled_sz;
+	  if (p.second < __n)
+		{
+		  *__out++ = *__first;
+		  --__n;
+		}
+
+	  ++__first;
+	}
+}
+
+  // The loop above is otherwise equivalent to this one-at-a-time version:
+
+  for (; __n != 0; ++__first)
 	if (__d(__g, __param_type{0, --__unsampled_sz}) < __n)
 	  {
 	*__out++ = *__first;

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Christophe Lyon]

On 19 October 2016 at 12:45, Andreas Schwab  wrote:
> FAIL: gcc.dg/Walloca-1.c  (test for warnings, line 26)
> FAIL: gcc.dg/Walloca-1.c (test for excess errors)
> Excess errors:
> /daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-1.c:26:5: 
> warning: unbounded use of 'alloca' [-Walloca-larger-than=]
> FAIL: gcc.dg/Walloca-2.c  (test for warnings, line 34)
> FAIL: gcc.dg/Walloca-2.c note (test for warnings, line 34)
> FAIL: gcc.dg/Walloca-2.c (test for excess errors)
> Excess errors:
> /daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-2.c:11:7: 
> warning: unbounded use of 'alloca' [-Walloca-larger-than=]
> /daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-2.c:34:9: 
> warning: unbounded use of 'alloca' [-Walloca-larger-than=]
>

I'm seeing the same errors on arm* targets.

Christophe

> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types

[Thomas Schwinge]

Hi!

On Mon, 17 Oct 2016 17:59:16 +0200, I wrote:
> On Thu, 29 Sep 2016 15:18:00 +0200, Thomas Schwinge  
> wrote:
> > On Mon, 19 Sep 2016 13:25:01 +0200, Richard Biener 
> >  wrote:
> > > On Mon, Sep 19, 2016 at 1:19 PM, Thomas Schwinge
> > >  wrote:
> > > > On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener 
> > > >  wrote:
> > > >> On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge
> > > >>  wrote:
> > > >> > --- gcc/tree-streamer.c
> > > >> > +++ gcc/tree-streamer.c
> > > >> > @@ -278,9 +278,23 @@ record_common_node (struct 
> > > >> > streamer_tree_cache_d *cache, tree node)
> > > >> >streamer_tree_cache_append (cache, node, cache->nodes.length ());
> > > >> >
> > > >> >if (POINTER_TYPE_P (node)
> > > >> > -  || TREE_CODE (node) == COMPLEX_TYPE
> > > >> >|| TREE_CODE (node) == ARRAY_TYPE)
> > > >> >  record_common_node (cache, TREE_TYPE (node));
> > > >> > +  else if (TREE_CODE (node) == COMPLEX_TYPE)
> > > >> > +{
> > > >> > +  /* Assert that complex types' component types have already 
> > > >> > been handled
> > > >> > +(and we thus don't need to recurse here).  See PR 
> > > >> > lto/77458.  */
> > > >> > +[...]
> > 
> > > >> So I very much like to go forward with this kind of change as well
> > 
> > > > [patch]
> > 
> > > Ok with [changes]
> > 
> > Like this?  (I'll then continue to replicate this for other tree codes.)

> --- gcc/tree-streamer.c
> +++ gcc/tree-streamer.c

> +/* Verify that NODE is in CACHE.  */
> +
> +static void
> +verify_common_node_recorded (struct streamer_tree_cache_d *cache, tree node)
> +{
> +  /* Restrict this to flag_checking only because in general violating it is
> + harmless plus we never know what happens on all targets/frontend/flag(!)
> + combinations.  */
> +  if (!flag_checking)
> +return;
> +
> +  bool found = false;
> +  if (cache->node_map)
> +gcc_assert (streamer_tree_cache_lookup (cache, node, NULL));
> +  else
> +{
> +  gcc_assert (cache->nodes.exists ());
> +  /* Linear search...  */
> +  for (unsigned i = 0; !found && i < cache->nodes.length (); ++i)
> + if (cache->nodes[i] == node)
> +   found = true;
> +  gcc_assert (found);
> +}
> +}

With the "bool found" definition moved into the else branch, committed to
trunk in r241338:

commit 2ba42fa30f9ea5bb8ade209d7ff40229fd574856
Author: tschwinge 
Date:   Wed Oct 19 10:48:46 2016 +

[PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx 
types

gcc/
PR lto/77458
* tree-core.h (enum tree_index): Put the complex types after their
component types.
* tree-streamer.c (verify_common_node_recorded): New function.
(preload_common_nodes) : Use it.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241338 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog   |  8 
 gcc/tree-core.h | 31 +--
 gcc/tree-streamer.c | 32 +++-
 3 files changed, 56 insertions(+), 15 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 59b00d16..b50e2e4 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,11 @@
+2016-10-19  Thomas Schwinge  
+
+   PR lto/77458
+   * tree-core.h (enum tree_index): Put the complex types after their
+   component types.
+   * tree-streamer.c (verify_common_node_recorded): New function.
+   (preload_common_nodes) : Use it.
+
 2016-10-19  Martin Liska  
 
* cgraph.h (cgraph_edge::binds_to_current_def_p):
diff --git gcc/tree-core.h gcc/tree-core.h
index 1bfe682..3e3f31e 100644
--- gcc/tree-core.h
+++ gcc/tree-core.h
@@ -556,20 +556,6 @@ enum tree_index {
   TI_BOOLEAN_FALSE,
   TI_BOOLEAN_TRUE,
 
-  TI_COMPLEX_INTEGER_TYPE,
-  TI_COMPLEX_FLOAT_TYPE,
-  TI_COMPLEX_DOUBLE_TYPE,
-  TI_COMPLEX_LONG_DOUBLE_TYPE,
-
-  TI_COMPLEX_FLOAT16_TYPE,
-  TI_COMPLEX_FLOATN_NX_TYPE_FIRST = TI_COMPLEX_FLOAT16_TYPE,
-  TI_COMPLEX_FLOAT32_TYPE,
-  TI_COMPLEX_FLOAT64_TYPE,
-  TI_COMPLEX_FLOAT128_TYPE,
-  TI_COMPLEX_FLOAT32X_TYPE,
-  TI_COMPLEX_FLOAT64X_TYPE,
-  TI_COMPLEX_FLOAT128X_TYPE,
-
   TI_FLOAT_TYPE,
   TI_DOUBLE_TYPE,
   TI_LONG_DOUBLE_TYPE,
@@ -599,6 +585,23 @@ enum tree_index {
 - TI_FLOATN_NX_TYPE_FIRST  \
 + 1)
 
+  /* Put the complex types after their component types, so that in (sequential)
+ tree streaming we can assert that their component types have already been
+ handled (see tree-streamer.c:record_common_node).  */
+  TI_COMPLEX_INTEGER_TYPE,
+  TI_COMPLEX_FLOAT_TYPE,
+  TI_COMPLEX_DOUBLE_TYPE,
+  TI_COMPLEX_LONG_DOUBLE_TYPE,
+
+  TI_COMPLEX_FLOAT16_TYPE,
+  TI_COMPLEX_FLOATN_NX_TYPE_FIRST = TI_COMPLEX_FLOAT16_TYPE,
+  TI_COMPLEX_FLOAT32_TYPE,
+  TI_COMPLEX_FLOAT64_TYPE,
+  TI_COMPLEX_FLOAT128_TYPE,
+  TI_COMPLEX_FLOAT32X_TYPE,
+  TI_COMPLEX_FLOAT64X_TYPE,
+  TI_COMPLEX_FLOAT128X_TYPE,
+
   TI_FLOAT_PTR_TYPE,
   TI_DOUBLE_PTR_TYPE,
   TI_LONG_DOUBLE_PTR_TYPE,
diff --git 

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Andreas Schwab]

At line 74 of file /opt/gcc/gcc-20161019/gcc/testsuite/gfortran.dg/dtio_17.f90 
(unit = 28, file = '/tmp/gfortrantmpQF10b7')
Fortran runtime error: Bad value during integer read

Error termination. Backtrace:
FAIL: gfortran.dg/dtio_17.f90   -O1  execution test

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Implement -Wduplicated-branches (PR c/64279)

[Marek Polacek]

This patch introduces a new warning, -Wduplicated-branches.  Its purpose is
to warn for code such as

  if (cond)
return 0;
  else
return 0;

as well as e.g.

  r = i ? *p : *p;

The approach I took was to use inchash::add_expr to hash the expressions
and then compare the hashes.  But of course nothing's that easy.  The
warning should stay quiet for various macro usages so I've introduced
expr_from_macro_expansion_r.  But since integer csts and various decls
don't carry location info, this works only partially, so the warning
warns even for e.g.

  if (TREE_STATIC (node) || DECL_EXTERNAL (node))
max_align = MAX_OFILE_ALIGNMENT;
  else
max_align = MAX_STACK_ALIGNMENT;

when MAX_OFILE_ALIGNMENT and MAX_STACK_ALIGNMENT represent the same number.
There's no way to get around this, so the warning isn't enabled by nor
-Wall neither -Wextra, and can't be until we solve the pesky location
horror.  (-Wduplicated-cond is off for the very same reason.)

add_expr didn't handle error_mark_node that can get there from the FEs
(an undeclared variable, etc.), so that's why the change.  But maybe
it'd be better to walk the tree in do_warn_duplicated_branches, and if
if sees an error node, don't attempt to hash the expr.

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

2016-10-19  Marek Polacek  

PR c/64279
* c-common.h (do_warn_duplicated_branches_r,
do_warn_duplicated_branches): Declare.
* c-gimplify.c (c_genericize): Walk the function tree calling
do_warn_duplicated_branches_r.
* c-warn.c (expr_from_macro_expansion_r): New.
(do_warn_duplicated_branches): New.
(do_warn_duplicated_branches_r): New.
* c.opt (Wduplicated-branches): New option.

* c-typeck.c (build_conditional_expr): Warn about duplicated branches.

* call.c (build_conditional_expr_1): Warn about duplicated branches.
* semantics.c (finish_expr_stmt): Build statement using the proper
location.

* doc/invoke.texi: Document -Wduplicated-branches.
* fold-const.c (fold_build_cleanup_point_expr): Use the expression
location when building CLEANUP_POINT_EXPR.
* tree.c (add_expr): Handle error_mark_node.

* c-c++-common/Wduplicated-branches-1.c: New test.
* c-c++-common/Wduplicated-branches-2.c: New test.
* c-c++-common/Wduplicated-branches-3.c: New test.
* c-c++-common/Wduplicated-branches-4.c: New test.
* c-c++-common/Wduplicated-branches-5.c: New test.
* c-c++-common/Wduplicated-branches-6.c: New test.
* c-c++-common/Wduplicated-branches-7.c: New test.
* c-c++-common/Wduplicated-branches-8.c: New test.
* c-c++-common/Wduplicated-branches-9.c: New test.
* c-c++-common/Wimplicit-fallthrough-7.c: Coalesce dg-warning.
* g++.dg/cpp0x/lambda/lambda-switch.C: Move dg-warning.
* g++.dg/ext/builtin-object-size3.C (bar): Likewise.
* g++.dg/gomp/loop-1.C: Likewise.
* g++.dg/warn/Wduplicated-branches1.C: New test.

diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index bfdbda0..67e 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -1530,6 +1530,8 @@ extern void maybe_warn_bool_compare (location_t, enum 
tree_code, tree, tree);
 extern bool maybe_warn_shift_overflow (location_t, tree, tree);
 extern void warn_duplicated_cond_add_or_warn (location_t, tree, vec **);
 extern bool diagnose_mismatched_attributes (tree, tree);
+extern tree do_warn_duplicated_branches_r (tree *, int *, void *);
+extern void do_warn_duplicated_branches (tree);
 
 /* In c-attribs.c.  */
 extern bool attribute_takes_identifier_p (const_tree);
diff --git gcc/c-family/c-gimplify.c gcc/c-family/c-gimplify.c
index c18b057..3ed2da8 100644
--- gcc/c-family/c-gimplify.c
+++ gcc/c-family/c-gimplify.c
@@ -125,6 +125,10 @@ c_genericize (tree fndecl)
 &pset);
 }
 
+  if (warn_duplicated_branches)
+walk_tree_without_duplicates (&DECL_SAVED_TREE (fndecl),
+ do_warn_duplicated_branches_r, NULL);
+
   /* Dump the C-specific tree IR.  */
   dump_orig = get_dump_info (TDI_original, &local_dump_flags);
   if (dump_orig)
diff --git gcc/c-family/c-warn.c gcc/c-family/c-warn.c
index 904f6d3..f6e8e71 100644
--- gcc/c-family/c-warn.c
+++ gcc/c-family/c-warn.c
@@ -2154,3 +2154,67 @@ maybe_warn_bool_compare (location_t loc, enum tree_code 
code, tree op0,
"with boolean expression is always false", cst);
 }
 }
+
+/* Callback function to determine whether an expression TP or one of its
+   subexpressions comes from macro expansion.  Used to suppress bogus
+   warnings.  */
+
+static tree
+expr_from_macro_expansion_r (tree *tp, int *, void *)
+{
+  if (CAN_HAVE_LOCATION_P (*tp)
+  && from_macro_expansion_at (EXPR_LOCATION (*tp)))
+return integer_zero_node;
+
+  return NULL_TREE;
+}
+
+/* Possibly warn when an if-else has identical br

Re: libgo patch committed: copy rdebug code from Go 1.7

[Richard Biener]

On Mon, Oct 17, 2016 at 6:54 PM, Ian Lance Taylor  wrote:
> This patch to libgo copies the rdebug code from the Go 1.7 runtime to libgo.
>
> While we're at it, this updates the runtime/debug package, and starts
> running its testsuite by default.  I'm not sure why runtime/debug was
> not previously updated to 1.7.  Doing that led me to fix some minor
> aspects of runtime.Stack and the C function runtime/debug.readGCStats.
>
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> to mainline.

Not sure which of the merges broke it but I get

...
rc/svn/trunk2/libgo/go/runtime/time.go
/space/rguenther/src/svn/trunk2/libgo/go/runtime/trace.go
/space/rguenther/src/svn/trunk2/libgo/go/runtime/traceback_gccgo.go
/space/rguenther/src/svn/trunk2/libgo/go/runtime/type.go
/space/rguenther/src/svn/trunk2/libgo/go/runtime/typekind.go
/space/rguenther/src/svn/trunk2/libgo/go/runtime/write_err.go
runtime_sysinfo.go  -fPIC -o .libs/runtime-go.o
/space/rguenther/src/svn/trunk2/libgo/go/runtime/netpoll_epoll.go:52:49:
error:integer constant overflow
  ev.events = _EPOLLIN | _EPOLLOUT | _EPOLLRDHUP | _EPOLLET
 ^
make[4]: *** [runtime-go.lo] Error 1

now and bootstrap is broken for me.  This is on x86_64-linux, SLES 11
SP4 which uses glibc 2.11.3.

There is a missing space after 'error:' as well.

Please fix.

Thanks,
Richard.

> Ian

[PATCH] Do not disable aggressive loop opts for, -fsanitize=unreachable or leak

[Martin Liška]

Hello.

This patch allows aggressive loop optimizations and strict overflow when
-fsanitize=unreachabne or -fsanitize=leak is (are) enabled. That would
help kernel people to have assumption that every functions should either
end with jmp ret or by __builtin___ubsan_handle_builtin_unreachable.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From 7f1648ef3480c6db856e567153cf9bb838c77d4f Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 17 Oct 2016 15:58:50 +0200
Subject: [PATCH] Do not disable aggressive loop opts for
 -fsanitize=unreachable or leak

gcc/ChangeLog:

2016-10-17  Martin Liska  

	PR sanitizer/77966
	* opts.c (finish_options): Skip conditionally.

gcc/testsuite/ChangeLog:

2016-10-17  Martin Liska  

	PR sanitizer/77966
	* c-c++-common/ubsan/unreachable-3.c: New test.
---
 gcc/opts.c   |  2 +-
 gcc/testsuite/c-c++-common/ubsan/unreachable-3.c | 21 +
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/unreachable-3.c

diff --git a/gcc/opts.c b/gcc/opts.c
index 90e6186..e909240 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -972,7 +972,7 @@ finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
 opts->x_flag_delete_null_pointer_checks = 0;
 
   /* Aggressive compiler optimizations may cause false negatives.  */
-  if (opts->x_flag_sanitize)
+  if (opts->x_flag_sanitize & ~(SANITIZE_LEAK | SANITIZE_UNREACHABLE))
 {
   opts->x_flag_aggressive_loop_optimizations = 0;
   opts->x_flag_strict_overflow = 0;
diff --git a/gcc/testsuite/c-c++-common/ubsan/unreachable-3.c b/gcc/testsuite/c-c++-common/ubsan/unreachable-3.c
new file mode 100644
index 000..b7a0d1a
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/ubsan/unreachable-3.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=unreachable -O2 -fno-reorder-blocks -fsanitize-coverage=trace-pc -fdump-tree-optimized" } */
+/* { dg-skip-if "" { *-*-* } { "-flto" } } */
+
+extern unsigned int ioread32(void *);
+struct vnic_wq_ctrl {
+unsigned int error_status;
+};
+struct snic {
+unsigned int wq_count;
+struct vnic_wq_ctrl *wq[1];
+int wq_lock[1];
+};
+void snic_log_q_error(struct snic *snic)
+{
+unsigned int i;
+for (i = 0; i < snic->wq_count; i++)
+ioread32(&snic->wq[i]->error_status);
+}
+
+/* { dg-final { scan-tree-dump "__builtin___ubsan_handle_builtin_unreachable" "optimized" } } */
-- 
2.10.1

Re: [PATCH] Fix std::experimental::shared_ptr SFINAE constraints

[Jonathan Wakely]

On 19/10/16 10:35 +0100, Jonathan Wakely wrote:

There are lots of SFINAE checks missing from experimental::shared_ptr,
and we even test that shared_ptr(new derived[1]) works, when
it should be ill-formed.


Moar tests!

Tested powerpc64le-linux, committed to trunk.

commit 9258e632b7810db67cef4e60c5c22bef3571b3bb
Author: Jonathan Wakely 
Date:   Wed Oct 19 12:06:31 2016 +0100

Test experimental::shared_ptr construction from other smart pointers

	* testsuite/experimental/memory/shared_ptr/cons/unique_ptr_ctor.cc:
	Add tests for valid and invalid conversions.
	* testsuite/experimental/memory/shared_ptr/cons/weak_ptr_ctor.cc:
	Likewise.

diff --git a/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/unique_ptr_ctor.cc b/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/unique_ptr_ctor.cc
index 631212f..0e61a3c 100644
--- a/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/unique_ptr_ctor.cc
+++ b/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/unique_ptr_ctor.cc
@@ -29,10 +29,35 @@ struct A : std::experimental::enable_shared_from_this
   ~A() { ++destroyed; }
 };
 
+struct B : A { };
+
 // 8.2.1.1 shared_ptr constructors [memory.smartptr.shared.const]
 
 // Construction from unique_ptr
 
+template
+constexpr bool constructible()
+{
+  using std::experimental::shared_ptr;
+  using std::experimental::is_constructible_v;
+  using std::unique_ptr;
+  return is_constructible_v, unique_ptr>;
+}
+
+static_assert(  constructible< A,A>(), "A -> A compatible" );
+static_assert( !constructible< A,A[]  >(), "A -> A[] not compatible" );
+static_assert( !constructible< A,A[1] >(), "A -> A[1] not compatible" );
+static_assert( !constructible< A[],  A>(), "A[] -> A not compatible" );
+static_assert(  constructible< A[],  A[]  >(), "A[] -> A[] compatible" );
+static_assert( !constructible< A[],  A[1] >(), "A[] -> A[1] not compatible" );
+
+static_assert(  constructible< B,A>(), "B -> A compatible" );
+static_assert( !constructible< B,A[]  >(), "B -> A[] not compatible" );
+static_assert( !constructible< B,A[1] >(), "B -> A[1] not compatible" );
+static_assert( !constructible< B[],  A>(), "B[] -> A not compatible" );
+static_assert( !constructible< B[],  A[]  >(), "B[] -> A[] not compatible" );
+static_assert( !constructible< B[],  A[1] >(), "B[2] -> A[1] not compatible" );
+
 void
 test01()
 {
diff --git a/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/weak_ptr_ctor.cc b/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/weak_ptr_ctor.cc
index 71cf583..3436c01 100644
--- a/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/weak_ptr_ctor.cc
+++ b/libstdc++-v3/testsuite/experimental/memory/shared_ptr/cons/weak_ptr_ctor.cc
@@ -23,11 +23,46 @@
 #include 
 
 struct A { };
+struct B : A { };
 
 // 8.2.1.1 shared_ptr constructors [memory.smartptr.shared.const]
 
+template
+constexpr bool constructible()
+{
+  using std::experimental::shared_ptr;
+  using std::experimental::weak_ptr;
+  using std::experimental::is_constructible_v;
+  return is_constructible_v, weak_ptr>
+&& is_constructible_v, const weak_ptr&>;
+}
+
+static_assert(  constructible< A,A>(), "A -> A compatible" );
+static_assert( !constructible< A,A[]  >(), "A -> A[] not compatible" );
+static_assert( !constructible< A,A[1] >(), "A -> A[1] not compatible" );
+static_assert( !constructible< A[],  A>(), "A[] -> A not compatible" );
+static_assert(  constructible< A[],  A[]  >(), "A[] -> A[] compatible" );
+static_assert( !constructible< A[],  A[1] >(), "A[] -> A[1] not compatible" );
+static_assert( !constructible< A[1], A>(), "A[1] -> A not compatible" );
+static_assert(  constructible< A[1], A[]  >(), "A[1] -> A[] compatible" );
+static_assert(  constructible< A[1], A[1] >(), "A[1] -> A[1] compatible" );
+static_assert( !constructible< A[2], A[1] >(), "A[2] -> A[1] not compatible" );
+
+static_assert(  constructible< B,A>(), "B -> A compatible" );
+static_assert( !constructible< B,A[]  >(), "B -> A[] not compatible" );
+static_assert( !constructible< B,A[1] >(), "B -> A[1] not compatible" );
+static_assert( !constructible< B[],  A>(), "B[] -> A not compatible" );
+static_assert( !constructible< B[],  A[]  >(), "B[] -> A[] not compatible" );
+static_assert( !constructible< B[],  A[1] >(), "B[] -> A[1] not compatible" );
+static_assert( !constructible< B[1], A>(), "B[] -> A not compatible" );
+static_assert( !constructible< B[1], A[]  >(), "B[] -> A[] not compatible" );
+static_assert( !constructible< B[1], A[1] >(), "B[] -> A[1] not compatible" );
+static_assert( !constructible< B[2], A[1] >(), "B[2] -> A[1] not compatible" );
+
+
+
 // Construction from weak_ptr
-int
+void
 test01()
 {
   A * a = new A[5];
@@ -39,14 +74,10 @@ test01()
   VERIFY( a3.get() == a );
   VERIFY( a2.use_count() == wa.use_count() );
   VERIFY( a3.use_count() == wa.use_count() );
-
-  return 0;
 }
 
-
 int
 main()

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

[Rainer Orth]

Hi Jakub,

>> 2016-10-01  Rainer Orth  
>> 
>>  * configure.ac (target_libraries): Readd target-boehm-gc.
>>  Restore --enable-objc-gc handling.
>>  * configure: Regenerate.
>
> This is incomplete.  I guess it can be committed as is, but should be
> followed by re-addition of:
>   bfin-*-*)
> noconfigdirs="$noconfigdirs target-boehm-gc"
> ;;
>   cris-*-* | crisv32-*-*)
> case "${target}" in
>   *-*-linux*)
> ;;
>   *) # See PR46792 regarding target-libffi.
> noconfigdirs="$noconfigdirs target-boehm-gc";;
> esac
> ;;
>   mmix-*-*)
> noconfigdirs="$noconfigdirs target-boehm-gc"
> ;;
> (perhaps in the same case as target-libffi handling).

sorry I missed this.  I can still re-add it if desired, but would rather
keep it in a separate case from the target-libffi handling: in-tree
boehm-gc may be replaced with an external version, while libffi is
likely to stay for libgo.

Rainer

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

Re: [PATCH 0/8] NVPTX offloading to NVPTX: backend patches

[Jakub Jelinek]

On Tue, Oct 18, 2016 at 07:58:49PM +0300, Alexander Monakov wrote:
> On Tue, 18 Oct 2016, Bernd Schmidt wrote:
> > The performance I saw was lower by a factor of 80 or so compared to their 
> > CUDA
> > version, and even lower than OpenMP on the host.
> 
> The currently published OpenMP version of LULESH simply doesn't use 
> openmp-simd
> anywhere. This should make it obvious that it won't be anywhere near any
> reasonable CUDA implementation, and also bound to be below host performance.
> Besides, it's common for such benchmark suites to have very different levels 
> of
> hand tuning for the native-CUDA implementation vs OpenMP implementation,
> sometimes to the point of significant algorithmic differences. So you're
> making an invalid comparison here.

This is related to the independent clause/construct (or whatever other
names) discussions, the problem with LULESH's
#pragma distribute parallel for
rather than
#pragma distribute parallel for simd
is that usually it calls (inline) functions, and distribute parallel for,
even with the implementation defined default for schedule() clause, isn't
just let the implementation choose distribution between teams/threads/simd
it likes; for loops which don't call any functions we can scan the loop body
and figure out if it could e.g. through various omp_* calls observe anything
that could reveal how it is distributed among teams/threads/simd, but for
loops that can call other functions that is hard to do, especially as early
as during omp lowering/expansion.
OpenMP 5.0 is likely going to have some clause or whatever that will just
say the loop iterations are completely independent, but until then the
programmer uses more prescriptive pragmas and needs to be careful what
exactly they want.

But, certainly we should collect some OpenMP/OpenACC offloading benchmarks
or write our own and use that to compare GCC with other compilers.

Jakub

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Aldy Hernandez]

On 10/19/2016 03:08 AM, Eric Botcazou wrote:

My apologies for the delay.  I have finally committed this patch.
Before doing so, I merged with trunk and re-tested (x86-64 Linux) just
in case.  There were no regressions.


Can you rename the testcases?  Git doesn't like the names:

*** These collisions happen when the name of two or more files
*** differ in casing only (Eg: "hello.txt" and "Hello.txt").
*** Please re-do your commit, chosing names that do not collide.
***
*** Commit: 09b6f37fdbc6b8955a13bce336f4679bb0da78d7
*** Subject: Manual merge of 'origin/fsf-gcc-head-branch' into gcc-head
(no-tn-check).
***
*** The matching files are:
***
*** gcc/testsuite/gcc.dg/Wvla-2.c
*** gcc/testsuite/gcc.dg/wvla-2.c
***
*** gcc/testsuite/gcc.dg/Wvla-1.c
*** gcc/testsuite/gcc.dg/wvla-1.c
***
*** gcc/testsuite/gcc.dg/Wvla-3.c
*** gcc/testsuite/gcc.dg/wvla-3.c)



It seems to me that there is a precedence for -W type tests to start 
with a capital letter, as opposed to a lowercase letter:


$ cd gcc.dg
$ ls W[a-z]* |wc
280 2805816

Do you think it would perhaps be reasonable to rename all of them to 
uppercase?  You could take -Wvla-[1-7].c and I can take the subsequent ones?


Aldy

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Aldy Hernandez]

On 10/19/2016 06:45 AM, Andreas Schwab wrote:

FAIL: gcc.dg/Walloca-1.c  (test for warnings, line 26)
FAIL: gcc.dg/Walloca-1.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-1.c:26:5: warning: 
unbounded use of 'alloca' [-Walloca-larger-than=]
FAIL: gcc.dg/Walloca-2.c  (test for warnings, line 34)
FAIL: gcc.dg/Walloca-2.c note (test for warnings, line 34)
FAIL: gcc.dg/Walloca-2.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-2.c:11:7: warning: 
unbounded use of 'alloca' [-Walloca-larger-than=]
/daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-2.c:34:9: warning: 
unbounded use of 'alloca' [-Walloca-larger-than=]

Andreas.



Is this for Arm as Christophe reported, or this on another target?

triplet?

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Andreas Schwab]

On Okt 19 2016, Aldy Hernandez  wrote:

> On 10/19/2016 06:45 AM, Andreas Schwab wrote:
>> FAIL: gcc.dg/Walloca-1.c  (test for warnings, line 26)
>> FAIL: gcc.dg/Walloca-1.c (test for excess errors)
>> Excess errors:
>> /daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-1.c:26:5: 
>> warning: unbounded use of 'alloca' [-Walloca-larger-than=]
>> FAIL: gcc.dg/Walloca-2.c  (test for warnings, line 34)
>> FAIL: gcc.dg/Walloca-2.c note (test for warnings, line 34)
>> FAIL: gcc.dg/Walloca-2.c (test for excess errors)
>> Excess errors:
>> /daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-2.c:11:7: 
>> warning: unbounded use of 'alloca' [-Walloca-larger-than=]
>> /daten/aranym/gcc/gcc-20161019/gcc/testsuite/gcc.dg/Walloca-2.c:34:9: 
>> warning: unbounded use of 'alloca' [-Walloca-larger-than=]
>>
>> Andreas.
>>
>
> Is this for Arm as Christophe reported, or this on another target?

m68k-suse-linux

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Eric Botcazou]

> m68k-suse-linux

visium-elf too.

-- 
Eric Botcazou

Re: libgo patch committed: copy rdebug code from Go 1.7

[Ian Lance Taylor]

On Wed, Oct 19, 2016 at 4:30 AM, Richard Biener
 wrote:
> On Mon, Oct 17, 2016 at 6:54 PM, Ian Lance Taylor  wrote:
>> This patch to libgo copies the rdebug code from the Go 1.7 runtime to libgo.
>>
>> While we're at it, this updates the runtime/debug package, and starts
>> running its testsuite by default.  I'm not sure why runtime/debug was
>> not previously updated to 1.7.  Doing that led me to fix some minor
>> aspects of runtime.Stack and the C function runtime/debug.readGCStats.
>>
>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
>> to mainline.
>
> Not sure which of the merges broke it but I get
>
> ...
> rc/svn/trunk2/libgo/go/runtime/time.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/trace.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/traceback_gccgo.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/type.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/typekind.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/write_err.go
> runtime_sysinfo.go  -fPIC -o .libs/runtime-go.o
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/netpoll_epoll.go:52:49:
> error:integer constant overflow
>   ev.events = _EPOLLIN | _EPOLLOUT | _EPOLLRDHUP | _EPOLLET
>  ^
> make[4]: *** [runtime-go.lo] Error 1
>
> now and bootstrap is broken for me.  This is on x86_64-linux, SLES 11
> SP4 which uses glibc 2.11.3.

Is this the 32-bit or 64-bit build?

What is the output of

find x86_64-pc-linux-gnu -name runtime_sysinfo.go | xargs grep EPOLLET

in your build directory?

Ian

Re: libgo patch committed: copy rdebug code from Go 1.7

[Richard Biener]

On Wed, Oct 19, 2016 at 3:17 PM, Ian Lance Taylor  wrote:
> On Wed, Oct 19, 2016 at 4:30 AM, Richard Biener
>  wrote:
>> On Mon, Oct 17, 2016 at 6:54 PM, Ian Lance Taylor  wrote:
>>> This patch to libgo copies the rdebug code from the Go 1.7 runtime to libgo.
>>>
>>> While we're at it, this updates the runtime/debug package, and starts
>>> running its testsuite by default.  I'm not sure why runtime/debug was
>>> not previously updated to 1.7.  Doing that led me to fix some minor
>>> aspects of runtime.Stack and the C function runtime/debug.readGCStats.
>>>
>>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
>>> to mainline.
>>
>> Not sure which of the merges broke it but I get
>>
>> ...
>> rc/svn/trunk2/libgo/go/runtime/time.go
>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/trace.go
>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/traceback_gccgo.go
>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/type.go
>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/typekind.go
>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/write_err.go
>> runtime_sysinfo.go  -fPIC -o .libs/runtime-go.o
>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/netpoll_epoll.go:52:49:
>> error:integer constant overflow
>>   ev.events = _EPOLLIN | _EPOLLOUT | _EPOLLRDHUP | _EPOLLET
>>  ^
>> make[4]: *** [runtime-go.lo] Error 1
>>
>> now and bootstrap is broken for me.  This is on x86_64-linux, SLES 11
>> SP4 which uses glibc 2.11.3.
>
> Is this the 32-bit or 64-bit build?

Hum, don't remember ...

> What is the output of
>
> find x86_64-pc-linux-gnu -name runtime_sysinfo.go | xargs grep EPOLLET
>
> in your build directory?

x86_64-pc-linux-gnu/32/libgo/runtime_sysinfo.go:const _EPOLLET = -2147483648
x86_64-pc-linux-gnu/libgo/runtime_sysinfo.go:const _EPOLLET = -2147483648

looks like the culprit.  All other _EPOLL* constants are positive

Richard.

> Ian

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Eric Botcazou]

> It seems to me that there is a precedence for -W type tests to start
> with a capital letter, as opposed to a lowercase letter:
> 
> $ cd gcc.dg
> $ ls W[a-z]* |wc
>  280 2805816
> 
> Do you think it would perhaps be reasonable to rename all of them to
> uppercase?

Yes, I agree that this would be more consistent.

> You could take -Wvla-[1-7].c and I can take the subsequent ones?

Not sure if this wouldn't make us tread on each other's toe. ;-)  I'd just 
rename your 3 new testcases (-Wvla-larger-than-1.c, Wvla-larger-than-2.c and 
Walloca-11.c probably) and promote the existing wvla-[1-7].c to uppercase.

-- 
Eric Botcazou

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Aldy Hernandez]

On 10/19/2016 09:24 AM, Eric Botcazou wrote:

It seems to me that there is a precedence for -W type tests to start
with a capital letter, as opposed to a lowercase letter:

$ cd gcc.dg
$ ls W[a-z]* |wc
 280 2805816

Do you think it would perhaps be reasonable to rename all of them to
uppercase?


Yes, I agree that this would be more consistent.


You could take -Wvla-[1-7].c and I can take the subsequent ones?


Not sure if this wouldn't make us tread on each other's toe. ;-)  I'd just
rename your 3 new testcases (-Wvla-larger-than-1.c, Wvla-larger-than-2.c and
Walloca-11.c probably) and promote the existing wvla-[1-7].c to uppercase.



It's unclear from your response whether you want to do this or want me 
to do it.  In the interest of being lazy, I'll let you do it :).


Aldy

p.s. If OTOH, you want me to do it, let me know.

Get rid of useless .oaccdevlow dump file

[Eric Botcazou]

Yet another pass generating a useless dump file when it is not run.

Tested on x86_64-suse-linux, applied on mainline as obvious.


2016-10-19  Eric Botcazou  

* omp-low.c (pass_oacc_device_lower::gate): New method.
(execute): Always call execute_oacc_device_lower.

-- 
Eric BotcazouIndex: omp-low.c
===
--- omp-low.c	(revision 241326)
+++ omp-low.c	(working copy)
@@ -19850,13 +19850,10 @@ public:
   {}
 
   /* opt_pass methods: */
+  virtual bool gate (function *) { return flag_openacc; };
+
   virtual unsigned int execute (function *)
 {
-  bool gate = flag_openacc != 0;
-
-  if (!gate)
-	return 0;
-
   return execute_oacc_device_lower ();
 }
 

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Eric Botcazou]

> It's unclear from your response whether you want to do this or want me
> to do it.  In the interest of being lazy, I'll let you do it :).

I guess this wasn't really decided in my mind either. ;-)

> p.s. If OTOH, you want me to do it, let me know.

Yes, please do, thanks in advance.

-- 
Eric Botcazou

[PATCH] Fix PR77916

[Bill Schmidt]

Hi,

The previous fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77916
ensured that record_increment would use normal multiplier initializers
for increments of -1 with unknown strides, just as for all other negative
increments.  However, we still had a problem in insert_initializers wherein
the test for whether the replacement will need a POINTER_PLUS_EXPR was not
accurate.  This patch fixes this, and again removes the stopgap solution
so that we can process -1 increments with pointer types.

Markus Trippelsdorf kindly tested all of the ffmpeg code on x86_64 with
-march=amdfam10 to ensure there are no more of these issues lurking there.
That has been a fertile environment for these kinds of negative pointer
increments.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no new
regressions, committed.

Thanks,
Bill


2016-10-19  Bill Schmidt  

PR tree-optimization/77916
PR tree-optimization/77937
* gimple-ssa-strength-reduction.c (analyze_increments): Remove
stopgap fix.
(insert_initializers): Requirement of initializer for -1 should be
based on pointer-typedness of the candidate basis.


Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c (revision 241305)
+++ gcc/gimple-ssa-strength-reduction.c (working copy)
@@ -2825,10 +2825,6 @@ analyze_increments (slsr_cand_t first_dep, machine
   && !POINTER_TYPE_P (first_dep->cand_type)))
incr_vec[i].cost = COST_NEUTRAL;
 
-  /* FIXME: Still having trouble with pointers with a -1 increment.  */
-  else if (incr == -1 && POINTER_TYPE_P (first_dep->cand_type))
-   incr_vec[i].cost = COST_INFINITE;
-
   /* FORNOW: If we need to add an initializer, give up if a cast from
 the candidate's type to its stride's type can lose precision.
 This could eventually be handled better by expressly retaining the
@@ -3115,7 +3111,7 @@ insert_initializers (slsr_cand_t c)
   if (!profitable_increment_p (i)
  || incr == 1
  || (incr == -1
- && gimple_assign_rhs_code (c->cand_stmt) != POINTER_PLUS_EXPR)
+ && (!POINTER_TYPE_P (lookup_cand (c->basis)->cand_type)))
  || incr == 0)
continue;
 

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Aldy Hernandez]

On 10/19/2016 09:24 AM, Eric Botcazou wrote:

It seems to me that there is a precedence for -W type tests to start
with a capital letter, as opposed to a lowercase letter:

$ cd gcc.dg
$ ls W[a-z]* |wc
 280 2805816

Do you think it would perhaps be reasonable to rename all of them to
uppercase?


Yes, I agree that this would be more consistent.


You could take -Wvla-[1-7].c and I can take the subsequent ones?


Not sure if this wouldn't make us tread on each other's toe. ;-)  I'd just
rename your 3 new testcases (-Wvla-larger-than-1.c, Wvla-larger-than-2.c and
Walloca-11.c probably) and promote the existing wvla-[1-7].c to uppercase.



Done.

I have committed the attached patch as mostly obvious :).

commit e066ee667cec9a90478deff7b3090587ae11236f
Author: aldyh 
Date:   Wed Oct 19 13:52:43 2016 +

* gcc.dg/Wvla-1.c: Rename to...
* gcc.dg/Wvla-larger-than-1.c: ...this.
* gcc.dg/Wvla-2.c: Rename to...
* gcc.dg/Wvla-larger-than-2.c: ...this.
* gcc.dg/Wvla-3.c: Rename to...
* gcc.dg/Walloca-11.c.: ...this.
* gcc.dg/wvla-[1-7].c: Rename to:
* gcc.dg/Wvla-[1-7].c: ...this.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241344 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index a270700..d3d269d 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,14 @@
+2016-10-19  Aldy Hernandez  
+
+   * gcc.dg/Wvla-1.c: Rename to...
+   * gcc.dg/Wvla-larger-than-1.c: ...this.
+   * gcc.dg/Wvla-2.c: Rename to...
+   * gcc.dg/Wvla-larger-than-2.c: ...this.
+   * gcc.dg/Wvla-3.c: Rename to...
+   * gcc.dg/Walloca-11.c.: ...this.
+   * gcc.dg/wvla-[1-7].c: Rename to:
+   * gcc.dg/Wvla-[1-7].c: ...this.
+
 2016-10-19  Bin Cheng  
 
PR tree-optimization/78005
diff --git a/gcc/testsuite/gcc.dg/Walloca-11.c 
b/gcc/testsuite/gcc.dg/Walloca-11.c
new file mode 100644
index 000..5124476
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Walloca-11.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-Walloca -O2" } */
+
+// Make sure we don't warn on VLA with -Walloca.
+
+void f (void*);
+
+void h1 (unsigned n)
+{
+  int a [n];
+  f (a);
+}
diff --git a/gcc/testsuite/gcc.dg/Wvla-1.c b/gcc/testsuite/gcc.dg/Wvla-1.c
index 384c930..d2e3cb5 100644
--- a/gcc/testsuite/gcc.dg/Wvla-1.c
+++ b/gcc/testsuite/gcc.dg/Wvla-1.c
@@ -1,24 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-Wvla-larger-than=100 -O2" } */
+/* { dg-options "-std=c89 -Wvla" } */
 
-typedef __SIZE_TYPE__ size_t;
-
-extern void useit (char *);
-
-int num;
-
-void test_vlas (size_t num)
-{
-  char str2[num];  /* { dg-warning "unbounded use" } */
-  useit(str2);
-
-  num = 98;
-  for (int i=0; i < 1234; ++i) {
-char str[num]; // OK, VLA in a loop, but it is a
-   // known size *AND* the compiler takes
-   // care of cleaning up between
-   // iterations with
-   // __builtin_stack_restore.
-useit(str);
-  }
-}
+extern void 
+func (int i, int array[i]); /* { dg-warning "ISO C90 forbids variable length 
array 'array'" } */
diff --git a/gcc/testsuite/gcc.dg/Wvla-2.c b/gcc/testsuite/gcc.dg/Wvla-2.c
index 96814dc..92c67ed 100644
--- a/gcc/testsuite/gcc.dg/Wvla-2.c
+++ b/gcc/testsuite/gcc.dg/Wvla-2.c
@@ -1,70 +1,5 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target stdint_types } */
-/* { dg-options "-O2 -Wvla-larger-than=40" } */
+/* { dg-options "-std=c99 -Wvla" } */
 
-#include 
-
-void f0 (void *);
-void
-f1 (__SIZE_TYPE__ a)
-{
-  if (a <= 10)
-{
-  // 10 * 4 bytes = 40: OK!
-  uint32_t x[a];
-  f0 (x);
-}
-}
-
-void
-f2 (__SIZE_TYPE__ a)
-{
-  if (a <= 11)
-{
-  // 11 * 4 bytes = 44: Not OK.
-  uint32_t x[a]; // { dg-warning "array may be too large" }
-  // { dg-message "note:.*argument may be as large as 44" "note" { target 
*-*-* } 25 }
-  f0 (x);
-}
-}
-
-void
-f3 (__SIZE_TYPE__ a, __SIZE_TYPE__ b)
-{
-  if (a <= 5 && b <= 3)
-{
-  // 5 * 3 * 4 bytes = 60: Not OK.
-  uint32_t x[a][b]; // { dg-warning "array may be too large" }
-  f0 (x);
-}
-}
-
-void
-f4 (__SIZE_TYPE__ a, __SIZE_TYPE__ b)
-{
-  if (a <= 5 && b <= 2)
-{
-  // 5 * 2 * 4 bytes = 40 bytes: OK!
-  uint32_t x[a][b];
-  f0 (x);
-}
-}
-
-void
-f5 (__SIZE_TYPE__ len)
-{
-  // Test that a direct call to __builtin_alloca_with_align is not
-  // confused with a VLA.
-  void *p = __builtin_alloca_with_align (len, 8);
-  f0 (p);
-}
-
-void
-f6 (unsigned stuff)
-{
-  int n = 7000;
-  do {
-char a[n]; // { dg-warning "variable-length array is too large" }
-f0 (a);
-  } while (stuff--);
-}
+extern void 
+func (int i, int array[i]); /* { dg-warning "ISO C90 forbids variable length 
array 'array'" } */
diff --git a/gcc/testsuite/gcc.dg/Wvla-3.c b/gcc/testsuite/gcc.dg/Wvla-

[ping * 2] PR35503 - warn for restrict

[Prathamesh Kulkarni]

Hi,
The attached patch is a rebased version of the patch posted at:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00446.html

The C++ changes are approved by Jason, other parts still require approval.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK to commit ?

I was wondering if the warning should go in Wall or Wextra ?
The patch can give false positives because
it only checks whether parameters are qualified with restrict, not how
parameters are used inside the function. For instance it warned for example 10
mentioned in n1570 under section 6.7.3.1 - "Formal definition of restrict".
Currently I have kept the warning in Wall.

Thanks,
Prathamesh
2016-10-19  Prathamesh Kulkarni  

PR c/35503
* doc/invoke.texi: Document Wrestrict.
* pretty-print.c (pp_format): Add case for "Z" specifier.
(test_pp_format): Test "Z" specifier.

c-family/
* c-common.h (warn_for_restrict): Declare.
* c-warn.c: Include gcc-rich-location.h.
(warn_for_restrict): New function.
* c-format.c (gcc_tdiag_char_table): Add entry for "Z" specifier.
(gcc_cdiag_char_table): Likewise.
(gcc_cxxdiag_char_table): Likewise.
* c.opt (Wrestrict): New option.

c/
* c-parser.c (c_parser_postfix_expression_after_primary): Call
warn_for_restrict.

cp/
* parser.c (cp_parser_postfix_pexpression): Call warn_for_restrict.

testsuite/
* c-c++-common/pr35503-1.c: New test.
* c-c++-common/pr35503-2.c: Likewise.
* c-c++-common/pr35503-3.c: Likewise.
* gcc.dg/format/gcc_diag-1.c: Add tests for "Z" specifier. 

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index bfdbda0..4d8866d 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1492,6 +1492,7 @@ extern void warnings_for_convert_and_check (location_t, 
tree, tree, tree);
 extern void c_do_switch_warnings (splay_tree, location_t, tree, tree, bool,
  bool);
 extern void warn_for_omitted_condop (location_t, tree);
+extern void warn_for_restrict (unsigned, vec *);
 
 /* Places where an lvalue, or modifiable lvalue, may be required.
Used to select diagnostic messages in lvalue_error and
diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index bf39ee0..8a4bf6f 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -713,6 +713,7 @@ static const format_char_info gcc_tdiag_char_table[] =
   { "r",   1, STD_C89, { T89_C,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "","cR",   NULL },
   { "<>'R",0, STD_C89, NOARGUMENTS, "",  "",   NULL },
   { "m",   0, STD_C89, NOARGUMENTS, "q", "",   NULL },
+  { "Z",   1, STD_C89, { T89_I,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "","", 
&gcc_tdiag_char_table[0] },
   { NULL,  0, STD_C89, NOLENGTHS, NULL, NULL, NULL }
 };
 
@@ -736,6 +737,7 @@ static const format_char_info gcc_cdiag_char_table[] =
   { "r",   1, STD_C89, { T89_C,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "","cR",   NULL },
   { "<>'R",0, STD_C89, NOARGUMENTS, "",  "",   NULL },
   { "m",   0, STD_C89, NOARGUMENTS, "q", "",   NULL },
+  { "Z",   1, STD_C89, { T89_I,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "","", 
&gcc_tdiag_char_table[0] },
   { NULL,  0, STD_C89, NOLENGTHS, NULL, NULL, NULL }
 };
 
@@ -762,6 +764,7 @@ static const format_char_info gcc_cxxdiag_char_table[] =
   { "r",   1, STD_C89, { T89_C,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "","cR",   NULL },
   { "<>'R",0, STD_C89, NOARGUMENTS, "",  "",   NULL },
   { "m",   0, STD_C89, NOARGUMENTS, "q", "",   NULL },
+  { "Z",   1, STD_C89, { T89_I,   BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  
BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN,  BADLEN  }, "","", 
&gcc_tdiag_char_table[0] },
   { NULL,  0, STD_C89, NOLENGTHS, NULL, NULL, NULL }
 };
 
diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index 904f6d3..36dce74 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -28,7 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tm_p.h"
 #include "diagnostic.h"
 #include "intl.h"
-
+#include "gcc-rich-location.h"
 
 /* Print a warning if a constant expression had overflow in folding.
Invoke this function on every expression that the language
@@ -2154,3 +2154,58 @@ maybe_warn_bool_compare (location_t loc, enum tree_code 
code, tree op0,
"with boolean expression is always false", cst);
 }
 }
+
+/* Warn if an argument at position param_pos is passed to a
+   restrict-qualified param, and it aliases with another argument.  */
+
+void
+warn_for_restrict (unsigned param_pos, vec *args)
+{
+  tree arg =

Re: [patch, avr, pr71676 and pr71678] Issues with casesi expand

[Georg-Johann Lay]

On 17.10.2016 09:27, Pitchumani Sivanupandi wrote:

On Thursday 13 October 2016 08:42 PM, Georg-Johann Lay wrote:

On 13.10.2016 13:44, Pitchumani Sivanupandi wrote:

On Monday 26 September 2016 08:19 PM, Georg-Johann Lay wrote:

On 26.09.2016 15:19, Pitchumani Sivanupandi wrote:

Attached patch for PR71676 and PR71678.

PR71676 is for AVR target that generates wrong code when switch case index is
more than 16 bits.

Switch case index of larger than SImode are checked for out of range before
'casesi' expand. RTL expand of casesi gets index as SImode, but index is
compared in HImode and ignores upper 16bits.

Attached patch changes the expansion for casesi to make the index comparison
in SImode and code generation accordingly.

PR71678 is ICE because below pattern in 'casesi' is not recognized.
(set (reg:HI 47)
 (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0)
   (reg:HI 45)))

Fix of PR71676 avoids the above pattern as it changes the comparison
to SImode.


But this means that all comparisons are now performed in SImode which is a
great performance loss for most programs which will switch on 16-bit values.

IMO we need a less intrusive (w.r.t. performance) approach.


Yes.

I tried to split 'casesi' into several based on case values so that compare is
done
in less expensive modes (i.e. QI or HI). In few cases it is not possible
without
SImode subtract/ compare.

Pattern casesi will have index in SI mode. So, out of range checks will be
expensive
as most common uses (in AVR) of case values will be in QI/HI mode.

e.g.
  if case values in QI range
if upper three bytes index is set
  goto out_of_range

offset = index - lower_bound (QImode)
if offset > case_range   (QImode)
  goto out_of_range
goto jump_table + offset

  else if case values in HI range
if index[2,3] is set
  goto out_of_range

offset = index - lower_bound (HImode)
if offset > case_range   (HImode)
  goto out_of_range
goto jump_table + offset

This modification will not work for the negative index values. Because code to
check
upper bytes of index will be expensive than the SImode subtract/ compare.

So, I'm trying to update fix to have SImode subtract/ compare if the case
values include
negative integers. For, others will try to optimize as mentioned above. Is that
approach OK?


But the above code will be executed at run time and add even more overhead,
or am I missing something?  If you conclude statically at expand time from
the case ranges then we might hit a similar problem as with the original
subreg computation.


No. Lower bound and case range are const_int_operand, known at compile time.


Yes, but if the range if form 10 to 90, say, then you still don't know whether 
HImode and QImode is appropriate or not which adds to code size and register 
pressure.


As I mentioned earlier, I am working on a different approach which would revert 
your changes:  The casesi is basically unaltered (except for operand clean-ups 
and avoidance of clobbering subregs).


The ups of my approach are:

* The original value is known and whether is is QI or HI.

* The signedness is known which allows to use the maximum range of
  QI resp. HI depending on the sign.

* Also works on negative values.

* All is done at compile time, no need for extra code.

* No intermediate 32-bit values, no unnecessary increase of reg pressure.

* Optimization can be switched off by -fdisable if desired.

* Result can be seen in dumps.

The downsides are:

* Also needs some lines of code (~400).

* Makes assumptions on the anatomy of the code, i.e. extension
  precedes casesi.

First we should decide which route to follow as the changes are conflicting 
each other.  I have not so much time to work on the stuff but the results are 
promising.  If you are interested in the changes, I can supply it but it's all 
still work in progress.


Johann


Tried to optimize code generated based on case values range.
Attached the revised patch.

Tested with avrtest, no regression found.

Is it OK?


Unfortunately, the generated code (setting cc0, a reg and pc) cannot be
wrapped into an unspec or parallel and then later be rectified...

I am thinking about a new avr target pass to tidy up the code if no 32-bit
computation is needed, but this will be some effort.

Ok.


Regards,
Pitchumani

gcc/ChangeLog

2016-10-17  Pitchumani Sivanupandi 

PR target/71676
PR target/71678
* config/avr/avr.md (casesi_index_qi, casesi_index_hi, casesi_index_si):
Add new expands, called by casesi based on case values range.

gcc/testsuite/ChangeLog

2016-10-17  Pitchumani Sivanupandi 

PR target/71676
PR target/71678
* gcc.target/avr/pr71676-1.c: New test.
* gcc.target/avr/pr71676.c: New test.
* gcc.target/avr/pr71678.c: New test.

Re: [RFC][IPA-VRP] ADDR_EXPR and nonnull

[Jan Hubicka]

> > Would excluding weak symbols (I believe I can check DECL_WEAK for this) good
> > enough. Or looking for acceptable subset would work?
> 
> I think we should add a symtab helper to tell if address_nonzero_p (if
> that doesn't aleady exist).

We have node->nonzero_address()

Honza
> 
> Richard.
> 
> > Thanks,
> > Kugan
> > 
> > > 
> > > Richard.
> > > 
> > > > Attached patch bootstraps and regression testing didn't introduce any 
> > > > new
> > > > regressions.
> > > > 
> > > > Thanks,
> > > > Kugan
> > > > 
> > > > 
> > > > gcc/ChangeLog:
> > > > 
> > > > 2016-10-19  Kugan Vivekanandarajah  
> > > > 
> > > > * ipa-prop.c (ipa_compute_jump_functions_for_edge): Set
> > > > value range to nonull for ADDR_EXPR.
> > > > 
> > > > gcc/testsuite/ChangeLog:
> > > > 
> > > > 2016-10-19  Kugan Vivekanandarajah  
> > > > 
> > > > * gcc.dg/ipa/vrp5.c: New test.
> > > > * gcc.dg/ipa/vrp6.c: New test.
> > > > 
> > > 
> > 
> > 
> 
> -- 
> Richard Biener 
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nuernberg)

Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

[David Malcolm]

On Fri, 2016-10-07 at 15:58 +0200, Bernd Schmidt wrote:
> On 10/07/2016 03:26 PM, David Malcolm wrote:
> > 
> > We could simply print the INSN_UID for CODE_LABELs; something like
> > this
> > (see the "(code_label 16" below):
> 
> I think that should work.
> 
> > You appear to have trimmed the idea of enclosing the insns with
> > (basic-block) directives without commenting on it.  Did you like
> > this
> > idea?
> 
> Sorry - I appear to have completely missed it.
> 
> > It would make the above look like:
> > 
> >   (basic-block 2
> > ;; insns snipped
> > (jump_insn (set (pc)
> > (if_then_else (ge (reg:CCGC 17 flags)
> > (const_int 0 [0]))
> > (label_ref 16)
> > (pc))) "test.c":3
> >-> 16)
> >   ) ;; basic-block 2
> >   (basic-block 4
> > (note [bb 4] NOTE_INSN_BASIC_BLOCK)
> > ;; insns snipped
> > (jump_insn (set (pc) (label_ref 20)) "test.c":4
> >  -> 20)
> >   ) ;; basic-block 4
> >   (barrier)
> >   (basic-block 5
> > (code_label 16 [1 uses])
> > (note [bb 5] NOTE_INSN_BASIC_BLOCK)
> > ;; etc
> >   ) ;; basic-block 5
> > 
> > Note how the above format expresses clearly that:
> > * the (barrier) is part of the insn chain, but not in a basic
> > block, and
> > * some insns can happen in a basic block
> 
> That looks really nice IMO. Except maybe drop the "-> 16" bit for the
> jump_insn (that's the JUMP_LABEL, isn't it?)

In r241120 I dropped all dumping of the JUMP_LABEL when adding the
"compact" mode.

I'm now running into an issue with this as I update the __RTL in cc1
tests to use the new format, since various passes require the
JUMP_INSNs to have JUMP_LABEL data.

For reference the JUMP_LABEL is at idx 7 of JUMP_INSN, a code '0' field, it's 
dumped by a special-case in print-rtx.c:print_rtx_operand_code_0, around line 
186:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/print-rtl.c;hb=HEAD#l186

OK if I simply reinstate the existing dump form for that in compact mode, or 
would you prefer a different syntax?

Maybe even just lose the newline in compact mode, giving something like the 
following:

Example of a jump with JUMP_LABEL == a LABEL_REF.

  (cjump_insn (set (pc)
(if_then_else (ge (reg:CCGC flags)
(const_int 0))
(label_ref 16)
(pc)))  (nil) -> 16)


Example of a jump with JUMP_LABEL == the simple_return_rtx singleton.

  (cjump_insn (set (pc) (label_ref 3)) (nil) -> simple_return)

[...snip...]

Dave

Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

[Bernd Schmidt]

On 10/19/2016 04:35 PM, David Malcolm wrote:


In r241120 I dropped all dumping of the JUMP_LABEL when adding the
"compact" mode.

I'm now running into an issue with this as I update the __RTL in cc1
tests to use the new format, since various passes require the
JUMP_INSNs to have JUMP_LABEL data.


Isn't it possible to recreate these? In jump.c we have 
rebuild_jump_labels, which looks like it'll also compute LABEL_NUSES 
which I think we were considering dropping in the output.



Bernd

Re: [PATCH 09/16] Split class rtx_reader into base_rtx_reader vs rtx_reader

[Bernd Schmidt]

On 10/18/2016 10:30 PM, David Malcolm wrote:


I'm not in love with the names I chose in this patch.  It does seem odd
having an "rtx_reader" class that can't actually read hierarchical rtx.

How about "md_reader" as the base class (with responsibility for the
things in read-md.o), and "rtx_reader" for the subclass (adding the
things in read-rtl.o)?


I think a lot of renaming was for a variable (base_rtx_reader_ptr), not 
the class, wasn't it? I would very much like to avoid these, but I think 
for the class names it should be ok to go with what you suggest.



Bernd

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Jerry DeLisle]

On 10/19/2016 01:59 AM, Christophe Lyon wrote:

Hi,


On 18 October 2016 at 04:45, Steve Kargl
 wrote:

On Mon, Oct 17, 2016 at 06:02:52PM -0700, Jerry DeLisle wrote:

Hi all,

The attached patch enables the size= specifier in a READ statement to work with
child DTIO procedures. This is accomplished by moving the size_used variable
from the dtp structure to the gfc_unit structure so that the accumulation of
bytes during READ is carried across the procedures via the UNIT.


--- snip ---


Since this was committed (r241294), I'm seeing regressions on
arm and aarch64 targets.

The list is a bit long, so it's probably simpler you look at:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/241306/report-build-info.html
Then click on the red "REGRESSED" in the gfortran column.



--- snip ---

The patch changes nothing related to any particular target. If I were to hazard 
a guess I would think the tests are linking against a wrong version of the 
library, the follow on patch (not yet committed) is bumping the libgfortran 
major version number.


I do not have access to a target machine unless there is a way to remote in.  Is 
there one in the gcc compile farm?


Jerry

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Jerry DeLisle]

On 10/19/2016 04:04 AM, Andreas Schwab wrote:

At line 74 of file /opt/gcc/gcc-20161019/gcc/testsuite/gfortran.dg/dtio_17.f90 
(unit = 28, file = '/tmp/gfortrantmpQF10b7')
Fortran runtime error: Bad value during integer read

Error termination. Backtrace:
FAIL: gfortran.dg/dtio_17.f90   -O1  execution test

Andreas.



See my reply to Christophe post on arm aarch64.

Could you try compiling manually the failing test with gfortran -static and then 
run it to see what happens. Also what target is this failing on.


Jerry

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Andreas Schwab]

On Okt 19 2016, Jerry DeLisle  wrote:

> The patch changes nothing related to any particular target. If I were to
> hazard a guess I would think the tests are linking against a wrong version
> of the library, the follow on patch (not yet committed) is bumping the
> libgfortran major version number.

There is only one version of the library, the one just built.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

[Andreas Krebbel]

On 10/17/2016 09:29 PM, Andreas Krebbel1 wrote:
>> Here is a patch implementing what I think has been discussed in this 
> thread.
>>
>> OK?
> 
> Looks good to me.
> 
> Uli, do you agree with that change for S/390 or would you rather see us 
> fixing the float_t type definition in Glibc?

I had a discussion with Ulrich. He agrees with the current patch. So the patch 
is ok to apply.
Thanks for taking care of this (and being patient with me).

Also I will try to push forward changing float_t to float. Your patch does not 
make things worse and
should not make it harder to do the float_t switch in the future. For the 
float_t switch I will have
to check with the distro maintainers.

-Andreas-

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Andreas Schwab]

On Okt 19 2016, Jerry DeLisle  wrote:

> Could you try compiling manually the failing test with gfortran -static
> and then run it to see what happens.

That does not change anything.

> Also what target is this failing on.

aarch64 and m68k.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Eric Botcazou]

> I have committed the attached patch as mostly obvious :).

Thanks!

-- 
Eric Botcazou

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Aldy Hernandez]

On 10/19/2016 09:16 AM, Eric Botcazou wrote:

m68k-suse-linux


visium-elf too.



The attached patch fixes the failures on m68k-suse-linux, visium-elf, 
and arm-eabi.


There were a few problems.

One problem is that on lp64 targets (where sizeof(size_t) != 
sizeof(int)), the warning is slightly different-- and rightly so.  I 
have updated the test to handle both warnings on the respective targets.


The other problem is that the following snippet is incorrectly warning 
on 32-bit targets:


  if (n > 0 && n < 2000)
p = __builtin_alloca (n);

Looking at the gimple it seems like another case of VRP failing to give 
any range information whatsoever.  I have xfailed it as another case 
where Andrew's upcoming work should theoretically fix this.  The test is 
fine on 64-bit targets.


Can y'all double check it on your respective targets as I only have a 
crude cross build?


Thanks.
Aldy
commit 32b629dcab7b78e8181146338c4b077f1d55a0bf
Author: Aldy Hernandez 
Date:   Wed Oct 19 11:24:44 2016 -0400

* gcc.dg/Walloca-1.c: Adjust test for !lp64 targets.
* gcc.dg/Walloca-2.c: Same.

diff --git a/gcc/testsuite/gcc.dg/Walloca-1.c b/gcc/testsuite/gcc.dg/Walloca-1.c
index 34a20c3..32e4ab8 100644
--- a/gcc/testsuite/gcc.dg/Walloca-1.c
+++ b/gcc/testsuite/gcc.dg/Walloca-1.c
@@ -23,7 +23,8 @@ void foo1 (size_t len, size_t len2, size_t len3)
   char *s = alloca (123);
   useit (s);   // OK, constant argument to alloca
 
-  s = alloca (num);// { dg-warning "large due to conversion" }
+  s = alloca (num);// { dg-warning "large due to conversion" "" { 
target lp64 } }
+  // { dg-warning "unbounded use of 'alloca'" "" { target { ! lp64 } } 26 }
   useit (s);
 
   s = alloca(9);   /* { dg-warning "is too large" } */
diff --git a/gcc/testsuite/gcc.dg/Walloca-2.c b/gcc/testsuite/gcc.dg/Walloca-2.c
index 284b34e..4695fda 100644
--- a/gcc/testsuite/gcc.dg/Walloca-2.c
+++ b/gcc/testsuite/gcc.dg/Walloca-2.c
@@ -8,7 +8,11 @@ g1 (int n)
 {
   void *p;
   if (n > 0 && n < 2000)
-p = __builtin_alloca (n);
+// FIXME: This is a bogus warning, and is currently happening on
+// 32-bit targets because VRP is not giving us any range info for
+// the argument to __builtin_alloca.  This should be fixed by the
+// upcoming range work.
+p = __builtin_alloca (n); // { dg-bogus "unbounded use of 'alloca'" "" { 
xfail { ! lp64 } } }
   else
 p = __builtin_malloc (n);
   f (p);
@@ -31,8 +35,9 @@ g3 (int n)
   void *p;
   if (n > 0 && n < 3000)
 {
-  p = __builtin_alloca (n); // { dg-warning "'alloca' may be too large" }
-  // { dg-message "note:.*argument may be as large as 2999" "note" { 
target *-*-* } 34 }
+  p = __builtin_alloca (n); // { dg-warning "'alloca' may be too large" "" 
{ target lp64} }
+  // { dg-message "note:.*argument may be as large as 2999" "note" { 
target lp64 } 38 }
+  // { dg-warning "unbounded use of 'alloca'" "" { target { ! lp64 } } 38 }
 }
   else
 p = __builtin_malloc (n);

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Andreas Schwab]

On Okt 19 2016, Aldy Hernandez  wrote:

> commit 32b629dcab7b78e8181146338c4b077f1d55a0bf
> Author: Aldy Hernandez 
> Date:   Wed Oct 19 11:24:44 2016 -0400
>
>   * gcc.dg/Walloca-1.c: Adjust test for !lp64 targets.
>   * gcc.dg/Walloca-2.c: Same.

This fixes both tests on m68k.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Eric Botcazou]

> This fixes both tests on m68k.

Likewise on Visium.

-- 
Eric Botcazou

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Jeff Law]

On 10/19/2016 09:32 AM, Aldy Hernandez wrote:

On 10/19/2016 09:16 AM, Eric Botcazou wrote:

m68k-suse-linux


visium-elf too.



The attached patch fixes the failures on m68k-suse-linux, visium-elf,
and arm-eabi.

There were a few problems.

One problem is that on lp64 targets (where sizeof(size_t) !=
sizeof(int)), the warning is slightly different-- and rightly so.  I
have updated the test to handle both warnings on the respective targets.

The other problem is that the following snippet is incorrectly warning
on 32-bit targets:

  if (n > 0 && n < 2000)
p = __builtin_alloca (n);

Looking at the gimple it seems like another case of VRP failing to give
any range information whatsoever.  I have xfailed it as another case
where Andrew's upcoming work should theoretically fix this.  The test is
fine on 64-bit targets.

Can y'all double check it on your respective targets as I only have a
crude cross build?

OK for the trunk whenever you're ready.

jeff

Re: [PATCH] Reduce stack usage in sha512 (PR target/77308)

[Bernd Edlinger]

On 10/19/16 12:44, Christophe Lyon wrote:
> On 19 October 2016 at 10:34, Kyrill Tkachov  
> wrote:
>>
>> On 19/10/16 07:55, Christophe Lyon wrote:
>>>
>>> On 18 October 2016 at 17:35, Christophe Lyon 
>>> wrote:

 On 18 October 2016 at 16:45, Bernd Edlinger 
 wrote:
>
> On 10/18/16 10:36, Christophe Lyon wrote:
>>
>> I am seeing a lot of regressions since this patch was committed:
>>
>> http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/241273/report-build-info.html
>>
>> (you can click on "REGRESSED" to see the list of regressions, "sum"
>> and "log" to download
>> the corresponding .sum/.log)
>>
>> Thanks,
>>
>> Christophe
>>
> Oh, sorry, I have completely missed that.
> Unfortunately I have tested one of the good combinations.
>
> I have not considered the case that in and out could be
> the same register.  But that happens here.
>
>
> This should solve it.
>
> Can you give it a try?
>
 Sure, I have started the validations, it will take a few hours.

>>> It looks OK, thanks.
>>
>>
>> Ok. Thanks for testing Christophe.
>> Sorry for not catching it in review.
>> Kyrill
>>
>
> Since it was painful to check that this 2nd patch fixed all the regressions
> observed in all the configurations, I ran another validation with
> the 2 patches combined, on top of r241272 to check the effect of the two
> over the previous reference.
>
> It turns out there is still a failure:
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/241272-r241273-combined/report-build-info.html
> gcc.c-torture/execute/pr34971.c   -O0  execution test
> now fails on arm-none-linux-gnueabihf when using thumb mode, expect
> when targeting cortex-a5.
>

Thanks Christophe, I looked in the test case,
and I think that is a pre-existing issue.

I can make the test case fail before my patch:

struct foo
{
   unsigned long long b:40;
} x;

extern void abort (void);

void test1(unsigned long long res)
{
   /* Build a rotate expression on a 40 bit argument.  */
   if ((x.b<<9) + (x.b>>31) != res)
 abort ();
}

int main()
{
   x.b = 0x010001;
   test1(0x000202);
   x.b = 0x01;
   test1(0x02);
   return 0;
}


fails with -mcpu=cortex-a9 -mthumb -mfpu=neon-fp16 -O0
even before my patch.

before reload we have this insn:
(insn 19 18 20 2 (parallel [
 (set (reg:DI 113 [ _4 ])
 (lshiftrt:DI (reg:DI 112 [ _3 ])
 (const_int 31 [0x1f])))
 (clobber (scratch:SI))
 (clobber (scratch:SI))
 (clobber (scratch:DI))
 (clobber (reg:CC 100 cc))
 ]) "pr34971.c":11 1232 {lshrdi3_neon}


which is replaced to this insn:
(insn 19 18 20 2 (parallel [
 (set (reg:DI 1 r1 [orig:113 _4 ] [113])
 (lshiftrt:DI (reg:DI 0 r0 [orig:112 _3 ] [112])
 (const_int 31 [0x1f])))
 (clobber (scratch:SI))
 (clobber (scratch:SI))
 (clobber (scratch:DI))
 (clobber (reg:CC 100 cc))
 ]) "pr34971.c":11 1232 {lshrdi3_neon}
  (nil))

And now that is not supposed to happen, when this code
is executed for shifts by a constant less than 32:

   emit_insn (SET (out_down, LSHIFT (code, in_down, amount)));
   emit_insn (SET (out_down,
   ORR (REV_LSHIFT (code, in_up, reverse_amount),
out_down)));
   emit_insn (SET (out_up, SHIFT (code, in_up, amount)));


out_down may not be the same hard register than in_up for this to work.

I opened a new BZ for this:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041

I am not sure if this is a LRA issue or if it can be handled in the
shift expansion.

Is the second patch good for trunk as it is?


Thanks
Bernd.

Re: [PATCH] Extend -Wint-in-bool-context to suspicious enum values (PR 77700)

[Markus Trippelsdorf]

On 2016.10.07 at 15:18 +, Bernd Edlinger wrote:
> Hi!
>
> This extends -Wint-in-bool-context to uses of enum values in boolean
> context, and fixes one place where accidentally an enum value was
> passed to a bool parameter.
>
> I excluded enum values 0 and 1 because that is used in
> gimple-ssa-strength-reduction.c, where we have enums
> which are passed in bool function arguments:
>
> enum stride_status
> {
>UNKNOWN_STRIDE = 0,
>KNOWN_STRIDE = 1
> };
>
> enum phi_adjust_status
> {
>NOT_PHI_ADJUST = 0,
>PHI_ADJUST = 1
> };
>
> enum count_phis_status
> {
>DONT_COUNT_PHIS = 0,
>COUNT_PHIS = 1
> };
>
> I would'nt use an enum in that way, but I think it is
> at least not completely wrong to do it like that...
>
>
> Unfortunately C is less strict with enum values, and from
> and enum we only see an integer value without an enum type
> in C.
>
> Therefore this warning does not work in C, only in C++.
> Also integer constants do not have a source location, so
> the displayed location is usually a bit vague.
> But I think it is still better than no warning at all.
>
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?

I came across an borderline example in Chromium today:

 62 enum FlushBehavior {
 63   // More bytes are coming, don't flush the codec.
 64   DoNotFlush = 0,
 65
 66   // A fetch has hit EOF. Some codecs handle fetches differently, for compat
 67   // reasons.
 68   FetchEOF,
 69
 70   // Do a full flush of the codec.
 71   DataEOF
 72 };
 73
 74 static_assert(!DoNotFlush, "DoNotFlush should be falsy");
 75 static_assert(FetchEOF, "FetchEOF should be truthy");
 76 static_assert(DataEOF, "DataEOF should be truthy");

../../third_party/WebKit/Source/wtf/text/TextCodec.h:76:51: warning: enum 
constant in boolean context [-Wint-in-bool-context]
 static_assert(DataEOF, "DataEOF should be truthy");
   ^

--
Markus

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Christophe Lyon]

On 19 October 2016 at 17:55, Jeff Law  wrote:
> On 10/19/2016 09:32 AM, Aldy Hernandez wrote:
>>
>> On 10/19/2016 09:16 AM, Eric Botcazou wrote:

 m68k-suse-linux
>>>
>>>
>>> visium-elf too.
>>>
>>
>> The attached patch fixes the failures on m68k-suse-linux, visium-elf,
>> and arm-eabi.
>>
>> There were a few problems.
>>
>> One problem is that on lp64 targets (where sizeof(size_t) !=
>> sizeof(int)), the warning is slightly different-- and rightly so.  I
>> have updated the test to handle both warnings on the respective targets.
>>
>> The other problem is that the following snippet is incorrectly warning
>> on 32-bit targets:
>>
>>   if (n > 0 && n < 2000)
>> p = __builtin_alloca (n);
>>
>> Looking at the gimple it seems like another case of VRP failing to give
>> any range information whatsoever.  I have xfailed it as another case
>> where Andrew's upcoming work should theoretically fix this.  The test is
>> fine on 64-bit targets.
>>
>> Can y'all double check it on your respective targets as I only have a
>> crude cross build?
>
> OK for the trunk whenever you're ready.
>
> jeff

You are too fast for me :-)
I do not have the build trees for all the configurations ready for
manual testing...
So, I just merged the initial patch and the 2nd one, and started
a validation job to make sure the 2nd patch fixes all the regressions
observed earlier.
It will take a few hours.

Christophe

Re: [tree-optimization/71947] Avoid unwanted propagations

[Jeff Law]

On 10/12/2016 08:36 AM, Christophe Lyon wrote:


It fixes the tests from 71947 and 77647 without regressing (obviously). I've
included an xfailed test for a more complex situation that we don't
currently handle (would require backtracking from the equality comparison
through the logicals that feed the equality comparison).


FWIW, this test is XPASS on arm-none-linux-gnueabihf
--with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16:

Most likely branch-costing is the culprit.  Let me see what I can do...

jeff

Re: [tree-optimization/71947] Avoid unwanted propagations

[Jeff Law]

On 10/12/2016 09:00 AM, Georg-Johann Lay wrote:

On 10.10.2016 23:06, Jeff Law wrote:



So if we have an equality conditional between A & B, we record into our
const/copy tables A = B and B = A.

This helps us discover some of the more obscure equivalences. But it also
creates problems with an expression like

A ^ B

Where we might cprop the first operand generating

B ^ B

Then the second generating

B ^ A

ANd we've lost the folding opportunity.  At first I'd tried folding
after each
propagation step, but that turns into a bit of a nightmare because of
changes
in the underlying structure of the gimple statement and cycles that
may develop
if we re-build the operand cache after folding.

This approach is simpler and should catch all these cases for binary
operators.  We just track the last copy propagated argument and refuse to
ping-pong propagations.

It fixes the tests from 71947 and 77647 without regressing
(obviously). I've
included an xfailed test for a more complex situation that we don't
currently
handle (would require backtracking from the equality comparison
through the
logicals that feed the equality comparison).

Bootstrapped and regression tested on x86_64.  Applied to the trunk.

commit 6223e6e425b6de916f0330b9dbe5698765d4a73c
Author: law 
Date:   Mon Oct 10 20:40:59 2016 +

PR tree-optimization/71947
* tree-ssa-dom.c (cprop_into_stmt): Avoid replacing A with B,
then
B with A within a single statement.

PR tree-optimization/71947
* gcc.dg/tree-ssa/pr71947-1.c: New test.
* gcc.dg/tree-ssa/pr71947-2.c: New test.
* gcc.dg/tree-ssa/pr71947-3.c: New test.
* gcc.dg/tree-ssa/pr71947-4.c: New test.
* gcc.dg/tree-ssa/pr71947-5.c: New test.
* gcc.dg/tree-ssa/pr71947-6.c: New test.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@240947
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1738bc7..16e25bf 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2016-10-10  Jeff Law  
+
+PR tree-optimization/71947
+* tree-ssa-dom.c (cprop_into_stmt): Avoid replacing A with B, then
+B with A within a single statement.
+
 2016-10-10  Bill Schmidt  

 PR tree-optimization/77824
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 04966cf..e31bcc6 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,13 @@
+2016-10-10  Jeff Law  
+
+PR tree-optimization/71947
+* gcc.dg/tree-ssa/pr71947-1.c: New test.
+* gcc.dg/tree-ssa/pr71947-2.c: New test.
+* gcc.dg/tree-ssa/pr71947-3.c: New test.
+* gcc.dg/tree-ssa/pr71947-4.c: New test.
+* gcc.dg/tree-ssa/pr71947-5.c: New test.
+* gcc.dg/tree-ssa/pr71947-6.c: New test.
+
 2016-10-10  Thomas Koenig  

 PR fortran/77915
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
new file mode 100644
index 000..b033495
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+
+int f(int x, int y)
+{
+   int ret;
+
+   if (x == y)
+ ret = x ^ y;
+   else
+ ret = 1;
+
+   return ret;
+}
+
+/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2"
} } */
+
+
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
new file mode 100644
index 000..de8f88b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+
+int f(int x, int y)
+{
+  int ret;
+  if (x == y)
+ret = x - y;
+  else
+ret = 1;
+
+  return ret;
+}
+
+/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2"
} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
new file mode 100644
index 000..e79847f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+int f(int x, int y)
+{
+  int ret = 10;
+  if (x == y)
+ret = x  -  y;
+  return ret;
+}
+
+/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2"
} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-4.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-4.c
new file mode 100644
index 000..a881f0d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-4.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+
+
+static inline long load(long *p)
+{
+long ret;
+asm ("movq  %1,%0\n\t" : "=r" (ret) : "m" (*p));



Hi, shouldn't this test be restricted to target machines that understand
MOVQ?

Same issue for gcc.dg/tree-ssa/pr71947-5.c below.
It shouldn't actually matter -- we compile to assembly, but never try to 
assemble th

Re: [PATCH] Reduce stack usage in sha512 (PR target/77308)

[Kyrill Tkachov]

On 19/10/16 17:06, Bernd Edlinger wrote:

On 10/19/16 12:44, Christophe Lyon wrote:

On 19 October 2016 at 10:34, Kyrill Tkachov  wrote:

On 19/10/16 07:55, Christophe Lyon wrote:

On 18 October 2016 at 17:35, Christophe Lyon 
wrote:

On 18 October 2016 at 16:45, Bernd Edlinger 
wrote:

On 10/18/16 10:36, Christophe Lyon wrote:

I am seeing a lot of regressions since this patch was committed:

http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/241273/report-build-info.html

(you can click on "REGRESSED" to see the list of regressions, "sum"
and "log" to download
the corresponding .sum/.log)

Thanks,

Christophe


Oh, sorry, I have completely missed that.
Unfortunately I have tested one of the good combinations.

I have not considered the case that in and out could be
the same register.  But that happens here.


This should solve it.

Can you give it a try?


Sure, I have started the validations, it will take a few hours.


It looks OK, thanks.


Ok. Thanks for testing Christophe.
Sorry for not catching it in review.
Kyrill


Since it was painful to check that this 2nd patch fixed all the regressions
observed in all the configurations, I ran another validation with
the 2 patches combined, on top of r241272 to check the effect of the two
over the previous reference.

It turns out there is still a failure:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/241272-r241273-combined/report-build-info.html
gcc.c-torture/execute/pr34971.c   -O0  execution test
now fails on arm-none-linux-gnueabihf when using thumb mode, expect
when targeting cortex-a5.


Thanks Christophe, I looked in the test case,
and I think that is a pre-existing issue.

I can make the test case fail before my patch:

struct foo
{
unsigned long long b:40;
} x;

extern void abort (void);

void test1(unsigned long long res)
{
/* Build a rotate expression on a 40 bit argument.  */
if ((x.b<<9) + (x.b>>31) != res)
  abort ();
}

int main()
{
x.b = 0x010001;
test1(0x000202);
x.b = 0x01;
test1(0x02);
return 0;
}


fails with -mcpu=cortex-a9 -mthumb -mfpu=neon-fp16 -O0
even before my patch.

before reload we have this insn:
(insn 19 18 20 2 (parallel [
  (set (reg:DI 113 [ _4 ])
  (lshiftrt:DI (reg:DI 112 [ _3 ])
  (const_int 31 [0x1f])))
  (clobber (scratch:SI))
  (clobber (scratch:SI))
  (clobber (scratch:DI))
  (clobber (reg:CC 100 cc))
  ]) "pr34971.c":11 1232 {lshrdi3_neon}


which is replaced to this insn:
(insn 19 18 20 2 (parallel [
  (set (reg:DI 1 r1 [orig:113 _4 ] [113])
  (lshiftrt:DI (reg:DI 0 r0 [orig:112 _3 ] [112])
  (const_int 31 [0x1f])))
  (clobber (scratch:SI))
  (clobber (scratch:SI))
  (clobber (scratch:DI))
  (clobber (reg:CC 100 cc))
  ]) "pr34971.c":11 1232 {lshrdi3_neon}
   (nil))

And now that is not supposed to happen, when this code
is executed for shifts by a constant less than 32:

emit_insn (SET (out_down, LSHIFT (code, in_down, amount)));
emit_insn (SET (out_down,
ORR (REV_LSHIFT (code, in_up, reverse_amount),
 out_down)));
emit_insn (SET (out_up, SHIFT (code, in_up, amount)));


out_down may not be the same hard register than in_up for this to work.

I opened a new BZ for this:
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041

I am not sure if this is a LRA issue or if it can be handled in the
shift expansion.

Is the second patch good for trunk as it is?


Thanks for the investigation and the bug report.
The patch is ok.
Kyrill



Thanks
Bernd.

Re: [gofrontend-dev] Re: libgo patch committed: copy rdebug code from Go 1.7

[Ian Lance Taylor]

On Wed, Oct 19, 2016 at 6:23 AM, Richard Biener
 wrote:
> On Wed, Oct 19, 2016 at 3:17 PM, Ian Lance Taylor  wrote:
>> On Wed, Oct 19, 2016 at 4:30 AM, Richard Biener
>>  wrote:
>>> On Mon, Oct 17, 2016 at 6:54 PM, Ian Lance Taylor  wrote:
 This patch to libgo copies the rdebug code from the Go 1.7 runtime to 
 libgo.

 While we're at it, this updates the runtime/debug package, and starts
 running its testsuite by default.  I'm not sure why runtime/debug was
 not previously updated to 1.7.  Doing that led me to fix some minor
 aspects of runtime.Stack and the C function runtime/debug.readGCStats.

 Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
 to mainline.
>>>
>>> Not sure which of the merges broke it but I get
>>>
>>> ...
>>> rc/svn/trunk2/libgo/go/runtime/time.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/trace.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/traceback_gccgo.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/type.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/typekind.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/write_err.go
>>> runtime_sysinfo.go  -fPIC -o .libs/runtime-go.o
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/netpoll_epoll.go:52:49:
>>> error:integer constant overflow
>>>   ev.events = _EPOLLIN | _EPOLLOUT | _EPOLLRDHUP | _EPOLLET
>>>  ^
>>> make[4]: *** [runtime-go.lo] Error 1
>>>
>>> now and bootstrap is broken for me.  This is on x86_64-linux, SLES 11
>>> SP4 which uses glibc 2.11.3.
>>
>> Is this the 32-bit or 64-bit build?
>
> Hum, don't remember ...
>
>> What is the output of
>>
>> find x86_64-pc-linux-gnu -name runtime_sysinfo.go | xargs grep EPOLLET
>>
>> in your build directory?
>
> x86_64-pc-linux-gnu/32/libgo/runtime_sysinfo.go:const _EPOLLET = -2147483648
> x86_64-pc-linux-gnu/libgo/runtime_sysinfo.go:const _EPOLLET = -2147483648
>
> looks like the culprit.  All other _EPOLL* constants are positive

I have not been able to recreate the problem.  Perhaps the definition
of EPOLLET in your  file is different; on my system the
definition is

EPOLLET = 1u << 31

In any case, I have committed this patch which I believe will fix the
problem.  Bootstrapped and tested on x86_64-pc-linux-gnu on a system
that does not show the problem anyhow.

Ian

Re: libgo patch committed: copy rdebug code from Go 1.7

[Ian Lance Taylor]

On Wed, Oct 19, 2016 at 4:30 AM, Richard Biener
 wrote:
> On Mon, Oct 17, 2016 at 6:54 PM, Ian Lance Taylor  wrote:
>> This patch to libgo copies the rdebug code from the Go 1.7 runtime to libgo.
>>
>> While we're at it, this updates the runtime/debug package, and starts
>> running its testsuite by default.  I'm not sure why runtime/debug was
>> not previously updated to 1.7.  Doing that led me to fix some minor
>> aspects of runtime.Stack and the C function runtime/debug.readGCStats.
>>
>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
>> to mainline.
>
> Not sure which of the merges broke it but I get
>
> ...
> rc/svn/trunk2/libgo/go/runtime/time.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/trace.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/traceback_gccgo.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/type.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/typekind.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/write_err.go
> runtime_sysinfo.go  -fPIC -o .libs/runtime-go.o
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/netpoll_epoll.go:52:49:
> error:integer constant overflow
>   ev.events = _EPOLLIN | _EPOLLOUT | _EPOLLRDHUP | _EPOLLET
>  ^
> make[4]: *** [runtime-go.lo] Error 1
>
> now and bootstrap is broken for me.  This is on x86_64-linux, SLES 11
> SP4 which uses glibc 2.11.3.
>
> There is a missing space after 'error:' as well.

I don't see that missing space after "error:" either.  The code in
question winds up calling the GCC function error_at with "integer
constant overflow".  The Go frontend does not print the string
"error:" at all.

Ian

Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

[David Malcolm]

On Wed, 2016-10-19 at 16:41 +0200, Bernd Schmidt wrote:
> On 10/19/2016 04:35 PM, David Malcolm wrote:
> 
> > In r241120 I dropped all dumping of the JUMP_LABEL when adding the
> > "compact" mode.
> > 
> > I'm now running into an issue with this as I update the __RTL in
> > cc1
> > tests to use the new format, since various passes require the
> > JUMP_INSNs to have JUMP_LABEL data.
> 
> Isn't it possible to recreate these? In jump.c we have 
> rebuild_jump_labels, which looks like it'll also compute LABEL_NUSES 
> which I think we were considering dropping in the output.

I already dropped LABEL_NUSES in compact mode in r241120; I think it's
possible to regenerate that information.

But how would we go about recreating the JUMP_LABEL data?  As far as I
can tell, it can be set up by reorg.c:make_return_insns
via comparison against function_return_label and
function_simple_return_label, which are set up by find_end_label; the
functions in question are non-trivial, and can lead to extra insns
being emitted.  Also, in shrink-wrap.c:handle_simple_exit, which has
similar state considerations.

It seems simpler to serialize this information.

Or am I missing something?

Thanks
Dave

Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

[Bernd Schmidt]

On 10/19/2016 07:19 PM, David Malcolm wrote:

I already dropped LABEL_NUSES in compact mode in r241120; I think it's
possible to regenerate that information.

But how would we go about recreating the JUMP_LABEL data?  As far as I
can tell, it can be set up by reorg.c:make_return_insns
via comparison against function_return_label and
function_simple_return_label, which are set up by find_end_label; the
functions in question are non-trivial, and can lead to extra insns
being emitted.  Also, in shrink-wrap.c:handle_simple_exit, which has
similar state considerations.


I'd expect every return/simple_return insn to contain the corresponding 
rtx code. mark_jump_label_1 has this, which supports the theory:


case RETURN:
case SIMPLE_RETURN:
  if (is_target)
{
  gcc_assert (JUMP_LABEL (insn) == NULL || JUMP_LABEL (insn) == x);
  JUMP_LABEL (insn) = x;
}
  return;

This is called via mark_all_labels from rebuild_jump_labels_1, so it 
should Just Work - in theory.



It seems simpler to serialize this information.


Simpler, probably, but it would be nice to omit it if it really is 
redundant.



Bernd

Re: [Fortran, Patch, PR{43366, 57117, 61337, 61376}, v1] Assign to polymorphic objects.

[Andre Vehreschild]

Hi all,

attached is an enhanced version of the patch, which now catches all of the
testcases in the comments of pr61337. Thanks for reporting that I missed them,
Dominique.

For a detailed description see below. PR61337 needed just some more pre-code
joining and correct handling of class-typed array constructors.

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

Regards,
Andre

On Thu, 13 Oct 2016 14:42:00 +0200
Andre Vehreschild  wrote:

> Hi all,
> 
> attached patch fixes the PRs (as to my knowledge):
> 
> PR43366 - [OOP][F08] Intrinsic assign to polymorphic variable
> PR57117 - [OOP] ICE for sourced allocation of a polymorphic entity using
> TRANSPOSE
> PR61337 - Wrong indexing and runtime crash with unlimited polymorphic array.
> PR61378 - Error using private statement in polymorphic derived type
> 
> The latter two are more or less fixed by accident or have been fixed by
> previous patches, but have not been identified as such. Anyway, they are fixed
> now and will be closed once the patch hits trunk.
> 
> As for PR43366: I did not indent to fix this one, but when going for PR57117 I
> once again stumbled over the deficiencies of gfc_trans_assigment's handling of
> class objects. Therefore I figured what would be needed to complete PR43366
> and this is it now. 
> 
> As for PR57117: The issue was that ALLOCATE () used gfc_copy_class_to_class ()
> when a class object was allocated. The function gfc_copy_class_to_class ()
> does not use the scalarizer correctly. I.e., a transpose of the source=
> expression would not be respected. I therefore decided to remove all this
> special casing for class objects in ALLOCATE () and let gfc_trans_assignment
> do the trick. This way ensuring, that any improvements of the scalarizer will
> benefit class objects, too. Unfortunately did this mean to add more logic to
> gfc_trans_assignment. While doing so, I learned that existing wrappers for
> class assignments were obsoleted by the work I did, so I removed them.
> 
> I tried to get rid of the malicious copy_class_to_class, too, but at the
> moment it is still used at one location where components of derived types are
> assigned. I was not bold enough to replace this occurrence with
> trans_assignment yet.
> 
> This patch shall make our lives easier, because now there is one routine to
> assign all sorts of objects and no special casing for class objects is needed
> anymore. I expect that some other parts of gfortran's code base may benefit
> from the changes and have their complexity reduced.
> 
> Bootstrapped and regtested ok on x86_64-linux/F23. Ok for trunk?
> 
> Regards,
>   Andre


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 


pr43366_v2.clog
Description: Binary data
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index 85589ee..3803b88 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2359,6 +2359,10 @@ gfc_expr_attr (gfc_expr *e)
 	  attr.allocatable = CLASS_DATA (sym)->attr.allocatable;
 	}
 	}
+  else if (e->value.function.isym
+	   && e->value.function.isym->transformational
+	   && e->ts.type == BT_CLASS)
+	attr = CLASS_DATA (e)->attr;
   else
 	attr = gfc_variable_attr (e, NULL);
 
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 87178a4..3bb057d 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9834,10 +9834,6 @@ resolve_ordinary_assign (gfc_code *code, gfc_namespace *ns)
 		 "requires %<-frealloc-lhs%>", &lhs->where);
 	  return false;
 	}
-  /* See PR 43366.  */
-  gfc_error ("Assignment to an allocatable polymorphic variable at %L "
-		 "is not yet supported", &lhs->where);
-  return false;
 }
   else if (lhs->ts.type == BT_CLASS)
 {
@@ -10740,6 +10736,19 @@ start:
 	  break;
 
 	gfc_check_pointer_assign (code->expr1, code->expr2);
+
+	/* Assigning a class object always is a regular assign.  */
+	if (code->expr2->ts.type == BT_CLASS
+		&& !CLASS_DATA (code->expr2)->attr.dimension
+		&& !(UNLIMITED_POLY (code->expr2)
+		 && code->expr1->ts.type == BT_DERIVED
+		 && (code->expr1->ts.u.derived->attr.sequence
+			 || code->expr1->ts.u.derived->attr.is_bind_c))
+		&& !(gfc_expr_attr (code->expr1).proc_pointer
+		 && code->expr2->expr_type == EXPR_VARIABLE
+		 && code->expr2->symtree->n.sym->attr.flavor
+			== FL_PROCEDURE))
+	  code->op = EXEC_ASSIGN;
 	break;
 	  }
 
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 37cca79..c59e872 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -2292,7 +2292,8 @@ trans_array_constructor (gfc_ss * ss, locus * where)
 	type = build_pointer_type (type);
 }
   else
-type = gfc_typenode_for_spec (&expr->ts);
+type = gfc_typenode_for_spec (expr->ts.type == BT_CLASS
+  ? &CLASS_DATA (expr)->ts : &expr->ts);
 
   /* See if the constructor determines the loop bounds.  */
   dynamic = false;
@@ -3036,50 +3037,57 @@ build_class

Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

[David Malcolm]

On Wed, 2016-10-19 at 19:22 +0200, Bernd Schmidt wrote:
> On 10/19/2016 07:19 PM, David Malcolm wrote:
> > I already dropped LABEL_NUSES in compact mode in r241120; I think
> > it's
> > possible to regenerate that information.
> > 
> > But how would we go about recreating the JUMP_LABEL data?  As far
> > as I
> > can tell, it can be set up by reorg.c:make_return_insns
> > via comparison against function_return_label and
> > function_simple_return_label, which are set up by find_end_label;
> > the
> > functions in question are non-trivial, and can lead to extra insns
> > being emitted.  Also, in shrink-wrap.c:handle_simple_exit, which
> > has
> > similar state considerations.
> 
> I'd expect every return/simple_return insn to contain the
> corresponding 
> rtx code. mark_jump_label_1 has this, which supports the theory:
> 
>  case RETURN:
>  case SIMPLE_RETURN:
>if (is_target)
>  {
>gcc_assert (JUMP_LABEL (insn) == NULL || JUMP_LABEL (insn)
> == x);
>JUMP_LABEL (insn) = x;
>  }
>return;
> 
> This is called via mark_all_labels from rebuild_jump_labels_1, so it 
> should Just Work - in theory.
> 
> > It seems simpler to serialize this information.
> 
> Simpler, probably, but it would be nice to omit it if it really is 
> redundant.

Thanks, that gave me the pointer I needed.  I think it is indeed
redundant and I'll work on regenerating it in class function_reader.

Re: [Patch, fortran] PR69566 - Failure of SELECT TYPE with unlimited polymorphic function result

[Andre Vehreschild]

Hi Paul,

I am not completely through with your patch, but what jumped into my eye was
that you copy ref in resolve_select_type and again in fixup_array_ref, when you
use it? May be I oversee something. You are more into this code. Is the double
copying necessary (line 49 and 82 as well as 95, respectively). IMHO the copy
in line 49 could be sufficient.

I look into it tomorrow more thoroughly. Please wait before submitting a new
version. May be I see something more :-)

So far, thanks for working on this.

Regards,
Andre

On Wed, 19 Oct 2016 09:28:39 +0200
Paul Richard Thomas  wrote:

> Dear Andre,
> 
> Following our exchange yesterday, I have eliminated the modification
> to trans_associate_var and have corrected the offending expressions in
> resolve.c(fixup_array_ref).
> 
> Please find attached the corrected patch.
> 
> Cheers
> 
> Paul
> 
> 2016-10-19  Paul Thomas  
> 
> PR fortran/69566
> * resolve.c (fixup_array_ref): New function.
> (resolve_select_type): Gather up the rank and array reference,
> if any, from the selector. Fix up the 'associate name' and the
> 'associate entities' as necessary.
> * trans-expr.c (gfc_conv_class_to_class): If the symbol backend
> decl is a FUNCTION_DECL, use the 'fake_result_decl' instead.
> 
> 2016-10-19  Paul Thomas  
> 
> PR fortran/69566
> * gfortran.dg/select_type_37.f03: New test.
> 
> On 18 October 2016 at 18:16, Andre Vehreschild  wrote:
> > Hi Paul,
> >  
> >> For reasons I don't understand, sometimes the expression type comes
> >> through as BT_DERIVED, whilst the symbol is BT_CLASS. I could repair
> >> this in resolve.c(fixup_array_ref) if you think that would be cleaner.  
> >
> > I think that I figured the rule:
> >
> > - when no _class-ref is present, then the type is BT_CLASS,
> > - as soon as a _class-ref is present the type is BT_DERIVED.
> >
> > There is an attr.is_class. Would that be an alternative? I don't know how
> > reliable it is set.
> >  
> >> > I am regression testing my polymorhpic class patch at the moment,
> >> > therefore I can't test.  
> >>
> >> OK - I can wait. I have quite a few other things to do :-(  
> >
> > I found an error in my patch that only manifests itself with an optimization
> > level great than 0. Now I am searching, never having done anything there.
> >
> > - Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de  
> 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

[PATCH] Fix incorrect comment about std::auto_ptr

[Jonathan Wakely]

Pedro pointed out this comment isn't true, see LWG 463 for the reason
why (in short, it needs too many user-defined conversions).

* include/backward/auto_ptr.h (dauto_ptr): Correct comment about
conversions from auto_ptr rvalues to auto_ptr.
* testsuite/20_util/auto_ptr/assign_neg.cc: Remove redundant dg-error
directives that only match notes, not errors.

Tested powerpc64le-linux, committed to trunk.

commit 39d4ba1f2d08632e0f860fa28b3acfe844cd219d
Author: Jonathan Wakely 
Date:   Wed Oct 19 18:48:01 2016 +0100

Fix incorrect comment about std::auto_ptr

* include/backward/auto_ptr.h (dauto_ptr): Correct comment about
conversions from auto_ptr rvalues to auto_ptr.
* testsuite/20_util/auto_ptr/assign_neg.cc: Remove redundant dg-error
directives that only match notes, not errors.

diff --git a/libstdc++-v3/include/backward/auto_ptr.h 
b/libstdc++-v3/include/backward/auto_ptr.h
index bfd42d8..4dfc8cc 100644
--- a/libstdc++-v3/include/backward/auto_ptr.h
+++ b/libstdc++-v3/include/backward/auto_ptr.h
@@ -249,13 +249,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   /** 
*  @brief  Automatic conversions
*
-   *  These operations convert an %auto_ptr into and from an auto_ptr_ref
-   *  automatically as needed.  This allows constructs such as
+   *  These operations are supposed to convert an %auto_ptr into and from
+   *  an auto_ptr_ref automatically as needed.  This would allow
+   *  constructs such as
*  @code
*auto_ptr  func_returning_auto_ptr(.);
*...
*auto_ptr ptr = func_returning_auto_ptr(.);
*  @endcode
+   *
+   *  But it doesn't work, and won't be fixed. For further details see
+   *  http://cplusplus.github.io/LWG/lwg-closed.html#463
*/
   auto_ptr(auto_ptr_ref __ref) throw()
   : _M_ptr(__ref._M_ptr) { }
diff --git a/libstdc++-v3/testsuite/20_util/auto_ptr/assign_neg.cc 
b/libstdc++-v3/testsuite/20_util/auto_ptr/assign_neg.cc
index 5e52ec4..22cc49e 100644
--- a/libstdc++-v3/testsuite/20_util/auto_ptr/assign_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/auto_ptr/assign_neg.cc
@@ -47,6 +47,3 @@ main()
   test01();
   return 0;
 }
-// { dg-error "::auto_ptr|no known conversion" "" { target *-*-* } 136 } 
-// { dg-error "note" "" { target *-*-* } 154 }
-// { dg-error "::auto_ptr|no known conversion" "" { target *-*-* } 264 } 

Re: [PATCH] Implement P0084R2, Emplace return type, for C++17

[Jonathan Wakely]

On 17/10/16 12:56 +0100, Jonathan Wakely wrote:

In C++17 the emplace_front and emplace_back members return a
reference. There isn't a very neat way to implement this, so it's just
lots of conditional compilation.


This fixes a silly typo. Committed to trunk.



commit 688f5967dd566c56c01c710f2c1b49c56eabe123
Author: Jonathan Wakely 
Date:   Wed Oct 19 19:25:43 2016 +0100

Fix copy&paste error in __gnu_debug::vector

	* include/debug/vector (__gnu_debug::vector::emplace_back): Fix return
	type.

diff --git a/libstdc++-v3/include/debug/vector b/libstdc++-v3/include/debug/vector
index b2d70bd..1b9e4a7 100644
--- a/libstdc++-v3/include/debug/vector
+++ b/libstdc++-v3/include/debug/vector
@@ -479,7 +479,7 @@ namespace __debug
 
   template
 #if __cplusplus > 201402L
-	deque<_Tp, _Alloc>::reference
+	reference
 #else
 	void
 #endif

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Aldy Hernandez]

OK for the trunk whenever you're ready.

jeff


You are too fast for me :-)
I do not have the build trees for all the configurations ready for
manual testing...
So, I just merged the initial patch and the 2nd one, and started
a validation job to make sure the 2nd patch fixes all the regressions
observed earlier.
It will take a few hours.


There shouldn't be any problems that didn't surface in my cross build, 
since they are not execution tests, but compile tests.


I have committed the patch.  If there any specific failures specific to 
your target, let me know and I'll address those separately.


Thanks.
Aldy

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Jerry DeLisle]

On 10/19/2016 08:20 AM, Andreas Schwab wrote:

On Okt 19 2016, Jerry DeLisle  wrote:


Could you try compiling manually the failing test with gfortran -static
and then run it to see what happens.


That does not change anything.


Also what target is this failing on.


aarch64 and m68k.

Andreas.



Dominique has discovered my flaw, the integers are being used not initialized 
and can happen to be large negative values that need 11 bytes in the format to 
hold the values.


I will commit a change to the test case shortly.

Jerry

[v3 PATCH] Do the operator= SFINAE in the return type for optional, not in the template parameters.

[Ville Voutilainen]

Tested on Linux-x64.

2016-10-19  Ville Voutilainen  

Do the operator= SFINAE in the return type for optional,
not in the template parameters.
* include/std/optional (operator=(_Up&&)): Move SFINAE
from template parameters to the return type.
(operator=(const optional<_Up>&)): Likewise.
(operator=(optional<_Up>&&)): Likewise.
diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index 21210ab..f272876 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -568,15 +568,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 return *this;
   }
 
-  template, decay_t<_Up>>>,
-is_constructible<_Tp, _Up>,
-__not_<__and_,
-  is_same<_Tp, decay_t<_Up,
-is_assignable<_Tp&, _Up>>::value,
-  bool> = true>
-optional&
+  template
+enable_if_t<__and_<
+ __not_, decay_t<_Up>>>,
+ is_constructible<_Tp, _Up>,
+ __not_<__and_,
+   is_same<_Tp, decay_t<_Up,
+ is_assignable<_Tp&, _Up>>::value,
+   optional&>
 operator=(_Up&& __u)
 {
   if (this->_M_is_engaged())
@@ -587,16 +586,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return *this;
 }
 
-  template>,
-is_constructible<_Tp, const _Up&>,
-is_assignable<_Tp&, _Up>,
-__not_<__converts_from_optional<_Tp, _Up>>,
-__not_<__assigns_from_optional<_Tp, _Up>>
->::value,
-  bool> = true>
-optional&
+  template
+   enable_if_t<__and_<
+ __not_>,
+ is_constructible<_Tp, const _Up&>,
+ is_assignable<_Tp&, _Up>,
+ __not_<__converts_from_optional<_Tp, _Up>>,
+ __not_<__assigns_from_optional<_Tp, _Up>>
+ >::value,
+   optional&>
 operator=(const optional<_Up>& __u)
 {
   if (__u)
@@ -613,16 +611,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return *this;
 }
 
-  template>,
-is_constructible<_Tp, _Up>,
-is_assignable<_Tp&, _Up>,
-__not_<__converts_from_optional<_Tp, _Up>>,
-__not_<__assigns_from_optional<_Tp, _Up>>
->::value,
-  bool> = true>
-optional&
+  template
+   enable_if_t<__and_<
+ __not_>,
+ is_constructible<_Tp, _Up>,
+ is_assignable<_Tp&, _Up>,
+ __not_<__converts_from_optional<_Tp, _Up>>,
+ __not_<__assigns_from_optional<_Tp, _Up>>
+ >::value,
+   optional&>
 operator=(optional<_Up>&& __u)
 {
   if (__u)

Re: RFC [1/3] divmod transform v2

[Jeff Law]

On 10/15/2016 11:59 PM, Prathamesh Kulkarni wrote:

Hi,
After approval from Bernd Schmidt, I committed the patch to remove
optab functions for
sdivmod_optab and udivmod_optab in optabs.def, which removes the block
for divmod patch.

This patch is mostly the same as previous one, except it drops
targeting __udivmoddi4() because
it gave undefined reference link error for calling __udivmoddi4() on
aarch64-linux-gnu.
It appears aarch64 has hardware insn for DImode div, so __udivmoddi4()
isn't needed for the target
(it was a bug in my patch that called __udivmoddi4() even though
aarch64 supported hardware div).

However this makes me wonder if it's guaranteed that __udivmoddi4()
will be available for a target if it doesn't have hardware div and
divmod insn and doesn't have target-specific libfunc for
DImode divmod ? To be conservative, the attached patch doesn't
generate call to __udivmoddi4.

Passes bootstrap+test on x86_64-unknown-linux.
Cross-tested on arm*-*-*, aarch64*-*-*.
Verified that there are no regressions with SPEC2006 on
x86_64-unknown-linux-gnu.
OK to commit ?

Thanks,
Prathamesh


divmod-v2-3-main.txt


2016-10-15  Prathamesh Kulkarni  
Kugan Vivekanandarajah  
Jim Wilson  

* target.def: New hook expand_divmod_libfunc.
* doc/tm.texi.in: Add hook for TARGET_EXPAND_DIVMOD_LIBFUNC
* doc/tm.texi: Regenerate.
* internal-fn.def: Add new entry for DIVMOD ifn.
* internal-fn.c (expand_DIVMOD): New.
* tree-ssa-math-opts.c: Include optabs-libfuncs.h, tree-eh.h,
targhooks.h.
(widen_mul_stats): Add new field divmod_calls_inserted.
(target_supports_divmod_p): New.
(divmod_candidate_p): Likewise.
(convert_to_divmod): Likewise.
(pass_optimize_widening_mul::execute): Call
calculate_dominance_info(), renumber_gimple_stmt_uids() at
beginning of function. Call convert_to_divmod()
and record stats for divmod.
Starting with some high level design comments.  If these conflict with 
comments from others, let me know and we'll work through the issues.


I don't really like introducing code conditional on the target 
capabilities this early in the gimple optimization pipeline.


Would it be possible to always do the transformation to divmod in the 
gimple optimizers, regardless of the target capabilities.  Then in the 
gimple->RTL expanders make a final decision about divmod insn, libcall, 
or using div/mod insns?


That would move all the target dependencies out of the gimple optimizers 
and into the gimple->rtl expansion phase, which is the preferred place 
to start introducing this kind of target dependency.


With that background, I'm going to focus more on the identification of 
divmod opportunities than the expansion bits.





diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index a4a8e49..866c368 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -7078,6 +7078,11 @@ This is firstly introduced on ARM/AArch64 targets, 
please refer to
 the hook implementation for how different fusion types are supported.
 @end deftypefn

+@deftypefn {Target Hook} void TARGET_EXPAND_DIVMOD_LIBFUNC (rtx @var{libfunc}, 
machine_mode @var{mode}, rtx @var{op0}, rtx @var{op1}, rtx *@var{quot}, rtx 
*@var{rem})
+Define this hook for enabling divmod transform if the port does not have
+hardware divmod insn but defines target-specific divmod libfuncs.
+@end deftypefn
+
 @node Sections
 @section Dividing the Output into Sections (Texts, Data, @dots{})
 @c the above section title is WAY too long.  maybe cut the part between
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 265f1be..c4c387b 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -4890,6 +4890,8 @@ them: try the first ones in this list first.

 @hook TARGET_SCHED_FUSION_PRIORITY

+@hook TARGET_EXPAND_DIVMOD_LIBFUNC
+
 @node Sections
 @section Dividing the Output into Sections (Texts, Data, @dots{})
 @c the above section title is WAY too long.  maybe cut the part between
diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 0b32d5f..42c6973 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -2207,6 +2207,53 @@ expand_ATOMIC_COMPARE_EXCHANGE (internal_fn, gcall *call)
   expand_ifn_atomic_compare_exchange (call);
 }

+/* Expand DIVMOD() using:

In general, we do not use () when referring to objects in comments.


+ a) optab handler for udivmod/sdivmod if it is available.
+ b) If optab_handler doesn't exist, generate call to
+target-specific divmod libfunc.  */
+
+static void
+expand_DIVMOD (internal_fn, gcall *call_stmt)
In general, don't use upper case for function names.  Lower case please. 
 But I believe we should be pushing all the expansion stuff into the 
gimple->rtl expansion code, so I haven't looked at this closely yet on 
the expectation it'll likely move.





diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
index 0cea1a8..

[PATCH] Make std::enable_shared_from_this cope with ambiguity

[Jonathan Wakely]

This patch does three things:

1. Refactor std::enable_shared_from_this support code.

 Instead of several overloads of __enable_shared_from_this_helper
 that contain the same code but operating on slightly different types
 I've split it into two parts. Upcasting to an accessible+unambiguous
 enable_shared_from_this base class is done by new functions found by
 ADL, __enable_shared_from_this_base. That is called by a new
 template function __shared_ptr::_M_enable_shared_from_this_with()
 which actually does the enabling by calling _M_weak_assign.

 Calls to _M_enable_shared_from_this_with(p) closely match the
 wording from my https://wg21.link/p0033r1 paper ("enables
 shared_from_this with p") and are constrained so they don't give an
 error if the __enable_shared_from_this_base() call is ambiguous. We
 already gracefully handled ambiguous std::enable_shared_from_this
 bases (PR56383) but failed noisily if a type had a combination of
 std::enable_shared_from_this, std::__enable_shared_from_this and
 std::experimental::enable_shared_from_this bases. Now we treat those
 combinations gracefully.

2. Change std::experimental::enable_shared_from_this bases to be
 initialized independently of std::enable_shared_from_this bases.
 It's now possible to have both, and for both to be enabled. See
 enable_shared_from_this.cc which tests this.

 The standard says we have to enable shared_from_this for types with
 an accessible and unambiguous std::enable_shared_from_this base
 class, and we should be able to do that even if the class also has
 an experimental::enable_shared_from_this base class. Now we can.

 Potentially we could do the same for std::__enable_shared_from_this,
 but I'm happy for those bases to be considered ambiguous with
 std::enable_shared_from_this.

3. Don't enable shared_from_this for arrays stored in
 experimental::shared_ptr.  This matches the boost::shared_ptr
 semantics, and I intend to propose this as a fix for C++17 too. It
 doesn't make sense to treat the first element of an array specially
 and enable shared_from_this for the first element only.


* include/backward/auto_ptr.h (__shared_ptr(auto_ptr&&)): Call
_M_enable_shared_from_this_with instead of
__enable_shared_from_this_helper.
* include/bits/shared_ptr.h (__enable_shared_from_this_helper):
Remove overload for std::enable_shared_from_this..
(__enable_shared_from_this_base): Define friend function to select a
std::enable_shared_from_this base class.
* include/bits/shared_ptr_base.h (__enable_shared_from_this_helper):
Remove all overloads.
(__shared_ptr): Change all relevant constructors to call
_M_enable_shared_from_this_with instead of
__enable_shared_from_this_helper.
(__shared_ptr::__efst_base_t, __shared_ptr::__has_efst_base): Helpers
to detect accessible and unambiguous enable_shared_from_this bases.
(__shared_ptr::_M_enable_shared_from_this_with): New function to
replace __enable_shared_from_this_helper overloads.
(__enable_shared_from_this_helper): Remove overload for
std::__enable_shared_from_this.
(__enable_shared_from_this_base): Define friend function to select a
std::__enable_shared_from_this base class.
* include/experimental/bits/shared_ptr.h (experimental::shared_ptr):
Change relevant constructors to call _M_enable_shared_from_this_with.
(experimental::shared_ptr::__efst_base_t)
(experimental::shared_ptr::__has_efst_base): Helpers to detect
accessible and unambiguous enable_shared_from_this bases.
(experimental::shared_ptr::_M_enable_shared_from_this_with): Define.
(experimental::__enable_shared_from_this_helper): Remove overload for
std::experimental::enable_shared_from_this.
(experimental::__expt_enable_shared_from_this_base): Define friend
function to select a std::experimental::enable_shared_from_this base.
* testsuite/experimental/memory/shared_ptr/cons/
enable_shared_from_this.cc: New test.
* testsuite/experimental/memory/shared_ptr/cons/unique_ptr_ctor.cc:
Adjust expected behaviour for shared_ptr.

Tested powerpc64le-linux, comitted to trunk.


commit 83405dbeebb5487ae4745b2bdb2edd8f29414a07
Author: Jonathan Wakely 
Date:   Wed Oct 19 19:36:55 2016 +0100

Make std::enable_shared_from_this cope with ambiguity

* include/backward/auto_ptr.h (__shared_ptr(auto_ptr&&)): Call
_M_enable_shared_from_this_with instead of
__enable_shared_from_this_helper.
* include/bits/shared_ptr.h (__enable_shared_from_this_helper):
Remove overload for std::enable_shared_from_this..
(__enable_shared_from_this_base): Define friend function to select a
std::enable_shared_from_this base class.
* include/bits/shared_ptr_base.h (__enable_shared_from_this_helper):
Remove all overloads.
(

Re: [PATCH] Make -Wint-in-bool-context warn on suspicious shift ops

[Jeff Law]

On 10/18/2016 12:14 PM, Bernd Edlinger wrote:

On 10/18/16 19:05, Joseph Myers wrote:

> On Tue, 18 Oct 2016, Bernd Edlinger wrote:
>

>> Hi,
>>
>> this restricts the -Wint-in-bool-context warning to signed shifts,
>> to reduce the number of false positives Markus reported yesterday.

>
> This patch seems to be missing testcases (that warned before the patch
> and don't warn after it).
>

Yes of course.

New patch, this time with a test case, compiled from the linux sample.

Bootstrapped and reg-tested as usual.
Is it OK for trunk?


Bernd.


patch-bool-context4.diff


c-family:
2016-10-17  Bernd Edlinger  

* c-common.c (c_common_truthvalue_conversion): Warn only for signed
integer shift ops in boolean context.

testsuite:
2016-10-17  Bernd Edlinger  

* c-c++-common/Wint-in-bool-context-2.c: New test.
Comment please in the code indicating why we're restricting this to 
signed shifts. I'm not entirely sure I agree with avoiding the 
warning for this case, but I'm not up for fighting about it.  So OK 
after adding the comment.


jeff

Re: [PATCH] Make std::enable_shared_from_this cope with ambiguity

[Jonathan Wakely]

On 19/10/16 21:13 +0100, Jonathan Wakely wrote:

This patch does three things:

1. Refactor std::enable_shared_from_this support code.

Instead of several overloads of __enable_shared_from_this_helper
that contain the same code but operating on slightly different types
I've split it into two parts. Upcasting to an accessible+unambiguous
enable_shared_from_this base class is done by new functions found by
ADL, __enable_shared_from_this_base. That is called by a new
template function __shared_ptr::_M_enable_shared_from_this_with()
which actually does the enabling by calling _M_weak_assign.

Calls to _M_enable_shared_from_this_with(p) closely match the
wording from my https://wg21.link/p0033r1 paper ("enables
shared_from_this with p") and are constrained so they don't give an
error if the __enable_shared_from_this_base() call is ambiguous. We
already gracefully handled ambiguous std::enable_shared_from_this
bases (PR56383) but failed noisily if a type had a combination of
std::enable_shared_from_this, std::__enable_shared_from_this and
std::experimental::enable_shared_from_this bases. Now we treat those
combinations gracefully.

2. Change std::experimental::enable_shared_from_this bases to be
initialized independently of std::enable_shared_from_this bases.
It's now possible to have both, and for both to be enabled. See
enable_shared_from_this.cc which tests this.

The standard says we have to enable shared_from_this for types with
an accessible and unambiguous std::enable_shared_from_this base
class, and we should be able to do that even if the class also has
an experimental::enable_shared_from_this base class. Now we can.

Potentially we could do the same for std::__enable_shared_from_this,
but I'm happy for those bases to be considered ambiguous with
std::enable_shared_from_this.

3. Don't enable shared_from_this for arrays stored in
experimental::shared_ptr.  This matches the boost::shared_ptr
semantics, and I intend to propose this as a fix for C++17 too. It
doesn't make sense to treat the first element of an array specially
and enable shared_from_this for the first element only.


I forgot to say that 2. and 3. are appropriate for gcc-6-branch too,
as they only touch the experimental TS code.

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Christophe Lyon]

On 19 October 2016 at 20:43, Aldy Hernandez  wrote:
>
>>> OK for the trunk whenever you're ready.
>>>
>>> jeff
>>
>>
>> You are too fast for me :-)
>> I do not have the build trees for all the configurations ready for
>> manual testing...
>> So, I just merged the initial patch and the 2nd one, and started
>> a validation job to make sure the 2nd patch fixes all the regressions
>> observed earlier.
>> It will take a few hours.
>
>
> There shouldn't be any problems that didn't surface in my cross build, since
> they are not execution tests, but compile tests.
>
> I have committed the patch.  If there any specific failures specific to your
> target, let me know and I'll address those separately.
>

Validation results of the 2 patches combined are OK.

Thanks

> Thanks.
> Aldy

Re: [PR other/70945] Handle function_glibc_finite_math in offloading

[Thomas Schwinge]

Hi!

On Sat, 21 May 2016 17:59:17 +0200, I wrote:
> As discussed in  "Offloading: compatibility
> of target and offloading toolchains", there are situations where we have
> to do more work to ensure compatibility between target and offloading
> toolchains.

The outcome of the discussion a few months ago has been that instead of
my proposed compiler patch, the "offloading port(s) of newlib [...]
should provide [a] translation layer from the host headers to the
offloading target functions".  We still plan to, but have not yet gotten
to spend time on that, unfortunately.

To at least support the following use case:

> The first thing I'm working on is math functions usage in offloaded
> regions.
> 
> Here is a first patch, addressing glibc's finite math optimizations: if
> -ffinite-math-only (as implied by -ffast-math, or -Ofast) is in effect,
> glibc's  is known to include  for "special
> entry points to use when the compiler got told to only expect finite
> results".  This divertes the math functions' assembler names from
> "[function]" to "__[function]_finite".  This, obviously, is incompatible
> with offloading targets that don't use glibc, and thus don't provide
> these "__[function]_finite" entry points.

..., I have now in r241355 committed my original patch to
gomp-4_0-branch, with an (incomplete) test case added:

commit 7e178f04bf6d692a17c4be4ff050da2d23a543e7
Author: tschwinge 
Date:   Wed Oct 19 21:24:37 2016 +

[PR other/70945] Handle function_glibc_finite_math in offloading

gcc/
PR other/70945
* targhooks.c (default_libc_has_function): Update comment.
* target.def (libc_has_function): Likewise.
* doc/tm.texi: Regenerate.
* coretypes.h (enum function_class): Add
function_glibc_finite_math.
* config/darwin.c (darwin_libc_has_function): Handle it.
* lto-streamer.h (enum lto_section_type): Rename
LTO_section_offload_table to LTO_section_offload_data.  Adjust all
users.
* lto-cgraph.c (void output_offload_data): New function, split out
of output_offload_tables.  Adjust all users.  Stream the target's
function_glibc_finite_math property.
(input_offload_data): New function, split out of
input_offload_tables.  Adjust all users.  Handle mismatch between
the target's and the offloading target's
function_glibc_finite_math property.
libgomp/
PR other/70945
* testsuite/libgomp.oacc-c-c++-common/pr70945-1.c: New file.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@241355 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog.gomp |  20 ++
 gcc/config/darwin.c|   2 +
 gcc/coretypes.h|  11 +-
 gcc/doc/tm.texi|   2 +-
 gcc/lto-cgraph.c   | 181 +++-
 gcc/lto-streamer-out.c |   2 +-
 gcc/lto-streamer.h |   6 +-
 gcc/lto/lto.c  |   2 +-
 gcc/target.def |   2 +-
 gcc/targhooks.c|   2 +-
 libgomp/ChangeLog.gomp |   5 +
 .../libgomp.oacc-c-c++-common/pr70945-1.c  | 231 +
 12 files changed, 408 insertions(+), 58 deletions(-)

diff --git gcc/ChangeLog.gomp gcc/ChangeLog.gomp
index 04894b8..851da81 100644
--- gcc/ChangeLog.gomp
+++ gcc/ChangeLog.gomp
@@ -1,3 +1,23 @@
+2016-10-19  Thomas Schwinge  
+
+   PR other/70945
+   * targhooks.c (default_libc_has_function): Update comment.
+   * target.def (libc_has_function): Likewise.
+   * doc/tm.texi: Regenerate.
+   * coretypes.h (enum function_class): Add
+   function_glibc_finite_math.
+   * config/darwin.c (darwin_libc_has_function): Handle it.
+   * lto-streamer.h (enum lto_section_type): Rename
+   LTO_section_offload_table to LTO_section_offload_data.  Adjust all
+   users.
+   * lto-cgraph.c (void output_offload_data): New function, split out
+   of output_offload_tables.  Adjust all users.  Stream the target's
+   function_glibc_finite_math property.
+   (input_offload_data): New function, split out of
+   input_offload_tables.  Adjust all users.  Handle mismatch between
+   the target's and the offloading target's
+   function_glibc_finite_math property.
+
 2016-10-05  Nathan Sidwell  
 
* tree.h (OMP_CLAUSE_TILE_ITERVAR, OMP_CLAUSE_TILE_COUNT): New.
diff --git gcc/config/darwin.c gcc/config/darwin.c
index 0055d80..92fe3e5 100644
--- gcc/config/darwin.c
+++ gcc/config/darwin.c
@@ -3401,6 +3401,8 @@ darwin_libc_has_function (enum function_class fn_class)
   || fn_class == function_c99_misc)
 return (TARGET_64BIT
|| strverscmp (darwin_macosx_

Re: [PATCH] fix outstanding -Wformat-length failures (pr77735 et al.)

[Jeff Law]

On 10/17/2016 03:59 PM, Martin Sebor wrote:



On 10/17/2016 01:11 PM, Jeff Law wrote:

On 10/02/2016 02:10 PM, Martin Sebor wrote:

The attached patch fixes a number of outstanding test failures
and ILP32-related bugs in the gimple-ssa-sprintf pattch pointed
out in bug 77676 and 77735).  The patch also fixes c_strlen to
correctly handle wide strings (previously it accepted them but
treated them as nul-terminated byte sequences), and adjusts the
handling of "%a" to avoid assuming a specific number of decimal
digits (this is likely a defect in C11 that I'm pursuing with
WG14).

Tested on powerpc64le, i386, and x86_64.

There is one outstanding failure in the builtin-sprintf-warn-1.c
test on powerpc64le that looks like it might be due to the
printf_pointer_format target hook not having been set up entirely
correctly.  I'll look into that separately, along with pr77819.

Martin

gcc-77735.diff


PR middle-end/77735 - FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c

gcc/ChangeLog:
2016-10-02  Martin Sebor  

PR middle-end/77735
* builtins.c (string_length): New function.
(c_strlen): Use string_length.  Correctly handle wide strings.
* gimple-ssa-sprintf.c (target_max_value, target_size_max): New
functions.
(target_int_max): Call target_max_value.
(format_result::knownrange): New data member.
(fmtresult::fmtresult): Define default constructor.
(format_integer): Use it and set format_result::knownrange.
Handle global constants.
(format_floating_max): Add third argument.
(format_floating): Recompute maximum value for %a for each argument.
(get_string_length): Use fmtresult default ctor.
(format_string): Set format_result::knownrange.
(format_directive): Check format_result::knownrange.
(add_bytes): Same.  Correct caret placement in diagnostics.
(pass_sprintf_length::compute_format_length): Set
format_result::knownrange.
(pass_sprintf_length::handle_gimple_call): Use target_size_max.

gcc/testsuite/ChangeLog:
2016-10-02  Martin Sebor  

PR middle-end/77735
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Add test cases.
* 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: Adjust/relax.
* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: XFAIL for LP64 only.
* gcc.dg/tree-ssa/builtin-sprintf.c: Add test cases.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 92f939e..410bbc3 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -1281,9 +1330,9 @@ format_floating (const conversion_spec &spec,
int width, int prec)
 res.range.max = width;
 }

-  /* The argument is only considered bounded when the range of output
- bytes is exact.  */
-  res.bounded = res.range.min == res.range.max;
+  /* The argument is considered bounded when the output of a directive
+ is fully specified and the range of output bytes is exact.  */
+  // res.bounded &= res.range.min == res.range.max;

Did you mean to leave this commented out?


I'm pretty sure I didn't mean to leave the code commented out like
that.  I suspect I commented it out to confirm that it's not needed,
and forgot to remove it after it passed my testing.  Let me remove
it (and thanks for pointing it out!)


It looks like you're defining a constructor for "struct fmtresult".
Normally once we define a constructor we turn the underlying object into
a class.It appears that the constructor leaves argmin, argmax,
knownrange, bounded & constant uninitialized?  Am I missing something
here?


I added the default ctor to avoid having to explicitly clear the
members.  The member() syntax means to default-initialize them by
setting them to zero or null:

 struct fmtresult
 {
+  fmtresult ()
+  : argmin (), argmax (), knownrange (), bounded (), constant ()
+  {
+range.min = range.max = HOST_WIDE_INT_MAX;
+  }
+

Or did you have something else in mind?  (I want to leave the members
public so they can conveniently accessed.)

Ah, thanks for clarifying.







+  /* A plain '%c' directive.  Its ouput is excactly 1.  */

Typo for exactly.



Will fix.

With that and with the comment above removed, would like me to post
an updated patch or is it okay commit?
OK to commit after the fix in floating_format (assignment to 
res.bounded) and the commit fix.


jeff

[libgo] Remove unused declarations in runtime.h

[Eric Botcazou]

Hi,

linking any Go program on SPARC/Solaris with the GNU assembler and the Sun 
linker yields a warning:

ld: warning: relocation error: R_SPARC_UA32: file 
/sydney.a/users/botcazou/gcc-head/sparc-sun-
solaris2.10/./libgo/libgobegin.a(libgobegin_a-go-main.o): symbol 
runtime_startup_random_data: external symbolic relocation against non-
allocatable section .debug_info; cannot be processed at runtime: relocation 
ignored

It's because (almost) every C file in runtime/ includes runtime.h, which has 
these lines:

byte*  runtime_startup_random_data;
uint32 runtime_startup_random_data_len;
void   runtime_get_random_data(byte**, int32*);

which cause (almost) every object file to have the first 2 as common symbols 
and this runs afoul of some limitation of the Sun linker.  Now there seem to 
be no other references to these 3 objects in the libgo directory and removing 
them doesn't seem to change the behavior of the Go compiler so the attached 
patch does just that.

Tested on x86_64-suse-linux and SPARC/Solaris, OK for mainline?


2016-10-19  Eric Botcazou  

* runtime/runtime.h (runtime_startup_random_data): Delete.
(runtime_startup_random_data_len): Likewise.
(runtime_get_random_data): Likewise.

-- 
Eric BotcazouIndex: runtime/runtime.h
===
--- runtime/runtime.h	(revision 241326)
+++ runtime/runtime.h	(working copy)
@@ -220,10 +220,6 @@ extern bool runtime_copystack;
 #define USED(v)		((void) v)
 #define	ROUND(x, n)	(((x)+(n)-1)&~(uintptr)((n)-1)) /* all-caps to mark as macro: it evaluates n twice */
 
-byte*	runtime_startup_random_data;
-uint32	runtime_startup_random_data_len;
-void	runtime_get_random_data(byte**, int32*);
-
 enum {
 	// hashinit wants this many random bytes
 	HashRandomBytes = 32

Re: [PATCH v3] gcc/config/tilegx/tilegx.c (tilegx_function_profiler): Save r10 to stack before call mcount

[Jeff Law]

On 10/06/2016 07:53 AM, Chen Gang wrote:

Hello Maintainers:

Is this patch OK? Please help check it when you have time (at least for
me, it passes all related test and comparation).

And I shall continue to find and fix another issues about tilegx.

Thanks.

On 6/4/16 21:25, cheng...@emindsoft.com.cn wrote:

From: Chen Gang 

r10 may also be as parameter stack pointer for the nested function, so
need save it before call mcount.

Also clean up code: use '!' instead of "== 0" for checking
static_chain_decl and compute_total_frame_size.

2016-06-04  Chen Gang  

gcc/
PR target/71331
* config/tilegx/tilegx.c (tilegx_function_profiler): Save r10
to stack before call mcount.
(tilegx_can_use_return_insn_p): Clean up code.
So if I understand the tilegx architecture correctly, you're issuing the 
r10 save & sp adjustment as a bundle, and the restore & sp adjustment as 
a bundle.


The problem is the semantics of bunding on the tilegx effectively mean 
that all source operands are read in parallel, then all outputs occur in 
parallel.


So if we take the bundle

{addi sp,sp,-8 ; st sp, r10}

The address used for the st is the value of the stack pointer before the 
addi instruction.


Similarly for the restore r10 bundle.  The address used for the load is 
sp before adjustment.


Given my understanding of the tilegx bundling semantics, that seems wrong.

Jeff

Re: [patch] Fix PHI optimization issue with boolean types

[Eric Botcazou]

> Because BOOLEAN_TYPE types only have two values as documented in
> tree.def:
> 
> /* Boolean type (true or false are the only values).  Looks like an
>INTEGRAL_TYPE.  */
> DEFTREECODE (BOOLEAN_TYPE, "boolean_type", tcc_type, 0)

Yes, but on the other hand they have a precision and a range.

> There are not many references to BOOLEAN_TYPE in ada/gcc-interface
> thus it shouldn't be hard to change ... (looks like Ada might even prefer
> ENUMERAL_TYPE here).

It was like that originally (an ENUMERAL_TYPE) but this blocked LTO (well, 
cross-language LTO) exactly like the sizetype discrepancy, so I don't really 
feel like going back in time.

-- 
Eric Botcazou

[committed] Fix bootstrap for hppa64-hpux11* on trunk

[John David Anglin]

The removal of the JCR_SECTION_NAME define in config/pa/pa64-hpux.h broke 
bootstrap on hppa64-hpux
with HP ld.  It exposed a header ordering issue building the crt* objects.  
EH_FRAME_SECTION was not
defined when pa64-hpux.h was included and as a result frame_dummy was not 
called.  This caused everything
which used the new libgcc to abort.

The problem was fixed by using the __LIBGCC_EH_FRAME_SECTION_NAME__ and
__LIBGCC_DTORS_SECTION_ASM_OP__ predefines.

I also moved three defines in gcc/config/pa/pa64-hpux.h to a new header file in 
libgcc.  These defines were only
used for building the crt* objects.

Tested on hppa64-hp-hpux11.11.  Committed to trunk.

Dave
--
John David Anglin   dave.ang...@bell.net


2016-10-19  John David Anglin  

libgcc/
* config/pa/pa64-hpux-lib.h: New file.  
(EH_FRAME_SECTION_NAME): Rename to __LIBGCC_EH_FRAME_SECTION_NAME__.
(DTORS_SECTION_ASM_OP): Rename to __LIBGCC_DTORS_SECTION_ASM_OP__.
* config.host (tm_file): Add pa/pa64-hpux-lib.h to tm_file on
hppa*64*-*-hpux11*.
gcc/
* config/pa/pa64-hpux.h (PA_INIT_FRAME_DUMMY_ASM_OP): Move to
config/pa/pa64-hpux-lib.h.
(PA_CRTBEGIN_HACK): Likewise.
(DTOR_LIST_BEGIN): Likewise.

--- /dev/null   2016-10-19 17:08:27 +
+++ libgcc/config/pa/pa64-hpux-lib.h2016-10-17 18:52:38 +
@@ -0,0 +1,101 @@
+/* Definitions of target machine for GNU compiler, for HPs running
+   HP-UX using the 64bit runtime model.
+   Copyright (C) 1999-2016 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/* We use DTOR_LIST_BEGIN to carry a bunch of hacks to allow us to use
+   the init and fini array sections with both the HP and GNU linkers.
+   The linkers setup the required dynamic entries in the dynamic segment
+   and the dynamic linker does the calls.  This approach avoids using
+   collect2.
+
+   The first hack is to implement __do_global_ctors_aux in crtbegin as
+   it needs to be the first entry in the init array so that it is called
+   last.  HP got the order of the init array backwards.  The DT_INIT_ARRAY
+   is supposed to be executed in the same order as the addresses appear in
+   the array.  DT_FINI_ARRAY is supposed to be executed in the opposite
+   order.
+
+   The second hack is a set of plabels to implement the effect of
+   CRT_CALL_STATIC_FUNCTION.  HP-UX 11 only supports DI_INIT_ARRAY and
+   DT_FINI_ARRAY and they put the arrays in .init and .fini, rather than
+   in .init_array and .fini_array.  The standard defines for .init and
+   .fini have the execute flag set.  So, the assembler has to be hacked
+   to munge the standard flags for these sections to make them agree
+   with what the HP linker expects.  With the GNU linker, we need to
+   used the .init_array and .fini_array sections.  So, we set up for
+   both just in case.  Once we have built the table, the linker does
+   the rest of the work.
+   The order is significant.  Placing __do_global_ctors_aux first in
+   the list, results in it being called last.  User specified initializers,
+   either using the linker +init command or a plabel, run before the
+   initializers specified here.  */
+
+/* We need to add frame_dummy to the initializer list if EH_FRAME_SECTION_NAME
+   is defined.  */
+#if defined(__LIBGCC_EH_FRAME_SECTION_NAME__)
+#define PA_INIT_FRAME_DUMMY_ASM_OP ".dword P%frame_dummy"
+#else
+#define PA_INIT_FRAME_DUMMY_ASM_OP ""
+#endif
+
+/* The following hack sets up the .init, .init_array, .fini and
+   .fini_array sections.  */
+#define PA_CRTBEGIN_HACK \
+asm (TEXT_SECTION_ASM_OP);  \
+static void __attribute__((used))   \
+__do_global_ctors_aux (void)\
+{   \
+  func_ptr *p = __CTOR_LIST__;  \
+  while (*(p + 1))  \
+p++;\
+  for (; *p != (func_ptr) -1; p--)  \
+(*p) ();\
+}   \
+   

[PATCH] DWARF5 .debug_line{,_str} support

[Jakub Jelinek]

Hi!

This patch adds support for DWARF5 .debug_line{,_str} section format,
though only if !DWARF2_ASM_LINE_DEBUG_INFO, because otherwise
.debug_line is emitted by the assembler.  For that we'll need some
coordination with gas, dunno if we want a new as directive for that,
or as command line switch, or perhaps key DWARF5 .debug_line on the
presence of .debug_line_str section (though the last one probably isn't a
good idea, because -gsplit-dwarf doesn't use .debug_line_str).

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

2016-10-20  Jakub Jelinek  

* dwarf2out.c (debug_line_str_section): New variable.
(debug_line_str_hash): Likewise.
(DEBUG_LINE_STR_SECTION): Define.
(set_indirect_string): Handle DW_FORM_line_strp like
DW_FORM_strp.
(find_string_form): Fix up formatting.
(size_of_die): Handle DW_FORM_line_strp like DW_FORM_strp.
Fix up indentation.
(output_die): Handle DW_FORM_line_strp.
(output_file_names): Add -gdwarf-5 support.
(output_line_info): Likewise.
(init_sections_and_labels): Initialize debug_line_str_section.
(output_indirect_string): Change 2nd argument from void *
to enum dwarf_form form, compare with form rather than
DW_FORM_strp.
(output_indirect_strings): Pass DW_FORM_strp to
output_indirect_string traversion.
(dwarf2out_finish): Output .debug_line_str strings.
(dwarf2out_c_finalize): Clear debug_line_str_section and
debug_line_str_hash.

--- gcc/dwarf2out.c.jj  2016-10-18 08:17:19.0 +0200
+++ gcc/dwarf2out.c 2016-10-19 14:37:23.945841924 +0200
@@ -167,6 +167,7 @@ static GTY(()) section *debug_loc_sectio
 static GTY(()) section *debug_pubnames_section;
 static GTY(()) section *debug_pubtypes_section;
 static GTY(()) section *debug_str_section;
+static GTY(()) section *debug_line_str_section;
 static GTY(()) section *debug_str_dwo_section;
 static GTY(()) section *debug_str_offsets_section;
 static GTY(()) section *debug_ranges_section;
@@ -225,6 +226,8 @@ struct indirect_string_hasher : ggc_ptr_
 
 static GTY (()) hash_table *debug_str_hash;
 
+static GTY (()) hash_table *debug_line_str_hash;
+
 /* With split_debug_info, both the comp_dir and dwo_name go in the
main object file, rather than the dwo, similar to the force_direct
parameter elsewhere but with additional complications:
@@ -232,8 +235,8 @@ static GTY (()) hash_tableform == DW_FORM_strp || node->form == DW_FORM_GNU_str_index)
+  if (node->form == DW_FORM_strp
+  || node->form == DW_FORM_line_strp
+  || node->form == DW_FORM_GNU_str_index)
 {
   gcc_assert (node->label);
   return;
@@ -4175,7 +4183,7 @@ find_string_form (struct indirect_string
  single module.  */
   if (DWARF2_INDIRECT_STRING_SUPPORT_MISSING_ON_TARGET
   || ((debug_str_section->common.flags & SECTION_MERGE) == 0
-  && (len - DWARF_OFFSET_SIZE) * node->refcount <= len))
+ && (len - DWARF_OFFSET_SIZE) * node->refcount <= len))
 return node->form = DW_FORM_string;
 
   set_indirect_string (node);
@@ -8500,10 +8508,10 @@ size_of_die (dw_die_ref die)
  break;
case dw_val_class_str:
   form = AT_string_form (a);
-  if (form == DW_FORM_strp)
+ if (form == DW_FORM_strp || form == DW_FORM_line_strp)
size += DWARF_OFFSET_SIZE;
- else if (form == DW_FORM_GNU_str_index)
-size += size_of_uleb128 (AT_index (a));
+ else if (form == DW_FORM_GNU_str_index)
+   size += size_of_uleb128 (AT_index (a));
  else
size += strlen (a->dw_attr_val.v.val_str->str) + 1;
  break;
@@ -9458,6 +9466,11 @@ output_die (dw_die_ref die)
a->dw_attr_val.v.val_str->label,
debug_str_section,
"%s: \"%s\"", name, AT_string (a));
+ else if (a->dw_attr_val.v.val_str->form == DW_FORM_line_strp)
+   dw2_asm_output_offset (DWARF_OFFSET_SIZE,
+  a->dw_attr_val.v.val_str->label,
+  debug_line_str_section,
+  "%s: \"%s\"", name, AT_string (a));
   else if (a->dw_attr_val.v.val_str->form == DW_FORM_GNU_str_index)
 dw2_asm_output_data_uleb128 (AT_index (a),
  "%s: \"%s\"", name, AT_string (a));
@@ -10429,8 +10442,18 @@ output_file_names (void)
 
   if (!last_emitted_file)
 {
-  dw2_asm_output_data (1, 0, "End directory table");
-  dw2_asm_output_data (1, 0, "End file name table");
+  if (dwarf_version >= 5)
+   {
+ dw2_asm_output_data (1, 0, "Directory entry format count");
+ dw2_asm_output_data_uleb128 (0, "Directories count");
+ dw2_asm_output_data (1, 0, "File name entry format count");
+ dw2_asm_output_data_uleb128 (0, "File name

[PATCH] DWARF5 .debug_loclists support

[Jakub Jelinek]

Hi!

This patch adds .debug_loclists and .debug_loclists.dwo
support for -gdwarf-5 and -gdwarf-5 -gsplit-dwarf.
The decrease of section size from .debug_loc section to .debug_loclists
is really nice.

The patch doesn't handle -gdwarf-5 -gsplit-dwarf on targets where assembler
doesn't support .uleb128, because in that case we really can't use
DW_LLE_startx_length (no way to emit uleb128 region sizes - we don't have
accurate instruction length computations) - we should use DW_LLE_startx_endx
in that case, but would need .debug_addr entries not just for the region
starts, but ends.  Cary, could you resolve this incrementally (and, do you
plan to convert other -gsplit-dwarf support parts to DWARF 5 for -gdwarf-5)?

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

2016-10-20  Jakub Jelinek  

* dwarf2out.h (enum dw_val_class): Add dw_val_class_loclistsptr.
* dwarf2out.c (struct dw_loc_list_struct): Change emitted field
from bool to 1-bit uchar bitfield.  Add num_assigned and
offset_emitted bitfields.
(dw_val_equal_p): Compare v.val_lbl_id rather than v.val_unsigned
for dw_val_class_lineptr and dw_val_class_macptr.  Handle
dw_val_class_loclistsptr.
(new_addr_loc_descr): Fix up formatting.
(DEBUG_LOCLISTS_SECTION, DEBUG_DWO_LOCLISTS_SECTION): Define.
(add_AT_low_high_pc): Fix up formatting.
(add_AT_loclistsptr): New function.
(AT_lbl): Allow dw_val_class_loclistsptr.
(print_dw_val, attr_checksum, attr_checksum_ordered, same_dw_val_p):
Handle dw_val_class_loclistsptr.
(loc_list_idx): New variable.
(output_loclists_offsets): New function.
(size_of_die): For dw_val_class_loc_list -gsplit-dwarf -gdwarf-5
add size_of_uleb128 of the index.  Drop never used
dwarf_split_debug_info AT_index handling.  Handle
dw_val_class_loclistsptr.
(value_format): Return DW_FORM_loclistsx for dw_val_class_loc_list
if -gsplit-dwarf -gdwarf-5.  Handle dw_val_class_loclistsptr.
(output_loc_list): Handle DWARF 5 .debug_loclists* format.
(output_loc_list_offset): Handle -gsplit-dwarf -gdwarf-5
DW_FORM_loclistx indexes.
(output_attr_index_or_value): Fix up formatting.  Don't handle
dw_val_class_loc_list here.
(output_die): Formatting fixes.  Handle dw_val_class_loclistsptr.
For dw_val_class_loc_list call output_loc_list_offset rather than
output_attr_index_or_value.
(init_sections_and_labels): For -gdwarf-5 use .debug_loclists
or .debug_loclists.dwo section name for debug_loc_section.
(resolve_addr_in_expr): Formatting fix.
(index_location_lists): Likewise.
(assign_location_list_indexes): New function.
(dwarf2out_finish): If there are any location lists, for
-gsplit-dwarf -gdwarf-5 add DW_AT_loclists_base attribute.  Call
index_location_lists only if have_location_lists.  Call
assign_location_list_indexes for -gsplit-dwarf -gdwarf-5.  Emit
.debug_loclists{,.dwo} section header for -gdwarf-5, for -gdwarf-5
-gsplit-dwarf also emit offset table.

--- gcc/dwarf2out.h.jj  2016-10-18 08:17:19.0 +0200
+++ gcc/dwarf2out.h 2016-10-19 23:09:53.456786659 +0200
@@ -147,6 +147,7 @@ enum dw_val_class
   dw_val_class_lineptr,
   dw_val_class_str,
   dw_val_class_macptr,
+  dw_val_class_loclistsptr,
   dw_val_class_file,
   dw_val_class_data8,
   dw_val_class_decl_ref,
--- gcc/dwarf2out.c.jj  2016-10-19 14:37:23.0 +0200
+++ gcc/dwarf2out.c 2016-10-19 23:15:44.280352083 +0200
@@ -1279,7 +1279,13 @@ typedef struct GTY(()) dw_loc_list_struc
   bool resolved_addr;
   /* True if this list has been replaced by dw_loc_next.  */
   bool replaced;
-  bool emitted;
+  /* True if it has been emitted into .debug_loc* / .debug_loclists*
+ section.  */
+  unsigned char emitted : 1;
+  /* True if hash field is index rather than hash value.  */
+  unsigned char num_assigned : 1;
+  /* True if .debug_loclists.dwo offset has been emitted for it already.  */
+  unsigned char offset_emitted : 1;
   /* True if the range should be emitted even if begin and end
  are the same.  */
   bool force;
@@ -1367,8 +1373,6 @@ dw_val_equal_p (dw_val_node *a, dw_val_n
 case dw_val_class_unsigned_const:
 case dw_val_class_const:
 case dw_val_class_range_list:
-case dw_val_class_lineptr:
-case dw_val_class_macptr:
   /* These are all HOST_WIDE_INT, signed or unsigned.  */
   return a->v.val_unsigned == b->v.val_unsigned;
 
@@ -1381,6 +1385,9 @@ dw_val_equal_p (dw_val_node *a, dw_val_n
 case dw_val_class_fde_ref:
   return a->v.val_fde_index == b->v.val_fde_index;
 case dw_val_class_lbl_id:
+case dw_val_class_lineptr:
+case dw_val_class_macptr:
+case dw_val_class_loclistsptr:
 case dw_val_class_high_pc:
   return strcmp (a->v.val_lbl_id, b->v.val_lbl_id) == 0;