Re: [hsa merge 07/10] IPA-HSA pass

[Alexander Monakov]

On Wed, 20 Jan 2016, Ilya Verbin wrote:
> I agree that OpenMP doesn't guarantee that all target regions must be executed
> on the device, but in this case a user can't be sure that some library 
> function
> always will offload (because the library might be replaced by fallback 
> version),
> and he/she will have to write something like:

I think there should be a way to allow the OpenMP runtime deduce what data
needs to be resynced on target region entries/exits in presence of fallback
execution; explicit copying via map(from/to:...) is a too big hammer for that.
I wonder if it was discussed.

It would be nice to be able to apply the idea of "debug counters" to target
region offloading in order to automatically bisect offload miscompilations:
force fallback execution for target region entries for Nth and next
executions; bisect by N to find the first incorrectly executing offload
region.  If the implementation cannot count on source program fully handling
arbitrary fallbacks, this idea doesn't work in general.

Alexander

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

[James Greenhalgh]

On Thu, Jan 21, 2016 at 11:13:29AM +, Wilco Dijkstra wrote:
> James Greenhalgh  wrote:
> > If we don't have any targets which care about the fccmps/fccmpd split in
> > the code base, do we really need it? Can we just follow the example of
> > fcsel?
> 
> If we do that then we should also change fcmps/d to fcmp to keep the f(c)cmp
> attributes orthogonal. However it seems better to have all FP operations use
> {s|d} postfix as the convention (rather than assume that all current and 
> future
> microarchitectures will treat float and double identically on all operations),
> so fcsel should ideally be fixed.

Adding values to this type attributes is a pretty lightweight change, and
each new type attribute has a small cost in compiler build-time and scheduler
performance. Given this, I don't see any need to design for the future, and
I don't see why we'd want to add more of them than we need to.

The fcmps/fcmpd split is used in cortex-a15-neon.md and cortex-r4f.md so
doesn't make a good comparison.

If we support a target in future which would benefit from different
modeling for fccmps and fccmpd we can split the value then.

Thanks,
James

Re: [AARCH64][ACLE][NEON] Implement vcvt*_s64_f64 and vcvt*_u64_f64 NEON intrinsics.

[James Greenhalgh]

On Wed, Jan 13, 2016 at 05:44:30PM +, Bilyan Borisov wrote:
> This patch implements all the vcvtR_s64_f64 and vcvtR_u64_f64 vector
> intrinsics, where R is ['',a,m,n,p]. Since these intrinsics are
> identical in semantics to the corresponding scalar variants, they are
> implemented in terms of them, with appropriate packing and unpacking
> of vector arguments. New test cases, covering all the intrinsics were
> also added.

This patch is very low risk, gets us another step towards closing pr58693,
and was posted before the Stage 3 deadline. This is OK for trunk.

Thanks,
James

> 
> Cross tested on aarch64-none-elf and aarch64-none-linux-gnu.
> Bootstrapped and
> tested on aarch64-none-linux-gnu.
> 
> ---
> 
> gcc/
> 
> 2015-XX-XX  Bilyan Borisov  
> 
>   * config/aarch64/arm_neon.h (vcvt_s64_f64): New intrinsic.
>   (vcvt_u64_f64): Likewise.
>   (vcvta_s64_f64): Likewise.
>   (vcvta_u64_f64): Likewise.
>   (vcvtm_s64_f64): Likewise.
>   (vcvtm_u64_f64): Likewise.
>   (vcvtn_s64_f64): Likewise.
>   (vcvtn_u64_f64): Likewise.
>   (vcvtp_s64_f64): Likewise.
>   (vcvtp_u64_f64): Likewise.
> 
> gcc/testsuite/
> 
> 2015-XX-XX  Bilyan Borisov  
> 
>   * gcc.target/aarch64/simd/vcvt_s64_f64_1.c: New.
>   * gcc.target/aarch64/simd/vcvt_u64_f64_1.c: Likewise.
>   * gcc.target/aarch64/simd/vcvta_s64_f64_1.c: Likewise.
>   * gcc.target/aarch64/simd/vcvta_u64_f64_1.c: Likewise.
>   * gcc.target/aarch64/simd/vcvtm_s64_f64_1.c: Likewise.
>   * gcc.target/aarch64/simd/vcvtm_u64_f64_1.c: Likewise.
>   * gcc.target/aarch64/simd/vcvtn_s64_f64_1.c: Likewise.
>   * gcc.target/aarch64/simd/vcvtn_u64_f64_1.c: Likewise.
>   * gcc.target/aarch64/simd/vcvtp_s64_f64_1.c: Likewise.
>   * gcc.target/aarch64/simd/vcvtp_u64_f64_1.c: Likewise.

[PATCH] Fix graphite build with ISL 0.14

[Richard Biener]

Committed as obvious.

2016-01-21  Richard Biener  

* graphite-optimize-isl.c (get_schedule_map): Fix typo.

