Re: Mostly rewrite genrecog

2015-04-29 Thread Andreas Schwab
Richard Sandiford  writes:

> /* Represents a test and the action that should be taken on the result.
>If a transition exists for the test outcome, the machine switches
>to the transition's target state.  If no suitable transition exists,
>the machine either falls through to the next decision or, if there are no
>more decisions to try, fails the match.  */
> struct decision : list_head 
> {
>   decision (const test &);
>
>   void set_parent (list_head  *s);
>   bool if_statement_p (uint64_t * = 0) const;
>
>   /* The state to which this decision belongs.  */
>   state *s;
>
>   /* Links to other decisions in the same state.  */
>   decision *prev, *next;
>
>   /* The test to perform.  */
>   struct test test;
> };

../../gcc/genrecog.c:1467: error: declaration of 'test decision::test'
../../gcc/genrecog.c:1051: error: changes meaning of 'test' from 'struct test'

Bootstrap compiler is gcc 4.3.4.

Andreas.

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


Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Andreas Schwab
Trevor Saunders  writes:

>> diff --git a/libobjc/encoding.c b/libobjc/encoding.c
>> index 7333908..20ace46 100644
>> --- a/libobjc/encoding.c
>> +++ b/libobjc/encoding.c
>> @@ -1167,7 +1167,7 @@ objc_layout_structure_next_member (struct 
>> objc_struct_layout *layout)
>>/* Record must have at least as much alignment as any field.
>>   Otherwise, the alignment of the field within the record
>>   is meaningless.  */
>> -#ifndef PCC_BITFIELD_TYPE_MATTERS
>> +#if !PCC_BITFIELD_TYPE_MATTERS

With `#define PCC_BITFIELD_TYPE_MATTERS true' this expands to `#if
!true' which evaluates to 1 since true isn't a defined identifier?

Andreas.

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


Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Andreas Schwab
Trevor Saunders  writes:

> actually pointing out libojc/encoding.c was more useful since that makes
> it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to
> be changed to #if !

That probably won't work on arm or powerpc or vax:

gcc/config/arm/arm.h:#define PCC_BITFIELD_TYPE_MATTERS TARGET_AAPCS_BASED
gcc/config/rs6000/sysv4.h:#define   PCC_BITFIELD_TYPE_MATTERS 
(TARGET_BITFIELD_TYPE)
gcc/config/vax/vax.h:#define PCC_BITFIELD_TYPE_MATTERS (! TARGET_VAXC_ALIGNMENT)

Andreas.

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


Re: Mostly rewrite genrecog

2015-04-29 Thread Bin.Cheng
On Mon, Apr 27, 2015 at 6:20 PM, Richard Sandiford
 wrote:
> I think it's been the case for a while that parallel builds of GCC tend
> to serialise around the compilation of insn-recog.c, especially with
> higher --enable-checking settings.  This patch tries to speed that
> up by replacing most of genrecog with a new algorithm.
>
> I think the main problems with the current code are:
>
> 1. Vector architectures have added lots of new instructions that have
>a similar shape and differ only in mode, code or unspec number.
>The current algorithm doesn't have any way of factoring out those
>similarities.
>
> 2. When matching a particular instruction, the current code examines
>everything about a SET_DEST before moving on to the SET_SRC.  This has
>two subproblems:
>
>2a. The destination of a SET isn't very distinctive.  It's usually
>just a register_operand, a memory_operand, a nonimmediate_operand
>or a flags register.  We therefore tend to backtrack to the
>SET_DEST a lot, oscillating between groups of instructions with
>the same kind of destination.
>
>2b. Backtracking through predicate checks is relatively expensive.
>It would be good to narrow down the "shape" of the instruction
>first and only then check the predicates.  (The backtracking is
>expensive in terms of insn-recog.o compile time too, both because
>we need to copy into argument registers and out of the result
>register, and because it adds more sites where spills are needed.)
>
> 3. The code keeps one local variable per rtx depth, so it ends up
>loading the same rtx many times over (mostly when backtracking).
>This is very expensive in rtl-checking builds because each XEXP
>includes a code check and a line-specific failure call.
>
>In principle the idea of having one local variable per depth
>is good.  But it was originally written that way when all optimisations
>were done at the rtl level and I imagine each local variable mapped
>to one pseudo register.  These days the statements that reload the
>value needed on backtracking lead to many more SSA names and phi
>statements than you'd get with just a single variable per position
>(loaded once, so naturally SSA).  There is still the potential benefit
>of avoiding having sibling rtxes live at once, but fixing (2) above
>reduces that problem.
>
> Also, the code is all goto-based, which makes it rather hard to step through.
>
> The patch deals with these as follows:
>
> 1. Detect subpatterns that differ only by mode, code and/or integer
>(e.g. unspec number) and split them out into a common routine.
>
> 2. Match the "shape" of the instruction first, in terms of codes,
>integers and vector lengths, and only then check the modes, predicates
>and dups.  When checking the shape, handle SET_SRCs before SET_DESTs.
>In practice this seems to greatly reduce the amount of backtracking.
>
> 3. Have one local variable per rtx position.  I tested the patch with
>and without the change and it helped a lot with rtl-checking builds
>without seeming to affect release builds much either way.
>
> As far as debuggability goes, the new code avoids gotos and just
> uses "natural" control flow.
>
> The headline stat is that a stage 3 --enable-checking=yes,rtl,df
> build of insn-recog.c on my box goes from 7m43s to 2m2s (using the
> same stage 2 compiler).  The corresponding --enable-checking=release
> change is from 49s to 24s (less impressive, as expected).
>
> The patch seems to speed up recog.  E.g. the time taken to build
> fold-const.ii goes from 6.74s before the patch to 6.69s after it;
> not a big speed-up, but reproducible.
>
> Here's a comparison of the number of lines of code in insn-recog.c
> before and after the patch on one target per config/ CPU:
>
> aarch64-linux-gnueabi   11552638169 :   33.04%
> alpha-linux-gnu  2447910740 :   43.87%
> arm-linux-gnueabi   16920867759 :   40.04%
> avr-rtems5564722127 :   39.76%
> bfin-elf 13928 6498 :   46.65%
> c6x-elf  2992813324 :   44.52%
> cr16-elf  2650 1419 :   53.55%
> cris-elf 18669 7257 :   38.87%
> epiphany-elf 19308 6131 :   31.75%
> fr30-elf  2204 1112 :   50.45%
> frv-linux-gnu13541 5950 :   43.94%
> h8300-elf19584 9327 :   47.63%
> hppa64-hp-hpux11.23  18299 8549 :   46.72%
> ia64-linux-gnu   3762917101 :   45.45%
> iq2000-elf

Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

2015-04-29 Thread Uros Bizjak
On Wed, Apr 29, 2015 at 11:22 PM, Caroline Tice  wrote:
> Here is a new patch to update the cold name partition so that it will
> only be treated like a function name and be given a size on the
> architectures that specifically define macros for such.
>
> I also updated the test case to try to only test on the appropriate
> architectures.  I am not sure I got the target triples correct for
> this, so I would appreciate some extra attention to that in the
> review.  I have tested this new patch on my workstation and it works
> as intended.  I am in the process of bootstrapping with the new patch.
> Assuming that the bootstrap passes, is this ok to commit?
>
> -- Caroline Tice
> cmt...@google.com
>
> ChangeLog (gcc):
>
> 2015-04-29  Caroline Tice  
>
> PR 65929
> * config/elfos.h (ASM_DECLARE_COLD_FUNCTION_NAME): New macro 
> definition.
> (ASM_DECLARE_COLD_FUNCTION_SIZE): New macro definition.
> * final.c (final_scan_insn):  Use ASM_DECLARE_COLD_FUNCTION_NAME
> instead of ASM_DECLARE_FUNCTION_NAME for cold partition name.
> * varasm.c (assemble_end_function):  Use 
> ASM_DECLARE_COLD_FUNCTION_SIZE
> instead of ASM_DECLARE_FUNCTION_SIZE for cold partition size.
>
> ChangeLog (testsuite):
>
> 2015-04-29  Caroline Tice  
>
>PR  65929
> * gcc.dg/tree-prof/cold_partition_label.c:  Only check for cold
> partition size on certain targets.

Documentation for new macros is missing (please see doc/tm.texi.in).

Uros.


Re: Refactor gcc/tree-vectorize.c:vectorize_loops

2015-04-29 Thread Jeff Law

On 04/29/2015 08:37 AM, Aditya K wrote:


Thanks for the feedback. I have added comment and properly indented the code.
I made a couple more formatting fixes (spaces -> tab & line wrapping), 
improved the ChangeLog, did a bootstrap & regression test on 
x86_64-linux-gnu and installed the final patch on the trunk.


Thanks,
Jeff



Re: [PATCH] PR target/48904 x86_64-knetbsd-gnu missing defs

2015-04-29 Thread Jeff Law

On 04/29/2015 02:01 AM, Bernhard Reutner-Fischer wrote:

2012-09-21  H.J. Lu  

PR target/48904
* config.gcc (x86_64-*-knetbsd*-gnu): Add i386/knetbsd-gnu64.h.
* config/i386/knetbsd-gnu64.h: New file

OK.  Please install on the trunk.

THanks,
Jeff



Re: [PATCH, RFC]: Next stage1, refactoring: propagating rtx subclasses

2015-04-29 Thread Jeff Law

On 04/29/2015 01:55 AM, Mikhail Maltsev wrote:
[ Big Snip ]

Couple minor issues.

Can you please check the changes to do_jump_1, the indention looked 
weird in the patch.  If it's correct, just say so.


The ChangeLog needed some work.  I'm attaching the one I'd use for the 
patch as it stands today.  There were some functions that had changed, 
but which weren't referenced and other minor oversights that I've fixed. 
 I suspect you'll need to adjust it slightly as you fix PEEP2_EOB (see 
below).


One significant question/issue.

The definition of PEEP2_EOB looks wrong.  I don't see how you can safely 
cast pc_rtx to an rtx_insn * since it's an RTX rather than rtx chain 
object.  Maybe you're getting away with it because it's used as marker. 
 But it still feels wrong.  You'd probably be better off creating a 
unique rtx_insn * object and using that as the marker.


Otherwise it's ready to go.

jeff


as_insn3.cl
Description: application/simple-filter


Re: [PATCH] add self-tuning to x86 hardware fast path in libitm

2015-04-29 Thread Andi Kleen
Nuno Diegues  writes:

> Hello,
>
> I have taken the chance to improve the patch by addressing the
> comments above in this thread.
> Namely:
>  - to use a simple random generator managed inside the library only
>  - removed floating point usage and replaced by fixed arithmetic
>  - added some comments where relevant

Thanks.

Patch looks good to me now. It would be perhaps nice to have an
environment variable to turn the adaptive algorithm off for tests,
but that's not critical.

It would be also nice to test it on something else, but I understand
it's difficult to find other software using the STM syntax.

I can't approve the patch however. I believe it's big enough that you
may need a copy right assignment.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only


Re: [patch] Rewrite check_global_declarations() generically

2015-04-29 Thread Aldy Hernandez

On 04/29/2015 12:33 PM, Jason Merrill wrote:

On 04/28/2015 09:01 PM, Aldy Hernandez wrote:

The approach looks good to me.


-  analyze_functions ();
+  analyze_functions (true);


In the C++ front end at least we comment anonymous boolean arguments, i.e.

  analyze_functions (/*first_time*/true);

Let's do that here, too.  Similarly for the calls to referred_to_p (false).


Done.




+  /* ?? Why are we looking at TREE_USED?  Shouldn't the call to
+ referred_to_p above be enough?  Apparently not, because the
+ `__unused__' attribute is not being considered for
+ referred_to_p.  */


Seems like you answered your question.  :)


I've adjusted the comment.




+  /* Global ctors and dtors are called by the runtime.  */
+  && (TREE_CODE (decl) != FUNCTION_DECL
+  || (!DECL_STATIC_CONSTRUCTOR (decl)
+  && !DECL_STATIC_DESTRUCTOR (decl)))


Maybe check snode->needed_p instead?


I thought so too, but it's a bit too restrictive.  Particularly, it 
causes this test to fail:


static void foo (void) {} /* { dg-warning "'foo' defined but not used" } */
static void bar (void) { bar (); } /* { dg-warning "'bar' defined but 
not used" } */


...because force_output is true, which unfortunately is set here:

  /* When not optimizing, also output the static functions. (see
 PR24561), but don't do so for always_inline functions, functions
 declared inline and nested functions.  These were optimized out
 in the original implementation and it is unclear whether we want
 to change the behavior here.  */
  if ((!opt_for_fn (decl, optimize)
   && !node->cpp_implicit_alias
   && !DECL_DISREGARD_INLINE_LIMITS (decl)
   && !DECL_DECLARED_INLINE_P (decl)
   && !(DECL_CONTEXT (decl)
&& TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL))
  && !DECL_COMDAT (decl) && !DECL_EXTERNAL (decl))
node->force_output = 1;

I've left it as is, and am committing the attached incremental patch.

Thanks.
Aldy
commit 5ffe67af1604495d4cafeae4b3e948bf2eac77b3
Author: Aldy Hernandez 
Date:   Wed Apr 29 18:04:58 2015 -0700

Provide comments for some boolean arguments.

Use needed_p instead of looking at DECL_*_CONSTRUCTOR.

diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 0ee1d2b..0873162 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -2467,13 +2467,13 @@ symbol_table::finalize_compilation_unit (void)
 
   /* Gimplify and lower all functions, compute reachability and
  remove unreachable nodes.  */
-  analyze_functions (true);
+  analyze_functions (/*first_time=*/true);
 
   /* Mark alias targets necessary and emit diagnostics.  */
   handle_alias_pairs ();
 
   /* Gimplify and lower thunks.  */
