Re: [PATCH, Pointer Bounds Checker 25/x] DCE

[Ilya Enkovich]

On 03 Jun 17:27, Ilya Enkovich wrote:
> 2014-06-03 15:56 GMT+04:00 Richard Biener :
> > On Tue, Jun 3, 2014 at 1:36 PM, Ilya Enkovich  
> > wrote:
> >> 2014-06-03 13:45 GMT+04:00 Richard Biener :
> >>> On Tue, Jun 3, 2014 at 9:23 AM, Ilya Enkovich  
> >>> wrote:
>  Hi,
> 
>  This patch adjusts alloc-free removal algorithm in DCE to take into 
>  account BUILT_IN_CHKP_BNDRET call returning bounds of allocated memory.
> 
>  Bootstrapped and tested on linux-x86_64.
> 
>  Thanks,
>  Ilya
>  --
>  gcc/
> 
>  2014-06-03  Ilya Enkovich  
> 
>  * tree-ssa-dce.c: Include target.h.
>  (propagate_necessity): For free call fed by alloc check
>  bounds are also provided by the same alloc.
>  (eliminate_unnecessary_stmts): Handle BUILT_IN_CHKP_BNDRET
>  used by free calls.
> 
>  diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
>  index 13a71ce..59a0b71 100644
>  --- a/gcc/tree-ssa-dce.c
>  +++ b/gcc/tree-ssa-dce.c
>  @@ -73,6 +73,7 @@ along with GCC; see the file COPYING3.  If not see
>   #include "flags.h"
>   #include "cfgloop.h"
>   #include "tree-scalar-evolution.h"
>  +#include "target.h"
> 
>   static struct stmt_stats
>   {
>  @@ -778,7 +779,23 @@ propagate_necessity (bool aggressive)
>    && DECL_BUILT_IN_CLASS (def_callee) == BUILT_IN_NORMAL
>    && (DECL_FUNCTION_CODE (def_callee) == BUILT_IN_MALLOC
>    || DECL_FUNCTION_CODE (def_callee) == 
>  BUILT_IN_CALLOC))
>  -   continue;
>  +   {
>  + tree retfndecl
>  +   = targetm.builtin_chkp_function 
>  (BUILT_IN_CHKP_BNDRET);
>  + gimple bounds_def_stmt;
>  + tree bounds;
>  +
>  + /* For instrumented calls we should also check used
>  +bounds are returned by the same allocation call.  */
>  + if (!gimple_call_with_bounds_p (stmt)
>  + || ((bounds = gimple_call_arg (stmt, 1))
> >>>
> >>> Please provide an abstraction for this - I seem to recall seeing multiple
> >>> (variants) of this.  Esp. repeated calls to the target hook above look
> >>> expensive to me (generally it will not be needed).
> >>>
> >>> I'd like to see gimple_call_bndarg (stmt) to get rid of the "magic" 1 and 
> >>> I'd
> >>> like to see sth similar to gimple_call_builtin_p, for example
> >>> gimple_call_chkp_p (stmt, BUILT_IN_CHKP_BNDRET) doing the
> >>> target hook invocation and the fndecl check.
> >>
> >> I do not see how to get rid of constant in gimple_call_arg call here.
> >> What semantics does proposed gimple_call_bndarg have? It has to return
> >> the first bounds arg but it's not clear from its name and function
> >> seems to be very specialized.
> >
> > Ah, ok.  I see now, so the code is ok as-is.
> >
> >>>
>  + && TREE_CODE (bounds) == SSA_NAME
> >>>
> >>> What about constant bounds?  That shouldn't make the call necessary 
> >>> either?
> >>
> >> Yep, it would be useless.
> >
> > So please fix.
> >
> >>>
>  + && (bounds_def_stmt = SSA_NAME_DEF_STMT 
>  (bounds))
>  + && is_gimple_call (bounds_def_stmt)
>  + && gimple_call_fndecl (bounds_def_stmt) == 
>  retfndecl
>  + && gimple_call_arg (bounds_def_stmt, 0) == 
>  ptr))
>  +   continue;
> >>>
> >>> So this all becomes
> >>>
> >>>if (!gimple_call_with_bounds_p (stmt)
> >>>|| ((bounds = gimple_call_bndarg (stmt))
> >>>&& TREE_CODE (bounds) == SSA_NAME
> >>>&& (bounds_def_stmt = SSA_NAME_DEF_STMT 
> >>> (bounds))
> >>>&& is_gimple_call (bounds_def_stmt)
> >>>&& gimple_call_chkp_p (bounds_def_stmt,
> >>> BUILT_IN_CHKP_BNDRET)
> >>> ...
> >>>
> >>> btw, I wonder how BUILT_IN_CHKP_BNDRET is in scope here but you
> >>> need a target hook to compare the fndecl?  Why isn't it enough to
> >>> just check DECL_FUNCTION_CODE and DECL_BUILT_IN?
> >>
> >> Call is required because builtins for Pointer Bounds Checker are
> >> provided by target depending on available features. That is why
> >> gimple_call_builtin_p is not used. I may add new interface function
> >> into tree-chkp.h as you propose (e.g. chkp_gimple_call_builtin_p). But
> >> I do not see how it may speed-up the code. New function would still
> >> need to switch by function code and compare with proper decl which is
> >> basically what we have with target hook.
> >
> > I don't understand - does this mean the builtin calls are in the GIMPLE
> > IL even though the target doesn't have the feature?  

Re: [PATCH, Pointer Bounds Checker 26/x] CCP

[Ilya Enkovich]

On 03 Jun 11:54, Richard Biener wrote:
> On Tue, Jun 3, 2014 at 9:38 AM, Ilya Enkovich  wrote:
> > Hi,
> >
> > This patch allows BUILT_IN_CHKP_BNDRET as a consumer of a result of 
> > BUILT_IN_STACK_SAVE call.
> >
> > Bootstrapped and tested on linux-x86_64.
> >
> > Thanks,
> > Ilya
> > --
> > gcc/
> >
> > 2014-06-03  Ilya Enkovich  
> >
> > * tree-ssa-ccp.c (insert_clobber_before_stack_restore): Handle
> > BUILT_IN_CHKP_BNDRET calls.
> >
> >
> > diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
> > index eeefeaf..c138337 100644
> > --- a/gcc/tree-ssa-ccp.c
> > +++ b/gcc/tree-ssa-ccp.c
> > @@ -1848,7 +1848,7 @@ insert_clobber_before_stack_restore (tree saved_val, 
> > tree var,
> >  gimple_htab *visited)
> >  {
> >gimple stmt, clobber_stmt;
> > -  tree clobber;
> > +  tree clobber, fndecl;
> >imm_use_iterator iter;
> >gimple_stmt_iterator i;
> >gimple *slot;
> > @@ -1880,6 +1880,10 @@ insert_clobber_before_stack_restore (tree saved_val, 
> > tree var,
> >  else if (gimple_assign_ssa_name_copy_p (stmt))
> >insert_clobber_before_stack_restore (gimple_assign_lhs (stmt), var,
> >visited);
> > +else if (gimple_code (stmt) == GIMPLE_CALL
> > +&& (fndecl = targetm.builtin_chkp_function 
> > (BUILT_IN_CHKP_BNDRET))
> > +&& gimple_call_fndecl (stmt) == fndecl)
> > +  continue;
> 
> Please change this to use the proper abstraction once implemented.  It should
> be sth like
> 
> else if (is_gimple_call (stmt)
>&& gimple_call_builtin_p (stmt, BUILT_IN_CHKP_BNDRET))
>continue;
> 
> I assume now that the builtins are not target builtins but added to
> builtins.def.
> 
> Richard.
> 
> >  else
> >gcc_assert (is_gimple_debug (stmt));
> >  }

Here is a fixed version with proper predicate.

Bootstrapped and tested on linux_x86-64.

Thanks,
Ilya
--
gcc/

2014-06-05  Ilya Enkovich  

* tree-ssa-ccp.c: Include tree-chkp.h.
(insert_clobber_before_stack_restore): Handle
BUILT_IN_CHKP_BNDRET calls.


diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
index eeefeaf..e99bcf5 100644
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -144,6 +144,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "diagnostic-core.h"
 #include "dbgcnt.h"
 #include "params.h"
+#include "tree-chkp.h"
 
 
 /* Possible lattice values.  */
@@ -1880,6 +1881,9 @@ insert_clobber_before_stack_restore (tree saved_val, tree 
var,
 else if (gimple_assign_ssa_name_copy_p (stmt))
   insert_clobber_before_stack_restore (gimple_assign_lhs (stmt), var,
   visited);
+else if (gimple_code (stmt) == GIMPLE_CALL
+&& chkp_gimple_call_builtin_p (stmt, BUILT_IN_CHKP_BNDRET))
+  continue;
 else
   gcc_assert (is_gimple_debug (stmt));
 }

Re: ipa-visibility TLC 2/n

[Jan Hubicka]

> Honza,
> 
> How can we make further progress with the large regression on AIX?
David,
sorry for taking time to get back to it.  I went through the code and see no 
obvious flaws
except that I am somewhat concerned what happens with local aliases into the 
anchors.
The problem however does not seem to be caused by it.  I tracked it down to the 
following
difference:

--- d2.s2014-06-06 08:59:01.101401622 +0200
+++ d3.s2014-06-06 08:59:01.491377632 +0200
@@ -499,7 +499,7 @@
.long   4
.long   4
.long   _ZTI1B
-   .long   _ZTv0_n12_N1B1fEv
+   .long   _ZTv0_n12_N1B1fEv.localalias.5
.weak   _ZTV1A
.align 2
 _ZTV1A:

Now _ZTv0_n12_N1B1fEv is thunk declared as:

.lglobl .LTHUNK..0
.lglobl LTHUNK..0
.set.LTHUNK..0,._ZN1B1fEv
.set LTHUNK..0,_ZN1B1fEv
.lglobl ._ZTv0_n12_N1B1fEv.localalias.5
.lglobl _ZTv0_n12_N1B1fEv.localalias.5
.set._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
.set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
.align 2
.weak   _ZTv0_n12_N1B1fEv[DS]
.weak   ._ZTv0_n12_N1B1fEv
.csect _ZTv0_n12_N1B1fEv[DS]
_ZTv0_n12_N1B1fEv:
.long ._ZTv0_n12_N1B1fEv, TOC[tc0], 0
.csect .text[PR]
._ZTv0_n12_N1B1fEv:
LFB..16:
lwz 12,0(3)
lwz 12,-12(12)
add 3,3,12
b .LTHUNK..0

Now when I move the declaration of localalias after the thunk:

--- d3.s2014-06-06 08:59:01.491377632 +0200
+++ d4.s2014-06-06 09:03:58.129810951 +0200
@@ -212,10 +212,6 @@
.lglobl LTHUNK..0
.set.LTHUNK..0,._ZN1B1fEv
.set LTHUNK..0,_ZN1B1fEv
-   .lglobl ._ZTv0_n12_N1B1fEv.localalias.5
-   .lglobl _ZTv0_n12_N1B1fEv.localalias.5
-   .set._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
-   .set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
.align 2
.weak   _ZTv0_n12_N1B1fEv[DS]
.weak   ._ZTv0_n12_N1B1fEv
@@ -229,6 +225,10 @@
lwz 12,-12(12)
add 3,3,12
b .LTHUNK..0
+   .lglobl ._ZTv0_n12_N1B1fEv.localalias.5
+   .lglobl _ZTv0_n12_N1B1fEv.localalias.5
+   .set._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
+   .set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
 LFE..16:
.align 2
.weak   _ZN1D1fEv[DS]

The code starts to work.  To me both sources should make same binary, but they 
don't.
Can you make better sense of this than claiming it is an assembler bug?

We output aliases after definitions for functions, but before definitions for 
thunks.
I am testing patch to change the second order.  I remeber tweaking this order 
once before
because of problems on solaris.  Lets see if we find order that works for 
everyone.

Honza
.file   "/home/jh/trunk/gcc/testsuite/g++.dg/abi/vcall1.C"
.csect .text[PR]
.toc
.csect .text[PR]
.globl b
.csect .data[RW],4
.align 2
b:
.space 4
.csect .text[PR]
.align 2
.weak   _ZN1A1fEv[DS]
.weak   ._ZN1A1fEv
.csect _ZN1A1fEv[DS]
_ZN1A1fEv:
.long ._ZN1A1fEv, TOC[tc0], 0
.csect .text[PR]
._ZN1A1fEv:
LFB..0:
stw 31,-4(1)
stwu 1,-32(1)
LCFI..0:
mr 31,1
LCFI..1:
stw 3,56(31)
addi 1,31,32
LCFI..2:
lwz 31,-4(1)
blr
LT.._ZN1A1fEv:
.long 0
.byte 0,9,32,96,128,1,1,1
.long 0
.long LT.._ZN1A1fEv-._ZN1A1fEv
.short 9
.byte "_ZN1A1fEv"
.byte 31
.align 2
LFE..0:
.lglobl ._ZN1A1fEv.localalias.4
.lglobl _ZN1A1fEv.localalias.4
.set._ZN1A1fEv.localalias.4,._ZN1A1fEv
.set _ZN1A1fEv.localalias.4,_ZN1A1fEv
.toc
LC..0:
.tc _ZTV1A.P8[TC],_ZTV1A+8
.csect .text[PR]
.align 2
.weak   _ZN1AC2Ev[DS]
.weak   ._ZN1AC2Ev
.csect _ZN1AC2Ev[DS]
_ZN1AC2Ev:
.long ._ZN1AC2Ev, TOC[tc0], 0
.csect .text[PR]
._ZN1AC2Ev:
LFB..3:
stw 31,-4(1)
stwu 1,-32(1)
LCFI..3:
mr 31,1
LCFI..4:
stw 3,56(31)
lwz 9,56(31)
lwz 10,LC..0(2)
stw 10,0(9)
addi 1,31,32
LCFI..5:
lwz 31,-4(1)
blr
LT.._ZN1AC2Ev:
.long 0
.byte 0,9,32,96,128,1,1,1
.long 0
.long LT.._ZN1AC2Ev-._ZN1AC2Ev
.short 9
.byte "_ZN1AC2Ev"
.byte 31
.align 2
LFE..3:
.lglobl ._ZN1AC2Ev.localalias.3
.lglobl _ZN1AC2Ev.localalias.3
.set._ZN1AC2Ev.localalias.3,._ZN1AC2Ev
.set _ZN1AC2Ev.localalias.3,_ZN1AC2Ev
.toc
LC..1:
.tc b[TC],b
.csect .text[PR]
.align 2
.weak   _ZN1BC2Ev[DS]
.weak   ._ZN1BC2Ev
.csect _ZN1BC2Ev[DS]
_ZN1BC2Ev:
.long ._ZN1BC2Ev, TOC[tc0], 0
.csect .text[PR]
._ZN1BC2Ev:
LFB..5:
mflr 0
stw 0,8(1)
stw 31,-4(1)
stwu 1,-64(

Re: [patch, mips, tree] align microMIPS functions to 16 bits with -Os

[Richard Biener]

On Thu, 5 Jun 2014, Sandra Loosemore wrote:

> On 06/05/2014 03:50 PM, Richard Sandiford wrote:
> > Sandra Loosemore  writes:
> > > On 06/05/2014 01:39 AM, Richard Biener wrote:
> > > > 
> > > > [snip]
> > > > 
> > > > Ok, we definitely need to preserve that (documented) behavior.  I
> > > > suppose
> > > > it also sets DECL_USER_ALIGN.  -falign-functions is probably another
> > > > setter of DECL_ALIGN here.
> > > > 
> > > > If we add a target hook that may adjust function alignment then it
> > > > has to honor any user set alignment, then -falign-functions and
> > > > then it may only increase alignment over the default FUNCTION_BOUNDARY.
> > > > 
> > > > The point to adjust alignment with the hook may still be output time,
> > > > but as we figured it can't simply ignore DECL_ALIGN.
> > > 
> > > H.  The MIPS tweak we want here is to decrease the alignment for
> > > certain functions, so I suppose this means we'd have to go about it
> > > backwards by making FUNCTION_BOUNDARY 16 rather than 32 (at least for
> > > -Os) and then later increasing it back to 32 for all non-microMIPS
> > > functions.
> > > 
> > > Richard S., WDYT?  Shall I hack up another patch that does it that way,
> > > or do you think that's still the wrong way to go about it?
> > 
> > Well, it sounds like the idea is that FUNCTION_BOUNDARY should basically
> > be ignored as a DECL_ALIGN.  The only cases where DECL_ALIGN should matter
> > are those where the user has set the alignment via command-line options
> > or attributes.  If so, I'd rather just leave it as it is and make the
> > hook pick something smaller.
> > 
> > Just to be sure: I'd imagined this working by having varasm.c detect
> > when DECL_ALIGN needs to be honoured and having a hook to call when
> > DECL_ALIGN is irrelevant.  The default version would then assert
> > that DECL_ALIGN is FUNCTION_BOUNDARY and would return that alignment.
> > The MIPS hook would override it for the special microMIPS case,
> > but would call into the default otherwise.
> > 
> > (Hmm, maybe for that level of detail I should just have written a patch.
> > Sorry about that...)

Well, the question is what you initialize DECL_ALIGN to initially and how
you ensure that docs are followed for aligned attribute (you can't
decrease function alignment by it).  Adjusting a pre-existing DECL_ALIGN
to sth smaller at any point sounds dangerous.  So why not go with
Sandras idea instead?  I'd transition FUNCTION_BOUNDARY to a target hook
like

  unsigned function_boundary (tree decl);

and for decl == NULL return the "default" (the default hook implementation
would just return MAX (FUNCTION_BOUNDARY, DECL_ALIGN)).  We'd call 
function_boundary (NULL) from tree.c and later from varasm.c query
it again, but this time with the decl specified.

And yes, you'd lower your default function_boundary.

Richard.

> I'm willing to write/test a patch once you guys agree on the semantics of the
> new hook and are happy with how it would be used to solve this particular
> problem

[PATCH] Run phi_only_cprop after 2nd VRP

[Richard Biener]

This moves the 2nd VRP pass to run befoe phi_only_cprop as
VRP performs jump-threading which can result in BBs with
PHI singletons.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2014-06-06  Richard Biener  

* passes.def: Move 2nd VRP pass before phi-only-cprop.

Index: gcc/passes.def
===
--- gcc/passes.def  (revision 211271)
+++ gcc/passes.def  (working copy)
@@ -240,13 +240,13 @@ along with GCC; see the file COPYING3.
   NEXT_PASS (pass_reassoc);
   NEXT_PASS (pass_strength_reduction);
   NEXT_PASS (pass_dominator);
+  NEXT_PASS (pass_vrp);
   /* The only const/copy propagation opportunities left after
-DOM should be due to degenerate PHI nodes.  So rather than
+DOM and VRP should be due to degenerate PHI nodes.  So rather than
 run the full propagators, run a specialized pass which
 only examines PHIs to discover const/copy propagation
 opportunities.  */
   NEXT_PASS (pass_phi_only_cprop);
-  NEXT_PASS (pass_vrp);
   NEXT_PASS (pass_cd_dce);
   NEXT_PASS (pass_tracer);
   NEXT_PASS (pass_dse);

Minor fixes in RTL location support

[Eric Botcazou]

This cleans up some left-overs of the transition from locators to locations in 
the RTL middle-end, most notably direct comparisons against UNKNOWN_LOCATION, 
and adds an insn_location function to be called instead of using insn_file and 
insn_line in a row.

Tested on x86_64-suse-linux, applied on the mainline.


2014-06-06  Eric Botcazou  

* rtl.h (insn_location): Declare.
* cfgcleanup.c (try_forward_edges): Compare the locus of locations
with UNKNOWN_LOCATION.
* emit-rtl.c (insn_location): New function.
* final.c (notice_source_line): Check that the instruction has a
location before retrieving it and use insn_location.
* modulo-sched.c (loop_single_full_bb_p): Likewise.
* print-rtl.c (print_rtx): Likewise.


-- 
Eric BotcazouIndex: rtl.h
===
--- rtl.h	(revision 211101)
+++ rtl.h	(working copy)
@@ -2130,6 +2130,7 @@ extern rtx prev_cc0_setter (rtx);
 extern int insn_line (const_rtx);
 extern const char * insn_file (const_rtx);
 extern tree insn_scope (const_rtx);
+extern expanded_location insn_location (const_rtx);
 extern location_t prologue_location, epilogue_location;
 
 /* In jump.c */
Index: cfgcleanup.c
===
--- cfgcleanup.c	(revision 211101)
+++ cfgcleanup.c	(working copy)
@@ -482,31 +482,30 @@ try_forward_edges (int mode, basic_block
 		  location_t new_locus = single_succ_edge (target)->goto_locus;
 		  location_t locus = goto_locus;
 
-		  if (new_locus != UNKNOWN_LOCATION
-		  && locus != UNKNOWN_LOCATION
+		  if (LOCATION_LOCUS (new_locus) != UNKNOWN_LOCATION
+		  && LOCATION_LOCUS (locus) != UNKNOWN_LOCATION
 		  && new_locus != locus)
 		new_target = NULL;
 		  else
 		{
-		  rtx last;
-
-		  if (new_locus != UNKNOWN_LOCATION)
+		  if (LOCATION_LOCUS (new_locus) != UNKNOWN_LOCATION)
 			locus = new_locus;
 
-		  last = BB_END (target);
+		  rtx last = BB_END (target);
 		  if (DEBUG_INSN_P (last))
 			last = prev_nondebug_insn (last);
+		  if (last && INSN_P (last))
+			new_locus = INSN_LOCATION (last);
+		  else
+			new_locus = UNKNOWN_LOCATION;
 
-		  new_locus = last && INSN_P (last)
-  ? INSN_LOCATION (last) : 0;
-
-		  if (new_locus != UNKNOWN_LOCATION
-			  && locus != UNKNOWN_LOCATION
+		  if (LOCATION_LOCUS (new_locus) != UNKNOWN_LOCATION
+			  && LOCATION_LOCUS (locus) != UNKNOWN_LOCATION
 			  && new_locus != locus)
 			new_target = NULL;
 		  else
 			{
-			  if (new_locus != UNKNOWN_LOCATION)
+			  if (LOCATION_LOCUS (new_locus) != UNKNOWN_LOCATION)
 			locus = new_locus;
 
 			  goto_locus = locus;
Index: emit-rtl.c
===
--- emit-rtl.c	(revision 211101)
+++ emit-rtl.c	(working copy)
@@ -6173,6 +6173,13 @@ insn_file (const_rtx insn)
   return LOCATION_FILE (INSN_LOCATION (insn));
 }
 
+/* Return expanded location of the statement that produced this insn.  */
+expanded_location
+insn_location (const_rtx insn)
+{
+  return expand_location (INSN_LOCATION (insn));
+}
+
 /* Return true if memory model MODEL requires a pre-operation (release-style)
barrier or a post-operation (acquire-style) barrier.  While not universal,
this function matches behavior of several targets.  */
Index: final.c
===
--- final.c	(revision 211101)
+++ final.c	(working copy)
@@ -3019,10 +3019,16 @@ notice_source_line (rtx insn, bool *is_s
   filename = override_filename;
   linenum = override_linenum;
 }
+  else if (INSN_HAS_LOCATION (insn))
+{
+  expanded_location xloc = insn_location (insn);
+  filename = xloc.file;
+  linenum = xloc.line;
+}
   else
 {
-  filename = insn_file (insn);
-  linenum = insn_line (insn);
+  filename = NULL;
+  linenum = 0;
 }
 
   if (filename == NULL)
Index: modulo-sched.c
===
--- modulo-sched.c	(revision 211101)
+++ modulo-sched.c	(working copy)
@@ -1244,11 +1244,10 @@ loop_single_full_bb_p (struct loop *loop
 static void
 dump_insn_location (rtx insn)
 {
-  if (dump_file && INSN_LOCATION (insn))
+  if (dump_file && INSN_HAS_LOCATION (insn))
 {
-  const char *file = insn_file (insn);
-  if (file)
-	fprintf (dump_file, " %s:%i", file, insn_line (insn));
+  expanded_location xloc = insn_location (insn);
+  fprintf (dump_file, " %s:%i", xloc.file, xloc.line);
 }
 }
 
Index: print-rtl.c
===
--- print-rtl.c	(revision 211101)
+++ print-rtl.c	(working copy)
@@ -395,9 +395,11 @@ print_rtx (const_rtx in_rtx)
 	/*  Pretty-print insn locations.  Ignore scoping as it is mostly
 		redundant with line number information and do not print anything
 		when there is no location information av

Re: [patch, mips, tree] align microMIPS functions to 16 bits with -Os

[Richard Sandiford]

Richard Biener  writes:
> On Thu, 5 Jun 2014, Sandra Loosemore wrote:
>
>> On 06/05/2014 03:50 PM, Richard Sandiford wrote:
>> > Sandra Loosemore  writes:
>> > > On 06/05/2014 01:39 AM, Richard Biener wrote:
>> > > > 
>> > > > [snip]
>> > > > 
>> > > > Ok, we definitely need to preserve that (documented) behavior.  I
>> > > > suppose
>> > > > it also sets DECL_USER_ALIGN.  -falign-functions is probably another
>> > > > setter of DECL_ALIGN here.
>> > > > 
>> > > > If we add a target hook that may adjust function alignment then it
>> > > > has to honor any user set alignment, then -falign-functions and
>> > > > then it may only increase alignment over the default FUNCTION_BOUNDARY.
>> > > > 
>> > > > The point to adjust alignment with the hook may still be output time,
>> > > > but as we figured it can't simply ignore DECL_ALIGN.
>> > > 
>> > > H.  The MIPS tweak we want here is to decrease the alignment for
>> > > certain functions, so I suppose this means we'd have to go about it
>> > > backwards by making FUNCTION_BOUNDARY 16 rather than 32 (at least for
>> > > -Os) and then later increasing it back to 32 for all non-microMIPS
>> > > functions.
>> > > 
>> > > Richard S., WDYT?  Shall I hack up another patch that does it that way,
>> > > or do you think that's still the wrong way to go about it?
>> > 
>> > Well, it sounds like the idea is that FUNCTION_BOUNDARY should basically
>> > be ignored as a DECL_ALIGN.  The only cases where DECL_ALIGN should matter
>> > are those where the user has set the alignment via command-line options
>> > or attributes.  If so, I'd rather just leave it as it is and make the
>> > hook pick something smaller.
>> > 
>> > Just to be sure: I'd imagined this working by having varasm.c detect
>> > when DECL_ALIGN needs to be honoured and having a hook to call when
>> > DECL_ALIGN is irrelevant.  The default version would then assert
>> > that DECL_ALIGN is FUNCTION_BOUNDARY and would return that alignment.
>> > The MIPS hook would override it for the special microMIPS case,
>> > but would call into the default otherwise.
>> > 
>> > (Hmm, maybe for that level of detail I should just have written a patch.
>> > Sorry about that...)
>
> Well, the question is what you initialize DECL_ALIGN to initially and how
> you ensure that docs are followed for aligned attribute (you can't
> decrease function alignment by it).  Adjusting a pre-existing DECL_ALIGN
> to sth smaller at any point sounds dangerous.  So why not go with
> Sandras idea instead?  I'd transition FUNCTION_BOUNDARY to a target hook
> like
>
>   unsigned function_boundary (tree decl);
>
> and for decl == NULL return the "default" (the default hook implementation
> would just return MAX (FUNCTION_BOUNDARY, DECL_ALIGN)).  We'd call 
> function_boundary (NULL) from tree.c and later from varasm.c query
> it again, but this time with the decl specified.
>
> And yes, you'd lower your default function_boundary.

What I don't like about this is the function_boundary (NULL) bit.
If having function_boundary (NULL) lower than function_boundary (decl)
is dangerous, that implies that we're using the function_boundary (NULL)
somewhere, which in itself seems bad.

How about initialising the DECL_ALIGN to:

(TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn
 ? 2 * BITS_PER_UNIT : BITS_PER_UNIT)

instead of function_boundary (NULL)?  That way we might even be able to
rely on DECL_ALIGN in get_object_alignment_2.

Richard

Put source location on return edges

[Eric Botcazou]

Similarly to what's done for gotos and conditional expressions.

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


2014-06-06  Eric Botcazou  

* tree-cfg.c (make_edges) : Put a location onto the edge.


-- 
Eric BotcazouIndex: tree-cfg.c
===
--- tree-cfg.c	(revision 211101)
+++ tree-cfg.c	(working copy)
@@ -763,8 +763,11 @@ make_edges (void)
 	  fallthru = false;
 	  break;
 	case GIMPLE_RETURN:
-	  make_edge (bb, EXIT_BLOCK_PTR_FOR_FN (cfun), 0);
-	  fallthru = false;
+	  {
+		edge e = make_edge (bb, EXIT_BLOCK_PTR_FOR_FN (cfun), 0);
+		e->goto_locus = gimple_location (last);
+		fallthru = false;
+	  }
 	  break;
 	case GIMPLE_COND:
 	  make_cond_expr_edges (bb);

[ping] Partially fix PR debug/53927

[Eric Botcazou]

https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00573.html

Thanks in advance.

-- 
Eric Botcazou

Re: [patch, mips, tree] align microMIPS functions to 16 bits with -Os

[Richard Biener]

On Fri, 6 Jun 2014, Richard Sandiford wrote:

> Richard Biener  writes:
> > On Thu, 5 Jun 2014, Sandra Loosemore wrote:
> >
> >> On 06/05/2014 03:50 PM, Richard Sandiford wrote:
> >> > Sandra Loosemore  writes:
> >> > > On 06/05/2014 01:39 AM, Richard Biener wrote:
> >> > > > 
> >> > > > [snip]
> >> > > > 
> >> > > > Ok, we definitely need to preserve that (documented) behavior.  I
> >> > > > suppose
> >> > > > it also sets DECL_USER_ALIGN.  -falign-functions is probably another
> >> > > > setter of DECL_ALIGN here.
> >> > > > 
> >> > > > If we add a target hook that may adjust function alignment then it
> >> > > > has to honor any user set alignment, then -falign-functions and
> >> > > > then it may only increase alignment over the default 
> >> > > > FUNCTION_BOUNDARY.
> >> > > > 
> >> > > > The point to adjust alignment with the hook may still be output time,
> >> > > > but as we figured it can't simply ignore DECL_ALIGN.
> >> > > 
> >> > > H.  The MIPS tweak we want here is to decrease the alignment for
> >> > > certain functions, so I suppose this means we'd have to go about it
> >> > > backwards by making FUNCTION_BOUNDARY 16 rather than 32 (at least for
> >> > > -Os) and then later increasing it back to 32 for all non-microMIPS
> >> > > functions.
> >> > > 
> >> > > Richard S., WDYT?  Shall I hack up another patch that does it that way,
> >> > > or do you think that's still the wrong way to go about it?
> >> > 
> >> > Well, it sounds like the idea is that FUNCTION_BOUNDARY should basically
> >> > be ignored as a DECL_ALIGN.  The only cases where DECL_ALIGN should 
> >> > matter
> >> > are those where the user has set the alignment via command-line options
> >> > or attributes.  If so, I'd rather just leave it as it is and make the
> >> > hook pick something smaller.
> >> > 
> >> > Just to be sure: I'd imagined this working by having varasm.c detect
> >> > when DECL_ALIGN needs to be honoured and having a hook to call when
> >> > DECL_ALIGN is irrelevant.  The default version would then assert
> >> > that DECL_ALIGN is FUNCTION_BOUNDARY and would return that alignment.
> >> > The MIPS hook would override it for the special microMIPS case,
> >> > but would call into the default otherwise.
> >> > 
> >> > (Hmm, maybe for that level of detail I should just have written a patch.
> >> > Sorry about that...)
> >
> > Well, the question is what you initialize DECL_ALIGN to initially and how
> > you ensure that docs are followed for aligned attribute (you can't
> > decrease function alignment by it).  Adjusting a pre-existing DECL_ALIGN
> > to sth smaller at any point sounds dangerous.  So why not go with
> > Sandras idea instead?  I'd transition FUNCTION_BOUNDARY to a target hook
> > like
> >
> >   unsigned function_boundary (tree decl);
> >
> > and for decl == NULL return the "default" (the default hook implementation
> > would just return MAX (FUNCTION_BOUNDARY, DECL_ALIGN)).  We'd call 
> > function_boundary (NULL) from tree.c and later from varasm.c query
> > it again, but this time with the decl specified.
> >
> > And yes, you'd lower your default function_boundary.
> 
> What I don't like about this is the function_boundary (NULL) bit.
> If having function_boundary (NULL) lower than function_boundary (decl)
> is dangerous, that implies that we're using the function_boundary (NULL)
> somewhere, which in itself seems bad.

The other way around - function_boundary (NULL) should not be larger
than function_boundary (decl).

> How about initialising the DECL_ALIGN to:
> 
> (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn
>  ? 2 * BITS_PER_UNIT : BITS_PER_UNIT)
> 
> instead of function_boundary (NULL)?  That way we might even be able to
> rely on DECL_ALIGN in get_object_alignment_2.

Not sure about that, but initializing that way certainly looks
reasonable.

Btw, maybe we should call function_boundary to properly initialize
DECL_ALIGN earlier than output time, for example in
cgraph_finalize_function.  There might be an IPA pass sorting
functions after their alignment to squeeze some more bits
by reducing possible padding.

Richard.

Re: [PATCH] Fix PR61335

[Uros Bizjak]

Hello!

> 2014-05-28  Richard Biener  
>
> PR tree-optimization/61335
> * tree-vrp.c (vrp_visit_phi_node): If the compare of old and
> new range fails, drop to varying.
>
> * gfortran.dg/pr61335.f90: New testcase.

This testcase triggers SIGFPE on alpha due to the use of denormal
operand. Maybe uninitialized value is used in line 48?

Reading symbols from ./pr61335.exe...done.
(gdb) r
Starting program: /space/homedirs/uros/test/pr61335.exe

Program received signal SIGFPE, Arithmetic exception.
0x00012b54 in cp_units::cp_unit_create (string=, _string=5)
at /home/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/pr61335.f90:48
48  unit_id=cp_units_none
(gdb) list
43  len_string, next_power
44  INTEGER, DIMENSION(cp_unit_max_kinds):: kind_id, power, unit_id
45  LOGICAL  :: failure
46
47  failure=.FALSE.
48  unit_id=cp_units_none
49  kind_id=cp_ukind_none
50  power=0
51  i_low=1
52  i_high=1

The exception is triggered in 0x12b50, but emitted on the next FP insn.

   0x00012b4c <+76>:lds $f10,48(fp)
   0x00012b50 <+80>:cvttq/c $f10,$f10
=> 0x00012b54 <+84>:ftoit   $f10,t0

(gdb) b *0x12b50
Breakpoint 1 at 0x12b50: file
/home/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/pr61335.f90, line
48.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /space/homedirs/uros/test/pr61335.exe

Breakpoint 1, 0x00012b50 in cp_units::cp_unit_create
(string=,
_string=5) at
/home/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/pr61335.f90:48
48  unit_id=cp_units_none

(gdb) i r $f10
f108.0173244974249919e-310  (raw 0x9396)

The test passes with -mieee that allows denormals.

Uros.

Re: [PATCH] Clean bswap messages and tests

[Richard Biener]

On Fri, Jun 6, 2014 at 7:32 AM, Thomas Preud'homme
 wrote:
> This patch include 2 cleanup that were requested in PR61320:
>
> * Use dg-additional-options to specify the extra option s390 target needs
> * Use the correct vocabulary of target endianness instead of host endianness 
> in comments, pass dump and the past ChangeLog entry.

Ok.

(just in case you intended to ask ;))

Richard.

> Here are the ChangeLog:
>
> *** gcc/ChangeLog ***
>
> 2014-06-04  Thomas Preud'homme  
>
> * ChangeLog (2014-05-23): Fix ChangeLog entry to refer to target
> endianness instead of host endianness.
> * tree-ssa-math-opts.c (find_bswap_or_nop_1): Likewise in dumps and
> comments.
>
> *** gcc/testsuite/ChangeLog ***
>
> 2014-06-04  Thomas Preud'homme  
>
> 2014-06-04  Thomas Preud'homme  
>
> * gcc.dg/optimize-bswaphi-1.c: Adapt test to change of dump output.
> Specify -march=z900 as an additional option.
> * gcc.dg/optimize-bswapsi-1.c: Likewise for s390 options.
> * gcc.dg/optimize-bswapsi-2.c: Likewise.
> * gcc.dg/optimize-bswapdi-3.c: Likewise for adaptation to dump change.
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index de07e5c..09122aa 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1623,7 +1623,8 @@
> (find_bswap_or_nop_1): This. Also add support for memory source.
> (find_bswap): Renamed to ...
> (find_bswap_or_nop): This. Also add support for memory source and
> -   detection of bitwise operations equivalent to load in host endianness.
> +   detection of bitwise operations equivalent to load in target
> +   endianness.
> (execute_optimize_bswap): Likewise. Also move its leading comment back
> in place and split statement transformation into ...
> (bswap_replace): This.
> diff --git a/gcc/testsuite/gcc.dg/optimize-bswapdi-3.c 
> b/gcc/testsuite/gcc.dg/optimize-bswapdi-3.c
> index 0a8bf2e..d96d7e5 100644
> --- a/gcc/testsuite/gcc.dg/optimize-bswapdi-3.c
> +++ b/gcc/testsuite/gcc.dg/optimize-bswapdi-3.c
> @@ -59,6 +59,6 @@ uint64_t read_be64_3 (unsigned char *data)
>  | ((uint64_t) *(data + 1) << 48) | ((uint64_t) *data << 56);
>  }
>
> -/* { dg-final { scan-tree-dump-times "64 bit load in host endianness found 
> at" 3 "bswap" } } */
> +/* { dg-final { scan-tree-dump-times "64 bit load in target endianness found 
> at" 3 "bswap" } } */
>  /* { dg-final { scan-tree-dump-times "64 bit bswap implementation found at" 
> 3 "bswap" { xfail alpha*-*-* arm*-*-* } } } */
>  /* { dg-final { cleanup-tree-dump "bswap" } } */
> diff --git a/gcc/testsuite/gcc.dg/optimize-bswaphi-1.c 
> b/gcc/testsuite/gcc.dg/optimize-bswaphi-1.c
> index 65bff98..3e51f04 100644
> --- a/gcc/testsuite/gcc.dg/optimize-bswaphi-1.c
> +++ b/gcc/testsuite/gcc.dg/optimize-bswaphi-1.c
> @@ -2,7 +2,7 @@
>  /* { dg-require-effective-target bswap16 } */
>  /* { dg-require-effective-target stdint_types } */
>  /* { dg-options "-O2 -fdump-tree-bswap" } */
> -/* { dg-options "-O2 -fdump-tree-bswap -march=z900" { target s390-*-* } } */
> +/* { dg-additional-options "-march=z900" { target s390-*-* } } */
>
>  #include 
>
> @@ -42,6 +42,6 @@ uint32_t read_be16_3 (unsigned char *data)
>return *(data + 1) | (*data << 8);
>  }
>
> -/* { dg-final { scan-tree-dump-times "16 bit load in host endianness found 
> at" 3 "bswap" } } */
> +/* { dg-final { scan-tree-dump-times "16 bit load in target endianness found 
> at" 3 "bswap" } } */
>  /* { dg-final { scan-tree-dump-times "16 bit bswap implementation found at" 
> 3 "bswap" { xfail alpha*-*-* arm*-*-* } } } */
>  /* { dg-final { cleanup-tree-dump "bswap" } } */
> diff --git a/gcc/testsuite/gcc.dg/optimize-bswapsi-1.c 
> b/gcc/testsuite/gcc.dg/optimize-bswapsi-1.c
> index 33d0bb0..ebfca60 100644
> --- a/gcc/testsuite/gcc.dg/optimize-bswapsi-1.c
> +++ b/gcc/testsuite/gcc.dg/optimize-bswapsi-1.c
> @@ -2,7 +2,7 @@
>  /* { dg-require-effective-target bswap32 } */
>  /* { dg-require-effective-target stdint_types } */
>  /* { dg-options "-O2 -fdump-tree-bswap" } */
> -/* { dg-options "-O2 -fdump-tree-bswap -march=z900" { target s390-*-* } } */
> +/* { dg-additional-options "-march=z900" { target s390-*-* } } */
>
>  #include 
>
> diff --git a/gcc/testsuite/gcc.dg/optimize-bswapsi-2.c 
> b/gcc/testsuite/gcc.dg/optimize-bswapsi-2.c
> index 518b510..de6e697 100644
> --- a/gcc/testsuite/gcc.dg/optimize-bswapsi-2.c
> +++ b/gcc/testsuite/gcc.dg/optimize-bswapsi-2.c
> @@ -2,7 +2,7 @@
>  /* { dg-require-effective-target bswap32 } */
>  /* { dg-require-effective-target stdint_types } */
>  /* { dg-options "-O2 -fdump-tree-bswap" } */
> -/* { dg-options "-O2 -fdump-tree-bswap -march=z900" { target s390-*-* } } */
> +/* { dg-additional-options "-march=z900" { target s390-*-* } } */
>
>  #include 
>
> @@ -44,6 +44,6 @@ uint32_t read_be32_3 (unsigned char *data)
>  | (*data << 24);
>  }
>
> -/* { dg-final { scan-tree-dump-times "32 bit load in host endianness found 
> at" 3 "bs

Re: [ping] Partially fix PR debug/53927

[Richard Biener]

On Fri, Jun 6, 2014 at 9:42 AM, Eric Botcazou  wrote:
> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00573.html
>
> Thanks in advance.

Ok.

Thanks,
Richard.

> --
> Eric Botcazou

Re: [PATCH, Pointer Bounds Checker 22/x] Inline

[Ilya Enkovich]

2014-06-03 13:07 GMT+04:00 Richard Biener :
> On Mon, Jun 2, 2014 at 5:56 PM, Ilya Enkovich  wrote:
>> Hi,
>>
>> This patch adds support for inlining instrumented calls.  Changes are mostly 
>> to support returned bounds.  Also generated mem-to-mem assignments are 
>> registered to be later instrumented with appropriate bounds copy.
>>
>> Bootstrapped and tested on linux-x86_64.
>>
>> Thanks,
>> Ilya
>> --
>> gcc/
>>
>> 2014-06-02  Ilya Enkovich  
>>
>> * ipa-inline.c (early_inliner): Check edge has summary allocated.
>> * tree-inline.c: Include tree-chkp.h.
>> (declare_return_variable): Add arg holding
>> returned bounds slot.  Create and initialize returned bounds var.
>> (remap_gimple_stmt): Handle returned bounds.
>> Return sequence of statements instead of a single statement.
>> (insert_init_stmt): Add declaration.
>> (remap_gimple_seq): Adjust to new remap_gimple_stmt signature.
>> (copy_bb): Adjust to changed return type of remap_gimple_stmt.
>> (expand_call_inline): Handle returned bounds.  Add bounds copy
>> for generated mem to mem assignments.
>> * tree-inline.h (copy_body_data): Add fields retbnd and
>> assign_stmts.
>> * cgraph.c: Include tree-chkp.h.
>> (cgraph_redirect_edge_call_stmt_to_callee): Support
>> returned bounds.
>> * value-prof.c: Include tree-chkp.h.
>> (gimple_ic): Support returned bounds.
>>
>>
>> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
>> index 1f684c2..4b6996b 100644
>> --- a/gcc/cgraph.c
>> +++ b/gcc/cgraph.c
>> @@ -63,6 +63,7 @@ along with GCC; see the file COPYING3.  If not see
>>  #include "gimple-pretty-print.h"
>>  #include "expr.h"
>>  #include "tree-dfa.h"
>> +#include "tree-chkp.h"
>>
>>  /* FIXME: Only for PROP_loops, but cgraph shouldn't have to know about 
>> this.  */
>>  #include "tree-pass.h"
>> @@ -1398,6 +1399,31 @@ cgraph_redirect_edge_call_stmt_to_callee (struct 
>> cgraph_edge *e)
>>   e->speculative = false;
>>   cgraph_set_call_stmt_including_clones (e->caller, e->call_stmt,
>>  new_stmt, false);
>> +
>> + /* Fix edges for BUILT_IN_CHKP_BNDRET calls attached to the
>> +processed call stmt.  */
>> + if (gimple_call_with_bounds_p (new_stmt)
>> + && gimple_call_lhs (new_stmt)
>> + && chkp_retbnd_call_by_val (gimple_call_lhs (e2->call_stmt)))
>> +   {
>> + tree dresult = gimple_call_lhs (new_stmt);
>> + tree iresult = gimple_call_lhs (e2->call_stmt);
>> + gimple dbndret = chkp_retbnd_call_by_val (dresult);
>> + gimple ibndret = chkp_retbnd_call_by_val (iresult);
>> + struct cgraph_edge *iedge = cgraph_edge (e2->caller, ibndret);
>> + struct cgraph_edge *dedge;
>> +
>> + if (dbndret)
>> +   {
>> + dedge = cgraph_create_edge (iedge->caller, iedge->callee,
>> + dbndret, e->count,
>> + e->frequency);
>> + dedge->frequency = compute_call_stmt_bb_frequency
>> +   (dedge->caller->decl, gimple_bb (dedge->call_stmt));
>> +   }
>> + iedge->frequency = compute_call_stmt_bb_frequency
>> +   (iedge->caller->decl, gimple_bb (iedge->call_stmt));
>> +   }
>>   e->frequency = compute_call_stmt_bb_frequency
>>(e->caller->decl, gimple_bb (e->call_stmt));
>>   e2->frequency = compute_call_stmt_bb_frequency
>> diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
>> index 4051819..a6fc853 100644
>> --- a/gcc/ipa-inline.c
>> +++ b/gcc/ipa-inline.c
>> @@ -2301,11 +2301,15 @@ early_inliner (void)
>>  info that might be cleared out for newly discovered edges.  */
>>   for (edge = node->callees; edge; edge = edge->next_callee)
>> {
>> - struct inline_edge_summary *es = inline_edge_summary (edge);
>> - es->call_stmt_size
>> -   = estimate_num_insns (edge->call_stmt, &eni_size_weights);
>> - es->call_stmt_time
>> -   = estimate_num_insns (edge->call_stmt, &eni_time_weights);
>> + /* We have no summary for new bound store calls yet.  */
>> + if (inline_edge_summary_vec.length () > (unsigned)edge->uid)
>> +   {
>> + struct inline_edge_summary *es = inline_edge_summary 
>> (edge);
>> + es->call_stmt_size
>> +   = estimate_num_insns (edge->call_stmt, 
>> &eni_size_weights);
>> + es->call_stmt_time
>> +   = estimate_num_insns (edge->call_stmt, 
>> &eni_time_weights);
>> +   }
>>   if (edge->callee->decl
>>   && !gimple_check_call_matching_types (
>>   edg

Re: [PATCH] Fix PR61335

[Uros Bizjak]

On Fri, Jun 6, 2014 at 9:47 AM, Uros Bizjak  wrote:

>> 2014-05-28  Richard Biener  
>>
>> PR tree-optimization/61335
>> * tree-vrp.c (vrp_visit_phi_node): If the compare of old and
>> new range fails, drop to varying.
>>
>> * gfortran.dg/pr61335.f90: New testcase.
>
> This testcase triggers SIGFPE on alpha due to the use of denormal
> operand. Maybe uninitialized value is used in line 48?

SIGFPE also triggers at the same place on x86_64 with unmasked FPE
exceptions (compile with -O0).

(gdb) b main
Breakpoint 1 at 0x401602: file
/home/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/pr61335.f90, line
115.
(gdb) r
Starting program: /home/uros/test/pr61335.exe
warning: no loadable sections found in added symbol-file
system-supplied DSO at 0x2aaab000

Breakpoint 1, main (argc=1, argv=0x7fffd88e) at
/home/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/pr61335.f90:115
115 USE cp_units
(gdb) i r mxcsr
mxcsr  0x1f80   [ IM DM ZM OM UM PM ]
(gdb) set $mxcsr=0x1000
(gdb) i r mxcsr
mxcsr  0x1000   [ PM ]
(gdb) c
Continuing.

Program received signal SIGFPE, Arithmetic exception.
0x00400b60 in cp_units::cp_unit_create (string=, _string=5)
at /home/uros/gcc-svn/trunk/gcc/testsuite/gfortran.dg/pr61335.f90:49
49  kind_id=cp_ukind_none

   0x00400b57 <+95>:mov-0x28(%rbp),%eax
   0x00400b5a <+98>:mov%eax,-0x280(%rbp)
=> 0x00400b60 <+104>:   cvttss2si -0x280(%rbp),%ecx

(gdb) i r mxcsr
mxcsr  0x1021   [ IE PE PM ]

Uros.

Re: [patch] Update catch(...) handlers to deal with __forced_unwind

[Uros Bizjak]

Hello!

>> Failing to rethrow a __forced_unwind exception is very bad.
>>
>> This patch ensures we rethrow them in async tasks, and makes the
>> shared state ready with a broken_promise so that waiting threads
>> don't block forever. That seems reasonable to me, does anyone have any
>> better ideas?
>>
>> Tested x86_64-linux, will wait for feedback before committing.
>>
>> Committed to trunk.

* testsuite/30_threads/async/forced_unwind.cc: New.
* testsuite/30_threads/packaged_task/forced_unwind.cc: New.

These two tests timeout on alpha-linux-gnu:

FAIL: 30_threads/async/forced_unwind.cc execution test
WARNING: program timed out.
FAIL: 30_threads/packaged_task/forced_unwind.cc execution test
WARNING: program timed out.

strace -f of 30_threads/async/forced_unwind.cc execution test:

...
open("/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0&\220\1\0\0\0\320r\0\0\0\0\0\0"...,
832) = 832
fstat64(3, {st_mode=S_IFREG|0755, st_size=141449, ...}) = 0
mmap(NULL, 189528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x227c000
mprotect(0x2296000, 57344, PROT_NONE) = 0
mmap(0x22a4000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x22a4000
mmap(0x22a8000, 9304, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x22a8000
close(3)= 0
open("/lib/libc.so.6.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0&\220\1\0\0\0`_\2\0\0\0\0\0"...,
832) = 832
fstat64(3, {st_mode=S_IFREG|0755, st_size=1646104, ...}) = 0
mmap(NULL, 1719888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x22ac000
mprotect(0x2438000, 57344, PROT_NONE) = 0
mmap(0x2446000, 32768, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18a000) = 0x2446000
mmap(0x244e000, 7760, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x244e000
close(3)= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x245
mprotect(0x2446000, 16384, PROT_READ) = 0
mprotect(0x22a4000, 8192, PROT_READ) = 0
mprotect(0x2278000, 8192, PROT_READ) = 0
mprotect(0x2254000, 8192, PROT_READ) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2452000
mprotect(0x217a000, 24576, PROT_READ) = 0
mprotect(0x120016000, 8192, PROT_READ)  = 0
mprotect(0x2032000, 8192, PROT_READ) = 0
munmap(0x2024000, 41134)= 0
set_tid_address(0x2450e50)  = 18325
set_robust_list(0x2450e60, 24)  = 0
futex(0x11f813260, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x11f813260, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1,
NULL, 22b0248) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRT_0, {0x2282db0, [], SA_SIGINFO}, NULL, 8, 0) = 0
rt_sigaction(SIGRT_1, {0x2282c70, [], SA_RESTART|SA_SIGINFO},
NULL, 8, 0) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_0 RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=9223372036854775807}) = 0
brk(0)  = 0x12001a000
brk(0x12003c000)= 0x12003c000
mmap(NULL, 8388608, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x2454000
mprotect(0x2454000, 8192, PROT_NONE) = 0
clone(Process 18326 attached
child_stack=0x2c52ae0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x2c532c0, tls=0x2c538e0,
child_tidptr=0x2c532c0) = 18326
[pid 18326] set_robust_list(0x2c532d0, 24 
[pid 18325] futex(0x2c532c0, FUTEX_WAIT, 18326, NULL 
[pid 18326] <... set_robust_list resumed> ) = 0
[pid 18326] mmap(NULL, 134217728, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c54000
[pid 18326] munmap(0x2c54000, 54181888) = 0
[pid 18326] munmap(0x2000800, 12926976) = 0
[pid 18326] mprotect(0x2000400, 139264, PROT_READ|PROT_WRITE) = 0
[pid 18326] futex(0x227a1f4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
[pid 18326] futex(0x12001a08c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
[pid 18326] madvise(0x2454000, 8355840, MADV_DONTNEED) = 0
[pid 18326] exit(0) = ?
[pid 18326] +++ exited with 0 +++
<... futex resumed> )   = 0
futex(0x12001a098, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x12001a05c, FUTEX_WAIT_PRIVATE, 1, NULL

... the test hangs here ...

Uros.

[RFC] Moving DECL_RESULT, DECL_ARGUMENTS, and DECL_SAVED_TREE into struct function

[Jan Hubicka]

Hi,
an attached patch is an experiment on how much work it would take to move
DECL_RESULT and DECL_ARGUMENTS, DECL_SAVED_TREE into struct function.  The
motivation is that middle-end threads them this way already - they are
technically part local declarations and part of the body. Moving those pointer
to struct function should save some memory and make things a bit cleaner.

The patch does only DECL_RESULT and bootstraps but won't pass fortran testsuite
and I did not even look into Ada, yet.

Main problem is that frontends tends to build the return values (and arguments)
separately from body, since that is how code was structured.  I wonder if there
are any reason why this change won't work or if it seems undesirable for some
reason?

Other problem is (ab)use of these fileds by frontends for various reasons.
C++ use result for namespace, obj-C for interfaces. I think we could/should
replace those by FE specific data, but I am not quite certain how to do that.

So any comments?

Honza

Index: c-family/c-ada-spec.c
===
--- c-family/c-ada-spec.c   (revision 211106)
+++ c-family/c-ada-spec.c   (working copy)
@@ -1720,16 +1720,8 @@ dump_ada_template (pretty_printer *buffe
 {
   /* DECL_VINDEX is DECL_TEMPLATE_INSTANTIATIONS in this context.  */
   tree inst = DECL_VINDEX (t);
-  /* DECL_RESULT_FLD is DECL_TEMPLATE_RESULT in this context.  */
-  tree result = DECL_RESULT_FLD (t);
   int num_inst = 0;
 
-  /* Don't look at template declarations declaring something coming from
- another file.  This can occur for template friend declarations.  */
-  if (LOCATION_FILE (decl_sloc (result, false))
-  != LOCATION_FILE (decl_sloc (t, false)))
-return 0;
-
   while (inst && inst != error_mark_node)
 {
   tree types = TREE_PURPOSE (inst);
Index: c-family/cilk.c
===
--- c-family/cilk.c (revision 211106)
+++ c-family/cilk.c (working copy)
@@ -322,12 +322,6 @@ create_cilk_helper_decl (struct wrapper_
  the parent stack frame is stolen.  */
   DECL_UNINLINABLE (fndecl) = 1;
 
-  tree result_decl = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE, 
-void_type_node);
-  DECL_ARTIFICIAL (result_decl) = 0;
-  DECL_IGNORED_P (result_decl) = 1;
-  DECL_CONTEXT (result_decl) = fndecl;
-  DECL_RESULT (fndecl) = result_decl;
   
   return fndecl;
 }
@@ -544,7 +538,14 @@ create_cilk_wrapper_body (tree stmt, str
  (modified) to the wrapped function.  Return the wrapper and modified ARGS 
  to the caller to generate a function call.  */
   fndecl = create_cilk_helper_decl (wd);
-  push_struct_function (fndecl);
+
+  tree result_decl = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE, 
+void_type_node);
+  DECL_ARTIFICIAL (result_decl) = 0;
+  DECL_IGNORED_P (result_decl) = 1;
+  DECL_CONTEXT (result_decl) = fndecl;
+
+  push_struct_function (fndecl, result_decl);
   if (wd->nested && (wd->type == CILK_BLOCK_FOR))
 {
   gcc_assert (TREE_VALUE (wd->arglist) == NULL_TREE);
Index: java/decl.c
===
--- java/decl.c (revision 211106)
+++ java/decl.c (working copy)
@@ -1743,16 +1743,14 @@ tree
 build_result_decl (tree fndecl)
 {
   tree restype = TREE_TYPE (TREE_TYPE (fndecl));
-  tree result = DECL_RESULT (fndecl);
-  if (! result)
-{
-  result = build_decl (DECL_SOURCE_LOCATION (fndecl),
-  RESULT_DECL, NULL_TREE, restype);
-  DECL_ARTIFICIAL (result) = 1;
-  DECL_IGNORED_P (result) = 1;
-  DECL_CONTEXT (result) = fndecl;
-  DECL_RESULT (fndecl) = result;
-}
+  tree result;
+
+  result = build_decl (DECL_SOURCE_LOCATION (fndecl),
+  RESULT_DECL, NULL_TREE, restype);
+  DECL_ARTIFICIAL (result) = 1;
+  DECL_IGNORED_P (result) = 1;
+  DECL_CONTEXT (result) = fndecl;
+
   return result;
 }
 
@@ -1886,7 +1884,7 @@ finish_method (tree fndecl)
   if (DECL_STRUCT_FUNCTION (fndecl))
 set_cfun (DECL_STRUCT_FUNCTION (fndecl));
   else
-allocate_struct_function (fndecl, false);
+allocate_struct_function (fndecl, false, build_result_decl (fndecl));
   cfun->function_end_locus = DECL_FUNCTION_LAST_LINE (fndecl);
 
   /* Defer inlining and expansion to the cgraph optimizers.  */
Index: java/jcf-parse.c
===
--- java/jcf-parse.c(revision 211106)
+++ java/jcf-parse.c(working copy)
@@ -1711,9 +1711,8 @@ java_emit_static_constructor (void)
   tree resdecl = build_decl (input_location,
 RESULT_DECL, NULL_TREE, void_type_node);
   DECL_ARTIFICIAL (resdecl) = 1;
-  DECL_RESULT (decl) = resdecl;
   current_function_decl = decl;
-  allocate_struct_function (decl, false);
+  allocate_struct_function (decl, false, resdecl);
 
   TREE_STATIC (de

[AArch64] Implement movmem for the benefit of inline memcpy

[James Greenhalgh]

Hi,

The move_by_pieces infrastructure performs a copy by repeatedly trying
the largest safe copy it can make. So for a 15-byte copy we might see:

offset   amount  bytes copied
08   0-7
84   8-11
12   2   12-13
14   1   14

However, we can implement a 15-byte copy as so:

offset   amount  bytes copied
08   0-7
78   7-14

Which can prove more efficient for both space and speed.

In this patch we set MOVE_RATIO low to avoid using move_by_pieces, and
implement the movmem pattern name to expand small block copy cases. Note, this
optimization does not apply for -mstrict-align targets, which must continue
copying byte-by-byte.

Setting MOVE_RATIO low in this way causes a few tests to begin failing,
both of these are documented in the test-case as expected to fail for
low MOVE_RATIO targets, which do not allow certain Tree-Level optimizations.

Bootstrapped on aarch64-unknown-linux-gnu with no issues.

OK for trunk?

Thanks,
James

---
gcc/

2014-06-06  James Greenhalgh  

* config/aarch64/aarch64-protos.h (aarch64_expand_movmem): New.
* config/aarch64/aarch64.c (aarch64_move_pointer): New.
(aarch64_progress_pointer): Likewise.
(aarch64_copy_one_part_and_move_pointers): Likewise.
(aarch64_expand_movmen): Likewise.
* config/aarch64/aarch64.h (MOVE_RATIO): Set low.
* config/aarch64/aarch64.md (movmem): New.

gcc/testsuite/

2014-06-06  James Greenhalgh  

* gcc.dg/tree-ssa/pr42585.c: Skip for AArch64.
* gcc.dg/tree-ssa/sra-12.c: Likewise.
diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index 68d488d..c4f75b3 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -180,6 +180,7 @@ bool aarch64_cannot_change_mode_class (enum machine_mode,
 enum aarch64_symbol_type
 aarch64_classify_symbolic_expression (rtx, enum aarch64_symbol_context);
 bool aarch64_constant_address_p (rtx);
+bool aarch64_expand_movmem (rtx *);
 bool aarch64_float_const_zero_rtx_p (rtx);
 bool aarch64_function_arg_regno_p (unsigned);
 bool aarch64_gen_movmemqi (rtx *);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index b26e5f5..0ae21cd 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -9434,6 +9434,164 @@ aarch64_modes_tieable_p (enum machine_mode mode1, enum machine_mode mode2)
   return false;
 }
 
+/* Return a new RTX holding the result of moving POINTER forward by
+   AMOUNT bytes.  */
+
+static rtx
+aarch64_move_pointer (rtx pointer, int amount)
+{
+  rtx next = plus_constant (Pmode, XEXP (pointer, 0), amount);
+
+  return adjust_automodify_address (pointer, GET_MODE (pointer),
+next, amount);
+}
+
+/* Return a new RTX holding the result of moving POINTER forward by the
+   size of the mode it points to.  */
+
+static rtx
+aarch64_progress_pointer (rtx pointer)
+{
+  HOST_WIDE_INT amount = GET_MODE_SIZE (GET_MODE (pointer));
+
+  return aarch64_move_pointer (pointer, amount);
+}
+
+/* Copy one MODE sized block from SRC to DST, then progress SRC and DST by
+   MODE bytes.  */
+
+static void
+aarch64_copy_one_block_and_progress_pointers (rtx *src, rtx *dst,
+	  enum machine_mode mode)
+{
+  rtx reg = gen_reg_rtx (mode);
+
+  /* "Cast" the pointers to the correct mode.  */
+  *src = adjust_address (*src, mode, 0);
+  *dst = adjust_address (*dst, mode, 0);
+  /* Emit the memcpy.  */
+  emit_move_insn (reg, *src);
+  emit_move_insn (*dst, reg);
+  /* Move the pointers forward.  */
+  *src = aarch64_progress_pointer (*src);
+  *dst = aarch64_progress_pointer (*dst);
+}
+
+/* Expand movmem, as if from a __builtin_memcpy.  Return true if
+   we succeed, otherwise return false.  */
+
+bool
+aarch64_expand_movmem (rtx *operands)
+{
+  unsigned int n;
+  rtx dst = operands[0];
+  rtx src = operands[1];
+  rtx base;
+  bool speed_p = !optimize_function_for_size_p (cfun);
+
+  /* When optimizing for size, give a better estimate of the length of a
+ memcpy call, but use the default otherwise.  */
+  unsigned int max_instructions = (speed_p ? 15 : AARCH64_CALL_RATIO) / 2;
+
+  /* We can't do anything smart if the amount to copy is not constant.  */
+  if (!CONST_INT_P (operands[2]))
+return false;
+
+  n = UINTVAL (operands[2]);
+
+  /* Try to keep the number of instructions low.  For cases below 16 bytes we
+ need to make at most two moves.  For cases above 16 bytes it will be one
+ move for each 16 byte chunk, then at most two additional moves.  */
+  if (((n / 16) + (n % 16 ? 2 : 0)) > max_instructions)
+return false;
+
+  base = copy_to_mode_reg (Pmode, XEXP (dst, 0));
+  dst = adjust_automodify_address (dst, VOIDmode, base, 0);
+
+  base = copy_to_mode_reg (Pmode, XEXP (src, 0));
+  src = adjust_automodify_address (src, VOIDmode, base, 0);
+
+  /* Simple cases.  Copy 0-3 bytes, as (if applicable) a 2-byte, then a
+ 1-byte chunk.  */
+  if (n < 4)

[PATCH] default_add_stmt_cost should call target specific builitin_vectorization_cost.

[Bingfeng Mei]

Hi,
I came across this issue a while back. My colleague Paulo Matos asked
and it was agreed that this is a bug. But he forgot to submit a patch.

default_add_stmt_cost should call target specific builtin_vectozriation_cost.
instead of default_builtin_vectorization_cost directly. So if the hook 
TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST is defined, it will use that cost.
Otherwise, it will fall back to default_builtin_vectorization_cost.

Bootstrapped and tested. OK for trunk?

Thanks,
Bingfeng Mei

Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 211281)
+++ gcc/ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+2014-06-05  Bingfeng Mei  
+
+   * targhooks.c (default_add_stmt_cost): Call target specific
+   hook instead of default one.
+
 2014-06-05  Ilya Enkovich  
 
* tree-inline.c (tree_function_versioning): Check DF info existence
Index: gcc/targhooks.c
===
--- gcc/targhooks.c (revision 211281)
+++ gcc/targhooks.c (working copy)
@@ -1073,8 +1073,8 @@ default_add_stmt_cost (void *data, int c
   unsigned retval = 0;
 
   tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;
-  int stmt_cost = default_builtin_vectorization_cost (kind, vectype,
- misalign);
+  int stmt_cost = targetm.vectorize.builtin_vectorization_cost (kind, vectype,
+   misalign);
/* Statements in an inner loop relative to the loop being
   vectorized are weighted more heavily.  The value here is
   arbitrary and could potentially be improved with analysis.  */

Re: [RFC] Moving DECL_RESULT, DECL_ARGUMENTS, and DECL_SAVED_TREE into struct function

[Richard Biener]

On Fri, Jun 6, 2014 at 10:30 AM, Jan Hubicka  wrote:
> Hi,
> an attached patch is an experiment on how much work it would take to move
> DECL_RESULT and DECL_ARGUMENTS, DECL_SAVED_TREE into struct function.  The
> motivation is that middle-end threads them this way already - they are
> technically part local declarations and part of the body. Moving those pointer
> to struct function should save some memory and make things a bit cleaner.
>
> The patch does only DECL_RESULT and bootstraps but won't pass fortran 
> testsuite
> and I did not even look into Ada, yet.
>
> Main problem is that frontends tends to build the return values (and 
> arguments)
> separately from body, since that is how code was structured.  I wonder if 
> there
> are any reason why this change won't work or if it seems undesirable for some
> reason?
>
> Other problem is (ab)use of these fileds by frontends for various reasons.
> C++ use result for namespace, obj-C for interfaces. I think we could/should
> replace those by FE specific data, but I am not quite certain how to do that.

We have decl_lang_specific for FE specific data.

> So any comments?

Well, I think it's a good idea to move stuff out of the decls if it
isn't required
for just declarations but definitions only.

Richard.

> Honza
>
> Index: c-family/c-ada-spec.c
> ===
> --- c-family/c-ada-spec.c   (revision 211106)
> +++ c-family/c-ada-spec.c   (working copy)
> @@ -1720,16 +1720,8 @@ dump_ada_template (pretty_printer *buffe
>  {
>/* DECL_VINDEX is DECL_TEMPLATE_INSTANTIATIONS in this context.  */
>tree inst = DECL_VINDEX (t);
> -  /* DECL_RESULT_FLD is DECL_TEMPLATE_RESULT in this context.  */
> -  tree result = DECL_RESULT_FLD (t);
>int num_inst = 0;
>
> -  /* Don't look at template declarations declaring something coming from
> - another file.  This can occur for template friend declarations.  */
> -  if (LOCATION_FILE (decl_sloc (result, false))
> -  != LOCATION_FILE (decl_sloc (t, false)))
> -return 0;
> -
>while (inst && inst != error_mark_node)
>  {
>tree types = TREE_PURPOSE (inst);
> Index: c-family/cilk.c
> ===
> --- c-family/cilk.c (revision 211106)
> +++ c-family/cilk.c (working copy)
> @@ -322,12 +322,6 @@ create_cilk_helper_decl (struct wrapper_
>   the parent stack frame is stolen.  */
>DECL_UNINLINABLE (fndecl) = 1;
>
> -  tree result_decl = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE,
> -void_type_node);
> -  DECL_ARTIFICIAL (result_decl) = 0;
> -  DECL_IGNORED_P (result_decl) = 1;
> -  DECL_CONTEXT (result_decl) = fndecl;
> -  DECL_RESULT (fndecl) = result_decl;
>
>return fndecl;
>  }
> @@ -544,7 +538,14 @@ create_cilk_wrapper_body (tree stmt, str
>   (modified) to the wrapped function.  Return the wrapper and modified 
> ARGS
>   to the caller to generate a function call.  */
>fndecl = create_cilk_helper_decl (wd);
> -  push_struct_function (fndecl);
> +
> +  tree result_decl = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE,
> +void_type_node);
> +  DECL_ARTIFICIAL (result_decl) = 0;
> +  DECL_IGNORED_P (result_decl) = 1;
> +  DECL_CONTEXT (result_decl) = fndecl;
> +
> +  push_struct_function (fndecl, result_decl);
>if (wd->nested && (wd->type == CILK_BLOCK_FOR))
>  {
>gcc_assert (TREE_VALUE (wd->arglist) == NULL_TREE);
> Index: java/decl.c
> ===
> --- java/decl.c (revision 211106)
> +++ java/decl.c (working copy)
> @@ -1743,16 +1743,14 @@ tree
>  build_result_decl (tree fndecl)
>  {
>tree restype = TREE_TYPE (TREE_TYPE (fndecl));
> -  tree result = DECL_RESULT (fndecl);
> -  if (! result)
> -{
> -  result = build_decl (DECL_SOURCE_LOCATION (fndecl),
> -  RESULT_DECL, NULL_TREE, restype);
> -  DECL_ARTIFICIAL (result) = 1;
> -  DECL_IGNORED_P (result) = 1;
> -  DECL_CONTEXT (result) = fndecl;
> -  DECL_RESULT (fndecl) = result;
> -}
> +  tree result;
> +
> +  result = build_decl (DECL_SOURCE_LOCATION (fndecl),
> +  RESULT_DECL, NULL_TREE, restype);
> +  DECL_ARTIFICIAL (result) = 1;
> +  DECL_IGNORED_P (result) = 1;
> +  DECL_CONTEXT (result) = fndecl;
> +
>return result;
>  }
>
> @@ -1886,7 +1884,7 @@ finish_method (tree fndecl)
>if (DECL_STRUCT_FUNCTION (fndecl))
>  set_cfun (DECL_STRUCT_FUNCTION (fndecl));
>else
> -allocate_struct_function (fndecl, false);
> +allocate_struct_function (fndecl, false, build_result_decl (fndecl));
>cfun->function_end_locus = DECL_FUNCTION_LAST_LINE (fndecl);
>
>/* Defer inlining and expansion to the cgraph optimizers.  */
> Index: java/jcf-parse.c
> ===
> --- java/jcf-parse.c(revision 21

Re: [PATCH, i386, Pointer Bounds Checker 17/x] Pointer bounds constants support

[Ilya Enkovich]

2014-06-04 10:58 GMT+04:00 Jeff Law :
> On 06/02/14 04:25, Ilya Enkovich wrote:
>>
>> Hi,
>>
>> This patch adds support for pointer bounds constants to be used as
>> DECL_INITIAL for constant bounds (like zero bounds).
>>
>> Bootstrapped and tested on linux-x86_64.
>>
>> Thanks,
>> Ilya
>> --
>> gcc/
>>
>> 2014-05-30  Ilya Enkovich  
>>
>> * emit-rtl.c (immed_double_const): Support MODE_POINTER_BOUNDS.
>> (init_emit_once): Build pointer bounds zero constants.
>> * explow.c (trunc_int_for_mode): Likewise.
>> * varpool.c (ctor_for_folding): Do not fold constant
>> bounds vars.
>> * varasm.c (output_constant_pool_2): Support MODE_POINTER_BOUNDS.
>> * config/i386/i386.c (ix86_legitimate_constant_p): Mark
>> bounds constant as not valid.
>
>
> [ ... ]
>
>
>>
>> @@ -5875,6 +5876,11 @@ init_emit_once (void)
>> if (STORE_FLAG_VALUE == 1)
>>   const_tiny_rtx[1][(int) BImode] = const1_rtx;
>>
>> +  for (mode = GET_CLASS_NARROWEST_MODE (MODE_POINTER_BOUNDS);
>> +   mode != VOIDmode;
>> +   mode = GET_MODE_WIDER_MODE (mode))
>> +const_tiny_rtx[0][mode] = immed_double_const (0, 0, mode);
>
> I'm pretty sure GET_CLASS_NARROWEST_MODE should be taking a class, not a
> mode as its argument.  So something is clearly wrong here...

MODE_POINTER_BOUNDS is a class. Modes in this class are BND32mode and BND64mode.

Ilya
>
>
> jeff

Re: libgo patch committed: Merge from revision 18783 of master

[Rainer Orth]

Ian Lance Taylor  writes:

> I have committed a patch to libgo to merge from revision
> 18783:00cce3a34d7e of the master library.  This revision was committed
> January 7.  I picked this revision to merge to because the next revision
> deleted a file that is explicitly merged in by the libgo/merge.sh
> script.
>
> Among other things, this patch changes type descriptors to add a new
> pointer to a zero value.  In gccgo this is implemented as a common
> variable, and that requires some changes to the compiler and a small
> change to go-gcc.cc.

This change introduced many failures on Solaris with /bin/ld, e.g.

FAIL: go.test/test/bom.go -O (test for excess errors)

ld: warning: symbol 'go$zerovalue' has differing sizes:
(file bom.o value=0x8; file 
/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/./libgo/.libs/libgo.so
 value=0x800);
bom.o definition taken and updated with larger size

Rainer

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

Re: [patch] Update catch(...) handlers to deal with __forced_unwind

[Jonathan Wakely]

On 06/06/14 10:27 +0200, Uros Bizjak wrote:

These two tests timeout on alpha-linux-gnu:

FAIL: 30_threads/async/forced_unwind.cc execution test
WARNING: program timed out.
FAIL: 30_threads/packaged_task/forced_unwind.cc execution test
WARNING: program timed out.


Sorry about that, I don't know why.

Does pthread_exit(0) use a __forced_unwind exception on
alpha-linux-gnu? This should tell you ...


#include 
#include 

void* f(void*) {
 try
 {
   pthread_exit(0);
 }
 catch (__cxxabiv1::__forced_unwind const&)
 {
   __builtin_puts("unwind");
   throw;
 }
 catch (...)
 {
   __builtin_puts("something else");
   throw;
 }
}

int main()
{
 pthread_t t;
 pthread_create(&t, 0, f, 0);
 pthread_join(t, 0);
}



[pid 18326] futex(0x227a1f4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
[pid 18326] futex(0x12001a08c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
[pid 18326] madvise(0x2454000, 8355840, MADV_DONTNEED) = 0
[pid 18326] exit(0) = ?
[pid 18326] +++ exited with 0 +++
<... futex resumed> )   = 0
futex(0x12001a098, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x12001a05c, FUTEX_WAIT_PRIVATE, 1, NULL

... the test hangs here ...


Could I get a stack trace of the remaining thread at that point?

Re: [PATCH, i386, Pointer Bounds Checker 18/x] Expand instrumented builtin function calls

[Ilya Enkovich]

2014-06-03 12:46 GMT+04:00 Richard Biener :
> On Mon, Jun 2, 2014 at 4:51 PM, Ilya Enkovich  wrote:
>> Hi,
>>
>> This patch adds support for normal builtin function calls (target ones are 
>> not instrumented).  The basic idea of the patch is to make call expr copy 
>> with no bounds and expand it instead.  If expr is going to be emitted as a 
>> function call then original instrumented expr takes place.  Handle string 
>> function separately because they are of high interest for the checker.
>
> It seems to be this should be user-controllable (always expand builtins with
> bounds as calls, or not), rather than deciding what is of interest yourself.

User has no idea what can be transformed into a builtin call. He may
pragmas in his source code to control instrumentation. Compiler just
tries to cover as much code as it can but reasonable compromise with
performance should be made.

>
> From a high-level perspective the expansion path doing inline expansion
> should be separated from that expanding as a call (or expanding as a
> different call).  I don't like that building of yet another GENERIC call expr
> in this code ... it goes very much backwards of the idea that we should
> expand from the GIMPLE representation.  You are making such transition
> even harder.
>
> Can't you do that frobbing from cfgexpand.c:expand_call_stmt instead 
> (please!)?

I need both instrumented and not instrumented versions of call in
expand_builtin, so I do not see how it may be handled in
expand_call_stmt.

Ilya
>
> Thanks,
> Richard.
>
>> Bootstrapped and tested on linux-x86_64.
>>
>> Thanks,
>> Ilya
>> --
>> gcc/
>>
>> 2014-06-02  Ilya Enkovich  
>>
>> * builtins.c: Include rtl-chkp.h, tree-chkp.h.
>> (expand_builtin_mempcpy_args): Add orig exp as argument.
>> Support BUILT_IN_CHKP_MEMPCPY_NOBND_NOCHK.
>> (expand_builtin_mempcpy): Adjust expand_builtin_mempcpy_args call.
>> (expand_builtin_stpcpy): Likewise.
>> (expand_builtin_memset_args): Support 
>> BUILT_IN_CHKP_MEMSET_NOBND_NOCHK.
>> (std_expand_builtin_va_start): Initialize bounds for va_list.
>> (expand_builtin): Support instrumented calls.
>>
>>
>> diff --git a/gcc/builtins.c b/gcc/builtins.c
>> index 7357124..c0140e1 100644
>> --- a/gcc/builtins.c
>> +++ b/gcc/builtins.c
>> @@ -59,6 +59,8 @@ along with GCC; see the file COPYING3.  If not see
>>  #include "builtins.h"
>>  #include "ubsan.h"
>>  #include "cilk.h"
>> +#include "tree-chkp.h"
>> +#include "rtl-chkp.h"
>>
>>
>>  static tree do_mpc_arg1 (tree, tree, int (*)(mpc_ptr, mpc_srcptr, 
>> mpc_rnd_t));
>> @@ -124,7 +126,7 @@ static rtx builtin_memcpy_read_str (void *, 
>> HOST_WIDE_INT, enum machine_mode);
>>  static rtx expand_builtin_memcpy (tree, rtx);
>>  static rtx expand_builtin_mempcpy (tree, rtx, enum machine_mode);
>>  static rtx expand_builtin_mempcpy_args (tree, tree, tree, rtx,
>> -   enum machine_mode, int);
>> +   enum machine_mode, int, tree);
>>  static rtx expand_builtin_strcpy (tree, rtx);
>>  static rtx expand_builtin_strcpy_args (tree, tree, rtx);
>>  static rtx expand_builtin_stpcpy (tree, rtx, enum machine_mode);
>> @@ -3284,7 +3286,8 @@ expand_builtin_mempcpy (tree exp, rtx target, enum 
>> machine_mode mode)
>>tree src = CALL_EXPR_ARG (exp, 1);
>>tree len = CALL_EXPR_ARG (exp, 2);
>>return expand_builtin_mempcpy_args (dest, src, len,
>> - target, mode, /*endp=*/ 1);
>> + target, mode, /*endp=*/ 1,
>> + exp);
>>  }
>>  }
>>
>> @@ -3296,10 +3299,23 @@ expand_builtin_mempcpy (tree exp, rtx target, enum 
>> machine_mode mode)
>>
>>  static rtx
>>  expand_builtin_mempcpy_args (tree dest, tree src, tree len,
>> -rtx target, enum machine_mode mode, int endp)
>> +rtx target, enum machine_mode mode, int endp,
>> +tree orig_exp)
>>  {
>> +  tree fndecl = get_callee_fndecl (orig_exp);
>> +
>>  /* If return value is ignored, transform mempcpy into memcpy.  */
>> -  if (target == const0_rtx && builtin_decl_implicit_p (BUILT_IN_MEMCPY))
>> +  if (target == const0_rtx
>> +  && DECL_FUNCTION_CODE (fndecl) == BUILT_IN_CHKP_MEMPCPY_NOBND_NOCHK
>> +  && builtin_decl_implicit_p (BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK))
>> +{
>> +  tree fn = builtin_decl_implicit (BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK);
>> +  tree result = build_call_nofold_loc (UNKNOWN_LOCATION, fn, 3,
>> +  dest, src, len);
>> +  return expand_expr (result, target, mode, EXPAND_NORMAL);
>> +}
>> +  else if (target == const0_rtx
>> +  && builtin_decl_implicit_p (BUILT_IN_MEMCPY))
>>  {
>>tree fn = builtin_decl_implicit (BUILT_IN_MEMCPY);
>>tree result = build_call_nofold_loc (UNKNOWN_LOCATION,

Re: [PATCH] default_add_stmt_cost should call target specific builitin_vectorization_cost.

[Richard Biener]

On Fri, Jun 6, 2014 at 10:52 AM, Bingfeng Mei  wrote:
> Hi,
> I came across this issue a while back. My colleague Paulo Matos asked
> and it was agreed that this is a bug. But he forgot to submit a patch.
>
> default_add_stmt_cost should call target specific builtin_vectozriation_cost.
> instead of default_builtin_vectorization_cost directly. So if the hook
> TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST is defined, it will use that cost.
> Otherwise, it will fall back to default_builtin_vectorization_cost.
>
> Bootstrapped and tested. OK for trunk?

Ok.  (though that target hook should be removed at some point)

Thanks,
Richard.

> Thanks,
> Bingfeng Mei
>
> Index: gcc/ChangeLog
> ===
> --- gcc/ChangeLog   (revision 211281)
> +++ gcc/ChangeLog   (working copy)
> @@ -1,3 +1,8 @@
> +2014-06-05  Bingfeng Mei  
> +
> +   * targhooks.c (default_add_stmt_cost): Call target specific
> +   hook instead of default one.
> +
>  2014-06-05  Ilya Enkovich  
>
> * tree-inline.c (tree_function_versioning): Check DF info existence
> Index: gcc/targhooks.c
> ===
> --- gcc/targhooks.c (revision 211281)
> +++ gcc/targhooks.c (working copy)
> @@ -1073,8 +1073,8 @@ default_add_stmt_cost (void *data, int c
>unsigned retval = 0;
>
>tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;
> -  int stmt_cost = default_builtin_vectorization_cost (kind, vectype,
> - misalign);
> +  int stmt_cost = targetm.vectorize.builtin_vectorization_cost (kind, 
> vectype,
> +   misalign);
> /* Statements in an inner loop relative to the loop being
>vectorized are weighted more heavily.  The value here is
>arbitrary and could potentially be improved with analysis.  */

RE: [PATCH] default_add_stmt_cost should call target specific builitin_vectorization_cost.

[Bingfeng Mei]

Thanks. Committed.

Bingfeng

-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com] 
Sent: 06 June 2014 10:40
To: Bingfeng Mei
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] default_add_stmt_cost should call target specific 
builitin_vectorization_cost.

On Fri, Jun 6, 2014 at 10:52 AM, Bingfeng Mei  wrote:
> Hi,
> I came across this issue a while back. My colleague Paulo Matos asked
> and it was agreed that this is a bug. But he forgot to submit a patch.
>
> default_add_stmt_cost should call target specific builtin_vectozriation_cost.
> instead of default_builtin_vectorization_cost directly. So if the hook
> TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST is defined, it will use that cost.
> Otherwise, it will fall back to default_builtin_vectorization_cost.
>
> Bootstrapped and tested. OK for trunk?

Ok.  (though that target hook should be removed at some point)

Thanks,
Richard.

> Thanks,
> Bingfeng Mei
>
> Index: gcc/ChangeLog
> ===
> --- gcc/ChangeLog   (revision 211281)
> +++ gcc/ChangeLog   (working copy)
> @@ -1,3 +1,8 @@
> +2014-06-05  Bingfeng Mei  
> +
> +   * targhooks.c (default_add_stmt_cost): Call target specific
> +   hook instead of default one.
> +
>  2014-06-05  Ilya Enkovich  
>
> * tree-inline.c (tree_function_versioning): Check DF info existence
> Index: gcc/targhooks.c
> ===
> --- gcc/targhooks.c (revision 211281)
> +++ gcc/targhooks.c (working copy)
> @@ -1073,8 +1073,8 @@ default_add_stmt_cost (void *data, int c
>unsigned retval = 0;
>
>tree vectype = stmt_info ? stmt_vectype (stmt_info) : NULL_TREE;
> -  int stmt_cost = default_builtin_vectorization_cost (kind, vectype,
> - misalign);
> +  int stmt_cost = targetm.vectorize.builtin_vectorization_cost (kind, 
> vectype,
> +   misalign);
> /* Statements in an inner loop relative to the loop being
>vectorized are weighted more heavily.  The value here is
>arbitrary and could potentially be improved with analysis.  */

Re: [PATCH, Pointer Bounds Checker 23/x] Function split

[Ilya Enkovich]

2014-06-04 11:15 GMT+04:00 Jeff Law :
> On 06/03/14 01:10, Ilya Enkovich wrote:
>>
>> Hi,
>>
>> This patch does not allow splitting in case bounds are returned until
>> retutrned bounds are supported.  It also propagates instrumentation marks
>> for generated call and function.
>>
>> Bootstrapped and tested on linux-x86_64.
>>
>> Thanks,
>> Ilya
>> --
>> gcc/
>>
>> 2014-06-03  Ilya Enkovich  
>>
>> * ipa-split.c: Include tree-chkp.h.
>> (consider_split): Do not split when return bounds.
>> (split_function): Propagate Pointer Bounds Checker
>> instrumentation marks.
>
> It's a hack.  There's no reason we can't support this.  So I'll approve on
> the condition that you do look at removing this limitation in the future.

I looked into it and did not find an easy way to fix damaged return.
Will definitely work more on this later. Any help from knowledgeable
person (Jan Hubicka?) would be great here.

Ilya
>
> jeff
>

Re: [AArch64] Implement movmem for the benefit of inline memcpy

[Richard Earnshaw]

On 06/06/14 09:50, James Greenhalgh wrote:
> 
> Hi,
> 
> The move_by_pieces infrastructure performs a copy by repeatedly trying
> the largest safe copy it can make. So for a 15-byte copy we might see:
> 
> offset   amount  bytes copied
> 08   0-7
> 84   8-11
> 12   2   12-13
> 14   1   14
> 
> However, we can implement a 15-byte copy as so:
> 
> offset   amount  bytes copied
> 08   0-7
> 78   7-14
> 
> Which can prove more efficient for both space and speed.
> 
> In this patch we set MOVE_RATIO low to avoid using move_by_pieces, and
> implement the movmem pattern name to expand small block copy cases. Note, this
> optimization does not apply for -mstrict-align targets, which must continue
> copying byte-by-byte.
> 
> Setting MOVE_RATIO low in this way causes a few tests to begin failing,
> both of these are documented in the test-case as expected to fail for
> low MOVE_RATIO targets, which do not allow certain Tree-Level optimizations.
> 
> Bootstrapped on aarch64-unknown-linux-gnu with no issues.
> 
> OK for trunk?
> 

This is OK.

Hmm, I notice sra-12 fails on ARM as well.  Is that for the same reason?
 If so, perhaps you could prepare a patch for that as well (consider it
pre-approved).

R.

> Thanks,
> James
> 
> ---
> gcc/
> 
> 2014-06-06  James Greenhalgh  
> 
>   * config/aarch64/aarch64-protos.h (aarch64_expand_movmem): New.
>   * config/aarch64/aarch64.c (aarch64_move_pointer): New.
>   (aarch64_progress_pointer): Likewise.
>   (aarch64_copy_one_part_and_move_pointers): Likewise.
>   (aarch64_expand_movmen): Likewise.
>   * config/aarch64/aarch64.h (MOVE_RATIO): Set low.
>   * config/aarch64/aarch64.md (movmem): New.
> 
> gcc/testsuite/
> 
> 2014-06-06  James Greenhalgh  
> 
>   * gcc.dg/tree-ssa/pr42585.c: Skip for AArch64.
>   * gcc.dg/tree-ssa/sra-12.c: Likewise.
> 
> 
> 0001-AArch64-Implement-movmem-for-the-benefit-of-inline-m.patch
> 
> 
> diff --git a/gcc/config/aarch64/aarch64-protos.h 
> b/gcc/config/aarch64/aarch64-protos.h
> index 68d488d..c4f75b3 100644
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++ b/gcc/config/aarch64/aarch64-protos.h
> @@ -180,6 +180,7 @@ bool aarch64_cannot_change_mode_class (enum machine_mode,
>  enum aarch64_symbol_type
>  aarch64_classify_symbolic_expression (rtx, enum aarch64_symbol_context);
>  bool aarch64_constant_address_p (rtx);
> +bool aarch64_expand_movmem (rtx *);
>  bool aarch64_float_const_zero_rtx_p (rtx);
>  bool aarch64_function_arg_regno_p (unsigned);
>  bool aarch64_gen_movmemqi (rtx *);
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index b26e5f5..0ae21cd 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -9434,6 +9434,164 @@ aarch64_modes_tieable_p (enum machine_mode mode1, 
> enum machine_mode mode2)
>return false;
>  }
>  
> +/* Return a new RTX holding the result of moving POINTER forward by
> +   AMOUNT bytes.  */
> +
> +static rtx
> +aarch64_move_pointer (rtx pointer, int amount)
> +{
> +  rtx next = plus_constant (Pmode, XEXP (pointer, 0), amount);
> +
> +  return adjust_automodify_address (pointer, GET_MODE (pointer),
> + next, amount);
> +}
> +
> +/* Return a new RTX holding the result of moving POINTER forward by the
> +   size of the mode it points to.  */
> +
> +static rtx
> +aarch64_progress_pointer (rtx pointer)
> +{
> +  HOST_WIDE_INT amount = GET_MODE_SIZE (GET_MODE (pointer));
> +
> +  return aarch64_move_pointer (pointer, amount);
> +}
> +
> +/* Copy one MODE sized block from SRC to DST, then progress SRC and DST by
> +   MODE bytes.  */
> +
> +static void
> +aarch64_copy_one_block_and_progress_pointers (rtx *src, rtx *dst,
> +   enum machine_mode mode)
> +{
> +  rtx reg = gen_reg_rtx (mode);
> +
> +  /* "Cast" the pointers to the correct mode.  */
> +  *src = adjust_address (*src, mode, 0);
> +  *dst = adjust_address (*dst, mode, 0);
> +  /* Emit the memcpy.  */
> +  emit_move_insn (reg, *src);
> +  emit_move_insn (*dst, reg);
> +  /* Move the pointers forward.  */
> +  *src = aarch64_progress_pointer (*src);
> +  *dst = aarch64_progress_pointer (*dst);
> +}
> +
> +/* Expand movmem, as if from a __builtin_memcpy.  Return true if
> +   we succeed, otherwise return false.  */
> +
> +bool
> +aarch64_expand_movmem (rtx *operands)
> +{
> +  unsigned int n;
> +  rtx dst = operands[0];
> +  rtx src = operands[1];
> +  rtx base;
> +  bool speed_p = !optimize_function_for_size_p (cfun);
> +
> +  /* When optimizing for size, give a better estimate of the length of a
> + memcpy call, but use the default otherwise.  */
> +  unsigned int max_instructions = (speed_p ? 15 : AARCH64_CALL_RATIO) / 2;
> +
> +  /* We can't do anything smart if the amount to copy is not constant.  */
> +  if (!CONST_INT_P (operands[2]))
> +return false;
> +
> +  n = UINTVAL (operands[2]);
> +
> +  /* Try to keep the 

Re: [patch] Update catch(...) handlers to deal with __forced_unwind

[Uros Bizjak]

On Fri, Jun 6, 2014 at 11:19 AM, Jonathan Wakely  wrote:
> On 06/06/14 10:27 +0200, Uros Bizjak wrote:
>>
>> These two tests timeout on alpha-linux-gnu:
>>
>> FAIL: 30_threads/async/forced_unwind.cc execution test
>> WARNING: program timed out.
>> FAIL: 30_threads/packaged_task/forced_unwind.cc execution test
>> WARNING: program timed out.
>
>
> Sorry about that, I don't know why.
>
> Does pthread_exit(0) use a __forced_unwind exception on
> alpha-linux-gnu? This should tell you ...
>
>
> #include 
> #include 
>
> void* f(void*) {
>  try
>  {
>pthread_exit(0);
>  }
>  catch (__cxxabiv1::__forced_unwind const&)
>  {
>__builtin_puts("unwind");
>throw;
>  }
>  catch (...)
>  {
>__builtin_puts("something else");
>throw;
>  }
> }
>
> int main()
> {
>  pthread_t t;
>  pthread_create(&t, 0, f, 0);
>  pthread_join(t, 0);
>
> }

Strange, I don't get anything ...

$ g++ -lpthread pt.C
$ ./a.out
$
$ g++ --version
g++ (Gentoo 4.8.2 p1.3r1, pie-0.5.8r1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Maybe Richard knows why...

>> [pid 18326] futex(0x227a1f4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
>> [pid 18326] futex(0x12001a08c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
>> [pid 18326] madvise(0x2454000, 8355840, MADV_DONTNEED) = 0
>> [pid 18326] exit(0) = ?
>> [pid 18326] +++ exited with 0 +++
>> <... futex resumed> )   = 0
>> futex(0x12001a098, FUTEX_WAKE_PRIVATE, 2147483647) = 0
>> futex(0x12001a05c, FUTEX_WAIT_PRIVATE, 1, NULL
>>
>> ... the test hangs here ...
>
>
> Could I get a stack trace of the remaining thread at that point?

Reading symbols from ./forced_unwind.exe...done.
(gdb) r
Starting program: /space/homedirs/uros/test/forced_unwind.exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0x2c531f0 (LWP 22587)]
[Thread 0x2c531f0 (LWP 22587) exited]
^C
Program received signal SIGINT, Interrupt.
0x02289ca4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
(gdb) bt
#0  0x02289ca4 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1  0x021279ec in
std::condition_variable::wait(std::unique_lock&) ()
   from /usr/lib/gcc/alpha-unknown-linux-gnu/4.8.2/libstdc++.so.6
#2  0x000120001a80 in
wait > (__p=...,
__lock=..., this=0x12001a058)
at 
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/include/condition_variable:98
#3  wait (this=0x12001a020) at
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/include/future:323
#4  _M_get_result (this=0x11fc8f190) at
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/include/future:618
#5  get (this=0x11fc8f190) at
/home/uros/gcc-build/alphaev68-unknown-linux-gnu/libstdc++-v3/include/future:783
#6  main () at 
/home/uros/gcc-svn/trunk/libstdc++-v3/testsuite/30_threads/async/forced_unwind.cc:38
(gdb)

Uros.

RE: [PATCH] Fix PR54733 Optimize endian independent load/store

[Thomas Preud'homme]

> From: Richard Biener [mailto:richard.guent...@gmail.com]
> On Wed, Jun 4, 2014 at 9:04 AM, Thomas Preud'homme
>  wrote:
> >
> > Great. What about you Andreas? Does it work fine for you? If yes, is this ok
> for trunk?
> 
> Ok.
> 
> Thanks,
> Richard.

Commited since I got positive feedback from Christophe Lyon and
Rainer (on PR61320).

Best regards,

Thomas

Re: [RFC] optimize x - y cmp 0 with undefined overflow

[Eric Botcazou]

> So when computing a range for z in
> 
>  z = y - x;
> 
> with x = [-INF, y - 1] and y = [x + 1, +INF] (deduced from !(x >= y)) we
> fail to do sth sensible with [y, y] - [-INF, y - 1] or [x + 1, +INF] - [x,
> x] but we do sth with [x + 1, +INF] - [-INF, x]?  That seems odd to me.
> 
> With the patch we compute z to [1, +INF(OVF)]

Right, and note the overflow.

> Going the [x + 1, +INF] - [x,x] path first we obtain
> 
>   [1, -x + INF]
> 
> which fails the sanity checking
> 
>   cmp = compare_values (min, max);
>   if (cmp == -2 || cmp == 1)
> {
>   /* If the new range has its limits swapped around (MIN > MAX),
>  then the operation caused one of them to wrap around, mark
>  the new range VARYING.  */
>   set_value_range_to_varying (vr);
> }
>   else
> set_value_range (vr, type, min, max, NULL);
> 
> but clearly the same reasoning you can apply that makes trying
> with [-INF, x] valid (it's just enlarging the range) can be applied
> here, too, when computing +INF - x for the upper bound.  We can
> safely increase that to +INF making the range valid for the above
> test.

I don't think we can enlarge to +INF because -x + INF can overflow, we can 
only enlarge to +INF(OVF).

> But I wonder what code path in the routine still relies on that sanity
> checking to produce a valid result (so I'd rather try removing it, or
> taking uncomparable bounds as a valid range).
> 
> Simplest would be to simply do
> 
>   set_value_range (vr, type, min, max, NULL);
>   return;
> 
> and be done with that in the plus/minus handling.  With that the
> testcase optimizes ok for me.

With [1, -x + INF] as the resulting range?  But it can be bogus if x is itself 
equal to +INF (unlike the input range [x + 1, +INF] which is always correct)
so this doesn't look valid to me.  I don't see how we can get away without a 
+INF(OVF) here, but I can compute it in extract_range_from_binary_expr_1 if 
you prefer and try only [op0,op0] and [op1,op1].

-- 
Eric Botcazou

[PATCH] Fix for PR 61422

[Marat Zakirov]

Hi all,

Here's a patch for PR 61422
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61422). 

It fixes false positive on 16 byte access in ffmpeg standard library opus
file NLSF_del_dec_quant.c.  

Reg. tested on x64.

--Marat


PR61422.diff
Description: Binary data

[C++ Patch] PR 60184

[Paolo Carlini]

Hi,

this rejects-valid issue, as submitted, has only the testcase:

union Test {
  static constexpr int kConstant = 10;
};

which seems easy to handle by adjusting check_field_decls. While doing 
that, I also noticed that the same piece of C++98 which went away in 
C++11, thus allowing static members in unions, also mentioned 
reference-types, which therefore, should be now also allowed (current 
ICC agrees, current clang disagrees). Tested x86_64-linux.


Thanks,
Paolo.


/cp
2014-06-06  Paolo Carlini  

PR c++/60184
* class.c (check_field_decls): In C++11 mode do not reject constexpr
static members and reference-type members of unions.

/testsuite
2014-06-06  Paolo Carlini  

PR c++/60184
* g++.dg/cpp0x/constexpr-union6.C: New.
* g++.dg/cpp0x/union6.C: Likewise.
* g++.dg/init/ref14.C: Adjust.
* g++.dg/init/union1.C: Likewise.
Index: cp/class.c
===
--- cp/class.c  (revision 211309)
+++ cp/class.c  (working copy)
@@ -3480,21 +3480,25 @@ check_field_decls (tree t, tree *access_decls,
   /* When this goes into scope, it will be a non-local reference.  */
   DECL_NONLOCAL (x) = 1;
 
-  if (TREE_CODE (t) == UNION_TYPE)
+  if (TREE_CODE (t) == UNION_TYPE
+ && cxx_dialect < cxx11)
{
- /* [class.union]
+ /* [class.union] (C++98)
 
 If a union contains a static data member, or a member of
-reference type, the program is ill-formed.  */
+reference type, the program is ill-formed.
+
+In C++11 this limitation doesn't exist anymore.  */
  if (VAR_P (x))
{
- error ("%q+D may not be static because it is a member of a 
union", x);
+ error ("in C++98 %q+D may not be static because it is "
+"a member of a union", x);
  continue;
}
  if (TREE_CODE (type) == REFERENCE_TYPE)
{
- error ("%q+D may not have reference type %qT because"
-" it is a member of a union",
+ error ("in C++98 %q+D may not have reference type %qT "
+"because it is a member of a union",
 x, type);
  continue;
}
Index: testsuite/g++.dg/cpp0x/constexpr-union6.C
===
--- testsuite/g++.dg/cpp0x/constexpr-union6.C   (revision 0)
+++ testsuite/g++.dg/cpp0x/constexpr-union6.C   (working copy)
@@ -0,0 +1,10 @@
+// PR c++/60184
+// { dg-do compile { target c++11 } }
+
+union Test1 {
+  static constexpr int kConstant = 10;
+};
+
+union Test2 {
+  static constexpr const int& kConstant = Test1::kConstant;
+};
Index: testsuite/g++.dg/cpp0x/union6.C
===
--- testsuite/g++.dg/cpp0x/union6.C (revision 0)
+++ testsuite/g++.dg/cpp0x/union6.C (working copy)
@@ -0,0 +1,20 @@
+// PR c++/60184
+// { dg-do compile { target c++11 } }
+
+union Test1 {
+  static int kConstant;
+};
+
+union Test2 {
+  static const int kConstant;
+};
+
+const int Test2::kConstant = 10;
+
+union Test3 {
+  int& kConstant;
+};
+
+union Test4 {
+  const int& kConstant = 10;
+};
Index: testsuite/g++.dg/init/ref14.C
===
--- testsuite/g++.dg/init/ref14.C   (revision 211309)
+++ testsuite/g++.dg/init/ref14.C   (working copy)
@@ -4,7 +4,7 @@
 
 union A
 {
-  int &i; // { dg-error "may not have reference type" }
+  int &i; // { dg-error "may not have reference type" "" { target { ! c++11 } 
} }
 };
 
 void foo()
Index: testsuite/g++.dg/init/union1.C
===
--- testsuite/g++.dg/init/union1.C  (revision 211309)
+++ testsuite/g++.dg/init/union1.C  (working copy)
@@ -1,5 +1,5 @@
 // PR c++/14401
 
 union U {
-  int& i; // { dg-error "" }
+  int& i; // { dg-error "reference type" "" { target { ! c++11 } } }
 };

Re: [PATCH 4/7] Break up determine_known_aggregate_parts

[Martin Jambor]

On Mon, May 26, 2014 at 02:54:17AM +0200, Jan Hubicka wrote:
> > Hi,
> > 
> > the main purpose of this patch is to break up function
> > determine_known_aggregate_parts so that the next patch can use the
> > standalone bits and to make the changes slightly easier for review.
> > 
> > However, this patch also removes some of the offset checks which Honza
> > correctly thought superfluous and even possibly filtering out useful
> > information.
> >  
> > Bootstrapped and tested and LTO-bootstrapped on x86_64-linux.
> > OK for trunk after the preceeding patches get in?
> > 
> > Thanks,
> > 
> > Martin
> > 
> > 
> > 2014-02-19  Martin Jambor  
> > 
> > * ipa-prop.c (get_place_in_agg_contents_list): New function.
> > (build_agg_jump_func_from_list): Likewise.
> > (determine_known_aggregate_parts): Renamed to
> > determine_locally_known_aggregate_parts.  Moved some functionality
> > to the two functions above, removed bound checks.
> 
> This is OK.
> Does it depend on part 4?
> 

No, it does not.  I have re-tested the new order of the patches and
committed this one.

Thanks,

Martin

RE: [PATCH][MIPS] Implement O32 FPXX ABI (GCC)

[Matthew Fortune]

Richard Sandiford  writes:
> Matthew Fortune  writes: 
> > MIPSr6 only supports 64-bit registers which naturally leads to needing
> > -mfp64. MIPSr6 does however also support a single-precision only
> variant.
> >
> > For a single purpose native toolchain then --with-fp=64 can be used
> xor
> > --with-fpu=single to get the desired tools.
> 
> Hmm, does that really mean that an FPU that only implements S/W-format
> instructions must still have 64-bit registers?  And are MTHC1 and MFHC1

No, the single-precision only is 32-bit registers as you would assume.

> therefore always supported for single-float-only FPUs?  The r6
> documentation
> I downloaded made it sound like 32-bit FPUs were still allowed for
> S/W-only FPUs but that 64-bit FPUs are required if D/L-format
> instructions are supported.
> 
> Or is this more a single-precision+MSA thing?

No it is me overcomplicating things. We can deal with it as part of the
R6 patch. I have however modified the mti vendor specs to infer -mfpxx
for specific architectures rather than for everything other than mips1
to make it ready for R6.

> (Can't really respond to the later specs stuff without understanding
> this part first.)
> 
> >> >> >> > diff --git a/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
> >> >> >> b/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
> >> >> >> > new file mode 100644
> >> >> >> > index 000..f47cdda
> >> >> >> > --- /dev/null
> >> >> >> > +++ b/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
> >> >> >> > @@ -0,0 +1,21 @@
> >> >> >> > +/* Check that we handle call-clobbered FPRs correctly.  */
> >> >> >> > +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { ""
> }
> >> } */
> >> >> >> > +/* { dg-options "-mabi=32 -modd-spreg -mfp32 -ffixed-f0 -
> >> ffixed-f1 -
> >> >> >> ffixed-f2 -ffixed-f3 -ffixed-f4 -ffixed-f5 -ffixed-f6 -ffixed-
> f7 -
> >> >> ffixed-f8
> >> >> >> -ffixed-f9 -ffixed-f10 -ffixed-f11 -ffixed-f12 -ffixed-f13 -
> >> ffixed-f14 -
> >> >> >> ffixed-f15 -ffixed-f16 -ffixed-f17 -ffixed-f18 -ffixed-f19 -
> >> ffixed-f20 -
> >> >> >> ffixed-f22 -ffixed-f24 -ffixed-f26 -ffixed-f28 -ffixed-f30" }
> */
> >> >> >> > +
> >> >> >> > +void bar (void);
> >> >> >> > +float a;
> >> >> >> > +float
> >> >> >> > +foo ()
> >> >> >> > +{
> >> >> >> > +  float b = a + 1.0f;
> >> >> >> > +  bar();
> >> >> >> > +  return b;
> >> >> >> > +}
> >> >> >> > +/* { dg-final { scan-assembler-times "lwc1" 2 } } */
> >> >> >> > +/* { dg-final { scan-assembler-not "swc1" } } */
> >> >> >> > +/* { dg-final { scan-assembler-times "sdc1" 2 } } */
> >> >> >> > +/* { dg-final { scan-assembler-not "mtc" } } */
> >> >> >> > +/* { dg-final { scan-assembler-not "mfc" } } */
> >> >> >> > +/* { dg-final { scan-assembler-not "mthc" } } */
> >> >> >> > +/* { dg-final { scan-assembler-not "mfhc" } } */
> >> >> >>
> >> >> >> Why require sdc1 here?  Would Chao-Ying's patch make this use
> SWC1
> >> and
> >> >> LWC1
> >> >> >> exclusively?
> >> >> >
> >> >> > The SDC1 instructions are for callee-saved registers. I'll add
> the
> >> >> > check for two corresponding LDC1 instructions in the epilogue
> >> though
> >> >> > since I've noticed them being missing.
> >> >>
> >> >> I'm probably being dense, sorry, but why is SDC1 needed for -mfp32
> >> >> -modd-spreg?  Can't we just save and restore the odd register?
> >> >> That's technically more correct too, since we shouldn't really
> touch
> >> >> -ffixed registers.
> >> >
> >> > You are correct and I am/was aware of this...
> >> >
> >> > GCC is saving too much of the callee-saved registers when single-
> >> precision
> >> > values are live in them but this is historic behaviour. The code
> which
> >> > controls this is very complex and I'd be worried about breaking it.
> >> The
> >> > fix would be invasive as all the logic is honed towards the notion
> of
> >> > 64-bit callee-saved registers.
> >>
> >> But that's because it was written before separate odd spregs came
> along.
> >> I'm not convinced the situation is as bad as you say.
> >>
> >> > One thing to say is that this test is
> >> > a very aggressive test of ABI not normal compiler behaviour.
> Normally
> >> > an even-numbered callee-saved register would be used first followed
> by
> >> the
> >> > odd meaning that it is rare to only use the odd register. That
> flips
> >> the
> >> > problem round to single precision data in even registers...
> >> >
> >> > I believe that prior to mips32 introducing odd-numbered single-
> >> precision
> >> > registers then GCC will have been saving and restoring using
> sdc1/ldc1
> >> > for even-numbered registers regardless of whether they are used for
> >> > single or double precision data (for mips1 it also will do pairs of
> >> > lwc1/swc1).
> >>
> >> Sure.  And saving and restoring both using LDC1 and SDC1 is still
> >> the right thing to do if both registers are clobbered.  But if only
> >> one is clobbered then we should save just that.  It's really just
> >> the same principle as Chao-ying's patch, but applied t

RE: [PATCH+1][MIPS] Implement O32 FPXX ABI (GCC)

[Matthew Fortune]

Hi Richard,

I've been working through the debug issues for O32 FPXX and O32 FP64 and have
identified some things to resolve along with proposed fixes...

What to do with debug info for double precision registers and the O32 FPXX
ABI? The choices are:
1) Do what O32 FP32 does and represent 8 byte values in two DW_OP_pieces
   referring to the relevant registers.
2) Do what O32 FP64 does and represent 8 byte values in a single register
3) Do a hybrid where 8-byte values sit in a single DW_OP_pieces.

I'm tentatively swayed to (3) as it is a slightly unusual construct that means
we should have better scope to detect it and do special handling. I've
implemented that in the patch below but am still not sure. My next choice is (1)
as it means there would only be special handling when debugging an O32 FP64
program with FPXX modules rather than both O32 FP32 and O32 FP64.

How to ensure unwinding will work when passing through functions with differing
ABI variants? There isn't much room for debate here as we simply have to
continue using the unwind table format as used in O32 FP32. This represents
32 32-bit floating point registers. A description of how O32 FP64 is modified to
cope with this is on the O32 FR wiki page:

https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#8._Re-definition_of_the_-mabi.3D32_-mfp64_ABI

Copied here for archive
===
Changes to O32 FP64:

* 6 double-precision callee-save registers ($f20 to $f30 evens). This used to be
  12 double-precision registers.
* GNU ABI extensions for returning _Complex float and _Complex double are
  redefined to return the two components in $f0 and $f2 instead of $f0 and $f1.
* The size of registers 32->63, which represent floating-point registers, in
  dwarf unwinding tables is set to 4-byte instead of the more natural choice of
  8-byte. This is required to ensure all ABI variants which can interlink have a
  consistent view of unwind information. Unwind registers 32-63 are conceptually
  defined to represent the low and high 32-bits of a double precision value in
  even numbered registers. Register 32 is lo32($f0) and register 33 is 
hi32($f0).
  The odd-numbered 64-bit floating point registers for O32 FP64 are not
  represented in frame unwind information, this is OK because none of them are
  callee-saved. When saving or restoring a 64-bit callee-saved register two CFI
  directives must be emitted, one to represent the mapping for the lo32 frame
  register and one for the hi32 frame register.
===

I have modified the --with-fp option to be --with-fp-32 where the -32 
corresponds
to the -32 found in --with-arch-32 option. This is to support building a simple
toolchain with one 64-bit ABI and one 32-bit ABI where the FP ABI for the 32-bit
ABI can be set without affecting the 64-bit ABI.

--with-arch-64=mips3 --with-arch-32=mips2 --with-fp-32=xx

"gcc -mabi=64" then implies "-mips3 -mgp64 -mfp64"
"gcc" then implies "-mips2 -mgp32 -mfpxx"

Finally I have had to add ASM_SPECs to pass through -mhard-float, -msoft-float,
-mdouble-float, -msingle-float. Without these building ASM sources for 
soft-float
or single-float get marked as if they were hard-float double-precision with the
new binutils .MIPS.abiflags support. This does of course mean that using an old
GCC with a new binutils will lead to problems building soft-float or
single-precision code.

Attached is a patch that just addresses these issues rather than the whole FPXX
patch again. I'll merge everything together and post the whole lot when things
are resolved and more testing has been done.

Regards,
Matthew

From 4fc4f1c72e1d226691d4cebf2c5fa6de809fb409 Mon Sep 17 00:00:00 2001
From: Matthew Fortune 
Date: Sat, 31 May 2014 23:33:21 +0100
Subject: [PATCH] fpxx feature fix

---
 gcc/config.gcc |8 
 gcc/config/mips/mips.c |   34 ++
 gcc/config/mips/mips.h |   10 +-
 gcc/dwarf2cfi.c|5 +
 4 files changed, 44 insertions(+), 13 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 79268f7..dc272d8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3731,7 +3731,7 @@ case "${target}" in
;;
 
mips*-*-*)
-   supported_defaults="abi arch arch_32 arch_64 float fpu nan fp 
tune tune_32 tune_64 divide llsc mips-plt synci"
+   supported_defaults="abi arch arch_32 arch_64 float fpu nan 
fp_32 tune tune_32 tune_64 divide llsc mips-plt synci"
 
case ${with_float} in
"" | soft | hard)
@@ -3763,12 +3763,12 @@ case "${target}" in
;;
esac
 
-   case ${with_fp} in
+   case ${with_fp_32} in
"" | 32 | xx | 64)
# OK
;;
*)
-   echo "Unknown FP mode used in --with-fp=$with_fp" 1>&2
+   echo "Unknown FP mode used in --with-fp-32=$with_fp_32" 
1>&2

Re: libgo patch committed: Merge from revision 18783 of master

[Ian Lance Taylor]

On Fri, Jun 6, 2014 at 2:12 AM, Rainer Orth  
wrote:
> Ian Lance Taylor  writes:
>
>> I have committed a patch to libgo to merge from revision
>> 18783:00cce3a34d7e of the master library.  This revision was committed
>> January 7.  I picked this revision to merge to because the next revision
>> deleted a file that is explicitly merged in by the libgo/merge.sh
>> script.
>>
>> Among other things, this patch changes type descriptors to add a new
>> pointer to a zero value.  In gccgo this is implemented as a common
>> variable, and that requires some changes to the compiler and a small
>> change to go-gcc.cc.
>
> This change introduced many failures on Solaris with /bin/ld, e.g.
>
> FAIL: go.test/test/bom.go -O (test for excess errors)
>
> ld: warning: symbol 'go$zerovalue' has differing sizes:
> (file bom.o value=0x8; file 
> /var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/./libgo/.libs/libgo.so
>  value=0x800);
> bom.o definition taken and updated with larger size

Interesting.  This is working as intended, except for the warning.

go$zerovalue is a common symbol, and the linker is supposed to use the
larger version.  From the error message I'm guessing the Solaris
linker supports this when linking object files, but not when linking
an object file against a shared library.

I wonder if we could avoid this warning by giving go$zerovalue hidden
visibility.  That would mean something like this patch.

Ian

Index: go-gcc.cc
===
--- go-gcc.cc   (revision 211315)
+++ go-gcc.cc   (working copy)
@@ -2521,6 +2521,8 @@ Gcc_backend::implicit_variable(const std
   DECL_COMMON(decl) = 1;
   TREE_PUBLIC(decl) = 1;
   gcc_assert(init_tree == NULL_TREE);
+  DECL_VISIBILITY(decl) = VISIBILITY_HIDDEN;
+  DECL_VISIBILITY_SPECIFIED(decl) = 1;
 }
   else if (is_constant)
 {

Re: [PATCH] Don't call init_caller_save if LRA enabled

[Vladimir Makarov]

On 2014-06-04, 12:31 PM, Kito Cheng wrote:

LRA generate caller-save register store/restore during split register,
not generate by caller-save.c:save_call_clobbered_regs, so initialize
this module by init_caller_save is meaningless if LRA enabled

2014-06-05  Kito Cheng  

  * ira.c (ira): Don't call init_caller_save if LRA enabled
  since LRA use its own infrastructure to handle that.




The patch is ok.  As I remember changelog entries should contain what is 
done but not why it is done.  But I guess this entry is ok too as it is 
still very brief.


Kito, thanks for fixing it.  You can commit it into the trunk.

Re: std::quoted doesn't respect padding

[Ed Smith-Rowland]

On 06/05/2014 11:48 AM, Jonathan Wakely wrote:

On 05/06/14 11:43 -0400, Ed Smith-Rowland wrote:

On 04/01/2014 07:33 AM, Jonathan Wakely wrote:

[CCing gcc-patches]

On 11/03/14 11:18 -0400, Ed Smith-Rowland wrote:

On 02/14/2014 07:56 PM, Jonathan Wakely wrote:

We need to implement this fix (probably after 4.9 is released though)

http://cplusplus.github.io/LWG/lwg-active.html#2344


Here is a patch (Stage 1 obviously).


A couple of things I didn't notice earlier ...


Index: include/std/iomanip
===
--- include/std/iomanip(revision 208430)
+++ include/std/iomanip(working copy)
@@ -41,6 +41,7 @@

#if __cplusplus >= 201103L
#include 
+#include  // used in quoted.


We really only need  for __cplusplus > 201103L, otherwise we
include it unnecessarily for C++11.



-return __os;
+return __os << __ostr.str();
 }


It should be slightly more efficient to do __os << __ostr.rdbuf() here,
and in the other operator<< overload, since that copies directly from
the stringbuf to __os's own streambuf, rather than creating a
temporary std::string and copying from that.



Sorry for the hiatus...

Here is a new patch with issues fixed.

OK if it passes testing on x86_64-linux?


Great, OK for trunk and 4.9 too, I think.

Thanks!




The rdbuf version fails.
The compare asserts fail and

  //  Should be: ["AB \"CD\" EF"xx]
  //  Gives: ["AB \"CD\" EF"xx]
  std::cout << "[" << std::left << std::setfill('x') << std::setw(20) 
<< R"("AB \"CD\" EF")" << "]" << std::endl;

  //  Should be: ["GH \"IJ\" KL"yy]
  //  Gives: ["yyyGH \"IJ\" KL"]
  std::cout << "[" << std::left << std::setfill('y') << std::setw(20) 
<< std::quoted(R"(GH "IJ" KL)") << "]" << std::endl;


This prints
["AB \"CD\" EF"xx]
[

No newline on the second line - just the '['.
I'll look at rdbuf. Error in rdbuf? Do I need to do something?

Failing that we know str() works even though it is inefficient.

Ed

__float128 typeinfo

[Marc Glisse]

Hello,

here is a new try on adding __float128 typeinfo to libsupc++. The 
front-end part is based on the discussion with Jason yesterday. The 
libstdc++ part is copied from:

https://gcc.gnu.org/ml/libstdc++/2014-04/msg00077.html
(which wasn't reviewed), but I changed the testsuite.

Michael will likely need to make some adjustments to his __float128 patch, 
but I believe it will only be a small configure tweak.


Ramana, does it look safe for ARM? By the way, do you want to remove the 
XFmode defined in arm-modes.def and apparently unused?


Bootstrap+testsuite on x86_64-linux-gnu. I manually checked that 
libstdc++.{a,so} gained exactly the symbols related to typeinfo for 
__float128.


abi_check is broken before my patch (134 incompatible symbols). After it, 
the number of added symbols increases by 7, but the number of incompatible 
symbols remains the same, so I take it as a pass.


2014-06-06  Marc Glisse  

PR libstdc++/43622
gcc/cp/
* rtti.c (emit_support_tinfos): Handle __float128.
libstdc++-v3/
* config/abi/pre/float128.ver: New file.
* configure.ac: Use float128.ver when relevant.
* configure: Regenerate.
* testsuite/util/testsuite_abi.cc (check_version): Accept new
CXXABI_FLOAT128_1.3.9 version.

--
Marc GlisseIndex: gcc/cp/rtti.c
===
--- gcc/cp/rtti.c   (revision 211311)
+++ gcc/cp/rtti.c   (working copy)
@@ -1540,20 +1540,31 @@ emit_support_tinfos (void)
/*tag_scope=*/ts_current, false);
   pop_abi_namespace ();
   if (!COMPLETE_TYPE_P (bltn_type))
 return;
   dtor = CLASSTYPE_DESTRUCTORS (bltn_type);
   if (!dtor || DECL_EXTERNAL (dtor))
 return;
   doing_runtime = 1;
   for (ix = 0; fundamentals[ix]; ix++)
 emit_support_tinfo_1 (*fundamentals[ix]);
+
+  /* Search for an extra floating point type like __float128.  */
+  for (enum machine_mode mode = GET_CLASS_NARROWEST_MODE (MODE_FLOAT);
+   mode != VOIDmode;
+   mode = GET_MODE_WIDER_MODE (mode))
+{
+  tree type = c_common_type_for_mode (mode, false);
+  if (type && type != float_type_node && type != double_type_node
+ && type != long_double_type_node)
+   emit_support_tinfo_1 (type);
+}
 }
 
 /* Finish a type info decl. DECL_PTR is a pointer to an unemitted
tinfo decl.  Determine whether it needs emitting, and if so
generate the initializer.  */
 
 bool
 emit_tinfo_decl (tree decl)
 {
   tree type = TREE_TYPE (DECL_NAME (decl));
Index: libstdc++-v3/config/abi/pre/float128.ver
===
--- libstdc++-v3/config/abi/pre/float128.ver(revision 0)
+++ libstdc++-v3/config/abi/pre/float128.ver(working copy)
@@ -0,0 +1,10 @@
+# Appended to version file.
+
+CXXABI_FLOAT128_1.3.9 {
+
+# typeinfo and typeinfo name for __float128
+_ZT[IS]g;
+_ZT[IS]Pg;
+_ZT[IS]PKg;
+
+};
Index: libstdc++-v3/configure
===
--- libstdc++-v3/configure  (revision 211311)
+++ libstdc++-v3/configure  (working copy)
@@ -15698,20 +15698,23 @@ $as_echo "#define _GLIBCXX_USE_FLOAT128
 $as_echo "$enable_float128" >&6; }
 rm -f conftest*
 
   ac_ext=c
 ac_cpp='$CPP $CPPFLAGS'
 ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
 ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext 
$LIBS >&5'
 ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
+if test "$enable_float128" = yes; then
+  port_specific_symbol_files="$port_specific_symbol_files 
\$(top_srcdir)/config/abi/pre/float128.ver"
+fi
 
 # Checks for compiler support that doesn't require linking.
 
   # All these tests are for C++; save the language and the compiler flags.
   # The CXXFLAGS thing is suspicious, but based on similar bits previously
   # found in GLIBCXX_CONFIGURE.
 
   ac_ext=cpp
 ac_cpp='$CXXCPP $CPPFLAGS'
 ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
Index: libstdc++-v3/configure.ac
===
--- libstdc++-v3/configure.ac   (revision 211311)
+++ libstdc++-v3/configure.ac   (working copy)
@@ -146,20 +146,23 @@ GLIBCXX_ENABLE_HOSTED
 # Enable descriptive messages to standard output on termination.
 GLIBCXX_ENABLE_VERBOSE
 
 # Enable compiler support that doesn't require linking.
 GLIBCXX_ENABLE_SJLJ_EXCEPTIONS
 GLIBCXX_ENABLE_PCH($is_hosted)
 GLIBCXX_ENABLE_THREADS
 GLIBCXX_ENABLE_ATOMIC_BUILTINS
 GLIBCXX_ENABLE_DECIMAL_FLOAT
 GLIBCXX_ENABLE_INT128_FLOAT128
+if test "$enable_float128" = yes; then
+  port_specific_symbol_files="$port_specific_symbol_files 
\$(top_srcdir)/config/abi/pre/float128.ver"
+fi
 
 # Checks for compiler support that doesn't require linking.
 GLIBCXX_CHECK_COMPILER_FEATURES
 
 # Enable all the variable C++ runtime options that don't require linking.
 GLIBCXX_ENABLE_CSTDIO
 GLIBCXX_ENABLE_CLOCALE
 GLIBCXX_ENABLE_ALLOCATOR
 GLIBCXX_E

Re: __float128 typeinfo

[Paolo Carlini]

Hi,

On 06/06/2014 04:16 PM, Marc Glisse wrote:

abi_check is broken before my patch (134 incompatible symbols).
Isn't broken for me, though. Likewise, AFAICS, on gcc-testresults. I 
would recommend investigating in some detail what's going on at your end...


Paolo.

Re: std::quoted doesn't respect padding

[Jonathan Wakely]

On 06/06/14 10:08 -0400, Ed Smith-Rowland wrote:

I'll look at rdbuf. Error in rdbuf? Do I need to do something?


No, just me being dumb. The ostream::operator<<(streambuf*) overload
behaves as an unformatted output function, so won't obey the padding,
which is exactly what you're trying to fix.  Sorry for suggesting it.

Re: [patch] Update catch(...) handlers to deal with __forced_unwind

[Jonathan Wakely]

On 06/06/14 12:40 +0200, Uros Bizjak wrote:

On Fri, Jun 6, 2014 at 11:19 AM, Jonathan Wakely  wrote:

On 06/06/14 10:27 +0200, Uros Bizjak wrote:


These two tests timeout on alpha-linux-gnu:

FAIL: 30_threads/async/forced_unwind.cc execution test
WARNING: program timed out.
FAIL: 30_threads/packaged_task/forced_unwind.cc execution test
WARNING: program timed out.



Sorry about that, I don't know why.

Does pthread_exit(0) use a __forced_unwind exception on
alpha-linux-gnu? This should tell you ...


#include 
#include 

void* f(void*) {
 try
 {
   pthread_exit(0);
 }
 catch (__cxxabiv1::__forced_unwind const&)
 {
   __builtin_puts("unwind");
   throw;
 }
 catch (...)
 {
   __builtin_puts("something else");
   throw;
 }
}

int main()
{
 pthread_t t;
 pthread_create(&t, 0, f, 0);
 pthread_join(t, 0);

}


Strange, I don't get anything ...

$ g++ -lpthread pt.C
$ ./a.out


That explains it then: the thread just goes away, and the waiting
function hangs forever expecting the future to be made ready.

The test assumes pthread_exit is implemented by throwing
__forced_unwind, which apparently isn't true for all glibc targets.

If the thread just goes away there's no way to make the future ready.
I guess we should just XFAIL it for alpha, and maybe other targets.

Re: [C++ Patch] PR 43453

[Jason Merrill]

I wondered if moving the list-collapsing code up for all cases would 
work, so I gave it a try and it seems to work fine.


Tested x86_64-pc-linux-gnu, applying to trunk.

commit 7d4d6e5d91d5677be05ad196a140f28b01a8f55f
Author: Jason Merrill 
Date:   Thu Jun 5 13:32:14 2014 -0400

	PR c++/43453
	* decl.c (check_initializer): Collapse a TREE_LIST here.
	* typeck2.c (store_init_value): Not here.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index b068df8..b4d26b7 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5758,13 +5758,16 @@ check_initializer (tree decl, tree init, int flags, vec **cleanups)
 		check_narrowing (type, init);
 	}
 	}
-  else if (TREE_CODE (type) == ARRAY_TYPE
-	   && TREE_CODE (init) == TREE_LIST
-	   && char_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (type)))
-	   && list_length (init) == 1
-	   && TREE_CODE (TREE_VALUE (init)) == STRING_CST)
-	/* We get here with code like `char s[] ("abc");' */
-	init = TREE_VALUE (init);
+  else if (TREE_CODE (init) == TREE_LIST
+	   && TREE_TYPE (init) != unknown_type_node
+	   && !MAYBE_CLASS_TYPE_P (type))
+	{
+	  gcc_assert (TREE_CODE (decl) != RESULT_DECL);
+
+	  /* We get here with code like `int a (2);' */
+	  init = build_x_compound_expr_from_list (init, ELK_INIT,
+		  tf_warning_or_error);
+	}
 
   /* If DECL has an array type without a specific bound, deduce the
 	 array size from the initializer.  */
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 3ed5c1d..a620f22 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -780,15 +780,6 @@ store_init_value (tree decl, tree init, vec** cleanups, int flags)
 	  init = build_constructor_from_list (init_list_type_node, nreverse (init));
 	}
 }
-  else if (TREE_CODE (init) == TREE_LIST
-	   && TREE_TYPE (init) != unknown_type_node)
-{
-  gcc_assert (TREE_CODE (decl) != RESULT_DECL);
-
-  /* We get here with code like `int a (2);' */
-  init = build_x_compound_expr_from_list (init, ELK_INIT,
-	  tf_warning_or_error);
-}
 
   /* End of special C++ code.  */
 

[patch] Libstdc++ doc updates

[Jonathan Wakely]

Mostly markup tweaks, with some additional info to help debug
docbook/latex errors.

Committed to trunk.

commit c3b82a04203fce3e4ee05fd3e544e146ffa60f3a
Author: Jonathan Wakely 
Date:   Thu May 29 14:24:10 2014 +0100

	* doc/xml/faq.xml (faq.stream_reopening_fails): Replace  in
	code example.
	* doc/xml/manual/backwards_compatibility.xml
	(backwards.second.stringstreams): Likewise.
	* doc/xml/manual/configure.xml (--enable-libstdcxx-time): Document
	change of default.
	* doc/xml/manual/containers.xml (associative.bitset.type_string):
	Replace  in code example.
	* doc/xml/manual/debug.xml: Clarify reference to ThreadSanitizer.
	* doc/xml/manual/documentation_hacking.xml: Improve debugging tips,
	fix typos, improve markup.
	* doc/xml/manual/intro.xml (manual.intro.status.bugs.iso): Replace
	 with .
	* doc/xml/manual/locale.xml (locale.impl.c): Remove backticks.
	* doc/xml/manual/support.xml (std.support.memory): Replace 
	and remove newlines in string literal.

diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml
index 69e2f90..154e610 100644
--- a/libstdc++-v3/doc/xml/faq.xml
+++ b/libstdc++-v3/doc/xml/faq.xml
@@ -801,12 +801,12 @@
 
 #include 
 ...
-std::fstream  fs(a_file);
+std::fstream  fs("a_file");
 // .
 // . do things with fs...
 // .
 fs.close();
-fs.open(a_new_file);
+fs.open("a_new_file");
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml
index 89c7cc6..59da85e 100644
--- a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml
+++ b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml
@@ -412,7 +412,7 @@ erase(size_type __pos = 0, size_type __n = npos)
   std::ostrstream oss;
 #endif
 
-oss << Name= << m_name << , number= << m_number << std::endl;
+oss << "Name=" << m_name << ", number=" << m_number << std::endl;
 ...
 #ifndef HAVE_SSTREAM
   oss << std::ends; // terminate the char*-string
diff --git a/libstdc++-v3/doc/xml/manual/configure.xml b/libstdc++-v3/doc/xml/manual/configure.xml
index 1c09972..717cca7 100644
--- a/libstdc++-v3/doc/xml/manual/configure.xml
+++ b/libstdc++-v3/doc/xml/manual/configure.xml
@@ -185,7 +185,8 @@
 	desirable because, in glibc, for example, in turn it triggers the
 	linking of libpthread too, which activates locking, a large overhead
 	for single-thread programs.  OPTION=no skips the tests completely.
-	The default is OPTION=no.
+	The default is OPTION=auto, which skips the checks and enables the
+	features only for targets known to support them.
 
  
 
diff --git a/libstdc++-v3/doc/xml/manual/containers.xml b/libstdc++-v3/doc/xml/manual/containers.xml
index 9fea0f7..ec2cb21 100644
--- a/libstdc++-v3/doc/xml/manual/containers.xml
+++ b/libstdc++-v3/doc/xml/manual/containers.xml
@@ -334,7 +334,7 @@
  constructor expression:


-  std::bitset<5> b ( std::string(10110) );
+  std::bitset<5> b ( std::string("10110") );

 

@@ -342,7 +342,7 @@

 
 
-  std::bitset<5> b ( 10110 );// invalid
+  std::bitset<5> b ( "10110" );// invalid
 
 
   
diff --git a/libstdc++-v3/doc/xml/manual/debug.xml b/libstdc++-v3/doc/xml/manual/debug.xml
index 5e84495..923f6ab 100644
--- a/libstdc++-v3/doc/xml/manual/debug.xml
+++ b/libstdc++-v3/doc/xml/manual/debug.xml
@@ -235,7 +235,8 @@
   Helgrind, and
   http://www.w3.org/1999/xlink"; 
   xlink:href="http://code.google.com/p/data-race-test/";> 
-  ThreadSanitizer.
+  ThreadSanitizer (this refers to ThreadSanitizer v1, not the
+  new "tsan" feature built-in to GCC itself).
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/documentation_hacking.xml b/libstdc++-v3/doc/xml/manual/documentation_hacking.xml
index 59f8445..ba53721 100644
--- a/libstdc++-v3/doc/xml/manual/documentation_hacking.xml
+++ b/libstdc++-v3/doc/xml/manual/documentation_hacking.xml
@@ -274,7 +274,9 @@
 	http://www.w3.org/1999/xlink"; xlink:href="http://www.graphviz.org";>Graphviz package
 	will need to be installed. For PDF
 	output, http://www.w3.org/1999/xlink"; xlink:href="http://www.tug.org/applications/pdftex/";>
-	pdflatex is required.
+	pdflatex is required as well as a number of TeX packages
+	such as texlive-xtab and
+	texlive-tocloft.
   
 
   
@@ -360,8 +362,8 @@
 	
 	
 	  Working on the doxygen path only, closely examine the
-	  contents of the following build directory:
-	  build/target/libstdc++-v3/doc/doxygen/latex.
+	  contents of the following build directory: build/target/libstdc++-v3/doc/doxygen/latex.
 	  Pay attention to three files enclosed within, annotated as follows.
 	
 
@@ -375,18 +377,36 @@
 The actual latex file, or partial latex file. This is generated
 via doxygen, and is the LaTeX version of the
 Doxygen XML file libstdc++-api.xml. Go to a specific
-line, and look at the genrated LaTeX, and try to deduce what
+line, and lo

Re: [Patch ARM/testsuite 00/22] Neon intrinsics executable tests

[Christophe Lyon]

On 6 June 2014 01:32, Joseph S. Myers  wrote:
> Have these been tested for both big and little endian (especially for
> tests where memory layout matters - load / store / lane number tests -
> remembering that GNU C vector initializers always use array ordering,
> which is not the same as the architecture-defined lane numbering for big
> endian)?
>

I did run the tests on armeb-none-linux-gnueabihf (with qemu), and in
addition to the FAILs I already mentionned I can see errors in the
vzip and vuzp tests.
At this stage I don't know if it's a bug in my tests or a compiler bug.

However my tests initialize vectors using vld1, not vector
initializers so I think there shouldn't be this problem.

Christophe.

Re: Create a library for tools like collect2 and lto-wrapper (2/2)

[Bernd Schmidt]

On 06/03/2014 10:55 PM, Joseph S. Myers wrote:

OK.


Thanks. Here's a new version of the original patch set. There are now 
three patches, the middle one containing just a few small cleanup steps 
towards unifying the code. There was confusion about the meaning of the 
"debug" variable, so I've created a new one "save_temps" which controls 
one aspect of the behaviour, while "debug" now just controls extra printout.


Bootstrapped/tested on x86_64-linux. A slightly earlier version was also 
tested on powerpc-ibm-aix7.1.0.0 (the gcc111 machine). Ok?



Bernd


commit af9bca9c6439e3f8f31b40d5813a3d016b1f21e5
Author: Bernd Schmidt 
Date:   Wed May 21 12:18:17 2014 +0200

Make a collect-utils library for use by tools like collect2 and lto-wrapper.

	* Makefile.in (ALL_HOST_BACKEND_OBJS): Add collect-utils.o.
	(lto-wrapper$(exeext)): Link with collect-utils.o.
	* collect-utils.c: New file.
	* collect-utils.h: New file.
	* lto-wrapper.c: Include "collect-utils.h".
	(args_name): Delete variable.
	(tool_name): New variable.
	(tool_cleanup): New function.
	(maybe_unlink): Renamed from maybe_unlink_file.  All callers changed.
	(lto_wrapper_cleanup, fatal_signal, collect_execute, collect_wait,
	fork_execute): Remove functions.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 3350186..24abad9 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1491,7 +1491,7 @@ ALL_HOST_FRONTEND_OBJS = $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
 ALL_HOST_BACKEND_OBJS = $(GCC_OBJS) $(OBJS) $(OBJS-libcommon) \
   $(OBJS-libcommon-target) @TREEBROWSER@ main.o c-family/cppspec.o \
   $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) $(GCOV_OBJS) $(GCOV_DUMP_OBJS) \
-  lto-wrapper.o
+  lto-wrapper.o collect-utils.o
 
 # This lists all host object files, whether they are included in this
 # compilation or not.
@@ -1910,9 +1910,10 @@ collect2$(exeext): $(COLLECT2_OBJS) $(LIBDEPS)
 CFLAGS-collect2.o += -DTARGET_MACHINE=\"$(target_noncanonical)\" \
 	@TARGET_SYSTEM_ROOT_DEFINE@
 
-lto-wrapper$(exeext): lto-wrapper.o ggc-none.o libcommon-target.a $(LIBDEPS)
+LTO_WRAPPER_OBJS = lto-wrapper.o collect-utils.o ggc-none.o
+lto-wrapper$(exeext): $(LTO_WRAPPER_OBJS) libcommon-target.a $(LIBDEPS)
 	+$(LINKER) $(ALL_COMPILERFLAGS) $(LDFLAGS) -o T$@ \
-	lto-wrapper.o ggc-none.o libcommon-target.a $(LIBS)
+	   $(LTO_WRAPPER_OBJS) libcommon-target.a $(LIBS)
 	mv -f T$@ $@
 
 # Files used by all variants of C or by the stand-alone pre-processor.
diff --git a/gcc/collect-utils.c b/gcc/collect-utils.c
new file mode 100644
index 000..004569c
--- /dev/null
+++ b/gcc/collect-utils.c
@@ -0,0 +1,222 @@
+/* Utility functions used by tools like collect2 and lto-wrapper.
+   Copyright (C) 2009-2014 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
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "intl.h"
+#include "diagnostic.h"
+#include "obstack.h"
+#include "opts.h"
+#include "options.h"
+#include "simple-object.h"
+#include "lto-section-names.h"
+#include "collect-utils.h"
+
+static char *response_file;
+
+bool debug;
+bool verbose;
+
+/* Delete tempfiles.  */
+
+void
+utils_cleanup (void)
+{
+  static bool cleanup_done = false;
+
+  if (cleanup_done)
+return;
+
+  /* Setting cleanup_done prevents an infinite loop if one of the
+ calls to maybe_unlink fails. */
+  cleanup_done = true;
+
+  if (response_file)
+maybe_unlink (response_file);
+  tool_cleanup ();
+}
+
+/* Notify user of a non-error.  */
+void
+notice (const char *cmsgid, ...)
+{
+  va_list ap;
+
+  va_start (ap, cmsgid);
+  vfprintf (stderr, _(cmsgid), ap);
+  va_end (ap);
+}
+
+void
+fatal_signal (int signum)
+{
+  signal (signum, SIG_DFL);
+  utils_cleanup ();
+  /* Get the same signal again, this time not handled,
+ so its normal effect occurs.  */
+  kill (getpid (), signum);
+}
+
+/* Execute a program, and wait for the reply. ARGV are the arguments. The
+   last one must be NULL. */
+
+struct pex_obj *
+collect_execute (char **argv)
+{
+  struct pex_obj *pex;
+  const char *errmsg;
+  int err;
+
+  if (verbose)
+{
+  char **p_argv;
+  const char *str;
+
+  for (p_argv = argv; (str = *p_argv) != (char *) 0; p_argv++)
+	fprintf (stderr, " %s", str);
+
+  fprintf (stderr, "\n");
+}
+
+  fflush (stdout);
+  fflush (stderr);
+
+  pex = pex_init (0, tool_name, NULL);
+

-finit-local-vars option

[Florian Weimer]

The attached crude patch as an -finit-local-vars option to the C front 
end.  If active, all local variables are initialized to zero.  It is 
part of an experiment to assess the performance impact of local variable 
initialization.


This is not a real patch submission because the way the flag is 
implemented, it interferes with unused-variable warnings.  I just want 
to archive it for posterity.


--
Florian Weimer / Red Hat Product Security Team
commit dbb1a7d8ee583466f00502848866fbfe5f5e2ca8
Author: Florian Weimer 
Date:   Thu Jun 5 10:16:34 2014 +0200

Add -finit-local-vars

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 5d36a80..54d7244 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1074,6 +1074,10 @@ Enum(ivar_visibility) String(public) Value(IVAR_VISIBILITY_PUBLIC)
 EnumValue
 Enum(ivar_visibility) String(package) Value(IVAR_VISIBILITY_PACKAGE)
 
+finit-local-vars
+C Var(flag_init_local_vars)
+Initialize local variables to zero
+
 fnonansi-builtins
 C++ ObjC++ Var(flag_no_nonansi_builtin, 0)
 
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index dc8dbc2..52efd56 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -4627,6 +4627,19 @@ finish_decl (tree decl, location_t init_loc, tree init,
 	diagnose_uninitialized_cst_member (decl, type);
 }
 
+  if (flag_init_local_vars
+  && TREE_CODE (decl) == VAR_DECL
+  && !DECL_EXTERNAL (decl)
+  && init == NULL_TREE
+  && DECL_INITIAL (decl) == NULL_TREE
+  && !global_bindings_p ())
+{
+  if (AGGREGATE_TYPE_P (type))
+	DECL_INITIAL (decl) = build_constructor (type, NULL);
+  else
+	DECL_INITIAL (decl) = fold_convert (type, integer_zero_node);
+}
+
 	invoke_plugin_callbacks (PLUGIN_FINISH_DECL, decl);
 }
 

[gomp4] Offload option handling

[Bernd Schmidt]

There's a problem when offloading from a compiler for one target machine 
to another: the machine specific options don't necessarily match. This 
patch tries to address this.


The idea is that since we have two options sections anyway, with 
different section name prefixes, we can arrange to pass only 
target-independent options in the omp_ version of the options section.
However, some target-specific options (specifically the ones specifying 
the ABI) need to be preserved somehow, so there's a new target hook for 
translating them to common a -foffload-* syntax.


How does this look? Comments on the approach, and ok for the 
gomp-4_0-branch?



Bernd

Index: gcc/common.opt
===
--- gcc/common.opt.orig
+++ gcc/common.opt
@@ -1601,6 +1601,19 @@ fnon-call-exceptions
 Common Report Var(flag_non_call_exceptions) Optimization
 Support synchronous non-call exceptions
 
+foffload-abi=
+Common Joined RejectNegative Enum(offload_abi) Var(flag_offload_abi) Init(OFFLOAD_ABI_UNSET)
+-foffload-abi=[lp64|ilp32]	Set the ABI to use in an offload compiler
+
+Enum
+Name(offload_abi) Type(enum offload_abi) UnknownError(unknown offload ABI %qs)
+
+EnumValue
+Enum(offload_abi) String(ilp32) Value(OFFLOAD_ABI_ILP32)
+
+EnumValue
+Enum(offload_abi) String(lp64) Value(OFFLOAD_ABI_LP64)
+
 fomit-frame-pointer
 Common Report Var(flag_omit_frame_pointer) Optimization
 When possible do not generate stack frames
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c.orig
+++ gcc/config/i386/i386.c
@@ -4261,6 +4261,15 @@ ix86_option_override (void)
   register_pass (&insert_vzeroupper_info);
 }
 
+/* Implement the TARGET_OFFLOAD_OPTIONS hook.  */
+static char *
+ix86_offload_options (void)
+{
+  if (TARGET_LP64)
+return xstrdup ("-foffload-abi=lp64");
+  return xstrdup ("-foffload-abi=ilp32");
+}
+
 /* Update register usage after having seen the compiler flags.  */
 
 static void
@@ -47142,6 +47151,10 @@ ix86_atomic_assign_expand_fenv (tree *ho
 #define TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P \
   ix86_float_exceptions_rounding_supported_p
 
+#undef TARGET_OFFLOAD_OPTIONS
+#define TARGET_OFFLOAD_OPTIONS \
+  ix86_offload_options
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 #include "gt-i386.h"
Index: gcc/coretypes.h
===
--- gcc/coretypes.h.orig
+++ gcc/coretypes.h
@@ -111,6 +111,12 @@ enum tls_model {
   TLS_MODEL_LOCAL_EXEC
 };
 
+enum offload_abi {
+  OFFLOAD_ABI_UNSET,
+  OFFLOAD_ABI_LP64,
+  OFFLOAD_ABI_ILP32
+};
+
 /* Types of unwind/exception handling info that can be generated.  */
 
 enum unwind_info_type
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi.orig
+++ gcc/doc/tm.texi
@@ -11446,3 +11446,12 @@ Used when offloaded functions are seen i
 sections are available.  It is called once for each symbol that must be
 recorded in the offload function and variable table.
 @end deftypefn
+
+@deftypefn {Target Hook} {char *} TARGET_OFFLOAD_OPTIONS (void)
+Used when writing out the list of options into an LTO file.  It should
+translate any relevant target-specific options (such as the ABI in use)
+into one of the @option{-foffload} options that exist as a common interface
+to express such options. It should return a string containing these options,
+separated by spaces, which the caller will free.
+
+@end deftypefn
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in.orig
+++ gcc/doc/tm.texi.in
@@ -8427,3 +8427,5 @@ and the associated definitions of those
 @hook TARGET_ATOMIC_ASSIGN_EXPAND_FENV
 
 @hook TARGET_RECORD_OFFLOAD_SYMBOL
+
+@hook TARGET_OFFLOAD_OPTIONS
Index: gcc/hooks.c
===
--- gcc/hooks.c.orig
+++ gcc/hooks.c
@@ -373,12 +373,19 @@ hook_tree_tree_tree_tree_3rd_identity (t
   return c;
 }
 
-/* Generic hook that takes no arguments and returns a NULL string.  */
+/* Generic hook that takes no arguments and returns a NULL const string.  */
 const char *
 hook_constcharptr_void_null (void)
 {
   return NULL;
 }
+
+/* Generic hook that takes no arguments and returns a NULL string.  */
+char *
+hook_charptr_void_null (void)
+{
+  return NULL;
+}
 
 /* Generic hook that takes a tree and returns a NULL string.  */
 const char *
Index: gcc/hooks.h
===
--- gcc/hooks.h.orig
+++ gcc/hooks.h
@@ -101,6 +101,7 @@ extern rtx hook_rtx_rtx_identity (rtx);
 extern rtx hook_rtx_rtx_null (rtx);
 extern rtx hook_rtx_tree_int_null (tree, int);
 
+extern char *hook_charptr_void_null (void);
 extern const char *hook_constcharptr_void_null (void);
 extern const char *hook_constcharptr_const_tree_null (const_tree);
 extern const char *hook_constcharptr_const_rtx_null (const_rtx);
Index:

Re: Create a library for tools like collect2 and lto-wrapper (2/2)

[Joseph S. Myers]

On Fri, 6 Jun 2014, Bernd Schmidt wrote:

> On 06/03/2014 10:55 PM, Joseph S. Myers wrote:
> > OK.
> 
> Thanks. Here's a new version of the original patch set. There are now three
> patches, the middle one containing just a few small cleanup steps towards
> unifying the code. There was confusion about the meaning of the "debug"
> variable, so I've created a new one "save_temps" which controls one aspect of
> the behaviour, while "debug" now just controls extra printout.
> 
> Bootstrapped/tested on x86_64-linux. A slightly earlier version was also
> tested on powerpc-ibm-aix7.1.0.0 (the gcc111 machine). Ok?

OK in the absence of objections within 72 hours.

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

Re: __float128 typeinfo

[Ramana Radhakrishnan]

On Fri, Jun 6, 2014 at 3:16 PM, Marc Glisse  wrote:
> Hello,
>
> here is a new try on adding __float128 typeinfo to libsupc++. The front-end
> part is based on the discussion with Jason yesterday. The libstdc++ part is
> copied from:
> https://gcc.gnu.org/ml/libstdc++/2014-04/msg00077.html
> (which wasn't reviewed), but I changed the testsuite.
>
> Michael will likely need to make some adjustments to his __float128 patch,
> but I believe it will only be a small configure tweak.
>
> Ramana, does it look safe for ARM? By the way, do you want to remove the
> XFmode defined in arm-modes.def and apparently unused?

Thanks for this though I know Tejas is actually trying to fix AArch64
first and then we'll move on to ARM for cleaning up all these types -
as you realize it's quite a chunky project.

A patch to remove XFmode is pre-approved. I have no idea why this is
in here. Archeaology shows this came in

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@72440

and with a FIXME:

I'll try and have a look at this patch later today or over the weekend
to see if it doesn't affect ARM / AArch64.

regards
Ramana

>
> Bootstrap+testsuite on x86_64-linux-gnu. I manually checked that
> libstdc++.{a,so} gained exactly the symbols related to typeinfo for
> __float128.
>
> abi_check is broken before my patch (134 incompatible symbols). After it,
> the number of added symbols increases by 7, but the number of incompatible
> symbols remains the same, so I take it as a pass.
>
> 2014-06-06  Marc Glisse  
>
> PR libstdc++/43622
> gcc/cp/
> * rtti.c (emit_support_tinfos): Handle __float128.
> libstdc++-v3/
> * config/abi/pre/float128.ver: New file.
> * configure.ac: Use float128.ver when relevant.
> * configure: Regenerate.
> * testsuite/util/testsuite_abi.cc (check_version): Accept new
> CXXABI_FLOAT128_1.3.9 version.
>
> --
> Marc Glisse
> Index: gcc/cp/rtti.c
> ===
> --- gcc/cp/rtti.c   (revision 211311)
> +++ gcc/cp/rtti.c   (working copy)
> @@ -1540,20 +1540,31 @@ emit_support_tinfos (void)
> /*tag_scope=*/ts_current, false);
>pop_abi_namespace ();
>if (!COMPLETE_TYPE_P (bltn_type))
>  return;
>dtor = CLASSTYPE_DESTRUCTORS (bltn_type);
>if (!dtor || DECL_EXTERNAL (dtor))
>  return;
>doing_runtime = 1;
>for (ix = 0; fundamentals[ix]; ix++)
>  emit_support_tinfo_1 (*fundamentals[ix]);
> +
> +  /* Search for an extra floating point type like __float128.  */
> +  for (enum machine_mode mode = GET_CLASS_NARROWEST_MODE (MODE_FLOAT);
> +   mode != VOIDmode;
> +   mode = GET_MODE_WIDER_MODE (mode))
> +{
> +  tree type = c_common_type_for_mode (mode, false);
> +  if (type && type != float_type_node && type != double_type_node
> + && type != long_double_type_node)
> +   emit_support_tinfo_1 (type);
> +}
>  }
>
>  /* Finish a type info decl. DECL_PTR is a pointer to an unemitted
> tinfo decl.  Determine whether it needs emitting, and if so
> generate the initializer.  */
>
>  bool
>  emit_tinfo_decl (tree decl)
>  {
>tree type = TREE_TYPE (DECL_NAME (decl));
> Index: libstdc++-v3/config/abi/pre/float128.ver
> ===
> --- libstdc++-v3/config/abi/pre/float128.ver(revision 0)
> +++ libstdc++-v3/config/abi/pre/float128.ver(working copy)
> @@ -0,0 +1,10 @@
> +# Appended to version file.
> +
> +CXXABI_FLOAT128_1.3.9 {
> +
> +# typeinfo and typeinfo name for __float128
> +_ZT[IS]g;
> +_ZT[IS]Pg;
> +_ZT[IS]PKg;
> +
> +};
> Index: libstdc++-v3/configure
> ===
> --- libstdc++-v3/configure  (revision 211311)
> +++ libstdc++-v3/configure  (working copy)
> @@ -15698,20 +15698,23 @@ $as_echo "#define _GLIBCXX_USE_FLOAT128
>  $as_echo "$enable_float128" >&6; }
>  rm -f conftest*
>
>ac_ext=c
>  ac_cpp='$CPP $CPPFLAGS'
>  ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
>  ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS
> conftest.$ac_ext $LIBS >&5'
>  ac_compiler_gnu=$ac_cv_c_compiler_gnu
>
>
> +if test "$enable_float128" = yes; then
> +  port_specific_symbol_files="$port_specific_symbol_files
> \$(top_srcdir)/config/abi/pre/float128.ver"
> +fi
>
>  # Checks for compiler support that doesn't require linking.
>
># All these tests are for C++; save the language and the compiler flags.
># The CXXFLAGS thing is suspicious, but based on similar bits previously
># found in GLIBCXX_CONFIGURE.
>
>ac_ext=cpp
>  ac_cpp='$CXXCPP $CPPFLAGS'
>  ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
> Index: libstdc++-v3/configure.ac
> ===
> --- libstdc++-v3/configure.ac   (revision 211311)
> +++ libstdc++-v3/configure.ac   (working copy)
> @@ -146,20 +146,2

[PATCH] Sink loads (fix PR59299)

[Richard Biener]

The following adds the missing capability to sink loads to
tree-ssa-sink.c.  This enables sinking of loads and dependent
expressions into code paths that uses them (thus performing
partial dead code elimination on loads).

The algorithm is simple (similar to that sinking stores) to
be light-weight on compile-time thus it may miss some
opportunities but it fires quite a bit on GCC itself.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2014-06-06  Richard Biener  

PR tree-optimization/59299
* tree-ssa-sink.c (all_immediate_uses_same_place): Work on
a def operand.
(nearest_common_dominator_of_uses): Likewise.
(statement_sink_location): Adjust.  Support sinking loads.

* gcc.dg/tree-ssa/ssa-sink-10.c: New testcase.

Index: gcc/tree-ssa-sink.c
===
*** gcc/tree-ssa-sink.c.orig2014-06-06 10:26:37.533999642 +0200
--- gcc/tree-ssa-sink.c 2014-06-06 15:20:50.886784230 +0200
*** find_bb_for_arg (gimple phi, tree def)
*** 110,135 
 used in, so that you only have one place you can sink it to.  */
  
  static bool
! all_immediate_uses_same_place (gimple stmt)
  {
!   gimple firstuse = NULL;
!   ssa_op_iter op_iter;
imm_use_iterator imm_iter;
use_operand_p use_p;
-   tree var;
  
!   FOR_EACH_SSA_TREE_OPERAND (var, stmt, op_iter, SSA_OP_ALL_DEFS)
  {
!   FOR_EACH_IMM_USE_FAST (use_p, imm_iter, var)
! {
! if (is_gimple_debug (USE_STMT (use_p)))
!   continue;
! if (firstuse == NULL)
!   firstuse = USE_STMT (use_p);
! else
!   if (firstuse != USE_STMT (use_p))
! return false;
!   }
  }
  
return true;
--- 110,131 
 used in, so that you only have one place you can sink it to.  */
  
  static bool
! all_immediate_uses_same_place (def_operand_p def_p)
  {
!   tree var = DEF_FROM_PTR (def_p);
imm_use_iterator imm_iter;
use_operand_p use_p;
  
!   gimple firstuse = NULL;
!   FOR_EACH_IMM_USE_FAST (use_p, imm_iter, var)
  {
!   if (is_gimple_debug (USE_STMT (use_p)))
!   continue;
!   if (firstuse == NULL)
!   firstuse = USE_STMT (use_p);
!   else
!   if (firstuse != USE_STMT (use_p))
! return false;
  }
  
return true;
*** all_immediate_uses_same_place (gimple st
*** 138,186 
  /* Find the nearest common dominator of all of the immediate uses in IMM.  */
  
  static basic_block
! nearest_common_dominator_of_uses (gimple stmt, bool *debug_stmts)
  {
bitmap blocks = BITMAP_ALLOC (NULL);
basic_block commondom;
unsigned int j;
bitmap_iterator bi;
-   ssa_op_iter op_iter;
imm_use_iterator imm_iter;
use_operand_p use_p;
-   tree var;
  
!   bitmap_clear (blocks);
!   FOR_EACH_SSA_TREE_OPERAND (var, stmt, op_iter, SSA_OP_ALL_DEFS)
  {
!   FOR_EACH_IMM_USE_FAST (use_p, imm_iter, var)
! {
! gimple usestmt = USE_STMT (use_p);
! basic_block useblock;
  
! if (gimple_code (usestmt) == GIMPLE_PHI)
!   {
! int idx = PHI_ARG_INDEX_FROM_USE (use_p);
  
! useblock = gimple_phi_arg_edge (usestmt, idx)->src;
!   }
! else if (is_gimple_debug (usestmt))
!   {
! *debug_stmts = true;
! continue;
!   }
! else
!   {
! useblock = gimple_bb (usestmt);
!   }
  
! /* Short circuit. Nothing dominates the entry block.  */
! if (useblock == ENTRY_BLOCK_PTR_FOR_FN (cfun))
!   {
! BITMAP_FREE (blocks);
! return NULL;
!   }
! bitmap_set_bit (blocks, useblock->index);
}
  }
commondom = BASIC_BLOCK_FOR_FN (cfun, bitmap_first_set_bit (blocks));
EXECUTE_IF_SET_IN_BITMAP (blocks, 0, j, bi)
--- 134,177 
  /* Find the nearest common dominator of all of the immediate uses in IMM.  */
  
  static basic_block
! nearest_common_dominator_of_uses (def_operand_p def_p, bool *debug_stmts)
  {
+   tree var = DEF_FROM_PTR (def_p);
bitmap blocks = BITMAP_ALLOC (NULL);
basic_block commondom;
unsigned int j;
bitmap_iterator bi;
imm_use_iterator imm_iter;
use_operand_p use_p;
  
!   FOR_EACH_IMM_USE_FAST (use_p, imm_iter, var)
  {
!   gimple usestmt = USE_STMT (use_p);
!   basic_block useblock;
  
!   if (gimple_code (usestmt) == GIMPLE_PHI)
!   {
! int idx = PHI_ARG_INDEX_FROM_USE (use_p);
  
! useblock = gimple_phi_arg_edge (usestmt, idx)->src;
!   }
!   else if (is_gimple_debug (usestmt))
!   {
! *debug_stmts = true;
! continue;
!   }
!   else
!   {
! useblock = gimple_bb (usestmt);
!   }
  
!   /* Short circuit. Nothing dominates the entry block.  */
!   if (useblock == ENTRY_BLOCK_PTR_FOR_FN (cfun))
!   {
! BITMAP_FREE (blocks);
! 

Re: [C++ Patch] PR 60184

[Jason Merrill]

OK.

Jason

Re: [PATCH, rs6000][trunk, 4.9, 4.8] Fix PR target/61415, long double 128 issues

[David Edelsohn]

On Thu, Jun 5, 2014 at 3:57 PM, Peter Bergner  wrote:
> PR61415 shows a problem for two test cases that should only be tested if the
> target supports a 128-bit long double.  In addition, the 128-bit long double
> pack and unpack builtins should not be enabled unless the target supports
> 128-bit long double.  The following patch accomplishes that, as well as
> removing the unused (and redundant) builtins __builtin_longdouble_dw0 and
> __builtin_longdouble_dw1.
>
> Is this ok for trunk assuming my powerpc64le-linux bootstrap and regtesting
> are clean?
>
> Is this also ok for the FSF 4.9 and FSF 4.8 branches?  Without the gcc/
> changes, we hit an ICE whenever we call __builtin_pack_longdouble and
> __builtin_unpack_longdouble when -mlong-double-64 is in effect.
>
> Peter
>
>
> gcc/
> PR target/61415
> * config/rs6000/rs6000-builtin.def (BU_MISC_1): Delete.
> (BU_MISC_2): Rename to ...
> (BU_LDBL128_2): ... this.
> * config/rs6000/rs6000.h (RS6000_BTM_LDBL128): New define.
> (RS6000_BTM_COMMON): Add RS6000_BTM_LDBL128.
> * config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): Handle
> RS6000_BTM_LDBL128.
> (rs6000_invalid_builtin): Add long double 128-bit builtin support.
> (rs6000_builtin_mask_names): Add RS6000_BTM_LDBL128.
> * config/rs6000/rs6000.md (unpacktf_0): Remove define)expand.
> (unpacktf_1): Likewise.
> * doc/extend.texi (__builtin_longdouble_dw0): Remove documentation.
> (__builtin_longdouble_dw1): Likewise.
> * doc/sourcebuild.texi (longdouble128): Document.
>
> gcc/testsuite/
> PR target/61415
> * lib/target-supports.exp (check_effective_target_longdouble128): New.
> * gcc.target/powerpc/pack02.c: Use it.
> * gcc.target/powerpc/tfmode_off.c: Likewise.

This is okay with me, as long as there are no objections from RMs
about removing the private APIs that should not have been added to FSF
GCC.

Thanks, David

Re: __float128 typeinfo

[Jason Merrill]

On 06/06/2014 10:16 AM, Marc Glisse wrote:

 * config/abi/pre/float128.ver: New file.
+CXXABI_FLOAT128_1.3.9 {


What's your rationale for keeping this in a separate version block 
rather than in 1.3.9 (like __int128)?


Jason

Re: __float128 typeinfo

[Marc Glisse]

On Fri, 6 Jun 2014, Ramana Radhakrishnan wrote:


On Fri, Jun 6, 2014 at 3:16 PM, Marc Glisse  wrote:

Hello,

here is a new try on adding __float128 typeinfo to libsupc++. The front-end
part is based on the discussion with Jason yesterday. The libstdc++ part is
copied from:
https://gcc.gnu.org/ml/libstdc++/2014-04/msg00077.html
(which wasn't reviewed), but I changed the testsuite.

Michael will likely need to make some adjustments to his __float128 patch,
but I believe it will only be a small configure tweak.

Ramana, does it look safe for ARM? By the way, do you want to remove the
XFmode defined in arm-modes.def and apparently unused?


Thanks for this though I know Tejas is actually trying to fix AArch64
first and then we'll move on to ARM for cleaning up all these types -
as you realize it's quite a chunky project.


Nice to know. I am a bit afraid it might be hard without breaking ABI 
compatibility at least a little. Good luck anyway.



A patch to remove XFmode is pre-approved.


Even for such a trivial patch, it would be good to do at least a build to 
check nothing breaks, but I don't have an easy way to do that (debian 
multiarch cross-builds don't work out of the box), it would be better if 
one of the people working on ARM could handle it.



I'll try and have a look at this patch later today or over the weekend
to see if it doesn't affect ARM / AArch64.


Thanks!

--
Marc Glisse

Re: [PATCH] Run phi_only_cprop after 2nd VRP

[Christophe Lyon]

On 6 June 2014 09:25, Richard Biener  wrote:
>
> This moves the 2nd VRP pass to run befoe phi_only_cprop as
> VRP performs jump-threading which can result in BBs with
> PHI singletons.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
Hi,

This caused PR 61430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61430


Christophe.

Re: [RFC] optimize x - y cmp 0 with undefined overflow

[Richard Biener]

On Fri, Jun 6, 2014 at 12:52 PM, Eric Botcazou  wrote:
>> So when computing a range for z in
>>
>>  z = y - x;
>>
>> with x = [-INF, y - 1] and y = [x + 1, +INF] (deduced from !(x >= y)) we
>> fail to do sth sensible with [y, y] - [-INF, y - 1] or [x + 1, +INF] - [x,
>> x] but we do sth with [x + 1, +INF] - [-INF, x]?  That seems odd to me.
>>
>> With the patch we compute z to [1, +INF(OVF)]
>
> Right, and note the overflow.
>
>> Going the [x + 1, +INF] - [x,x] path first we obtain
>>
>>   [1, -x + INF]
>>
>> which fails the sanity checking
>>
>>   cmp = compare_values (min, max);
>>   if (cmp == -2 || cmp == 1)
>> {
>>   /* If the new range has its limits swapped around (MIN > MAX),
>>  then the operation caused one of them to wrap around, mark
>>  the new range VARYING.  */
>>   set_value_range_to_varying (vr);
>> }
>>   else
>> set_value_range (vr, type, min, max, NULL);
>>
>> but clearly the same reasoning you can apply that makes trying
>> with [-INF, x] valid (it's just enlarging the range) can be applied
>> here, too, when computing +INF - x for the upper bound.  We can
>> safely increase that to +INF making the range valid for the above
>> test.
>
> I don't think we can enlarge to +INF because -x + INF can overflow, we can
> only enlarge to +INF(OVF).
>
>> But I wonder what code path in the routine still relies on that sanity
>> checking to produce a valid result (so I'd rather try removing it, or
>> taking uncomparable bounds as a valid range).
>>
>> Simplest would be to simply do
>>
>>   set_value_range (vr, type, min, max, NULL);
>>   return;
>>
>> and be done with that in the plus/minus handling.  With that the
>> testcase optimizes ok for me.
>
> With [1, -x + INF] as the resulting range?  But it can be bogus if x is itself
> equal to +INF (unlike the input range [x + 1, +INF] which is always correct)

Hmm, indeed.

> so this doesn't look valid to me.  I don't see how we can get away without a
> +INF(OVF) here, but I can compute it in extract_range_from_binary_expr_1 if
> you prefer and try only [op0,op0] and [op1,op1].

Yeah, I'd prefer that.

Thanks,
Richard.

> --
> Eric Botcazou

Re: __float128 typeinfo

[Ramana Radhakrishnan]

On 06/06/14 16:40, Marc Glisse wrote:

On Fri, 6 Jun 2014, Ramana Radhakrishnan wrote:


On Fri, Jun 6, 2014 at 3:16 PM, Marc Glisse  wrote:

Hello,

here is a new try on adding __float128 typeinfo to libsupc++. The front-end
part is based on the discussion with Jason yesterday. The libstdc++ part is
copied from:
https://gcc.gnu.org/ml/libstdc++/2014-04/msg00077.html
(which wasn't reviewed), but I changed the testsuite.

Michael will likely need to make some adjustments to his __float128 patch,
but I believe it will only be a small configure tweak.

Ramana, does it look safe for ARM? By the way, do you want to remove the
XFmode defined in arm-modes.def and apparently unused?


Thanks for this though I know Tejas is actually trying to fix AArch64
first and then we'll move on to ARM for cleaning up all these types -
as you realize it's quite a chunky project.


Nice to know. I am a bit afraid it might be hard without breaking ABI
compatibility at least a little. Good luck anyway.


We did talk about that - but our expectation was that these scalar types 
are actually not exposed on any interface and are purely for internal 
representations.


User land should only be using the vector types from arm_neon.h - in any 
case if such types were used in intrinsics land, user-code will not be 
portable across compilers anyway.





A patch to remove XFmode is pre-approved.


Even for such a trivial patch, it would be good to do at least a build to
check nothing breaks, but I don't have an easy way to do that (debian
multiarch cross-builds don't work out of the box), it would be better if
one of the people working on ARM could handle it.


Sure, one of us will handle that. Thanks for pointing it out.

Ramana




I'll try and have a look at this patch later today or over the weekend
to see if it doesn't affect ARM / AArch64.


Thanks!

Re: ipa-visibility TLC 2/n

[David Edelsohn]

On Fri, Jun 6, 2014 at 3:09 AM, Jan Hubicka  wrote:

> sorry for taking time to get back to it.  I went through the code and see no 
> obvious flaws
> except that I am somewhat concerned what happens with local aliases into the 
> anchors.
> The problem however does not seem to be caused by it.  I tracked it down to 
> the following
> difference:
>
> --- d2.s2014-06-06 08:59:01.101401622 +0200
> +++ d3.s2014-06-06 08:59:01.491377632 +0200
> @@ -499,7 +499,7 @@
> .long   4
> .long   4
> .long   _ZTI1B
> -   .long   _ZTv0_n12_N1B1fEv
> +   .long   _ZTv0_n12_N1B1fEv.localalias.5
> .weak   _ZTV1A
> .align 2
>  _ZTV1A:
>
> Now _ZTv0_n12_N1B1fEv is thunk declared as:
>
> .lglobl .LTHUNK..0
> .lglobl LTHUNK..0
> .set.LTHUNK..0,._ZN1B1fEv
> .set LTHUNK..0,_ZN1B1fEv
> .lglobl ._ZTv0_n12_N1B1fEv.localalias.5
> .lglobl _ZTv0_n12_N1B1fEv.localalias.5
> .set._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
> .set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
> .align 2
> .weak   _ZTv0_n12_N1B1fEv[DS]
> .weak   ._ZTv0_n12_N1B1fEv
> .csect _ZTv0_n12_N1B1fEv[DS]
> _ZTv0_n12_N1B1fEv:
> .long ._ZTv0_n12_N1B1fEv, TOC[tc0], 0
> .csect .text[PR]
> ._ZTv0_n12_N1B1fEv:
> LFB..16:
> lwz 12,0(3)
> lwz 12,-12(12)
> add 3,3,12
> b .LTHUNK..0
>
> Now when I move the declaration of localalias after the thunk:
>
> --- d3.s2014-06-06 08:59:01.491377632 +0200
> +++ d4.s2014-06-06 09:03:58.129810951 +0200
> @@ -212,10 +212,6 @@
> .lglobl LTHUNK..0
> .set.LTHUNK..0,._ZN1B1fEv
> .set LTHUNK..0,_ZN1B1fEv
> -   .lglobl ._ZTv0_n12_N1B1fEv.localalias.5
> -   .lglobl _ZTv0_n12_N1B1fEv.localalias.5
> -   .set._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
> -   .set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
> .align 2
> .weak   _ZTv0_n12_N1B1fEv[DS]
> .weak   ._ZTv0_n12_N1B1fEv
> @@ -229,6 +225,10 @@
> lwz 12,-12(12)
> add 3,3,12
> b .LTHUNK..0
> +   .lglobl ._ZTv0_n12_N1B1fEv.localalias.5
> +   .lglobl _ZTv0_n12_N1B1fEv.localalias.5
> +   .set._ZTv0_n12_N1B1fEv.localalias.5,._ZTv0_n12_N1B1fEv
> +   .set _ZTv0_n12_N1B1fEv.localalias.5,_ZTv0_n12_N1B1fEv
>  LFE..16:
> .align 2
> .weak   _ZN1D1fEv[DS]
>
> The code starts to work.  To me both sources should make same binary, but 
> they don't.
> Can you make better sense of this than claiming it is an assembler bug?
>
> We output aliases after definitions for functions, but before definitions for 
> thunks.
> I am testing patch to change the second order.  I remeber tweaking this order 
> once before
> because of problems on solaris.  Lets see if we find order that works for 
> everyone.

Honza,

The AIX assembler is a very simple, single-pass assembler. The order
has a lot of importance because the assembler makes assumptions about
symbols, such as section placement and annotations, if they are
referenced before defined. I notice that your change places the
.lglobl declaration after the .weak declaration.  That may be more
important than placing it after the thunk.

Thanks, David

Re: [PATCH ARM] PR/61062 Fix arm_neon.h ZIP/UZP/TRN for bigendian

[Ramana Radhakrishnan]

On Wed, May 14, 2014 at 2:52 PM, Alan Lawrence  wrote:
> Hi,
>
> Due to differences in how the ARM C Language Extensions and gcc's vector
> extensions deal with indices within vectors, the __builtin_shuffle masks
> used to implement the ZIP, UZP and TRN Neon Intrinsics in arm_neon.h are
> correct only for little-endian. (The problem on bigendian has recently been
> revealed by new tests in gcc.target/arm/simd/.)
>
> This patch corrects the indices using "#ifdef __ARM_BIG_ENDIAN" through
> arm_neon.h. I've tested all the arm-specific tests (arm.exp acle.exp
> aapcs.exp simd.exp neon.exp) on both arm-none-eabi and armeb-none-eabi and
> there are no regressions, and on armeb-none-eabi this patch fixes FAIL ->
> PASS for simd/v{uzp,zip,trn}*_1.c.
>
> Note the patch also modifies gcc.target/arm/pr48252.c. A bit of diving into
> the history of this test reveals
>*the test was first written in the days when the arm_neon.h
> implementation used builtins such as __builtin_neon_vzipv8qi (which were
> thus correct for bigendian).
>*In SVN rev 189294, ZIP intrinsics were rewritten to use
> __builtin_shuffle (with little-endian masks); this broke pr48252.c on
> bigendian, but this was not detected until...
>*In SVN rev 191200, in which pr48252.c was modified to expect different
> results according to endianness - that is, "fixing" the test to match the
> broken implementation. (I have verified that this updated test failed on the
> original __builtin_neon_vzipv8qi implementation.)

Thanks for fixing this up - This patch is ok. Please apply to trunk
and backport to 4.9 after letting it bake on trunk for a few days.

I suspect 4.8 is also afflicted from a quick look - can you please
double check and then apply.

If this goes in we need to kill the ml for 4.8 and 4.9 now.

regards
Ramana

>
> The fix to pr48252.c here largely reverts to the original form although
> keeps the (correct, proper) use of vld1.
>
> gcc/ChangeLog:
>
> * config/arm/arm_neon.h (vtrn_s8, vtrn_s16, vtrn_u8, vtrn_u16,
> vtrn_p8,
> vtrn_p16, vtrn_s32, vtrn_f32, vtrn_u32, vtrnq_s8, vtrnq_s16,
> vtrnq_s32,
> vtrnq_f32, vtrnq_u8, vtrnq_u16, vtrnq_u32, vtrnq_p8, vtrnq_p16,
> vzip_s8,
> vzip_s16, vzip_u8, vzip_u16, vzip_p8, vzip_p16, vzip_s32, vzip_f32,
> vzip_u32, vzipq_s8, vzipq_s16, vzipq_s32, vzipq_f32, vzipq_u8,
> vzipq_u16, vzipq_u32, vzipq_p8, vzipq_p16, vuzp_s8, vuzp_s16,
> vuzp_s32,
> vuzp_f32, vuzp_u8, vuzp_u16, vuzp_u32, vuzp_p8, vuzp_p16, vuzpq_s8,
> vuzpq_s16, vuzpq_s32, vuzpq_f32, vuzpq_u8, vuzpq_u16, vuzpq_u32,
> vuzpq_p8, vuzpq_p16): Correct mask for bigendian.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/pr48252.c (main): Expect same result as
> endian-neutral.
>
> Cheers, Alan

Re: [Patch ARM/testsuite 00/22] Neon intrinsics executable tests

[Ramana Radhakrishnan]

On 06/06/14 15:40, Christophe Lyon wrote:

On 6 June 2014 01:32, Joseph S. Myers  wrote:

Have these been tested for both big and little endian (especially for
tests where memory layout matters - load / store / lane number tests -
remembering that GNU C vector initializers always use array ordering,
which is not the same as the architecture-defined lane numbering for big
endian)?



I did run the tests on armeb-none-linux-gnueabihf (with qemu), and in
addition to the FAILs I already mentionned I can see errors in the
vzip and vuzp tests.
At this stage I don't know if it's a bug in my tests or a compiler bug.


Didn't Alan recently fix a bug for big-endian in vzip / vuzp ?

PR target/61062

Ramana



However my tests initialize vectors using vld1, not vector
initializers so I think there shouldn't be this problem.

Christophe.

Re: __float128 typeinfo

[Marc Glisse]

On Fri, 6 Jun 2014, Jason Merrill wrote:


On 06/06/2014 10:16 AM, Marc Glisse wrote:

 * config/abi/pre/float128.ver: New file.
+CXXABI_FLOAT128_1.3.9 {


What's your rationale for keeping this in a separate version block rather 
than in 1.3.9 (like __int128)?


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622#c6

Powerpc already has those symbols in CXXABI_LDBL_1.3 (for a type that 
isn't __float128 but (de)mangles that way). That doesn't prevent from 
using CXXABI_1.3.9 in the x86/ia64-specific file though, so I can do that 
if you prefer. If a new target implements __float128 in 4.11 or 4.12, they 
will have to refine the configure test and provide a different .ver file 
to avoid adding symbols to an old version. Or I could try to share the 
CXXABI_LDBL_1.3 name although it doesn't correspond to long double in this 
case.


I have no preference, I'll go with whatever people like.

--
Marc Glisse

[fortran, patch] F2003 "non-default kind specifiers" compliance

[FX]

Hi all,

Our Fortran 2003 status page [1] says gfortran does not support "Kind type 
parameters of integer specifiers”. This item is defined thusly (item 4.9 in 
[2]):

> Some of the integer specifiers (e.g. NEXTREC) were limited to default kind in 
> Fortran 95. Any kind of integer is permitted in Fortran 2003.


I wanted to fix this, so I combed through the 95, 2003 and 2008 standards, and 
listed these changes. F2003 lifted all requirements on integer specifiers, and 
F2008 lifted requirements on logical specifiers. However, it appears that all 
of these are actually already handled in current trunk! So I’m proposing a 
simple two-fold action:

  - update the Fortran 2003 status to indicate our compliance
  - commit the attached testcase (bootstrapped and regtested on 
x86_64-apple-darwin) which will make sure we stay that way.

OK?


[1] https://gcc.gnu.org/wiki/Fortran2003Status
[2] ftp://ftp.nag.co.uk/sc22wg5/N1551-N1600/N1579.pdf


Index: gfortran.dg/nondefault_int_kind.f90
===
--- gfortran.dg/nondefault_int_kind.f90 (revision 0)
+++ gfortran.dg/nondefault_int_kind.f90 (working copy)
@@ -0,0 +1,26 @@
+! { dg-do compile }
+!
+! Test our conformance to item 4.9 ("Kind type parameters of integer
+! specifiers") of the Fortran 2003 status document at
+! ftp://ftp.nag.co.uk/sc22wg5/N1551-N1600/N1579.pdf
+!
+! The non-default logical variables are allowed since Fortran 2008.
+
+  integer(kind=8) :: i, j, k, n
+  logical(kind=8) :: l1, l2, l3
+
+  open(unit=10, status="scratch", iostat=i)
+
+  backspace(10, iostat=i)
+  endfile(10, iostat=i)
+  rewind(10, iostat=i)
+
+  read(*, '(I2)', advance='no', iostat=i, size=j) k
+
+  inquire(iolength=i) "42"
+  inquire(10, iostat=i, number=j, recl=k, nextrec=n)
+  inquire(10, exist=l1, opened=l2, named=l3)
+
+  close(unit=10, iostat=i)
+
+end

Re: __float128 typeinfo

[Jason Merrill]

On 06/06/2014 11:58 AM, Marc Glisse wrote:

On Fri, 6 Jun 2014, Jason Merrill wrote:


What's your rationale for keeping this in a separate version block
rather than in 1.3.9 (like __int128)?


Powerpc already has those symbols in CXXABI_LDBL_1.3 (for a type that
isn't __float128 but (de)mangles that way). That doesn't prevent from
using CXXABI_1.3.9 in the x86/ia64-specific file though, so I can do
that if you prefer. If a new target implements __float128 in 4.11 or
4.12, they will have to refine the configure test and provide a
different .ver file to avoid adding symbols to an old version.


Fair enough.  Let's stick with your approach then, but drop the 1.3.9 
from the name.


Why is __float128 handled as a target type, anyway?  I'd think it ought 
to be a standard type that just isn't supported on all targets, like 
__int128.


Jason

Re: __float128 typeinfo

[Joseph S. Myers]

On Fri, 6 Jun 2014, Jason Merrill wrote:

> On 06/06/2014 11:58 AM, Marc Glisse wrote:
> > On Fri, 6 Jun 2014, Jason Merrill wrote:
> > 
> > > What's your rationale for keeping this in a separate version block
> > > rather than in 1.3.9 (like __int128)?
> > 
> > Powerpc already has those symbols in CXXABI_LDBL_1.3 (for a type that
> > isn't __float128 but (de)mangles that way). That doesn't prevent from
> > using CXXABI_1.3.9 in the x86/ia64-specific file though, so I can do
> > that if you prefer. If a new target implements __float128 in 4.11 or
> > 4.12, they will have to refine the configure test and provide a
> > different .ver file to avoid adding symbols to an old version.
> 
> Fair enough.  Let's stick with your approach then, but drop the 1.3.9 from the
> name.
> 
> Why is __float128 handled as a target type, anyway?  I'd think it ought to be
> a standard type that just isn't supported on all targets, like __int128.

If we want something like that as a standard type not supported on all 
targets I'd think we should use the DTS 18661-3 naming (_Float128) and 
then make __float128 a typedef for that, at least for C.  (I don't know if 
C++ would want peculiarities such as _Float128 being a distinct type from 
long double even if they have the same representation and alignment, so a 
conservative approach would be for _Float128 not to exist for C++ unless 
it's distinct.  There are various other details in which _Float128 differs 
from __float128, e.g. it's a keyword and all _FloatN for N >= 128 and a 
multiple of 32 are keywords whether or not the type is supported.  I 
imagine any C++ bindings would look somewhat different, like the C++ 
bindings to decimal floating point.)

Both __float128 and __int128 names came from the x86_64 ABI.

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

Re: __float128 typeinfo

[Jason Merrill]

On 06/06/2014 12:54 PM, Joseph S. Myers wrote:

If we want something like that as a standard type not supported on all
targets I'd think we should use the DTS 18661-3 naming (_Float128)


Ah, I wasn't aware of that TS, thanks.  I'll check whether it's on the 
C++ committee agenda yet.


Jason

Re: [PATCH] proposed fix for bug # 61144

[Rich Felker]

On Fri, May 23, 2014 at 12:26:18PM -0600, Jeff Law wrote:
> On 05/21/14 21:59, Rich Felker wrote:
> >On Wed, May 21, 2014 at 11:17:53AM +0200, Richard Biener wrote:
> >>On Wed, May 21, 2014 at 3:59 AM, Rich Felker  wrote:
> >>>Bug # 61144 is a regression in 4.9.0 that breaks building of musl libc
> >>>due to aggressive and semantically-incorrect constant folding of weak
> >>>aliases. The attached patch seems to fix the issue. A weak alias
> >>>should never be a candidate for constant folding because it may always
> >>>be replaced by a strong definition from another translation unit.
> >>>
> >>>For details see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
> >>>
> >>>I do not have a copyright assignment on file but this patch should be
> >>>sufficiently trivial not to require it.
> >>
> >>Please add a testcase.  Also I wonder why it isn't better to generalize
> >
> >How should a testcase be done? On the PR there's a testcase that shows
> >the problem in the generated code, but no automated check for it.
> >Testing this is actually a bit of a pain unless you're allowed to run
> >the generated program.
> You can run the test program.  Have it exit (0) on success, abort ()
> on failure if at all possible.  Then drop the test source file into
> gcc/testsuite/gcc.c-torture/execute/pr61144.c

The test needs to be two translation units linked together: one with
a weak definition of the object as 0, and the other with a strong
definition. The test should show the weak value being used rather than
the strong one. But I'm not sure how this should be integrated with
the build process.

Is anyone from the gcc side willing to help on this? I'd really like
to get it fixed before the bug propagates into more releases and makes
longstanding weak alias semantics unreliable, but I'm not familiar
with gcc internals well enough to know if my existing patch is the
preferred fix or not, nor how to make a good test case.

Rich

Re: [PATCH] Trust TREE_ADDRESSABLE

[Eric Botcazou]

> Bootstrapped and tested on x86_64-unknown-linux-gnu for all
> languages including obj-c++, ada and go (yay), applied.

Something went wrong because this nevertheless introduced a regression:

FAIL: gnat.dg/aliasing3.adb execution test

In Ada we don't mark (external) variables as addressable if we don't see their 
address taken.

-- 
Eric Botcazou

Re: __float128 typeinfo

[Marc Glisse]

On Fri, 6 Jun 2014, Jason Merrill wrote:


On 06/06/2014 11:58 AM, Marc Glisse wrote:

On Fri, 6 Jun 2014, Jason Merrill wrote:


What's your rationale for keeping this in a separate version block
rather than in 1.3.9 (like __int128)?


Powerpc already has those symbols in CXXABI_LDBL_1.3 (for a type that
isn't __float128 but (de)mangles that way). That doesn't prevent from
using CXXABI_1.3.9 in the x86/ia64-specific file though, so I can do
that if you prefer. If a new target implements __float128 in 4.11 or
4.12, they will have to refine the configure test and provide a
different .ver file to avoid adding symbols to an old version.


Fair enough.  Let's stick with your approach then, but drop the 1.3.9 from 
the name.


Ok. To help with the review, I am appending the updated patch (untested). 
(if we add numeric_limits<__float128> later, I think it should go into 
GLIBCXX_FLOAT128_1)


Why is __float128 handled as a target type, anyway?  I'd think it ought to be 
a standard type that just isn't supported on all targets, like __int128.


I don't know. Since it is implemented in software on all platforms as far 
as I know, it shouldn't be that specific to a target. But it isn't just 
__float128, on some targets my patch may start generating extra symbols 
for half-floats (ARM) or __float80.


DJ Delorie's work on __intN may be a good direction for __floatN as well, 
IIUC we will have a global list of 4 __intN types, and the target decides 
the value of N for each of them, so we can refer to those type nodes in 
common code but they are still target-specific. Or maybe there isn't 
enough variety in float types to deserve this.


--
Marc GlisseIndex: gcc/cp/rtti.c
===
--- gcc/cp/rtti.c   (revision 211311)
+++ gcc/cp/rtti.c   (working copy)
@@ -1540,20 +1540,31 @@ emit_support_tinfos (void)
/*tag_scope=*/ts_current, false);
   pop_abi_namespace ();
   if (!COMPLETE_TYPE_P (bltn_type))
 return;
   dtor = CLASSTYPE_DESTRUCTORS (bltn_type);
   if (!dtor || DECL_EXTERNAL (dtor))
 return;
   doing_runtime = 1;
   for (ix = 0; fundamentals[ix]; ix++)
 emit_support_tinfo_1 (*fundamentals[ix]);
+
+  /* Search for an extra floating point type like __float128.  */
+  for (enum machine_mode mode = GET_CLASS_NARROWEST_MODE (MODE_FLOAT);
+   mode != VOIDmode;
+   mode = GET_MODE_WIDER_MODE (mode))
+{
+  tree type = c_common_type_for_mode (mode, false);
+  if (type && type != float_type_node && type != double_type_node
+ && type != long_double_type_node)
+   emit_support_tinfo_1 (type);
+}
 }
 
 /* Finish a type info decl. DECL_PTR is a pointer to an unemitted
tinfo decl.  Determine whether it needs emitting, and if so
generate the initializer.  */
 
 bool
 emit_tinfo_decl (tree decl)
 {
   tree type = TREE_TYPE (DECL_NAME (decl));
Index: libstdc++-v3/config/abi/pre/float128.ver
===
--- libstdc++-v3/config/abi/pre/float128.ver(revision 0)
+++ libstdc++-v3/config/abi/pre/float128.ver(working copy)
@@ -0,0 +1,10 @@
+# Appended to version file.
+
+CXXABI_FLOAT128 {
+
+# typeinfo and typeinfo name for __float128
+_ZT[IS]g;
+_ZT[IS]Pg;
+_ZT[IS]PKg;
+
+};
Index: libstdc++-v3/configure
===
--- libstdc++-v3/configure  (revision 211311)
+++ libstdc++-v3/configure  (working copy)
@@ -15698,20 +15698,23 @@ $as_echo "#define _GLIBCXX_USE_FLOAT128
 $as_echo "$enable_float128" >&6; }
 rm -f conftest*
 
   ac_ext=c
 ac_cpp='$CPP $CPPFLAGS'
 ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
 ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext 
$LIBS >&5'
 ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 
+if test "$enable_float128" = yes; then
+  port_specific_symbol_files="$port_specific_symbol_files 
\$(top_srcdir)/config/abi/pre/float128.ver"
+fi
 
 # Checks for compiler support that doesn't require linking.
 
   # All these tests are for C++; save the language and the compiler flags.
   # The CXXFLAGS thing is suspicious, but based on similar bits previously
   # found in GLIBCXX_CONFIGURE.
 
   ac_ext=cpp
 ac_cpp='$CXXCPP $CPPFLAGS'
 ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
Index: libstdc++-v3/configure.ac
===
--- libstdc++-v3/configure.ac   (revision 211311)
+++ libstdc++-v3/configure.ac   (working copy)
@@ -146,20 +146,23 @@ GLIBCXX_ENABLE_HOSTED
 # Enable descriptive messages to standard output on termination.
 GLIBCXX_ENABLE_VERBOSE
 
 # Enable compiler support that doesn't require linking.
 GLIBCXX_ENABLE_SJLJ_EXCEPTIONS
 GLIBCXX_ENABLE_PCH($is_hosted)
 GLIBCXX_ENABLE_THREADS
 GLIBCXX_ENABLE_ATOMIC_BUILTINS
 GLIBCXX_ENABLE_DECIMAL_FLOAT
 GLIBCXX_ENABLE_INT128_FLOAT128
+if test "$enable_float128" = yes; then

Re: [PATCH] Trust TREE_ADDRESSABLE

[Richard Biener]

On June 6, 2014 7:15:55 PM CEST, Eric Botcazou  wrote:
>> Bootstrapped and tested on x86_64-unknown-linux-gnu for all
>> languages including obj-c++, ada and go (yay), applied.
>
>Something went wrong because this nevertheless introduced a regression:
>
>FAIL: gnat.dg/aliasing3.adb execution test

Hmm, I don't see this.

>In Ada we don't mark (external) variables as addressable if we don't
>see their 
>address taken.

You have to (now).  The testing was of course to detect this...

Richard.

Re: patch to fix PR61325

[Vladimir Makarov]

On 2014-06-05, 8:37 AM, James Greenhalgh wrote:

On Wed, Jun 04, 2014 at 08:00:51PM +0100, Vladimir Makarov wrote:

 From my perspective, I think this should go in, and be backported to 4.9.



I've committed it as rev. 211320 for trunk and rev. 211319 for gcc-4.9 
branch.


2014-06-06  Vladimir Makarov  

* lra-constraints.c (process_address_1): Check scale equal to one
to prevent transformation: base + scale * index => base + new_reg.

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 211061)
+++ lra-constraints.c   (working copy)
@@ -2974,6 +2974,13 @@ process_address_1 (int nop, rtx *before,
   *ad.inner = simplify_gen_binary (PLUS, GET_MODE (new_reg),
   new_reg, *ad.index);
 }
+  else if (get_index_scale (&ad) == 1)
+{
+  /* The last transformation to one reg will be made in
+curr_insn_transform function.  */
+  end_sequence ();
+  return false;
+}
   else
 {
   /* base + scale * index => base + new_reg,

Re: __float128 typeinfo

[Michael Meissner]

On Fri, Jun 06, 2014 at 07:21:03PM +0200, Marc Glisse wrote:
> DJ Delorie's work on __intN may be a good direction for __floatN as
> well, IIUC we will have a global list of 4 __intN types, and the
> target decides the value of N for each of them, so we can refer to
> those type nodes in common code but they are still target-specific.
> Or maybe there isn't enough variety in float types to deserve this.

One of the problems I've been having with IEEE floating point on PowerPC is the
number of bits is not the only measure.  The IBM double-double format that is
currently used for long double is 128 bits as is the IEEE 128-bit floating
point.  So, in theory __float128 could be used for the IBM double-double
format.  There might be other places where an implementation has 2 floating
point formats of the same size.

One of the things I need to do to the basic internals, is provide an option so
that __float128 does not widen to a larger type or have smaller types widen to
it.

Another problem with the current __float128 on x86 is it isn't a base type, so
you have do something like the following:

typedef _Complex float __attribute__((mode(TC))) _Complex128;

It would be nice to have a standard name for IEEE 128-bit floating point,
whether it is a defacto standard like __float128, or something in future
standards like _Float128.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[PATCH, i386]: Fix PR 61423, incorrect conversion from unsigned int to floating point

[Uros Bizjak]

Hello!

Attached patch fixes PR 61423. The problem was that splitters omitted
apparently necessary zero extension, and left garbage in the highpart
of the register.

2014-06-06  Uros Bizjak  

PR target/61423
* config/i386/i386.md (*floatunssi2_i387_with_xmm): New
define_insn_and_split pattern, merged from *floatunssi2_1
and corresponding splitters.  Zero extend general register
or memory input operand to XMM temporary.  Enable for
TARGET_SSE2 and TARGET_INTER_UNIT_MOVES_TO_VEC only.
(floatunssi2): Update expander predicate.

testsuite/ChangeLog:

2014-06-06  Uros Bizjak  

PR target/61423
* gcc.target/i386/pr61423.c: New test.

The patch was bootstrapped and regression tested on
x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.

Please note that the patch breaks bootstrap when gcc is configured
with "--with-arch=core-avx-i --with-cpu=core-avx-i" due to an
unrelated problem in REE pass. The failing preprocessed source from
the libgcc is attached to the PR.

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 211316)
+++ config/i386/i386.md (working copy)
@@ -4943,66 +4943,37 @@
 
 ;; Avoid store forwarding (partial memory) stall penalty by extending
 ;; SImode value to DImode through XMM register instead of pushing two
-;; SImode values to stack. Note that even !TARGET_INTER_UNIT_MOVES_TO_VEC
-;; targets benefit from this optimization. Also note that fild
-;; loads from memory only.
+;; SImode values to stack. Also note that fild loads from memory only.
 
-(define_insn "*floatunssi2_1"
-  [(set (match_operand:X87MODEF 0 "register_operand" "=f,f")
+(define_insn_and_split "*floatunssi2_i387_with_xmm"
+  [(set (match_operand:X87MODEF 0 "register_operand" "=f")
(unsigned_float:X87MODEF
- (match_operand:SI 1 "nonimmediate_operand" "x,m")))
-   (clobber (match_operand:DI 2 "memory_operand" "=m,m"))
-   (clobber (match_scratch:SI 3 "=X,x"))]
+ (match_operand:SI 1 "nonimmediate_operand" "rm")))
+   (clobber (match_scratch:DI 3 "=x"))
+   (clobber (match_operand:DI 2 "memory_operand" "=m"))]
   "!TARGET_64BIT
&& TARGET_80387 && X87_ENABLE_FLOAT (mode, DImode)
-   && TARGET_SSE"
+   && TARGET_SSE2 && TARGET_INTER_UNIT_MOVES_TO_VEC"
   "#"
+  "&& reload_completed"
+  [(set (match_dup 3) (zero_extend:DI (match_dup 1)))
+   (set (match_dup 2) (match_dup 3))
+   (set (match_dup 0)
+   (float:X87MODEF (match_dup 2)))]
+  ""
   [(set_attr "type" "multi")
(set_attr "mode" "")])
 
-(define_split
-  [(set (match_operand:X87MODEF 0 "register_operand")
-   (unsigned_float:X87MODEF
- (match_operand:SI 1 "register_operand")))
-   (clobber (match_operand:DI 2 "memory_operand"))
-   (clobber (match_scratch:SI 3))]
-  "!TARGET_64BIT
-   && TARGET_80387 && X87_ENABLE_FLOAT (mode, DImode)
-   && TARGET_SSE
-   && reload_completed"
-  [(set (match_dup 2) (match_dup 1))
-   (set (match_dup 0)
-   (float:X87MODEF (match_dup 2)))]
-  "operands[1] = simplify_gen_subreg (DImode, operands[1], SImode, 0);")
-
-(define_split
-  [(set (match_operand:X87MODEF 0 "register_operand")
-   (unsigned_float:X87MODEF
- (match_operand:SI 1 "memory_operand")))
-   (clobber (match_operand:DI 2 "memory_operand"))
-   (clobber (match_scratch:SI 3))]
-  "!TARGET_64BIT
-   && TARGET_80387 && X87_ENABLE_FLOAT (mode, DImode)
-   && TARGET_SSE
-   && reload_completed"
-  [(set (match_dup 2) (match_dup 3))
-   (set (match_dup 0)
-   (float:X87MODEF (match_dup 2)))]
-{
-  emit_move_insn (operands[3], operands[1]);
-  operands[3] = simplify_gen_subreg (DImode, operands[3], SImode, 0);
-})
-
 (define_expand "floatunssi2"
   [(parallel
  [(set (match_operand:X87MODEF 0 "register_operand")
   (unsigned_float:X87MODEF
 (match_operand:SI 1 "nonimmediate_operand")))
-  (clobber (match_dup 2))
-  (clobber (match_scratch:SI 3))])]
+  (clobber (match_scratch:DI 3))
+  (clobber (match_dup 2))])]
   "!TARGET_64BIT
&& ((TARGET_80387 && X87_ENABLE_FLOAT (mode, DImode)
-   && TARGET_SSE)
+   && TARGET_SSE2 && TARGET_INTER_UNIT_MOVES_TO_VEC)
|| (SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH))"
 {
   if (SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
Index: testsuite/gcc.target/i386/pr61423.c
===
--- testsuite/gcc.target/i386/pr61423.c (revision 0)
+++ testsuite/gcc.target/i386/pr61423.c (working copy)
@@ -0,0 +1,38 @@
+/* PR target/61423 */
+/* { dg-do run { target ia32 } } */
+/* { dg-options "-O1 -ftree-vectorize -msse2 -mfpmath=387 -mtune=core2" } */
+
+#define N 1024
+static unsigned int A[N];
+
+double
+__attribute__((noinline))
+func (void)
+{
+  unsigned int sum = 0;
+  unsigned i;
+  double t;
+
+  for (i = 0; i < N; i++)
+sum += A[i];
+
+  t = sum;
+  return t;
+}
+
+int
+main ()
+{
+  unsigned i;
+  double d;
+
+  for(i = 0; i < N; i++)
+A[i] = 1;
+
+  d

Re: __float128 typeinfo

[Joseph S. Myers]

On Fri, 6 Jun 2014, Marc Glisse wrote:

> DJ Delorie's work on __intN may be a good direction for __floatN as well, IIUC
> we will have a global list of 4 __intN types, and the target decides the value
> of N for each of them, so we can refer to those type nodes in common code but
> they are still target-specific. Or maybe there isn't enough variety in float
> types to deserve this.

The binary types in TS 18661-3 are:

- _FloatN, where N is 16, 32, 64, or >= 128 and a multiple of 32
- _Float32x
- _Float64x
- _Float128x

(_Float32, _Float64, _Float32x required; the first two same representation 
and alignment as float and double; other types optional.  _Float32x likely 
to be same representation and alignment as double.  _Float64x likely to be 
same representation and alignment as __float80 where that's supported, or 
__float128 where that's supported but __float80 isn't.  All of these types 
have IEEE semantics for their operations, so IBM long double would not be 
used for any of them.  All these types are distinct from each other and 
from float / double / long double.  All these types have corresponding 
_Complex types.  Obviously there are ABI issues with compatibility with 
other implementations when supporting these types, although I doubt there 
will be much difficulty with those in practice.  To support these in C++ 
you'd need mangling defined.)

I don't really expect anything other than _Float16, _Float32, _Float64, 
_Float128, _Float32x (= binary64), _Float64x (= __float80 or binary128) to 
be widely used in the near future, though you might still want generic 
_FloatN support (and would need it to a certain extent, to process 
unsupported types meeting the given pattern as keywords rather than 
identifiers then give an error that the type isn't supported).

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

[PATCH], PowerPC PR 61431, Fix little endian word swapping for 128-bit types

[Michael Meissner]

The pack01.c test fails on GCC 4.8 on little endian power8 systems. In looking
at it, it is a bug where the V1TI memory operations do not have the word
swapping define_split support.  GCC 4.9 and trunk can optimize the union to
stay in a register, so the test case passes on those systems, but it is still a
bug that would be exposed if you ever need to store vector __int128 values.
The test p8vector-int128-2.c is such a case, and it needs the fix.

I've tested this via bootstrap and make check on power8 big and little endian
systems, and there were no regressions.  The test p8vector-int128-2.c now
passes on the little endian power8 with this fix.

Are these patches ok to check into the trunk, and 4.9/4.8 branches?

2014-06-06  Michael Meissner  

PR target/61431
* config/rs6000/vsx.md (VSX_LE): Split VSX_D into 2 separate
iterators, VSX_D that handles 64-bit types, and VSX_LE that
handles swapping the two 64-bit double words on little endian
systems.  Include V1TImode and optionally TImode in VSX_LE so that
these types are properly swapped.  Change all of the insns and
splits that do the 64-bit swaps to use VSX_LE.
(vsx_le_perm_load_): Likewise.
(vsx_le_perm_store_): Likewise.
(splitters for little endian memory operations): Likewise.
(vsx_xxpermdi2_le_): Likewise.
(vsx_lxvd2x2_le_): Likewise.
(vsx_stxvd2x2_le_): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 211316)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -24,6 +24,13 @@ (define_mode_iterator VSX_B [DF V4SF V2D
 ;; Iterator for the 2 64-bit vector types
 (define_mode_iterator VSX_D [V2DF V2DI])
 
+;; Iterator for the 2 64-bit vector types + 128-bit types that are loaded with
+;; lxvd2x to properly handle swapping words on little endian
+(define_mode_iterator VSX_LE [V2DF
+ V2DI
+ V1TI
+ (TI   "VECTOR_MEM_VSX_P (TImode)")])
+
 ;; Iterator for the 2 32-bit vector types
 (define_mode_iterator VSX_W [V4SF V4SI])
 
@@ -228,8 +235,8 @@ (define_c_enum "unspec"
 ;; The patterns for LE permuted loads and stores come before the general
 ;; VSX moves so they match first.
 (define_insn_and_split "*vsx_le_perm_load_"
-  [(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa")
-(match_operand:VSX_D 1 "memory_operand" "Z"))]
+  [(set (match_operand:VSX_LE 0 "vsx_register_operand" "=wa")
+(match_operand:VSX_LE 1 "memory_operand" "Z"))]
   "!BYTES_BIG_ENDIAN && TARGET_VSX"
   "#"
   "!BYTES_BIG_ENDIAN && TARGET_VSX"
@@ -342,16 +349,16 @@ (define_insn_and_split "*vsx_le_perm_loa
(set_attr "length" "8")])
 
 (define_insn "*vsx_le_perm_store_"
-  [(set (match_operand:VSX_D 0 "memory_operand" "=Z")
-(match_operand:VSX_D 1 "vsx_register_operand" "+wa"))]
+  [(set (match_operand:VSX_LE 0 "memory_operand" "=Z")
+(match_operand:VSX_LE 1 "vsx_register_operand" "+wa"))]
   "!BYTES_BIG_ENDIAN && TARGET_VSX"
   "#"
   [(set_attr "type" "vecstore")
(set_attr "length" "12")])
 
 (define_split
-  [(set (match_operand:VSX_D 0 "memory_operand" "")
-(match_operand:VSX_D 1 "vsx_register_operand" ""))]
+  [(set (match_operand:VSX_LE 0 "memory_operand" "")
+(match_operand:VSX_LE 1 "vsx_register_operand" ""))]
   "!BYTES_BIG_ENDIAN && TARGET_VSX && !reload_completed"
   [(set (match_dup 2)
 (vec_select:
@@ -369,8 +376,8 @@ (define_split
 ;; The post-reload split requires that we re-permute the source
 ;; register in case it is still live.
 (define_split
-  [(set (match_operand:VSX_D 0 "memory_operand" "")
-(match_operand:VSX_D 1 "vsx_register_operand" ""))]
+  [(set (match_operand:VSX_LE 0 "memory_operand" "")
+(match_operand:VSX_LE 1 "vsx_register_operand" ""))]
   "!BYTES_BIG_ENDIAN && TARGET_VSX && reload_completed"
   [(set (match_dup 1)
 (vec_select:
@@ -1353,9 +1360,9 @@ (define_insn "vsx_concat_v2sf"
 ;; xxpermdi for little endian loads and stores.  We need several of
 ;; these since the form of the PARALLEL differs by mode.
 (define_insn "*vsx_xxpermdi2_le_"
-  [(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa")
-(vec_select:VSX_D
-  (match_operand:VSX_D 1 "vsx_register_operand" "wa")
+  [(set (match_operand:VSX_LE 0 "vsx_register_operand" "=wa")
+(vec_select:VSX_LE
+  (match_operand:VSX_LE 1 "vsx_register_operand" "wa")
   (parallel [(const_int 1) (const_int 0)])))]
   "!BYTES_BIG_ENDIAN && VECTOR_MEM_VSX_P (mode)"
   "xxpermdi %x0,%x1,%x1,2"
@@ -1402,9 +1409,9 @@ (define_insn "*vsx_xxpermdi16_le_V16QI"
 ;; lxvd2x for little endian loads.  We need several of
 ;; these since the form of the PARALLEL dif

[fortran, patch] Audit and patch of F95 and F2003 "non-default kind specifiers" warnings

[FX]

> It seems that some of these extensions are not caught by -std=f95

I’ve now audited the I/O specifiers for such warnings too. A warning existed 
only for EXIST, which was introduced way back by Steve:

> 2010-07-05  Steven G. Kargl  
> 
> PR fortran/44797
> * fortran/io.c (resolve_tag): Check EXIST tag is a default logical.

I’ve extended the logical warning to the NAMED, OPENED, and PENDING specifiers. 
I’ve also audited the integer specifiers, and extended the warning to NUMBER, 
NEXTREC, and RECL, which were missing.

Bootstrapped and regtested on x86_64-apple-darwin13, OK to commit?

FX




io_diagnostics.ChangeLog
Description: Binary data


io_diagnostics.diff
Description: Binary data

Re: [fortran, patch] F2003 "non-default kind specifiers" compliance

[Steve Kargl]

On Fri, Jun 06, 2014 at 06:21:02PM +0200, FX wrote:
> Hi all,
> 
> Our Fortran 2003 status page [1] says gfortran does not support "Kind type 
> parameters of integer specifiers?. This item is defined thusly (item 4.9 in 
> [2]):
> 
> > Some of the integer specifiers (e.g. NEXTREC) were limited to default kind 
> > in Fortran 95. Any kind of integer is permitted in Fortran 2003.
> 
> 
> I wanted to fix this, so I combed through the 95, 2003 and 2008 standards, 
> and listed these changes. F2003 lifted all requirements on integer 
> specifiers, and F2008 lifted requirements on logical specifiers. However, it 
> appears that all of these are actually already handled in current trunk! So 
> I?m proposing a simple two-fold action:
> 
>   - update the Fortran 2003 status to indicate our compliance
>   - commit the attached testcase (bootstrapped and regtested on 
> x86_64-apple-darwin) which will make sure we stay that way.
> 
> OK?

This is OK with me.

-- 
Steve

Re: [fortran, patch] Audit and patch of F95 and F2003 "non-default kind specifiers" warnings

[Steve Kargl]

On Fri, Jun 06, 2014 at 09:38:06PM +0200, FX wrote:
> > It seems that some of these extensions are not caught by -std=f95
> 
> I?ve now audited the I/O specifiers for such warnings too. A warning existed 
> only for EXIST, which was introduced way back by Steve:
> 
> > 2010-07-05  Steven G. Kargl  
> > 
> > PR fortran/44797
> > * fortran/io.c (resolve_tag): Check EXIST tag is a default logical.
> 
> I?ve extended the logical warning to the NAMED, OPENED, and PENDING 
> specifiers. I?ve also audited the integer specifiers, and extended the 
> warning to NUMBER, NEXTREC, and RECL, which were missing.
> 
> Bootstrapped and regtested on x86_64-apple-darwin13, OK to commit?
> 

Yes.

-- 
Steve

Re: [fortran, patch] Audit and patch of F95 and F2003 "non-default kind specifiers" warnings

[FX]

> I’ve extended the logical warning to the NAMED, OPENED, and PENDING 
> specifiers. I’ve also audited the integer specifiers, and extended the 
> warning to NUMBER, NEXTREC, and RECL, which were missing.
> 
> Bootstrapped and regtested on x86_64-apple-darwin13, OK to commit?

Committed as rev. 211323.

FX

Re: [Patch ARM/testsuite 00/22] Neon intrinsics executable tests

[Christophe Lyon]

On 6 June 2014 17:57, Ramana Radhakrishnan  wrote:
> On 06/06/14 15:40, Christophe Lyon wrote:
>>
>> On 6 June 2014 01:32, Joseph S. Myers  wrote:
>>>
>>> Have these been tested for both big and little endian (especially for
>>> tests where memory layout matters - load / store / lane number tests -
>>> remembering that GNU C vector initializers always use array ordering,
>>> which is not the same as the architecture-defined lane numbering for big
>>> endian)?
>>>
>>
>> I did run the tests on armeb-none-linux-gnueabihf (with qemu), and in
>> addition to the FAILs I already mentionned I can see errors in the
>> vzip and vuzp tests.
>> At this stage I don't know if it's a bug in my tests or a compiler bug.
>
>
> Didn't Alan recently fix a bug for big-endian in vzip / vuzp ?
>
> PR target/61062
>
> Ramana
>
Maybe, but this hasn't been committed yet, so I didn't test with this fix.

Christophe.

Back

[Sebastian Pop]

Hi,
I will commit the attached patch.

Sebastian
From 32fa3756f5c41be16d92fd176ec5e42bfdcbb643 Mon Sep 17 00:00:00 2001
From: Sebastian Pop 
Date: Fri, 6 Jun 2014 15:56:33 -0500
Subject: [PATCH] update my email address

2014-06-06  Sebastian Pop  

* MAINTAINERS: Update my email address.
---
 ChangeLog   |4 
 MAINTAINERS |6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 80e9600..890e0b5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2014-06-06  Sebastian Pop  
+
+	* MAINTAINERS: Update my email address.
+
 2014-06-04  Thomas Preud'homme  
 
 	* MAINTAINERS (Write After Approval): Add myself.
diff --git a/MAINTAINERS b/MAINTAINERS
index 71206e7..9130935 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -238,9 +238,9 @@ tree-ssa		Diego Novillo		dnovi...@google.com
 tree-ssa		Andrew MacLeod		amacl...@redhat.com
 PRE			Daniel Berlin		dber...@dberlin.org
 code sinking		Daniel Berlin		dber...@dberlin.org
-tree browser/unparser	Sebastian Pop		sebastian@amd.com
+tree browser/unparser	Sebastian Pop		seb...@gmail.com
 scev, data dependence	Daniel Berlin		dber...@dberlin.org
-scev, data dependence	Sebastian Pop		sebastian@amd.com
+scev, data dependence	Sebastian Pop		seb...@gmail.com
 profile feedback	Jan Hubicka		hubi...@ucw.cz
 type-safe vectors	Nathan Sidwell		nat...@codesourcery.com
 alias analysis		Daniel Berlin		dber...@dberlin.org
@@ -283,7 +283,7 @@ Fortran			Paul Thomas		pa...@gcc.gnu.org
 Fortran			Janus Weil		ja...@gcc.gnu.org
 Graphite		Daniel Berlin		dber...@dberlin.org
 Graphite 		Tobias Grosser		gros...@fim.uni-passau.de
-Graphite		Sebastian Pop		sebastian@amd.com
+Graphite		Sebastian Pop		seb...@gmail.com
 libcpp			Tom Tromey		tro...@redhat.com
 libsanitizer, asan.c	Jakub Jelinek		ja...@redhat.com
 libsanitizer, asan.c	Dodji Seketeli		do...@redhat.com
-- 
1.7.9.5

Re: [PATCH], PowerPC PR 61431, Fix little endian word swapping for 128-bit types

[David Edelsohn]

On Fri, Jun 6, 2014 at 3:02 PM, Michael Meissner
 wrote:
> The pack01.c test fails on GCC 4.8 on little endian power8 systems. In looking
> at it, it is a bug where the V1TI memory operations do not have the word
> swapping define_split support.  GCC 4.9 and trunk can optimize the union to
> stay in a register, so the test case passes on those systems, but it is still 
> a
> bug that would be exposed if you ever need to store vector __int128 values.
> The test p8vector-int128-2.c is such a case, and it needs the fix.
>
> I've tested this via bootstrap and make check on power8 big and little endian
> systems, and there were no regressions.  The test p8vector-int128-2.c now
> passes on the little endian power8 with this fix.
>
> Are these patches ok to check into the trunk, and 4.9/4.8 branches?
>
> 2014-06-06  Michael Meissner  
>
> PR target/61431
> * config/rs6000/vsx.md (VSX_LE): Split VSX_D into 2 separate
> iterators, VSX_D that handles 64-bit types, and VSX_LE that
> handles swapping the two 64-bit double words on little endian
> systems.  Include V1TImode and optionally TImode in VSX_LE so that
> these types are properly swapped.  Change all of the insns and
> splits that do the 64-bit swaps to use VSX_LE.
> (vsx_le_perm_load_): Likewise.
> (vsx_le_perm_store_): Likewise.
> (splitters for little endian memory operations): Likewise.
> (vsx_xxpermdi2_le_): Likewise.
> (vsx_lxvd2x2_le_): Likewise.
> (vsx_stxvd2x2_le_): Likewise.

okay.

Thanks, David

Committed: fix MMIX LTO gcc.dg/torture/stackalign/builtin-return-1.c

[Hans-Peter Nilsson]

Apparently LTO improved or at least changed between r21 and
r211121, such that memory outside the defined space was wrongly read
as "expected" for this test-case, corresponding to the wrongly
presumed stacked parameters.  For a "normal" target this would
correspond to a SEGV.  You'd need the memory-strictness change file (a
sort-of CWEB patch) from
 to see this
when testing with the mmixware mmix simulator:

Running 
/home/hp/gcctop/tmp/mbase1/gcc/gcc/testsuite/gcc.dg/torture/stackalign/stackalign.exp
 ...
FAIL: gcc.dg/torture/stackalign/builtin-return-1.c  -O2 -flto 
-fuse-linker-plugin -fno-fat-lto-objects  execution test

and in gcc.log:
spawn mmix ./builtin-return-1.exe
 1. 03ec: 8d10fd20 (LDOI) $16=l[25] = 
M8[#16809fe0+32] = 0
  198 instructions, 49 mems, 236 oops; 4 good guesses, 7 bad
  (now at location #03f0)

(for the default Knuth ABI; but the error for the GNU ABI is similar)

This also annotates as fixed an age-old PR, though test has actually
been passing for some time after "Tue Nov 9 00:36:20 UTC 2004" (yes,
this was CVS time) and up-to-and-including at least r21.  I wrote
this fix when investigating fallout from the memory-strictness feature
mentioned above, but as this test didn't fail at that time, I didn't
apply it.

Committed.

PR target/18343
* gcc.dg/torture/stackalign/builtin-return-1.c (STACK_ARGUMENTS_SIZE):
New macro, 0 for __MMIX__, default 64.
(bar): Pass it to __builtin_apply instead of literal 64.

Index: gcc/testsuite/gcc.dg/torture/stackalign/builtin-return-1.c
===
--- gcc/testsuite/gcc.dg/torture/stackalign/builtin-return-1.c  (revision 
211328)
+++ gcc/testsuite/gcc.dg/torture/stackalign/builtin-return-1.c  (working copy)
@@ -5,6 +5,13 @@
 /* This used to fail on SPARC because the (undefined) return
value of 'bar' was overwriting that of 'foo'.  */

+#ifdef __MMIX__
+/* No parameters on stack for bar.  */
+#define STACK_ARGUMENTS_SIZE 0
+#else
+#define STACK_ARGUMENTS_SIZE 64
+#endif
+
 extern void abort(void);

 int foo(int n)
@@ -14,7 +21,8 @@ int foo(int n)

 int bar(int n)
 {
-  __builtin_return(__builtin_apply((void (*)(void))foo, 
__builtin_apply_args(), 64));
+  __builtin_return(__builtin_apply((void (*)(void))foo, __builtin_apply_args(),
+  STACK_ARGUMENTS_SIZE));
 }

 char *g;

brgds, H-P

Re: __float128 typeinfo

[Richard Earnshaw]

On 06/06/14 16:25, Ramana Radhakrishnan wrote:
> On Fri, Jun 6, 2014 at 3:16 PM, Marc Glisse  wrote:
>> Hello,
>>
>> here is a new try on adding __float128 typeinfo to libsupc++. The front-end
>> part is based on the discussion with Jason yesterday. The libstdc++ part is
>> copied from:
>> https://gcc.gnu.org/ml/libstdc++/2014-04/msg00077.html
>> (which wasn't reviewed), but I changed the testsuite.
>>
>> Michael will likely need to make some adjustments to his __float128 patch,
>> but I believe it will only be a small configure tweak.
>>
>> Ramana, does it look safe for ARM? By the way, do you want to remove the
>> XFmode defined in arm-modes.def and apparently unused?
> 
> Thanks for this though I know Tejas is actually trying to fix AArch64
> first and then we'll move on to ARM for cleaning up all these types -
> as you realize it's quite a chunky project.
> 
> A patch to remove XFmode is pre-approved. I have no idea why this is
> in here. Archeaology shows this came in
> 
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@72440
> 
> and with a FIXME:
> 
> I'll try and have a look at this patch later today or over the weekend
> to see if it doesn't affect ARM / AArch64.
> 


XFmode should have been removed on ARM when the FPA code was expunged.

In fact, it was only briefly used on ARM many, many, years ago when I
tried to use the FPA's extended double-precision format for long double.
 That change was backed out when it turned out that some machines of
that era would hang hard (BRS time) in the RISC iX kernel due to a bug
in the floating-point emulation code for handling denormals.

R.

Re: [PATCH, libgfortran] Add overflow check to xmalloc

[Janne Blomqvist]

PING #2

On Fri, May 30, 2014 at 5:53 PM, Janne Blomqvist
 wrote:
> PING
>
> On Tue, May 20, 2014 at 12:42 AM, Janne Blomqvist
>  wrote:
>> On Thu, May 15, 2014 at 1:00 AM, Janne Blomqvist
>>  wrote:
>>> Hi,
>>>
>>> a common malloc() pattern is "malloc(num_foo * sizeof(foo_t)", that
>>> is, create space for an array of type foo_t with num_foo elements.
>>> There is a slight danger here in that the multiplication can overflow
>>> and wrap around, and then the caller thinks it has a larger array than
>>> what malloc has actually created. The attached patch changes the
>>> libgfortran xmalloc() function to have an API similar to calloc() with
>>> two arguments, and the implementation checks for wraparound.
>>
>> Hello,
>>
>> attached is an updated patch which instead introduces a new function,
>> xmallocarray, with the overflow check, and leaves the existing xmalloc
>> as is. Thus avoiding the extra checking in the common case where one
>> of the arguments to xmallocarray would be 1.
>>
>> Tested on x86_64-unknown-linux-gnu, Ok for trunk?
>>
>> 2014-05-20  Janne Blomqvist  
>>
>> * libgfortran.h (xmallocarray): New prototype.
>> * runtime/memory.c (xmallocarray): New function.
>> (xcalloc): Check for nonzero separately instead of multiplying.
>> * generated/*.c: Regenerated.
>> * intrinsics/cshift0.c (cshift0): Call xmallocarray instead of
>> xmalloc.
>> * intrinsics/eoshift0.c (eoshift0): Likewise.
>> * intrinsics/eoshift2.c (eoshift2): Likewise.
>> * intrinsics/pack_generic.c (pack_internal): Likewise.
>> (pack_s_internal): Likewise.
>> * intrinsics/reshape_generic.c (reshape_internal): Likewise.
>> * intrinsics/spread_generic.c (spread_internal): Likewise.
>> (spread_internal_scalar): Likewise.
>> * intrinsics/string_intrinsics_inc.c (string_trim): Likewise.
>> (string_minmax): Likewise.
>> * intrinsics/transpose_generic.c (transpose_internal): Likewise.
>> * intrinsics/unpack_generic.c (unpack_internal): Likewise.
>> * io/list_read.c (nml_touch_nodes): Don't cast xmalloc return value.
>> * io/transfer.c (st_set_nml_var): Call xmallocarray instead of
>> xmalloc.
>> * io/unit.c (get_internal_unit): Likewise.
>> (filename_from_unit): Don't cast xmalloc return value.
>> * io/write.c (nml_write_obj): Likewise, formatting.
>> * m4/bessel.m4 (bessel_jn_r'rtype_kind`): Call xmallocarray
>> instead of xmalloc.
>> (besse_yn_r'rtype_kind`): Likewise.
>> * m4/cshift1.m4 (cshift1): Likewise.
>> * m4/eoshift1.m4 (eoshift1): Likewise.
>> * m4/eoshift3.m4 (eoshift3): Likewise.
>> * m4/iforeach.m4: Likewise.
>> * m4/ifunction.m4: Likewise.
>> * m4/ifunction_logical.m4 (name`'rtype_qual`_'atype_code):
>> Likewise.
>> * m4/in_pack.m4 (internal_pack_'rtype_ccode`): Likewise.
>> * m4/matmul.m4 (matmul_'rtype_code`): Likewise.
>> * m4/matmull.m4 (matmul_'rtype_code`): Likewise.
>> * m4/pack.m4 (pack_'rtype_code`): Likewise.
>> * m4/reshape.m4 (reshape_'rtype_ccode`): Likewise.
>> * m4/shape.m4 (shape_'rtype_kind`): Likewise.
>> * m4/spread.m4 (spread_'rtype_code`): Likewise.
>> (spread_scalar_'rtype_code`): Likewise.
>> * m4/transpose.m4 (transpose_'rtype_code`): Likewise.
>> * m4/unpack.m4 (unpack0_'rtype_code`): Likewise.
>> (unpack1_'rtype_code`): Likewise.
>> * runtime/convert_char.c (convert_char1_to_char4): Likewise.
>> (convert_char4_to_char1): Simplify.
>> * runtime/environ.c (init_unformatted): Call xmallocarray instead
>> of xmalloc.
>> * runtime/in_pack_generic.c (internal_pack): Likewise.
>>
>>
>>
>>
>> --
>> Janne Blomqvist
>
>
>
> --
> Janne Blomqvist



-- 
Janne Blomqvist

Re: [PATCH, libgfortran] PR 56981 Flush buffer at record boundaries

[Janne Blomqvist]

PING

On Tue, May 27, 2014 at 11:50 PM, Janne Blomqvist
 wrote:
> Hi,
>
> the attached patch implements the idea in
> https://gcc.gnu.org/ml/fortran/2013-04/msg00258.html ; though it
> turned out it was much simpler than what I envisaged back then. With
> this patch, we no longer seek back and forth when writing small
> records with sequential unformatted, which previously happened due to
> the buffer filling up when not on record boundaries.
> Performance-wise, I didn't really see any difference on Linux/tmpfs,
> but maybe it makes a difference in other circumstances. And of course,
> as a side-effect, it makes sequential unformatted work on unseekable
> devices such as pipes as long as the records are small, although I'm
> not sure this is something we want to advertise to users.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>
> 2014-05-27  Janne Blomqvist  
>
> PR libfortran/56981
> * io/unix.h (struct stream_vtable): Add new member function,
> markeor.
> (smarkeor): New inline function.
> (flush_if_unbuffered): Remove prototype.
> * io/unix.c (raw_markeor): New function.
> (raw_vtable): Initialize markeor member.
> (buf_markeor): New function.
> (buf_vtable): Initialize markeor member.
> (mem_vtable): Likewise.
> (mem4_vtable): Likewise.
> (flush_if_unbuffered): Remove function.
> * io/transfer.c (next_record): Call smarkeor instead of
> flush_if_unbuffered.
>
>
> --
> Janne Blomqvist



-- 
Janne Blomqvist

Re: std::quoted doesn't respect padding

[Ed Smith-Rowland]

On 06/06/2014 10:27 AM, Jonathan Wakely wrote:

On 06/06/14 10:08 -0400, Ed Smith-Rowland wrote:

I'll look at rdbuf. Error in rdbuf? Do I need to do something?


No, just me being dumb. The ostream::operator<<(streambuf*) overload
behaves as an unformatted output function, so won't obey the padding,
which is exactly what you're trying to fix.  Sorry for suggesting it.



As committed..

I'll backport to 4.9 tomorrow or Sunday.

2014-06-06  Ed Smith-Rowland  <3dw...@verizon.net>

DR 2344 - std::quoted doesn't respect padding
* include/std/iomanip: Allow for padding in quoted inserters.
* testsuite/27_io/manipulators/standard/char/dr2344.cc: New.
* testsuite/27_io/manipulators/standard/wchar_t/dr2344.cc: New.

Index: include/std/iomanip
===
--- include/std/iomanip (revision 211313)
+++ include/std/iomanip (working copy)
@@ -41,7 +41,10 @@
 
 #if __cplusplus >= 201103L
 #include 
+#if __cplusplus > 201103L
+#include  // used in quoted.
 #endif
+#endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -342,7 +345,6 @@
 
 /**
  * @brief Struct for delimited strings.
- *The left and right delimiters can be different.
  */
 template
   struct _Quoted_string
@@ -364,8 +366,10 @@
   };
 
 /**
- * @brief Inserter for delimited strings.
- *The left and right delimiters can be different.
+ * @brief Inserter for quoted strings.
+ *
+ *  _GLIBCXX_RESOLVE_LIB_DEFECTS
+ *  DR 2344 quoted()'s interaction with padding is unclear
  */
 template
   auto&
@@ -372,21 +376,24 @@
   operator<<(std::basic_ostream<_CharT, _Traits>& __os,
 const _Quoted_string& __str)
   {
-   __os << __str._M_delim;
+   std::basic_ostringstream<_CharT, _Traits> __ostr;
+   __ostr << __str._M_delim;
for (const _CharT* __c = __str._M_string; *__c; ++__c)
  {
if (*__c == __str._M_delim || *__c == __str._M_escape)
- __os << __str._M_escape;
-   __os << *__c;
+ __ostr << __str._M_escape;
+   __ostr << *__c;
  }
-   __os << __str._M_delim;
+   __ostr << __str._M_delim;
 
-   return __os;
+   return __os << __ostr.str();
   }
 
 /**
- * @brief Inserter for delimited strings.
- *The left and right delimiters can be different.
+ * @brief Inserter for quoted strings.
+ *
+ *  _GLIBCXX_RESOLVE_LIB_DEFECTS
+ *  DR 2344 quoted()'s interaction with padding is unclear
  */
 template
   auto&
@@ -393,16 +400,17 @@
   operator<<(std::basic_ostream<_CharT, _Traits>& __os,
 const _Quoted_string<_String, _CharT>& __str)
   {
-   __os << __str._M_delim;
+   std::basic_ostringstream<_CharT, _Traits> __ostr;
+   __ostr << __str._M_delim;
for (auto& __c : __str._M_string)
  {
if (__c == __str._M_delim || __c == __str._M_escape)
- __os << __str._M_escape;
-   __os << __c;
+ __ostr << __str._M_escape;
+   __ostr << __c;
  }
-   __os << __str._M_delim;
+   __ostr << __str._M_delim;
 
-   return __os;
+   return __os << __ostr.str();
   }
 
 /**
Index: testsuite/27_io/manipulators/standard/char/dr2344.cc
===
--- testsuite/27_io/manipulators/standard/char/dr2344.cc(revision 0)
+++ testsuite/27_io/manipulators/standard/char/dr2344.cc(working copy)
@@ -0,0 +1,50 @@
+// { dg-do run }
+// { dg-options "-std=gnu++14" }
+
+// Copyright (C) 2014 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
+// .
+
+// 27.7.6 - Quoted manipulators[quoted.manip]
+
+#include 
+#include 
+#include 
+
+void
+test01()
+{
+  bool test [[gnu::unused]] = true;
+
+  std::ostringstream ssx;
+  ssx << "[" << std::left << std::setfill('x') << std::setw(20) << R"("AB 
\"CD\" EF")" << "]";
+  VERIFY( ssx.str() == R"(["AB \"CD\" EF"xx])" );
+
+  std::ostringstream ssy;
+  ssy << "[" << std::left << std::setfill('y') << std::setw(20) << 
std::quoted(R"(GH "IJ" KL)") << "]";
+  VERIFY( ssy.str() == R"(["GH \"IJ\" KL"yy])" );
+
+  std::ostr

[PR 61424] std::regex matches right to left, not leftmost longest

[Tim Shen]

Here's a patch that is a little bit "quick & dirty". In BFS mode it's
not trivial to support ECMAScript's
"match from left to right". A quick solution is only using DFS for
ECMAScript. See the patch.

It is possible to support ECMAScript's "left to right" in BFS mode
(re2 does this), but I didn't see an obvious way. We could take a look
at re2.

Bootstrap & tested.

Thank you!


-- 
Regards,
Tim Shen
commit 1fef2d9d80f7dcda227c1bbaf909128e068f6907
Author: tim 
Date:   Fri Jun 6 00:00:25 2014 -0700

	PR libstdc++/61424
	* include/bits/regex.tcc (__regex_algo_impl<>): Use DFS for ECMAScript,
	not just regex containing back-references.
	* include/bits/regex_automaton.h (_NFA_base<>::_NFA_base):
	Remove _M_has_backref tracking.
	* include/bits/regex_automaton.tcc (_NFA<>::_M_insert_backref):
	Likewise.
	* include/bits/regex_compiler.tcc (_Compiler<>::_M_disjunction):
	exchange _M_next and _M_alt for alternative operator,
	making matching from left to right.
	* include/bits/regex_executor.h (_State_info<>::_M_get_sol_pos):
	Add position tracking fom DFS.
	* include/bits/regex_executor.tcc (_Executor<>::_M_main_dispatch,
	_Executor<>::_M_dfs): Likewise.
	* include/bits/regex_scanner.h: Remove unused enum entry.
	* testsuite/28_regex/algorithms/regex_search/61424.cc: New
	testcase from PR.

diff --git a/libstdc++-v3/include/bits/regex.tcc b/libstdc++-v3/include/bits/regex.tcc
index a81f517..6a1faaf 100644
--- a/libstdc++-v3/include/bits/regex.tcc
+++ b/libstdc++-v3/include/bits/regex.tcc
@@ -70,7 +70,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // without defining a macro. Users should define
   // _GLIBCXX_REGEX_USE_THOMPSON_NFA if they need to use this approach.
   bool __ret;
-  if (!__re._M_automaton->_M_has_backref
+  if (!(__re._M_flags & regex_constants::ECMAScript)
 #ifndef _GLIBCXX_REGEX_USE_THOMPSON_NFA
 	  && __policy == _RegexExecutorPolicy::_S_alternate
 #endif
diff --git a/libstdc++-v3/include/bits/regex_automaton.h b/libstdc++-v3/include/bits/regex_automaton.h
index 1b0da14..a45ce1a 100644
--- a/libstdc++-v3/include/bits/regex_automaton.h
+++ b/libstdc++-v3/include/bits/regex_automaton.h
@@ -119,8 +119,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 explicit
 _NFA_base(_FlagT __f)
-: _M_flags(__f), _M_start_state(0), _M_subexpr_count(0),
-_M_has_backref(false)
+: _M_flags(__f), _M_start_state(0), _M_subexpr_count(0)
 { }
 
 _NFA_base(_NFA_base&&) = default;
@@ -145,7 +144,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 _FlagT_M_flags;
 _StateIdT _M_start_state;
 _SizeT_M_subexpr_count;
-bool  _M_has_backref;
   };
 
   template
diff --git a/libstdc++-v3/include/bits/regex_automaton.tcc b/libstdc++-v3/include/bits/regex_automaton.tcc
index 1c6cfdd..78c83ec 100644
--- a/libstdc++-v3/include/bits/regex_automaton.tcc
+++ b/libstdc++-v3/include/bits/regex_automaton.tcc
@@ -160,7 +160,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   for (auto __it : this->_M_paren_stack)
 	if (__index == __it)
 	  __throw_regex_error(regex_constants::error_backref);
-  this->_M_has_backref = true;
   _StateT __tmp(_S_opcode_backref);
   __tmp._M_backref_index = __index;
   return _M_insert_state(std::move(__tmp));
diff --git a/libstdc++-v3/include/bits/regex_compiler.tcc b/libstdc++-v3/include/bits/regex_compiler.tcc
index 0df10cc..f15f7dd 100644
--- a/libstdc++-v3/include/bits/regex_compiler.tcc
+++ b/libstdc++-v3/include/bits/regex_compiler.tcc
@@ -103,9 +103,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	  auto __end = _M_nfa._M_insert_dummy();
 	  __alt1._M_append(__end);
 	  __alt2._M_append(__end);
+	  // __alt2 is state._M_next, __alt1 is state._M_alt. The executor
+	  // executes _M_alt before _M_next, as well as executing left
+	  // alternative before right one.
 	  _M_stack.push(_StateSeqT(_M_nfa,
-   _M_nfa._M_insert_alt(__alt1._M_start,
-			__alt2._M_start, false),
+   _M_nfa._M_insert_alt(__alt2._M_start,
+			__alt1._M_start, false),
    __end));
 	}
 }
diff --git a/libstdc++-v3/include/bits/regex_executor.h b/libstdc++-v3/include/bits/regex_executor.h
index 1991c00..e02fa65 100644
--- a/libstdc++-v3/include/bits/regex_executor.h
+++ b/libstdc++-v3/include/bits/regex_executor.h
@@ -173,6 +173,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	  void _M_queue(_StateIdT __i, const _ResultsVec& __res)
 	  { _M_match_queue.emplace_back(__i, __res); }
 
+	  _BiIter* _M_get_sol_pos() { return nullptr; }
+
 	  // Saves states that need to be considered for the next character.
 	  vector>	_M_match_queue;
 	  // Indicates which states are already visited.
@@ -191,12 +193,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	  // Dummy implementations for DFS mode.
 	  bool _M_visited(_StateIdT) const { return false; }
 	  void _M_queue(_StateIdT, const _ResultsVec&) { }
+	  _BiIter* _M_get_sol_pos() { return &_M_sol_pos; }