Index: gcc/graphite-optimize-isl.c
===
--- gcc/graphite-optimize-isl.c (revision 232666)
+++ gcc/graphite-optimize-isl.c (working copy)
@@ -301,7 +301,7 @@ get_schedule_map (isl_schedule *schedule
 {
   isl_band_list *band_list = isl_schedule_get_band_forest (schedule);
   isl_union_map *schedule_map = get_schedule_for_band_list (band_list);
-  isl_band_list_free (bandList);
+  isl_band_list_free (band_list);
   return schedule_map;
 }
 #endif

Re: [PATCH, rs6000] Add Power9 asm entries

[David Edelsohn]

On Wed, Jan 20, 2016 at 4:21 PM, Pat Haugen  wrote:
> The following adds a couple missed Power9 assembler option entries.
> Bootstrapped on ppc64. Ok for trunk?
>
> -Pat
>
> 2016-01-20  Pat Haugen  
>
> * config/rs6000/aix71.h (ASM_CPU_SPEC): Add entry for Power9.
> * config/rs6000/driver-rs6000.c (struct asm_names): Likewise.

Okay.

We still need to find out the magic number that AIX will return for Power9.

Thanks, David

[PATCH] Early "SSA" prerequesite - make SSA def stmt update cheaper

[Richard Biener]

This makes the SSA def stmt update during inlining cheaper by adjusting
it after remapping a SSA def instead of via an extra walk over all stmt
defs (which incidentially is not possible with FOR_EACH_SSA_* during
"early SSA" as we don't have SSA operands there).

I've tested this independently of the
[RFC] Delayed folding, match-and-simplify and early GIMPLE
patch.

This exposes that the walk_gimple_* stuff is somewhat awkward and
needs some refactoring (can't re-construct wi->gsi as gsi_for_stmt
only works for stmts in a BB and thus when we have a CFG).  Need to
think about sth (simplest is require a gsi for walk_gimple_op, like
we do for walk_gimple_stmt).

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Queued for GCC 7.

Richard.

2016-01-21  Richard Biener  

* gimple-walk.h (struct walk_stmt_info): Add stmt member.
* gimple-walk.c (walk_gimple_op): Initialize it.
(walk_gimple_asm): Set wi->is_lhs before each callback invocation.
* tree-inline.c (remap_gimple_op_r): Set SSA_NAME_DEF_STMT when
remapping SSA names of defs.
(copy_bb): Remove walk over all SSA defs and SSA_NAME_DEF_STMT
adjustment.

Index: gcc/gimple-walk.c
===
*** gcc/gimple-walk.c   (revision 232670)
--- gcc/gimple-walk.c   (working copy)
*** walk_gimple_asm (gasm *stmt, walk_tree_f
*** 100,108 
noutputs = gimple_asm_noutputs (stmt);
oconstraints = (const char **) alloca ((noutputs) * sizeof (const char *));
  
-   if (wi)
- wi->is_lhs = true;
- 
for (i = 0; i < noutputs; i++)
  {
op = gimple_asm_output_op (stmt, i);
--- 100,105 
*** walk_gimple_asm (gasm *stmt, walk_tree_f
*** 114,119 
--- 111,118 
   _reg, _inout))
wi->val_only = (allows_reg || !allows_mem);
}
+   if (wi)
+   wi->is_lhs = true;
ret = walk_tree (_VALUE (op), callback_op, wi, NULL);
if (ret)
return ret;
*** walk_gimple_op (gimple *stmt, walk_tree_
*** 182,187 
--- 181,189 
unsigned i;
tree ret = NULL_TREE;
  
+   if (wi)
+ wi->stmt = stmt;
+ 
switch (gimple_code (stmt))
  {
  case GIMPLE_ASSIGN:
Index: gcc/gimple-walk.h
===
*** gcc/gimple-walk.h   (revision 232670)
--- gcc/gimple-walk.h   (working copy)
*** struct walk_stmt_info
*** 28,33 
--- 28,34 
  {
/* Points to the current statement being walked.  */
gimple_stmt_iterator gsi;
+   gimple *stmt;
  
/* Additional data that the callback functions may want to carry
   through the recursion.  */
Index: gcc/tree-inline.c
===
*** gcc/tree-inline.c   (revision 232670)
--- gcc/tree-inline.c   (working copy)
*** remap_gimple_op_r (tree *tp, int *walk_s
*** 862,871 
--- 862,877 
copy_body_data *id = (copy_body_data *) wi_p->info;
tree fn = id->src_fn;
  
+   /* For recursive invocations this is no longer the LHS itself.  */
+   bool is_lhs = wi_p->is_lhs;
+   wi_p->is_lhs = false;
+ 
if (TREE_CODE (*tp) == SSA_NAME)
  {
*tp = remap_ssa_name (*tp, id);
*walk_subtrees = 0;
+   if (is_lhs)
+   SSA_NAME_DEF_STMT (*tp) = wi_p->stmt;
return NULL;
  }
else if (auto_var_in_fn_p (*tp, fn))
*** copy_bb (copy_body_data *id, basic_block
*** 2089,2104 
  maybe_duplicate_eh_stmt_fn (cfun, stmt, id->src_cfun, orig_stmt,
  id->eh_map, id->eh_lp_nr);
  
- if (gimple_in_ssa_p (cfun) && !is_gimple_debug (stmt))
-   {
- ssa_op_iter i;
- tree def;
- 
- FOR_EACH_SSA_TREE_OPERAND (def, stmt, i, SSA_OP_DEF)
-   if (TREE_CODE (def) == SSA_NAME)
- SSA_NAME_DEF_STMT (def) = stmt;
-   }
- 
  gsi_next (_gsi);
}
while (!gsi_end_p (copy_gsi));
--- 2095,2100 

Re: [patch] Restore cross-language inlining into Ada

[Jan Hubicka]

> On Wed, Jan 20, 2016 at 9:32 AM, Eric Botcazou  wrote:
> > Hi,
> >
> > this patch from Jan:
> >   https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01388.html
> > totally disabled cross-language inlining into Ada without notice, by adding 
> > a
> > check that always fails when the language of the callee is not Ada...
> > The attached patch simply deletes this new check to restore the initial 
> > state.

I only updated
-  /* Don't inline if the callee can throw non-call exceptions but the
- caller cannot.
- FIXME: this is obviously wrong for LTO where STRUCT_FUNCTION is missing.
- Move the flag into cgraph node or mirror it in the inline summary.  */
-  else if (callee_fun && callee_fun->can_throw_non_call_exceptions
-  && !(caller_fun && caller_fun->can_throw_non_call_exceptions))
-{
-  e->inline_failed = CIF_NON_CALL_EXCEPTIONS;
-  inlinable = false;
-}
to actually work with LTO where callee_fun/caller_fun is not always available
(but sometimes, like when ICF requested the body or when we merged profiles, it
is).

> >
> > Tested on x86_64-suse-linux, OK for the mainline?
> 
> I think the intent was to allow inlining a non-throwing -fnon-call-exceptions
> function into a not -fnon-call-exceptions function but _not_ a
> non-throwing not -fnon-call-exceptions function (that "not-throwing" is
> basically a non-sensible test) into a -fnon-call-exceptions function
> because that may now miss EH edges.
> 
> So the test looks conservatively correct to me - we can't reliably
> check whether the callee throws if the IL now were -fnon-call-exceptions
> (which we know the caller is after !opt_for_fn (callee->decl,
> flag_non_call_exceptions)
> 
> So - this doesn't look correct to me.
> 
> OTOH
> 
> static inline int foo (int a, int *b)
> {
>   return a / *b;
> }
> 
> int __attribute__((optimize("non-call-exceptions")))
> bar (int *p, int *b)
> {
>   try
> {
>   return foo (*p, b);
> }
>   catch (...)
> {
>   return 0;
> }
> }
> 
> happily inlines foo with your patch but doesn't ICE during stmt verification.
> 
> So maybe we're not verifying that "correctness" part - ah, yeah, I think
> we changed it to only verify EH tree vs. stmt consistency but not the
> other way around.

Well, it is a while since I looked deeper into EH code, but if I remember
correctly we have EH region associated with statements and the non-call
exceptions do not have EH region that is taken by EH code as an information
that the statement was proved to not throw? In that case inlining could be
safe, if the inlined statements are not placed in EH region (I think inliner
does that)

So perhaps this inlining is always safe?

Honza

Re: [PATCH][ARM] Fix PR target/69245 Rewrite arm_set_current_function

[Kyrill Tkachov]

Hi Christian,

On 21/01/16 10:36, Christian Bruel wrote:
The current arm_set_current_function was both awkward and buggy. For instance using partially set TARGET_OPTION set from pragma_parse, while restore_target_globalsnor arm_option_params_internal was not reset. Another issue is that in some 
paths, target_reinit was not called due to old cached target_option_current_node value. for instance with


foo{}
#pragma GCC target ...

foo was called with global_options set from old GCC target (which was wrong) 
and correct rtl values.

This is a reimplementation of the function. Hoping to be easier to read (and 
maintain). Solves the current issues seen so far.

regtested for arm-linux-gnueabi -mfpu=vfp, -mfpu=neon,-mfpu=neon-fp-armv8



Thanks for the patch, I'll try it out.
In the meantime there's a couple of style and typo nits...

+  /* Make sure that target_reinit is called for next function, since
+TREE_TARGET_OPTION might change with the #pragma even if there are
+no target attribute attached to the function.  */

s/attribute/attributes

-  arm_previous_fndecl = fndecl;
+  /* if no attribute, use the mode set by the current pragma target.  */
+  if (! new_tree)
+new_tree = target_option_current_node;
+

s/if/If/

+  /* now target_reinit can save the state for later. */
+  TREE_TARGET_GLOBALS (new_tree)
+   = save_target_globals_default_opts ();

s/now/Now/

Re: [PATCH 5/5] s390: Add -fsplit-stack support

[Marcin Kościelnicki]

On 21/01/16 11:12, Andreas Krebbel wrote:

On 01/15/2016 10:08 PM, Marcin Kościelnicki wrote:

On 15/01/16 19:38, Andreas Krebbel wrote:

Marcin,

your implementation looks very good to me. Thanks!

But please be aware that we deprecated the support of g5 and g6 and intend to 
remove that code from
the back-end with the next GCC version.  So I would prefer if you could remove 
all the
!TARGET_CPU_ZARCH stuff from the implementation and just error out if 
split-stack is enabled with
-march g5/g6.  It currently makes the implementation more complicated and would 
have to be removed
anyway in the future.

Thanks!

https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01854.html


Bye,

-Andreas-




Very well, I'll do that.

Btw, as for dropping support for g5/g6: I've noticed
s390_function_profiler could also use larl+brasl for -m31 given
TARGET_CPU_ZARCH.  Should I submit a patch for that?  I'm asking because
gold with -fsplit-stack needs to know the exact sequence used, so if
it's going to change after g5/g6 removal, I'd better add it to gold now
(and make gcc always emit it for non-g5/g6, so that gold won't need to
look at the old one).


Yes please, that would be great. Good catch!

Thanks!

-Andreas-



I've submitted the gcc patch, and will soon update the gold patch.

Marcin Kościelnicki

[PATCH] s390: New mcount call sequence for z900+ CPUs in 31-bit mode.

[Marcin Kościelnicki]

On TARGET_CPU_ZARCH && !TARGET_64BIT, we can use a similiar lean mcount
call sequence to TARGET_64BIT.  The longer sequences are now used only
on deprecated g5/g6 CPUs.

Tested on s390-ibm-linux-gnu on RHEL 7.2.

gcc/ChangeLog:

* config/s390/s390.c (s390_function_profiler): Add a new sequence
for z900+ CPUs in 31-bit mode.
---
This change was mentioned in the s390 split-stack thread.

 gcc/ChangeLog  | 5 +
 gcc/config/s390/s390.c | 7 +++
 2 files changed, 12 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 0e77409..94b9bd0 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2016-01-21  Marcin Kościelnicki  
+
+   * config/s390/s390.c (s390_function_profiler): Add a new sequence
+   for z900+ CPUs in 31-bit mode.
+
 2016-01-21  Richard Biener  
 
* graphite-optimize-isl.c (get_schedule_map): Fix typo.
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 3be64de..eb26f18 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -11974,6 +11974,13 @@ s390_function_profiler (FILE *file, int labelno)
   output_asm_insn ("brasl\t%0,%4", op);
   output_asm_insn ("lg\t%0,%1", op);
 }
+  else if (TARGET_CPU_ZARCH)
+{
+  output_asm_insn ("st\t%0,%1", op);
+  output_asm_insn ("larl\t%2,%3", op);
+  output_asm_insn ("brasl\t%0,%4", op);
+  output_asm_insn ("l\t%0,%1", op);
+}
   else if (!flag_pic)
 {
   op[6] = gen_label_rtx ();
-- 
2.7.0

Re: [PATCH], PowerPC IEEE 128-bit fp, #11-rev4 (enable libgcc conversions)

[David Edelsohn]

On Wed, Jan 20, 2016 at 8:00 PM, Michael Meissner
 wrote:
> This is revision 4 of the IEEE 128-bit floating point libgcc support.
>
> Since revision 3, I have removed the gcc changes that broke AIX.  I rewrote 
> the
> IBM extended double pack/unpack support to not use the builtin functions, but
> instead uses a union.  The libgcc code that I wrote tickles a bug in the pack
> function.  While I would like to fix the pack function bug, I will need to 
> make
> sure I don't break AIX, so I didn't want to couple this library to getting
> those bugs fixed.
>
> I have also rewritten how the ifunc support is done, so that ifunc is only 
> done
> if the target assembler supports ISA 3.0 instructions AND the compiler 
> supports
> ifunc functions.  This is so that the compiler can build on 64-bit systems if
> --enable-gnu-indirect-function is not specified without the ifunc functions
> being flagged.
>
> I have done bootstraps on both a big endian power7 system and a little endian
> power8 with no regressions.  In addition, I have built a compiler explicitly
> disabling ifunc support, and it built and ran the ieee 128-bit floating point
> unit tests correctly.
>
> Can I install this into libgcc?
>
> Assuming I can install these changes, the one final change that I would like 
> to
> make is to enable float128 automatically on VSX powerpc Linux systems, but not
> on other systems (AIX, *BSD, etc.) since those systems do not build float128
> emulator functions.

What does "enable" mean?

> 2016-01-20  Michael Meissner  
> Steven Munroe 
> Tulio Magno Quites Machado Filho 
>
> * config/rs6000/float128-sed: New files to convert TF names to KF
> names for PowerPC IEEE 128-bit floating point support.
> * config/rs6000/float128-sed-hw: Likewise.
>
> * config/rs6000/float128-hw.c: New file for ISA 3.0 IEEE 128-bit
> floating point hardware support.
>
> * config/rs6000/float128-ifunc.c: New file to pick either IEEE
> 128-bit floating point software emulation or use ISA 3.0 hardware
> support if it is available.
>
> * config/rs6000/quad-float128.h: New file to support IEEE 128-bit
> floating point.
>
> * config/rs6000/extendkftf2-sw.c: New file, convert IEEE 128-bit
> floating point to IBM extended double.
>
> * config/rs6000/trunctfkf2-sw.c: New file, convert IBM extended
> double to IEEE 128-bit floating point.
>
> * config/rs6000/t-float128: New Makefile fragments to enable
> building __float128 emulation support.
> * config/rs6000/t-float128-hw: Likewise.
>
> * config/rs6000/sfp-exceptions.c: New file to provide exception
> support for IEEE 128-bit floating point.
>
> * config/rs6000/floattikf.c: New files for converting between IEEE
> 128-bit floating point and signed/unsigned 128-bit integers.
> * config/rs6000/fixunskfti.c: Likewise.
> * config/rs6000/fixkfti.c: Likewise.
> * config/rs6000/floatuntikf.c: Likewise.
>
> * config/rs6000/sfp-machine.h (_FP_W_TYPE_SIZE): Use 64-bit types
> when building on 64-bit systems, or when VSX is enabled.
> (_FP_W_TYPE): Likewise.
> (_FP_WS_TYPE): Likewise.
> (_FP_I_TYPE): Likewise.
> (TItype): Define on 64-bit systems.
> (UTItype): Likewise.
> (TI_BITS): Likewise.
> (_FP_MUL_MEAT_D): Add support for using 64-bit types.
> (_FP_MUL_MEAT_Q): Likewise.
> (_FP_DIV_MEAT_D): Likewise.
> (_FP_DIV_MEAT_Q): Likewise.
> (_FP_NANFRAC_D): Likewise.
> (_FP_NANFRAC_Q): Likewise.
> (ISA_BIT): Add exception support if we are being compiled on a
> machine with hardware floating point support to build the IEEE
> 128-bit emulation functions.
> (FP_EX_INVALID): Likewise.
> (FP_EX_OVERFLOW): Likewise.
> (FP_EX_UNDERFLOW): Likewise.
> (FP_EX_DIVZERO): Likewise.
> (FP_EX_INEXACT): Likewise.
> (FP_EX_ALL): Likewise.
> (__sfp_handle_exceptions): Likewise.
> (FP_HANDLE_EXCEPTIONS): Likewise.
> (FP_RND_NEAREST): Likewise.
> (FP_RND_ZERO): Likewise.
> (FP_RND_PINF): Likewise.
> (FP_RND_MINF): Likewise.
> (FP_RND_MASK): Likewise.
> (_FP_DECL_EX): Likewise.
> (FP_INIT_ROUNDMODE): Likewise.
> (FP_ROUNDMODE): Likewise.
>
> * libgcc/config.host (powerpc*-*-linux*): If compiler can compile
> VSX code, enable IEEE 128-bit floating point.  If the compiler can
> compile IEEE 128-bit floating point code with ISA 3.0 IEEE 128-bit
> floating point hardware instructions and it supports declaring
> functions with the ifunc attribute, enable ifunc functions to
> switch between software and hardware 

Re: [patch] Restore cross-language inlining into Ada

[Richard Biener]

On Thu, Jan 21, 2016 at 3:13 PM, Jan Hubicka  wrote:
>> On Wed, Jan 20, 2016 at 9:32 AM, Eric Botcazou  wrote:
>> > Hi,
>> >
>> > this patch from Jan:
>> >   https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01388.html
>> > totally disabled cross-language inlining into Ada without notice, by 
>> > adding a
>> > check that always fails when the language of the callee is not Ada...
>> > The attached patch simply deletes this new check to restore the initial 
>> > state.
>
> I only updated
> -  /* Don't inline if the callee can throw non-call exceptions but the
> - caller cannot.
> - FIXME: this is obviously wrong for LTO where STRUCT_FUNCTION is missing.
> - Move the flag into cgraph node or mirror it in the inline summary.  */
> -  else if (callee_fun && callee_fun->can_throw_non_call_exceptions
> -  && !(caller_fun && caller_fun->can_throw_non_call_exceptions))
> -{
> -  e->inline_failed = CIF_NON_CALL_EXCEPTIONS;
> -  inlinable = false;
> -}
> to actually work with LTO where callee_fun/caller_fun is not always available
> (but sometimes, like when ICF requested the body or when we merged profiles, 
> it
> is).
>
>> >
>> > Tested on x86_64-suse-linux, OK for the mainline?
>>
>> I think the intent was to allow inlining a non-throwing -fnon-call-exceptions
>> function into a not -fnon-call-exceptions function but _not_ a
>> non-throwing not -fnon-call-exceptions function (that "not-throwing" is
>> basically a non-sensible test) into a -fnon-call-exceptions function
>> because that may now miss EH edges.
>>
>> So the test looks conservatively correct to me - we can't reliably
>> check whether the callee throws if the IL now were -fnon-call-exceptions
>> (which we know the caller is after !opt_for_fn (callee->decl,
>> flag_non_call_exceptions)
>>
>> So - this doesn't look correct to me.
>>
>> OTOH
>>
>> static inline int foo (int a, int *b)
>> {
>>   return a / *b;
>> }
>>
>> int __attribute__((optimize("non-call-exceptions")))
>> bar (int *p, int *b)
>> {
>>   try
>> {
>>   return foo (*p, b);
>> }
>>   catch (...)
>> {
>>   return 0;
>> }
>> }
>>
>> happily inlines foo with your patch but doesn't ICE during stmt verification.
>>
>> So maybe we're not verifying that "correctness" part - ah, yeah, I think
>> we changed it to only verify EH tree vs. stmt consistency but not the
>> other way around.
>
> Well, it is a while since I looked deeper into EH code, but if I remember
> correctly we have EH region associated with statements and the non-call
> exceptions do not have EH region that is taken by EH code as an information
> that the statement was proved to not throw? In that case inlining could be
> safe, if the inlined statements are not placed in EH region (I think inliner
> does that)
>
> So perhaps this inlining is always safe?

That's what I think.

Richard.

> Honza

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

[Wilco Dijkstra]

James Greenhalgh  wrote:
> If we don't have any targets which care about the fccmps/fccmpd split in
> the code base, do we really need it? Can we just follow the example of
> fcsel?

If we do that then we should also change fcmps/d to fcmp to keep the f(c)cmp
attributes orthogonal. However it seems better to have all FP operations use
{s|d} postfix as the convention (rather than assume that all current and future
microarchitectures will treat float and double identically on all operations),
so fcsel should ideally be fixed.

Wilco

Re: [patch] libstdc++/69386 Ensure C++ language linkage in cmath and cstdlib

[Jonathan Wakely]

On 21/01/16 10:27 +0100, Dominique d'Humières wrote:

Jonathan,

PR libstdc++/69386
* include/c_global/ccomplex: Ensure C++ language linkage.
* include/c_global/cmath: Likewise.
* include/c_global/cstdlib: Likewise.
* include/c_global/ctgmath: Likewise.
* testsuite/17_intro/headers/c++2011/linkage.cc: New.


The test  testsuite/17_intro/headers/c++2011/linkage.cc fails on darwin

/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++2011/linkage.cc:47:19: 
fatal error: uchar.h: No such file or directory


I should have been checking which headers are actually supported,
fixed like this. This also adds extern "C++" to some more headers, so
that the order of including  and  doesn't matter.

Tested powerpc64le-linux, committed to trunk.

commit 77a9e07d731a90aceb17f6fded227003b1c9c510
Author: Jonathan Wakely 
Date:   Thu Jan 21 13:07:01 2016 +

libstdc++/69406 Fix test to check for supported headers

	PR libstdc++/69406
	* include/bits/cpp_type_traits.h: Ensure C++ language linkage.
	* include/ext/type_traits.h: Likewise.
	* testsuite/17_intro/headers/c++2011/linkage.cc: Check autoconf macros
	for presence of C headers.
	* testsuite/ext/type_traits/add_unsigned_floating_neg.cc: Adjust
	dg-error line number.
	* testsuite/ext/type_traits/add_unsigned_integer_neg.cc: Likewise.
	* testsuite/ext/type_traits/remove_unsigned_floating_neg.cc: Likewise.
	* testsuite/ext/type_traits/remove_unsigned_integer_neg.cc: Likewise.

diff --git a/libstdc++-v3/include/bits/cpp_type_traits.h b/libstdc++-v3/include/bits/cpp_type_traits.h
index 3b188d4..fff1e99 100644
--- a/libstdc++-v3/include/bits/cpp_type_traits.h
+++ b/libstdc++-v3/include/bits/cpp_type_traits.h
@@ -64,6 +64,8 @@
 // removed.
 //
 
+extern "C++" {
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -408,5 +410,6 @@ __INT_N(__GLIBCXX_TYPE_INT_N_3)
 
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace
+} // extern "C++"
 
 #endif //_CPP_TYPE_TRAITS_H
diff --git a/libstdc++-v3/include/ext/type_traits.h b/libstdc++-v3/include/ext/type_traits.h
index 0a4f425..dd27657 100644
--- a/libstdc++-v3/include/ext/type_traits.h
+++ b/libstdc++-v3/include/ext/type_traits.h
@@ -34,6 +34,8 @@
 #include 
 #include 
 
+extern "C++" {
+
 namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -214,5 +216,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace
+} // extern "C++"
 
 #endif 
diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++2011/linkage.cc b/libstdc++-v3/testsuite/17_intro/headers/c++2011/linkage.cc
index 33e7053..67c384b 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++2011/linkage.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++2011/linkage.cc
@@ -20,15 +20,23 @@
 
 // libstdc++/69386
 
+#include 
+
 extern "C"
 {
 #include 
+#ifdef _GLIBCXX_HAVE_COMPLEX_H
 #include 
+#endif
 #include 
 #include 
+#ifdef _GLIBCXX_HAVE_FENV_H
 #include 
+#endif
 #include 
+#ifdef _GLIBCXX_HAVE_INTTYPES_H
 #include 
+#endif
 #include 
 #include 
 #include 
@@ -36,15 +44,27 @@ extern "C"
 #include 
 #include 
 #include 
+#ifdef _GLIBCXX_HAVE_STDBOOL_H
 #include 
+#endif
 #include 
+#ifdef _GLIBCXX_HAVE_STDINT_H
 #include 
+#endif
 #include 
 #include 
 #include 
+#ifdef _GLIBCXX_HAVE_TGMATH_H
 #include 
+#endif
 #include 
+#if __has_include()
 #include 
+#endif
+#ifdef _GLIBCXX_HAVE_WCHAR_H
 #include 
+#endif
+#ifdef _GLIBCXX_HAVE_WCTYPE_H
 #include 
+#endif
 }
diff --git a/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_floating_neg.cc b/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_floating_neg.cc
index f0c48d0..09d2c7c 100644
--- a/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_floating_neg.cc
+++ b/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_floating_neg.cc
@@ -35,4 +35,4 @@ int main()
 }
 
 // { dg-error "required from" "" { target *-*-* } 28 }
-// { dg-error "no type" "" { target *-*-* } 69 } 
+// { dg-error "no type" "" { target *-*-* } 71 } 
diff --git a/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_integer_neg.cc b/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_integer_neg.cc
index cee08a3..567684e 100644
--- a/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_integer_neg.cc
+++ b/libstdc++-v3/testsuite/ext/type_traits/add_unsigned_integer_neg.cc
@@ -36,5 +36,5 @@ int main()
 }
 
 // { dg-error "invalid use of incomplete" "" { target *-*-* } 28 } 
-// { dg-error "declaration of" "" { target *-*-* } 98 }
-// { dg-error "declaration of" "" { target *-*-* } 101 }
+// { dg-error "declaration of" "" { target *-*-* } 100 }
+// { dg-error "declaration of" "" { target *-*-* } 103 }
diff --git a/libstdc++-v3/testsuite/ext/type_traits/remove_unsigned_floating_neg.cc b/libstdc++-v3/testsuite/ext/type_traits/remove_unsigned_floating_neg.cc
index 98ba8a6..c946a4f 100644
--- a/libstdc++-v3/testsuite/ext/type_traits/remove_unsigned_floating_neg.cc

Re: RFA: MIPS: Fix race condition causing PR 69129

[Nick Clifton]

Hi Matthias,


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

this fixes the bootstrap errors for me, seen in both libgnat and libgfortran.


Great - I have gone ahead and checked the patch in.

Cheers
  Nick

Re: [patch] libstdc++/69386 Ensure C++ language linkage in cmath and cstdlib

[Jonathan Wakely]

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

--- a/libstdc++-v3/include/c_global/ccomplex
+++ b/libstdc++-v3/include/c_global/ccomplex
@@ -35,6 +35,8 @@
# include 
#endif

+extern "C++" {
#include 
+}


P.S. I would have preferred not to do this around  and add
the linkage specification inside , but that would also mean
adding it inside , which includes the entire iostream
hierarchy and  and bits/stl_algobase.h and lots of other
headers. Maybe I'll clean that up in stage 1 but it's a big patch.

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Torvald Riegel]

On Thu, 2016-01-21 at 11:00 +0100, Dominique d'Humières wrote:
> Torvald,
> 
> Now that I can bootstrap on darwin, I have found the following failure for 
> libitm.c++/libstdc++-safeexc.C
> 
> /opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
> unsafe function call 'std::underflow_error::underflow_error(const string&)' 
> within atomic transaction
>   throw T (what);
>   ^

Well, yes, that's my oversight.  The previous fix disabled the support,
so we need to now xfail or disable this test on Darwin.  Same for AIX.
Ignore these failures for now.  I'll work on a fix.

Re: TR29124 C++ Special Maths - Make pull functions into global namespace.

[Jonathan Wakely]

On 20/01/16 20:30 -0500, Ed Smith-Rowland wrote:
Now that libstdc++ installs a proper math.h we can piggyback on that 
to put in the last bit of TR29124.


This patch adds the math special functions to c_compatibility/math.h 
in the global namespace.

I remove the XFAILs from the compile_2.cc tests.

This converts 21 XFAILs into 21 PASSes.

Tested on x86_64-linux.

I understand if this is too late.
I'll put it up on trunk and backport after stage 1 reopens.

Meanwhile I'll commit this to the tr29124 branch.


I'm inclined to say the change is OK for trunk now. We've added math.h
and we've added the special functions, it would be good if the two new
things work together.

However ...


Index: include/c_compatibility/math.h
===
--- include/c_compatibility/math.h  (revision 232610)
+++ include/c_compatibility/math.h  (working copy)
@@ -75,70 +75,71 @@
#endif

#if __STDCPP_WANT_MATH_SPEC_FUNCS__ == 1
-using std::assoc_laguerref


This doesn't look like the right patch, because these lines aren't in
the version on trunk.

[PATCH] Fix buffer overflow in the arm port (PR target/69187)

[Jakub Jelinek]

Hi!

This is the same issue that has been fixed a while ago in the aarch64 port
as PR65624.  Bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?

2016-01-21   Stefan Sørensen  
 Jakub Jelinek  

PR target/69187
PR target/65624
* config/arm/arm-builtins.c (arm_expand_neon_builtin): Increase
args array size by one to avoid buffer overflow.

* gcc.target/arm/pr69187.c: New test.

--- gcc/config/arm/arm-builtins.c.jj2016-01-15 20:37:31.0 +0100
+++ gcc/config/arm/arm-builtins.c   2016-01-20 09:04:40.121275057 +0100
@@ -2246,7 +2246,7 @@ arm_expand_neon_builtin (int fcode, tree
   neon_builtin_datum *d =
_builtin_data[fcode - ARM_BUILTIN_NEON_PATTERN_START];
   enum insn_code icode = d->code;
-  builtin_arg args[SIMD_MAX_BUILTIN_ARGS];
+  builtin_arg args[SIMD_MAX_BUILTIN_ARGS + 1];
   int num_args = insn_data[d->code].n_operands;
   int is_void = 0;
   int k;
--- gcc/testsuite/gcc.target/arm/pr69187.c.jj   2016-01-20 09:02:53.832778539 
+0100
+++ gcc/testsuite/gcc.target/arm/pr69187.c  2016-01-20 09:03:26.132321652 
+0100
@@ -0,0 +1,19 @@
+/* PR target/69187 */
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_neon } */
+/* { dg-options "-O0" }  */
+/* { dg-add-options arm_neon }  */
+
+#include 
+
+int32x4_t
+foo (void)
+{
+  int32x4_t vector_int32x4;
+  int16x4_t vector3_int16x4;
+  int16x4_t vector4_int16x4;
+  static int32_t buffer_int32x4[32];
+
+  vector_int32x4 = vld1q_s32(buffer_int32x4);
+  return vqdmlsl_lane_s16(vector_int32x4, vector3_int16x4, vector4_int16x4, 0);
+}

Jakub

Re: [patch] libstdc++/69386 Ensure C++ language linkage in cmath and cstdlib

[Dominique d'Humières]

Jonathan,
> PR libstdc++/69386
> * include/c_global/ccomplex: Ensure C++ language linkage.
> * include/c_global/cmath: Likewise.
> * include/c_global/cstdlib: Likewise.
> * include/c_global/ctgmath: Likewise.
> * testsuite/17_intro/headers/c++2011/linkage.cc: New.

The test  testsuite/17_intro/headers/c++2011/linkage.cc fails on darwin

/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++2011/linkage.cc:47:19: 
fatal error: uchar.h: No such file or directory

TIA

Dominique

Re: [PATCH] Fix buffer overflow in the arm port (PR target/69187)

[Kyrill Tkachov]

On 21/01/16 09:20, Jakub Jelinek wrote:

Hi!

This is the same issue that has been fixed a while ago in the aarch64 port
as PR65624.  Bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?


Ok, thanks for taking care of this.
Kyrill


2016-01-21   Stefan Sørensen  
 Jakub Jelinek  

PR target/69187
PR target/65624
* config/arm/arm-builtins.c (arm_expand_neon_builtin): Increase
args array size by one to avoid buffer overflow.

* gcc.target/arm/pr69187.c: New test.

--- gcc/config/arm/arm-builtins.c.jj2016-01-15 20:37:31.0 +0100
+++ gcc/config/arm/arm-builtins.c   2016-01-20 09:04:40.121275057 +0100
@@ -2246,7 +2246,7 @@ arm_expand_neon_builtin (int fcode, tree
neon_builtin_datum *d =
_builtin_data[fcode - ARM_BUILTIN_NEON_PATTERN_START];
enum insn_code icode = d->code;
-  builtin_arg args[SIMD_MAX_BUILTIN_ARGS];
+  builtin_arg args[SIMD_MAX_BUILTIN_ARGS + 1];
int num_args = insn_data[d->code].n_operands;
int is_void = 0;
int k;
--- gcc/testsuite/gcc.target/arm/pr69187.c.jj   2016-01-20 09:02:53.832778539 
+0100
+++ gcc/testsuite/gcc.target/arm/pr69187.c  2016-01-20 09:03:26.132321652 
+0100
@@ -0,0 +1,19 @@
+/* PR target/69187 */
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_neon } */
+/* { dg-options "-O0" }  */
+/* { dg-add-options arm_neon }  */
+
+#include 
+
+int32x4_t
+foo (void)
+{
+  int32x4_t vector_int32x4;
+  int16x4_t vector3_int16x4;
+  int16x4_t vector4_int16x4;
+  static int32_t buffer_int32x4[32];
+
+  vector_int32x4 = vld1q_s32(buffer_int32x4);
+  return vqdmlsl_lane_s16(vector_int32x4, vector3_int16x4, vector4_int16x4, 0);
+}

Jakub

Re: [PATCH 4/5] Don't mark targets of unconditional jumps with side effects as FALLTHRU.

[Marcin Kościelnicki]

On 21/01/16 11:05, Andreas Krebbel wrote:

On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:

When an unconditional jump with side effects targets an immediately
following label, rtl_tidy_fallthru_edge is called.  Since it has side
effects, it doesn't remove the jump, but the label is still marked
as fallthru.  This later causes a verification error.  Do nothing in this
case instead.

gcc/ChangeLog:

* cfgrtl.c (rtl_tidy_fallthru_edge): Bail for unconditional jumps
with side effects.


The change looks ok to me (although I'm not able to approve it). Could you 
please run regressions
tests on x86_64 with that change?

Perhaps a short comment in the code would be good.

-Andreas-



OK, I'll run the testsuite and add a comment.

Re: [PATCH 2/5] s390: Fix missing .size directives.

[Marcin Kościelnicki]

On 21/01/16 10:58, Andreas Krebbel wrote:

On 01/20/2016 02:16 PM, Andreas Krebbel wrote:

On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:

It seems at some point the .size hook was hijacked to emit some
machine-specific directives, and the actual .size directive was
forgotten.  This caused problems for split-stack support, since
linker couldn't scan the function body for non-split-stack calls.

gcc/ChangeLog:

* config/s390/s390.c (s390_asm_declare_function_size): Add code
to actually emit the .size directive.


...


  s390_asm_declare_function_size (FILE *asm_out_file,
-   const char *fnname ATTRIBUTE_UNUSED, tree decl)
+   const char *fnname, tree decl)
  {
+  if (!flag_inhibit_size_directive)
+ASM_OUTPUT_MEASURED_SIZE (asm_out_file, fnname);
if (DECL_FUNCTION_SPECIFIC_TARGET (decl) == NULL)
  return;
fprintf (asm_out_file, "\t.machine pop\n");


It would be good to use the original ASM_DECLARE_FUNCTION_SIZE macro from 
config/elfos.h here.  This
probably would require to change its name in s390.h first and then use it from
s390_asm_declare_function_size. Not really beautiful but at least changes to 
the original macro
would not require adjusting our backend.


I've looked into how the other archs are doing this and didn't find anything 
better than just
including the code from the original macro. The real fix probably would be to 
turn this into a
target hook instead.

I've committed the patch now since it fixes a real problem not only with 
split-stack.

Thanks!

-Andreas-



I did a version that reincludes elfos.h, but it didn't finish testing 
(it made it through bootstrap) before you applied the patch:


diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 21a5687..c56b909 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -6832,10 +6832,17 @@ s390_asm_output_function_prefix (FILE *asm_out_file,

 /* Write an extra function footer after the very end of the function.  */

+/* Get elfos.h's original ASM_DECLARE_FUNCTION_SIZE, so that we can 
delegate

+   to it below.  */
+
+#undef ASM_DECLARE_FUNCTION_SIZE
+#include "../elfos.h"
+
 void
 s390_asm_declare_function_size (FILE *asm_out_file,
-   const char *fnname ATTRIBUTE_UNUSED, 
tree decl)

+   const char *fnname, tree decl)
 {
+  ASM_DECLARE_FUNCTION_SIZE(asm_out_file, fnname, decl);
   if (DECL_FUNCTION_SPECIFIC_TARGET (decl) == NULL)
 return;
   fprintf (asm_out_file, "\t.machine pop\n");


But, this is much uglier, and the macro is very unlikely to change in 
the first place.  I guess we should stay with the applied patch.


Thanks,

Marcin

Re: [PATCH 1/5] s390: Use proper read-only data section for literals.

[Mike Stump]

On Jan 20, 2016, at 10:56 PM, Marcin Kościelnicki  wrote:
>> This is ok if bootstrap and regression tests are clean. Thanks!

> The bootstrap and regression tests are indeed clean for this patch and #2.  I 
> don't have commit access to gcc repo, how do I get this pushed?

Just ask someone to apply it for you.

Re: [PATCH 1/5] s390: Use proper read-only data section for literals.

[Andreas Krebbel]

On 01/21/2016 07:56 AM, Marcin Kościelnicki wrote:
>>> +2016-01-02  Marcin Kościelnicki  
>>> +
>>> +   * config/s390/s390.md (pool_section_start): Use switch_to_section
>>> +   to select proper read-only data section instead of hardcoding .rodata.
>>> +   (pool_section_end): Use switch_to_section to match the above.
>>> +
>>
>> This is ok if bootstrap and regression tests are clean. Thanks!
>>
>> -Andreas-
>>
>>
> 
> The bootstrap and regression tests are indeed clean for this patch and 
> #2.  I don't have commit access to gcc repo, how do I get this pushed?

Committed to mainline. Thanks!

-Andreas-

Re: [PATCH 2/5] s390: Fix missing .size directives.

[Andreas Krebbel]

On 01/20/2016 02:16 PM, Andreas Krebbel wrote:
> On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:
>> It seems at some point the .size hook was hijacked to emit some
>> machine-specific directives, and the actual .size directive was
>> forgotten.  This caused problems for split-stack support, since
>> linker couldn't scan the function body for non-split-stack calls.
>>
>> gcc/ChangeLog:
>>
>>  * config/s390/s390.c (s390_asm_declare_function_size): Add code
>>  to actually emit the .size directive.
> 
> ...
> 
>>  s390_asm_declare_function_size (FILE *asm_out_file,
>> -const char *fnname ATTRIBUTE_UNUSED, tree decl)
>> +const char *fnname, tree decl)
>>  {
>> +  if (!flag_inhibit_size_directive)
>> +ASM_OUTPUT_MEASURED_SIZE (asm_out_file, fnname);
>>if (DECL_FUNCTION_SPECIFIC_TARGET (decl) == NULL)
>>  return;
>>fprintf (asm_out_file, "\t.machine pop\n");
> 
> It would be good to use the original ASM_DECLARE_FUNCTION_SIZE macro from 
> config/elfos.h here.  This
> probably would require to change its name in s390.h first and then use it from
> s390_asm_declare_function_size. Not really beautiful but at least changes to 
> the original macro
> would not require adjusting our backend.

I've looked into how the other archs are doing this and didn't find anything 
better than just
including the code from the original macro. The real fix probably would be to 
turn this into a
target hook instead.

I've committed the patch now since it fixes a real problem not only with 
split-stack.

Thanks!

-Andreas-

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Dominique d'Humières]

Torvald,

Now that I can bootstrap on darwin, I have found the following failure for 
libitm.c++/libstdc++-safeexc.C

/opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
unsafe function call 'std::underflow_error::underflow_error(const string&)' 
within atomic transaction
  throw T (what);
  ^

/opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
unsafe function call 'std::overflow_error::overflow_error(const string&)' 
within atomic transaction
  throw T (what);
  ^

/opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
unsafe function call 'std::range_error::range_error(const string&)' within 
atomic transaction
  throw T (what);
  ^

/opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
unsafe function call 'std::runtime_error::runtime_error(const string&)' within 
atomic transaction
  throw T (what);
  ^

/opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
unsafe function call 'std::out_of_range::out_of_range(const string&)' within 
atomic transaction
  throw T (what);
  ^

/opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
unsafe function call 'std::length_error::length_error(const string&)' within 
atomic transaction
  throw T (what);
  ^

/opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
unsafe function call 'std::invalid_argument::invalid_argument(const string&)' 
within atomic transaction
  throw T (what);
  ^

/opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
unsafe function call 'std::domain_error::domain_error(const string&)' within 
atomic transaction
  throw T (what);
  ^

/opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
unsafe function call 'std::logic_error::logic_error(const string&)' within 
atomic transaction
  throw T (what);
  ^

TIA

Dominique

> Le 19 janv. 2016 à 20:20, Jonathan Wakely  a écrit :
> 
> On 19/01/16 20:10 +0100, Torvald Riegel wrote:
>> On Sat, 2016-01-16 at 10:57 +0100, Dominique d'Humières wrote:
>>> > Addressed these, fixed a problem with using GLIBCXX_WEAK_DEFINITION
>>> > (which is only set on Darwin despite the generic-sounding name -- so
>>> > just use __attribute__((weak)) directly), and also updated
>>> > testsuite_abi.cc so that it knows about CXXABI_1.3.10.
>>> >
>>> > Approved by Jonathan Wakely.  Committed as r232454.
>>> This breaks bootstrap on darwin, see 
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310.
>> 
>> Please give this patch a try.  I've only tested it on x86_64-linux.
>> Jon, okay from your side if Darwin testing succeeds?
> 
> Yes, OK.

Re: [PATCH 5/5] s390: Add -fsplit-stack support

[Andreas Krebbel]

On 01/15/2016 10:08 PM, Marcin Kościelnicki wrote:
> On 15/01/16 19:38, Andreas Krebbel wrote:
>> Marcin,
>>
>> your implementation looks very good to me. Thanks!
>>
>> But please be aware that we deprecated the support of g5 and g6 and intend 
>> to remove that code from
>> the back-end with the next GCC version.  So I would prefer if you could 
>> remove all the
>> !TARGET_CPU_ZARCH stuff from the implementation and just error out if 
>> split-stack is enabled with
>> -march g5/g6.  It currently makes the implementation more complicated and 
>> would have to be removed
>> anyway in the future.
>>
>> Thanks!
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01854.html
>>
>>
>> Bye,
>>
>> -Andreas-
>>
>>
> 
> Very well, I'll do that.
> 
> Btw, as for dropping support for g5/g6: I've noticed 
> s390_function_profiler could also use larl+brasl for -m31 given 
> TARGET_CPU_ZARCH.  Should I submit a patch for that?  I'm asking because 
> gold with -fsplit-stack needs to know the exact sequence used, so if 
> it's going to change after g5/g6 removal, I'd better add it to gold now 
> (and make gcc always emit it for non-g5/g6, so that gold won't need to 
> look at the old one).

Yes please, that would be great. Good catch!

Thanks!

-Andreas-

Re: [PATCH, GCC] Fix PR67781: wrong code generation for partial load on big endian targets

[Thomas Preud'homme]

On Thursday, January 21, 2016 09:21:52 AM Richard Biener wrote:
> On Thu, 21 Jan 2016, Thomas Preud'homme wrote:
> > On Friday, January 08, 2016 10:05:25 AM Richard Biener wrote:
> > > On Tue, 5 Jan 2016, Thomas Preud'homme wrote:
> > > > Hi,
> > > > 
> > > > bswap optimization pass generate wrong code on big endian targets when
> > > > the
> > > > result of a bit operation it analyzed is a partial load of the range
> > > > of
> > > > memory accessed by the original expression (when one or more bytes at
> > > > lowest address were lost in the computation). This is due to the way
> > > > cmpxchg and cmpnop are adjusted in find_bswap_or_nop before being
> > > > compared to the result of the symbolic expression. Part of the
> > > > adjustment
> > > > is endian independent: it's to ignore the bytes that were not accessed
> > > > by
> > > > the original gimple expression. However, when the result has less byte
> > > > than that original expression, some more byte need to be ignored and
> > > > this
> > > > is endian dependent.
> > > > 
> > > > The current code only support loss of bytes at the highest addresses
> > > > because there is no code to adjust the address of the load. However,
> > > > for
> > > > little and big endian targets the bytes at highest address translate
> > > > into
> > > > different byte significance in the result. This patch first separate
> > > > cmpxchg and cmpnop adjustement into 2 steps and then deal with
> > > > endianness
> > > > correctly for the second step.
> > > > 
> > > > ChangeLog entries are as follow:
> > > > 
> > > > 
> > > > *** gcc/ChangeLog ***
> > > > 
> > > > 2015-12-16  Thomas Preud'homme  
> > > > 
> > > > PR tree-optimization/67781
> > > > * tree-ssa-math-opts.c (find_bswap_or_nop): Zero out bytes in
> > > > cmpxchg
> > > > and cmpnop in two steps: first the ones not accessed in
> > > > original
> > > > gimple expression in a endian independent way and then the
> > > > ones
> > > > not
> > > > accessed in the final result in an endian-specific way.
> > > > 
> > > > *** gcc/testsuite/ChangeLog ***
> > > > 
> > > > 2015-12-16  Thomas Preud'homme  
> > > > 
> > > > PR tree-optimization/67781
> > > > * gcc.c-torture/execute/pr67781.c: New file.
> > > > 
> > > > diff --git a/gcc/testsuite/gcc.c-torture/execute/pr67781.c
> > > > b/gcc/testsuite/gcc.c-torture/execute/pr67781.c
> > > > new file mode 100644
> > > > index 000..bf50aa2
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/gcc.c-torture/execute/pr67781.c
> > > > @@ -0,0 +1,34 @@
> > > > +#ifdef __UINT32_TYPE__
> > > > +typedef __UINT32_TYPE__ uint32_t;
> > > > +#else
> > > > +typedef unsigned uint32_t;
> > > > +#endif
> > > > +
> > > > +#ifdef __UINT8_TYPE__
> > > > +typedef __UINT8_TYPE__ uint8_t;
> > > > +#else
> > > > +typedef unsigned char uint8_t;
> > > > +#endif
> > > > +
> > > > +struct
> > > > +{
> > > > +  uint32_t a;
> > > > +  uint8_t b;
> > > > +} s = { 0x123456, 0x78 };
> > > > +
> > > > +int pr67781()
> > > > +{
> > > > +  uint32_t c = (s.a << 8) | s.b;
> > > > +  return c;
> > > > +}
> > > > +
> > > > +int
> > > > +main ()
> > > > +{
> > > > +  if (sizeof (uint32_t) * __CHAR_BIT__ != 32)
> > > > +return 0;
> > > > +
> > > > +  if (pr67781 () != 0x12345678)
> > > > +__builtin_abort ();
> > > > +  return 0;
> > > > +}
> > > > diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
> > > > index b00f046..e5a185f 100644
> > > > --- a/gcc/tree-ssa-math-opts.c
> > > > +++ b/gcc/tree-ssa-math-opts.c
> > > > @@ -2441,6 +2441,8 @@ find_bswap_or_nop_1 (gimple *stmt, struct
> > > > symbolic_number *n, int limit)
> > > > 
> > > >  static gimple *
> > > >  find_bswap_or_nop (gimple *stmt, struct symbolic_number *n, bool
> > > >  *bswap)
> > > >  {
> > > > 
> > > > +  unsigned rsize;
> > > > +  uint64_t tmpn, mask;
> > > > 
> > > >  /* The number which the find_bswap_or_nop_1 result should match in
> > > >  order
> > > >  
> > > > to have a full byte swap.  The number is shifted to the right
> > > > according to the size of the symbolic number before using it.  */
> > > > 
> > > > @@ -2464,24 +2466,38 @@ find_bswap_or_nop (gimple *stmt, struct
> > > > symbolic_number *n, bool *bswap)
> > > > 
> > > >/* Find real size of result (highest non-zero byte).  */
> > > >if (n->base_addr)
> > > > 
> > > > -{
> > > > -  int rsize;
> > > > -  uint64_t tmpn;
> > > > -
> > > > -  for (tmpn = n->n, rsize = 0; tmpn; tmpn >>= BITS_PER_MARKER,
> > > > rsize++); -  n->range = rsize;
> > > > -}
> > > > +for (tmpn = n->n, rsize = 0; tmpn; tmpn >>= BITS_PER_MARKER,
> > > > rsize++);
> > > > +  else
> > > > +rsize = n->range;
> > > > 
> > > > -  /* Zero out the extra bits of N and CMP*.  */
> > > > +  /* Zero out the bits corresponding to untouched bytes in original
> > > > gimple
> > > > + expression.  */
> > > > 
> > > >  

Re: [PATCH, GCC] Fix PR67781: wrong code generation for partial load on big endian targets

[Richard Biener]

On Thu, 21 Jan 2016, Thomas Preud'homme wrote:

> On Friday, January 08, 2016 10:05:25 AM Richard Biener wrote:
> > On Tue, 5 Jan 2016, Thomas Preud'homme wrote:
> > > Hi,
> > > 
> > > bswap optimization pass generate wrong code on big endian targets when the
> > > result of a bit operation it analyzed is a partial load of the range of
> > > memory accessed by the original expression (when one or more bytes at
> > > lowest address were lost in the computation). This is due to the way
> > > cmpxchg and cmpnop are adjusted in find_bswap_or_nop before being
> > > compared to the result of the symbolic expression. Part of the adjustment
> > > is endian independent: it's to ignore the bytes that were not accessed by
> > > the original gimple expression. However, when the result has less byte
> > > than that original expression, some more byte need to be ignored and this
> > > is endian dependent.
> > > 
> > > The current code only support loss of bytes at the highest addresses
> > > because there is no code to adjust the address of the load. However, for
> > > little and big endian targets the bytes at highest address translate into
> > > different byte significance in the result. This patch first separate
> > > cmpxchg and cmpnop adjustement into 2 steps and then deal with endianness
> > > correctly for the second step.
> > > 
> > > ChangeLog entries are as follow:
> > > 
> > > 
> > > *** gcc/ChangeLog ***
> > > 
> > > 2015-12-16  Thomas Preud'homme  
> > > 
> > > PR tree-optimization/67781
> > > * tree-ssa-math-opts.c (find_bswap_or_nop): Zero out bytes in
> > > cmpxchg
> > > and cmpnop in two steps: first the ones not accessed in original
> > > gimple expression in a endian independent way and then the ones
> > > not
> > > accessed in the final result in an endian-specific way.
> > > 
> > > *** gcc/testsuite/ChangeLog ***
> > > 
> > > 2015-12-16  Thomas Preud'homme  
> > > 
> > > PR tree-optimization/67781
> > > * gcc.c-torture/execute/pr67781.c: New file.
> > > 
> > > diff --git a/gcc/testsuite/gcc.c-torture/execute/pr67781.c
> > > b/gcc/testsuite/gcc.c-torture/execute/pr67781.c
> > > new file mode 100644
> > > index 000..bf50aa2
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.c-torture/execute/pr67781.c
> > > @@ -0,0 +1,34 @@
> > > +#ifdef __UINT32_TYPE__
> > > +typedef __UINT32_TYPE__ uint32_t;
> > > +#else
> > > +typedef unsigned uint32_t;
> > > +#endif
> > > +
> > > +#ifdef __UINT8_TYPE__
> > > +typedef __UINT8_TYPE__ uint8_t;
> > > +#else
> > > +typedef unsigned char uint8_t;
> > > +#endif
> > > +
> > > +struct
> > > +{
> > > +  uint32_t a;
> > > +  uint8_t b;
> > > +} s = { 0x123456, 0x78 };
> > > +
> > > +int pr67781()
> > > +{
> > > +  uint32_t c = (s.a << 8) | s.b;
> > > +  return c;
> > > +}
> > > +
> > > +int
> > > +main ()
> > > +{
> > > +  if (sizeof (uint32_t) * __CHAR_BIT__ != 32)
> > > +return 0;
> > > +
> > > +  if (pr67781 () != 0x12345678)
> > > +__builtin_abort ();
> > > +  return 0;
> > > +}
> > > diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
> > > index b00f046..e5a185f 100644
> > > --- a/gcc/tree-ssa-math-opts.c
> > > +++ b/gcc/tree-ssa-math-opts.c
> > > @@ -2441,6 +2441,8 @@ find_bswap_or_nop_1 (gimple *stmt, struct
> > > symbolic_number *n, int limit)
> > > 
> > >  static gimple *
> > >  find_bswap_or_nop (gimple *stmt, struct symbolic_number *n, bool *bswap)
> > >  {
> > > 
> > > +  unsigned rsize;
> > > +  uint64_t tmpn, mask;
> > > 
> > >  /* The number which the find_bswap_or_nop_1 result should match in order
> > >  
> > > to have a full byte swap.  The number is shifted to the right
> > > according to the size of the symbolic number before using it.  */
> > > 
> > > @@ -2464,24 +2466,38 @@ find_bswap_or_nop (gimple *stmt, struct
> > > symbolic_number *n, bool *bswap)
> > > 
> > >/* Find real size of result (highest non-zero byte).  */
> > >if (n->base_addr)
> > > 
> > > -{
> > > -  int rsize;
> > > -  uint64_t tmpn;
> > > -
> > > -  for (tmpn = n->n, rsize = 0; tmpn; tmpn >>= BITS_PER_MARKER,
> > > rsize++); -  n->range = rsize;
> > > -}
> > > +for (tmpn = n->n, rsize = 0; tmpn; tmpn >>= BITS_PER_MARKER,
> > > rsize++);
> > > +  else
> > > +rsize = n->range;
> > > 
> > > -  /* Zero out the extra bits of N and CMP*.  */
> > > +  /* Zero out the bits corresponding to untouched bytes in original
> > > gimple
> > > + expression.  */
> > > 
> > >if (n->range < (int) sizeof (int64_t))
> > >
> > >  {
> > > 
> > > -  uint64_t mask;
> > > -
> > > 
> > >mask = ((uint64_t) 1 << (n->range * BITS_PER_MARKER)) - 1;
> > >cmpxchg >>= (64 / BITS_PER_MARKER - n->range) * BITS_PER_MARKER;
> > >cmpnop &= mask;
> > >  
> > >  }
> > > 
> > > +  /* Zero out the bits corresponding to unused bytes in the result of the
> > > + gimple 

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

[James Greenhalgh]

On Wed, Jan 06, 2016 at 02:44:47PM -0600, Evandro Menezes wrote:
> Hi, Wilco.
> 
> On 01/06/2016 06:04 AM, Wilco Dijkstra wrote:
> >>Here's what I had in mind when I inquired about distinguishing FCMP from
> >>FCCMP.  As you can see in the patch, Exynos is the only target that
> >>cares about it, but I wonder if ThunderX or Xgene would too.
> >>
> >>What do you think?
> >The new attributes look fine (I've got a similar outstanding change), however
> >please don't add them to non-AArch64 cores. We only need it for thunderx.md,
> >cortex-a53.md, cortex-a57.md, xgene1.md and exynos-m1.md.
> 
> Add support for the FCCMP insn types
> 
> 2016-01-04  Evandro Menezes  
> 
> gcc/
> * config/aarch64/aarch64.md (fccmp): Change insn type.
> (fccmpe): Likewise.
> * config/aarch64/thunderx.md (thunderx_fcmp): Add
>"fccmp{s,d}" types.
> * config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
> * config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
> * config/arm/xgene1.md (xgene1_fcmp): Likewise.
> * config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn
>reservation.
> * config/arm/types.md (fccmps): Add new insn type.
> (fccmpd): Likewise.
> 
> Got it.  Here's an updated patch.  Again, assuming that your
> original patch is in place.  Perhaps you can build on it.

If we don't have any targets which care about the fccmps/fccmpd split in
the code base, do we really need it? Can we just follow the example of
fcsel?

> diff --git a/gcc/config/arm/types.md b/gcc/config/arm/types.md
> index 321ff89..daf7162 100644
> --- a/gcc/config/arm/types.md
> +++ b/gcc/config/arm/types.md
> @@ -70,6 +70,7 @@
>  ; f_rint[d,s]double/single floating point rount to integral.
>  ; f_store[d,s]   double/single store to memory.  Used for VFP unit.
>  ; fadd[d,s]  double/single floating-point scalar addition.
> +; fccmp[d,s] double/single floating-point conditional compare.

Can we follow the convention fcsel uses of calling out "From ARMv8-A:"
for this type?

Thanks,
James

Re: [PATCH 4/5] Don't mark targets of unconditional jumps with side effects as FALLTHRU.

[Andreas Krebbel]

On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:
> When an unconditional jump with side effects targets an immediately
> following label, rtl_tidy_fallthru_edge is called.  Since it has side
> effects, it doesn't remove the jump, but the label is still marked
> as fallthru.  This later causes a verification error.  Do nothing in this
> case instead.
> 
> gcc/ChangeLog:
> 
>   * cfgrtl.c (rtl_tidy_fallthru_edge): Bail for unconditional jumps
>   with side effects.

The change looks ok to me (although I'm not able to approve it). Could you 
please run regressions
tests on x86_64 with that change?

Perhaps a short comment in the code would be good.

-Andreas-

Re: [PATCH 01/15] add more coalescing to simplify constraints

[Matthew Wahab]

On 15/01/16 17:14, Sebastian Pop wrote:

From: Sebastian Pop 

2015-12-30  Aditya Kumar  
Sebastian Pop  

* graphite-dependences.c (constrain_domain): Add call to isl_*_coalesce.
(add_pdr_constraints): Same.
(scop_get_reads): Same.
(scop_get_must_writes): Same.
(scop_get_may_writes): Same.
(scop_get_original_schedule): Same.
(extend_schedule): Same.
(apply_schedule_on_deps): Same.
(carries_deps): Same.
(compute_deps): Same.
(scop_get_dependences): Same.
* graphite-isl-ast-to-gimple.c
(translate_isl_ast_to_gimple::generate_isl_schedule): Same.
* graphite-optimize-isl.c (get_schedule_for_band): Same.
(get_schedule_for_band_list): Same.
(get_schedule_map): Same.
(apply_schedule_map_to_scop): Same.
* graphite-sese-to-poly.c (build_pbb_scattering_polyhedrons): Same.
(build_loop_iteration_domains): Same.
(add_condition_to_pbb): Same.
(add_param_constraints): Same.
(pdr_add_memory_accesses): Same.
(pdr_add_data_dimensions): Same.
---
  gcc/graphite-dependences.c   | 63 ++--
  gcc/graphite-isl-ast-to-gimple.c |  2 ++
  gcc/graphite-optimize-isl.c  | 12 
  gcc/graphite-sese-to-poly.c  | 28 --
  4 files changed, 56 insertions(+), 49 deletions(-)



diff --git a/gcc/graphite-optimize-isl.c b/gcc/graphite-optimize-isl.c
index 9626e96..15dd5b0 100644
--- a/gcc/graphite-optimize-isl.c
+++ b/gcc/graphite-optimize-isl.c

[..]

  static isl_union_map *
  get_schedule_map (isl_schedule *schedule)
  {
-  isl_band_list *bandList = isl_schedule_get_band_forest (schedule);
-  isl_union_map *schedule_map = get_schedule_for_band_list (bandList);
+  isl_band_list *band_list = isl_schedule_get_band_forest (schedule);
+  isl_union_map *schedule_map = get_schedule_for_band_list (band_list);
isl_band_list_free (bandList);
return schedule_map;
  }


Building arm-none-linux-gnueabihf fails at the isl_band_list_free. Shouldn't bandList 
be band_list?


Matthew

Re: [PATCH] OpenACC use_device clause ICE fix

[Chung-Lin Tang]

On 2016/1/20 09:17 PM, Bernd Schmidt wrote:
> On 01/05/2016 02:15 PM, Chung-Lin Tang wrote:
>> * omp-low.c (scan_sharing_clauses): Call add_local_decl() for
>> use_device/use_device_ptr variables.
> 
> It looks vaguely plausible, but if everything is part of the host
> function, why make a copy of the decl at all? I.e. what happens if you
> just remove the install_var_local call?

Because (only) inside the OpenMP context, the variable is supposed to
contain the device-side value; a runtime call is used to obtain the
value from the device back to host.  So a new variable is created, the
remap_decl mechanisms are used to change references inside the omp
context, and other references of the original variable are not touched.

Re: [PATCH] OpenACC use_device clause ICE fix

[Jakub Jelinek]

On Thu, Jan 21, 2016 at 10:22:19PM +0800, Chung-Lin Tang wrote:
> On 2016/1/20 09:17 PM, Bernd Schmidt wrote:
> > On 01/05/2016 02:15 PM, Chung-Lin Tang wrote:
> >> * omp-low.c (scan_sharing_clauses): Call add_local_decl() for
> >> use_device/use_device_ptr variables.
> > 
> > It looks vaguely plausible, but if everything is part of the host
> > function, why make a copy of the decl at all? I.e. what happens if you
> > just remove the install_var_local call?
> 
> Because (only) inside the OpenMP context, the variable is supposed to
> contain the device-side value; a runtime call is used to obtain the
> value from the device back to host.  So a new variable is created, the
> remap_decl mechanisms are used to change references inside the omp
> context, and other references of the original variable are not touched.

The patch looks wrong to me, the var shouldn't be actually used,
it is supposed to have DECL_VALUE_EXPR set for it during omp lowering and
the following gimplification is supposed to replace it.

I've tried the testcases you've listed and couldn't get an ICE, so, if you
see some ICE, can you mail the testcase (in patch form)?
Perhaps there is something wrong with the OpenACC lowering?

Jakub

Re: [patch] Restore cross-language inlining into Ada

[Jan Hubicka]

> >
> > Well, it is a while since I looked deeper into EH code, but if I remember
> > correctly we have EH region associated with statements and the non-call
> > exceptions do not have EH region that is taken by EH code as an information
> > that the statement was proved to not throw? In that case inlining could be
> > safe, if the inlined statements are not placed in EH region (I think inliner
> > does that)
> >
> > So perhaps this inlining is always safe?
> 
> That's what I think.
OK, as far as I can tell, Eric introduced the check in 
https://gcc.gnu.org/ml/gcc-patches/2010-05/msg01822.html

I am fine with it being relaxed and permitting inlining !non_call_exceptions to
non_call_exceptions functions..  It would be also cool to have a testcases.

Honza

[PATCH] Detangle gcc/configure for Darwin

[David Edelsohn]

A gcc/configure stanza to test for PowerPC mfcrf support became
tangled with Darwin test for .machine directive.  This patch detangles
and separates the two tests.

I don't have a Darwin system to test.

* configure.ac (gcc_cv_as_powerpc_mfcrf, gcc_cv_as_machine_directive): Detangle.

Okay?

Thanks, David

Index: configure.ac
===
--- configure.ac(revision 232675)
+++ configure.ac(working copy)
@@ -4172,10 +4172,8 @@
 ;;

   powerpc*-*-*)
+
 case $target in
-  *-*-aix*) conftest_s='   .machine "pwr5"
-   .csect .text[[PR]]
-   mfcr 3,128';;
   *-*-darwin*)
gcc_GAS_CHECK_FEATURE([.machine directive support],
  gcc_cv_as_machine_directive,,,
@@ -4185,7 +4183,14 @@
  echo you can get it from:
ftp://gcc.gnu.org/pub/gcc/infrastructure/cctools-528.5.dmg >&2
  test x$build = x$target && exit 1
fi
-   conftest_s='.text
+;;
+esac
+
+case $target in
+  *-*-aix*) conftest_s='   .machine "pwr5"
+   .csect .text[[PR]]
+   mfcr 3,128';;
+  *-*-darwin*) conftest_s='.text
mfcr r3,128';;
   *) conftest_s='  .machine power4
.text

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Torvald Riegel]

On Thu, 2016-01-21 at 11:00 +0100, Dominique d'Humières wrote:
> Torvald,
> 
> Now that I can bootstrap on darwin, I have found the following failure for 
> libitm.c++/libstdc++-safeexc.C
> 
> /opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
> unsafe function call 'std::underflow_error::underflow_error(const string&)' 
> within atomic transaction
>   throw T (what);
>   ^

Does this patch fix it (ie, mark the test unsupported)?
commit 259c0cf27d0a88eecc90af1aa500f88f6108cb04
Author: Torvald Riegel 
Date:   Thu Jan 21 16:21:33 2016 +0100

libitm: Disable testing transaction-safe exceptions on Darwin and AIX.

	* testsuite/libitm.c++/libstdc++-safeexc.C: Not supported on darwin
	or AIX.

diff --git a/libitm/testsuite/libitm.c++/libstdc++-safeexc.C b/libitm/testsuite/libitm.c++/libstdc++-safeexc.C
index 3e1655e..55ebd25 100644
--- a/libitm/testsuite/libitm.c++/libstdc++-safeexc.C
+++ b/libitm/testsuite/libitm.c++/libstdc++-safeexc.C
@@ -2,7 +2,10 @@
 // are indeed that.  Thus, this also tests the transactional clones in
 // libstdc++ and libsupc++.
 
-// { dg-do run }
+// Not supported on Darwin nor AIX because those lack the support for
+// weak references to undefined functions that we need in libstdc++ to make
+// exceptions transaction-safe.
+// { dg-do run { target { ! *-*-darwin* powerpc-ibm-aix* } } }
 
 #include 
 #include 

Re: gomp_target_fini

[Bernd Schmidt]

Thomas, I've mentioned this issue before - there is sometimes just too 
much irrelevant stuff to wade through in your patch submissions, and it 
discourages review. The discussion of the actual problem begins more 
than halfway through your multi-page mail. Please try to be more concise.


On 12/16/2015 01:30 PM, Thomas Schwinge wrote:

Now, with the above change installed, GOMP_PLUGIN_fatal will trigger the
atexit handler, gomp_target_fini, which, with the device lock held, will
call back into the plugin, GOMP_OFFLOAD_fini_device, which will try to
clean up.

Because of the earlier CUDA_ERROR_LAUNCH_FAILED, the associated CUDA
context is now in an inconsistent state



Thus, any cuMemFreeHost invocations that are run during clean-up will now
also/still return CUDA_ERROR_LAUNCH_FAILED, due to which we'll again call
GOMP_PLUGIN_fatal, which again will trigger the same or another
(GOMP_offload_unregister_ver) atexit handler, which will then deadlock
trying to lock the device again, which is still locked.



libgomp/
* error.c (gomp_vfatal): Call _exit instead of exit.


It seems unfortunate to disable the atexit handlers for everything for 
what seems purely an nvptx problem.


What exactly happens if you don't register the cleanups with atexit in 
the first place? Or maybe you can query for CUDA_ERROR_LAUNCH_FAILED in 
the cleanup functions?



Bernd

Re: [PATCH] OpenACC use_device clause ICE fix

[Bernd Schmidt]

On 01/21/2016 03:22 PM, Chung-Lin Tang wrote:

On 2016/1/20 09:17 PM, Bernd Schmidt wrote:

On 01/05/2016 02:15 PM, Chung-Lin Tang wrote:

 * omp-low.c (scan_sharing_clauses): Call add_local_decl() for
 use_device/use_device_ptr variables.


It looks vaguely plausible, but if everything is part of the host
function, why make a copy of the decl at all? I.e. what happens if you
just remove the install_var_local call?


Because (only) inside the OpenMP context, the variable is supposed to
contain the device-side value; a runtime call is used to obtain the
value from the device back to host.  So a new variable is created, the
remap_decl mechanisms are used to change references inside the omp
context, and other references of the original variable are not touched.


Hmm, ok. Let's go with your patch then.


Bernd

Re: [PATCH 01/15] add more coalescing to simplify constraints

[Matthew Wahab]

On 21/01/16 14:22, Matthew Wahab wrote:

On 15/01/16 17:14, Sebastian Pop wrote:

From: Sebastian Pop 

2015-12-30  Aditya Kumar  
Sebastian Pop  

* graphite-dependences.c (constrain_domain): Add call to isl_*_coalesce.
(add_pdr_constraints): Same.
(scop_get_reads): Same.
(scop_get_must_writes): Same.
(scop_get_may_writes): Same.
(scop_get_original_schedule): Same.
(extend_schedule): Same.
(apply_schedule_on_deps): Same.
(carries_deps): Same.
(compute_deps): Same.
(scop_get_dependences): Same.
* graphite-isl-ast-to-gimple.c
(translate_isl_ast_to_gimple::generate_isl_schedule): Same.
* graphite-optimize-isl.c (get_schedule_for_band): Same.
(get_schedule_for_band_list): Same.
(get_schedule_map): Same.
(apply_schedule_map_to_scop): Same.
* graphite-sese-to-poly.c (build_pbb_scattering_polyhedrons): Same.
(build_loop_iteration_domains): Same.
(add_condition_to_pbb): Same.
(add_param_constraints): Same.
(pdr_add_memory_accesses): Same.
(pdr_add_data_dimensions): Same.
---
  gcc/graphite-dependences.c   | 63 ++--
  gcc/graphite-isl-ast-to-gimple.c |  2 ++
  gcc/graphite-optimize-isl.c  | 12 
  gcc/graphite-sese-to-poly.c  | 28 --
  4 files changed, 56 insertions(+), 49 deletions(-)



diff --git a/gcc/graphite-optimize-isl.c b/gcc/graphite-optimize-isl.c
index 9626e96..15dd5b0 100644
--- a/gcc/graphite-optimize-isl.c
+++ b/gcc/graphite-optimize-isl.c

[..]

  static isl_union_map *
  get_schedule_map (isl_schedule *schedule)
  {
-  isl_band_list *bandList = isl_schedule_get_band_forest (schedule);
-  isl_union_map *schedule_map = get_schedule_for_band_list (bandList);
+  isl_band_list *band_list = isl_schedule_get_band_forest (schedule);
+  isl_union_map *schedule_map = get_schedule_for_band_list (band_list);
isl_band_list_free (bandList);
return schedule_map;
  }


Building arm-none-linux-gnueabihf fails at the isl_band_list_free. Shouldn't 
bandList
be band_list?


Kyrill points out that it's already fixed: 
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01613.html


Matthew

[PATCH, rs6000] Fix PR63354

[Bill Schmidt]

Hi,

Anton Blanchard proposed a fix to his own bug report in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354, but never submitted
the patch upstream.  I've added a formal test case and am submitting on
his behalf.

The patch simply ensures that we don't stack a frame for leaf procedures
when called with -pg -mprofile-kernel.  The automatically generated
calls to _mcount occur prior to the prolog and do not require us to
stack a frame.

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

Thanks,
Bill


[gcc]

2016-01-21  Anton Blanchard  
Bill Schmidt  

PR target/63354
* config/rs6000/linux64.h (TARGET_KEEP_LEAF_WHEN_PROFILED): New
#define.
* config/rs6000/rs6000.c (rs6000_keep_leaf_when_profiled): New
function.

[gcc/testsuite]

2016-01-21  Anton Blanchard  
Bill Schmidt  

PR target/63354
* gcc.target/powerpc/pr63354.c:  New test.


Index: gcc/config/rs6000/linux64.h
===
--- gcc/config/rs6000/linux64.h (revision 232677)
+++ gcc/config/rs6000/linux64.h (working copy)
@@ -59,6 +59,9 @@ extern int dot_symbols;
 
 #define TARGET_PROFILE_KERNEL profile_kernel
 
+#undef TARGET_KEEP_LEAF_WHEN_PROFILED
+#define TARGET_KEEP_LEAF_WHEN_PROFILED rs6000_keep_leaf_when_profiled
+
 #define TARGET_USES_LINUX64_OPT 1
 #ifdef HAVE_LD_LARGE_TOC
 #undef TARGET_CMODEL
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 232677)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -26237,6 +26237,14 @@ rs6000_output_function_prologue (FILE *file,
   rs6000_pic_labelno++;
 }
 
+/* -mprofile-kernel code calls mcount before the function prolog,
+   so a profiled leaf function should stay a leaf function.  */
+static bool
+rs6000_keep_leaf_when_profiled ()
+{
+  return TARGET_PROFILE_KERNEL;
+}
+
 /* Non-zero if vmx regs are restored before the frame pop, zero if
we restore after the pop when possible.  */
 #define ALWAYS_RESTORE_ALTIVEC_BEFORE_POP 0
Index: gcc/testsuite/gcc.target/powerpc/pr63354.c
===
--- gcc/testsuite/gcc.target/powerpc/pr63354.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr63354.c  (working copy)
@@ -0,0 +1,11 @@
+/* Verify that we don't stack a frame for leaf functions when using
+   -pg -mprofile-kernel.  */
+
+/* { dg-do compile { target { powerpc64*-*-* } } } */
+/* { dg-options "-O2 -pg -mprofile-kernel" } */
+/* { dg-final { scan-assembler-not "mtlr" } } */
+
+int foo(void)
+{
+  return 1;
+}

Re: Speedup configure and build with system.h

[Richard Biener]

On Thu, Jan 21, 2016 at 5:57 PM, Michael Matz  wrote:
> Hi,
>
> this has bothered me for some time.  The gcc configure with stage1 feels
> like taking forever because some of the decl availability tests (checking
> for C function) include system.h, and that, since a while, unconditionally
> includes  and  under C++, and we meanwhile use the C++
> compiler for configure tests (which makes sense).  Now, the difference for
> a debuggable (but not even checking-enabled) cc1plus for a file containing
> just main():
>
> % cat blaeh.cc
> #include 
> #include 
> #include 
> #include 
> int main() {}
> % cc1plus -quiet -ftime-report blaeh.cc
>  TOTAL :   0.12 0.01 0.14
>
> (This is btw. three times as expensive as with 4.8 headers (i.e.
> precompile with g++-4.8 then compile with the same cc1plus as above,
> taking 0.04 seconds; the STL headers bloat quite much over time)
>
> Well, not quite blazing fast but then adding :
>
> % cc1plus -quiet -ftime-report blaeh-string.cc
>  TOTAL :   0.60 0.05 0.66
>
> Meeh.  And adding  on top:
>
> % cc1plus -quiet -ftime-report blaeh-string-alg.cc
>  TOTAL :   1.13 0.09 1.23
>
> So, more than a second for checking if some C-only decl is available, just
> because system.h unconditionally includes mostly useless STL headers.
>
> So, how useless exactly?  A whopping single file of cc1 proper needs
> , _two_ files need , and a single target has an unlucky
> interface in its prototypes and also needs .  (One additional
> header lazily uses std::string for no particular reason).  So we pay about
> 5 minutes build time per stage (there are ~400 libbackend.a files) for
> more or less nothing.
>
> So, let's include those headers only conditionally; I'm pretty sure it's
> not unreasonable for a source file, if it needs a particular STL facility
> to #define USES_abcheader (like one normally would have to #include
> ) before the "system.h" include.
>
> See the patch.  I've grepped for target or language dependencies on other
> STL types, and either they were already including the right header, or
> were covered with the new system.h (i.e. I've built all targets quickly
> for which grepping for 'std::' returned anything).  The genconditions.c
> change is for the benefit of aarch64 as well, and it single function
> aarch64_get_extension_string_for_isa_flags returning a std::string.
>
> What do people think?  Should I pass it through a proper bootstrap and put
> it to trunk?  It's a (developer time) regression, right? ;-)

Ok.

Thanks,
Richard.

I'm inclined to say #define INCLUDE_ALGORITHM is a better name,
but just bike-shedding...  and please convert the (bogus) ISL way of
achieving a similar thing.

I'm also inclined to say that we should remove  usage.  Not
sure about algorithm, but I'd say it's the same.

Richard.

>
> Ciao,
> Michael.
> * system.h (string, algorithm): Include only conditionally.
> (new): Include always under C++.
> * bb-reorder.c (toplevel): Define USES_ALGORITHM.
> * final.c (toplevel): Ditto.
> * ipa-chkp.c (toplevel): Define USES_STRING.
> * genconditions.c (write_header): Make gencondmd.c define
> USES_STRING.
> * mem-stats.h (mem_usage::print_dash_line): Don't use std::string.
>
> * config/aarch64/aarch64.c (toplevel): Define USES_STRING.
> * common/config/aarch64/aarch64-common.c (toplevel): Ditto.
>
> Index: bb-reorder.c
> ===
> --- bb-reorder.c(revision 232675)
> +++ bb-reorder.c(working copy)
> @@ -91,6 +91,7 @@
>  */
>
>  #include "config.h"
> +#define USES_ALGORITHM /* stable_sort */
>  #include "system.h"
>  #include "coretypes.h"
>  #include "backend.h"
> Index: final.c
> ===
> --- final.c (revision 232675)
> +++ final.c (working copy)
> @@ -43,6 +43,7 @@ along with GCC; see the file COPYING3.
> function_epilogue.  Those instructions never exist as rtl.  */
>
>  #include "config.h"
> +#define USES_ALGORITHM /* reverse */
>  #include "system.h"
>  #include "coretypes.h"
>  #include "backend.h"
> Index: genconditions.c
> ===
> --- genconditions.c (revision 232675)
> +++ genconditions.c (working copy)
> @@ -51,6 +51,7 @@ write_header (void)
> machine description file.  */\n\
>  \n\
>  #include \"bconfig.h\"\n\
> +#define USES_STRING\n\
>  #include \"system.h\"\n\
>  \n\
>  /* It is necessary, but not entirely safe, to include the headers below\n\
> Index: ipa-chkp.c
> ===
> --- ipa-chkp.c  (revision 232675)
> +++ ipa-chkp.c  (working copy)
> @@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.
>  .  */
>
>  #include 

Re: [Patch,microblaze]: Optimized register reorganization for Microblaze.

[Michael Eager]

On 01/12/2016 09:42 AM, Ajit Kumar Agarwal wrote:

The patch contains the changes in the macros fixed_registers and 
call_used_registers.
Earlier the register r21 is marked as fixed and also marked as 1 for call_used 
registers.
On top of that r21 is not assigned to any of the temporaries in rtl insns.

This makes the usage of registers r21 in the callee functions not possible and 
wasting
one registers to allocate in the callee function. The changes makes the 
register r21 as
allocatable to the callee function and optimized usage of the registers r21 in 
the callee
function reduces spill and fetch. The reduction in the spill and fetch is due 
to availability
of register r21 in the callee function. The availability of register r21 is 
made by
marking the register r21 as not fixed and the call_used registers is marked as 
0.
Also r20 is marked as fixed. The changes are done not to mark as fixed thus 
allowing
the registers to be used reducing the spill and fetch.

Regtested for Microblaze.

Performance runs made on Mibench/EEMBC benchmarks for microblaze. Following 
benchmarks
shows the gains

  Benchmarks Gains
automotive_qsort1 =3.96%
automotive_susan_c = 7.68%
consumer_mad =9.6%
security_rijndael_d =19.57%
telecom_CRC32 =   7.66%
bitmnp01_lite =  10.61%
a2time01_lite =6.97%

ChangeLog:
2016-01-12  Ajit Agarwal  

* config/microblaze/microblaze.h
(FIXED_REGISTERS): Update in macro.
(CALL_USED_REGISTERS): Update in macro.

Signed-off-by:Ajit Agarwal ajit...@xilinx.com.
---
  gcc/config/microblaze/microblaze.h |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/microblaze/microblaze.h 
b/gcc/config/microblaze/microblaze.h
index e115c42..dbfb652 100644
--- a/gcc/config/microblaze/microblaze.h
+++ b/gcc/config/microblaze/microblaze.h
@@ -253,14 +253,14 @@ extern enum pipeline_type microblaze_pipe;
  #define FIXED_REGISTERS   
\
  { \
1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, \
-  1, 1, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  \
+  1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  \
1, 1, 1, 1  \
  }

  #define CALL_USED_REGISTERS   \
  { \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
-  1, 1, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  \
+  1, 1, 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  \
1, 1, 1, 1  \
  }
  #define GP_REG_FIRST0



Committed revision 232682.

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

Re: [PATCH, rs6000] Fix PR63354

[David Edelsohn]

On Thu, Jan 21, 2016 at 11:48 AM, Bill Schmidt
 wrote:
> Hi,
>
> Anton Blanchard proposed a fix to his own bug report in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354, but never submitted
> the patch upstream.  I've added a formal test case and am submitting on
> his behalf.
>
> The patch simply ensures that we don't stack a frame for leaf procedures
> when called with -pg -mprofile-kernel.  The automatically generated
> calls to _mcount occur prior to the prolog and do not require us to
> stack a frame.
>
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions.  Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> [gcc]
>
> 2016-01-21  Anton Blanchard  
> Bill Schmidt  
>
> PR target/63354
> * config/rs6000/linux64.h (TARGET_KEEP_LEAF_WHEN_PROFILED): New
> #define.
> * config/rs6000/rs6000.c (rs6000_keep_leaf_when_profiled): New
> function.
>
> [gcc/testsuite]
>
> 2016-01-21  Anton Blanchard  
> Bill Schmidt  
>
> PR target/63354
> * gcc.target/powerpc/pr63354.c:  New test.

Okay.

Thanks, David

[patch] Document restriction of scalar_storage_order

[Eric Botcazou]

Tested on x86_64-suse-linux, OK for the mainline?


2016-01-21  Eric Botcazou  

* doc/extend.texi (scalar_storage_order type attribute): Document
restriction on type punning and aliasing.

-- 
Eric BotcazouIndex: doc/extend.texi
===
--- doc/extend.texi	(revision 232465)
+++ doc/extend.texi	(working copy)
@@ -6512,6 +6512,10 @@ is taken, so storing indirectly through
 The second case is nevertheless allowed to be able to perform a block copy
 from or to the array.
 
+Moreover, the use of type punning or aliasing to toggle the storage order
+is not supported; that is to say, a given scalar object cannot be accessed
+through distinct types that assign a different storage order to it.
+
 @item transparent_union
 @cindex @code{transparent_union} type attribute
 

Re: [Patch,microblaze]: Instruction prefetch optimization for microblaze.

[Michael Eager]

On 12/07/2015 09:39 AM, Ajit Kumar Agarwal wrote:



-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Thursday, December 03, 2015 7:27 PM
To: Ajit Kumar Agarwal; GCC Patches
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [Patch,microblaze]: Instruction prefetch optimization for 
microblaze.

On 12/01/2015 12:49 AM, Ajit Kumar Agarwal wrote:

The changes are made in this patch for the instruction prefetch optimizations 
for Microblaze.

Reg tested for Microblaze target.

The changes are made for instruction prefetch optimizations for
Microblaze. The "wic" microblaze instruction is the instruction
prefetch instruction. The instruction prefetch optimization is done to
generate the iprefetch instruction at the call site fall through path.
This optimization is enabled with  microblaze target flag mxl-prefetch. The purpose of 
adding the flags is that selection of "wic" instruction should be enabled in 
the reconfigurable design and the selection is not enabled by default.

ChangeLog:
2015-12-01  Ajit Agarwal  

* config/microblaze/microblaze.c
(get_branch_target): New.
(insert_wic_for_ilb_runout): New.
(insert_wic): New.
(microblaze_machine_dependent_reorg): New.
(TARGET_MACHINE_DEPENDENT_REORG): Define macro.
* config/microblaze/microblaze.md
(UNSPEC_IPREFETCH): Define.
(iprefetch): New pattern
* config/microblaze/microblaze.opt
(mxl-prefetch): New flag.

Signed-off-by:Ajit Agarwal ajit...@xilinx.com


Thanks & Regards
Ajit




+  rtx_insn *insn, *before_4 = 0, *before_16 = 0;  int addr = 0, length,
+ first_addr = -1;  int wic_addr0 = 128 * 4, wic_addr1 = 128 * 4;



Especially when there are initializers, I prefer to see each variable declared on a 
separate line.  If the meaning of a variable is not clear (and most of these are 
not), include a comment >>before the declaration.



+if (first_addr == -1)
+  first_addr = INSN_ADDRESSES (INSN_UID (insn));



Can be moved to initialize first_addr.



+addr = INSN_ADDRESSES (INSN_UID (insn)) - first_addr;



Is "addr" and address or offset?  If the latter, use a more descriptive name.




+if (before_4 == 0 && addr + length >= 4 * 4)
+  before_4 = insn;

...


Please add comments to describe what you are doing here.  What are before_4 and 
before_16?  What are all these conditions testing?




+  loop_optimizer_finalize();



Space before parens.


All the above comments are incorporated. Updated patch is attached.

Regtested for Microblaze target.

Mibench/EEMBC benchmarks are run on the hardware enabling the mxl-prefetch and 
the run goes through fine
With the generation of "wic" instruction.

[Patch,microblaze]: Instruction prefetch optimization for microblaze.

The changes are made for instruction prefetch optimizations for Microblaze. The 
"wic"
microblaze instruction is the instruction prefetch instruction. The instruction 
prefetch
optimization is done to generate the iprefetch instruction at the call site 
fall through
path. This optimization is enabled with  microblaze target flag mxl-prefetch. 
The purpose
of adding the flags is that selection of "wic" instruction should be enabled in 
the
reconfigurable design and the selection is not enabled by default.

ChangeLog:
2015-12-07  Ajit Agarwal  

* config/microblaze/microblaze.c
(get_branch_target): New.
(insert_wic_for_ilb_runout): New.
(insert_wic): New.
(microblaze_machine_dependent_reorg): New.
(TARGET_MACHINE_DEPENDENT_REORG): Define macro.
* config/microblaze/microblaze.md
(UNSPEC_IPREFETCH): Define.
(iprefetch): New pattern
* config/microblaze/microblaze.opt
(mxl-prefetch): New flag.

Signed-off-by:Ajit Agarwal ajit...@xilinx.com

Thanks & Regards
Ajit



Committed revision 232683.


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

Re: [PATCH] fix #69405 - [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add

[Jeff Law]

On 01/20/2016 10:00 PM, Martin Sebor wrote:

The attached patch avoids printing a diagnostic referencing the type
of an incompatible argument to the __atomic_xxx built-ins when the
argument is in error.  Doing otherwise causes an ICE as pointed out
in the bug, for both of which I am to blame.

Martin

gcc-69405.patch


gcc/testsuite/ChangeLog:
2016-01-20  Martin Sebor

PR c/69405
* gcc.dg/sync-fetch.c: New test.

gcc/c-family/ChangeLog:
2016-01-20  Martin Sebor

PR c/69405
* c-common.c (sync_resolve_size): Avoid printing diagnostic about
 an incompatible argument when the argument isn't a valid a tree
 node.

OK.

THanks,
Jeff

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Dominique d'Humières]

> Le 21 janv. 2016 à 16:25, Torvald Riegel  a écrit :
> 
> On Thu, 2016-01-21 at 11:00 +0100, Dominique d'Humières wrote:
>> Torvald,
>> 
>> Now that I can bootstrap on darwin, I have found the following failure for 
>> libitm.c++/libstdc++-safeexc.C
>> 
>> /opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
>> unsafe function call 'std::underflow_error::underflow_error(const string&)' 
>> within atomic transaction
>>  throw T (what);
>>  ^
> 
> Does this patch fix it (ie, mark the test unsupported)?

AFAIU the error occurs at compile time and If my memory is correct the patch 
won’t fix the issue (not tested) and the test should be skipped on *-*-darwin* 
powerpc-ibm-aix*.

Dominique

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Dominique d'Humières]

> Le 21 janv. 2016 à 18:15, Dominique d'Humières  a écrit :
> 
> 
>> Le 21 janv. 2016 à 16:25, Torvald Riegel  a écrit :
>> 
>> On Thu, 2016-01-21 at 11:00 +0100, Dominique d'Humières wrote:
>>> Torvald,
>>> 
>>> Now that I can bootstrap on darwin, I have found the following failure for 
>>> libitm.c++/libstdc++-safeexc.C
>>> 
>>> /opt/gcc/work/libitm/testsuite/libitm.c++/libstdc++-safeexc.C:50:2: error: 
>>> unsafe function call 'std::underflow_error::underflow_error(const string&)' 
>>> within atomic transaction
>>> throw T (what);
>>> ^
>> 
>> Does this patch fix it (ie, mark the test unsupported)?
> 
> AFAIU the error occurs at compile time and If my memory is correct the patch 
> won’t fix the issue (not tested) and the test should be skipped on 
> *-*-darwin* powerpc-ibm-aix*.

OK, my memory was not good!-( However the target selection in the patch is 
wrong, the following one works

// { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }


Dominique

Re: [PATCH], PowerPC IEEE 128-bit fp, #11-rev4 (enable libgcc conversions)

[Michael Meissner]

On Thu, Jan 21, 2016 at 08:28:05AM -0500, David Edelsohn wrote:
> On Wed, Jan 20, 2016 at 8:00 PM, Michael Meissner
>  wrote:
> > This is revision 4 of the IEEE 128-bit floating point libgcc support.
> >
> > Since revision 3, I have removed the gcc changes that broke AIX.  I rewrote 
> > the
> > IBM extended double pack/unpack support to not use the builtin functions, 
> > but
> > instead uses a union.  The libgcc code that I wrote tickles a bug in the 
> > pack
> > function.  While I would like to fix the pack function bug, I will need to 
> > make
> > sure I don't break AIX, so I didn't want to couple this library to getting
> > those bugs fixed.
> >
> > I have also rewritten how the ifunc support is done, so that ifunc is only 
> > done
> > if the target assembler supports ISA 3.0 instructions AND the compiler 
> > supports
> > ifunc functions.  This is so that the compiler can build on 64-bit systems 
> > if
> > --enable-gnu-indirect-function is not specified without the ifunc functions
> > being flagged.
> >
> > I have done bootstraps on both a big endian power7 system and a little 
> > endian
> > power8 with no regressions.  In addition, I have built a compiler explicitly
> > disabling ifunc support, and it built and ran the ieee 128-bit floating 
> > point
> > unit tests correctly.
> >
> > Can I install this into libgcc?
> >
> > Assuming I can install these changes, the one final change that I would 
> > like to
> > make is to enable float128 automatically on VSX powerpc Linux systems, but 
> > not
> > on other systems (AIX, *BSD, etc.) since those systems do not build float128
> > emulator functions.
> 
> What does "enable" mean?

I would prefer users being able to use __float128 without having to use the
-mfloat128 option on power7/power8/power9 systems.  Since we currently only
build the emulation for PowerPC Linux systems, I don't think we want to enable
it by default without enabling the emulation on those other systems.

This means, I probably don't want to put OPTION_MASK_FLOAT128 into
ISA_2_6_MASKS_SERVER in rs6000-cpus.def, but instead turn it on in the option
handling in rs6000.c if the switch was not done by the user, and we are
targetting a VSX Linux system.

If you want AIX support, in theory it should be doable. However, it has been a
long time since I used AIX, and I will need to refresh my memories on the
capabilities of the object file format currently used (in particular, does
ifunc and aliases work).

For *BSD, it may be more problematical.  We've had at least one query about
getting __float128 to work on non-VSX systems.  Obviously, it won't be in GCC
6, but it may come up in GCC 7.

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

patch to fix PR68990

[Vladimir Makarov]

  The following patch fixes

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

  The patch was successfully bootstrapped and tested on x86 and 
x86-64.  The patch was also checked on x86-64 SPECFP2000.  The only 
changed code was for fma3d.  There was no visible change in fm3d 
performance.


  Committed as r232679.sy

P.S.  I believe it also fixes PR69377.  It seems that x86 with 
-march=x86-64 stresses RA much and is a good for its testing.



Index: ChangeLog
===
--- ChangeLog	(revision 232571)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2016-01-21  Vladimir Makarov  
+
+	PR rtl-optimization/68990
+	* lra-coalesce.c (lra_coalesce): Invalidate value for the result
+	pseudo instead of inheritance ones.
+
 2016-01-19  Richard Biener  
 
 	* hsa-gen.c (get_memory_order_name): Use MEMMODEL_ constants.
Index: lra-coalesce.c
===
--- lra-coalesce.c	(revision 232571)
+++ lra-coalesce.c	(working copy)
@@ -224,13 +224,10 @@ lra_coalesce (void)
   rtx_insn *mv, *insn, *next, **sorted_moves;
   rtx set;
   int i, mv_num, sregno, dregno;
-  unsigned int regno;
   int coalesced_moves;
   int max_regno = max_reg_num ();
   bitmap_head involved_insns_bitmap;
-  bitmap_head result_pseudo_vals_bitmap;
-  bitmap_iterator bi;
-
+  
   timevar_push (TV_LRA_COALESCE);
 
   if (lra_dump_file != NULL)
@@ -327,7 +324,7 @@ lra_coalesce (void)
 }
   /* If we have situation after inheritance pass:
 
- r1 <- ...  insn originally setting p1
+ r1 <- p1   insn originally setting p1
  i1 <- r1   setting inheritance i1 from reload r1
...
  ... <- ... p2 ... dead p2
@@ -339,20 +336,18 @@ lra_coalesce (void)
  And we are coalescing p1 and p2 using p1.  In this case i1 and p1
  should have different values, otherwise they can get the same
  hard reg and this is wrong for insn using p2 before coalescing.
- So invalidate such inheritance pseudo values.  */
-  bitmap_initialize (_pseudo_vals_bitmap, _obstack);
-  EXECUTE_IF_SET_IN_BITMAP (_pseudos_bitmap, 0, regno, bi)
-bitmap_set_bit (_pseudo_vals_bitmap,
-		lra_reg_info[first_coalesced_pseudo[regno]].val);
-  EXECUTE_IF_SET_IN_BITMAP (_inheritance_pseudos, 0, regno, bi)
-if (bitmap_bit_p (_pseudo_vals_bitmap, lra_reg_info[regno].val))
+ The situation even can be more complicated when new reload
+ pseudos occur after the inheriatnce.  So invalidate the result
+ pseudos.  */
+  for (i = 0; i < max_regno; i++)
+if (first_coalesced_pseudo[i] == i
+	&& first_coalesced_pseudo[i] != next_coalesced_pseudo[i])
   {
-	lra_set_regno_unique_value (regno);
+	lra_set_regno_unique_value (i);
 	if (lra_dump_file != NULL)
 	  fprintf (lra_dump_file,
-		   "	 Make unique value for inheritance r%d\n", regno);
+		   "	 Make unique value for coalescing result r%d\n", i);
   }
-  bitmap_clear (_pseudo_vals_bitmap);
   bitmap_clear (_pseudos_bitmap);
   bitmap_clear (_insns_bitmap);
   bitmap_clear (_pseudos_bitmap);
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog	(revision 232571)
+++ testsuite/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2016-01-21  Vladimir Makarov  
+
+	PR rtl-optimization/68990
+	* gcc.target/i386/pr68990: New.
+
 2016-01-19  Marek Polacek  
 
 	PR c++/68965
Index: testsuite/gcc.target/i386/pr68990.c
===
--- testsuite/gcc.target/i386/pr68990.c	(revision 0)
+++ testsuite/gcc.target/i386/pr68990.c	(working copy)
@@ -0,0 +1,49 @@
+/* { dg-do compile { target { ia32 } } } */
+/* { dg-options "-O3 -march=x86-64" } */
+/* { dg-final { scan-assembler-not "cmpl\[ \t]+(\[%a-z]+), \\1" } } */
+
+short a;
+int b = 1, f;
+char c, e = 1;
+long long d;
+
+static short
+foo ()
+{
+  unsigned g, h = 0;
+  int i = 0 || d * (b | e);
+  char j = a << i, l = a;
+  short k;
+  int m = -b;
+  if (m < b)
+{
+  k = m = b;
+  g = (k || l) / (b / e);
+  if (b)
+	__builtin_printf ("foo=%lld\n", (long long) a);
+}
+  a = b = m;
+  if (j || e)
+{
+  h = g;
+  i = m;
+  g = j * k / (i - d);
+  if (m)
+	b = j && b;
+  e = b * (h & d) || g;
+}
+  b = i;
+  char n = e || h | d;
+  e = i < d & k / n;
+  return f;
+}
+
+int
+main ()
+{
+  if (foo ())
+if (c)
+lab:
+  goto lab;
+  return 0;
+}

Backport PR63681 cfglayout/doloop fix to 4.9

[Bernd Schmidt]

I've bootstrapped and tested the following on 4.9-branch. It's a 
backport of a patch that avoids unnecessary assertion failures, both by 
tuning down an assert, and restricting an optimization for the case 
where the assert would validly trigger.


Ok to commit on the branch?


Bernd

	PR target/63681
	* cfgrtl.c (cfg_layout_initialize): Weaken assert to only trigger if
	flag_reorder_blocks_and_partition.
	* hw-doloop.c (reorg_loops): Avoid reordering if that flag is set.

diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index 1a63249..2d75845 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -4222,14 +4222,14 @@ cfg_layout_initialize (unsigned int flags)
   rtx x;
   basic_block bb;
 
-  /* Once bb reordering is complete, cfg layout mode should not be re-entered.
- Entering cfg layout mode will perform optimizations on the cfg that
- could affect the bb layout negatively or even require fixups. An
- example of the latter is if edge forwarding performed when optimizing
- the cfg layout required moving a block from the hot to the cold section
- under -freorder-blocks-and-partition. This would create an illegal
- partitioning unless some manual fixup was performed.  */
-  gcc_assert (!crtl->bb_reorder_complete);
+  /* Once bb partitioning is complete, cfg layout mode should not be
+ re-entered.  Entering cfg layout mode may require fixups.  As an
+ example, if edge forwarding performed when optimizing the cfg
+ layout required moving a block from the hot to the cold
+ section. This would create an illegal partitioning unless some
+ manual fixup was performed.  */
+  gcc_assert (!(crtl->bb_reorder_complete
+		&& flag_reorder_blocks_and_partition));
 
   initialize_original_copy_tables ();
 
diff --git a/gcc/hw-doloop.c b/gcc/hw-doloop.c
index b6184a2..9c2c874 100644
--- a/gcc/hw-doloop.c
+++ b/gcc/hw-doloop.c
@@ -636,7 +636,9 @@ reorg_loops (bool do_reorder, struct hw_doloop_hooks *hooks)
 
   loops = discover_loops (_stack, hooks);
 
-  if (do_reorder)
+  /* We can't enter cfglayout mode anymore if basic block partitioning
+ already happened.  */
+  if (do_reorder && !flag_reorder_blocks_and_partition)
 {
   reorder_loops (loops);
   free_loops (loops);

[PATCH] libitm: Disable testing transaction-safe exceptions on Darwin and AIX.

[Torvald Riegel]

On Thu, 2016-01-21 at 10:06 -0800, Mike Stump wrote:
> On Jan 21, 2016, at 9:29 AM, Dominique d'Humières  wrote:
> > // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
> 
> A comment to hint that this has something to do with weak undefined would be 
> nice.

Here's the patch I prepared (which indeed includes a comment).

OK for trunk?  I'm not quite sure whether this qualifies as a
regression, but having an additional test that now fails is one I guess.
commit 0323fed14832e5744cbc63bcfeeb6728f7f13394
Author: Torvald Riegel 
Date:   Thu Jan 21 16:21:33 2016 +0100

libitm: Disable testing transaction-safe exceptions on Darwin and AIX.

	* testsuite/libitm.c++/libstdc++-safeexc.C: Not supported on darwin
	or AIX.

diff --git a/libitm/testsuite/libitm.c++/libstdc++-safeexc.C b/libitm/testsuite/libitm.c++/libstdc++-safeexc.C
index 3e1655e..20e2e5e 100644
--- a/libitm/testsuite/libitm.c++/libstdc++-safeexc.C
+++ b/libitm/testsuite/libitm.c++/libstdc++-safeexc.C
@@ -2,7 +2,10 @@
 // are indeed that.  Thus, this also tests the transactional clones in
 // libstdc++ and libsupc++.
 
-// { dg-do run }
+// Not supported on Darwin nor AIX because those lack the support for
+// weak references to undefined functions that we need in libstdc++ to make
+// exceptions transaction-safe.
+// { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
 
 #include 
 #include 

C++ PATCH for c++/69379 (ICE with PTRMEM_CST wrapped in NOP_EXPR)

[Marek Polacek]

The problem in this PR is that we have a PTRMEM_CST wrapped in NOP_EXPR
and fold_convert can't digest that.

For the unreduced test in the PR, this occurs since rev 230508: we force
a NOP_EXPR when converting to the same type in build_static_cast_1:

  if (result == expr && SCALAR_TYPE_P (type))
/* Leave some record of the cast.  */
result = build_nop (type, expr);

For the reduced test in the PR, this happens since the C++ delayed folding
merge, and we wrap a PTRMEM_CST in NOP_EXPR in build_reinterpret_cast:

  else if ((TYPE_PTRFN_P (type) && TYPE_PTRFN_P (intype))
   || (TYPE_PTRMEMFUNC_P (type) && TYPE_PTRMEMFUNC_P (intype)))
return build_nop (type, expr);

This patch  prevented
cp_fold_convert to wrap a PTRMEM_CST in NOP_EXPR, but in this case
cp_fold_convert gets a PTRMEM_CST already wrapped in NOP_EXPR.  I think we can
fix this by extending the fix to also handle nested PTRMEM_CSTs.  I've verified
that this fixes the ICE with the unreduced testcase too.

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

2016-01-21  Marek Polacek  

PR c++/69379
* cvt.c (cp_fold_convert): Handle PTRMEM_CSTs wrapped in NOP_EXPRs.

* g++.dg/pr69379.C: New test.

diff --git gcc/cp/cvt.c gcc/cp/cvt.c
index f381f9b..667307a 100644
--- gcc/cp/cvt.c
+++ gcc/cp/cvt.c
@@ -592,12 +592,14 @@ tree
 cp_fold_convert (tree type, tree expr)
 {
   tree conv;
+  tree sexpr = tree_strip_nop_conversions (expr);
+
   if (TREE_TYPE (expr) == type)
 conv = expr;
-  else if (TREE_CODE (expr) == PTRMEM_CST)
+  else if (TREE_CODE (sexpr) == PTRMEM_CST)
 {
   /* Avoid wrapping a PTRMEM_CST in NOP_EXPR.  */
-  conv = copy_node (expr);
+  conv = copy_node (sexpr);
   TREE_TYPE (conv) = type;
 }
   else
diff --git gcc/testsuite/g++.dg/pr69379.C gcc/testsuite/g++.dg/pr69379.C
index e69de29..249ad00 100644
--- gcc/testsuite/g++.dg/pr69379.C
+++ gcc/testsuite/g++.dg/pr69379.C
@@ -0,0 +1,20 @@
+// PR c++/69379
+// { dg-do compile }
+// { dg-options "-Wformat" }
+
+typedef int T;
+class A {
+public:
+  template  A(const char *, D);
+  template 
+  void m_fn1(const char *, Fn, A1 const &, A2);
+};
+struct Dict {
+  void m_fn2();
+};
+void fn1() {
+  A a("", "");
+  typedef void *Get;
+  typedef void (Dict::*d)(T);
+  a.m_fn1("", Get(), d(::m_fn2), "");
+}

Marek

Re: [PATCH] Fix the remaining PR c++/24666 blockers (arrays decay to pointers too early)

[Jason Merrill]

On 01/19/2016 10:30 PM, Patrick Palka wrote:

 * g++.dg/template/unify17.C: XFAIL.


Hmm, I'm not comfortable with deliberately regressing this testcase.


  template 
-void bar (void (T[5])); // { dg-error "array of 'void'" }
+void bar (void (T[5])); // { dg-error "array of 'void'" "" { xfail
*-*-* } }


Can we work it so that T[5] also is un-decayed in the DECL_ARGUMENTS of 
bar, but decayed in the TYPE_ARG_TYPES?


Jason

Re: [PATCH] gcc/configure test for AIX DWARF

[David Edelsohn]

On Thu, Jan 21, 2016 at 12:47 PM, Bernd Schmidt  wrote:
> On 01/18/2016 08:30 PM, David Edelsohn wrote:
>>
>> Bootstrapped on powerpc-ibm-aix7.1.2.0 with and without the corrected
>> assembler.
>>
>> Okay?
>
>
> The changes seem to be in *-*-aix blocks, so as far as I'm concerned you are
> the maintainer and can check this in. One question though:
>
>> ;;
>>  esac
>> -;;
>>
>>mips*-*-*)
>>  gcc_GAS_CHECK_FEATURE([explicit relocation support],
>
>
> Did you intend to remove this line? This looks odd.

The ";;" were mis-matched in the patch I sent.  It is correct on trunk.

- David

[PATCH][ARM] Fix PR target/69403: Bug in thumb2_ior_scc_strict_it pattern

[Kyrill Tkachov]

Hi all,

In this wrong-code PR the pattern for performing
x = x |  for -mrestrict-it is buggy and ends up writing 1 to the
result register rather than orring it.

The offending pattern is *thumb2_ior_scc_strict_it.
My proposed solution is to rewrite it as a splitter, remove the
alternative for the case where operands[1] and 0 are the same reg
that emits the bogus:
it ; mov%0, #1; it ; orr %0, %1

to emit the RTL equivalent to:
orr %0, %1, #1; it ; mov%D2\\t%0, %1
while marking operand 0 as an earlyclobber operand so that it doesn't
get assigned the same register as operand 1.

This way we avoid the wrong-code, make the sequence better (by eliminating the 
move of #1 into a register
and relaxing the constraints from 'l' to 'r' since only the register move has 
to be conditional).
and still stay within the rules for arm_restrict_it.

Bootstrapped and tested on arm-none-linux-gnueabihf configured 
--with-arch=armv8-a and --with-mode=thumb.

Ok for trunk, GCC 5 and 4.9?

Han, can you please try this out to see if it solves the problem on your end as 
well?

Thanks,
Kyrill

2016-01-21  Kyrylo Tkachov  

PR target/69403
* config/arm/thumb2.md (*thumb2_ior_scc_strict_it): Convert to
define_insn_and_split.  Ensure operands[1] and operands[0] do not
get assigned the same register.

2016-01-21  Kyrylo Tkachov  

PR target/69403
* gcc.c-torture/execute/pr69403.c: New test.
commit 536a372b7adbb89afa56f61a511ae86e00b7385f
Author: Kyrylo Tkachov 
Date:   Thu Jan 21 10:15:38 2016 +

[ARM] Fix PR target/69403: Bug in thumb2_ior_scc_strict_it pattern

diff --git a/gcc/config/arm/thumb2.md b/gcc/config/arm/thumb2.md
index 7368d06..9925365 100644
--- a/gcc/config/arm/thumb2.md
+++ b/gcc/config/arm/thumb2.md
@@ -663,15 +663,27 @@ (define_insn_and_split "*thumb2_ior_scc"
(set_attr "type" "multiple")]
 )
 
-(define_insn "*thumb2_ior_scc_strict_it"
-  [(set (match_operand:SI 0 "s_register_operand" "=l,l")
+(define_insn_and_split "*thumb2_ior_scc_strict_it"
+  [(set (match_operand:SI 0 "s_register_operand" "=")
 	(ior:SI (match_operator:SI 2 "arm_comparison_operator"
 		 [(match_operand 3 "cc_register" "") (const_int 0)])
-		(match_operand:SI 1 "s_register_operand" "0,?l")))]
+		(match_operand:SI 1 "s_register_operand" "r")))]
   "TARGET_THUMB2 && arm_restrict_it"
-  "@
-   it\\t%d2\;mov%d2\\t%0, #1\;it\\t%d2\;orr%d2\\t%0, %1
-   mov\\t%0, #1\;orr\\t%0, %1\;it\\t%D2\;mov%D2\\t%0, %1"
+  "#" ; orr\\t%0, %1, #1\;it\\t%D2\;mov%D2\\t%0, %1
+  "&& reload_completed"
+  [(set (match_dup 0) (ior:SI (match_dup 1) (const_int 1)))
+   (cond_exec (match_dup 4)
+ (set (match_dup 0) (match_dup 1)))]
+  {
+machine_mode mode = GET_MODE (operands[3]);
+rtx_code rc = GET_CODE (operands[2]);
+
+if (mode == CCFPmode || mode == CCFPEmode)
+  rc = reverse_condition_maybe_unordered (rc);
+else
+  rc = reverse_condition (rc);
+operands[4] = gen_rtx_fmt_ee (rc, VOIDmode, operands[3], const0_rtx);
+  }
   [(set_attr "conds" "use")
(set_attr "length" "8")
(set_attr "type" "multiple")]
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr69403.c b/gcc/testsuite/gcc.c-torture/execute/pr69403.c
new file mode 100644
index 000..097d366
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr69403.c
@@ -0,0 +1,20 @@
+/* PR target/69403.  */
+
+int a, b, c;
+
+__attribute__ ((__noinline__)) int
+fn1 ()
+{
+  if ((b | (a != (a & c))) == 1)
+__builtin_abort ();
+  return 0;
+}
+
+int
+main (void)
+{
+  a = 5;
+  c = 1;
+  b = 6;
+  return fn1 ();
+}

Re: [PATCH] Detangle gcc/configure for Darwin

[Mike Stump]

On Jan 21, 2016, at 6:50 AM, David Edelsohn  wrote:
> A gcc/configure stanza to test for PowerPC mfcrf support became
> tangled with Darwin test for .machine directive.  This patch detangles
> and separates the two tests.
> 
> I don't have a Darwin system to test.
> 
> * configure.ac (gcc_cv_as_powerpc_mfcrf, gcc_cv_as_machine_directive): 
> Detangle.
> 
> Okay?

Ok.

Would have been slightly easier to back out the patch that went wrong, and 
review the re-application of that patch as it should have been originally.

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Pedro Alves]

On 01/21/2016 06:06 PM, Mike Stump wrote:
> On Jan 21, 2016, at 9:29 AM, Dominique d'Humières  wrote:
>> // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
> 
> A comment to hint that this has something to do with weak undefined would be 
> nice.
> 

Or come up with some new "dg-require-effective-target weakref-whatnot", making 
it
self-documenting.

Re: [PATCH] libitm: Disable testing transaction-safe exceptions on Darwin and AIX.

[Mike Stump]

On Jan 21, 2016, at 10:15 AM, Torvald Riegel  wrote:
> On Thu, 2016-01-21 at 10:06 -0800, Mike Stump wrote:
>> On Jan 21, 2016, at 9:29 AM, Dominique d'Humières  wrote:
>>> // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
>> 
>> A comment to hint that this has something to do with weak undefined would be 
>> nice.
> 
> Here's the patch I prepared (which indeed includes a comment).
> 
> OK for trunk?  I'm not quite sure whether this qualifies as a
> regression, but having an additional test that now fails is one I guess.
> 

A simple testsuite fixup like this is still ok.  From a darwin, AIX perspective 
it is fine.  If either the transaction or the libstdc++ people like it, I think 
we’re set.

Re: [PATCH] libitm: Disable testing transaction-safe exceptions on Darwin and AIX.

[Jonathan Wakely]

On 21/01/16 10:19 -0800, Mike Stump wrote:

On Jan 21, 2016, at 10:15 AM, Torvald Riegel  wrote:

On Thu, 2016-01-21 at 10:06 -0800, Mike Stump wrote:

On Jan 21, 2016, at 9:29 AM, Dominique d'Humières  wrote:

// { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }


A comment to hint that this has something to do with weak undefined would be 
nice.


Here's the patch I prepared (which indeed includes a comment).

OK for trunk?  I'm not quite sure whether this qualifies as a
regression, but having an additional test that now fails is one I guess.



A simple testsuite fixup like this is still ok.  From a darwin, AIX perspective 
it is fine.  If either the transaction or the libstdc++ people like it, I think 
we’re set.


OK from the libstdc++ side.

Re: [patch] Document restriction of scalar_storage_order

[Bernd Schmidt]

On 01/21/2016 05:34 PM, Eric Botcazou wrote:

Tested on x86_64-suse-linux, OK for the mainline?


2016-01-21  Eric Botcazou  

* doc/extend.texi (scalar_storage_order type attribute): Document
restriction on type punning and aliasing.


Isn't this kind of implied by the already documented restriction of 
taking the address of a union field? Still, you can add this or any kind 
of similar language if you like.



Bernd

Re: [PATCH] gcc/configure test for AIX DWARF

[Bernd Schmidt]

On 01/18/2016 08:30 PM, David Edelsohn wrote:

Bootstrapped on powerpc-ibm-aix7.1.2.0 with and without the corrected assembler.

Okay?


The changes seem to be in *-*-aix blocks, so as far as I'm concerned you 
are the maintainer and can check this in. One question though:



;;
 esac
-;;

   mips*-*-*)
 gcc_GAS_CHECK_FEATURE([explicit relocation support],


Did you intend to remove this line? This looks odd.


Bernd

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Mike Stump]

On Jan 21, 2016, at 9:29 AM, Dominique d'Humières  wrote:
> // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }

A comment to hint that this has something to do with weak undefined would be 
nice.

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Torvald Riegel]

On Thu, 2016-01-21 at 18:12 +, Pedro Alves wrote:
> On 01/21/2016 06:06 PM, Mike Stump wrote:
> > On Jan 21, 2016, at 9:29 AM, Dominique d'Humières  
> > wrote:
> >> // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
> > 
> > A comment to hint that this has something to do with weak undefined would 
> > be nice.
> > 
> 
> Or come up with some new "dg-require-effective-target weakref-whatnot", 
> making it
> self-documenting.
> 

It's just one test that needs this right now.  If there should be more
in the future, I agree that a dg-require-... might be nicer.

Re: [PATCH] libitm: Disable testing transaction-safe exceptions on Darwin and AIX.

[Torvald Riegel]

On Thu, 2016-01-21 at 18:26 +, Jonathan Wakely wrote:
> On 21/01/16 10:19 -0800, Mike Stump wrote:
> >On Jan 21, 2016, at 10:15 AM, Torvald Riegel  wrote:
> >> On Thu, 2016-01-21 at 10:06 -0800, Mike Stump wrote:
> >>> On Jan 21, 2016, at 9:29 AM, Dominique d'Humières  
> >>> wrote:
>  // { dg-do run { target { ! { *-*-darwin* powerpc-ibm-aix* } } } }
> >>>
> >>> A comment to hint that this has something to do with weak undefined would 
> >>> be nice.
> >>
> >> Here's the patch I prepared (which indeed includes a comment).
> >>
> >> OK for trunk?  I'm not quite sure whether this qualifies as a
> >> regression, but having an additional test that now fails is one I guess.
> >> 
> >
> >A simple testsuite fixup like this is still ok.  From a darwin, AIX 
> >perspective it is fine.  If either the transaction or the libstdc++ people 
> >like it, I think we’re set.
> 
> OK from the libstdc++ side.
> 

Committed.

Re: C++ PATCH for c++/69379 (ICE with PTRMEM_CST wrapped in NOP_EXPR)

[Jason Merrill]

On 01/21/2016 01:25 PM, Marek Polacek wrote:

The problem in this PR is that we have a PTRMEM_CST wrapped in NOP_EXPR
and fold_convert can't digest that.


Why didn't we fold away the NOP_EXPR before calling fold_convert?  I 
guess we shouldn't call fold_convert on an un-folded operand.


Jason

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

[Evandro Menezes]

Hi, James.

On 01/21/16 03:24, James Greenhalgh wrote:

On Wed, Jan 06, 2016 at 02:44:47PM -0600, Evandro Menezes wrote:

On 01/06/2016 06:04 AM, Wilco Dijkstra wrote:

Here's what I had in mind when I inquired about distinguishing FCMP from
FCCMP.  As you can see in the patch, Exynos is the only target that
cares about it, but I wonder if ThunderX or Xgene would too.

What do you think?

The new attributes look fine (I've got a similar outstanding change), however
please don't add them to non-AArch64 cores. We only need it for thunderx.md,
cortex-a53.md, cortex-a57.md, xgene1.md and exynos-m1.md.

 Add support for the FCCMP insn types

 2016-01-04  Evandro Menezes  

 gcc/
 * config/aarch64/aarch64.md (fccmp): Change insn type.
 (fccmpe): Likewise.
 * config/aarch64/thunderx.md (thunderx_fcmp): Add
"fccmp{s,d}" types.
 * config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
 * config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
 * config/arm/xgene1.md (xgene1_fcmp): Likewise.
 * config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn
reservation.
 * config/arm/types.md (fccmps): Add new insn type.
 (fccmpd): Likewise.

Got it.  Here's an updated patch.  Again, assuming that your
original patch is in place.  Perhaps you can build on it.

If we don't have any targets which care about the fccmps/fccmpd split in
the code base, do we really need it? Can we just follow the example of
fcsel?


The Exynos M1 does care about the difference between FCMP and FCCMP, as 
can be seen in the patch.



diff --git a/gcc/config/arm/types.md b/gcc/config/arm/types.md
index 321ff89..daf7162 100644
--- a/gcc/config/arm/types.md
+++ b/gcc/config/arm/types.md
@@ -70,6 +70,7 @@
  ; f_rint[d,s]double/single floating point rount to integral.
  ; f_store[d,s]   double/single store to memory.  Used for VFP unit.
  ; fadd[d,s]  double/single floating-point scalar addition.
+; fccmp[d,s] double/single floating-point conditional compare.

Can we follow the convention fcsel uses of calling out "From ARMv8-A:"
for this type?



I'm not sure I follow.  Though I didn't refer to the ISA spec, I used 
the description from it for the *fccmp* type.


Please, advise.

--
Evandro Menezes

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

[Evandro Menezes]

On 01/21/16 13:58, Evandro Menezes wrote:

Hi, James.

On 01/21/16 03:24, James Greenhalgh wrote:

On Wed, Jan 06, 2016 at 02:44:47PM -0600, Evandro Menezes wrote:

On 01/06/2016 06:04 AM, Wilco Dijkstra wrote:
Here's what I had in mind when I inquired about distinguishing 
FCMP from

FCCMP.  As you can see in the patch, Exynos is the only target that
cares about it, but I wonder if ThunderX or Xgene would too.

What do you think?
The new attributes look fine (I've got a similar outstanding 
change), however
please don't add them to non-AArch64 cores. We only need it for 
thunderx.md,

cortex-a53.md, cortex-a57.md, xgene1.md and exynos-m1.md.

 Add support for the FCCMP insn types

 2016-01-04  Evandro Menezes 

 gcc/
 * config/aarch64/aarch64.md (fccmp): Change insn type.
 (fccmpe): Likewise.
 * config/aarch64/thunderx.md (thunderx_fcmp): Add
"fccmp{s,d}" types.
 * config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
 * config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
 * config/arm/xgene1.md (xgene1_fcmp): Likewise.
 * config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn
reservation.
 * config/arm/types.md (fccmps): Add new insn type.
 (fccmpd): Likewise.

Got it.  Here's an updated patch.  Again, assuming that your
original patch is in place.  Perhaps you can build on it.

If we don't have any targets which care about the fccmps/fccmpd split in
the code base, do we really need it? Can we just follow the example of
fcsel?


The Exynos M1 does care about the difference between FCMP and FCCMP, 
as can be seen in the patch.





More explicitly:

   (define_insn_reservation "exynos_m1_fp_cmp" 4
  (and (eq_attr "tune" "exynosm1")
   (eq_attr "type" "fcmps, fcmpd"))
  "em1_nmisc")

   (define_insn_reservation "exynos_m1_fp_ccmp" 7
  (and (eq_attr "tune" "exynosm1")
   (eq_attr "type" "fccmps, fccmpd"))
  "em1_st, em1_nmisc")


Thank you,

--
Evandro Menezes

Speedup configure and build with system.h

[Michael Matz]

Hi,

this has bothered me for some time.  The gcc configure with stage1 feels 
like taking forever because some of the decl availability tests (checking 
for C function) include system.h, and that, since a while, unconditionally 
includes  and  under C++, and we meanwhile use the C++ 
compiler for configure tests (which makes sense).  Now, the difference for 
a debuggable (but not even checking-enabled) cc1plus for a file containing 
just main():

% cat blaeh.cc
#include 
#include 
#include 
#include 
int main() {}
% cc1plus -quiet -ftime-report blaeh.cc
 TOTAL :   0.12 0.01 0.14

(This is btw. three times as expensive as with 4.8 headers (i.e. 
precompile with g++-4.8 then compile with the same cc1plus as above, 
taking 0.04 seconds; the STL headers bloat quite much over time)

Well, not quite blazing fast but then adding :

% cc1plus -quiet -ftime-report blaeh-string.cc
 TOTAL :   0.60 0.05 0.66

Meeh.  And adding  on top:

% cc1plus -quiet -ftime-report blaeh-string-alg.cc
 TOTAL :   1.13 0.09 1.23

So, more than a second for checking if some C-only decl is available, just 
because system.h unconditionally includes mostly useless STL headers.

So, how useless exactly?  A whopping single file of cc1 proper needs 
, _two_ files need , and a single target has an unlucky 
interface in its prototypes and also needs .  (One additional 
header lazily uses std::string for no particular reason).  So we pay about 
5 minutes build time per stage (there are ~400 libbackend.a files) for 
more or less nothing.

So, let's include those headers only conditionally; I'm pretty sure it's 
not unreasonable for a source file, if it needs a particular STL facility 
to #define USES_abcheader (like one normally would have to #include 
) before the "system.h" include.

See the patch.  I've grepped for target or language dependencies on other 
STL types, and either they were already including the right header, or 
were covered with the new system.h (i.e. I've built all targets quickly 
for which grepping for 'std::' returned anything).  The genconditions.c 
change is for the benefit of aarch64 as well, and it single function 
aarch64_get_extension_string_for_isa_flags returning a std::string.

What do people think?  Should I pass it through a proper bootstrap and put 
it to trunk?  It's a (developer time) regression, right? ;-)


Ciao,
Michael.
* system.h (string, algorithm): Include only conditionally.
(new): Include always under C++.
* bb-reorder.c (toplevel): Define USES_ALGORITHM.
* final.c (toplevel): Ditto.
* ipa-chkp.c (toplevel): Define USES_STRING.
* genconditions.c (write_header): Make gencondmd.c define
USES_STRING.
* mem-stats.h (mem_usage::print_dash_line): Don't use std::string.

* config/aarch64/aarch64.c (toplevel): Define USES_STRING.
* common/config/aarch64/aarch64-common.c (toplevel): Ditto.

Index: bb-reorder.c
===
--- bb-reorder.c(revision 232675)
+++ bb-reorder.c(working copy)
@@ -91,6 +91,7 @@
 */
 
 #include "config.h"
+#define USES_ALGORITHM /* stable_sort */
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
Index: final.c
===
--- final.c (revision 232675)
+++ final.c (working copy)
@@ -43,6 +43,7 @@ along with GCC; see the file COPYING3.
function_epilogue.  Those instructions never exist as rtl.  */
 
 #include "config.h"
+#define USES_ALGORITHM /* reverse */
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
Index: genconditions.c
===
--- genconditions.c (revision 232675)
+++ genconditions.c (working copy)
@@ -51,6 +51,7 @@ write_header (void)
machine description file.  */\n\
 \n\
 #include \"bconfig.h\"\n\
+#define USES_STRING\n\
 #include \"system.h\"\n\
 \n\
 /* It is necessary, but not entirely safe, to include the headers below\n\
Index: ipa-chkp.c
===
--- ipa-chkp.c  (revision 232675)
+++ ipa-chkp.c  (working copy)
@@ -19,6 +19,7 @@ along with GCC; see the file COPYING3.
 .  */
 
 #include "config.h"
+#define USES_STRING
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
Index: mem-stats.h
===
--- mem-stats.h (revision 232675)
+++ mem-stats.h (working copy)
@@ -200,7 +200,9 @@ struct mem_usage
   static inline void
   print_dash_line (size_t count = 140)
   {
-fprintf (stderr, "%s\n", std::string (count, '-').c_str ());
+while (count--)
+  fputc ('-', stderr);
+fputc ('\n', stderr);
   }
 
   /* Dump header with NAME.  */
Index: system.h

Re: [PATCH 0/2][AArch64] Implement AAPCS64 updates for alignment attribute

[Alan Lawrence]

On 18/01/16 17:10, Eric Botcazou wrote:

Similarly to ARM, I note that Ada is affected. Indeed, with a gcc 4.9 host
compiler, I saw a bootstrap miscompare iff including Ada; however, I was
able to bootstrap Ada successfully, if I first built a GCC including this
patch with --disable-bootstrap, and then used that as host compiler. The
best explanation I can see for this is mismatched host vs built libraries
and compiler being used together, something like Jakub's suggestion
http://gcc.gnu.org/ml/gcc-patches/2015-11/msg00338.html. I don't feel I have
the expertise for this, and am CCing the Ada maintainers in the hope they
can help.


That's a bit weird though because this should have also occurred for ARM when
the ABI was broken the same way if the Ada bootstrap is not entirely correct.
Now, as far I know, this didn't occur for ARM during bootstrap but only during
testing with make -k check.  Or else could this be a parallel compilation bug?

Could you post the list of files that differ?  How do they differ exactly?


Hmmm. Well, I definitely had this failing to bootstrap once. I repeated that, to 
try to identify exactly what the differences wereand it succeeded even with 
my pre-AAPCS64-update host compiler. So, this is probably a false alarm; I'm 
bootstrapping again, after a rebase, to make sure...


--Alan

C++ PATCH for c++/65687 (typedefs and attribute deprecated)

[Jason Merrill]

This BZ asks that the C++ front end follow the behavior of the C front 
end in handling typedefs that involve deprecated types: we should warn 
when defining the typedef, not when using it.  This seems reasonable, 
particularly since the C front end works this way.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit a2de40417b69ee1a42396ecbe8ca7e02a7541160
Author: Jason Merrill 
Date:   Thu Jan 21 14:45:05 2016 -0500

	PR c++/65687
	* decl.c (type_is_deprecated): Don't look into a typedef.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 020e9bd..f4604b6 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -11595,9 +11595,13 @@ type_is_deprecated (tree type)
   enum tree_code code;
   if (TREE_DEPRECATED (type))
 return type;
-  if (TYPE_NAME (type)
-  && TREE_DEPRECATED (TYPE_NAME (type)))
-return type;
+  if (TYPE_NAME (type))
+{
+  if (TREE_DEPRECATED (TYPE_NAME (type)))
+	return type;
+  else
+	return NULL_TREE;
+}
 
   /* Do warn about using typedefs to a deprecated class.  */
   if (OVERLOAD_TYPE_P (type) && type != TYPE_MAIN_VARIANT (type))
diff --git a/gcc/testsuite/g++.dg/warn/deprecated-10.C b/gcc/testsuite/g++.dg/warn/deprecated-10.C
new file mode 100644
index 000..55cdf3d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/deprecated-10.C
@@ -0,0 +1,14 @@
+// PR c++/65687
+
+typedef struct old_visible_stuff *opaquePointer;
+
+struct old_visible_stuff {
+  int things_we_no_longer;
+  int wish_to_expose;
+} __attribute__((__deprecated__("do not refer to this, the layout might change")));
+
+typedef struct old_visible_stuff *another; // { dg-warning "deprecated" }
+
+opaquePointer runtime_function (opaquePointer someObject);
+
+opaquePointer bad_runtime_call (struct old_visible_stuff *otherObject); // { dg-warning "deprecated" }

[PATCH] Reuse intermediate qualified DIEs even if they don't have corresponding tree type (PR debug/66668)

[Jakub Jelinek]

Hi!

This patch attempts to fix a regression caused by early debug info, where
DIEs are created sooner and some intermediate qualified types might not
exist yet.

Rather than creating further variant tree types, this patch arranges for the
qualified DIEs (DW_TAG_{atomic,restrict,volatile,const}_type with just
DW_AT_type) to be emitted next to the unqualified type's DIE, and as there
can be only a few (for ordered at most 10, for unordered at most 15), it is
not expensive to look whether we already have the right one around.

Furthermore, for -fdebug-types-section it ignores
get_nearest_type_subqualifiers result and uses unqualified type if
using the partially qualified one would lead to non-canonical order of the
qualifiers.

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

2016-01-21  Jakub Jelinek  

PR debug/8
* dwarf2out.c (add_child_die_after): New function.
(dwarf_qual_info_t): New type.
(dwarf_qual_info): New variable.
(qualified_die_p): New function.
(modified_type_die): For -fdebug-types-section, ensure
canonical order of qualifiers.  Put qualified DIEs adjacent
to the corresponding non-qualified type DIE and search there
for existing qualified DIEs.

--- gcc/dwarf2out.c.jj  2016-01-21 00:41:46.0 +0100
+++ gcc/dwarf2out.c 2016-01-21 12:35:37.229374047 +0100
@@ -4970,6 +4970,25 @@ add_child_die (dw_die_ref die, dw_die_re
   die->die_child = child_die;
 }
 
+/* Like add_child_die, but put CHILD_DIE after AFTER_DIE.  */
+
+static void
+add_child_die_after (dw_die_ref die, dw_die_ref child_die,
+dw_die_ref after_die)
+{
+  gcc_assert (die
+ && child_die
+ && after_die
+ && die->die_child
+ && die != child_die);
+
+  child_die->die_parent = die;
+  child_die->die_sib = after_die->die_sib;
+  after_die->die_sib = child_die;
+  if (die->die_child == after_die)
+die->die_child = child_die;
+}
+
 /* Unassociate CHILD from its parent, and make its parent be
NEW_PARENT.  */
 
@@ -11149,6 +11168,45 @@ get_nearest_type_subqualifiers (tree typ
   return best_qual;
 }
 
+struct dwarf_qual_info_t { int q; enum dwarf_tag t; };
+static const dwarf_qual_info_t dwarf_qual_info[] =
+{
+  { TYPE_QUAL_ATOMIC, DW_TAG_atomic_type },
+  { TYPE_QUAL_RESTRICT, DW_TAG_restrict_type },
+  { TYPE_QUAL_VOLATILE, DW_TAG_volatile_type },
+  { TYPE_QUAL_CONST, DW_TAG_const_type },
+};
+static const unsigned int dwarf_qual_info_size
+  = sizeof (dwarf_qual_info) / sizeof (dwarf_qual_info[0]);
+
+/* If DIE is a qualified DIE of some base DIE with the same parent,
+   return the base DIE, otherwise return NULL.  Set MASK to the
+   qualifiers added compared to the returned DIE.  */
+
+static dw_die_ref
+qualified_die_p (dw_die_ref die, int *mask, unsigned int depth)
+{
+  unsigned int i;
+  for (i = 0; i < dwarf_qual_info_size; i++)
+if (die->die_tag == dwarf_qual_info[i].t)
+  break;
+  if (i == dwarf_qual_info_size)
+return NULL;
+  if (vec_safe_length (die->die_attr) != 1)
+return NULL;
+  dw_die_ref type = get_AT_ref (die, DW_AT_type);
+  if (type == NULL || type->die_parent != die->die_parent)
+return NULL;
+  *mask |= dwarf_qual_info[i].q;
+  if (depth)
+{
+  dw_die_ref ret = qualified_die_p (type, mask, depth - 1);
+  if (ret)
+   return ret;
+}
+  return type;
+}
+
 /* Given a pointer to an arbitrary ..._TYPE tree node, return a debugging
entry that chains the modifiers specified by CV_QUALS in front of the
given type.  REVERSE is true if the type is to be interpreted in the
@@ -11255,31 +11313,97 @@ modified_type_die (tree type, int cv_qua
 
   if (cv_quals)
 {
-  struct qual_info { int q; enum dwarf_tag t; };
-  static const struct qual_info qual_info[] =
-   {
- { TYPE_QUAL_ATOMIC, DW_TAG_atomic_type },
- { TYPE_QUAL_RESTRICT, DW_TAG_restrict_type },
- { TYPE_QUAL_VOLATILE, DW_TAG_volatile_type },
- { TYPE_QUAL_CONST, DW_TAG_const_type },
-   };
-  int sub_quals;
+  int sub_quals = 0, first_quals = 0;
   unsigned i;
+  dw_die_ref first = NULL, last = NULL;
 
   /* Determine a lesser qualified type that most closely matches
 this one.  Then generate DW_TAG_* entries for the remaining
 qualifiers.  */
   sub_quals = get_nearest_type_subqualifiers (type, cv_quals,
  cv_qual_mask);
+  if (sub_quals && use_debug_types)
+   {
+ bool needed = false;
+ /* If emitting type units, make sure the order of qualifiers
+is canonical.  Thus, start from unqualified type if
+an earlier qualifier is missing in sub_quals, but some later
+one is present there.  */
+ for (i = 0; i < dwarf_qual_info_size; i++)
+   if (dwarf_qual_info[i].q & cv_quals & ~sub_quals)
+ needed = 

C++ PATCH for c++/43407 (scoped enum attributes)

[Jason Merrill]

We were complaining about attributes on C++11 scoped enums because 
start_enum gives them an underlying type, and thereby a TYPE_SIZE, 
immediately.  Fixed by passing early attributes to start_enum.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2a974c0078f1f7b39e7b4ef94fee8836faf5aa95
Author: Jason Merrill 
Date:   Tue Jan 19 17:29:04 2016 -0500

	PR c++/43407
	* decl.c (start_enum): Add attributes parameter.
	* parser.c (cp_parser_enum_specifier): Pass it.
	* pt.c (lookup_template_class_1): Pass it.
	* cp-tree.h: Adjust.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 51589c3..0aeee57 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5788,7 +5788,7 @@ extern bool grok_op_properties			(tree, bool);
 extern tree xref_tag(enum tag_types, tree, tag_scope, bool);
 extern tree xref_tag_from_type			(tree, tree, tag_scope);
 extern bool xref_basetypes			(tree, tree);
-extern tree start_enum(tree, tree, tree, bool, bool *);
+extern tree start_enum(tree, tree, tree, tree, bool, bool *);
 extern void finish_enum_value_list		(tree);
 extern void finish_enum(tree);
 extern void build_enumerator			(tree, tree, tree, tree, location_t);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index ceeef60..d995654 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13045,6 +13045,8 @@ copy_type_enum (tree dst, tree src)
the enumeration type. This should be NULL_TREE if no storage type
was specified.
 
+   ATTRIBUTES are any attributes specified after the enum-key.
+
SCOPED_ENUM_P is true if this is a scoped enumeration type.
 
if IS_NEW is not NULL, gets TRUE iff a new type is created.
@@ -13055,7 +13057,7 @@ copy_type_enum (tree dst, tree src)
 
 tree
 start_enum (tree name, tree enumtype, tree underlying_type,
-	bool scoped_enum_p, bool *is_new)
+	tree attributes, bool scoped_enum_p, bool *is_new)
 {
   tree prevtype = NULL_TREE;
   gcc_assert (identifier_p (name));
@@ -13163,6 +13165,8 @@ start_enum (tree name, tree enumtype, tree underlying_type,
 
   SET_SCOPED_ENUM_P (enumtype, scoped_enum_p);
 
+  cplus_decl_attributes (, attributes, (int)ATTR_FLAG_TYPE_IN_PLACE);
+
   if (underlying_type)
 {
   if (CP_INTEGRAL_TYPE_P (underlying_type))
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 8dd7e49..33f1df3 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -17132,7 +17132,7 @@ cp_parser_enum_specifier (cp_parser* parser)
brace so the enum will be recorded as being on the line of its
tag (or the 'enum' keyword, if there is no tag).  */
 type = start_enum (identifier, type, underlying_type,
-		   scoped_enum_p, _new_type);
+		   attributes, scoped_enum_p, _new_type);
 
   /* If the next token is not '{' it is an opaque-enum-specifier or an
  elaborated-type-specifier.  */
@@ -17248,7 +17248,6 @@ cp_parser_enum_specifier (cp_parser* parser)
   if (cp_parser_allow_gnu_extensions_p (parser))
 {
   tree trailing_attr = cp_parser_gnu_attributes_opt (parser);
-  trailing_attr = chainon (trailing_attr, attributes);
   cplus_decl_attributes (,
 			 trailing_attr,
 			 (int) ATTR_FLAG_TYPE_IN_PLACE);
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ae60f1c..7985198 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -214,6 +214,7 @@ static tree listify_autos (tree, tree);
 static tree tsubst_template_parm (tree, tree, tsubst_flags_t);
 static tree instantiate_alias_template (tree, tree, tsubst_flags_t);
 static bool complex_alias_template_p (const_tree tmpl);
+static tree tsubst_attributes (tree, tree, tsubst_flags_t, tree);
 
 /* Make the current scope suitable for access checking when we are
processing T.  T can be FUNCTION_DECL for instantiated function
@@ -8398,6 +8399,8 @@ lookup_template_class_1 (tree d1, tree arglist, tree in_decl, tree context,
 	  t = start_enum (TYPE_IDENTIFIER (template_type), NULL_TREE,
 			  tsubst (ENUM_UNDERLYING_TYPE (template_type),
   arglist, complain, in_decl),
+			  tsubst_attributes (TYPE_ATTRIBUTES (template_type),
+		 arglist, complain, in_decl),
 			  SCOPED_ENUM_P (template_type), NULL);
 
 	  if (t == error_mark_node)
@@ -9540,6 +9543,109 @@ can_complete_type_without_circularity (tree type)
 
 static tree tsubst_omp_clauses (tree, bool, bool, tree, tsubst_flags_t, tree);
 
+/* Instantiate a single dependent attribute T (a TREE_LIST), and return either
+   T or a new TREE_LIST, possibly a chain in the case of a pack expansion.  */
+
+static tree
+tsubst_attribute (tree t, tree *decl_p, tree args,
+		  tsubst_flags_t complain, tree in_decl)
+{
+  gcc_assert (ATTR_IS_DEPENDENT (t));
+
+  tree val = TREE_VALUE (t);
+  if (val == NULL_TREE)
+/* Nothing to do.  */;
+  else if ((flag_openmp || flag_openmp_simd || flag_cilkplus)
+	   && is_attribute_p ("omp declare simd",
+			  get_attribute_name (t)))
+{
+  tree clauses = TREE_VALUE (val);
+  clauses = tsubst_omp_clauses (clauses, true, 

[gcc-5-branch] [PATCH] Fix C++ __builtin_constant_p

[H.J. Lu]

wide-int.h has

  /* For fixed-precision integers like offset_int and widest_int,
 handle the case where the shift value is constant and the
 result is a single nonnegative HWI (meaning that we don't
 need to worry about val[1]).  This is particularly common
 for converting a byte count to a bit count.

 For variable-precision integers like wide_int, handle HWI
 and sub-HWI integers inline.  */
  if (__builtin_constant_p (xi.precision > HOST_BITS_PER_WIDE_INT)
  ? (__builtin_constant_p (shift < HOST_BITS_PER_WIDE_INT - 1)
 && xi.len == 1
 && xi.val[0] <= (HOST_WIDE_INT) ((unsigned HOST_WIDE_INT)
  HOST_WIDE_INT_MAX >>
shift))
  : precision <= HOST_BITS_PER_WIDE_INT)
{
  val[0] = xi.ulow () << shift;
  result.set_len (1);
}

__builtin_constant_p is miscompiled due to PR c++/65656, which leads
to PR 69399.  Backport the PR c++/65656 fix to gcc-5-branch fixes
PR 69399.  OK for gcc-5-branch if there is no regression on x86-64?

Thanks.


H.J.
--
We have two desires for interaction of __builtin_constant_p with
constexpr:  1) it should be a constant-expression even if its operands
are not, and 2) we shouldn't fold it to false prematurely when parsing a
constexpr function (c++/54021).  We were having trouble with both of
these, and this patch fixes #1 without breaking #2.

gcc/cp/

Backport from mainline
2015-04-28  Jason Merrill  

PR c++/65656
* constexpr.c (cxx_eval_builtin_function_call): Fix
__builtin_constant_p.

gcc/testsuite/

Backport from mainline
2015-04-28  Jason Merrill  

PR c++/65656
* g++.dg/cpp0x/constexpr-builtin3.C: New test.
---
 gcc/cp/constexpr.c  | 32 +
 gcc/testsuite/g++.dg/cpp0x/constexpr-builtin3.C |  6 +
 2 files changed, 28 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-builtin3.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 4ca99e8..3c9362e 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1024,7 +1024,7 @@ lookup_parameter_binding (const constexpr_call *call, 
tree t)
represented by _CST nodes.  */
 
 static tree
-cxx_eval_builtin_function_call (const constexpr_ctx *ctx, tree t,
+cxx_eval_builtin_function_call (const constexpr_ctx *ctx, tree t, tree fun,
bool lval,
bool *non_constant_p, bool *overflow_p)
 {
@@ -1032,18 +1032,30 @@ cxx_eval_builtin_function_call (const constexpr_ctx 
*ctx, tree t,
   tree *args = (tree *) alloca (nargs * sizeof (tree));
   tree new_call;
   int i;
-  for (i = 0; i < nargs; ++i)
+
+  /* Don't fold __builtin_constant_p within a constexpr function.  */
+  if (DECL_FUNCTION_CODE (fun) == BUILT_IN_CONSTANT_P
+  && current_function_decl
+  && DECL_DECLARED_CONSTEXPR_P (current_function_decl))
 {
-  args[i] = cxx_eval_constant_expression (ctx, CALL_EXPR_ARG (t, i),
- lval,
- non_constant_p, overflow_p);
-  if (ctx->quiet && *non_constant_p)
-   return t;
+  *non_constant_p = true;
+  return t;
 }
-  if (*non_constant_p)
-return t;
+
+  /* Be permissive for arguments to built-ins; __builtin_constant_p should
+ return constant false for a non-constant argument.  */
+  constexpr_ctx new_ctx = *ctx;
+  new_ctx.quiet = true;
+  bool dummy1 = false, dummy2 = false;
+  for (i = 0; i < nargs; ++i)
+args[i] = cxx_eval_constant_expression (_ctx, CALL_EXPR_ARG (t, i),
+   lval, , );
+
+  bool save_ffbcp = force_folding_builtin_constant_p;
+  force_folding_builtin_constant_p = true;
   new_call = fold_build_call_array_loc (EXPR_LOCATION (t), TREE_TYPE (t),
CALL_EXPR_FN (t), nargs, args);
+  force_folding_builtin_constant_p = save_ffbcp;
   VERIFY_CONSTANT (new_call);
   return new_call;
 }
@@ -1226,7 +1238,7 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree 
t,
 return void_node;
 
   if (is_builtin_fn (fun))
-return cxx_eval_builtin_function_call (ctx, t,
+return cxx_eval_builtin_function_call (ctx, t, fun,
   lval, non_constant_p, overflow_p);
   if (!DECL_DECLARED_CONSTEXPR_P (fun))
 {
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-builtin3.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-builtin3.C
new file mode 100644
index 000..3582525
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-builtin3.C
@@ -0,0 +1,6 @@
+// PR c++/65656
+// { dg-options "-std=c++11 -O" }
+
+int main(int argc, char *argv[]) {
+  constexpr bool x = __builtin_constant_p(argc);
+}
-- 
2.5.0

Re: [patch, fortran] PR65996 [5/6 Regression] gfortran ICE with -dH

[Jerry DeLisle]

On 01/18/2016 11:01 AM, Jerry DeLisle wrote:
> This patch follows the suggestion Jakub made in the PR and is very 
> straightforward.
> 

The patch is simple enough.  I will commit to trunk shortly if I hear from no 
one.

Regards,

Jerry

> With the patch, an abort is given on actual errors, in agreement with the
> documentation for -dH.
> (Yes, not very useful, but we can clear this PR)
> 
> Buffered errors bypass this abort by saving and restoring the state.
> 
> Regression tested on x86-64-linux.
> 
> OK for trunk and then back port to 5 in about a week?
> 
> A test case will be included, similar to that given by Dominique in the PR.
> 
> Regards,
> 
> Jerry
> 
> 2016-01-18  Jerry DeLisle  
> 
>   PR fortran/65996
>   * error.c (gfc_error): Save the state of abort_on_error and set
>   it to false for buffered errors to allow normal processing.
>   Restore the state before leaving.
> 

C++ PATCH for c++/40751 (can't change alignment of enum)

[Jason Merrill]

The problem here was that when copy_type_enum updates the size and 
alignment of the enum to match its underlying type, it was clobbering 
any explicit alignment.  I've fixed similar issues in other places, but 
this one needed the update as well.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0dc9dc45a5a9d2a0efc7456a72e13dab38551d4c
Author: Jason Merrill 
Date:   Thu Jan 21 14:22:05 2016 -0500

	PR c++/40751
	PR c++/64987
	* decl.c (copy_type_enum): Respect TYPE_USER_ALIGN.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index d995654..020e9bd 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13030,8 +13030,12 @@ copy_type_enum (tree dst, tree src)
   TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (src);
   SET_TYPE_MODE (dst, TYPE_MODE (src));
   TYPE_PRECISION (t) = TYPE_PRECISION (src);
-  TYPE_ALIGN (t) = TYPE_ALIGN (src);
-  TYPE_USER_ALIGN (t) = TYPE_USER_ALIGN (src);
+  unsigned valign = TYPE_ALIGN (src);
+  if (TYPE_USER_ALIGN (t))
+	valign = MAX (valign, TYPE_ALIGN (t));
+  else
+	TYPE_USER_ALIGN (t) = TYPE_USER_ALIGN (src);
+  TYPE_ALIGN (t) = valign;
   TYPE_UNSIGNED (t) = TYPE_UNSIGNED (src);
 }
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/alignas5.C b/gcc/testsuite/g++.dg/cpp0x/alignas5.C
new file mode 100644
index 000..2820ca7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alignas5.C
@@ -0,0 +1,6 @@
+// { dg-do compile { target c++11 } }
+
+#define SA(X) static_assert(X,#X)
+
+enum alignas(16) E {};
+SA(alignof(E) == 16);

Re: Backport PR63681 cfglayout/doloop fix to 4.9

[Jeff Law]

On 01/21/2016 10:53 AM, Bernd Schmidt wrote:

I've bootstrapped and tested the following on 4.9-branch. It's a
backport of a patch that avoids unnecessary assertion failures, both by
tuning down an assert, and restricting an optimization for the case
where the assert would validly trigger.

Ok to commit on the branch?

Yes.

jeff

[gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading" (was: [PATCH] Add fopt-info-oacc)

[Thomas Schwinge]

Hi!

On Mon, 18 Jan 2016 18:26:49 +0100, Tom de Vries  wrote:
> This patch introduces an option fopt-info-oacc.
> 
> When using the option like this with a kernels region in kernels-loop.c 
> that parloops does not manage to parallelize:
> ...
> $ gcc kernels-loop.c -S -O2 -fopenacc -fopt-info-oacc-all
> ...
> 
> we get a message:
> ...
> kernels-loop.c:23:9: note: kernels region executed sequentially. 
> Consider mapping it to host execution, to avoid data copy penalty.
> ...

Yay for helping the user understand what the compiler is doing!

> Any comments?

Telling from real-world code that we've been having a look at, when the
above situation happens, we're -- in the vast majority of all cases -- in
a situation where we generally want to avoid offloading (unless
explicitly requested), "to avoid data copy penalty" as well as typically
much slower single-threaded execution on the GPU.  Obviously, that will
have to be revisited as parloops (or any other mechanism in GCC) is able
to better understand/use the parallelism in OpenACC kernels constructs.

So, building upon Tom's patch, I have implemented an "avoid offloading"
flag given the presence of one un-parallelized OpenACC kernels construct.
This is currently only enabled for OpenACC kernels constructs, in
combination with nvptx offloading, but I think the general scheme will be
useful also for other constructs as well as other (non-shared memory)
offloading targets.

Also, "avoid offloading" is just a default: if a user explicitly
requested the use of, for example, a Nvidia GPU (with an
acc_init(acc_device_nvidia) call, or by setting the
ACC_DEVICE_TYPE=nvidia environemnt variable, for example), then we cannot
apply host-fallback execution, because in this case the user can
rightfully assume Nvidia GPU semantics (async clause works, and so on).


The new warning (very similar to the one that Tom proposed) also
uncovered a bunch of OpenACC kernels test cases in libgomp that did not
have OpenACC kernels processing enabled (-ftree-parallelize-loops), but
which parloops can handle fine once that is enabled -- and also a bunch
of OpenACC kernels test cases that parloops doesn't handle but it looked
as they were meant to be.  (Maybe I'm wrong about that, though.)  Anyway,
Tom, would you please make a note to audit all use of -foffload-force in
the libgomp testsuite?  (It is appropriate for all test cases that
parloops truely is not meant to handle, but for all others, that flag
should probably be removed and instead an XFAILed dg-bogus directive
added, so that we will notice (XPASS) once it does handle them.)


I've also added a new command-line option, -foffload-force, that restores
the current behavior, inhibits the "avoid offloading" handling.  This is
primarily meant for GCC (libgomp) testsuite usage, but could occasionally
also be useful for users.  Considering alternatives (that can be applied
in a more fine-grained way, case by case per OpenACC kernels construct):

1) a new GCC-specific pragma, for example:

#pragma GCC force offloading
#pragma acc kernels
  [un-parallelizable stuff]

2) a new GCC-specific clause, for example in the implementation
namespace, starting with "_":

#pragma acc kernels _force_offloading
  [un-parallelizable stuff]

..., the -foffload-force flag was the simplest solution.  (Because, if
you're going to alter the sources anyway, you might as well just remove
the one offending OpenACC kernels construct...)


Committed to gomp-4_0-branch in r232709:

commit 41a76d233e714fd7b79dc1f40823f607c38306ba
Author: tschwinge 
Date:   Thu Jan 21 21:52:50 2016 +

Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid 
offloading"

gcc/
* common.opt: Add -foffload-force.
* lto-wrapper.c (merge_and_complain, append_compiler_options):
Handle it.
* doc/invoke.texi: Document it.
* config/nvptx/mkoffload.c (struct id_map): Add "flags" member.
(record_id): Parse, and set it.
(process): Use it.
* config/nvptx/nvptx.c (nvptx_attribute_table): Add "omp avoid
offloading".
(nvptx_record_offload_symbol): Use it.
(nvptx_goacc_validate_dims): Set it.
libgomp/
* target.c (GOMP_offload_register_ver)
(GOMP_offload_unregister_ver, gomp_init_device)
(gomp_unload_device, gomp_offload_target_available_p): Handle and
document "avoid offloading" ("host_table == NULL").
(resolve_device): Document "avoid offloading".
* oacc-init.c (resolve_device): Likewise.
* libgomp.texi (Enabling OpenACC): Likewise.
* testsuite/libgomp.oacc-c-c++-common/avoid-offloading-1.c: New
file.
* testsuite/libgomp.oacc-c-c++-common/avoid-offloading-2.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/avoid-offloading-3.c:
Likewise.
* 

Re: [PATCH] Reuse intermediate qualified DIEs even if they don't have corresponding tree type (PR debug/66668)

[Jason Merrill]

On 01/21/2016 03:35 PM, Jakub Jelinek wrote:

+static const dwarf_qual_info_t dwarf_qual_info[] =
+{
+  { TYPE_QUAL_ATOMIC, DW_TAG_atomic_type },
+  { TYPE_QUAL_RESTRICT, DW_TAG_restrict_type },
+  { TYPE_QUAL_VOLATILE, DW_TAG_volatile_type },
+  { TYPE_QUAL_CONST, DW_TAG_const_type },
+};


Let's go ahead and move const to the top of this array; it should be 
much more common than the others.  OK with that change.


Jason

[PATCH] [PR tree-optimization/69347] Fix memory consumption in threader & minor speed improvement

[Jeff Law]

BZ69347 shows excessive memory consumption in the FSM threading code. 
The underlying problem has been there since the introduction of the FSM 
threader, but the increased reliance on the FSM threader has brought the 
issue to the forefront of things we need to look at.


Essentially the FSM bits, in two places, allocate vectors large enough 
for every basic block in the current function and does so each call into 
the FSM threader.  The vectors in question are filled with safe_push 
style operations, so it's safe to initialize them to any constant size. 
 I selected "10" entries.  Doing that brings the memory consumption 
*way* down.


Second, I noticed that record_temporary_equivalences has gotten 
considerably more expensive with its immediate-use walking.  I'm 
pondering how to bring that cost down, but in the mean time we can 
simply remove roughly 1/3 of the calls into the routine that were 
totally redundant.


We would call it from dom_opt_walker::thread_across_edge to record 
temporary equivalences related to the given edge.  Then we'd call 
::thread_across_edge from tree-ssa-threadedge.c, which in turn calls 
thread_through_normal_block which calls record_temporary_equivalences 
again on the same edge.


Bootstrapped and regression tested on x86_64.  Also verified no code 
generation differences on my bucket of .i files.  Installed on the trunk.


Jeff
commit 3ef2e1cc4f4c6904642891a4f779230737d50613
Author: law 
Date:   Thu Jan 21 22:21:55 2016 +

[PATCH] [PR tree-optimization/69347] Fix memory consumption in threader & 
minor speed improvement

PR middle-end/69347
* tree-ssa-dom.c (dom_opt_dom_walker::thread_across_edge): Avoid
useless call to record_temporary_equivalences.
* tree-ssa-threadbackward.c (find_jump_threads_backwards): Just
allocate 10 slots in the bb_path vector and let it grow as needed.
(fsm_find_control_statement_thread_paths): Similarly for the next_path
vector.

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

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 5f0d7c0..c3908ea 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,13 @@
+2016-01-21  Jeff Law  
+
+   PR middle-end/69347
+   * tree-ssa-dom.c (dom_opt_dom_walker::thread_across_edge): Avoid
+   useless call to record_temporary_equivalences.
+   * tree-ssa-threadbackward.c (find_jump_threads_backwards): Just
+   allocate 10 slots in the bb_path vector and let it grow as needed.
+   (fsm_find_control_statement_thread_paths): Similarly for the next_path
+   vector.
+
 2016-01-21  David Edelsohn  
 
* configure.ac (gcc_cv_as_powerpc_mfcrf, gcc_cv_as_machine_directive):
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index 3eeaa9c..84c9a6a 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -935,9 +935,6 @@ dom_opt_dom_walker::thread_across_edge (edge e)
   m_avail_exprs_stack->push_marker ();
   m_const_and_copies->push_marker ();
 
-  /* Traversing E may result in equivalences we can utilize.  */
-  record_temporary_equivalences (e, m_const_and_copies, m_avail_exprs_stack);
-
   /* With all the edge equivalences in the tables, go ahead and attempt
  to thread through E->dest.  */
   ::thread_across_edge (m_dummy_cond, e, false,
diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index 8d8aa30..8be57a0 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -142,7 +142,7 @@ fsm_find_control_statement_thread_paths (tree name,
   int e_count = 0;
   edge_iterator ei;
   vec *next_path;
-  vec_alloc (next_path, n_basic_blocks_for_fn (cfun));
+  vec_alloc (next_path, 10);
 
   /* When VAR_BB == LAST_BB_IN_PATH, then the first block in the path
 will already be in VISITED_BBS.  When they are not equal, then we
@@ -379,7 +379,7 @@ find_jump_threads_backwards (edge e)
 return;
 
   vec *bb_path;
-  vec_alloc (bb_path, n_basic_blocks_for_fn (cfun));
+  vec_alloc (bb_path, 10);
   vec_safe_push (bb_path, e->dest);
   hash_set *visited_bbs = new hash_set;
 

Re: [patch] Document restriction of scalar_storage_order

[Sandra Loosemore]

On 01/21/2016 09:34 AM, Eric Botcazou wrote:

Tested on x86_64-suse-linux, OK for the mainline?


2016-01-21  Eric Botcazou  

* doc/extend.texi (scalar_storage_order type attribute): Document
restriction on type punning and aliasing.



This patch is OK.

I wish somebody could fix the existing documentation for this attribute 
to use the present tense instead of the future to describe GCC's current 
behavior, though  :-S


-Sandra

Re: TR29124 C++ Special Maths - Make pull functions into global namespace.

[Ed Smith-Rowland]

On 01/21/2016 07:29 AM, Jonathan Wakely wrote:

On 20/01/16 20:30 -0500, Ed Smith-Rowland wrote:
Now that libstdc++ installs a proper math.h we can piggyback on that 
to put in the last bit of TR29124.


This patch adds the math special functions to c_compatibility/math.h 
in the global namespace.

I remove the XFAILs from the compile_2.cc tests.

This converts 21 XFAILs into 21 PASSes.

Tested on x86_64-linux.

I understand if this is too late.
I'll put it up on trunk and backport after stage 1 reopens.

Meanwhile I'll commit this to the tr29124 branch.


I'm inclined to say the change is OK for trunk now. We've added math.h
and we've added the special functions, it would be good if the two new
things work together.

However ...


Index: include/c_compatibility/math.h
===
--- include/c_compatibility/math.h(revision 232610)
+++ include/c_compatibility/math.h(working copy)
@@ -75,70 +75,71 @@
#endif

#if __STDCPP_WANT_MATH_SPEC_FUNCS__ == 1
-using std::assoc_laguerref


This doesn't look like the right patch, because these lines aren't in
the version on trunk.


I must have given you a negative patch relative to the tr29124 
branch...  Sigh.

I'll make a new one.
Those lines have to be *added*.
Sorry.

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

[James Greenhalgh]

On Thu, Jan 21, 2016 at 01:58:31PM -0600, Evandro Menezes wrote:
> Hi, James.
> 
> On 01/21/16 03:24, James Greenhalgh wrote:
> >On Wed, Jan 06, 2016 at 02:44:47PM -0600, Evandro Menezes wrote:
> >>On 01/06/2016 06:04 AM, Wilco Dijkstra wrote:
> Here's what I had in mind when I inquired about distinguishing FCMP from
> FCCMP.  As you can see in the patch, Exynos is the only target that
> cares about it, but I wonder if ThunderX or Xgene would too.
> 
> What do you think?
> >>>The new attributes look fine (I've got a similar outstanding change), 
> >>>however
> >>>please don't add them to non-AArch64 cores. We only need it for 
> >>>thunderx.md,
> >>>cortex-a53.md, cortex-a57.md, xgene1.md and exynos-m1.md.
> >> Add support for the FCCMP insn types
> >>
> >> 2016-01-04  Evandro Menezes  
> >>
> >> gcc/
> >> * config/aarch64/aarch64.md (fccmp): Change insn type.
> >> (fccmpe): Likewise.
> >> * config/aarch64/thunderx.md (thunderx_fcmp): Add
> >>"fccmp{s,d}" types.
> >> * config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
> >> * config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
> >> * config/arm/xgene1.md (xgene1_fcmp): Likewise.
> >> * config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn
> >>reservation.
> >> * config/arm/types.md (fccmps): Add new insn type.
> >> (fccmpd): Likewise.
> >>
> >>Got it.  Here's an updated patch.  Again, assuming that your
> >>original patch is in place.  Perhaps you can build on it.
> >If we don't have any targets which care about the fccmps/fccmpd split in
> >the code base, do we really need it? Can we just follow the example of
> >fcsel?
> 
> The Exynos M1 does care about the difference between FCMP and FCCMP,
> as can be seen in the patch.

> More explicitly:
> 
>(define_insn_reservation "exynos_m1_fp_cmp" 4
>   (and (eq_attr "tune" "exynosm1")
>(eq_attr "type" "fcmps, fcmpd"))
>   "em1_nmisc")
> 
>(define_insn_reservation "exynos_m1_fp_ccmp" 7
>   (and (eq_attr "tune" "exynosm1")
>(eq_attr "type" "fccmps, fccmpd"))
>   "em1_st, em1_nmisc")
> 

I think I was unclear. Your exynos-m1 model cares about splitting fcmp[s/d]
and fccmp, but it doesn't care about splitting fccmp in to fccmps/fccmpd. It
is the split to fccmps/fccmpd that I think is unneccesary at this time.

> >>diff --git a/gcc/config/arm/types.md b/gcc/config/arm/types.md
> >>index 321ff89..daf7162 100644
> >>--- a/gcc/config/arm/types.md
> >>+++ b/gcc/config/arm/types.md
> >>@@ -70,6 +70,7 @@
> >>  ; f_rint[d,s]double/single floating point rount to integral.
> >>  ; f_store[d,s]   double/single store to memory.  Used for VFP unit.
> >>  ; fadd[d,s]  double/single floating-point scalar addition.
> >>+; fccmp[d,s] double/single floating-point conditional compare.
> >Can we follow the convention fcsel uses of calling out "From ARMv8-A:"
> >for this type?
> >
> 
> I'm not sure I follow.  Though I didn't refer to the ISA spec, I
> used the description from it for the *fccmp* type.
> 
> Please, advise.

Something like:

; fccmpFrom ARMv8-A: floating point conditional compare.

Just to capture that this instruction is only available for cores implementing
ARMv8-A.

Thanks,
James

[wwwdocs] Use global CSS in gcc-5/porting_to.html (and thus restore color on gcc.gnu.org)

[Gerald Pfeifer]

Per the exchange we had two days ago.

Applied.

Gerald

Index: gcc-5/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/porting_to.html,v
retrieving revision 1.10
diff -u -r1.10 porting_to.html
--- gcc-5/porting_to.html   20 Apr 2015 22:12:57 -  1.10
+++ gcc-5/porting_to.html   21 Jan 2016 22:19:32 -
@@ -97,9 +97,9 @@
 This example now gives the following diagnostic:
 
 
-f.c:1:12: warning: inline function 
'foo' declared but never defined
+f.c:1:12: warning: inline function 
'foo' declared but never defined
inline int foo (void);
-  ^
+  ^
 
 
 Furthermore, there is a difference between extern inline and
@@ -197,9 +197,9 @@
 This example now gives the following diagnostic:
 
 
-w.c:4:10: warning: implicit declaration of 
function 'bar' [-Wimplicit-function-declaration]
+w.c:4:10: warning: implicit 
declaration of function 'bar' [-Wimplicit-function-declaration]
return bar ();
-  ^
+  ^
 
 
 To suppress this warning add the proper declaration:
@@ -223,11 +223,11 @@
 This example now gives the following diagnostic:
 
 
-q.c:1:1: warning: return type defaults to 
'int' [-Wimplicit-int]
+q.c:1:1: warning: return type defaults 
to 'int' [-Wimplicit-int]
foo (u)
-   ^
+   ^
 q.c: In function 'foo':
-q.c:1:1: warning: type of 'u' 
defaults to 'int' [-Wimplicit-int]
+q.c:1:1: warning: type of 'u' 
defaults to 'int' [-Wimplicit-int]
 
 
 To suppress this warning just add the proper types:
@@ -256,9 +256,9 @@
 This example now gives the following diagnostic:
 
 
-q.c:4:3: warning: 'return' with no 
value, in function returning non-void
+q.c:4:3: warning: 'return' with 
no value, in function returning non-void
return;
-   ^
+   ^
 
 
 The fix is either to specify a proper return value, or to declare the return
@@ -280,17 +280,17 @@
 We used to reject such code in C99/C11 mode:
 
 
-q.c:3:29: error: initializer element is not 
constant
+q.c:3:29: error: initializer element is 
not constant
static struct S s = (struct S) { .t = { 42 } };
-   ^
+   ^
 
 
 Note that using -Wpedantic will cause a warning be emitted:
 
 
-q.c:3:29: warning: initializer element is 
not constant [-Wpedantic]
+q.c:3:29: warning: initializer element 
is not constant [-Wpedantic]
static struct S s = (struct S) { .t = { 42 } };
-   ^
+   ^
 
 
 __STDC_VERSION__ macro
@@ -334,9 +334,9 @@
 
 
 
-q.c:7:10: warning: format '%a' 
expects argument of type 'float *', but argument 2 has type 'char 
**' [-Wformat=]
+q.c:7:10: warning: format '%a' 
expects argument of type 'float *', but argument 2 has type 'char 
**' [-Wformat=]
   scanf ("%as", s);
- ^
+ ^
 
 
 To use the dynamic allocation conversion specifier in C99 and C11, specify
@@ -358,9 +358,9 @@
 
 
 
-q.c:4:19: warning: ISO C does not support 
'__FUNCTION__' predefined identifier [-Wpedantic]
+q.c:4:19: warning: ISO C does not 
support '__FUNCTION__' predefined identifier [-Wpedantic]
   const char *s = __FUNCTION__;
-  ^
+  ^
 
 
 The fix is either to use the standard predefined identifier 
__func__

Re: [PATCH] fix #69251 - [6 Regression] ICE in unify_array_domain on a flexible array member

[Jason Merrill]

Can we reconsider the representation of flexible arrays?  Following the 
example of the C front-end is causing a lot of trouble, and using a null 
TYPE_DOMAIN seems more intuitive.


Jason

[PATCH, rs6000] Fix PR67489

[Bill Schmidt]

Hi,

The test case gcc.target/powerpc/p8vector-builtin-8.c needs to be
restricted to targets that support the __int128 keyword.  This was
wrongly being attempted with { dg-do compile { target int128 } } when
what's really wanted is { dg-require-effective-target int128 }.  With
this patch, the test no longer runs on 32-bit targets.

Tested on powerpc64-unknown-linux-gnu using -m32.  Is this ok for trunk?

Thanks,
Bill


2016-01-21  Bill Schmidt  

PR testsuite/67489
* gcc.target/powerpc/p8vector-builtin-8.c: Remove { target int128
} from dg-do compile directive, and instead add {
dg-require-effective-target int128 }.


Index: gcc/testsuite/gcc.target/powerpc/p8vector-builtin-8.c
===
--- gcc/testsuite/gcc.target/powerpc/p8vector-builtin-8.c   (revision 
232683)
+++ gcc/testsuite/gcc.target/powerpc/p8vector-builtin-8.c   (working copy)
@@ -1,5 +1,6 @@
-/* { dg-do compile { target int128 } } */
+/* { dg-do compile } */
 /* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-require-effective-target int128 } */
 /* { dg-options "-mpower8-vector -O2" } */
 
 #include 

Suspicious code in fold-const.c

[Andrew MacLeod]

I was trying the ttype prototype for static type checking on 
fold-const.c to see how long it would take me to convert such a large 
file, and it choked on this snippet of code in fold_unary_loc, around 
lines 7690-7711:


suspect code tagged with (*)

 if ((CONVERT_EXPR_CODE_P (code)
   || code == NON_LVALUE_EXPR)
  && TREE_CODE (tem) == COND_EXPR
  && TREE_CODE (TREE_OPERAND (tem, 1)) == code
  && TREE_CODE (TREE_OPERAND (tem, 2)) == code
  (*)  && ! VOID_TYPE_P (TREE_OPERAND (tem, 1))
  (*)  && ! VOID_TYPE_P (TREE_OPERAND (tem, 2))
  && (TREE_TYPE (TREE_OPERAND (TREE_OPERAND (tem, 1), 0))
  == TREE_TYPE (TREE_OPERAND (TREE_OPERAND (tem, 2), 0)))
  && (! (INTEGRAL_TYPE_P (TREE_TYPE (tem))
 && (INTEGRAL_TYPE_P
 (TREE_TYPE (TREE_OPERAND (TREE_OPERAND (tem, 
1), 0

 && TYPE_PRECISION (TREE_TYPE (tem)) <= BITS_PER_WORD)
  || flag_syntax_only))
tem = build1_loc (loc, code, type,
  build3 (COND_EXPR,
  TREE_TYPE (TREE_OPERAND
 (TREE_OPERAND (tem, 
1), 0)),

  TREE_OPERAND (tem, 0),
  TREE_OPERAND (TREE_OPERAND (tem, 
1), 0),

  TREE_OPERAND (TREE_OPERAND (tem, 2),
0)));

and with:
#define VOID_TYPE_P(NODE)  (TREE_CODE (NODE) == VOID_TYPE)

I don't think this is what was intended. it would expand into:

  && TREE_CODE (TREE_OPERAND (tem, 1)) == code
  && TREE_CODE (TREE_OPERAND (tem, 2)) == code
   && ! (TREE_CODE (TREE_OPERAND (tem, 1)) == VOID_TYPE)
   && ! (TREE_CODE (TREE_OPERAND (tem, 2)) == VOID_TYPE)

the latter two would be obviously true if the first 2 were true.

My guess is this is probably suppose to be
&& ! VOID_TYPE_P (TREE_TYPE (TREE_OPERAND (tem, 1)))
 && ! VOID_TYPE_P (TREE_TYPE (TREE_OPERAND (tem, 2)))

but I'm not sure.   Any guesses whats intended here?

Andrew

Re: [PATCH 4/5] Don't mark targets of unconditional jumps with side effects as FALLTHRU.

[Jeff Law]

On 01/21/2016 03:05 AM, Andreas Krebbel wrote:

On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:

When an unconditional jump with side effects targets an immediately
following label, rtl_tidy_fallthru_edge is called.  Since it has side
effects, it doesn't remove the jump, but the label is still marked
as fallthru.  This later causes a verification error.  Do nothing in this
case instead.

gcc/ChangeLog:

* cfgrtl.c (rtl_tidy_fallthru_edge): Bail for unconditional jumps
with side effects.


The change looks ok to me (although I'm not able to approve it). Could you 
please run regressions
tests on x86_64 with that change?

Perhaps a short comment in the code would be good.
I think the patch is technically fine, the question is does it fix a 
visible bug?  I read the series as new feature enablement so I put this 
patch into my gcc7 queue.


jeff

Re: [hsa merge 00/10] Merge of HSA branch

[Gerald Pfeifer]

On Tue, 19 Jan 2016, Richard Biener wrote:
> I think the merge warrants a NEWS entry on gcc.gnu.org/

...and gcc-6/changes.html. :-)

Martin, happy to help.  Want to propose some text (or even patch)?

Gerald

Re: [PATCH] fix #69251 - [6 Regression] ICE in unify_array_domain on a flexible array member

[Martin Sebor]

On 01/21/2016 04:19 PM, Jason Merrill wrote:

Can we reconsider the representation of flexible arrays?  Following the
example of the C front-end is causing a lot of trouble, and using a null
TYPE_DOMAIN seems more intuitive.


I remember running into at least one ICE in the middle end with
the alternate representation (null TYPE_DOMAIN).  At this late
stage I would worry about the fallout from that. It seems that
outside of 69251 and 69277 the problems are mostly triggered by
ill-formed code that wasn't being tested and I'm hoping that
the problems in the well-formed cases have been reported (and
with the patches I've sent fixed).

At the same time, based on some debugging I had to do for 69251
(ICE in unify_array_domain on a flexible array member) it seems
that it might make handling them in template easier.

Martin

Re: [PATCH, rs6000] Fix PR67489

[David Edelsohn]

On Thu, Jan 21, 2016 at 6:00 PM, Bill Schmidt
 wrote:
> Hi,
>
> The test case gcc.target/powerpc/p8vector-builtin-8.c needs to be
> restricted to targets that support the __int128 keyword.  This was
> wrongly being attempted with { dg-do compile { target int128 } } when
> what's really wanted is { dg-require-effective-target int128 }.  With
> this patch, the test no longer runs on 32-bit targets.
>
> Tested on powerpc64-unknown-linux-gnu using -m32.  Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> 2016-01-21  Bill Schmidt  
>
> PR testsuite/67489
> * gcc.target/powerpc/p8vector-builtin-8.c: Remove { target int128
> } from dg-do compile directive, and instead add {
> dg-require-effective-target int128 }.

Okay.

Thanks, David

Re: [PATCH, PR69110] Don't return NULL access_fns in dr_analyze_indices

[Tom de Vries]

On 13/01/16 09:42, Richard Biener wrote:

On Tue, 12 Jan 2016, Tom de Vries wrote:


On 12/01/16 14:04, Richard Biener wrote:

On Tue, 12 Jan 2016, Tom de Vries wrote:


On 12/01/16 12:22, Richard Biener wrote:

Doesnt' the same issue apply to


unsigned int *p;

static void __attribute__((noinline, noclone))
foo (void)
{
unsigned int z;

for (z = 0; z < N; ++z)
  ++(*p);
}

thus when we have a MEM_REF[p_1]?  SCEV will not analyze
its evolution to a POLYNOMIAL_CHREC and thus access_fns will
be NULL again.



I didn't manage to trigger this scenario, though I could probably make it
happen by modifying ftree-loop-im to work in one case (the load of the
value
of p) but not the other (the *p load and store).


I think avoiding a NULL access_fns is ok but it should be done
unconditionally, not only for the DECL_P case.


Ok, I'll retest and commit this patch.


Please add a comment as well.


Patch updated with comment.

During testing however, I ran into two testsuite regressions:

1.

-PASS: gfortran.dg/graphite/pr39516.f   -O  (test for excess errors)
+FAIL: gfortran.dg/graphite/pr39516.f   -O  (internal compiler error)
+FAIL: gfortran.dg/graphite/pr39516.f   -O  (test for excess errors)

AFAIU, this is a duplicate of PR68976.

Should I wait with committing the patch until PR68976 is fixed?


Yes - we shouldn't introduce new testsuite regressions willingly at this
point.



After r232659 (the fix for pr68692), the ICE no longer occurs.


2.

-XFAIL: gcc.dg/graphite/scop-pr66980.c scan-tree-dump-times graphite "number
of SCoPs: 1" 1
+XPASS: gcc.dg/graphite/scop-pr66980.c scan-tree-dump-times graphite "number
of SCoPs: 1" 1

AFAIU, this is not a real regression, but the testcase needs to be updated.
I'm not sure how. Sebastian, perhaps you have an idea there?


It looks like simply removing the xfail might be ok.  But the comment in
the testcase doesn't suggest its dependency analysis fault that the
situation is not handled so I'd like Sebastian to chime in (who also
should know the dependence code very well).



Sebastian,

Ping on the xfail -> xpass issue mentioned above.

I'd like to commit this ( 
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00762.html  ) patch. I'm 
currently retesting using r232712 as baseline.


Thanks,
- Tom

Re: [PATCH][ARM] Fix PR target/69403: Bug in thumb2_ior_scc_strict_it pattern

[Han Shen]

Hi Kyrill, the patched gcc generates correct asm for me for the test
case.  (I'll then build the whole system to see if other it-block
related bugs are gone too.)

One short question, the newly generated RTL for
x = x |(a)
will be
orr %0, %1, #1; it ; mov%D2\\t%0, %1 (b)

The cond in (a) should be the reverse of cond in(b), right?

Thanks for your quick fix.

Han

On Thu, Jan 21, 2016 at 9:51 AM, Kyrill Tkachov
 wrote:
> Hi all,
>
> In this wrong-code PR the pattern for performing
> x = x |  for -mrestrict-it is buggy and ends up writing 1 to the
> result register rather than orring it.
>
> The offending pattern is *thumb2_ior_scc_strict_it.
> My proposed solution is to rewrite it as a splitter, remove the
> alternative for the case where operands[1] and 0 are the same reg
> that emits the bogus:
> it ; mov%0, #1; it ; orr %0, %1
>
> to emit the RTL equivalent to:
> orr %0, %1, #1; it ; mov%D2\\t%0, %1
> while marking operand 0 as an earlyclobber operand so that it doesn't
> get assigned the same register as operand 1.
>
> This way we avoid the wrong-code, make the sequence better (by eliminating
> the move of #1 into a register
> and relaxing the constraints from 'l' to 'r' since only the register move
> has to be conditional).
> and still stay within the rules for arm_restrict_it.
>
> Bootstrapped and tested on arm-none-linux-gnueabihf configured
> --with-arch=armv8-a and --with-mode=thumb.
>
> Ok for trunk, GCC 5 and 4.9?
>
> Han, can you please try this out to see if it solves the problem on your end
> as well?
>
> Thanks,
> Kyrill
>
> 2016-01-21  Kyrylo Tkachov  
>
> PR target/69403
> * config/arm/thumb2.md (*thumb2_ior_scc_strict_it): Convert to
> define_insn_and_split.  Ensure operands[1] and operands[0] do not
> get assigned the same register.
>
> 2016-01-21  Kyrylo Tkachov  
>
> PR target/69403
> * gcc.c-torture/execute/pr69403.c: New test.



-- 
Han Shen |  Software Engineer |  shen...@google.com |  +1-650-440-3330

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

[Evandro Menezes]

On 01/21/16 16:07, James Greenhalgh wrote:

On Thu, Jan 21, 2016 at 01:58:31PM -0600, Evandro Menezes wrote:

Hi, James.

On 01/21/16 03:24, James Greenhalgh wrote:

On Wed, Jan 06, 2016 at 02:44:47PM -0600, Evandro Menezes wrote:

On 01/06/2016 06:04 AM, Wilco Dijkstra wrote:

Here's what I had in mind when I inquired about distinguishing FCMP from
FCCMP.  As you can see in the patch, Exynos is the only target that
cares about it, but I wonder if ThunderX or Xgene would too.

What do you think?

The new attributes look fine (I've got a similar outstanding change), however
please don't add them to non-AArch64 cores. We only need it for thunderx.md,
cortex-a53.md, cortex-a57.md, xgene1.md and exynos-m1.md.

 Add support for the FCCMP insn types

 2016-01-04  Evandro Menezes  

 gcc/
 * config/aarch64/aarch64.md (fccmp): Change insn type.
 (fccmpe): Likewise.
 * config/aarch64/thunderx.md (thunderx_fcmp): Add
"fccmp{s,d}" types.
 * config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
 * config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
 * config/arm/xgene1.md (xgene1_fcmp): Likewise.
 * config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn
reservation.
 * config/arm/types.md (fccmps): Add new insn type.
 (fccmpd): Likewise.

Got it.  Here's an updated patch.  Again, assuming that your
original patch is in place.  Perhaps you can build on it.

If we don't have any targets which care about the fccmps/fccmpd split in
the code base, do we really need it? Can we just follow the example of
fcsel?

The Exynos M1 does care about the difference between FCMP and FCCMP,
as can be seen in the patch.
More explicitly:

(define_insn_reservation "exynos_m1_fp_cmp" 4
   (and (eq_attr "tune" "exynosm1")
(eq_attr "type" "fcmps, fcmpd"))
   "em1_nmisc")

(define_insn_reservation "exynos_m1_fp_ccmp" 7
   (and (eq_attr "tune" "exynosm1")
(eq_attr "type" "fccmps, fccmpd"))
   "em1_st, em1_nmisc")


I think I was unclear. Your exynos-m1 model cares about splitting fcmp[s/d]
and fccmp, but it doesn't care about splitting fccmp in to fccmps/fccmpd. It
is the split to fccmps/fccmpd that I think is unneccesary at this time.


Indeed.  However, it seems to me that the jury is still out about the 
{s,d} suffix, isn't it?  Otherwise, whatever others deem better.  I 
myself am agnostic about it.



diff --git a/gcc/config/arm/types.md b/gcc/config/arm/types.md
index 321ff89..daf7162 100644
--- a/gcc/config/arm/types.md
+++ b/gcc/config/arm/types.md
@@ -70,6 +70,7 @@
  ; f_rint[d,s]double/single floating point rount to integral.
  ; f_store[d,s]   double/single store to memory.  Used for VFP unit.
  ; fadd[d,s]  double/single floating-point scalar addition.
+; fccmp[d,s] double/single floating-point conditional compare.

Can we follow the convention fcsel uses of calling out "From ARMv8-A:"
for this type?

I'm not sure I follow.  Though I didn't refer to the ISA spec, I
used the description from it for the *fccmp* type.

Something like:

; fccmpFrom ARMv8-A: floating point conditional compare.

Just to capture that this instruction is only available for cores implementing
ARMv8-A.



Got it.

Let me try this again:

   Add support for the FCCMP insn types

   2016-01-21  Evandro Menezes  

   gcc/
* config/aarch64/aarch64.md (fccmp): Change insn type.
(fccmpe): Likewise.
* config/aarch64/thunderx.md (thunderx_fcmp): Add
   "fccmp{s,d}" types.
* config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
* config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
* config/arm/xgene1.md (xgene1_fcmp): Likewise.
* config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn
   reservation.
* config/arm/types.md (fccmps): Add new insn type.
(fccmpd): Likewise.


Thank you,

--
Evandro Menezes

>From 14874dec3257c7b59aed4b7c610305f76bbbcf33 Mon Sep 17 00:00:00 2001
From: Evandro Menezes 
Date: Mon, 4 Jan 2016 18:44:30 -0600
Subject: [PATCH] Add support for the FCCMP insn types

2016-01-21  Evandro Menezes  

gcc/
	* config/aarch64/aarch64.md (fccmp): Change insn type.
	(fccmpe): Likewise.
	* config/aarch64/thunderx.md (thunderx_fcmp): Add "fccmp{s,d}" types.
	* config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
	* config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
	* config/arm/xgene1.md (xgene1_fcmp): Likewise.
	* config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn reservation.
	* config/arm/types.md (fccmps): Add new insn type.
	(fccmpd): Likewise.
---
 gcc/config/aarch64/aarch64.md  | 4 ++--
 gcc/config/aarch64/thunderx.md | 2 +-
 gcc/config/arm/cortex-a53.md   | 4 ++--
 gcc/config/arm/cortex-a57.md   | 2 +-
 

Re: [PATCH] fix #69405 - [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add

[Jakub Jelinek]

On Thu, Jan 21, 2016 at 10:37:47AM -0700, Jeff Law wrote:
> On 01/20/2016 10:00 PM, Martin Sebor wrote:
> >The attached patch avoids printing a diagnostic referencing the type
> >of an incompatible argument to the __atomic_xxx built-ins when the
> >argument is in error.  Doing otherwise causes an ICE as pointed out
> >in the bug, for both of which I am to blame.
> >
> >Martin
> >
> >gcc-69405.patch
> >
> >
> >gcc/testsuite/ChangeLog:
> >2016-01-20  Martin Sebor
> >
> > PR c/69405
> > * gcc.dg/sync-fetch.c: New test.
> >
> >gcc/c-family/ChangeLog:
> >2016-01-20  Martin Sebor
> >
> > PR c/69405
> > * c-common.c (sync_resolve_size): Avoid printing diagnostic about
> > an incompatible argument when the argument isn't a valid a tree
> > node.
> OK.

Note, the last "a" should go, "a valid tree node".  Furthermore, it seems
the last two lines of the c-family/ ChangeLog entry are not tab indented.

Jakub

Re: [PATCH], PowerPC IEEE 128-bit fp, #12 (default -mfloat128 on PowerPC-Linux)

[Michael Meissner]

This is the final patch (at least so far) that turns on -mfloat128 by default
for PowerPC Linux systems where the VSX instruction set is enabled.  As I
mentioned in the last email, because we don't build the __float128 emulator on
other systems, I didn't think it would be useful to make it the default.

I did a boostrap build/check with no regressions on a little endian power8
system.  Are the patches ok to check in?

[gcc]
2016-01-21   Michael Meissner  

* config/rs6000/rs6000.c (rs6000_option_override_internal): Enable
-mfloat128 by default on PowerPC Linux systems with the VSX
instruction enabled.

[gcc/testsuite]
2016-01-21   Michael Meissner  

* gcc.target/powerpc/float128-1.c: New test for IEEE 128-bit
floating point support.
* gcc.target/powerpc/float128-2.c: Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 232690)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -4236,6 +4236,15 @@ rs6000_option_override_internal (bool gl
}
 }
 
+  /* At present, we only build the __float128 emulator on PowerPC Linux.
+ Enable default __float128 support for PowerPC Linux systems, but not for
+ others.  */
+#ifdef POWERPC_LINUX
+  if (TARGET_VSX && !TARGET_FLOAT128
+  && (rs6000_isa_flags_explicit & OPTION_MASK_FLOAT128) == 0)
+rs6000_isa_flags |= OPTION_MASK_FLOAT128;
+#endif
+
   /* __float128 requires VSX support.  */
   if (TARGET_FLOAT128 && !TARGET_VSX)
 {
Index: gcc/testsuite/gcc.target/powerpc/float128-1.c
===
--- gcc/testsuite/gcc.target/powerpc/float128-1.c   (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/float128-1.c   (revision 0)
@@ -0,0 +1,147 @@
+/* { dg-do run { target { powerpc*-*-linux* } } } */
+/* { dg-require-effective-target ppc_float128_sw } */
+/* { dg-options "-mcpu=power7 -O2 -mfloat128 -static-libgcc" } */
+
+#ifdef DEBUG
+#include 
+#include 
+#include 
+#include 
+#endif
+
+#if !defined(__FLOAT128__) || !defined(_ARCH_PPC)
+static __float128
+pass_through (__float128 x)
+{
+  return x;
+}
+
+__float128 (*no_optimize) (__float128) = pass_through;
+#endif
+
+#ifdef DEBUG
+__attribute__((__noinline__))
+static void
+print_f128 (__float128 x)
+{
+  unsigned sign;
+  unsigned exponent;
+  uint64_t mantissa1;
+  uint64_t mantissa2;
+  uint64_t upper;
+  uint64_t lower;
+
+#if defined(_ARCH_PPC) && defined(__BIG_ENDIAN__)
+  struct ieee128 {
+uint64_t upper;
+uint64_t lower;
+  };
+
+#elif (defined(_ARCH_PPC) && defined(__LITTLE_ENDIAN__)) || defined(__x86_64__)
+  struct ieee128 {
+uint64_t lower;
+uint64_t upper;
+  };
+
+#else
+#error "Unknown system"
+#endif
+
+  union {
+__float128 f128;
+struct ieee128 s128;
+  } u;
+
+  u.f128 = x;
+  upper  = u.s128.upper;
+  lower  = u.s128.lower;
+
+  sign  = (unsigned)((upper >> 63) & 1);
+  exponent  = (unsigned)((upper >> 48) & uint64_t)1) << 16) - 1));
+  mantissa1 = (upper & uint64_t)1) << 48) - 1));
+  mantissa2 = lower;
+
+  printf ("%c 0x%.4x 0x%.12" PRIx64 " 0x%.16" PRIx64,
+ sign ? '-' : '+',
+ exponent,
+ mantissa1,
+ mantissa2);
+}
+#endif
+
+__attribute__((__noinline__))
+static void
+do_test (__float128 expected, __float128 got, const char *name)
+{
+  int equal_p = (expected == got);
+
+#ifdef DEBUG
+  printf ("Test %s, expected: ", name);
+  print_f128 (expected);
+  printf (" %5g, got: ", (double) expected);
+  print_f128 (got);
+  printf (" %5g, result %s\n",
+ (double) got,
+ (equal_p) ? "equal" : "not equal");
+#endif
+
+  if (!equal_p)
+__builtin_abort ();
+}
+
+
+int
+main (void)
+{
+  __float128 one   = 1.0q;
+  __float128 two   = 2.0q;
+  __float128 three = 3.0q;
+  __float128 four  = 4.0q;
+  __float128 five  = 5.0q;
+  __float128 add_result = (1.0q + 2.0q);
+  __float128 mul_result = ((1.0q + 2.0q) * 3.0q);
+  __float128 div_result = (((1.0q + 2.0q) * 3.0q) / 4.0q);
+  __float128 sub_result = 1.0q + 2.0q) * 3.0q) / 4.0q) - 5.0q);
+  __float128 neg_result = - sub_result;
+  __float128 add_xresult;
+  __float128 mul_xresult;
+  __float128 div_xresult;
+  __float128 sub_xresult;
+  __float128 neg_xresult;
+
+#if defined(__FLOAT128__) && defined(_ARCH_PPC)
+  __asm__ (" #prevent constant folding, %x0" : "+wa" (one));
+  __asm__ (" #prevent constant folding, %x0" : "+wa" (two));
+  __asm__ (" #prevent constant folding, %x0" : "+wa" (three));
+  __asm__ (" #prevent constant folding, %x0" : "+wa" (four));
+  __asm__ (" #prevent constant folding, %x0" : "+wa" (five));
+
+#else
+  one   = no_optimize (one);
+  two   = no_optimize (two);
+  three = no_optimize 

Re: [PATCH] Fix the remaining PR c++/24666 blockers (arrays decay to pointers too early)

[Patrick Palka]

On Thu, 21 Jan 2016, Jason Merrill wrote:


On 01/19/2016 10:30 PM, Patrick Palka wrote:

 * g++.dg/template/unify17.C: XFAIL.


Hmm, I'm not comfortable with deliberately regressing this testcase.


  template 
-void bar (void (T[5])); // { dg-error "array of 'void'" }
+void bar (void (T[5])); // { dg-error "array of 'void'" "" { xfail
*-*-* } }


Can we work it so that T[5] also is un-decayed in the DECL_ARGUMENTS of bar, 
but decayed in the TYPE_ARG_TYPES?


I think so, I'll try it.



Jason

[PATCH] #69290 - [6 Regression] ICE on invalid initialization of a flexible array member

[Martin Sebor]

The attached patch fixes another ICE triggered by an invalid
initialization of a flexible array member, and caused by making
the upper bound of the TYPE_DOMAIN() of such arrays null.

Martin

PS Jason, when you have a chance, there are two other patches
for similar P1 failures waiting for your review:

[PATCH] fix #69251 - [6 Regression] ICE in unify_array_domain on
  a flexible array member
  https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01348.html

[PATCH] fix #69253 - [6 Regression] ICE in
   cxx_incomplete_type_diagnostic initializing a flexible array
   member with empty string
   https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01325.html
PR c++/69290 - [6 Regression] ICE on invalid initialization of a flexible
array member

gcc/testsuite/ChangeLog:
2016-01-21  Martin Sebor  

	PR c++/69290
	* g++.dg/ext/flexary12.C: New test.

gcc/cp/ChangeLog:
2016-01-21  Martin Sebor  

	PR c++/69290
	* tree.c (array_of_runtime_bound_p): Handle flexible array members.
Index: gcc/cp/tree.c
===
--- gcc/cp/tree.c	(revision 232692)
+++ gcc/cp/tree.c	(working copy)
@@ -937,9 +937,12 @@ array_of_runtime_bound_p (tree t)
   tree dom = TYPE_DOMAIN (t);
   if (!dom)
 return false;
-  tree max = TYPE_MAX_VALUE (dom);
-  return (!potential_rvalue_constant_expression (max)
-	  || (!value_dependent_expression_p (max) && !TREE_CONSTANT (max)));
+  if (tree max = TYPE_MAX_VALUE (dom))
+return (!potential_rvalue_constant_expression (max)
+	|| (!value_dependent_expression_p (max) && !TREE_CONSTANT (max)));
+
+  /* Flexible array members have no upper bound.  */
+  return false;
 }
 
 /* Return a reference type node referring to TO_TYPE.  If RVAL is
Index: gcc/testsuite/g++.dg/ext/flexary12.C
===
--- gcc/testsuite/g++.dg/ext/flexary12.C	(revision 0)
+++ gcc/testsuite/g++.dg/ext/flexary12.C	(working copy)
@@ -0,0 +1,63 @@
+// PR c++/69290 - [6 Regression] g++ ICE on invalid initialization
+// of a flexible array member
+// { dg-do compile }
+
+// Suppress pedantic errors about initialization of a flexible array member.
+// { dg-options "-Wno-pedantic" }
+
+struct A {
+  int a [];  // { dg-error "flexible array member .A::a. in an otherwise empty .struct A." }
+};
+
+void f1 ()
+{
+  // This is the meat of the test from c++/69290:
+  struct A a
+= { "c" };   // { dg-error "invalid conversion from .const char\\*. to .int." }
+
+  (void)
+}
+
+
+// Exercise other forms of invalid initialization besides the one in the bug.
+struct B {
+  int n;
+  int a [];
+};
+
+void f2 ()
+{
+  struct B b1
+= { 0, "c" };   // { dg-error "invalid conversion from .const char\\*. to .int." }
+
+  (void)
+
+  const char s[] = "c";
+  struct B b2
+= { 0, s };   // { dg-error "invalid conversion from .const char\\*. to .int." }
+
+  (void)
+}
+
+struct D {
+  int a [];  // { dg-error "flexible array member .D::a. in an otherwise empty .struct D." }
+  D ();
+};
+
+D::D ():
+  a ("c")   // { dg-error "incompatible types in assignment of .const char \\\[2\\\]. to .int \\\[\\\]." }
+{ }
+
+
+template 
+struct C {
+  T a [];  // { dg-error "flexible array member" }
+};
+
+void f3 ()
+{
+  struct C cd
+= { "c" };   // { dg-error "cannot convert .const char\\*. to .double." }
+
+  (void)
+}