-  analyze_functions (false);
+  analyze_functions (/*first_time=*/false);
 
   /* Emit early debug for reachable functions, and by consequence,
  locally scoped symbols.  */
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 3155595..9a27ca2 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -505,8 +505,6 @@ wrapup_global_declarations (tree *vec, int len)
 void
 check_global_declaration (tree decl)
 {
-  // ?? Perhaps we should avoid all DECL_ARTIFICIALs here?
-
   /* Warn about any function declared static but not defined.  We don't
  warn about variables, because many programs have static variables
  that exist only to get some text into the object file.  */
@@ -518,9 +516,9 @@ check_global_declaration (tree decl)
   && ! TREE_NO_WARNING (decl)
   && ! TREE_PUBLIC (decl)
   && (warn_unused_function
- || snode->referred_to_p (false)))
+ || snode->referred_to_p (/*include_self=*/false)))
 {
-  if (snode->referred_to_p (false))
+  if (snode->referred_to_p (/*include_self=*/false))
pedwarn (input_location, 0, "%q+F used but never defined", decl);
   else
warning (OPT_Wunused_function, "%q+F declared % but never 
defined", decl);
@@ -535,11 +533,10 @@ check_global_declaration (tree decl)
|| (warn_unused_variable
   && TREE_CODE (decl) == VAR_DECL && ! TREE_READONLY (decl)))
   && ! DECL_IN_SYSTEM_HEADER (decl)
-  && ! snode->referred_to_p (false)
-  /* ?? Why are we looking at TREE_USED?  Shouldn't the call to
-referred_to_p above be enough?  Apparently not, because the
-`__unused__' attribute is not being considered for
-referred_to_p.  */
+  && ! snode->referred_to_p (/*include_self=*/false)
+  /* This TREE_USED check is needed in addition to referred_to_p
+above, because the `__unused__' attribute is not being
+considered for referred_to_p.  */
   && ! TREE_USED (decl)
   /* The TREE_USED bit for file-scope decls is kept in the identifier,
 to handle multiple external decls in different scopes.  */


Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

2015-04-29 Thread Jack Howarth
The new patch bootstraps fine on x86_64-apple-darwin14.

On Wed, Apr 29, 2015 at 5:22 PM, Caroline Tice  wrote:
> Here is a new patch to update the cold name partition so that it will
> only be treated like a function name and be given a size on the
> architectures that specifically define macros for such.
>
> I also updated the test case to try to only test on the appropriate
> architectures.  I am not sure I got the target triples correct for
> this, so I would appreciate some extra attention to that in the
> review.  I have tested this new patch on my workstation and it works
> as intended.  I am in the process of bootstrapping with the new patch.
> Assuming that the bootstrap passes, is this ok to commit?
>
> -- Caroline Tice
> cmt...@google.com
>
> ChangeLog (gcc):
>
> 2015-04-29  Caroline Tice  
>
> PR 65929
> * config/elfos.h (ASM_DECLARE_COLD_FUNCTION_NAME): New macro 
> definition.
> (ASM_DECLARE_COLD_FUNCTION_SIZE): New macro definition.
> * final.c (final_scan_insn):  Use ASM_DECLARE_COLD_FUNCTION_NAME
> instead of ASM_DECLARE_FUNCTION_NAME for cold partition name.
> * varasm.c (assemble_end_function):  Use 
> ASM_DECLARE_COLD_FUNCTION_SIZE
> instead of ASM_DECLARE_FUNCTION_SIZE for cold partition size.
>
> ChangeLog (testsuite):
>
> 2015-04-29  Caroline Tice  
>
>PR  65929
> * gcc.dg/tree-prof/cold_partition_label.c:  Only check for cold
> partition size on certain targets.
>
>
>
>
>
> On Wed, Apr 29, 2015 at 11:59 AM, Caroline Tice  wrote:
>> Thank you; I will work with your suggestions and try to get a new
>> patch done soon.
>>
>> -- Caroline Tice
>> cmt...@google.com
>>
>>
>> On Wed, Apr 29, 2015 at 11:34 AM, Uros Bizjak  wrote:
>>> On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak  wrote:
 On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice  wrote:
> The attached patch can revert the previous patch, if that is the way
> we should proceed on this.  If you want me to apply the reversion,
> please let me know.
>
> I would be happy to fix to the problem, rather than just reverting the
> patch, but I do not have expertise in assembly language on other
> platforms, so I would need some help, if anyone would be interested in
> helping me?

 How about adding ASM_DECLARE_COLD_FUNCTION_NAME and
 ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used
 instead, and targets are free to define them in any way.
>>>
>>> Something like the attached prototype RFC patch. Using this patch,
>>> readelf -sW returns:
>>>
>>> Symbol table '.symtab' contains 18 entries:
>>>Num:Value  Size TypeBind   Vis  Ndx Name
>>>  0:  0 NOTYPE  LOCAL  DEFAULT  UND
>>>  1:  0 SECTION LOCAL  DEFAULT1
>>>  2:  0 SECTION LOCAL  DEFAULT3
>>>  3:  0 SECTION LOCAL  DEFAULT4
>>>  4:  0 SECTION LOCAL  DEFAULT5
>>>  5:  0 SECTION LOCAL  DEFAULT6
>>>  6:  0 SECTION LOCAL  DEFAULT8
>>>  7:  8 FUNCLOCAL  DEFAULT6 main.cold.0
>>>  8:  0 SECTION LOCAL  DEFAULT   10
>>>  9:  0 SECTION LOCAL  DEFAULT   13
>>> 10:  0 SECTION LOCAL  DEFAULT   12
>>> 11:    312 FUNCGLOBAL DEFAULT [: 88] 8 
>>> main
>>> 12: 0008   160 OBJECT  GLOBAL DEFAULT  COM buf
>>> 13:  0 NOTYPE  GLOBAL DEFAULT  UND memset
>>> 14: 44 FUNCGLOBAL DEFAULT [: 88] 1 
>>> sub2
>>> 15:  0 NOTYPE  GLOBAL DEFAULT  UND strcmp
>>> 16:  0 NOTYPE  GLOBAL DEFAULT  UND exit
>>> 17:  0 NOTYPE  GLOBAL DEFAULT  UND abort
>>>
>>> Uros.


Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Jeff Law

On 04/29/2015 08:10 PM, Trevor Saunders wrote:


I decided to commit this, it seems like testing it can be slow on some
targets and I did a bootstrap on x86_64-linux-gnu (with regtest queued)
and it seems very very unlikely to break anything else.

Seems reasonable.Thanks for taking care of it quickly.

/me wonders if we should have an aranym instance for m68k testing in the 
compile farm.


jeff



More type narrowing in match.pd

2015-04-29 Thread Jeff Law


This is an incremental improvement to the type narrowing in match.pd. 
It's largely based on the pattern I added to fix 47477.


Basically if we have

(bit_and (arith_op (convert A) (convert B)) mask)

Where the conversions are widening and the mask turns off all bits 
outside the original types of A & B, then we can turn that into


(bit_and (arith_op A B) mask)

We may need to convert A & B to an unsigned type with the same 
width/precision as their original type, but that's still better than a 
widening conversion.


Bootstrapped and regression tested on x86_64-linux-gnu.

OK for the trunk?

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 5c7558a..51f68ab 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-04-29  Jeff Law  
+
+   * match.pd (bit_and (plus/minus (convert @0) (convert @1) mask): New
+   simplifier to narrow arithmetic.
+
 2015-04-29  Mikhail Maltsev  
 
* dojump.c (do_compare_rtx_and_jump): Use std::swap instead of
diff --git a/gcc/match.pd b/gcc/match.pd
index fc374de..357e767 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1068,3 +1068,41 @@ along with GCC; see the file COPYING3.  If not see
(convert (op @0 @1)))
   (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
(convert (op (convert:utype @0) (convert:utype @1)))
+
+/* This is another case of narrowing, specifically when there's an outer
+   BIT_AND_EXPR which masks off bits outside the type of the innermost
+   operands.   Like the previous case we have to convert the operands
+   to unsigned types to avoid introducing undefined behaviour for the
+   arithmetic operation.  */
+(for op (minus plus)
+  (simplify
+(bit_and (op (convert@2 @0) (convert@3 @1)) INTEGER_CST@4)
+(if (INTEGRAL_TYPE_P (type)
+/* We check for type compatibility between @0 and @1 below,
+   so there's no need to check that @1/@3 are integral types.  */
+&& INTEGRAL_TYPE_P (TREE_TYPE (@0))
+&& INTEGRAL_TYPE_P (TREE_TYPE (@2))
+/* The precision of the type of each operand must match the
+   precision of the mode of each operand, similarly for the
+   result.  */
+&& (TYPE_PRECISION (TREE_TYPE (@0))
+== GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (@0
+&& (TYPE_PRECISION (TREE_TYPE (@1))
+== GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (@1
+&& TYPE_PRECISION (type) == GET_MODE_PRECISION (TYPE_MODE (type))
+/* The inner conversion must be a widening conversion.  */
+&& TYPE_PRECISION (TREE_TYPE (@2)) > TYPE_PRECISION (TREE_TYPE (@0))
+&& ((GENERIC 
+ && (TYPE_MAIN_VARIANT (TREE_TYPE (@0))
+ == TYPE_MAIN_VARIANT (TREE_TYPE (@1
+|| (GIMPLE
+&& types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1
+&& (tree_int_cst_min_precision (@4, UNSIGNED)
+<= TYPE_PRECISION (TREE_TYPE (@0
+  (if (TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
+   (with { tree ntype = TREE_TYPE (@0); }
+ (convert (bit_and (op @0 @1) (convert:ntype @4)
+  (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
+   (convert (bit_and (op (convert:utype @0) (convert:utype @1))
+ (convert:utype @4)))
+
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 7aebfec..9df76c6 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2015-04-29  Jeff Law  
+
+   * gcc.dg/tree-ssa/shorten-1.c: New test.
+
 2015-04-29  Petar Jovanovic  
 
* gcc.target/mips/call-from-init.c: New test.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/shorten-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/shorten-1.c
new file mode 100644
index 000..cecdd44
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/shorten-1.c
@@ -0,0 +1,78 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+extern const unsigned char mode_ibit[];
+extern const unsigned char mode_fbit[];
+extern const signed char smode_ibit[];
+extern const signed char smode_fbit[];
+
+/* We use bit-and rather than modulo to ensure we're actually
+   testing the desired match.pd pattern.  */
+unsigned char
+muufubar (int indx)
+{
+  int ret = (mode_fbit [indx] - mode_ibit [indx]) & 3;
+  return ret;
+}
+
+signed char
+msufubar (int indx)
+{
+  int ret = (mode_fbit [indx] - mode_ibit [indx]) & 3;
+  return ret;
+}
+
+unsigned char
+musfubar (int indx)
+{
+  int ret = (smode_fbit [indx] - smode_ibit [indx]) & 3;
+  return ret;
+}
+
+signed char
+mssfubar (int indx)
+{
+  int ret = (smode_fbit [indx] - smode_ibit [indx]) & 3;
+  return ret;
+}
+
+
+unsigned char
+puufubar (int indx)
+{
+  int ret = (mode_fbit [indx] + mode_ibit [indx]) & 3;
+  return ret;
+}
+
+signed char
+psufubar (int indx)
+{
+  int ret = (mode_fbit [indx] + mode_ibit [indx]) & 3;
+  return ret;
+}
+
+unsigned char
+pusfubar (int indx)
+{
+  int ret = (smode_fbit [indx] + smode_ibit [indx]) & 3;
+  ret

Re: [PATCH, RFC]: Next stage1, refactoring: propagating rtx subclasses

2015-04-29 Thread Jeff Law

On 04/29/2015 01:55 AM, Mikhail Maltsev wrote:



I probably would have done separate patches for the std::swap
changes. They're not really related to the rtx subclasses work.

OK, sending 2 separate patches. Note that they a not "commutative":
std::swap should be applied before the main one, because one of the
swaps in do_compare_rtx_and_jump uses a single temporary variable of
type rtx for swapping labels and for storing generic rtl expressions
(this could be worked around, of course, but I think that would be just
a waste of time).
I've applied the swap patch.  I want to look over the subclass patch a 
final time before applying it.


If you're going to continue this work, you should probably get 
write-after-approval access so that you can commit your own approved 
changes.



jeff



Re: [PATCH] add self-tuning to x86 hardware fast path in libitm

2015-04-29 Thread Nuno Diegues
Hello,

I have taken the chance to improve the patch by addressing the
comments above in this thread.
Namely:
 - to use a simple random generator managed inside the library only
 - removed floating point usage and replaced by fixed arithmetic
 - added some comments where relevant

Re-running the STAMP benchmarks shows similar gains (to those shown
above) with respect to an unmodified GCC 5.0.0:

benchmark: speedup
genome: 1.58
intruder: 1.78
labyrinth: 1.0
ssca2: 1.01
yada: 1.0
kmeans-high: 1.16
kmeans-low: 1.16
vacation-high: 2.05
vacation-low: 2.81

I appreciate any feedback and comments!

Index: libitm/libitm_i.h
===
--- libitm/libitm_i.h (revision 219316)
+++ libitm/libitm_i.h (working copy)
@@ -242,6 +242,9 @@ struct gtm_thread
   uint32_t restart_reason[NUM_RESTARTS];
   uint32_t restart_total;

+  // Keeps track of how many transactions were successfully executed.
+  uint64_t number_executed_txns;
+
   // *** The shared part of gtm_thread starts here. ***
   // Shared state is on separate cachelines to avoid false sharing with
   // thread-local parts of gtm_thread.
@@ -286,6 +289,8 @@ struct gtm_thread
   static void *operator new(size_t);
   static void operator delete(void *);

+  static void reoptimize_htm_execution();
+
   // Invoked from assembly language, thus the "asm" specifier on
   // the name, avoiding complex name mangling.
   static uint32_t begin_transaction(uint32_t, const gtm_jmpbuf *)
@@ -309,6 +314,59 @@ struct gtm_thread
   void commit_user_actions ();
 };

+// Different ways to deal with capacity aborts in HTM execution.
+enum gtm_capacity_abort_mode
+{
+  STUBBORN,
+  HALVEN,
+  GIVEUP
+};
+
+// Definition of fixed point arithmetic types.
+// Half the bits are dedicated to the fractional type, and the rest to the
+// "whole" part.
+#define FIXED_PT_WIDTH  64
+#define FIXED_PT_INTEGER_WIDTH  32
+typedef uint64_t fixed_pt_t;
+typedef __uint128_t fixed_pt_td;
+
+#define FIXED_PT_FRAC_WIDTH (FIXED_PT_WIDTH - FIXED_PT_INTEGER_WIDTH)
+#define FIXED_PT_ONE((fixed_pt_t)((fixed_pt_t)1 << FIXED_PT_FRAC_WIDTH))
+#define FIXED_PT_TWO(FIXED_PT_ONE + FIXED_PT_ONE)
+
+#define fixed_mul(A,B) \
+  ((fixed_pt_t)(((fixed_pt_td)(A) * (fixed_pt_td)(B)) >> FIXED_PT_FRAC_WIDTH))
+#define fixed_div(A,B) \
+  ((fixed_pt_t)(((fixed_pt_td)(A) << FIXED_PT_FRAC_WIDTH) / (fixed_pt_td)(B)))
+#define fixed_const(R) \
+  ((fixed_pt_t)((R) * FIXED_PT_ONE + ((R) >= 0 ? 0.5 : -0.5)))
+
+// Maintains the current values optimized for HTM execution and the
+// corresponding statistics gathered for the decision-making.
+struct gtm_global_optimizer
+{
+  // Mode chosen to currently deal with capacity aborts.
+  gtm_capacity_abort_mode optimized_mode;
+  // Number of attempts chosen to currently insist on HTM execution.
+  uint32_t optimized_attempts;
+
+  uint64_t last_cycles;
+  uint64_t last_total_txs_executed;
+
+  fixed_pt_t last_throughput;
+  uint32_t last_attempts;
+
+  fixed_pt_t best_ever_throughput;
+  uint32_t best_ever_attempts;
+
+  uint64_t txns_while_stubborn;
+  uint64_t cycles_while_stubborn;
+  uint64_t txns_while_halven;
+  uint64_t cycles_while_halven;
+  uint64_t txns_while_giveup;
+  uint64_t cycles_while_giveup;
+};
+
 } // namespace GTM

 #include "tls.h"
@@ -346,6 +404,9 @@ extern gtm_cacheline_mask gtm_mask_stack(gtm_cache
 // the name, avoiding complex name mangling.
 extern uint32_t htm_fastpath __asm__(UPFX "gtm_htm_fastpath");

+// Maintains the optimization for HTM execution.
+extern gtm_global_optimizer optimizer;
+
 } // namespace GTM

 #endif // LIBITM_I_H
Index: libitm/libitm.h
===
--- libitm/libitm.h (revision 219316)
+++ libitm/libitm.h (working copy)
@@ -101,7 +101,8 @@ typedef enum
/* These are not part of the ABI but used for custom HTM fast paths.  See
   ITM_beginTransaction and gtm_thread::begin_transaction.  */
pr_HTMRetryableAbort = 0x80,
-   pr_HTMRetriedAfterAbort = 0x100
+   pr_HTMRetriedAfterAbort = 0x100,
+   pr_HTMCapacityAbort  = 0x200
 } _ITM_codeProperties;

 /* Result from startTransaction that describes what actions to take.
Index: libitm/method-serial.cc
===
--- libitm/method-serial.cc (revision 219316)
+++ libitm/method-serial.cc (working copy)
@@ -223,7 +223,23 @@ struct htm_mg : public method_group
 // initially disabled.
 #ifdef USE_HTM_FASTPATH
 htm_fastpath = htm_init();
+#ifdef HAVE_AS_RTM
+optimizer.optimized_mode = STUBBORN;
+optimizer.optimized_attempts = htm_fastpath;
+optimizer.last_cycles = rdtsc();
+optimizer.last_total_txs_executed = 0;
+optimizer.last_throughput = fixed_const(0.0001);
+optimizer.last_attempts = htm_fastpath > 0 ? htm_fastpath - 1 : 1;
+optimizer.best_ever_throughput = optimizer.last_throughput;
+optimizer.best_ever_attempts = htm_fastpath;
+optimizer.

Re: [PATCH] Fix PR62283

2015-04-29 Thread H.J. Lu
On Tue, Apr 28, 2015 at 1:29 AM, Richard Biener  wrote:
>
> The following fixes a missed optimization in basic-block vectorization.
> Currently we require the SLP chain to end up in a sequence of loads
> we support.  But of course we can in theory end the SLP chain at
> any point and simply construct the vector operand of the uses by
> pieces.  This is what the patch does to handle the case where
> "external" defs are not really external.  As the patch is somewhat
> more generic it also handles more cases and relies on the cost model
> to reject the outright non-profitable ones (like the bb-slp-14.c
> case which is run with -fno-vect-cost-model though).
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
>
> Richard.
>
> 2015-04-28  Richard Biener  
>
> PR tree-optimization/62283
> * tree-vect-slp.c (vect_build_slp_tree): When the SLP build
> fails fatally and we are vectorizing a basic-block simply
> cause the child to be constructed piecewise.
> (vect_analyze_slp_cost_1): Adjust.
> (vect_detect_hybrid_slp_stmts): Likewise.
> (vect_bb_slp_scalar_cost): Likewise.
> (vect_get_constant_vectors): For piecewise constructed
> constants place them after the last def.
> (vect_get_slp_defs): Adjust.
> * tree-vect-stmts.c (vect_is_simple_use): Detect in-BB
> externals for basic-block vectorization.
>

This caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65935


-- 
H.J.


Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Trevor Saunders
On Wed, Apr 29, 2015 at 08:13:16PM -0400, Trevor Saunders wrote:
> On Wed, Apr 29, 2015 at 04:29:26PM -0600, Jeff Law wrote:
> > On 04/29/2015 04:25 PM, Trevor Saunders wrote:
> > >On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote:
> > >>On 04/29/2015 03:55 PM, Andreas Schwab wrote:
> > >>>Trevor Saunders  writes:
> > >>>
> > it passes for me on x86_64-linux after that commit, what platform is
> > this?
> > >>>
> > >>>Any one with #undef PCC_BITFIELD_TYPE_MATTERS.  See libobjc/encoding.c.
> > >>Can't you just answer the question Andreas instead of making Trevor go
> > >>looking around?  You already have this information, why make his job 
> > >>harder?
> > >
> > >
> > >actually pointing out libojc/encoding.c was more useful since that makes
> > >it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to
> > >be changed to #if !
> > >
> > >>Trevor, try m68k-elf cross.
> > >
> > >ok, lets see if I can get this to work (its an execution test that
> > >breaks, so I'll need to setup binutils and qemu)
> > I've actually got a aranym m68k emulator here...  So I can do native
> > bootstrapping and testing for m68k linux.  If you want me to test something,
> > just let me know -- FWIW, it takes a week or so to bootstrap ;-)
> 
> Well the fix is just this
> 
> diff --git a/libobjc/encoding.c b/libobjc/encoding.c
> index 7333908..20ace46 100644
> --- a/libobjc/encoding.c
> +++ b/libobjc/encoding.c
> @@ -1167,7 +1167,7 @@ objc_layout_structure_next_member (struct 
> objc_struct_layout *layout)
>/* Record must have at least as much alignment as any field.
>   Otherwise, the alignment of the field within the record
>   is meaningless.  */
> -#ifndef PCC_BITFIELD_TYPE_MATTERS
> +#if !PCC_BITFIELD_TYPE_MATTERS
>layout->record_align = MAX (layout->record_align, desired_align);
>  #else/* PCC_BITFIELD_TYPE_MATTERS */
>if (*type == _C_BFLD)
> 
>I looked at the .i built for m68k-linux-elf before and after the
>patch and it does what I expect it should do and is a pretty obvious
>part that should go with the rest of this patch.
> 
>Obviously something else should be done in the long run at least to
>separate gcc and libobjc configuration, but I can't see an argument
>for that patch not being ok for now so I'm inclined to check it in
>with the current level of testing.

I decided to commit this, it seems like testing it can be slow on some
targets and I did a bootstrap on x86_64-linux-gnu (with regtest queued)
and it seems very very unlikely to break anything else.

Trev

> 
>Trev
> 
> > 
> > jeff


mismatch in configure.ac for libgomp

2015-04-29 Thread Pedro Giffuni

Hello;

I was checking out some old gcc revisions and I found this commit:

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=140497

It has an obvious error that is still carried today:

Instead of adding adding the check for the  header
a redundant check for  was added.  The mismatch
is still in trunk (and all recent gcc versions).
The attached patch fixes it.

Regards,

Pedro.
--- libgomp/configure.ac.orig   2015-04-29 20:33:18.322158239 -0500
+++ libgomp/configure.ac2015-04-29 20:34:01.202743439 -0500
@@ -170,7 +170,7 @@
 AC_STDC_HEADERS
 AC_HEADER_TIME
 ACX_HEADER_STRING
-AC_CHECK_HEADERS(unistd.h semaphore.h sys/loadavg.h sys/time.h sys/time.h)
+AC_CHECK_HEADERS(unistd.h semaphore.h sys/loadavg.h sys/sysctl.h sys/time.h)
 
 GCC_HEADER_STDINT(gstdint.h)
 


[debug-early] fix -fdump-go-spec

2015-04-29 Thread Aldy Hernandez

Hi guys!

Despite what Go thinks:

  /* The debug hooks are used to implement -fdump-go-spec because it
 gives a simple and stable API for all the information we need to
 dump.  */

...the debug hooks are not stable... :).

The godump-1.c test is failing in the debug-early branch.  It seems that 
Go is hijacking the debug_hook machinery to access globals generated by 
the front-ends.  In debug-early, things have moved around.


With this patch I have done my best to give Go what it wants without 
recreating what the front-ends were doing.  I've made the go_decl() call 
work from within the early_global_decl() hook which gets called as we 
parse (rest_of_decl_compilation).  I far as I understand, this hack is a 
one-time thing for use internally in the build process, so we don't care 
whether go_decl() will receive location information??


I have also relaxed the condition in rest_of_decl_compilation to allow 
function prototypes.  Go was expecting to be fed function prototypes as 
part of the global_decl machinery.  However, it won't ever see these, as 
the early_global_decl code iterating through functions uses the symbol 
table, which does not have prototypes:


  /* Emit early debug for reachable functions, and by consequence,
 locally scoped symbols.  */
  struct cgraph_node *cnode;
  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (cnode)
if (!decl_function_context (cnode->decl))
  (*debug_hooks->early_global_decl) (cnode->decl);

(By the way, even iterating through symbols, without regards to gimple 
body, we end up with nothing...and even before we analyze_functions() 
and prune unreachable nodes.).


Relaxing the condition does the trick, and the dwarf early_global_decl 
debug hook just works because it avoids functions with no body anyhow.


In a world with Go and non dwarf (stabs, etc) debug hooks, I may have to 
adjust the calls to debug_hooks->{early,late}_global_decl a bit more to 
get all debugging backends to get what they want.  This may involve 
feeding more to the debug hooks while making the individual hooks 
disregard DECLs they don't want/need.


Is there not a more modern way of Go getting the DECLs it needs without 
abusing the debug_hook machinery?


Anyways... this is what I have so far.  It may change, as I have at 
least one stabs problem that may regarding tweaking things again.


Committed to branch.

Aldy
commit 040d95e2436d7fa1ef75761dfe50b7481726373d
Author: Aldy Hernandez 
Date:   Wed Apr 29 17:37:21 2015 -0700

Fix -fdump-go-spec.

diff --git a/gcc/godump.c b/gcc/godump.c
index 94d0c8b..5de34db 100644
--- a/gcc/godump.c
+++ b/gcc/godump.c
@@ -517,6 +517,7 @@ go_function_decl (tree decl)
 static void
 go_early_global_decl (tree decl)
 {
+  go_decl (decl);
   real_debug_hooks->early_global_decl (decl);
 }
 
@@ -526,7 +527,6 @@ static void
 go_late_global_decl (tree decl)
 {
   real_debug_hooks->late_global_decl (decl);
-  go_decl (decl);
 }
 
 /* A type declaration.  */
diff --git a/gcc/passes.c b/gcc/passes.c
index 3bb0e5d..4dee8ad 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -297,10 +297,20 @@ rest_of_decl_compilation (tree decl,
   /* Generate early debug for global variables.  Any local variables will
  be handled by either handling reachable functions from
  finalize_compilation_unit (and by consequence, locally scoped
- symbols), or by rest_of_type_compilation below.  */
+ symbols), or by rest_of_type_compilation below.
+
+ Also, pick up function prototypes, which will be mostly ignored
+ by the different early_global_decl() hooks, but will at least be
+ used by Go's hijack of the debug_hooks to implement
+ -fdump-go-spec.  */
   if (!flag_wpa
   && !in_lto_p
-  && TREE_CODE (decl) != FUNCTION_DECL
+  && (TREE_CODE (decl) != FUNCTION_DECL
+ /* This will pick up function prototypes with no bodies,
+which are not visible in finalize_compilation_unit()
+while iterating with FOR_EACH_*_FUNCTION through the
+symbol table.  */
+ || !DECL_SAVED_TREE (decl))
   && !decl_function_context (decl)
   && !current_function_decl
   && !decl_type_context (decl))


Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Trevor Saunders
On Wed, Apr 29, 2015 at 04:29:26PM -0600, Jeff Law wrote:
> On 04/29/2015 04:25 PM, Trevor Saunders wrote:
> >On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote:
> >>On 04/29/2015 03:55 PM, Andreas Schwab wrote:
> >>>Trevor Saunders  writes:
> >>>
> it passes for me on x86_64-linux after that commit, what platform is
> this?
> >>>
> >>>Any one with #undef PCC_BITFIELD_TYPE_MATTERS.  See libobjc/encoding.c.
> >>Can't you just answer the question Andreas instead of making Trevor go
> >>looking around?  You already have this information, why make his job harder?
> >
> >
> >actually pointing out libojc/encoding.c was more useful since that makes
> >it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to
> >be changed to #if !
> >
> >>Trevor, try m68k-elf cross.
> >
> >ok, lets see if I can get this to work (its an execution test that
> >breaks, so I'll need to setup binutils and qemu)
> I've actually got a aranym m68k emulator here...  So I can do native
> bootstrapping and testing for m68k linux.  If you want me to test something,
> just let me know -- FWIW, it takes a week or so to bootstrap ;-)

Well the fix is just this

diff --git a/libobjc/encoding.c b/libobjc/encoding.c
index 7333908..20ace46 100644
--- a/libobjc/encoding.c
+++ b/libobjc/encoding.c
@@ -1167,7 +1167,7 @@ objc_layout_structure_next_member (struct 
objc_struct_layout *layout)
   /* Record must have at least as much alignment as any field.
  Otherwise, the alignment of the field within the record
  is meaningless.  */
-#ifndef PCC_BITFIELD_TYPE_MATTERS
+#if !PCC_BITFIELD_TYPE_MATTERS
   layout->record_align = MAX (layout->record_align, desired_align);
 #else  /* PCC_BITFIELD_TYPE_MATTERS */
   if (*type == _C_BFLD)

   I looked at the .i built for m68k-linux-elf before and after the
   patch and it does what I expect it should do and is a pretty obvious
   part that should go with the rest of this patch.

   Obviously something else should be done in the long run at least to
   separate gcc and libobjc configuration, but I can't see an argument
   for that patch not being ok for now so I'm inclined to check it in
   with the current level of testing.

   Trev

> 
> jeff


[C++ Patch] PR 61683

2015-04-29 Thread Paolo Carlini

Hi,

this seems pretty straightforward given the grammar. Tested x86_64-linux.

Thanks,
Paolo.


/cp
2015-04-30  Paolo Carlini  

PR c++/61683
* parser.c (cp_parser_mem_initializer): Allow for decltype-specifier.

/testsuite
2015-04-30  Paolo Carlini  

PR c++/61683
* g++.dg/cpp0x/decltype-base1.C: New.
Index: cp/parser.c
===
--- cp/parser.c (revision 222599)
+++ cp/parser.c (working copy)
@@ -12776,6 +12776,7 @@ cp_parser_mem_initializer (cp_parser* parser)
 
mem-initializer-id:
  :: [opt] nested-name-specifier [opt] class-name
+ decltype-specifier (C++11)
  identifier
 
Returns a TYPE indicating the class to be initializer for the first
@@ -12838,14 +12839,18 @@ cp_parser_mem_initializer_id (cp_parser* parser)
 /*is_declaration=*/true);
   /* Otherwise, we could also be looking for an ordinary identifier.  */
   cp_parser_parse_tentatively (parser);
-  /* Try a class-name.  */
-  id = cp_parser_class_name (parser,
-/*typename_keyword_p=*/true,
-/*template_keyword_p=*/false,
-none_type,
-/*check_dependency_p=*/true,
-/*class_head_p=*/false,
-/*is_declaration=*/true);
+  if (cp_lexer_next_token_is_decltype (parser->lexer))
+/* Try a decltype-specifier.  */
+id = cp_parser_decltype (parser);
+  else
+/* Otherwise, try a class-name.  */
+id = cp_parser_class_name (parser,
+  /*typename_keyword_p=*/true,
+  /*template_keyword_p=*/false,
+  none_type,
+  /*check_dependency_p=*/true,
+  /*class_head_p=*/false,
+  /*is_declaration=*/true);
   /* If we found one, we're done.  */
   if (cp_parser_parse_definitely (parser))
 return id;
Index: testsuite/g++.dg/cpp0x/decltype-base1.C
===
--- testsuite/g++.dg/cpp0x/decltype-base1.C (revision 0)
+++ testsuite/g++.dg/cpp0x/decltype-base1.C (working copy)
@@ -0,0 +1,8 @@
+// PR c++/61683
+// { dg-do compile { target c++11 } }
+
+struct A {};
+A a;
+struct B : A {
+  B(): decltype(a)() {}
+};


Re: [PATCH 0/13] Add musl support to GCC

2015-04-29 Thread Joseph Myers
On Wed, 29 Apr 2015, Szabolcs Nagy wrote:

> only affects [u]int_fastN_t types
> (on 64bit systems for N=16,32 musl uses int but glibc uses long)
> 
> i can fix glibc-stdint.h, but it's yet another way in which the
> compiler is tied to a particular libc.
> 
> (using musl-stdint.h would be nicer, but that would require more
> changes i think, i have a fix now where the glibc-stdint.h types
> depend on OPTION_MUSL, but i still have to make sure OPTION_MUSL
> is always defined when this header is used).
> 
> (i'd prefer if the compiler did not know about these types, but
> the standard requires them in stdatomic.h without including stdint.h
> and in stdint.h in freestanding mode, i'm not sure if there is a
> workaround without depending on libc)

The compiler also needs to know these types for the Fortran C bindings.

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


Re: [C/C++ PATCH] Implement -Wshift-negative-value (PR c/65179)

2015-04-29 Thread Joseph Myers
On Mon, 27 Apr 2015, Marek Polacek wrote:

> trigger by default.  One change is that we reject programs that use shift with
> undefined behavior in a context where a constant expression is required, thus
> e.g. enum E { A = -1 << 0 };
> But I hope that's reasonable.

That seems appropriate (for C99 and above).

But if someone explicitly uses -Wshift-negative-value, I'd expect that to 
produce the warnings (as opposed to the rejections where a constant 
expression is required) even in C90 mode.  That is, for the warnings, I 
think flag_isoc99 should maybe affect the default (whether -Wextra enables 
the warning, or whatever such approach gets taken), but not whether 
-Wshift-negative-value, given that the option has been enabled, produces 
warnings.

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


Go patch committed: Fix escape analysis for multi-result calls

2015-04-29 Thread Ian Lance Taylor
This patch from Chris Manghane fixes the handling of multi-result
calls in escape analysis.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian
diff -r 76359c093067 go/escape.cc
--- a/go/escape.cc  Wed Apr 29 15:09:15 2015 -0700
+++ b/go/escape.cc  Wed Apr 29 15:27:38 2015 -0700
@@ -989,21 +989,21 @@
  Named_object* lhs_no = this->resolve_var_reference(assn->lhs());
  Named_object* rhs_no = this->resolve_var_reference(assn->rhs());
 
- if (assn->rhs()->is_composite_literal()
- || assn->rhs()->heap_expression() != NULL)
-   this->handle_composite_literal(var, assn->rhs());
- else if (assn->rhs()->call_result_expression() != NULL)
+ Expression* rhs = assn->rhs();
+ if (rhs->is_composite_literal()
+ || rhs->heap_expression() != NULL)
+   this->handle_composite_literal(var, rhs);
+
+ if (rhs->call_result_expression() != NULL)
{
  // V's initialization will be a call result if
  // V, V1 := call(VAR).
  // There are no useful edges to make from V, but we want
  // to make sure we handle the call that references VAR.
- Expression* call =
-   assn->rhs()->call_result_expression()->call();
- this->handle_call(var, call);
+ rhs = rhs->call_result_expression()->call();
}
- else if (assn->rhs()->call_expression() != NULL)
-   this->handle_call(var, assn->rhs());
+ if (rhs->call_expression() != NULL)
+   this->handle_call(var, rhs);
 
  // If there is no standalone variable on the rhs, this could be a
  // binary expression, which isn't interesting for analysis or a
@@ -1038,8 +1038,12 @@
break;
 
  case Statement::STATEMENT_EXPRESSION:
-   this->handle_call(var,
- p->statement->expression_statement()->expr());
+   {
+ Expression* call = p->statement->expression_statement()->expr();
+ if (call->call_result_expression() != NULL)
+   call = call->call_result_expression()->call();
+ this->handle_call(var, call);
+   }
break;
 
  case Statement::STATEMENT_GO:
@@ -1064,10 +1068,17 @@
  else if (cond->binary_expression() != NULL)
{
  Binary_expression* comp = cond->binary_expression();
- if (comp->left()->call_expression() != NULL)
-   this->handle_call(var, comp->left());
- if (comp->right()->call_expression() != NULL)
-   this->handle_call(var, comp->right());
+ Expression* left = comp->left();
+ Expression* right = comp->right();
+
+ if (left->call_result_expression() != NULL)
+   left = left->call_result_expression()->call();
+ if (left->call_expression() != NULL)
+   this->handle_call(var, left);
+ if (right->call_result_expression() != NULL)
+   right = right->call_result_expression()->call();
+ if (right->call_expression() != NULL)
+   this->handle_call(var, right);
}
}
break;
@@ -1092,16 +1103,10 @@
  // composite literal.
  this->handle_composite_literal(decl_no, init);
}
- else if (init->call_result_expression() != NULL)
-   {
- // V's initialization will be a call result if
- // V, V1 := call(VAR).
- // There's no useful edges to make from V or V1, but we want
- // to make sure we handle the call that references VAR.
- Expression* call = init->call_result_expression()->call();
- this->handle_call(var, call);
-   }
- else if (init->call_expression() != NULL)
+
+ if (init->call_result_expression() != NULL)
+   init = init->call_result_expression()->call();
+ if (init->call_expression() != NULL)
this->handle_call(var, init);
}
break;
@@ -1148,18 +1153,46 @@
   if (lhs_no == NULL)
break;
 
-  if (assn->rhs()->func_expression() != NULL)
+  Expression* rhs = assn->rhs();
+  if (rhs->temporary_reference_expression() != NULL)
+   rhs = rhs->temporary_reference_expression()->statement()->init();
+  if (rhs == NULL)
+   break;
+
+  if (rhs->call_result_expression() != NULL)
+   rhs = rhs->call_result_expression()->call();
+  if (rhs->call_expression() != NULL)
+   {
+ // It's not clear what variables we are trying to find references to
+ // 

Re: [Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding

2015-04-29 Thread Jeff Law

On 04/29/2015 03:36 PM, Jiong Wang wrote:


Jeff Law writes:


On 04/27/2015 02:21 PM, Jiong Wang wrote:


Jeff,

Sorry, I can't understand the meaning of "overlap between t_low and low",
assume "right" in "right value" means the opposite of "left" not
"correct".

So what you mean is t_low and low share the same pseudo regiser?

My concern is sharing the same pseudo or memory location.  But thinking
more about it, the shifted value has to have range information, so it
must have been an SSA_NAME, right?  If so, then it can't overlap with
the destination, so this is a non-issue.  Sorry for the confusion.


Thanks for the light. By looking at related code, looks like even it's
SSA_NAME, it's still possible to share the same pseudo given the
destination is in the same SSA map parition after ssa name coleascing?
If they're the same size and have non-overlapping lifetimes, then yes, 
they could be the same pseudo.  That ought to be easy to check. 
Thankfully we don't have to worry about MEMs, which is a harder check.



OK. I will rework the patch, and I found there is a function named
"expand_doubleword_shift" which looks like a more natural place to do
this optimization, although it's hard to get range info there. I will do
further explore on this.

Sounds good.

jeff


Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Jeff Law

On 04/29/2015 04:25 PM, Trevor Saunders wrote:

On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote:

On 04/29/2015 03:55 PM, Andreas Schwab wrote:

Trevor Saunders  writes:


it passes for me on x86_64-linux after that commit, what platform is
this?


Any one with #undef PCC_BITFIELD_TYPE_MATTERS.  See libobjc/encoding.c.

Can't you just answer the question Andreas instead of making Trevor go
looking around?  You already have this information, why make his job harder?



actually pointing out libojc/encoding.c was more useful since that makes
it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to
be changed to #if !

In that case, Andreas, please accept my apologies.

jeff



Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Jeff Law

On 04/29/2015 04:25 PM, Trevor Saunders wrote:

On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote:

On 04/29/2015 03:55 PM, Andreas Schwab wrote:

Trevor Saunders  writes:


it passes for me on x86_64-linux after that commit, what platform is
this?


Any one with #undef PCC_BITFIELD_TYPE_MATTERS.  See libobjc/encoding.c.

Can't you just answer the question Andreas instead of making Trevor go
looking around?  You already have this information, why make his job harder?



actually pointing out libojc/encoding.c was more useful since that makes
it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to
be changed to #if !


Trevor, try m68k-elf cross.


ok, lets see if I can get this to work (its an execution test that
breaks, so I'll need to setup binutils and qemu)
I've actually got a aranym m68k emulator here...  So I can do native 
bootstrapping and testing for m68k linux.  If you want me to test 
something, just let me know -- FWIW, it takes a week or so to bootstrap ;-)


jeff


Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Trevor Saunders
On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote:
> On 04/29/2015 03:55 PM, Andreas Schwab wrote:
> >Trevor Saunders  writes:
> >
> >>it passes for me on x86_64-linux after that commit, what platform is
> >>this?
> >
> >Any one with #undef PCC_BITFIELD_TYPE_MATTERS.  See libobjc/encoding.c.
> Can't you just answer the question Andreas instead of making Trevor go
> looking around?  You already have this information, why make his job harder?


actually pointing out libojc/encoding.c was more useful since that makes
it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to
be changed to #if !

> Trevor, try m68k-elf cross.

ok, lets see if I can get this to work (its an execution test that
breaks, so I'll need to setup binutils and qemu)

Trev

> 
> jeff


Go patch committed: Propagate escape info from closures to enclosed variables

2015-04-29 Thread Ian Lance Taylor
This patch from Chris Manghane fixes the Go frontend to propagate
escape information from closures to the enclosed variables to which
they refer.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian
diff -r 0010ef165479 go/escape.cc
--- a/go/escape.cc  Wed Apr 29 14:28:30 2015 -0700
+++ b/go/escape.cc  Wed Apr 29 15:07:47 2015 -0700
@@ -1276,8 +1276,22 @@
   Node* m = worklist.front();
   worklist.pop_front();
 
-  for (std::set::iterator n = m->edges().begin();
-  n != m->edges().end();
+  std::set reachable = m->edges();
+  if (m->object()->is_function()
+ && m->object()->func_value()->needs_closure())
+   {
+ // If a closure escapes everything it closes over also escapes.
+ Function* closure = m->object()->func_value();
+ for (size_t i = 0; i < closure->closure_field_count(); i++)
+   {
+ Named_object* enclosed = closure->enclosing_var(i);
+ Node* enclosed_node = this->lookup_connection_node(enclosed);
+ go_assert(enclosed_node != NULL);
+ reachable.insert(enclosed_node);
+   }
+   }
+  for (std::set::iterator n = reachable.begin();
+  n != reachable.end();
   ++n)
{
  // If an object can be reached from a node with ESCAPE_GLOBAL,
@@ -1296,7 +1310,7 @@
p != this->named_connection_nodes_.end();
++p)
 {
-  if (p->second->connection_node()->escape_state() == Node::ESCAPE_ARG)
+  if (p->second->connection_node()->escape_state() < Node::ESCAPE_NONE)
worklist.push_back(p->second);
 }
 
@@ -1305,15 +1319,30 @@
   Node* m = worklist.front();
   worklist.pop_front();
 
-  for (std::set::iterator n = m->edges().begin();
-  n != m->edges().end();
+  std::set reachable = m->edges();
+  if (m->object()->is_function()
+ && m->object()->func_value()->needs_closure())
+   {
+ // If a closure escapes everything it closes over also escapes.
+ Function* closure = m->object()->func_value();
+ for (size_t i = 0; i < closure->closure_field_count(); i++)
+   {
+ Named_object* enclosed = closure->enclosing_var(i);
+ Node* enclosed_node = this->lookup_connection_node(enclosed);
+ go_assert(enclosed_node != NULL);
+ reachable.insert(enclosed_node);
+   }
+   }
+  for (std::set::iterator n = reachable.begin();
+  n != reachable.end();
   ++n)
{
  // If an object can be reached from a node with ESCAPE_ARG,
  // it is ESCAPE_ARG or ESCAPE_GLOBAL.
- if ((*n)->connection_node()->escape_state() > Node::ESCAPE_ARG)
+ Node::Escapement_lattice e = m->connection_node()->escape_state();
+ if ((*n)->connection_node()->escape_state() > e)
{
- (*n)->connection_node()->set_escape_state(Node::ESCAPE_ARG);
+ (*n)->connection_node()->set_escape_state(e);
  worklist.push_back(*n);
}
}
diff -r 0010ef165479 go/gogo.h
--- a/go/gogo.h Wed Apr 29 14:28:30 2015 -0700
+++ b/go/gogo.h Wed Apr 29 15:07:47 2015 -0700
@@ -1042,6 +1042,11 @@
 this->is_unnamed_type_stub_method_ = true;
   }
 
+  // Return the amount of enclosed variables in this closure.
+  size_t
+  closure_field_count() const
+  { return this->closure_fields_.size(); }
+
   // Add a new field to the closure variable.
   void
   add_closure_field(Named_object* var, Location loc)


Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Jeff Law

On 04/29/2015 03:55 PM, Andreas Schwab wrote:

Trevor Saunders  writes:


it passes for me on x86_64-linux after that commit, what platform is
this?


Any one with #undef PCC_BITFIELD_TYPE_MATTERS.  See libobjc/encoding.c.
Can't you just answer the question Andreas instead of making Trevor go 
looking around?  You already have this information, why make his job harder?



Trevor, try m68k-elf cross.

jeff


Re: [Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding

2015-04-29 Thread Jiong Wang

Jeff Law writes:

> On 04/27/2015 02:21 PM, Jiong Wang wrote:
>
>> Jeff,
>>
>>Sorry, I can't understand the meaning of "overlap between t_low and low",
>>assume "right" in "right value" means the opposite of "left" not
>>"correct".
>>
>>So what you mean is t_low and low share the same pseudo regiser?
> My concern is sharing the same pseudo or memory location.  But thinking 
> more about it, the shifted value has to have range information, so it 
> must have been an SSA_NAME, right?  If so, then it can't overlap with 
> the destination, so this is a non-issue.  Sorry for the confusion.

Thanks for the light. By looking at related code, looks like even it's
SSA_NAME, it's still possible to share the same pseudo given the
destination is in the same SSA map parition after ssa name coleascing?   

> I've never liked the model of storing into TARGET when it's convenient. 
>   Because storing into TARGET is totally optional, it means the callers 
> have to check if the value was stored into TARGET or not.
>
> Sadly that model has been in the expanders as long as I can remember.
>
> So I think this can go forward once we resolve the case where 
> expand_variable_shift returns its value in something other than the 
> passed in target.

OK. I will rework the patch, and I found there is a function named
"expand_doubleword_shift" which looks like a more natural place to do
this optimization, although it's hard to get range info there. I will do
further explore on this.

-- 
Regards,
Jiong



Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Andreas Schwab
Trevor Saunders  writes:

> it passes for me on x86_64-linux after that commit, what platform is
> this?

Any one with #undef PCC_BITFIELD_TYPE_MATTERS.  See libobjc/encoding.c.

Andreas.

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


Re: [PATCH] gfortran testsuite: implicitly cleanup-modules

2015-04-29 Thread Joseph Myers
On Thu, 23 Apr 2015, Bernhard Reutner-Fischer wrote:

> I've done the above some time ago, dejagnu >= 1.5.2 has a "libdirs"
> variable so i'd like to propose to:
> 
> - Bump the required dejagnu version for gcc-6 to (let's say) 1.5.3

1.5.2 is only a few months old.  I suggest waiting until a given version 
is widely present in long-term-support GNU/Linux distributions before 
requiring it.

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


libgo patch committed: Support -buildmode=c-archive

2015-04-29 Thread Ian Lance Taylor
The upcoming Go 1.5 release of the gc compiler adds support for "go
build -buildmode=c-archive".  This can be used to build Go code into
an archive (a .a file) that can be linked with a non-Go program, such
that the non-Go program can call into Go code.  This patch adds
support for that to gccgo.

I'm going to commit this patch to the GCC 5 branch as well.  This will
permit the Go 1.5 go tool to be used with the GCC 5.2 and later.  That
way people won't have to wait for GCC 6.  This patch seems safe to me
and passes all my testing.

Bootstrapped and ran Go tests and gc cgo tests on
x86_64-unknown-linux-gnu.  Committed to mainline and GCC 5 branch.

Ian
diff -r ae8a4c892d42 libgo/Makefile.am
--- a/libgo/Makefile.am Fri Apr 24 15:07:55 2015 -0700
+++ b/libgo/Makefile.am Wed Apr 29 13:41:41 2015 -0700
@@ -105,7 +105,7 @@
 toolexeclib_LIBRARIES = libgobegin-llgo.a
 else
 toolexeclib_LTLIBRARIES = libgo.la
-toolexeclib_LIBRARIES = libgobegin.a libnetgo.a
+toolexeclib_LIBRARIES = libgobegin.a libgolibbegin.a libnetgo.a
 endif
 
 toolexeclibgo_DATA = \
@@ -2036,6 +2036,11 @@
 libgobegin_a_CFLAGS = $(AM_CFLAGS) -fPIC
 libgobegin_llgo_a_CFLAGS = $(AM_CFLAGS) -fPIC
 
+libgolibbegin_a_SOURCES = \
+   runtime/go-libmain.c
+
+libgolibbegin_a_CFLAGS = $(AM_CFLAGS) -fPIC
+
 libnetgo_a_SOURCES = $(go_netgo_files)
 libnetgo_a_LIBADD = netgo.o
 
@@ -2067,7 +2072,7 @@
 BUILDNETGO = \
$(MKDIR_P) $(@D); \
files=`echo $^ | sed -e 's/[^ ]*\.gox//g'`; \
-   $(GOCOMPILE) -I . -c -fgo-pkgpath=net -o $@ $$files
+   $(GOCOMPILE) -I . -c -fPIC -fgo-pkgpath=net -o $@ $$files
 
 GOTESTFLAGS =
 GOBENCH = 
diff -r ae8a4c892d42 libgo/runtime/go-cgo.c
--- a/libgo/runtime/go-cgo.cFri Apr 24 15:07:55 2015 -0700
+++ b/libgo/runtime/go-cgo.cWed Apr 29 13:41:41 2015 -0700
@@ -8,6 +8,9 @@
 #include "go-alloc.h"
 #include "interface.h"
 #include "go-panic.h"
+#include "go-type.h"
+
+extern void __go_receive (ChanType *, Hchan *, byte *);
 
 /* Prepare to call from code written in Go to code written in C or
C++.  This takes the current goroutine out of the Go scheduler, as
@@ -86,6 +89,15 @@
 
   runtime_exitsyscall ();
 
+  if (runtime_g ()->ncgo == 0)
+{
+  /* The C call to Go came from a thread not currently running any
+Go.  In the case of -buildmode=c-archive or c-shared, this
+call may be coming in before package initialization is
+complete.  Wait until it is.  */
+  __go_receive (NULL, runtime_main_init_done, NULL);
+}
+
   mp = runtime_m ();
   if (mp->needextram)
 {
@@ -177,3 +189,65 @@
 
   __go_panic (e);
 }
+
+/* Used for _cgo_wait_runtime_init_done.  This is based on code in
+   runtime/cgo/gcc_libinit.c in the master library.  */
+
+static pthread_cond_t runtime_init_cond = PTHREAD_COND_INITIALIZER;
+static pthread_mutex_t runtime_init_mu = PTHREAD_MUTEX_INITIALIZER;
+static _Bool runtime_init_done;
+
+/* This is called by exported cgo functions to ensure that the runtime
+   has been initialized before we enter the function.  This is needed
+   when building with -buildmode=c-archive or similar.  */
+
+void
+_cgo_wait_runtime_init_done (void)
+{
+  int err;
+
+  if (__atomic_load_n (&runtime_init_done, __ATOMIC_ACQUIRE))
+return;
+
+  err = pthread_mutex_lock (&runtime_init_mu);
+  if (err != 0)
+abort ();
+  while (!__atomic_load_n (&runtime_init_done, __ATOMIC_ACQUIRE))
+{
+  err = pthread_cond_wait (&runtime_init_cond, &runtime_init_mu);
+  if (err != 0)
+   abort ();
+}
+  err = pthread_mutex_unlock (&runtime_init_mu);
+  if (err != 0)
+abort ();
+}
+
+/* This is called by runtime_main after the Go runtime is
+   initialized.  */
+
+void
+_cgo_notify_runtime_init_done (void)
+{
+  int err;
+
+  err = pthread_mutex_lock (&runtime_init_mu);
+  if (err != 0)
+abort ();
+  __atomic_store_n (&runtime_init_done, 1, __ATOMIC_RELEASE);
+  err = pthread_cond_broadcast (&runtime_init_cond);
+  if (err != 0)
+abort ();
+  err = pthread_mutex_unlock (&runtime_init_mu);
+  if (err != 0)
+abort ();
+}
+
+// runtime_iscgo is set to true if some cgo code is linked in.
+// This is done by a constructor in the cgo generated code.
+_Bool runtime_iscgo;
+
+// runtime_cgoHasExtraM is set on startup when an extra M is created
+// for cgo.  The extra M must be created before any C/C++ code calls
+// cgocallback.
+_Bool runtime_cgoHasExtraM;
diff -r ae8a4c892d42 libgo/runtime/go-libmain.c
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/libgo/runtime/go-libmain.cWed Apr 29 13:41:41 2015 -0700
@@ -0,0 +1,114 @@
+/* go-libmain.c -- the startup function for a Go library.
+
+   Copyright 2015 The Go Authors. All rights reserved.
+   Use of this source code is governed by a BSD-style
+   license that can be found in the LICENSE file.  */
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "runtime.h"
+#include "go-alloc.h"
+#include "array.h"
+#include "arch.h"
+#include "malloc.h"

Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Trevor Saunders
On Wed, Apr 29, 2015 at 02:35:39PM +0200, Andreas Schwab wrote:
> spawn /daten/aranym/gcc/gcc-20150429/Build/gcc/xgcc 
> -B/daten/aranym/gcc/gcc-20150429/Build/gcc/ 
> /daten/aranym/gcc/gcc-20150429/gcc/testsuite/objc/execute/bf-1.m 
> -fno-diagnostics-show-caret -fdiagnostics-color=never -w -O0 -fgnu-runtime 
> -I/daten/aranym/gcc/gcc-20150429/gcc/testsuite/../../libobjc 
> -B/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs 
> -L/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs -lobjc -lm 
> -o /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0
> PASS: objc/execute/bf-1.m compilation,  -O0 -fgnu-runtime
> Executing on aranym: OMP_NUM_THREADS=2 
> LD_LIBRARY_PATH=.::/daten/aranym/gcc/gcc-20150429/Build/gcc:/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs
>  timeout 600 /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0  
>   (timeout = 300)
> Executed /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0, 
> status 1
> Output: type = {class_vars=#fc{?=b0i2b2i3b5i12}c}
> ivar 'isa', type '#', offset 0d
> ivar 'f', type 'f', offset 4d
> ivar 'a', type 'c', offset 8d
> ivar 'flags', type '{?="i"b0i2"j"b2i3"k"b5i12}', offset 9d
> ivar 'c', type 'c', offset 12d
> real ivar 'isa' offset 0d
> computed type '#fc{?=b0i2b2i3b5i12}c}' offset 0
> real ivar 'f' offset 4d
> computed type 'fc{?=b0i2b2i3b5i12}c}' offset 4
> real ivar 'a' offset 8d
> computed type 'c{?=b0i2b2i3b5i12}c}' offset 8
> real ivar 'flags' offset 9d
> computed type '{?=b0i2b2i3b5i12}c}' offset 10
> offset 9d and computed position 10 don't match on ivar 'flags' (i = 3)
> child process exited abnormally
> FAIL: objc/execute/bf-1.m execution,  -O0 -fgnu-runtime

it passes for me on x86_64-linux after that commit, what platform is
this?

Trev

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


New Danish PO file for 'gcc' (version 5.1.0)

2015-04-29 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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




Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

2015-04-29 Thread Caroline Tice
Here is a new patch to update the cold name partition so that it will
only be treated like a function name and be given a size on the
architectures that specifically define macros for such.

I also updated the test case to try to only test on the appropriate
architectures.  I am not sure I got the target triples correct for
this, so I would appreciate some extra attention to that in the
review.  I have tested this new patch on my workstation and it works
as intended.  I am in the process of bootstrapping with the new patch.
Assuming that the bootstrap passes, is this ok to commit?

-- Caroline Tice
cmt...@google.com

ChangeLog (gcc):

2015-04-29  Caroline Tice  

PR 65929
* config/elfos.h (ASM_DECLARE_COLD_FUNCTION_NAME): New macro definition.
(ASM_DECLARE_COLD_FUNCTION_SIZE): New macro definition.
* final.c (final_scan_insn):  Use ASM_DECLARE_COLD_FUNCTION_NAME
instead of ASM_DECLARE_FUNCTION_NAME for cold partition name.
* varasm.c (assemble_end_function):  Use ASM_DECLARE_COLD_FUNCTION_SIZE
instead of ASM_DECLARE_FUNCTION_SIZE for cold partition size.

ChangeLog (testsuite):

2015-04-29  Caroline Tice  

   PR  65929
* gcc.dg/tree-prof/cold_partition_label.c:  Only check for cold
partition size on certain targets.





On Wed, Apr 29, 2015 at 11:59 AM, Caroline Tice  wrote:
> Thank you; I will work with your suggestions and try to get a new
> patch done soon.
>
> -- Caroline Tice
> cmt...@google.com
>
>
> On Wed, Apr 29, 2015 at 11:34 AM, Uros Bizjak  wrote:
>> On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak  wrote:
>>> On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice  wrote:
 The attached patch can revert the previous patch, if that is the way
 we should proceed on this.  If you want me to apply the reversion,
 please let me know.

 I would be happy to fix to the problem, rather than just reverting the
 patch, but I do not have expertise in assembly language on other
 platforms, so I would need some help, if anyone would be interested in
 helping me?
>>>
>>> How about adding ASM_DECLARE_COLD_FUNCTION_NAME and
>>> ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used
>>> instead, and targets are free to define them in any way.
>>
>> Something like the attached prototype RFC patch. Using this patch,
>> readelf -sW returns:
>>
>> Symbol table '.symtab' contains 18 entries:
>>Num:Value  Size TypeBind   Vis  Ndx Name
>>  0:  0 NOTYPE  LOCAL  DEFAULT  UND
>>  1:  0 SECTION LOCAL  DEFAULT1
>>  2:  0 SECTION LOCAL  DEFAULT3
>>  3:  0 SECTION LOCAL  DEFAULT4
>>  4:  0 SECTION LOCAL  DEFAULT5
>>  5:  0 SECTION LOCAL  DEFAULT6
>>  6:  0 SECTION LOCAL  DEFAULT8
>>  7:  8 FUNCLOCAL  DEFAULT6 main.cold.0
>>  8:  0 SECTION LOCAL  DEFAULT   10
>>  9:  0 SECTION LOCAL  DEFAULT   13
>> 10:  0 SECTION LOCAL  DEFAULT   12
>> 11:    312 FUNCGLOBAL DEFAULT [: 88] 8 
>> main
>> 12: 0008   160 OBJECT  GLOBAL DEFAULT  COM buf
>> 13:  0 NOTYPE  GLOBAL DEFAULT  UND memset
>> 14: 44 FUNCGLOBAL DEFAULT [: 88] 1 
>> sub2
>> 15:  0 NOTYPE  GLOBAL DEFAULT  UND strcmp
>> 16:  0 NOTYPE  GLOBAL DEFAULT  UND exit
>> 17:  0 NOTYPE  GLOBAL DEFAULT  UND abort
>>
>> Uros.
Index: gcc/config/elfos.h
===
--- gcc/config/elfos.h	(revision 222584)
+++ gcc/config/elfos.h	(working copy)
@@ -284,6 +284,22 @@
   while (0)
 #endif
 
+/* Write the extra assembler code needed to declare the name of a
+   cold function partition properly. Some svr4 assemblers need to also
+   have something extra said about the function's return value.  We
+   allow for that here.  */
+
+#ifndef ASM_DECLARE_COLD_FUNCTION_NAME
+#define ASM_DECLARE_COLD_FUNCTION_NAME(FILE, NAME, DECL)	\
+  do\
+{\
+  ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "function");	\
+  ASM_DECLARE_RESULT (FILE, DECL_RESULT (DECL));		\
+  ASM_OUTPUT_FUNCTION_LABEL (FILE, NAME, DECL);		\
+}\
+  while (0)
+#endif
+
 /* Write the extra assembler code needed to declare an object properly.  */
 
 #ifdef HAVE_GAS_GNU_UNIQUE_OBJECT
@@ -358,6 +374,17 @@
   while (0)
 #endif
 
+/* This is how to declare the size of a cold function partition.  */
+#ifndef ASM_DECLARE_COLD_FUNCTION_SIZE
+#define ASM_DECLARE_COLD_FUNCTION_SIZE(FILE, FNAME, DECL)	\
+  do\
+{\
+  if (!flag_inhibit_size_directive)\
+	ASM_OUTPUT_MEASURED_SIZE (FILE, FNAME);			\
+}\
+  while (0)
+#endif
+
 /*

Re: [PATCH 5/14][AArch64] Add basic fp16 support

2015-04-29 Thread Joseph Myers
On Wed, 22 Apr 2015, Alan Lawrence wrote:

> [Resending with correct in-reply-to header]
> 
> This adds basic support for moving __fp16 values around, passing and
> returning, and operating on them by promoting to 32-bit floats. Also a few
> scalar testcases.

I'd think it would be desirable to share tests between ARM and AArch64 as 
far as possible (where applicable to both - so not the tests for the 
alternative format, and some of the gcc.target/arm/fp16-* tests using 
scan-assembler might need adapting to work for AArch64).

To the extent that the ARM implementation follows an old specification and 
AArch64 is following newer ACLE, of course, this might require ARM to be 
updated to follow newer ACLE before tests can be shared.  (For example, 
the older specification implemented for ARM includes double rounding when 
converting from double to fp16, but ACLE specifies single rounding.)

Longer term, I'd hope the aim would be for semantics to follow TS 18661-3 
(DTS ballot recently passed), using the standard name _Float16 (and 
FLT_EVAL_METHOD == 32 as the nearest equivalent of the promotions to 
float).

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


Re: [PATCH, i386]: Fix PR 65871, bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

2015-04-29 Thread Uros Bizjak
On Wed, Apr 29, 2015 at 9:02 PM, Uros Bizjak  wrote:
> Hello!
>
> Attached patch implements a CCZ-only setting pattern for a couple of
> BMI[,2] intrinsics.

These two insns are three operand instructions, and some peephole2
patterns were not prepared for this. Please note that clobbered
register can be different than input registers. Attached patch fixes
this omission.

2015-04-29  Uros Bizjak  

PR target/65871
* config/i386/i386.md (*bmi_bextr__cczonly): New pattern.
(*bmi2_bzhi_3_1_cczonly): Ditto.
(setcc+movzbl peephole2): Check also clobbered reg.
(setcc+andl peephole2): Ditto.

Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 222590)
+++ config/i386/i386.md (working copy)
@@ -11567,7 +11567,9 @@
(zero_extend (match_dup 1)))]
   "(peep2_reg_dead_p (3, operands[1])
 || operands_match_p (operands[1], operands[3]))
-   && ! reg_overlap_mentioned_p (operands[3], operands[0])"
+   && ! reg_overlap_mentioned_p (operands[3], operands[0])
+   && ! (GET_CODE (operands[4]) == CLOBBER
+&& reg_mentioned_p (operands[3], operands[4]))"
   [(parallel [(set (match_dup 5) (match_dup 0))
  (match_dup 4)])
(set (strict_low_part (match_dup 6))
@@ -11610,7 +11612,9 @@
  (clobber (reg:CC FLAGS_REG))])]
   "(peep2_reg_dead_p (3, operands[1])
 || operands_match_p (operands[1], operands[3]))
-   && ! reg_overlap_mentioned_p (operands[3], operands[0])"
+   && ! reg_overlap_mentioned_p (operands[3], operands[0])
+   && ! (GET_CODE (operands[4]) == CLOBBER
+&& reg_mentioned_p (operands[3], operands[4]))"
   [(parallel [(set (match_dup 5) (match_dup 0))
  (match_dup 4)])
(set (strict_low_part (match_dup 6))


RE: [Patch, MIPS] Change mips4 default processor to r10K

2015-04-29 Thread Moore, Catherine
> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Tuesday, April 28, 2015 2:38 PM
> 
> Steve Ellcey   writes:
> >
> > 2015-04-28  Steve Ellcey  
> >
> > * config/mips/mips-cpus.def: (mips4): Change default processor
> > from PROCESSOR_R8000 to PROCESSOR_R1.
> 
> Ok with me. I'd like Catherine to have the chance to raise any concerns
> though.

This change is OK with me, as well.
Catherine



Re: C++ PATCH for c++/50800 (ICE with may_alias and templates)

2015-04-29 Thread Jason Merrill

On 04/29/2015 07:41 AM, Markus Trippelsdorf wrote:

I'm getting hundreds of new warnings when building LLVM, e.g.:


Whoops.  Fixed thus.


commit 7da5a68ba55cd49c46ff9ac547df59248bd90f7d
Author: Jason Merrill 
Date:   Wed Apr 29 16:04:08 2015 -0400

	PR c++/50800
	* tree.c (apply_identity_attributes): Fix handling of classes.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index d00f0d7..ec9be8c 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1187,6 +1187,13 @@ apply_identity_attributes (tree result, tree attribs, bool *remove_attributes)
   tree new_attribs = NULL_TREE;
   tree *p = &new_attribs;
 
+  if (OVERLOAD_TYPE_P (result))
+{
+  /* On classes and enums all attributes are ingrained.  */
+  gcc_assert (attribs == TYPE_ATTRIBUTES (result));
+  return result;
+}
+
   for (tree a = attribs; a; a = TREE_CHAIN (a))
 {
   const attribute_spec *as
diff --git a/gcc/testsuite/g++.dg/cpp0x/alignas3.C b/gcc/testsuite/g++.dg/cpp0x/alignas3.C
new file mode 100644
index 000..aa62e5a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alignas3.C
@@ -0,0 +1,20 @@
+// PR c++/50800
+// { dg-do compile { target c++11 } }
+
+template  struct A;
+template  struct A<_Up *> { typedef _Up type; };
+template  struct B { typedef typename A::type type; };
+template  struct C;
+template  struct C {
+  typedef typename B::type SimpleType;
+};
+template  struct D { typedef int ret_type; };
+template  struct F {
+  typedef typename D::SimpleType>::ret_type ret_type;
+};
+template  typename F::ret_type cast(Y &);
+class CompoundStmt;
+class alignas(8) Stmt {
+  Stmt *Children[1];
+  CompoundStmt *getBlock() const { cast(Children[0]); }
+};


Re: [PATCH] Refactor handle_section_attribute to reduce nesting and distinguish error cases

2015-04-29 Thread Jeff Law

On 04/26/2015 07:09 PM, Josh Triplett wrote:

handle_section_attribute contains many levels of nested conditionals and
branching code flow paths, with the error cases sometimes in the else
case and sometimes in the if case.  Simplify the code flow into a series
of potential failure cases ending with the successful path, with no
nesting and no else clauses.
---

I do not have commit access; if you approve, please commit.

This cleanup will help enable a larger patch enhancing the section attribute.

gcc/Changelog entry:

2014-08-24  Josh Triplett  

 * c-family/c-common.c (handle_section_attribute): Refactor to reduce
 nesting and distinguish between error cases.

Installed on the trunk.

WRT the larger patch, if you don't have a copyright assignment on file 
with the FSF, you should get that process started.  ass...@gnu.org.



jeff



RE: [PATCH v4][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

2015-04-29 Thread Moore, Catherine


> -Original Message-
> From: Petar Jovanovic [mailto:petar.jovano...@rt-rk.com]
> Sent: Friday, April 24, 2015 10:51 AM
> Subject: [PATCH v4][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
> 
> gcc/ChangeLog:
> 
> 2015-04-21  Petar Jovanovic  
> 
>   * config/mips/mips.h (CRT_CALL_STATIC_FUNCTION): Fix the macro
> to use
>   la/jalr instead of jal.
> 
> gcc/testsuite/ChangeLog:
> 
> 2015-04-21  Petar Jovanovic  
> 
>   * gcc.target/mips/call-from-init.c: New test.
>   * gcc.target/mips/mips.exp: Add section_start to


Thank you, Petar.  I have now committed this patch.
Catherine



Re: [C PATCH] c_incomplete_type_error TLC

2015-04-29 Thread Jeff Law

On 04/29/2015 12:51 PM, Marek Polacek wrote:

This patch cleans up c_incomplete_type_error a bit: today, we should prefer
using %qT over %<%s %E%> (the code is largely intact since 1992), and second,
we should print the type if we can.  The "invalid use of incomplete typedef"
error wasn't tested at all, so I'm also adding a test to exercise that code
path.

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

2015-04-29  Marek Polacek  

* c-typeck.c (c_incomplete_type_error): Refactor to use %qT.  Print
the type of a decl.

* gcc.dg/incomplete-typedef-1.c: New test.

OK.
jeff



Re: [patch] Rewrite check_global_declarations() generically

2015-04-29 Thread Jason Merrill

On 04/28/2015 09:01 PM, Aldy Hernandez wrote:

The approach looks good to me.


-  analyze_functions ();
+  analyze_functions (true);


In the C++ front end at least we comment anonymous boolean arguments, i.e.

 analyze_functions (/*first_time*/true);

Let's do that here, too.  Similarly for the calls to referred_to_p (false).


+  /* ?? Why are we looking at TREE_USED?  Shouldn't the call to
+referred_to_p above be enough?  Apparently not, because the
+`__unused__' attribute is not being considered for
+referred_to_p.  */


Seems like you answered your question.  :)


+  /* Global ctors and dtors are called by the runtime.  */
+  && (TREE_CODE (decl) != FUNCTION_DECL
+ || (!DECL_STATIC_CONSTRUCTOR (decl)
+ && !DECL_STATIC_DESTRUCTOR (decl)))


Maybe check snode->needed_p instead?

Jason




Re: [PATCH, i386]: Fix PR 65871, bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

2015-04-29 Thread Uros Bizjak
On Wed, Apr 29, 2015 at 9:23 PM, Jakub Jelinek  wrote:
> On Wed, Apr 29, 2015 at 09:02:16PM +0200, Uros Bizjak wrote:
>> Hello!
>>
>> Attached patch implements a CCZ-only setting pattern for a couple of
>> BMI[,2] intrinsics.
>
> What about the case when the result is used, but also tested for zero or
> non-zero?  Like e.g.
> int bar (void);
> int foo (unsigned int x, unsigned int y)
> {
>   int v = __builtin_ia32_bextr_u32 (x, y);
>   if (v)
> return v;
>   return bar ();
> }

Yes, I have considered this usage, but it would require *another*
pattern. I don't think it is worth just to have one test insn less...

Uros.


Re: [PATCH, i386]: Fix PR 65871, bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

2015-04-29 Thread Jakub Jelinek
On Wed, Apr 29, 2015 at 09:02:16PM +0200, Uros Bizjak wrote:
> Hello!
> 
> Attached patch implements a CCZ-only setting pattern for a couple of
> BMI[,2] intrinsics.

What about the case when the result is used, but also tested for zero or
non-zero?  Like e.g.
int bar (void);
int foo (unsigned int x, unsigned int y)
{
  int v = __builtin_ia32_bextr_u32 (x, y);
  if (v)
return v;
  return bar ();
}

Jakub


Re: [RFC]: Remove Mem/address type assumption in combiner

2015-04-29 Thread Jeff Law

On 04/29/2015 03:25 AM, Kumar, Venkataramanan wrote:

Hi Jeff/Segher,

When we see an  RTX code with PLUS or MINUS then it is treated as  MEM/address 
type (we are inside address RTX).
Is there any significance on that assumption?  I removed this assumption and 
the test case in the PR 63949 passed.
When appearing inside a MEM, we have different canonicalization rules. 
The comment in make_compound_operation clearly indicates that the 
PLUS/MINUS support is a hack.  However, I'm pretty sure it was strictly 
for getting better code than for correctness.


One path forward is to properly track if we're in a MEM, at which point 
the hack for PLUS/MINUS could probably just go away.





diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..945abdb 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code)
   but once inside, go back to our default of SET.  */

next_code = (code == MEM ? MEM
-  : ((code == PLUS || code == MINUS)
- && SCALAR_INT_MODE_P (mode)) ? MEM
: ((code == COMPARE || COMPARISON_P (x))
   && XEXP (x, 1) == const0_rtx) ? COMPARE
: in_code == COMPARE ? SET : in_code);


On X86_64, it passes bootstrap and regression tests.
But on Aarch64 the test in PR passed, but I got a few test case failures.

Tests that now fail, but worked before:

gcc.target/aarch64/adds1.c scan-assembler adds\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3
gcc.target/aarch64/adds1.c scan-assembler adds\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 3
So that test seems to want to verify that you can generate a shift-add 
type instruction.  I suspect the others are similar.  I'd be curious to 
see the .combine dump as well as the final assembly for this test.



Which is a strong hint that we should be looking at target with 
shift-add style instructions.  ARM, AArch64, HPPA, x86 come immediately 
to mind.






There are few patterns based on multiplication operations in Aarch64 backend 
which are used to match with the pattern combiner generated.
Now those patterns have to be fixed to use SHIFTS.  Also need to see any impact 
on other targets.

But  before that  I wanted to check if the assumption in combiner,  can simply 
be removed ?
Given what I'm seeing now, I doubt it can simply be removed at this 
point (which is a change in my position) since ports with these 
shift-add style instructions have probably been tuned to work with 
existing combine behaviour.  We may need to do a deep test across 
various targets to identify those affected and fix them.


jeff



Re: [RFC]: Remove Mem/address type assumption in combiner

2015-04-29 Thread Jeff Law

On 04/29/2015 11:03 AM, Segher Boessenkool wrote:


Right.  It would be good if you could find out for what targets it matters.
The thing is, if a target expects only the patterns as combine used to make
them, it will regress (as you've seen on aarch64); but it will regress
_silently_.  Which isn't so nice.


But  before that  I wanted to check if the assumption in combiner,  can simply 
be removed ?


Seeing for what targets / patterns it makes a difference would tell us the
answer to that, too :-)
Right.  ANd that was one of the two general directions I recommended 
earlier this week ;-)


1. Figure out if this code still matters at all.
2. If the code still matters, accurately track if we're
   inside a MEM so that things canonicalize correctly.

jeff


Re: [RFC]: Remove Mem/address type assumption in combiner

2015-04-29 Thread Jeff Law

On 04/29/2015 03:25 AM, Kumar, Venkataramanan wrote:

Hi Jeff/Segher,

Restarting the discussion on the GCC combiner assumption about Memory/address 
type.
Ref: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01298.html
https://gcc.gnu.org/ml/gcc/2015-04/msg00028.html



Regards,
Venkat.

PS:  I am starting a new thread since I no more have access to Linaro ID from 
where I sent the earlier mail.
Funny, I sent mail just a few days ago trying to get this restarted, but 
it went to your Linaro address.  I'll forward it separately.



Jeff



[PATCH, i386]: Fix PR 65871, bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

2015-04-29 Thread Uros Bizjak
Hello!

Attached patch implements a CCZ-only setting pattern for a couple of
BMI[,2] intrinsics.

2015-04-29  Uros Bizjak  

PR target/65871
* config/i386/i386.md (*bmi_bextr__cczonly): New pattern.
(*bmi2_bzhi_3_1_cczonly): Ditto.

testsuite/ChangeLog:

2015-04-29  Uros Bizjak  

PR target/65871
* gcc.target/i386/pr65871-1.c: New test
* gcc.target/i386/pr65871-2.c: Ditto.

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

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 222585)
+++ config/i386/i386.md (working copy)
@@ -12594,6 +12594,20 @@
(set_attr "btver2_decode" "direct, double")
(set_attr "mode" "")])
 
+(define_insn "*bmi_bextr__cczonly"
+  [(set (reg:CCZ FLAGS_REG)
+   (compare:CCZ
+ (unspec:SWI48 [(match_operand:SWI48 1 "nonimmediate_operand" "r,m")
+(match_operand:SWI48 2 "register_operand" "r,r")]
+   UNSPEC_BEXTR)
+ (const_int 0)))
+   (clobber (match_scratch:SWI48 0 "=r,r"))]
+  "TARGET_BMI"
+  "bextr\t{%2, %1, %0|%0, %1, %2}"
+  [(set_attr "type" "bitmanip")
+   (set_attr "btver2_decode" "direct, double")
+   (set_attr "mode" "")])
+
 (define_insn "*bmi_blsi_"
   [(set (match_operand:SWI48 0 "register_operand" "=r")
 (and:SWI48
@@ -12667,6 +12681,7 @@
(set_attr "mode" "")])
 
 (define_mode_attr k [(SI "k") (DI "q")])
+
 (define_insn "*bmi2_bzhi_3_1"
   [(set (match_operand:SWI48 0 "register_operand" "=r")
(zero_extract:SWI48
@@ -12682,6 +12697,23 @@
(set_attr "prefix" "vex")
(set_attr "mode" "")])
 
+(define_insn "*bmi2_bzhi_3_1_cczonly"
+  [(set (reg:CCZ FLAGS_REG)
+   (compare:CCZ
+ (zero_extract:SWI48
+   (match_operand:SWI48 1 "nonimmediate_operand" "rm")
+   (umin:SWI48
+ (zero_extend:SWI48 (match_operand:QI 2 "register_operand" "r"))
+ (match_operand:SWI48 3 "const_int_operand" "n"))
+   (const_int 0))
+   (const_int 0)))
+   (clobber (match_scratch:SWI48 0 "=r"))]
+  "TARGET_BMI2 && INTVAL (operands[3]) ==  * BITS_PER_UNIT"
+  "bzhi\t{%2, %1, %0|%0, %1, %2}"
+  [(set_attr "type" "bitmanip")
+   (set_attr "prefix" "vex")
+   (set_attr "mode" "")])
+
 (define_insn "bmi2_pdep_3"
   [(set (match_operand:SWI48 0 "register_operand" "=r")
 (unspec:SWI48 [(match_operand:SWI48 1 "register_operand" "r")
Index: testsuite/gcc.target/i386/pr65871-1.c
===
--- testsuite/gcc.target/i386/pr65871-1.c   (revision 0)
+++ testsuite/gcc.target/i386/pr65871-1.c   (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mbmi" } */
+
+int foo (unsigned int x, unsigned int y)
+{
+  if (__builtin_ia32_bextr_u32 (x, y))
+return 1;
+
+  return 0;
+}
+
+/* { dg-final { scan-assembler-not "test" } } */
Index: testsuite/gcc.target/i386/pr65871-2.c
===
--- testsuite/gcc.target/i386/pr65871-2.c   (revision 0)
+++ testsuite/gcc.target/i386/pr65871-2.c   (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mbmi2" } */
+
+int foo (unsigned int x, unsigned int y)
+{
+  if (__builtin_ia32_bzhi_si (x, y))
+return 1;
+
+  return 0;
+}
+
+/* { dg-final { scan-assembler-not "test" } } */


Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

2015-04-29 Thread Caroline Tice
Thank you; I will work with your suggestions and try to get a new
patch done soon.

-- Caroline Tice
cmt...@google.com


On Wed, Apr 29, 2015 at 11:34 AM, Uros Bizjak  wrote:
> On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak  wrote:
>> On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice  wrote:
>>> The attached patch can revert the previous patch, if that is the way
>>> we should proceed on this.  If you want me to apply the reversion,
>>> please let me know.
>>>
>>> I would be happy to fix to the problem, rather than just reverting the
>>> patch, but I do not have expertise in assembly language on other
>>> platforms, so I would need some help, if anyone would be interested in
>>> helping me?
>>
>> How about adding ASM_DECLARE_COLD_FUNCTION_NAME and
>> ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used
>> instead, and targets are free to define them in any way.
>
> Something like the attached prototype RFC patch. Using this patch,
> readelf -sW returns:
>
> Symbol table '.symtab' contains 18 entries:
>Num:Value  Size TypeBind   Vis  Ndx Name
>  0:  0 NOTYPE  LOCAL  DEFAULT  UND
>  1:  0 SECTION LOCAL  DEFAULT1
>  2:  0 SECTION LOCAL  DEFAULT3
>  3:  0 SECTION LOCAL  DEFAULT4
>  4:  0 SECTION LOCAL  DEFAULT5
>  5:  0 SECTION LOCAL  DEFAULT6
>  6:  0 SECTION LOCAL  DEFAULT8
>  7:  8 FUNCLOCAL  DEFAULT6 main.cold.0
>  8:  0 SECTION LOCAL  DEFAULT   10
>  9:  0 SECTION LOCAL  DEFAULT   13
> 10:  0 SECTION LOCAL  DEFAULT   12
> 11:    312 FUNCGLOBAL DEFAULT [: 88] 8 main
> 12: 0008   160 OBJECT  GLOBAL DEFAULT  COM buf
> 13:  0 NOTYPE  GLOBAL DEFAULT  UND memset
> 14: 44 FUNCGLOBAL DEFAULT [: 88] 1 sub2
> 15:  0 NOTYPE  GLOBAL DEFAULT  UND strcmp
> 16:  0 NOTYPE  GLOBAL DEFAULT  UND exit
> 17:  0 NOTYPE  GLOBAL DEFAULT  UND abort
>
> Uros.


Contents of PO file 'cpplib-5.1.0.sv.po'

2015-04-29 Thread Translation Project Robot


cpplib-5.1.0.sv.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.



New Swedish PO file for 'cpplib' (version 5.1.0)

2015-04-29 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

http://translationproject.org/latest/cpplib/sv.po

(This file, 'cpplib-5.1.0.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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




[C PATCH] c_incomplete_type_error TLC

2015-04-29 Thread Marek Polacek
This patch cleans up c_incomplete_type_error a bit: today, we should prefer
using %qT over %<%s %E%> (the code is largely intact since 1992), and second,
we should print the type if we can.  The "invalid use of incomplete typedef"
error wasn't tested at all, so I'm also adding a test to exercise that code
path.

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

2015-04-29  Marek Polacek  

* c-typeck.c (c_incomplete_type_error): Refactor to use %qT.  Print
the type of a decl.

* gcc.dg/incomplete-typedef-1.c: New test.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index c58e918..cc4acf7 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -229,15 +229,13 @@ require_complete_type (tree value)
 void
 c_incomplete_type_error (const_tree value, const_tree type)
 {
-  const char *type_code_string;
-
   /* Avoid duplicate error message.  */
   if (TREE_CODE (type) == ERROR_MARK)
 return;
 
   if (value != 0 && (TREE_CODE (value) == VAR_DECL
 || TREE_CODE (value) == PARM_DECL))
-error ("%qD has an incomplete type", value);
+error ("%qD has an incomplete type %qT", value, type);
   else
 {
 retry:
@@ -246,15 +244,8 @@ c_incomplete_type_error (const_tree value, const_tree type)
   switch (TREE_CODE (type))
{
case RECORD_TYPE:
- type_code_string = "struct";
- break;
-
case UNION_TYPE:
- type_code_string = "union";
- break;
-
case ENUMERAL_TYPE:
- type_code_string = "enum";
  break;
 
case VOID_TYPE:
@@ -280,11 +271,10 @@ c_incomplete_type_error (const_tree value, const_tree 
type)
}
 
   if (TREE_CODE (TYPE_NAME (type)) == IDENTIFIER_NODE)
-   error ("invalid use of undefined type %<%s %E%>",
-  type_code_string, TYPE_NAME (type));
+   error ("invalid use of undefined type %qT", type);
   else
/* If this type has a typedef-name, the TYPE_NAME is a TYPE_DECL.  */
-   error ("invalid use of incomplete typedef %qD", TYPE_NAME (type));
+   error ("invalid use of incomplete typedef %qT", type);
 }
 }
 
diff --git gcc/testsuite/gcc.dg/incomplete-typedef-1.c 
gcc/testsuite/gcc.dg/incomplete-typedef-1.c
index e69de29..622bf65 100644
--- gcc/testsuite/gcc.dg/incomplete-typedef-1.c
+++ gcc/testsuite/gcc.dg/incomplete-typedef-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+typedef struct S TS;
+typedef union U TU;
+
+void
+foo (void)
+{
+  (TS) { }; /* { dg-error "invalid use of incomplete typedef" } */
+  (TU) { }; /* { dg-error "invalid use of incomplete typedef" } */
+}

Marek


Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

2015-04-29 Thread Uros Bizjak
On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak  wrote:
> On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice  wrote:
>> The attached patch can revert the previous patch, if that is the way
>> we should proceed on this.  If you want me to apply the reversion,
>> please let me know.
>>
>> I would be happy to fix to the problem, rather than just reverting the
>> patch, but I do not have expertise in assembly language on other
>> platforms, so I would need some help, if anyone would be interested in
>> helping me?
>
> How about adding ASM_DECLARE_COLD_FUNCTION_NAME and
> ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used
> instead, and targets are free to define them in any way.

Something like the attached prototype RFC patch. Using this patch,
readelf -sW returns:

Symbol table '.symtab' contains 18 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND
 1:  0 SECTION LOCAL  DEFAULT1
 2:  0 SECTION LOCAL  DEFAULT3
 3:  0 SECTION LOCAL  DEFAULT4
 4:  0 SECTION LOCAL  DEFAULT5
 5:  0 SECTION LOCAL  DEFAULT6
 6:  0 SECTION LOCAL  DEFAULT8
 7:  8 FUNCLOCAL  DEFAULT6 main.cold.0
 8:  0 SECTION LOCAL  DEFAULT   10
 9:  0 SECTION LOCAL  DEFAULT   13
10:  0 SECTION LOCAL  DEFAULT   12
11:    312 FUNCGLOBAL DEFAULT [: 88] 8 main
12: 0008   160 OBJECT  GLOBAL DEFAULT  COM buf
13:  0 NOTYPE  GLOBAL DEFAULT  UND memset
14: 44 FUNCGLOBAL DEFAULT [: 88] 1 sub2
15:  0 NOTYPE  GLOBAL DEFAULT  UND strcmp
16:  0 NOTYPE  GLOBAL DEFAULT  UND exit
17:  0 NOTYPE  GLOBAL DEFAULT  UND abort

Uros.
Index: config/elfos.h
===
--- config/elfos.h  (revision 222585)
+++ config/elfos.h  (working copy)
@@ -284,6 +284,17 @@ see the files COPYING3 and COPYING.RUNTIME respect
   while (0)
 #endif
 
+#ifndef ASM_DECLARE_COLD_FUNCTION_NAME
+#define ASM_DECLARE_COLD_FUNCTION_NAME(FILE, NAME, DECL)   \
+  do   \
+{  \
+  ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "function");  \
+  ASM_DECLARE_RESULT (FILE, DECL_RESULT (DECL));   \
+  ASM_OUTPUT_FUNCTION_LABEL (FILE, NAME, DECL);\
+}  \
+  while (0)
+#endif
+
 /* Write the extra assembler code needed to declare an object properly.  */
 
 #ifdef HAVE_GAS_GNU_UNIQUE_OBJECT
@@ -358,6 +369,16 @@ see the files COPYING3 and COPYING.RUNTIME respect
   while (0)
 #endif
 
+#ifndef ASM_DECLARE_COLD_FUNCTION_SIZE
+#define ASM_DECLARE_COLD_FUNCTION_SIZE(FILE, FNAME, DECL)  \
+  do   \
+{  \
+  if (!flag_inhibit_size_directive)\
+   ASM_OUTPUT_MEASURED_SIZE (FILE, FNAME); \
+}  \
+  while (0)
+#endif
+
 /* A table of bytes codes used by the ASM_OUTPUT_ASCII and
ASM_OUTPUT_LIMITED_STRING macros.  Each byte in the table
corresponds to a particular byte value [0..255].  For any
Index: final.c
===
--- final.c (revision 222585)
+++ final.c (working copy)
@@ -2235,10 +2235,10 @@ final_scan_insn (rtx_insn *insn, FILE *file, int o
{
  cold_function_name
= clone_function_name (current_function_decl, "cold");
-#ifdef ASM_DECLARE_FUNCTION_NAME
- ASM_DECLARE_FUNCTION_NAME (asm_out_file,
-IDENTIFIER_POINTER 
(cold_function_name),
-current_function_decl);
+#ifdef ASM_DECLARE_COLD_FUNCTION_NAME
+ ASM_DECLARE_COLD_FUNCTION_NAME
+   (asm_out_file, IDENTIFIER_POINTER (cold_function_name),
+current_function_decl);
 #else
  ASM_OUTPUT_LABEL (asm_out_file,
IDENTIFIER_POINTER (cold_function_name));
Index: varasm.c
===
--- varasm.c(revision 222585)
+++ varasm.c(working copy)
@@ -1864,11 +1864,10 @@ assemble_end_function (tree decl, const char *fnna
 
   save_text_section = in_section;
   switch_to_section (unlikely_text_section ());
-#ifdef ASM_DECLARE_FUNCTION_SIZE
+#ifdef ASM_DECLARE_COLD_FUNCTION_SIZE
   if (cold_function

Re: [PATCH] [libstdc++/65839] whatis support for xmethods

2015-04-29 Thread Jonathan Wakely

On 29/04/15 10:57 -0700, Doug Evans wrote:

On Tue, Apr 28, 2015 at 5:16 AM, Jonathan Wakely  wrote:

On 27/04/15 15:44 -0700, Doug Evans wrote:


PR libstdc++/65839
* python/libstdcxx/v6/xmethods.py (get_bool_type): New function.
Replace all lookups of "bool" with this.
(get_std_size_type): New function.  Replace all lookups of
std::size_t
with this.
(ArrayWorkerBase): Rename arg valtype to elem_type for
consistency,



I'd say ArrayWorkerBase's _valtype is correct and deque and vector are
wrong to use _elemtype.

C++ containers use value_type for the type of the container objects.
Smart pointers use element_type for the type of the owned object. So
using _valtype for containers and _elemtype for unique_ptr would be
consistent with the C++ library types.


Hi.
Here's v2.
It's assumes the naming cleanup patch has been applied.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00183.html

Regression tested on amd64-linux.


Looks good, OK for trunk, thanks.

If you want to fix this on the branch too then the renaming patch and
this one are both OK for the gcc-5-branch as well.



Re: [PATCH] Use consistent naming in libstdcxx/v6/xmethods.py

2015-04-29 Thread Jonathan Wakely

On 29/04/15 09:49 -0700, Doug Evans wrote:

Hi.

This patch splits out from the patch for 65839 the consistent naming
suggested here.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00155.html

Regression tested on amd64-linux.

Ok to commit?


Thanks for doing this, OK to commit.



Re: [PATCH] [libstdc++/65839] whatis support for xmethods

2015-04-29 Thread Doug Evans
On Tue, Apr 28, 2015 at 5:16 AM, Jonathan Wakely  wrote:
> On 27/04/15 15:44 -0700, Doug Evans wrote:
>>
>> PR libstdc++/65839
>> * python/libstdcxx/v6/xmethods.py (get_bool_type): New function.
>> Replace all lookups of "bool" with this.
>> (get_std_size_type): New function.  Replace all lookups of
>> std::size_t
>> with this.
>> (ArrayWorkerBase): Rename arg valtype to elem_type for
>> consistency,
>
>
> I'd say ArrayWorkerBase's _valtype is correct and deque and vector are
> wrong to use _elemtype.
>
> C++ containers use value_type for the type of the container objects.
> Smart pointers use element_type for the type of the owned object. So
> using _valtype for containers and _elemtype for unique_ptr would be
> consistent with the C++ library types.

Hi.
Here's v2.
It's assumes the naming cleanup patch has been applied.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00183.html

Regression tested on amd64-linux.
2015-04-29  Doug Evans  

PR libstdc++/65839
* python/libstdcxx/v6/xmethods.py (get_bool_type): New function.
Replace all lookups of "bool" with this.
(get_std_size_type): New function.  Replace all lookups of std::size_t
with this.
(*Worker): New method get_result_type.
(DequeWorkerBase.__init__): New arg val_type.  All callers updated.
(ListWorkerBase.__init__): New arg val_type.  All callers updated.
(UniquePtrGetWorker.__init__): New arg elem_type.  All callers updated.
Delete setting of name, enabled.
(UniquePtrDerefWorker.__init__): New arg elem_type.  All callers
updated.  Delete setting of name.
(UniquePtrMethodsMatcher): Rewrite for consistency with all other
libstdc++ xmethod matchers.
* testsuite/libstdc++-xmethods/array.cc: Add whatis tests.
* testsuite/libstdc++-xmethods/associative-containers.cc: Ditto.
* testsuite/libstdc++-xmethods/deque.cc: Ditto.
* testsuite/libstdc++-xmethods/forwardlist.cc: Ditto.
* testsuite/libstdc++-xmethods/list.cc: Ditto.
* testsuite/libstdc++-xmethods/unique_ptr.cc: Ditto.
* testsuite/libstdc++-xmethods/vector.cc: Ditto.

Index: python/libstdcxx/v6/xmethods.py
===
--- python/libstdcxx/v6/xmethods.py
+++ python/libstdcxx/v6/xmethods.py
@@ -21,6 +21,12 @@ import re
 
 matcher_name_prefix = 'libstdc++::'
 
+def get_bool_type():
+return gdb.lookup_type('bool')
+
+def get_std_size_type():
+return gdb.lookup_type('std::size_t')
+
 class LibStdCxxXMethod(gdb.xmethod.XMethod):
 def __init__(self, name, worker_class):
 gdb.xmethod.XMethod.__init__(self, name)
@@ -44,6 +50,9 @@ class ArraySizeWorker(ArrayWorkerBase):
 def get_arg_types(self):
 return None
 
+def get_result_type(self, obj):
+return get_std_size_type()
+
 def __call__(self, obj):
 return self._size
 
@@ -54,6 +63,9 @@ class ArrayEmptyWorker(ArrayWorkerBase):
 def get_arg_types(self):
 return None
 
+def get_result_type(self, obj):
+return get_bool_type()
+
 def __call__(self, obj):
 return (int(self._size) == 0)
 
@@ -64,6 +76,9 @@ class ArrayFrontWorker(ArrayWorkerBase):
 def get_arg_types(self):
 return None
 
+def get_result_type(self, obj):
+return self._val_type
+
 def __call__(self, obj):
 if int(self._size) > 0:
 return obj['_M_elems'][0]
@@ -77,6 +92,9 @@ class ArrayBackWorker(ArrayWorkerBase):
 def get_arg_types(self):
 return None
 
+def get_result_type(self, obj):
+return self._val_type
+
 def __call__(self, obj):
 if int(self._size) > 0:
 return obj['_M_elems'][self._size - 1]
@@ -88,7 +106,10 @@ class ArrayAtWorker(ArrayWorkerBase):
 ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
-return gdb.lookup_type('std::size_t')
+return get_std_size_type()
+
+def get_result_type(self, obj, index):
+return self._val_type
 
 def __call__(self, obj, index):
 if int(index) >= int(self._size):
@@ -101,7 +122,10 @@ class ArraySubscriptWorker(ArrayWorkerBa
 ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
-return gdb.lookup_type('std::size_t')
+return get_std_size_type()
+
+def get_result_type(self, obj, index):
+return self._val_type
 
 def __call__(self, obj, index):
 if int(self._size) > 0:
@@ -140,6 +164,7 @@ class ArrayMethodsMatcher(gdb.xmethod.XM
 
 class DequeWorkerBase(gdb.xmethod.XMethodWorker):
 def __init__(self, val_type):
+self._val_type = val_type
 self._bufsize = (512 / val_type.sizeof) or 1
 
 def size(self, obj):
@@ -158,6 +183,9 @@ class DequeEmptyWorker(DequeWorkerBase):
 def get_arg_types(self):
 return None
 
+def get_result_type(sel

Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

2015-04-29 Thread Uros Bizjak
On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice  wrote:
> The attached patch can revert the previous patch, if that is the way
> we should proceed on this.  If you want me to apply the reversion,
> please let me know.
>
> I would be happy to fix to the problem, rather than just reverting the
> patch, but I do not have expertise in assembly language on other
> platforms, so I would need some help, if anyone would be interested in
> helping me?

How about adding ASM_DECLARE_COLD_FUNCTION_NAME and
ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used
instead, and targets are free to define them in any way.

Uros.


Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

2015-04-29 Thread Caroline Tice
The attached patch can revert the previous patch, if that is the way
we should proceed on this.  If you want me to apply the reversion,
please let me know.

I would be happy to fix to the problem, rather than just reverting the
patch, but I do not have expertise in assembly language on other
platforms, so I would need some help, if anyone would be interested in
helping me?

-- Caroline Tice
cmt...@google.com

ChangeLog (gcc):

2015-04-29  Caroline Tice  

Revert patch from 2015-04-27
* final.c (final_scan_insn): Remove code to output
cold_function_name as a function type in assembly.
* varasm.c (cold_function_name): Remove global declaration.
(assemble_start_function): Remove code to re-set
cold_function_name.
(assemble_end_function):  Do not output side of cold
partition.

ChangLog (gcc/testsuite):

2015-04-29  Caroline Tice  

Revert patch from 2015-04-27
* gcc.dg/tree-prof/cold_partition_label.c: Do not check
for cold partition size.




On Wed, Apr 29, 2015 at 9:33 AM, Uros Bizjak  wrote:
> Hello!
>
>> 2015-03-27  Caroline Tice  
>>
>> * final.c (final_scan_insn): Change 'cold_function_name' to
>> 'cold_partition_name' and make it a global variable; also output
>> assembly to give it a 'FUNC' type, if appropriate.
>> * varasm.c (cold_partition_name): Declare and initialize global
>> variable.
>> (assemble_start_function): Re-set value for cold_partition_name.
>> (assemble_end_function): Output assembly to calculate size of cold
>> partition, and associate size with name, if appropriate.
>> * varash.h (cold_partition_name): Add extern declaration for global
>> variable.
>> * testsuite/gcc.dg/tree-prof/cold_partition_label.c: Add dg-final-use
>> to scan assembly for cold partition name and size.
>
> This patch caused PR 65929 [1].
>
> Targets are (ab)using ASM_DECLARE_FUNCTION_NAME and
> ASM_DECLARE_FUNCTION_SIZE for more things that their name suggests. As
> shown in the PR, some directives that are generated through these
> macros apply only to real functions, not to parts of function in the
> middle of the function.
>
> In the particular case in the PR, assembler doesn't tolerate nested
> function declaration.
>
> I suggest to revert the patch for now, until side effects of the patch
> are resolved.
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65929
>
> Uros.
Index: gcc/final.c
===
--- gcc/final.c	(revision 222584)
+++ gcc/final.c	(working copy)
@@ -2233,16 +2233,10 @@
 	 suffixing "cold" to the original function's name.  */
 	  if (in_cold_section_p)
 	{
-	  cold_function_name
+	  tree cold_function_name
 		= clone_function_name (current_function_decl, "cold");
-#ifdef ASM_DECLARE_FUNCTION_NAME
-	  ASM_DECLARE_FUNCTION_NAME (asm_out_file,
-	 IDENTIFIER_POINTER (cold_function_name),
-	 current_function_decl);
-#else
 	  ASM_OUTPUT_LABEL (asm_out_file,
 IDENTIFIER_POINTER (cold_function_name));
-#endif
 	}
 	  break;
 
Index: gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c
===
--- gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c	(revision 222584)
+++ gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c	(working copy)
@@ -35,6 +35,4 @@
   return 0;
 }
 
-/* { dg-final-use { scan-assembler "foo\[._\]+cold\[\._\]+0" } } */
-/* { dg-final-use { scan-assembler "size\[ \ta-zA-Z0-0\]+foo\[._\]+cold\[\._\]+0" } } */
 /* { dg-final-use { cleanup-saved-temps } } */
Index: gcc/varasm.c
===
--- gcc/varasm.c	(revision 222584)
+++ gcc/varasm.c	(working copy)
@@ -187,13 +187,6 @@
at the cold section.  */
 bool in_cold_section_p;
 
-/* The following global holds the "function name" for the code in the
-   cold section of a function, if hot/cold function splitting is enabled
-   and there was actually code that went into the cold section.  A
-   pseudo function name is needed for the cold section of code for some
-   debugging tools that perform symbolization. */
-tree cold_function_name = NULL_TREE;
-
 /* A linked list of all the unnamed sections.  */
 static GTY(()) section *unnamed_sections;
 
@@ -1726,7 +1719,6 @@
   ASM_GENERATE_INTERNAL_LABEL (tmp_label, "LCOLDE", const_labelno);
   crtl->subsections.cold_section_end_label = ggc_strdup (tmp_label);
   const_labelno++;
-  cold_function_name = NULL_TREE;
 }
   else
 {
@@ -1864,12 +1856,6 @@
 
   save_text_section = in_section;
   switch_to_section (unlikely_text_section ());
-#ifdef ASM_DECLARE_FUNCTION_SIZE
-  if (cold_function_name != NULL_TREE)
-	ASM_DECLARE_FUNCTION_SIZE (asm_out_file,
-   IDENTIFIER_POINTER (cold_function_name),
-   decl);
-#endif
   ASM_OUTPUT_LABEL (asm_out_file,

Re: [PATCH] Tidy up locking for libgomp OpenACC entry points

2015-04-29 Thread Thomas Schwinge
Hi Julian!

On Fri, 24 Apr 2015 18:13:08 +0100, Julian Brown  
wrote:
> On Thu, 23 Apr 2015 18:41:34 +0200
> Thomas Schwinge  wrote:
> > On Wed, 22 Apr 2015 19:42:43 +0100, Julian Brown
> >  wrote:
> > > This patch is an attempt to fix some potential race conditions with
> > > accesses to shared data structures from multiple concurrent threads
> > > in libgomp's OpenACC entry points.

> > > Tests look OK (with offloading to NVidia PTX).
> > 
> > How did you test to get some confidence in the locking being
> > sufficient?
> 
> Merely by running the existing tests and via inspection, sadly. I'm not
> sure how much value we'd get from implementing an exhaustive threading
> testsuite at this stage: I guess testcases will be easier to come by in
> the future if/when people start to use e.g. OpenMP and OpenACC together.

;-) The poor person to be the first to actually exercise all that code...

Thanks for your explanations and the rework.

> Re-tested (libgomp), results look OK.
> 
> OK to apply now?

OK, thanks!


Grüße,
 Thomas


pgp6oCMUj9Siy.pgp
Description: PGP signature


Re: [RFC]: Remove Mem/address type assumption in combiner

2015-04-29 Thread Segher Boessenkool
Hello Venkat,

On Wed, Apr 29, 2015 at 09:25:21AM +, Kumar, Venkataramanan wrote:
> diff --git a/gcc/combine.c b/gcc/combine.c
> index 5c763b4..945abdb 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code)
>   but once inside, go back to our default of SET.  */
> 
>next_code = (code == MEM ? MEM
> -  : ((code == PLUS || code == MINUS)
> - && SCALAR_INT_MODE_P (mode)) ? MEM
>: ((code == COMPARE || COMPARISON_P (x))
>   && XEXP (x, 1) == const0_rtx) ? COMPARE
>: in_code == COMPARE ? SET : in_code);
> 
> 
> On X86_64, it passes bootstrap and regression tests.
> But on Aarch64 the test in PR passed, but I got a few test case failures.

> There are few patterns based on multiplication operations in Aarch64 backend 
> which are used to match with the pattern combiner generated.
> Now those patterns have to be fixed to use SHIFTS.  Also need to see any 
> impact on other targets.

Right.  It would be good if you could find out for what targets it matters.
The thing is, if a target expects only the patterns as combine used to make
them, it will regress (as you've seen on aarch64); but it will regress
_silently_.  Which isn't so nice.

> But  before that  I wanted to check if the assumption in combiner,  can 
> simply be removed ?

Seeing for what targets / patterns it makes a difference would tell us the
answer to that, too :-)

I'll run some tests with and without your patch.


Segher


[PATCH] Use consistent naming in libstdcxx/v6/xmethods.py

2015-04-29 Thread Doug Evans
Hi.

This patch splits out from the patch for 65839 the consistent naming
suggested here.
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00155.html

Regression tested on amd64-linux.

Ok to commit?

2015-04-29  Doug Evans  

Use consistent naming for value type attributes.
* python/libstdcxx/v6/xmethods.py (ArrayWorkerBase): Rename _valtype
to _val_type.
(ArraySizeWorker, ArrayEmptyWorker): Ditto.
(ArrayFrontWorker, ArrayBackWorker): Ditto.
(ArrayAtWorker, ArraySubscriptWorker): Ditto.
(DequeWorkerBase): Rename elemtype to val_type.
(ForwardListWorkerBase): Rename _elem_type to _val_type.
(ForwardListFrontWorker): Ditto.  And rename elem_address to
val_address.
(ForwardListMethodsMatcher): Rename elem_type to val_type.
(VectorWorkerBase): Rename _elemtype to _val_type.

Index: xmethods.py
===
--- xmethods.py (revision 222551)
+++ xmethods.py (working copy)
@@ -29,17 +29,17 @@ class LibStdCxxXMethod(gdb.xmethod.XMethod):
 # Xmethods for std::array
 
 class ArrayWorkerBase(gdb.xmethod.XMethodWorker):
-def __init__(self, valtype, size):
-self._valtype = valtype
+def __init__(self, val_type, size):
+self._val_type = val_type
 self._size = size
 
 def null_value(self):
 nullptr = gdb.parse_and_eval('(void *) 0')
-return nullptr.cast(self._valtype.pointer()).dereference()
+return nullptr.cast(self._val_type.pointer()).dereference()
 
 class ArraySizeWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return None
@@ -48,8 +48,8 @@ class ArraySizeWorker(ArrayWorkerBase):
 return self._size
 
 class ArrayEmptyWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return None
@@ -58,8 +58,8 @@ class ArrayEmptyWorker(ArrayWorkerBase):
 return (int(self._size) == 0)
 
 class ArrayFrontWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return None
@@ -71,8 +71,8 @@ class ArrayFrontWorker(ArrayWorkerBase):
 return self.null_value()
 
 class ArrayBackWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return None
@@ -84,8 +84,8 @@ class ArrayBackWorker(ArrayWorkerBase):
 return self.null_value()
 
 class ArrayAtWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return gdb.lookup_type('std::size_t')
@@ -97,8 +97,8 @@ class ArrayAtWorker(ArrayWorkerBase):
 return obj['_M_elems'][index]
 
 class ArraySubscriptWorker(ArrayWorkerBase):
-def __init__(self, valtype, size):
-ArrayWorkerBase.__init__(self, valtype, size)
+def __init__(self, val_type, size):
+ArrayWorkerBase.__init__(self, val_type, size)
 
 def get_arg_types(self):
 return gdb.lookup_type('std::size_t')
@@ -139,8 +139,8 @@ class ArrayMethodsMatcher(gdb.xmethod.XMethodMatch
 # Xmethods for std::deque
 
 class DequeWorkerBase(gdb.xmethod.XMethodWorker):
-def __init__(self, elemtype):
-self._bufsize = (512 / elemtype.sizeof) or 1
+def __init__(self, val_type):
+self._bufsize = (512 / val_type.sizeof) or 1
 
 def size(self, obj):
 first_node = obj['_M_impl']['_M_start']['_M_node']
@@ -232,8 +232,8 @@ class DequeMethodsMatcher(gdb.xmethod.XMethodMatch
 # Xmethods for std::forward_list
 
 class ForwardListWorkerBase(gdb.xmethod.XMethodMatcher):
-def __init__(self, elem_type, node_type):
-self._elem_type = elem_type
+def __init__(self, val_type, node_type):
+self._val_type = val_type
 self._node_type = node_type
 
 def get_arg_types(self):
@@ -246,8 +246,8 @@ class ForwardListEmptyWorker(ForwardListWorkerBase
 class ForwardListFrontWorker(ForwardListWorkerBase):
 def __call__(self, obj):
 node = obj['_M_impl']['_M_head']['_M_next'].cast(self._node_type)
-elem_address = node['_M_storage']['_M_storage'].address
-return elem_address.cast(self._elem_type.pointer()).derefe

[debug-early] adjust tests for new defined/used warnings

2015-04-29 Thread Aldy Hernandez
This fixes the remaining regressions.  With the new design for 
check_global_declaration*(), we diagnose many more warnings and so far, 
no false positives.


Committed to branch.
commit 7aeb35184b29f3c67470b63fcf107b54f075ffd7
Author: Aldy Hernandez 
Date:   Wed Apr 29 09:43:48 2015 -0700

Adjust tests with defined/used warnings.

diff --git a/gcc/objc/objc-gnu-runtime-abi-01.c 
b/gcc/objc/objc-gnu-runtime-abi-01.c
index b096fb9..cdf77b2 100644
--- a/gcc/objc/objc-gnu-runtime-abi-01.c
+++ b/gcc/objc/objc-gnu-runtime-abi-01.c
@@ -500,6 +500,8 @@ build_selector_table_decl (void)
   temp = build_array_type (objc_selector_template, NULL_TREE);
 
   UOBJC_SELECTOR_TABLE_decl = start_var_decl (temp, "_OBJC_SELECTOR_TABLE");
+  /* Squash `defined but not used' warning check_global_declaration.  */
+  TREE_USED (UOBJC_SELECTOR_TABLE_decl) = 1;
   OBJCMETA (UOBJC_SELECTOR_TABLE_decl, objc_meta, meta_base);
 }
 
diff --git a/gcc/testsuite/g++.dg/torture/pr46383.C 
b/gcc/testsuite/g++.dg/torture/pr46383.C
index 2b61039..e4810c5 100644
--- a/gcc/testsuite/g++.dg/torture/pr46383.C
+++ b/gcc/testsuite/g++.dg/torture/pr46383.C
@@ -69,9 +69,9 @@ template < class Tr, class Derived, class Element, class 
Previous, class Triangu
   Mesher_level(Previous_level& previous)
 : previous_level(previous)
   { }
-  Vertex_handle insert(Point p, Zone& z) ;
-  Zone conflicts_zone(const Point& p, Element e) ;
-  Element get_next_element() ;
+  Vertex_handle insert(Point p, Zone& z) ; // { dg-warning "used but never 
defined" }
+  Zone conflicts_zone(const Point& p, Element e) ; // { dg-warning "used but 
never defined" }
+  Element get_next_element() ; // { dg-warning "used but never defined" }
   template  void before_insertion(Element& e, const Point& 
p, Zone& zone, Mesh_visitor visitor) {
 visitor.before_insertion(e, p, zone);
   }
@@ -171,7 +171,7 @@ template  struct 
Triangulation_mesher_level_traits_3
   tr.is_infinite(f) ;
   new_facet(f);
 }
-template  void 
new_facet (const Facet& f) ;
+template  void 
new_facet (const Facet& f) ; // { dg-warning "used but never defined" }
 void after_insertion_handle_opposite_facet (const Facet& f) {
   after_insertion_handle_incident_facet (f);
 }
diff --git a/gcc/testsuite/gfortran.dg/intent_out_8.f90 
b/gcc/testsuite/gfortran.dg/intent_out_8.f90
index 674d833..6360314 100644
--- a/gcc/testsuite/gfortran.dg/intent_out_8.f90
+++ b/gcc/testsuite/gfortran.dg/intent_out_8.f90
@@ -10,7 +10,7 @@ end type t
 
 contains
 
-  subroutine foo(x)
+  subroutine foo(x) ! { dg-warning "defined but not used" }
 type(t), intent(out) :: x
   end subroutine
 
diff --git a/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90 
b/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90
index 9113a88..749f987 100644
--- a/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90
+++ b/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90
@@ -10,7 +10,7 @@ subroutine test
   integer, target :: t
   p => t
 contains
-  subroutine sub()
+  subroutine sub() ! { dg-warning "defined but not used" }
 if (p /= 0) return
   end subroutine
 end subroutine
@@ -22,7 +22,7 @@ contains
 integer, target :: t2
 p2 => t2 ! { dg-warning "Pointer at .1. in pointer assignment might 
outlive the pointer target" }
   contains
-subroutine sub()
+subroutine sub() ! { dg-warning "defined but not used" }
   if (p2 /= 0) return
 end subroutine
   end subroutine
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 43e1577..3155595 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -505,6 +505,8 @@ wrapup_global_declarations (tree *vec, int len)
 void
 check_global_declaration (tree decl)
 {
+  // ?? Perhaps we should avoid all DECL_ARTIFICIALs here?
+
   /* Warn about any function declared static but not defined.  We don't
  warn about variables, because many programs have static variables
  that exist only to get some text into the object file.  */


Re: C PATCH to reject va_arg (ap, void) (PR c/65901)

2015-04-29 Thread Marek Polacek
On Tue, Apr 28, 2015 at 09:07:09PM -0600, Martin Sebor wrote:
> The error message in the test cases below isn't quite right.
> The type of the aggregates isn't undefined, it's incomplete.
> Looking at the function, I wonder if the first argument
> should be EXPR rather than than NULL_TREE? Alternatively,
> experimenting with other cases where GCC diagnoses invalid
> uses of incomplete type, I see that it issues:
> 
>   "invalid application of %qs to incomplete type %qT"
> 
> which might work even better here since we could name the
> expression (va_arg).

Yeah, I haven't concerned myself with the exact wording of the error
message much, and I agree it could be improved.  But passing down the
EXPR would mean that the compiler outputs "'ap' has an incomplete type"
and that looks wrong as well.  I think I'm going to apply the following
tomorrow if I hear no objections (and it passes testing).  Thanks for noticing.

(And I think c_incomplete_type_error deserves some TLC; I'll post a separate
patch.)

2015-04-29  Marek Polacek  

* c-typeck.c (c_build_va_arg): Clarify the error message.

* gcc.dg/pr65901.c (foo): Adjust dg-error.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index c58e918..028d2f81 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -12645,14 +12645,17 @@ c_build_qualified_type (tree type, int type_quals)
 tree
 c_build_va_arg (location_t loc, tree expr, tree type)
 {
-  if (warn_cxx_compat && TREE_CODE (type) == ENUMERAL_TYPE)
-warning_at (loc, OPT_Wc___compat,
-   "C++ requires promoted type, not enum type, in %");
-  if (type == error_mark_node || !COMPLETE_TYPE_P (type))
+  if (error_operand_p (type))
+return error_mark_node;
+  else if (!COMPLETE_TYPE_P (type))
 {
-  c_incomplete_type_error (NULL_TREE, type);
+  error_at (loc, "second argument to % is of incomplete "
+   "type %qT", type);
   return error_mark_node;
 }
+  else if (warn_cxx_compat && TREE_CODE (type) == ENUMERAL_TYPE)
+warning_at (loc, OPT_Wc___compat,
+   "C++ requires promoted type, not enum type, in %");
   return build_va_arg (loc, expr, type);
 }
 
diff --git gcc/testsuite/gcc.dg/pr65901.c gcc/testsuite/gcc.dg/pr65901.c
index 8708a1e..b40eea3 100644
--- gcc/testsuite/gcc.dg/pr65901.c
+++ gcc/testsuite/gcc.dg/pr65901.c
@@ -9,8 +9,8 @@ union U;
 void
 foo (__builtin_va_list ap)
 {
-  __builtin_va_arg (ap, void);  /* { dg-error "invalid use of void expression" 
} */
-  __builtin_va_arg (ap, struct S);  /* { dg-error "invalid use of undefined 
type" } */
-  __builtin_va_arg (ap, enum E);  /* { dg-error "invalid use of undefined 
type" } */
-  __builtin_va_arg (ap, union U);  /* { dg-error "invalid use of undefined 
type" } */
+  __builtin_va_arg (ap, void);  /* { dg-error "second argument to .va_arg. is 
of incomplete type .void." } */
+  __builtin_va_arg (ap, struct S);  /* { dg-error "second argument to .va_arg. 
is of incomplete type .struct S." } */
+  __builtin_va_arg (ap, enum E);  /* { dg-error "second argument to .va_arg. 
is of incomplete type .enum E." } */
+  __builtin_va_arg (ap, union U);  /* { dg-error "second argument to .va_arg. 
is of incomplete type .union U." } */
 }

Marek


Re: [PATCH] Fix size & type for cold partition names (hot-cold function partitioning)

2015-04-29 Thread Uros Bizjak
Hello!

> 2015-03-27  Caroline Tice  
>
> * final.c (final_scan_insn): Change 'cold_function_name' to
> 'cold_partition_name' and make it a global variable; also output
> assembly to give it a 'FUNC' type, if appropriate.
> * varasm.c (cold_partition_name): Declare and initialize global
> variable.
> (assemble_start_function): Re-set value for cold_partition_name.
> (assemble_end_function): Output assembly to calculate size of cold
> partition, and associate size with name, if appropriate.
> * varash.h (cold_partition_name): Add extern declaration for global
> variable.
> * testsuite/gcc.dg/tree-prof/cold_partition_label.c: Add dg-final-use
> to scan assembly for cold partition name and size.

This patch caused PR 65929 [1].

Targets are (ab)using ASM_DECLARE_FUNCTION_NAME and
ASM_DECLARE_FUNCTION_SIZE for more things that their name suggests. As
shown in the PR, some directives that are generated through these
macros apply only to real functions, not to parts of function in the
middle of the function.

In the particular case in the PR, assembler doesn't tolerate nested
function declaration.

I suggest to revert the patch for now, until side effects of the patch
are resolved.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65929

Uros.


Re: [PATCH 6/n] OpenMP 4.0 offloading infrastructure: option handling

2015-04-29 Thread Thomas Schwinge
Hi!

On Tue, 28 Apr 2015 15:24:08 +0200, Bernd Schmidt  
wrote:
> On 04/27/2015 06:08 PM, Thomas Schwinge wrote:
> 
> >>> OK to do the following instead?  (Coding style/code copied from
> >>> gcc/config/i386/intelmic-mkoffload.c for consistency.)
> 
> Err, was this a question for me? I'm fine with that too.

Yes -- you're the nvptx maintainer after all.  ;-)

Committed in r222583:

commit df615909263269988fd9611f8d007902580829d9
Author: tschwinge 
Date:   Wed Apr 29 16:23:26 2015 +

[PR libgomp/65099] nvptx mkoffload: pass "-m32" or "-m64" to the compiler

... depending on "-foffload-abi=[...]".

Coding style/code copied from gcc/config/i386/intelmic-mkoffload.c for
consistency.

gcc/
* config/nvptx/mkoffload.c (target_ilp32): New variable.
(main): Set it depending on "-foffload-abi=[...]".
(compile_native, main): Use it to pass "-m32" or "-m64" to the
compiler.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222583 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog|8 
 gcc/config/nvptx/mkoffload.c |   18 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index aaa06c3..d7455e4 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,11 @@
+2015-04-29  Thomas Schwinge  
+
+   PR libgomp/65099
+   * config/nvptx/mkoffload.c (target_ilp32): New variable.
+   (main): Set it depending on "-foffload-abi=[...]".
+   (compile_native, main): Use it to pass "-m32" or "-m64" to the
+   compiler.
+
 2015-04-29  Alan Lawrence  
 
PR target/65770
diff --git gcc/config/nvptx/mkoffload.c gcc/config/nvptx/mkoffload.c
index dbc68bc..8687154 100644
--- gcc/config/nvptx/mkoffload.c
+++ gcc/config/nvptx/mkoffload.c
@@ -126,6 +126,9 @@ static id_map *var_ids, **vars_tail = &var_ids;
 static const char *ptx_name;
 static const char *ptx_cfile_name;
 
+/* Shows if we should compile binaries for i386 instead of x86-64.  */
+bool target_ilp32 = false;
+
 /* Delete tempfiles.  */
 
 /* Unlink a temporary file unless requested otherwise.  */
@@ -885,6 +888,7 @@ compile_native (const char *infile, const char *outfile, 
const char *compiler)
   struct obstack argv_obstack;
   obstack_init (&argv_obstack);
   obstack_ptr_grow (&argv_obstack, compiler);
+  obstack_ptr_grow (&argv_obstack, target_ilp32 ? "-m32" : "-m64");
   obstack_ptr_grow (&argv_obstack, infile);
   obstack_ptr_grow (&argv_obstack, "-c");
   obstack_ptr_grow (&argv_obstack, "-o");
@@ -962,11 +966,23 @@ main (int argc, char **argv)
  passed with @file.  Expand them into argv before processing.  */
   expandargv (&argc, &argv);
 
+  /* Find out whether we should compile binaries for i386 or x86-64.  */
+  for (int i = argc - 1; i > 0; i--)
+if (strncmp (argv[i], "-foffload-abi=", sizeof ("-foffload-abi=") - 1) == 
0)
+  {
+   if (strstr (argv[i], "ilp32"))
+ target_ilp32 = true;
+   else if (!strstr (argv[i], "lp64"))
+ fatal_error (input_location,
+  "unrecognizable argument of option -foffload-abi");
+   break;
+  }
+
   struct obstack argv_obstack;
   obstack_init (&argv_obstack);
   obstack_ptr_grow (&argv_obstack, driver);
   obstack_ptr_grow (&argv_obstack, "-xlto");
-  obstack_ptr_grow (&argv_obstack, "-m64");
+  obstack_ptr_grow (&argv_obstack, target_ilp32 ? "-m32" : "-m64");
   obstack_ptr_grow (&argv_obstack, "-S");
 
   for (int ix = 1; ix != argc; ix++)


Grüße,
 Thomas


pgp4nQYIGv1oG.pgp
Description: PGP signature


Re: [PATCH] libstdc++: Fix list.cc xmethods test.

2015-04-29 Thread Jonathan Wakely
On 29 April 2015 at 17:04, Doug Evans wrote:
> Tested the same patch on the gcc 5.0 branch.
> Just double checking ... ok to apply there too?

Yes, OK for the branch too.

> btw, the test is currently marked as unsupported by the test run.
> I don't know what would be involved in marking it as failing instead,
> but I noticed this happening a lot while I was working with this code.
> I can imagine more failures going unnoticed because of this.

That's due to:

(*): Shared library is missing debugging information.^M
skipping: (*): Shared library is missing debugging information.^M
list.gdb:10: Error in sourced command file:^M
Cannot evaluate function -- may be inlined^M
skipping: list.gdb:10: Error in sourced command file:^M
skipping: Cannot evaluate function -- may be inlined^M
UNSUPPORTED: libstdc++-xmethods/list.cc

But I can't say anything more useful than that.


Re: Help needed debugging std::is_convertible problem (PR 65760)

2015-04-29 Thread Jonathan Wakely

On 17/04/15 01:03 +0200, Daniel Krügler wrote:

2015-04-16 14:33 GMT+02:00 Jonathan Wakely :

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65760

I don't understand why commenting out *any one* of the lines marked
(1), (2), (3), (4) causes this to compile:

#include 

struct C {
C() = default;

C(std::function);  // (1)
C(std::function); // (2)
template  C operator () (T&&); // (3)
template  C operator () (T&&, T&&); // (4)
};


My current understanding of the state of affairs is still complete in
some details, but let me still throw in my 2 cents: The compiler sees
an object of C constructed by an rvalue of C. Now we have - in
addition to the copy/move constructors - two corresponding pairs of
function call operator and converting constructor to consider. Let me
simplify the situation a bit more by removing the additional layer of
template deduction of the call operators to:

struct C
{
 C() = default;

 C(std::function);  // (1)
 C(std::function); // (2)
 C operator()(int); // (3)
 C operator()(int, int); // (4)
};

In the presence of all four members the compiler is allowed (I think
by [temp.inst] p7) to instantiate one or both of the different
std::function specializations, because it has to respect possible
conversions. When this happens, the converting template constructor
declaration of std::function also needs to be instantiated. While
doing this, we come to the point where within the SFINAE condition
std::is_convertible needs to be instantiated, effectively
leading to a situation that we have two different contexts, in which
the compiler needs to evaluate the result the self-conversion of C, C
never becoming completed to realize that during that attempt.

If *any* of the four members is missing, we don't have the situation
that two conversion sequences based on function template deduction
need to be partially ordered, we have only the non-template copy/move
constructor against exactly one possible function template. For this
to order, the compiler doesn't require instantiation of the converting
constructor of std::function.


[...]


Nonetheless, my understanding of your fix is that it actually is not
conforming to what the standard currently requires (This seems to
match you own thinking expressed above), because [func.wrap.func.con]
p8 requires:

"shall not participate in overload resolution unless f is Callable
(20.9.12.2) for argument types ArgTypes... and return type R."

and if we unroll this against the definition Callable (ending in
[func.require] p2) we finally end up in a required test whether the
return type of the invokable thingee has a value of
std::is_convertible::value == true (C has the role of the return
type R). This is so, *even*, if LWG issue

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

would be fixed as described, because we have no void return type involved here.

My current position is that we presumably have a Standard Library
issue lurking around, because I see no way how any library can
implement std::function without breaking this seemingly valid example
case. Either the Standard Library needs to express stronger
constraints on the return type R of std::function (so
to make the example invalid), or - what I would currently prefer - the
library would need to reduce the SFINAE constraints of the
std::function template constructor basically ending in not requiring
that R is complete, or in other words: not requiring the final part of
the Callable test involving the implicit conversion of the functor
result to the described result type R of
std::function.

To follow the intention of std::functions design, the Library could
require that when the constructor definition of

template function(F);

becomes instantiated, the current SFINAE requirements are to be
tested, possibly making this definition instantiation ill-formed.

Summarizing this, I consider your suggested resolution as useful for
practical reasons.


While I agree with Daniel that my suggested fix may not be strictly
conforming, I think it is worth doing anyway, so I'm committing it.

Tested powerpc64le-linux, committed to trunk.


commit bc3d6d30fd620ea1d7d286512f983a7a1ddb99c0
Author: Jonathan Wakely 
Date:   Fri Apr 17 13:25:42 2015 +0100

	PR libstdc++/65760
	* include/std/functional (__check_func_return_type): Use is_same to
	avoid using _is_convertible on incomplete types.
	* testsuite/20_util/function/65760.cc: New.

diff --git a/libstdc++-v3/include/std/functional b/libstdc++-v3/include/std/functional
index e9d48e4..946cf63 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -1962,7 +1962,7 @@ _GLIBCXX_MEM_FN_TRAITS(&&, false_type, true_type)
 
   template
 using __check_func_return_type
-  = __or_, is_convertible<_From, _To>>;
+  = __or_, is_same<_From, _To>, is_convertible<_From, _To>>;
 
   /**
*  @brief Primary class template for std::function.
diff --git a/libstdc++-v3/testsuite/20_util/function/657

[PATCH] PR ld/18355: --enable-shared doesn't work

2015-04-29 Thread H.J. Lu
When bfd is configured as a shared library, we need to configure zlib
with --enable-host-shared since zlib is used by bfd.  Any comments,
feedbacks, objections?


H.J.
--
PR ld/18355
* Makefile.def: Add extra_configure_flags to host zlib.
* configure.ac (extra_host_zlib_configure_flags): New.  Set
to --enable-host-shared When bfd is to be built as shared
library.  AC_SUBST.
* Makefile.in: Regenerated.
* configure: Likewise.
---
 Makefile.def |  4 +++-
 Makefile.in  | 20 +---
 configure| 10 ++
 configure.ac |  9 +
 4 files changed, 35 insertions(+), 8 deletions(-)

diff --git a/Makefile.def b/Makefile.def
index 4e76450..4394188 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -104,7 +104,9 @@ host_modules= { module= readline; };
 host_modules= { module= sid; };
 host_modules= { module= sim; };
 host_modules= { module= texinfo; no_install= true; };
-host_modules= { module= zlib; no_install=true; no_check=true; bootstrap=true; 
};
+host_modules= { module= zlib; no_install=true; no_check=true;
+   bootstrap=true;
+   extra_configure_flags='@extra_host_zlib_configure_flags@';};
 host_modules= { module= gdb; };
 host_modules= { module= expect; };
 host_modules= { module= guile; };
diff --git a/Makefile.in b/Makefile.in
index cc05f7b..8ae261f 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -26714,7 +26714,7 @@ configure-zlib:
  $$s/$$module_srcdir/configure \
  --srcdir=$${topdir}/$$module_srcdir \
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
- --target=${target_alias}  \
+ --target=${target_alias} @extra_host_zlib_configure_flags@ \
  || exit 1
 @endif zlib
 
@@ -26749,7 +26749,8 @@ configure-stage1-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   \
- $(STAGE1_CONFIGURE_FLAGS)
+ $(STAGE1_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 .PHONY: configure-stage2-zlib maybe-configure-stage2-zlib
@@ -26782,7 +26783,8 @@ configure-stage2-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   --with-build-libsubdir=$(HOST_SUBDIR)  \
- $(STAGE2_CONFIGURE_FLAGS)
+ $(STAGE2_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 .PHONY: configure-stage3-zlib maybe-configure-stage3-zlib
@@ -26815,7 +26817,8 @@ configure-stage3-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   --with-build-libsubdir=$(HOST_SUBDIR)  \
- $(STAGE3_CONFIGURE_FLAGS)
+ $(STAGE3_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 .PHONY: configure-stage4-zlib maybe-configure-stage4-zlib
@@ -26848,7 +26851,8 @@ configure-stage4-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   --with-build-libsubdir=$(HOST_SUBDIR)  \
- $(STAGE4_CONFIGURE_FLAGS)
+ $(STAGE4_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 .PHONY: configure-stageprofile-zlib maybe-configure-stageprofile-zlib
@@ -26881,7 +26885,8 @@ configure-stageprofile-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   --with-build-libsubdir=$(HOST_SUBDIR)  \
- $(STAGEprofile_CONFIGURE_FLAGS)
+ $(STAGEprofile_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 .PHONY: configure-stagefeedback-zlib maybe-configure-stagefeedback-zlib
@@ -26914,7 +26919,8 @@ configure-stagefeedback-zlib:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   --with-build-libsubdir=$(HOST_SUBDIR)  \
- $(STAGEfeedback_CONFIGURE_FLAGS)
+ $(STAGEfeedback_CONFIGURE_FLAGS) \
+ @extra_host_zlib_configure_flags@
 @endif zlib-bootstrap
 
 
diff --git a/configure b/configure
index 97250fa..426eece 100755
--- a/configure
+++ b/configure
@@ -643,6 +643,7 @@ CXXFLAGS_FOR_TARGET
 CFLAGS_FOR_TARGET
 DEBUG_PREFIX_CFLAGS_FOR_TARGET
 SYSROOT_CFLAGS_FOR_TARGET
+extra_host_zlib_configure_flags
 extra_host_libiberty_configure_flags
 stage1_languages
 extra_linker_plugin_flags
@@ -6585,15 +6586,24 @@ fi
 
 # Sometimes we have special requirements for the host libiberty.
 extra_host_libiberty_configure_flags=
+extra_host_zlib_configure_flags=
 case " $configdirs " in
   *" lto-plugin "* | *" libcc1 "*)
 # When these are to be built as shared libraries, the same applies to
 # libiberty.
 extra_host_libiberty_configure_flags=--enable-shared
 ;;
+  *" bfd "*)
+# When bfd is to be built as a shared library, the 

Re: [PATCH] libstdc++: Fix list.cc xmethods test.

2015-04-29 Thread Doug Evans
On Mon, Apr 27, 2015 at 3:41 PM, Jonathan Wakely  wrote:
> On 27 April 2015 at 23:33, Doug Evans wrote:
>> Hi.
>>
>> While we should eventually get the xmethods to handle cxx11,
>> this patch fixes the current failure.
>> The xmethod matcher doesn't currently handle __cxx11 in the type name.
>>
>> Adding cxx11 support can be a follow up patch.
>
> Agreed. And when that's done we should backport it to the gcc-5-branch too.
>
>> Ok to commit?
>
> OK for trunk, thanks

Tested the same patch on the gcc 5.0 branch.
Just double checking ... ok to apply there too?

btw, the test is currently marked as unsupported by the test run.
I don't know what would be involved in marking it as failing instead,
but I noticed this happening a lot while I was working with this code.
I can imagine more failures going unnoticed because of this.


Re: OMP_CLAUSES with clauses in operand 0

2015-04-29 Thread Thomas Schwinge
Hi!

On Wed, 29 Apr 2015 17:28:54 +0200, Jakub Jelinek  wrote:
> On Wed, Apr 29, 2015 at 05:25:39PM +0200, Thomas Schwinge wrote:
> > Done.  (I also reverted the gcc/cp/pt.c:tsubst_expr change which
> > motivated this patch; will include that with the patch adding support for
> > C++ templates usage with OpenACC directives.)  OK for trunk?
> 
> Ok, thanks.

Committed in r222580:

commit 95cfd3918aef02196f24de30a1e7cbd34e45e827
Author: tschwinge 
Date:   Wed Apr 29 15:44:41 2015 +

Add OMP_STANDALONE_CLAUSES.

gcc/
* tree.h (OMP_STANDALONE_CLAUSES): New macro.
* gimplify.c (gimplify_omp_workshare): Use it.
gcc/c/
* c-parser.c (c_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.
gcc/cp/
* parser.c (cp_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222580 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog|5 +
 gcc/c/ChangeLog  |5 +
 gcc/c/c-parser.c |5 +
 gcc/cp/ChangeLog |5 +
 gcc/cp/parser.c  |5 +
 gcc/gimplify.c   |   13 +
 gcc/tree.h   |6 ++
 7 files changed, 28 insertions(+), 16 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 4fb5490..11cb62a 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-04-29  Thomas Schwinge  
+
+   * tree.h (OMP_STANDALONE_CLAUSES): New macro.
+   * gimplify.c (gimplify_omp_workshare): Use it.
+
 2015-04-29  Richard Sandiford  
 
* Makefile.in (build/genrecog.o): Depend on inchash.h.
diff --git gcc/c/ChangeLog gcc/c/ChangeLog
index 9c769ca..6d8dbb1 100644
--- gcc/c/ChangeLog
+++ gcc/c/ChangeLog
@@ -1,3 +1,8 @@
+2015-04-29  Thomas Schwinge  
+
+   * c-parser.c (c_parser_oacc_enter_exit_data): Use
+   OMP_STANDALONE_CLAUSES.
+
 2015-04-28  Marek Polacek  
 
* c-parser.c (c_parser_binary_expression): Remove duplicate line.
diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index cc8a4e3..bf0e4c57 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -12154,10 +12154,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, bool 
enter)
 
   stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
   TREE_TYPE (stmt) = void_type_node;
-  if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
-  else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
 }
diff --git gcc/cp/ChangeLog gcc/cp/ChangeLog
index 3ee050c..9442faa 100644
--- gcc/cp/ChangeLog
+++ gcc/cp/ChangeLog
@@ -1,3 +1,8 @@
+2015-04-29  Thomas Schwinge  
+
+   * parser.c (cp_parser_oacc_enter_exit_data): Use
+   OMP_STANDALONE_CLAUSES.
+
 2015-04-29  Paolo Carlini  
 
PR c++/64667
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 4ea2ca2..cfb512b 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -31606,10 +31606,7 @@ cp_parser_oacc_enter_exit_data (cp_parser *parser, 
cp_token *pragma_tok,
 
   stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
   TREE_TYPE (stmt) = void_type_node;
-  if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
-  else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, pragma_tok->location);
   add_stmt (stmt);
   return stmt;
diff --git gcc/gimplify.c gcc/gimplify.c
index 1d5341e..9ce3dd9 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -7411,34 +7411,31 @@ gimplify_omp_workshare (tree *expr_p, gimple_seq *pre_p)
 static void
 gimplify_omp_target_update (tree *expr_p, gimple_seq *pre_p)
 {
-  tree expr = *expr_p, clauses;
+  tree expr = *expr_p;
   int kind;
   gomp_target *stmt;
 
   switch (TREE_CODE (expr))
 {
 case OACC_ENTER_DATA:
-  clauses = OACC_ENTER_DATA_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
   break;
 case OACC_EXIT_DATA:
-  clauses = OACC_EXIT_DATA_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
   break;
 case OACC_UPDATE:
-  clauses = OACC_UPDATE_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_UPDATE;
   break;
 case OMP_TARGET_UPDATE:
-  clauses = OMP_TARGET_UPDATE_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_UPDATE;
   break;
 default:
   gcc_unreachable ();
 }
-  gimplify_scan_omp_clauses (&clauses, pre_p, ORT_WORKSHARE);
-  gimplify_adjust_omp_clauses (pre_p, &clauses);
-  stmt = gimple_build_omp_target (NULL, kind, clauses);
+  gimplify_scan_omp_clauses (&OMP_STANDALONE_CLAUSES (expr), pre_p,
+ORT_WORKSHARE);
+  gimplify_adjust_omp_clauses (pre_p, &OMP_STANDALONE_CLAUSES (expr));
+  stmt = gimple_build_omp_target (NULL, kind, OMP_STANDALONE_CLAUSES (expr));
 
   gimplify_seq_add_stmt (pre_p, stmt);
   *expr_p = NULL_TREE;
diff --git gcc/tree.h gcc/tree.h
index 2ec9708..e17bd9b 100644
--- gcc/tree.h
+++ gcc/tree.h
@@ -1197,11 +1197,17 @

Re: OMP_CLAUSES with clauses in operand 0

2015-04-29 Thread Thomas Schwinge
Hi Jakub!

On Wed, 29 Apr 2015 16:36:24 +0200, Jakub Jelinek  wrote:
> On Wed, Apr 29, 2015 at 04:31:32PM +0200, Thomas Schwinge wrote:
> > > So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for
> > > everything.
> > 
> > Like this (for trunk)?
> > 
> > commit 300e28fce192cb56d73cb61f787872643030f0bf
> > Author: Thomas Schwinge 
> > Date:   Wed Apr 29 16:18:49 2015 +0200
> > 
> > Add OMP_STANDALONE_CLAUSES.
> > 
> > gcc/
> > * tree.h (OACC_CACHE_CLAUSES, OACC_DECLARE_CLAUSES)
> > (OACC_ENTER_DATA_CLAUSES, OACC_EXIT_DATA_CLAUSES)
> > (OACC_UPDATE_CLAUSES, OMP_TARGET_UPDATE_CLAUSES): Merge into...
> > (OMP_STANDALONE_CLAUSES): ... this new macro.  Adjust all users.
> 
> I would keep the specific *_CLAUSES macros, just add
> OMP_STANDALONE_CLAUSES and change the uses only if you are dealing with
> multiple different codes.  That will match OMP_CLAUSES vs. OMP_FOR_CLAUSES,
> OMP_PARALLEL_CLAUSES etc.

My (non-explicit) rationale has been:

> > --- gcc/c/c-parser.c
> > +++ gcc/c/c-parser.c
> > @@ -11987,7 +11987,7 @@ c_parser_oacc_cache (location_t loc, c_parser 
> > *parser)
> >  
> >stmt = make_node (OACC_CACHE);

We have just created a OACC_CACHE node here...

> >TREE_TYPE (stmt) = void_type_node;
> > -  OACC_CACHE_CLAUSES (stmt) = clauses;
> > +  OMP_STANDALONE_CLAUSES (stmt) = clauses;

..., so there is no point in checking here that we're indeed dealing
specifically with an OACC_CACHE node.

> So, drop hunks like this.
> 
> > @@ -12155,10 +12155,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, 
> > bool enter)
> >  
> >stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
> >TREE_TYPE (stmt) = void_type_node;
> > -  if (enter)
> > -OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
> > -  else
> > -OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
> > +  OMP_STANDALONE_CLAUSES (stmt) = clauses;
> >SET_EXPR_LOCATION (stmt, loc);
> >add_stmt (stmt);
> >  }
> 
> And just keep ones like this.

Done.  (I also reverted the gcc/cp/pt.c:tsubst_expr change which
motivated this patch; will include that with the patch adding support for
C++ templates usage with OpenACC directives.)  OK for trunk?

commit 82e588b6d62f9e7254e76a3dfcc46efceb2075a5
Author: Thomas Schwinge 
Date:   Wed Apr 29 17:08:17 2015 +0200

Add OMP_STANDALONE_CLAUSES.

gcc/
* tree.h (OMP_STANDALONE_CLAUSES): New macro.
* gimplify.c (gimplify_omp_workshare): Use it.
gcc/c/
* c-parser.c (c_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.
gcc/cp/
* parser.c (cp_parser_oacc_enter_exit_data): Use
OMP_STANDALONE_CLAUSES.
---
 gcc/c/c-parser.c |5 +
 gcc/cp/parser.c  |5 +
 gcc/gimplify.c   |   13 +
 gcc/tree.h   |6 ++
 4 files changed, 13 insertions(+), 16 deletions(-)

diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index f5e2ac2c..015de7f 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -12155,10 +12155,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, bool 
enter)
 
   stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
   TREE_TYPE (stmt) = void_type_node;
-  if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
-  else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
 }
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 4ea2ca2..cfb512b 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -31606,10 +31606,7 @@ cp_parser_oacc_enter_exit_data (cp_parser *parser, 
cp_token *pragma_tok,
 
   stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
   TREE_TYPE (stmt) = void_type_node;
-  if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
-  else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, pragma_tok->location);
   add_stmt (stmt);
   return stmt;
diff --git gcc/gimplify.c gcc/gimplify.c
index c68bd47..bda62ce 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -7427,34 +7427,31 @@ gimplify_omp_workshare (tree *expr_p, gimple_seq *pre_p)
 static void
 gimplify_omp_target_update (tree *expr_p, gimple_seq *pre_p)
 {
-  tree expr = *expr_p, clauses;
+  tree expr = *expr_p;
   int kind;
   gomp_target *stmt;
 
   switch (TREE_CODE (expr))
 {
 case OACC_ENTER_DATA:
-  clauses = OACC_ENTER_DATA_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
   break;
 case OACC_EXIT_DATA:
-  clauses = OACC_EXIT_DATA_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_ENTER_EXIT_DATA;
   break;
 case OACC_UPDATE:
-  clauses = OACC_UPDATE_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_OACC_UPDATE;
   break;
 case OMP_TARGET_UPDATE:
-  clauses = OMP_TARGET_UPDATE_CLAUSES (expr);
   kind = GF_OMP_TARGET_KIND_UPDATE;
   break;
 default:
   

Re: OMP_CLAUSES with clauses in operand 0

2015-04-29 Thread Jakub Jelinek
On Wed, Apr 29, 2015 at 05:25:39PM +0200, Thomas Schwinge wrote:
> Done.  (I also reverted the gcc/cp/pt.c:tsubst_expr change which
> motivated this patch; will include that with the patch adding support for
> C++ templates usage with OpenACC directives.)  OK for trunk?

Ok, thanks.

Jakub


Re: [Patch, fortran, PR44672, v4] [F08] ALLOCATE with SOURCE and no array-spec

2015-04-29 Thread Andre Vehreschild
Hi all,

this is the fourth version of the patch, adapting to the current state of
trunk. This patch is based on my patch for 65584 version 2 and needs that patch
applied beforehand to apply cleanly. The patch for 65548 is available from:

https://gcc.gnu.org/ml/fortran/2015-04/msg00121.html

Scope:

Allow allocate of arrays w/o having to give an array-spec as specified in
F2008:C633. An example is:

integer, dimension(:) :: arr
allocate(arr, source = [1,2,3])

Solution:

While resolving an allocate, the objects to allocate are analyzed whether they
carry an array-spec, if not the array-spec of the source=-expression is
transferred. Unfortunately some source=-expressions are not easy to handle and
have to be assigned to a temporary variable first. Only with the temporary
variable the gfc_trans_allocate() is then able to compute the array descriptor
correctly and allocate with correct array bounds.

Side notes:

This patch creates a regression in alloc_comp_constructor_1.f90 where two
free()'s are gone missing. This will be fixed by the patch for pr58586 and
therefore not repeated here.

Bootstraps and regtests ok on x86_64-linux-gnu/f21.

Ok for trunk?

Regards,
Andre

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


pr44672_4.clog
Description: Binary data
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 832a6ce..9b5f4cf 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2394,6 +2394,9 @@ typedef struct gfc_code
 {
   gfc_typespec ts;
   gfc_alloc *list;
+  /* Take the array specification from expr3 to allocate arrays
+	 without an explicit array specification.  */
+  unsigned arr_spec_from_expr3:1;
 }
 alloc;
 
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 316b413..41b128a 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -6804,7 +6804,7 @@ conformable_arrays (gfc_expr *e1, gfc_expr *e2)
have a trailing array reference that gives the size of the array.  */
 
 static bool
-resolve_allocate_expr (gfc_expr *e, gfc_code *code)
+resolve_allocate_expr (gfc_expr *e, gfc_code *code, bool *array_alloc_wo_spec)
 {
   int i, pointer, allocatable, dimension, is_abstract;
   int codimension;
@@ -7103,13 +7103,24 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code)
   if (!ref2 || ref2->type != REF_ARRAY || ref2->u.ar.type == AR_FULL
   || (dimension && ref2->u.ar.dimen == 0))
 {
-  gfc_error ("Array specification required in ALLOCATE statement "
-		 "at %L", &e->where);
-  goto failure;
+  /* F08:C633.  */
+  if (code->expr3)
+	{
+	  if (!gfc_notify_std (GFC_STD_F2008, "Array specification required "
+			   "in ALLOCATE statement at %L", &e->where))
+	goto failure;
+	  *array_alloc_wo_spec = true;
+	}
+  else
+	{
+	  gfc_error ("Array specification required in ALLOCATE statement "
+		 "at %L", &e->where);
+	  goto failure;
+	}
 }
 
   /* Make sure that the array section reference makes sense in the
-context of an ALLOCATE specification.  */
+ context of an ALLOCATE specification.  */
 
   ar = &ref2->u.ar;
 
@@ -7124,7 +7135,7 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code)
 
   for (i = 0; i < ar->dimen; i++)
 {
-  if (ref2->u.ar.type == AR_ELEMENT)
+  if (ar->type == AR_ELEMENT || ar->type == AR_FULL)
 	goto check_symbols;
 
   switch (ar->dimen_type[i])
@@ -7201,12 +7212,18 @@ failure:
   return false;
 }
 
+
 static void
 resolve_allocate_deallocate (gfc_code *code, const char *fcn)
 {
   gfc_expr *stat, *errmsg, *pe, *qe;
   gfc_alloc *a, *p, *q;
 
+  /* When this flag is set already, then this allocate has already been
+ resolved.  Doing so again, would result in an endless loop.  */
+  if (code->ext.alloc.arr_spec_from_expr3)
+return;
+
   stat = code->expr1;
   errmsg = code->expr2;
 
@@ -7375,8 +7392,96 @@ resolve_allocate_deallocate (gfc_code *code, const char *fcn)
 
   if (strcmp (fcn, "ALLOCATE") == 0)
 {
+  bool arr_alloc_wo_spec = false;
   for (a = code->ext.alloc.list; a; a = a->next)
-	resolve_allocate_expr (a->expr, code);
+	resolve_allocate_expr (a->expr, code, &arr_alloc_wo_spec);
+
+  if (arr_alloc_wo_spec && code->expr3)
+	{
+	  /* Mark the allocate to have to take the array specification
+	 from the expr3.  */
+	  code->ext.alloc.arr_spec_from_expr3 = 1;
+
+	  if (code->expr3->expr_type == EXPR_ARRAY
+	  || code->expr3->expr_type == EXPR_FUNCTION)
+	{
+	  /* The trans stage can not cope with expr3->expr_type
+		 being EXPR_ARRAY or EXPR_FUNCTION, therefore create a
+		 temporary variable and assign expr3 to it, substituting
+		 the variable in expr3.  */
+	  char name[25];
+	  static unsigned int alloc_sym_count = 0;
+	  gfc_symbol *temp_var_sym;
+	  gfc_expr *temp_var;
+	  gfc_code *ass, *old_alloc;
+	  gfc_namespace *ns = code->ext.alloc.list->expr->symtree->n.sym->ns;
+	  gfc_array_spec *as;
+	  int dim;
+	  mpz_t dim_size;
+
+

Re: Fix librayr name of __builtin_allocal_with_align

2015-04-29 Thread Sandra Loosemore

On 04/28/2015 08:22 PM, Jan Hubicka wrote:


I also looked into extend.texi and both __builtin_alloca and 
__builtin_alloca_with_align
is missing (along with many other builtins) which is probably quite bad omission
(__builtin_alloca_with_align is used at some places, i.e. in Firefox)

Sandra, since you d oreat job on updating the docs recently, perhaps this could
get at your radar?


H.  I have quite a lot of other stuff in my queue at the moment 
(including a bunch of nios2 patches, not just documentation work) and I 
might forget about this before I have time to work on it.  I'd encourage 
people who notice omissions in the manual to take a stab at fixing it 
themselves.  Alternatively, you could file PRs for documentation bugs, 
or maybe we should have a documentation improvements section on the wiki 
so that people besides me who have time/interest could find chunks of 
the backlog to chip away at.


-Sandra



[patch] libstdc++/64657 support iterators with overloaded comma operator

2015-04-29 Thread Jonathan Wakely

I think this covers all the places in the library where we do:

 ++i, ++j

Tested powerpc64le-linux, committed to trunk.
commit 572881116b98ee50027dbd5e8880ea6d92e86cca
Author: Jonathan Wakely 
Date:   Sun Jan 18 17:04:10 2015 +

	PR libstdc++/64657
	* include/bits/basic_string (basic_string::_S_copy_chars): Cast
	expression to void.
	* include/bits/locale_facets_nonio.tcc (money_get::_M_extract,
	time_get::_M_extract_num, time_get::_M_extract_name,
	time_get::_M_extract_wday_or_month): Likewise.
	* include/bits/stl_algo.h (__includes, __replace_copy_if,
	__is_sorted_until, __is_permutation, transform): Likewise.
	* include/bits/stl_algobase.h (swap_ranges, __copy_move::__copy_m,
	__equal::equal, __lexicographical_compare_impl, equal): Likewise.
	* include/bits/stl_numeric.h (inner_product): Likewise.
	* include/bits/stl_uninitialized.h (__uninitialized_copy_a): Likewise.
	* testsuite/util/testsuite_iterators.h (output_iterator_wrapper,
	input_iterator_wrapper): Declare unusable comma operator.
	* testsuite/21_strings/basic_string/cons/char/64657.cc: New.
	* testsuite/21_strings/basic_string/modifiers/assign/char/64657.cc:
	New.

diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
index 3b2603f..3e3eef4 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -324,7 +324,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 _S_copy_chars(_CharT* __p, _Iterator __k1, _Iterator __k2)
 	_GLIBCXX_NOEXCEPT
 {
-	  for (; __k1 != __k2; ++__k1, ++__p)
+	  for (; __k1 != __k2; ++__k1, (void)++__p)
 	traits_type::assign(*__p, *__k1); // These types are off.
 	}
 
@@ -2779,7 +2779,7 @@ _GLIBCXX_END_NAMESPACE_CXX11
 _S_copy_chars(_CharT* __p, _Iterator __k1, _Iterator __k2)
 	_GLIBCXX_NOEXCEPT
 {
-	  for (; __k1 != __k2; ++__k1, ++__p)
+	  for (; __k1 != __k2; ++__k1, (void)++__p)
 	traits_type::assign(*__p, *__k1); // These types are off.
 	}
 
diff --git a/libstdc++-v3/include/bits/locale_facets_nonio.tcc b/libstdc++-v3/include/bits/locale_facets_nonio.tcc
index 188d07b..2e73b5d 100644
--- a/libstdc++-v3/include/bits/locale_facets_nonio.tcc
+++ b/libstdc++-v3/include/bits/locale_facets_nonio.tcc
@@ -202,7 +202,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL_OR_CXX11
 		size_type __j = 0;
 		for (; __beg != __end && __j < __len
 			   && *__beg == __lc->_M_curr_symbol[__j];
-			 ++__beg, ++__j);
+			 ++__beg, (void)++__j);
 		if (__j != __len
 			&& (__j || __io.flags() & ios_base::showbase))
 		  __testvalid = false;
@@ -298,7 +298,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL_OR_CXX11
 	 : __lc->_M_positive_sign;
 	size_type __i = 1;
 	for (; __beg != __end && __i < __sign_size
-		   && *__beg == __sign[__i]; ++__beg, ++__i);
+		   && *__beg == __sign[__i]; ++__beg, (void)++__i);
 	
 	if (__i != __sign_size)
 	  __testvalid = false;
@@ -858,7 +858,7 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
   ++__min;
   size_t __i = 0;
   int __value = 0;
-  for (; __beg != __end && __i < __len; ++__beg, ++__i)
+  for (; __beg != __end && __i < __len; ++__beg, (void)++__i)
 	{
 	  const char __c = __ctype.narrow(*__beg, '*');
 	  if (__c >= '0' && __c <= '9')
@@ -923,7 +923,8 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
 	  for (size_t __i2 = 1; __i2 < __nmatches; ++__i2)
 	__minlen = std::min(__minlen,
 			  __traits_type::length(__names[__matches[__i2]]));
-	  ++__beg, ++__pos;
+	  ++__beg;
+	  ++__pos;
 	  if (__pos < __minlen && __beg != __end)
 	for (size_t __i3 = 0; __i3 < __nmatches;)
 	  {
@@ -940,11 +941,12 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
   if (__nmatches == 1)
 	{
 	  // Make sure found name is completely extracted.
-	  ++__beg, ++__pos;
+	  ++__beg;
+	  ++__pos;
 	  __name = __names[__matches[0]];
 	  const size_t __len = __traits_type::length(__name);
 	  while (__pos < __len && __beg != __end && __name[__pos] == *__beg)
-	++__beg, ++__pos;
+	++__beg, (void)++__pos;
 
 	  if (__len == __pos)
 	__member = __matches[0];
@@ -987,7 +989,8 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
 
   if (__nmatches)
 	{
-	  ++__beg, ++__pos;
+	  ++__beg;
+	  ++__pos;
 
 	  __matches_lengths
 	= static_cast(__builtin_alloca(sizeof(size_t)
@@ -997,7 +1000,7 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
 	  = __traits_type::length(__names[__matches[__i]]);
 	}
 
-  for (; __beg != __end; ++__beg, ++__pos)
+  for (; __beg != __end; ++__beg, (void)++__pos)
 	{
 	  size_t __nskipped = 0;
 	  const char_type __c = *__beg;
diff --git a/libstdc++-v3/include/bits/stl_algo.h b/libstdc++-v3/include/bits/stl_algo.h
index 56cc743..93e834a 100644
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -2805,7 +2805,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	else if (__comp(__first1, __first2))
 	  ++__first1;
 	else
-	  +

Re: [PATCH, AArch64] [4.8] [4.9] Backport PR64304 fix (miscompilation with -mgeneral-regs-only )

2015-04-29 Thread Marcus Shawcroft
Picking up this old back port request...


On 5 March 2015 at 06:36, Chen Shanyao  wrote:

> +2015-03-05  Shanyao Chen

There should be two spaces after the date and two before the < marker
in a ChangeLog name line.  This comment applies to each of the
ChangeLogs presented.

> +/* { dg-final { cleanup-saved-temps } } */
> +

An additional line appears to have been inserted at the end of this
test case. I would have expected the test case to be identical to the
one committed on trunk.

By convention we only post one patch per email to gcc-patches.  Please
fix the comments above and re-post in separate emails for each patch.

Thanks /Marcus


[ubsan] Add -fsanitize=bounds-strict

2015-04-29 Thread Marek Polacek
This patch adds the -fsanitize=bounds-strict option Martin U. wanted; it is
actually based on his earlier patch, I did only some small adjustments.

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

2015-04-29  Marek Polacek  
Martin Uecker  

* c-ubsan.c (ubsan_instrument_bounds): Don't skip instrumenting
flexible member array-like members if SANITIZE_BOUNDS_STRICT.

* doc/invoke.texi: Document -fsanitize=bounds-strict.
* flag-types.h (enum sanitize_code): Add SANITIZE_BOUNDS_STRICT, or it
into SANITIZE_NONDEFAULT.
* opts.c (common_handle_option): Handle -fsanitize=bounds-strict.

* c-c++-common/ubsan/bounds-10.c: New test.

diff --git gcc/c-family/c-ubsan.c gcc/c-family/c-ubsan.c
index a14426f..dbbdc5b 100644
--- gcc/c-family/c-ubsan.c
+++ gcc/c-family/c-ubsan.c
@@ -301,9 +301,11 @@ ubsan_instrument_bounds (location_t loc, tree array, tree 
*index,
 bound = fold_build2 (PLUS_EXPR, TREE_TYPE (bound), bound,
 build_int_cst (TREE_TYPE (bound), 1));
 
-  /* Detect flexible array members and suchlike.  */
+  /* Detect flexible array members and suchlike, unless
+ -fsanitize=bounds-strict.  */
   tree base = get_base_address (array);
-  if (TREE_CODE (array) == COMPONENT_REF
+  if ((flag_sanitize & SANITIZE_BOUNDS_STRICT) == 0
+  && TREE_CODE (array) == COMPONENT_REF
   && base && (TREE_CODE (base) == INDIRECT_REF
  || TREE_CODE (base) == MEM_REF))
 {
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 7d2f6e5..d050ba6 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -5728,6 +5728,13 @@ This option enables instrumentation of array bounds.  
Various out of bounds
 accesses are detected.  Flexible array members, flexible array member-like
 arrays, and initializers of variables with static storage are not instrumented.
 
+@item -fsanitize=bounds-strict
+@opindex fsanitize=bounds-strict
+This option enables strict instrumentation of array bounds.  Most out of bounds
+accesses are detected, including flexible array members and flexible array
+member-like arrays.  Initializers of variables with static storage are not
+instrumented.
+
 @item -fsanitize=alignment
 @opindex fsanitize=alignment
 
diff --git gcc/flag-types.h gcc/flag-types.h
index bfdce44..2f820a5 100644
--- gcc/flag-types.h
+++ gcc/flag-types.h
@@ -238,6 +238,7 @@ enum sanitize_code {
   SANITIZE_RETURNS_NONNULL_ATTRIBUTE = 1UL << 19,
   SANITIZE_OBJECT_SIZE = 1UL << 20,
   SANITIZE_VPTR = 1UL << 21,
+  SANITIZE_BOUNDS_STRICT = 1UL << 22,
   SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | SANITIZE_UNREACHABLE
   | SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
   | SANITIZE_SI_OVERFLOW | SANITIZE_BOOL | SANITIZE_ENUM
@@ -246,6 +247,7 @@ enum sanitize_code {
   | SANITIZE_RETURNS_NONNULL_ATTRIBUTE
   | SANITIZE_OBJECT_SIZE | SANITIZE_VPTR,
   SANITIZE_NONDEFAULT = SANITIZE_FLOAT_DIVIDE | SANITIZE_FLOAT_CAST
+   | SANITIZE_BOUNDS_STRICT
 };
 
 /* flag_vtable_verify initialization levels. */
diff --git gcc/opts.c gcc/opts.c
index 39c190d..8c6716b 100644
--- gcc/opts.c
+++ gcc/opts.c
@@ -1584,6 +1584,8 @@ common_handle_option (struct gcc_options *opts,
  { "float-cast-overflow", SANITIZE_FLOAT_CAST,
sizeof "float-cast-overflow" - 1 },
  { "bounds", SANITIZE_BOUNDS, sizeof "bounds" - 1 },
+ { "bounds-strict", SANITIZE_BOUNDS | SANITIZE_BOUNDS_STRICT,
+   sizeof "bounds-strict" - 1 },
  { "alignment", SANITIZE_ALIGNMENT, sizeof "alignment" - 1 },
  { "nonnull-attribute", SANITIZE_NONNULL_ATTRIBUTE,
sizeof "nonnull-attribute" - 1 },
diff --git gcc/testsuite/c-c++-common/ubsan/bounds-10.c 
gcc/testsuite/c-c++-common/ubsan/bounds-10.c
index e69de29..a6187b5 100644
--- gcc/testsuite/c-c++-common/ubsan/bounds-10.c
+++ gcc/testsuite/c-c++-common/ubsan/bounds-10.c
@@ -0,0 +1,16 @@
+/* { dg-do run } */
+/* { dg-options "-fsanitize=bounds-strict" } */
+
+struct V { int l; int a[1]; };
+
+int
+main (void)
+{
+  /* For strict, do instrument last array in a struct.  */
+  struct V *v = (struct V *) __builtin_malloc (sizeof (struct V) + 10);
+  v->a[1] = 1;
+
+  return 0;
+}
+
+/* { dg-output "index 1 out of bounds for type 'int \\\[1\\\]'" } */

Marek


Re: [gomp4.1] Initial support for some OpenMP 4.1 construct parsing

2015-04-29 Thread Thomas Schwinge
Hi Jakub!

On Wed, 29 Apr 2015 14:06:44 +0200, Jakub Jelinek  wrote:
> On Wed, Apr 29, 2015 at 01:52:24PM +0200, Thomas Schwinge wrote:
> > > --- gcc/tree-pretty-print.c.jj2015-04-29 10:58:01.663745452 +0200
> > > +++ gcc/tree-pretty-print.c   2015-04-29 11:03:04.648990986 +0200
> > > @@ -550,22 +560,22 @@ dump_omp_clause (pretty_printer *pp, tre
> > > pp_string (pp, "tofrom");
> > > break;
> > >   case GOMP_MAP_FORCE_ALLOC:
> > > -   pp_string (pp, "force_alloc");
> > > +   pp_string (pp, "always,alloc");
> > > break;
> > >   case GOMP_MAP_FORCE_TO:
> > > -   pp_string (pp, "force_to");
> > > +   pp_string (pp, "always,to");
> > > break;
> > >   case GOMP_MAP_FORCE_FROM:
> > > -   pp_string (pp, "force_from");
> > > +   pp_string (pp, "always,from");
> > > break;
> > >   case GOMP_MAP_FORCE_TOFROM:
> > > -   pp_string (pp, "force_tofrom");
> > > +   pp_string (pp, "always,tofrom");
> > > break;
> > >   case GOMP_MAP_FORCE_PRESENT:
> > > pp_string (pp, "force_present");
> > > break;
> > >   case GOMP_MAP_FORCE_DEALLOC:
> > > -   pp_string (pp, "force_dealloc");
> > > +   pp_string (pp, "always,delete");
> > > break;
> > >   case GOMP_MAP_FORCE_DEVICEPTR:
> > > pp_string (pp, "force_deviceptr");
> > 
> > Makes some sense to me to use the same "always,*" syntax also for the
> > other "force_*" ones, given that these are artificial ("non-OpenACC")
> > descriptions anyway.
> 
> Ok.  Are the GOMP_MAP_FORCE_* artificial too?  If yes, I can change that
> to GOMP_MAP_ALWAYS_*.

Yes, fine with me.  (Though, what about that »names are sticky« thing,
?)


Grüße,
 Thomas


pgpjurL6NHBRx.pgp
Description: PGP signature


RE: Refactor gcc/tree-vectorize.c:vectorize_loops

2015-04-29 Thread Aditya K

Thanks for the feedback. I have added comment and properly indented the code.

-Aditya


> Date: Wed, 29 Apr 2015 09:31:46 +0200
> From: ja...@redhat.com
> To: l...@redhat.com
> CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org
> Subject: Re: Refactor gcc/tree-vectorize.c:vectorize_loops
>
> On Tue, Apr 28, 2015 at 09:53:24PM -0600, Jeff Law wrote:
>> On 04/28/2015 08:20 PM, Aditya K wrote:
>>>Hi,
>>>This is a small patch where I moved a portion of code from the function 
>>>vectorize_loops outside to improve readability.
>>>Please see the patch attached and give comments for improvements.
>> You need to add a comment for the new function. These function comments
>> should describe what the function does, in terms of its arguments and return
>> value (if any).
>>
>> With a function comment, this refactoring would be fine.
>
> --- a/gcc/tree-vectorizer.c
> +++ b/gcc/tree-vectorizer.c
> @@ -399,6 +399,39 @@ fold_loop_vectorized_call (gimple g, tree value)
> }
> }
>
> +static void
> +set_uid_loop_bbs(loop_vec_info loop_vinfo, gimple loop_vectorized_call)
>
> The formatting is incorrect too, missing space before ( here.
>
> +{
> + tree arg = gimple_call_arg (loop_vectorized_call, 1);
>
> Lines should be indented by 2 spaces rather than after {
>
> + basic_block *bbs;
> + unsigned int i;
> + struct loop *scalar_loop = get_loop (cfun, tree_to_shwi (arg));
> +
> + LOOP_VINFO_SCALAR_LOOP (loop_vinfo) = scalar_loop;
> + gcc_checking_assert (vect_loop_vectorized_call
> + (LOOP_VINFO_SCALAR_LOOP (loop_vinfo))
> + == loop_vectorized_call);
> + bbs = get_loop_body (scalar_loop);
> + for (i = 0; i < scalar_loop->num_nodes; i++)
> + {
> + basic_block bb = bbs[i];
> + gimple_stmt_iterator gsi;
> + for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi);
> + gsi_next (&gsi))
>
> With the refactoring, this for should fit on one line.
>
> + {
> + gimple phi = gsi_stmt (gsi);
> + gimple_set_uid (phi, 0);
> + }
> + for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi);
> + gsi_next (&gsi))
>
> Likewise.
>
> if (loop_vectorized_call)
> - {
> + set_uid_loop_bbs(loop_vinfo, loop_vectorized_call);
>
> Again, missing space before (. And you are using only spaces
> when a tab plus two spaces should be used.
>
> Jakub
  

refactor-vectorize-loops.patch
Description: Binary data


Re: OMP_CLAUSES with clauses in operand 0

2015-04-29 Thread Jakub Jelinek
On Wed, Apr 29, 2015 at 04:31:32PM +0200, Thomas Schwinge wrote:
> > So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for
> > everything.
> 
> Like this (for trunk)?
> 
> commit 300e28fce192cb56d73cb61f787872643030f0bf
> Author: Thomas Schwinge 
> Date:   Wed Apr 29 16:18:49 2015 +0200
> 
> Add OMP_STANDALONE_CLAUSES.
> 
>   gcc/
>   * tree.h (OACC_CACHE_CLAUSES, OACC_DECLARE_CLAUSES)
>   (OACC_ENTER_DATA_CLAUSES, OACC_EXIT_DATA_CLAUSES)
>   (OACC_UPDATE_CLAUSES, OMP_TARGET_UPDATE_CLAUSES): Merge into...
>   (OMP_STANDALONE_CLAUSES): ... this new macro.  Adjust all users.

I would keep the specific *_CLAUSES macros, just add
OMP_STANDALONE_CLAUSES and change the uses only if you are dealing with
multiple different codes.  That will match OMP_CLAUSES vs. OMP_FOR_CLAUSES,
OMP_PARALLEL_CLAUSES etc.

> --- gcc/c/c-parser.c
> +++ gcc/c/c-parser.c
> @@ -11987,7 +11987,7 @@ c_parser_oacc_cache (location_t loc, c_parser *parser)
>  
>stmt = make_node (OACC_CACHE);
>TREE_TYPE (stmt) = void_type_node;
> -  OACC_CACHE_CLAUSES (stmt) = clauses;
> +  OMP_STANDALONE_CLAUSES (stmt) = clauses;
>SET_EXPR_LOCATION (stmt, loc);
>add_stmt (stmt);
>  

So, drop hunks like this.

> @@ -12155,10 +12155,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, 
> bool enter)
>  
>stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
>TREE_TYPE (stmt) = void_type_node;
> -  if (enter)
> -OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
> -  else
> -OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
> +  OMP_STANDALONE_CLAUSES (stmt) = clauses;
>SET_EXPR_LOCATION (stmt, loc);
>add_stmt (stmt);
>  }

And just keep ones like this.

Jakub


Re: OMP_CLAUSES with clauses in operand 0

2015-04-29 Thread Thomas Schwinge
Hi Jakub!

On Wed, 29 Apr 2015 13:43:55 +0200, Jakub Jelinek  wrote:
> On Wed, Apr 29, 2015 at 01:13:29PM +0200, Thomas Schwinge wrote:
> > On Wed, 29 Apr 2015 11:32:31 +0200, Jakub Jelinek  wrote:
> > > Yeah, it is a non-starter, it has unnecessary runtime overhead everywhere
> > > where it is used.
> > 
> > Huh.  OMP_CLAUSES is currently used in a dozen places in
> > cp/cp-gimplify.c, cp/pt.c, and gimplify.c.  I've been expecting my
> > changed code to be well-optimizable, for the compiler already knows
> > TREE_CODE(NODE) in a lot of these places.  Doing a quick before (1)/after
> > (2) comparison test with -g -O2 on x86_64 GNU/Linux using GCC 4.8.3, the
> > object file sizes are as follows:
> > 
> >textdata bss dec hex filename
> >   37027   0  16   3704390b3 1/build-gcc/gcc/cp/cp-gimplify.o
> >   36307   0  16   363238de3 2/build-gcc/gcc/cp/cp-gimplify.o
> >textdata bss dec hex filename
> >  458742   0 136  458878   7007e 1/build-gcc/gcc/cp/pt.o
> >  458630   0 136  458766   7000e 2/build-gcc/gcc/cp/pt.o
> >textdata bss dec hex filename
> >  166056   0  48  166104   288d8 1/build-gcc/gcc/gimplify.o
> >  166200   0  48  166248   28968 2/build-gcc/gcc/gimplify.o
> > 
> > ..., so actually smaller for the first two files.  Admittedly, there is a
> > 144 bytes (0.0867 %) size increase in gimplify.o, and I have not measured
> > the actual runtime overhead (which I'm totally expecting to be "in the
> > noise", but...), so I'm assuming that my proposal to keep the interface
> > simple does not pay for the presumed runtime overhead, so I guess I'm
> > posting this patch just for the archives...
> 
> I really don't understand how you could get smaller code out of that, that
> doesn't make any sense.

I tried a quick -fdump-tree-all comparison but that doesn't lead
anywhere, because a vast number of IDs change.  Any tricks how to tackle
such a thing?


> So yes, I really prefer OMP_STANDALONE_CLAUSES over OMP_CLAUSES for
> everything.

Like this (for trunk)?

commit 300e28fce192cb56d73cb61f787872643030f0bf
Author: Thomas Schwinge 
Date:   Wed Apr 29 16:18:49 2015 +0200

Add OMP_STANDALONE_CLAUSES.

gcc/
* tree.h (OACC_CACHE_CLAUSES, OACC_DECLARE_CLAUSES)
(OACC_ENTER_DATA_CLAUSES, OACC_EXIT_DATA_CLAUSES)
(OACC_UPDATE_CLAUSES, OMP_TARGET_UPDATE_CLAUSES): Merge into...
(OMP_STANDALONE_CLAUSES): ... this new macro.  Adjust all users.
---
 gcc/c/c-parser.c|   11 ---
 gcc/cp/parser.c |   11 ---
 gcc/cp/pt.c |4 ++--
 gcc/gimplify.c  |   18 --
 gcc/tree-pretty-print.c |   12 ++--
 gcc/tree.def|   12 ++--
 gcc/tree.h  |   19 ++-
 7 files changed, 32 insertions(+), 55 deletions(-)

diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index f5e2ac2c..86b77f3 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -11987,7 +11987,7 @@ c_parser_oacc_cache (location_t loc, c_parser *parser)
 
   stmt = make_node (OACC_CACHE);
   TREE_TYPE (stmt) = void_type_node;
-  OACC_CACHE_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
 
@@ -12155,10 +12155,7 @@ c_parser_oacc_enter_exit_data (c_parser *parser, bool 
enter)
 
   stmt = enter ? make_node (OACC_ENTER_DATA) : make_node (OACC_EXIT_DATA);
   TREE_TYPE (stmt) = void_type_node;
-  if (enter)
-OACC_ENTER_DATA_CLAUSES (stmt) = clauses;
-  else
-OACC_EXIT_DATA_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
 }
@@ -12285,7 +12282,7 @@ c_parser_oacc_update (c_parser *parser)
 
   tree stmt = make_node (OACC_UPDATE);
   TREE_TYPE (stmt) = void_type_node;
-  OACC_UPDATE_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
 }
@@ -13858,7 +13855,7 @@ c_parser_omp_target_update (location_t loc, c_parser 
*parser,
 
   tree stmt = make_node (OMP_TARGET_UPDATE);
   TREE_TYPE (stmt) = void_type_node;
-  OMP_TARGET_UPDATE_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, loc);
   add_stmt (stmt);
   return false;
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 4ea2ca2..61fd34f 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -31386,7 +31386,7 @@ cp_parser_omp_target_update (cp_parser *parser, 
cp_token *pragma_tok,
 
   tree stmt = make_node (OMP_TARGET_UPDATE);
   TREE_TYPE (stmt) = void_type_node;
-  OMP_TARGET_UPDATE_CLAUSES (stmt) = clauses;
+  OMP_STANDALONE_CLAUSES (stmt) = clauses;
   SET_EXPR_LOCATION (stmt, pragma_tok->location);
   add_stmt (stmt);
   return false;
@@ -31496,7 +31496,7 @@ cp_parser_oacc_cache (cp_parser *parser, cp_token 
*pragma_tok)
 
   stmt = make_node (OACC_CACHE);
   TREE_TY

Re: Bare bones of type verifier

2015-04-29 Thread Jan Hubicka
Hi,
this is updated patch that passes all languages LTO and non-LTO testing on 
ppc64.
I found few issues
 - C++ FE messes up METHOD pointers becuase sometimes it duplicated a type while
   METHOD list is incomplete, so there are type variants that points to the 
middle
   of the final list. (I suppose we want to track this only on main variant)
 - C FE messes TYPE_VFIELD in libgo build because it uses it to link
   C_TYPE_INCOMPLETE_VARS. Sometimes it produce type variant and forgets to 
clear
   the pointer and sometimes it never walks the lists and never clears it.
   I added code to free_lang_data to clear it since it is not quite clear
   how to track this in FE.  
 - Java FE messes up with TYPE_BINFO because it produces dummy BINFO by:
/* Unfortunately we must create the binfo here, so that class
   loading works.  */
TYPE_BINFO (type) = make_tree_binfo (0);
   and in some variants it forgets to replace it by real thing later.
   I just relaxed the check for the moment and will look into it incrementally.
   Again I think we may want TYPE_BINFO on main variants only or Java may just
   propagate proper info to all vairant copies. Both would work.
 - Java FE sometimes unnecesarily recomputes TYPE_SIZE_UNIT in different type
   so pointer compare fails even when it could pass (TYPE_SIZE is fine)
   Again I relaxed the sanity check to require sizes to be equal but not pointer
   equivalent and will look into it.

This only covers the few checks implemented in verify_type_variant.  There are
clearly many issues to look into. I will commit this version of patch tomorrow
if there are no complains and will start chasing issues in small stemps.

Honza

* dwarf2out.c (gen_type_die_with_usage): Call verify_type.
* ipa-chkp.c (chkp_copy_function_type_adding_bounds): Do not produce
bugus variants.
* tree.c: Include print-tree.h and ipa-utils.h
(free_lang_data_in_type): Clear TYPE_VFIELD leaked by C FE.
(free_lang_data_in_cgraph): Call verify_type.
(verify_type_variant): New function.
(verify_type): New function.
* tree.h (verify_type): Declare.

* lto.c (lto_fixup_state): Call verify_type.
Index: dwarf2out.c
===
--- dwarf2out.c (revision 222526)
+++ dwarf2out.c (working copy)
@@ -20238,6 +20238,11 @@ gen_type_die_with_usage (tree type, dw_d
   if (type == NULL_TREE || type == error_mark_node)
 return;
 
+#ifdef ENABLE_CHECKING
+  if (type)
+ verify_type (type);
+#endif
+
   if (TYPE_NAME (type) != NULL_TREE
   && TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
   && is_redundant_typedef (TYPE_NAME (type))
Index: ipa-chkp.c
===
--- ipa-chkp.c  (revision 222526)
+++ ipa-chkp.c  (working copy)
@@ -244,7 +244,7 @@ tree
 chkp_copy_function_type_adding_bounds (tree orig_type)
 {
   tree type;
-  tree arg_type, attrs, t;
+  tree arg_type, attrs;
   unsigned len = list_length (TYPE_ARG_TYPES (orig_type));
   unsigned *indexes = XALLOCAVEC (unsigned, len);
   unsigned idx = 0, new_idx = 0;
@@ -327,20 +327,6 @@ chkp_copy_function_type_adding_bounds (t
   TYPE_ATTRIBUTES (type) = attrs;
 }
 
-  t = TYPE_MAIN_VARIANT (orig_type);
-  if (orig_type != t)
-{
-  TYPE_MAIN_VARIANT (type) = t;
-  TYPE_NEXT_VARIANT (type) = TYPE_NEXT_VARIANT (t);
-  TYPE_NEXT_VARIANT (t) = type;
-}
-  else
-{
-  TYPE_MAIN_VARIANT (type) = type;
-  TYPE_NEXT_VARIANT (type) = NULL;
-}
-
-
   return type;
 }
 
Index: lto/lto.c
===
--- lto/lto.c   (revision 222526)
+++ lto/lto.c   (working copy)
@@ -2844,6 +2844,10 @@ lto_fixup_state (struct lto_in_decl_stat
   for (i = 0; i < vec_safe_length (trees); i++)
{
  tree t = (*trees)[i];
+#ifdef ENABLE_CHECKING
+ if (TYPE_P (t))
+   verify_type (t);
+#endif
  if (VAR_OR_FUNCTION_DECL_P (t)
  && (TREE_PUBLIC (t) || DECL_EXTERNAL (t)))
(*trees)[i] = lto_symtab_prevailing_decl (t);
Index: tree.c
===
--- tree.c  (revision 222526)
+++ tree.c  (working copy)
@@ -102,6 +102,8 @@ along with GCC; see the file COPYING3.
 #include "debug.h"
 #include "intl.h"
 #include "builtins.h"
+#include "print-tree.h"
+#include "ipa-utils.h"
 
 /* Tree code classes.  */
 
@@ -5077,6 +5079,11 @@ free_lang_data_in_type (tree type)
   else
TYPE_FIELDS (type) = NULL_TREE;
 
+  /* FIXME: C FE uses TYPE_VFIELD to record C_TYPE_INCOMPLETE_VARS
+and danagle the pointer from time to time.  */
+  if (TYPE_VFIELD (type) && TREE_CODE (TYPE_VFIELD (type)) != FIELD_DECL)
+TYPE_VFIELD (type) = NULL_TREE;
+
   TYPE_METHODS (type) = NULL_TREE;
   if (TYPE_BINFO (type))
{
@@ -5784,6 +5791,10 @@ free_lang_data_in_cgraph (void)
 

Re: [patch] Perform anonymous constant propagation during inlining

2015-04-29 Thread Jan Hubicka
> On Wed, Apr 29, 2015 at 3:23 PM, Jan Hubicka  wrote:
> >> Historically the pragma Inline_Always of GNAT had been implemented in the 
> >> FE
> >> because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
> >> powerful enough to inline some constructs.  But this approach had 
> >> drawbacks,
> >> especially wrt debug info.  These restrictions were gradually lifted and 
> >> now
> >> the pragma is entirely piggybacked on the Tree inliner.
> >>
> >> This went mostly OK, except for a few cases where intrisinc operations that
> >> used to be reasonably handled at -O0 now generate awful code, the typical
> >> example being a modulus or division instrinsic by a power-of-2 generating a
> >> fully-fledged modulus or division instruction instead of a simple shift.
> >>
> >> Therefore the attached patch implements anonymous constant propagation in 
> >> the
> >> inliner to fix the code quality regression.
> >>
> >> Tested on x86_64-suse-linux, OK for the mainline?
> >>
> >>if (TREE_CODE (*tp) == SSA_NAME)
> >>  {
> >> -  *tp = remap_ssa_name (*tp, id);
> >> +  tree t = remap_ssa_name (*tp, id);
> >> +  /* Perform anonymous constant propagation, this makes it possible to
> >> + generate reasonable code even at -O0 for operators implemented as
> >> + inline functions.  */
> >> +  if (TREE_CODE (t) == SSA_NAME
> >> +   && SSA_NAME_DEF_STMT (t)
> >> +   && (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t)))
> >> +   && gimple_assign_copy_p (SSA_NAME_DEF_STMT (t))
> >> +   && is_gimple_min_invariant
> >> +  (gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t
> >> + *tp = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t));
> >> +  else
> >> + *tp = t;
> >
> > This looks like a good idea to me (though i can't approve it).  We may want 
> > to
> > lift the (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t))) when 
> > optimize
> > is set - the amount of garbage inliner produce is large and killing it 
> > early is
> > better than killing it later.  This has chance to help early opts where
> > ordering between ccp and einline is quite hard.
> 
> Early opts run CCP as pretty much the first pass, so I don't see what
> you are refering to here.

Hmm, you are right. I remember playing with similar patch but that was before
we turned off iteration in early inliner and it was motivated to do more
of indirect  call promotion.

Since ipa-prop is no longer complete joke on propagating devirutalization info
perhaps this is no longer too important.

honza


Re: [PATCH][AArch64] Increase static buffer size in aarch64_rewrite_selected_cpu

2015-04-29 Thread Kyrill Tkachov


On 20/04/15 21:30, James Greenhalgh wrote:

On Mon, Apr 20, 2015 at 05:24:39PM +0100, Kyrill Tkachov wrote:

Hi all,

When trying to compile a testcase with -mcpu=cortex-a57+crypto+nocrc I got
the weird assembler error:
Assembler messages:
Error: missing architectural extension
Error: unrecognized option -mcpu=cortex-a57+crypto+no

The problem is the aarch64_rewrite_selected_cpu that is used to rewrite -mcpu
for big.LITTLE options has a limit of 20 characters in what it handles, which
we can exhaust quickly if we specify architectural extensions in a
fine-grained manner.

This patch increases that character limit to 128 and adds an assert to
confirm that no bad things happen.

You've implemented this as a hard ICE, was that intended?


It also fixes another problem: If we pass a big.LITTLE combination with
feature modifiers like: -mcpu=cortex-a57.cortex-a53+nosimd

the code will truncate everything after '.', thus destroying the extensions
that we want to pass.  The patch adds code to stitch the extensions back on
after the LITTLE cpu is removed.

UGH, I should not be allowed near strings! This code is on my list of
things I'd love to rewrite to this year! For now, this is OK and please
also queue it for 5.2 when that opens for patches.


Hi all,
Just to confirm.
Is it ok to backport this patch to the GCC 5 branch?

Thanks,
Kyrill




Ok for trunk?

Yes, thanks. And sorry again for introducing this in the first place.

James





Re: [PATCH 5/13] microblaze musl support

2015-04-29 Thread Szabolcs Nagy


On 29/04/15 14:17, Michael Eager wrote:
> On 04/27/2015 07:35 AM, Szabolcs Nagy wrote:
>>
>> On 20/04/15 19:54, Szabolcs Nagy wrote:
>>> Set up dynamic linker name for microblaze.
>>>
>>
>> Patch v2.
>> (undef MUSL_DYNAMIC_LINKER that comes from config/linux.h)
>>
>> gcc/Changelog:
>>
>> 2015-04-24  Gregor Richards  
>>
>>  * config/microblaze/linux.h (MUSL_DYNAMIC_LINKER): Define.
>>  (DYNAMIC_LINKER): Change.
>>
> 
> Are you building with both glibc and musl to verify these patches?
> 

i tested various aarch64 and x86 configurations with both glibc
and musl, but not everything was tested.

in particular microblaze (big and little endian) was only built
with musl.

note that microblaze does not use the GNU_USER_DYNAMIC_LINKER
macro so the -mglibc etc options don't work.
(that should be changed probably, assuming -muclibc and -mbionic
have no side effects when they are not supported)



Re: Mostly rewrite genrecog

2015-04-29 Thread Richard Sandiford
Jeff Law  writes:
> On 04/27/2015 04:20 AM, Richard Sandiford wrote:
>> Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-none-eabi.
>> Also tested by building the testsuite for each of the targets above
>> and making sure there were no assembly differences.  Made sure that no
>> objects in spec2k6 changed for aarch64-linux-gnu (except for perlbench
>> perl.o and cactusADM datestamp.o, where the differences are timestamps).
>> OK to install?
> To be very blunt, I'm probably not capable of reviewing the new code. 
> You're going to know it best and you should probably own it.
>
> Given your history with gcc and attention to detail, I'm comfortable 
> with approving this knowing you'll deal with any issues as they arise.

Thanks, applied.

> The one thing I would ask is that you make sure to include the recently 
> added matching constraint checking bits in genrecog.  I'm assuming all 
> the older sanity checks that have been in genrecog for a longer period 
> of time have been kept.

Yeah, Chen Gang's changes are all still in there.  All the older checks
should still be in there too.

Richard



Re: Mostly rewrite genrecog

2015-04-29 Thread Richard Sandiford
Eric Botcazou  writes:
>> Also, the code is all goto-based, which makes it rather hard to step
>> through.
>
> Do you mean the code in genrecog.c or the generated code in insn-recog.c?

The generated code.  genrecog.c itself isn't bad. :-)

>> PS. I've attached the new genrecog.c since the diff version is unreadable.
>
> Small request: you didn't change a single line of the head comment, yet the 
> size of the file is doubled.  Could you add a sketch of the algorithm to the 
> head comment, e.g. by copy-and-pasting the above part of your message?

OK.  I'd left the head comment alone because it just described the
interface, which hasn't changed.  But I suppose past lack of commentary
doesn't justify future lack of commentary.  Here's what I added:

   At a high level, the algorithm used in this file is as follows:

   1. Build up a decision tree for each routine, using the following
  approach to matching an rtx:

  - First determine the "shape" of the rtx, based on GET_CODE,
XVECLEN and XINT.  This phase examines SET_SRCs before SET_DESTs
since SET_SRCs tend to be more distinctive.  It examines other
operands in numerical order, since the canonicalization rules
prefer putting complex operands of commutative operators first.

  - Next check modes and predicates.  This phase examines all
operands in numerical order, even for SETs, since the mode of a
SET_DEST is exact while the mode of a SET_SRC can be VOIDmode
for constant integers.

  - Next check match_dups.

  - Finally check the C condition and (where appropriate) pnum_clobbers.

   2. Try to optimize the tree by removing redundant tests, CSEing tests,
  folding tests together, etc.

   3. Look for common subtrees and split them out into "pattern" routines.
  These common subtrees can be identical or they can differ in mode,
  code, or integer (usually an UNSPEC or UNSPEC_VOLATILE code).
  In the latter case the users of the pattern routine pass the
  appropriate mode, etc., as argument.  For example, if two patterns
  contain:

 (plus:SI (match_operand:SI 1 "register_operand")
  (match_operand:SI 2 "register_operand"))

  we can split the associated matching code out into a subroutine.
  If a pattern contains:

 (minus:DI (match_operand:DI 1 "register_operand")
   (match_operand:DI 2 "register_operand"))

  then we can consider using the same matching routine for both
  the plus and minus expressions, passing PLUS and SImode in the
  former case and MINUS and DImode in the latter case.

  The main aim of this phase is to reduce the compile time of the
  insn-recog.c code and to reduce the amount of object code in
  insn-recog.o.

   4. Split the matching trees into functions, trying to limit the
  size of each function to a sensible amount.

  Again, the main aim of this phase is to reduce the compile time
  of insn-recog.c.  (It doesn't help with the size of insn-recog.o.)

   5. Write out C++ code for each function.

BTW, hope at least part of the doubling in size is due to more commentary
in the code itself.

> The old code contained a couple of DEBUG_FUNCTIONs but the new one doesn't.

Yeah, but I don't know how useful they were.  I had to debug the old
code several times and never used them.

I'd rather leave stuff like that to someone who wants it rather than try
to write routines speculatively in the hope that someone would find them
useful.

Thanks,
Richard



Re: [patch] Perform anonymous constant propagation during inlining

2015-04-29 Thread Richard Biener
On Wed, Apr 29, 2015 at 3:23 PM, Jan Hubicka  wrote:
>> Historically the pragma Inline_Always of GNAT had been implemented in the FE
>> because the RTL inliner and then the Tree inliner weren't invoked at -O0 or
>> powerful enough to inline some constructs.  But this approach had drawbacks,
>> especially wrt debug info.  These restrictions were gradually lifted and now
>> the pragma is entirely piggybacked on the Tree inliner.
>>
>> This went mostly OK, except for a few cases where intrisinc operations that
>> used to be reasonably handled at -O0 now generate awful code, the typical
>> example being a modulus or division instrinsic by a power-of-2 generating a
>> fully-fledged modulus or division instruction instead of a simple shift.
>>
>> Therefore the attached patch implements anonymous constant propagation in the
>> inliner to fix the code quality regression.
>>
>> Tested on x86_64-suse-linux, OK for the mainline?
>>
>>if (TREE_CODE (*tp) == SSA_NAME)
>>  {
>> -  *tp = remap_ssa_name (*tp, id);
>> +  tree t = remap_ssa_name (*tp, id);
>> +  /* Perform anonymous constant propagation, this makes it possible to
>> + generate reasonable code even at -O0 for operators implemented as
>> + inline functions.  */
>> +  if (TREE_CODE (t) == SSA_NAME
>> +   && SSA_NAME_DEF_STMT (t)
>> +   && (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t)))
>> +   && gimple_assign_copy_p (SSA_NAME_DEF_STMT (t))
>> +   && is_gimple_min_invariant
>> +  (gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t
>> + *tp = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t));
>> +  else
>> + *tp = t;
>
> This looks like a good idea to me (though i can't approve it).  We may want to
> lift the (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t))) when 
> optimize
> is set - the amount of garbage inliner produce is large and killing it early 
> is
> better than killing it later.  This has chance to help early opts where
> ordering between ccp and einline is quite hard.

Early opts run CCP as pretty much the first pass, so I don't see what
you are refering to here.

>>*walk_subtrees = 0;
>>return NULL;
>>  }
>> @@ -1965,7 +1977,7 @@ copy_bb (copy_body_data *id, basic_block
>>
>> /* Statements produced by inlining can be unfolded, especially
>>when we constant propagated some operands.  We can't fold
>> -  them right now for two reasons:
>> +  them right now in the general case for two reasons:
>>1) folding require SSA_NAME_DEF_STMTs to be correct
>>2) we can't change function calls to builtins.
>>So we just mark statement for later folding.  We mark
>> @@ -1974,7 +1986,10 @@ copy_bb (copy_body_data *id, basic_block
>>foldable indirectly are updated.  If this turns out to be
>>expensive, copy_body can be told to watch for nontrivial
>>changes.  */
>> -   if (id->statements_to_fold)
>> +   if (gimple_assign_cast_p (stmt)
>> +   && is_gimple_min_invariant (gimple_assign_rhs1 (stmt)))
>> + fold_stmt (©_gsi);
>> +   else if (id->statements_to_fold)
>
> Why this is needed? Is it just an optimization because we know that folding of
> casts will not do crazy stuff like SSA graph walking (that was original reason
> for delaying the folidng) or just an optimization to reudce the size of the 
> list?

Beause this folding turns the cast into sth the above hunk handles...

It's basically a hack ;)

A better approach might be to simply fold stmts we copy during the
stmt copy itself by using gimple_build intead of gimple_copy + fold_stmt.
Note that the match-and-simplify machinery does not perform constant
propgation but relies on a valueization hook.

Richard.

> Honza
>>   id->statements_to_fold->add (stmt);
>>
>> /* We're duplicating a CALL_EXPR.  Find any corresponding


Re: [PATCH][AArch64] Fix PR/65770 vstN_lane on bigendian

2015-04-29 Thread Marcus Shawcroft
On 16 April 2015 at 18:27, Alan Lawrence  wrote:
> As per bugzilla entry, indices in the generated assembly for bigendian are
> flipped when they should not be (and, flipped always relative to a
> Q-register!).
>
> This flips the lane indices back again at assembly time, fixing PR. The
> "indices" contained in the RTL are still wrong for D registers, but these
> are only parameters to an UNSPEC and so never acted upon. (Nonetheless I
> intend to fix this anomaly in later patches).
>
> Tested check-gcc on aarch64-none-elf and aarch64_be-none-elf.
> New test (initially failing on bigendian) now passing on both.
>
> gcc/ChangeLog:
>
> PR target/65770
> config/aarch64/aarch64-simd.md (vec_store_lanesoi_lane,
> vec_store_lanesci_lane, vec_store_lanesxi_lane):
> Flip lane index back at assembly time for bigendian.
>
> gcc/testsuite/ChangeLog:
>
> PR target/65770
> gcc.target/aarch64/vstN_lane_1.c: New file.

OK and backport to 5 please. /Marcus


Re: [PATCH 0/13] Add musl support to GCC

2015-04-29 Thread Szabolcs Nagy


On 29/04/15 00:27, Joseph Myers wrote:
> On Mon, 20 Apr 2015, Szabolcs Nagy wrote:
> 
>> * On powerpc it seems the only configure option to choose the default
>> long-double abi is --with-long-double-128, but that's the default with
>> sufficiently new glibc. (musl gets 64bit long-double because the glibc
>> version check fails, this is ok, because there is no ibm128 support in
>> musl, but it would be better if --with-long-double-64 could be set
>> explicitly or even ieee128 abi if gcc supports that).
> 
> It should be possible to use --without-long-double-128 (if not, that's a 
> bug).
> 

ok, --without-long-double-128 works, i thought i tested it

>> * gcc stdatomic.h has some incompatible typedefs with musl stdint.h
> 
> If musl has chosen stdint.h types different from those in glibc, you need 
> to make the *_TYPE macros appropriately conditional (possibly making 
> glibc-stdint.h include conditionals to select the musl types when musl is 
> in use).
> 

only affects [u]int_fastN_t types
(on 64bit systems for N=16,32 musl uses int but glibc uses long)

i can fix glibc-stdint.h, but it's yet another way in which the
compiler is tied to a particular libc.

(using musl-stdint.h would be nicer, but that would require more
changes i think, i have a fix now where the glibc-stdint.h types
depend on OPTION_MUSL, but i still have to make sure OPTION_MUSL
is always defined when this header is used).

(i'd prefer if the compiler did not know about these types, but
the standard requires them in stdatomic.h without including stdint.h
and in stdint.h in freestanding mode, i'm not sure if there is a
workaround without depending on libc)



Re: [C++ Patch] PR 64667

2015-04-29 Thread Jason Merrill

On 04/29/2015 08:52 AM, Paolo Carlini wrote:

+  /* Handle references.  */
+  if (TREE_CODE (val) == INDIRECT_REF)


Let's use REFERENCE_REF_P here.  OK with that change.

Jason



Re: [PATCH][AArch64] Fix PR/65770 vstN_lane on bigendian

2015-04-29 Thread Alan Lawrence

Alan Lawrence wrote:
As per bugzilla entry, indices in the generated assembly for bigendian are 
flipped when they should not be (and, flipped always relative to a Q-register!).


This flips the lane indices back again at assembly time, fixing PR. The 
"indices" contained in the RTL are still wrong for D registers, but these are 
only parameters to an UNSPEC and so never acted upon. (Nonetheless I intend to 
fix this anomaly in later patches).


Tested check-gcc on aarch64-none-elf and aarch64_be-none-elf.
New test (initially failing on bigendian) now passing on both.

gcc/ChangeLog:

PR target/65770
config/aarch64/aarch64-simd.md (vec_store_lanesoi_lane,
vec_store_lanesci_lane, vec_store_lanesxi_lane):
Flip lane index back at assembly time for bigendian.

gcc/testsuite/ChangeLog:

PR target/65770
gcc.target/aarch64/vstN_lane_1.c: New file.


Ping.



Re: [patch] Perform anonymous constant propagation during inlining

2015-04-29 Thread Jan Hubicka
> Historically the pragma Inline_Always of GNAT had been implemented in the FE 
> because the RTL inliner and then the Tree inliner weren't invoked at -O0 or 
> powerful enough to inline some constructs.  But this approach had drawbacks, 
> especially wrt debug info.  These restrictions were gradually lifted and now 
> the pragma is entirely piggybacked on the Tree inliner.
> 
> This went mostly OK, except for a few cases where intrisinc operations that 
> used to be reasonably handled at -O0 now generate awful code, the typical 
> example being a modulus or division instrinsic by a power-of-2 generating a 
> fully-fledged modulus or division instruction instead of a simple shift.
> 
> Therefore the attached patch implements anonymous constant propagation in the 
> inliner to fix the code quality regression.
> 
> Tested on x86_64-suse-linux, OK for the mainline?
> 
>if (TREE_CODE (*tp) == SSA_NAME)
>  {
> -  *tp = remap_ssa_name (*tp, id);
> +  tree t = remap_ssa_name (*tp, id);
> +  /* Perform anonymous constant propagation, this makes it possible to
> + generate reasonable code even at -O0 for operators implemented as
> + inline functions.  */
> +  if (TREE_CODE (t) == SSA_NAME
> +   && SSA_NAME_DEF_STMT (t)
> +   && (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t)))
> +   && gimple_assign_copy_p (SSA_NAME_DEF_STMT (t))
> +   && is_gimple_min_invariant
> +  (gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t
> + *tp = gimple_assign_rhs1 (SSA_NAME_DEF_STMT (t));
> +  else
> + *tp = t;

This looks like a good idea to me (though i can't approve it).  We may want to
lift the (!SSA_NAME_VAR (t) || DECL_IGNORED_P (SSA_NAME_VAR (t))) when optimize
is set - the amount of garbage inliner produce is large and killing it early is
better than killing it later.  This has chance to help early opts where
ordering between ccp and einline is quite hard.
>*walk_subtrees = 0;
>return NULL;
>  }
> @@ -1965,7 +1977,7 @@ copy_bb (copy_body_data *id, basic_block
>  
> /* Statements produced by inlining can be unfolded, especially
>when we constant propagated some operands.  We can't fold
> -  them right now for two reasons:
> +  them right now in the general case for two reasons:
>1) folding require SSA_NAME_DEF_STMTs to be correct
>2) we can't change function calls to builtins.
>So we just mark statement for later folding.  We mark
> @@ -1974,7 +1986,10 @@ copy_bb (copy_body_data *id, basic_block
>foldable indirectly are updated.  If this turns out to be
>expensive, copy_body can be told to watch for nontrivial
>changes.  */
> -   if (id->statements_to_fold)
> +   if (gimple_assign_cast_p (stmt)
> +   && is_gimple_min_invariant (gimple_assign_rhs1 (stmt)))
> + fold_stmt (©_gsi);
> +   else if (id->statements_to_fold)

Why this is needed? Is it just an optimization because we know that folding of
casts will not do crazy stuff like SSA graph walking (that was original reason
for delaying the folidng) or just an optimization to reudce the size of the 
list?

Honza
>   id->statements_to_fold->add (stmt);
>  
> /* We're duplicating a CALL_EXPR.  Find any corresponding


Re: [PATCH,rs6000] Change -mcrypto to only affect Category:Vector.Crypto instructions

2015-04-29 Thread David Edelsohn
On Wed, Mar 4, 2015 at 3:14 PM, Bill Schmidt
 wrote:
> Hi,
>
> I recently observed that -mno-crypto disables all instructions in
> section 5.11 of the 2.07 ISA, rather than just those flagged as
> Category:Vector.Crypto.  This patch fixes that undesirable situation.
>
> The main fix is to ensure the remaining instructions are gated by
> TARGET_P8_VECTOR rather than TARGET_CRYPTO.  This leaves us in a
> somewhat ugly state where we have builtins named __builtin_crypto_* that
> are not controlled by -mcrypto.  However, we have to keep support for
> these existing builtins.  As discussed elsewhere, the longer-term plan
> is to implement a different common naming scheme for these builtins
> across all POWER compilers, at which point the __builtin_crypto_* forms
> will be deprecated.
>
> The changes to rs6000-builtin.def aren't the prettiest in the world, but
> were the best I could think of that continues support for the existing
> builtins while changing their predicates.  Let me know if there's a
> better way.
>
> Ok for trunk once GCC 5 branches?  I would eventually like to fix this
> in 4.8, 4.9, and 5 as well.

> Index: gcc/testsuite/gcc.target/powerpc/crypto-builtin-2.c
> ===
> --- gcc/testsuite/gcc.target/powerpc/crypto-builtin-2.c (revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/crypto-builtin-2.c (working copy)
> @@ -0,0 +1,36 @@
> +/* { dg-do compile { target { powerpc*-*-* } } } */
> +/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
> +/* { dg-require-effective-target powerpc_vsx_ok } */
> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> "-mcpu=power8" } } */
> +/* { dg-options "-O2 -mcpu=power8 -mno-crypto" } */

Bill,

I think this test criterion is wrong and should be

Index: crypto-builtin-2.c
===
--- crypto-builtin-2.c  (revision 222534)
+++ crypto-builtin-2.c  (working copy)
@@ -1,6 +1,6 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
-/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*"
} { "-mcpu=power8" } } */
 /* { dg-options "-O2 -mcpu=power8 -mno-crypto" } */

Thoughts?

- David


Re: [PATCH 5/13] microblaze musl support

2015-04-29 Thread Michael Eager

On 04/27/2015 07:35 AM, Szabolcs Nagy wrote:


On 20/04/15 19:54, Szabolcs Nagy wrote:

Set up dynamic linker name for microblaze.



Patch v2.
(undef MUSL_DYNAMIC_LINKER that comes from config/linux.h)

gcc/Changelog:

2015-04-24  Gregor Richards  

* config/microblaze/linux.h (MUSL_DYNAMIC_LINKER): Define.
(DYNAMIC_LINKER): Change.



Are you building with both glibc and musl to verify these patches?

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


[C++ Patch] PR 64667

2015-04-29 Thread Paolo Carlini

Hi,

Jonathan noticed in the audit trail the probably his work for c++/18016 
could be easily extended to handle references: simply looking through 
INDIRECT_REFs appears to do the trick. Tested x86_64-linux.


Thanks,
Paolo.


/cp
2015-04-29  Paolo Carlini  

PR c++/64667
* init.c (perform_member_init): Handle references for -Winit-self.

/testsuite
2015-04-29  Paolo Carlini  

PR c++/64667
* g++.dg/warn/Winit-self-3.C: New.
Index: cp/init.c
===
--- cp/init.c   (revision 222561)
+++ cp/init.c   (working copy)
@@ -625,6 +625,9 @@ perform_member_init (tree member, tree init)
   && TREE_CHAIN (init) == NULL_TREE)
 {
   tree val = TREE_VALUE (init);
+  /* Handle references.  */
+  if (TREE_CODE (val) == INDIRECT_REF)
+   val = TREE_OPERAND (val, 0);
   if (TREE_CODE (val) == COMPONENT_REF && TREE_OPERAND (val, 1) == member
  && TREE_OPERAND (val, 0) == current_class_ref)
warning_at (DECL_SOURCE_LOCATION (current_function_decl),
Index: testsuite/g++.dg/warn/Winit-self-3.C
===
--- testsuite/g++.dg/warn/Winit-self-3.C(revision 0)
+++ testsuite/g++.dg/warn/Winit-self-3.C(working copy)
@@ -0,0 +1,26 @@
+// PR c++/64667
+// { dg-options "-Winit-self" }
+
+class A
+{
+public:
+  A(const A&) : a(a) {}  // { dg-warning "initialized with itself" }
+private:
+  int a;
+};
+
+class B
+{
+public:
+  B(const B&) : b(b) {}  // { dg-warning "initialized with itself" }
+private:
+  int* b;
+};
+
+class C
+{
+public:
+  C(const C&) : c(c) {}  // { dg-warning "initialized with itself" }
+private:
+  int& c;
+};


Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS

2015-04-29 Thread Andreas Schwab
spawn /daten/aranym/gcc/gcc-20150429/Build/gcc/xgcc 
-B/daten/aranym/gcc/gcc-20150429/Build/gcc/ 
/daten/aranym/gcc/gcc-20150429/gcc/testsuite/objc/execute/bf-1.m 
-fno-diagnostics-show-caret -fdiagnostics-color=never -w -O0 -fgnu-runtime 
-I/daten/aranym/gcc/gcc-20150429/gcc/testsuite/../../libobjc 
-B/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs 
-L/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs -lobjc -lm -o 
/daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0
PASS: objc/execute/bf-1.m compilation,  -O0 -fgnu-runtime
Executing on aranym: OMP_NUM_THREADS=2 
LD_LIBRARY_PATH=.::/daten/aranym/gcc/gcc-20150429/Build/gcc:/daten/aranym/gcc/gcc-20150429/Build/m68k-linux/./libobjc/.libs
 timeout 600 /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0
(timeout = 300)
Executed /daten/aranym/gcc/gcc-20150429/Build/gcc/testsuite/objc/bf-1.x0, 
status 1
Output: type = {class_vars=#fc{?=b0i2b2i3b5i12}c}
ivar 'isa', type '#', offset 0d
ivar 'f', type 'f', offset 4d
ivar 'a', type 'c', offset 8d
ivar 'flags', type '{?="i"b0i2"j"b2i3"k"b5i12}', offset 9d
ivar 'c', type 'c', offset 12d
real ivar 'isa' offset 0d
computed type '#fc{?=b0i2b2i3b5i12}c}' offset 0
real ivar 'f' offset 4d
computed type 'fc{?=b0i2b2i3b5i12}c}' offset 4
real ivar 'a' offset 8d
computed type 'c{?=b0i2b2i3b5i12}c}' offset 8
real ivar 'flags' offset 9d
computed type '{?=b0i2b2i3b5i12}c}' offset 10
offset 9d and computed position 10 don't match on ivar 'flags' (i = 3)
child process exited abnormally
FAIL: objc/execute/bf-1.m execution,  -O0 -fgnu-runtime

Andreas.

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


  1   2   >