[c++-concepts] variable concepts

[Braden Obrzut]

This patch adds support for variable concepts.

There is a known issue that prevents concept variables from having 
requires expressions that have parameters.  This issue is not within the 
scope of this patch as it affects adhoc requires expressions as well.


2014-08-13  Braden Obrzut 

* gcc/cp/constraint.cc (deduce_constrained_parameter): Deduce concept
from variable concept template-id expressions.
(normalize_var): New.
(normalize_template_id): Identify variable concepts.
(build_concept_check): Handle variable concepts.
(finish_shorthand_requirement): Handle variable concepts.
(diagnose_var): New.
(diagnose_node): Identify variable concepts.
* gcc/cp/decl.c (grokvardecl): Pass concept flag through to
check_explicit_specialization.
(grokdeclarator): Allow variable concepts and pass concept flag through
grokvardecl.
* gcc/cp/parser.c (cp_is_constrained_parameter): Accept variable
concepts.
(cp_parser_nonclass_name): Accept variable concepts.
(get_concept_from_constraint): Handle variable concepts.
* gcc/cp/pt.c (tsubst_copy_and_build): Lookup variable templates.
(value_dependent_expression_p): Check requires expressions for value
dependence.
* gcc/cp/semantics.c (finish_call_expr): Don't instantiate variable
templates if processing a template declaration.
* gcc/testsuite/g++.dg/concepts/decl-diagnose.C: Change expected error
as variable concepts are now handled.
* gcc/testsuite/g++.dg/concepts/var-concepts1.C: New test.
* gcc/testsuite/g++.dg/concepts/var-concepts2.C: New test.

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 5cbd6e6..8a28023 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -198,29 +198,44 @@ resolve_constraint_check (tree call)
   return resolve_constraint_check (ovl, args);
 }
 
-// Given a call expression to a concept, possibly including a placeholder
-// argument, deduce the concept being checked and the prototype paraemter.
-// Returns true if the constraint and prototype can be deduced and false
-// otherwise. Note that the CHECK and PROTO arguments are set to NULL_TREE
-// if this returns false.
+// Given a call expression or template-id expression to a concept, EXPR,
+// possibly including a placeholder argument, deduce the concept being checked
+// and the prototype paraemter.  Returns true if the constraint and prototype
+// can be deduced and false otherwise. Note that the CHECK and PROTO arguments
+// are set to NULL_TREE if this returns false.
 bool
-deduce_constrained_parameter (tree call, tree& check, tree& proto)
+deduce_constrained_parameter (tree expr, tree& check, tree& proto)
 {
-  // Resolve the constraint check to deduce the declared parameter.
-  if (tree info = resolve_constraint_check (call))
+  if (TREE_CODE (expr) == TEMPLATE_ID_EXPR)
 {
-  // Get function and argument from the resolved check expression and
-  // the prototype parameter. Note that if the first argument was a
-  // pack, we need to extract the first element ot get the prototype.
-  check = TREE_VALUE (info);
-  tree arg = TREE_VEC_ELT (TREE_PURPOSE (info), 0);
-  if (ARGUMENT_PACK_P (arg))
-arg = TREE_VEC_ELT (ARGUMENT_PACK_ARGS (arg), 0);
-  proto = TREE_TYPE (arg);
+  // Get the check and prototype parameter from the variable template.
+  tree decl = TREE_OPERAND (expr, 0);
+  tree parms = DECL_TEMPLATE_PARMS (decl);
+
+  check = DECL_TEMPLATE_RESULT (decl);
+  proto = TREE_VALUE (TREE_VEC_ELT (TREE_VALUE (parms), 0));
   return true;
 }
-  check = proto = NULL_TREE;
-  return false;
+  else if (TREE_CODE (expr) == CALL_EXPR)
+{
+  // Resolve the constraint check to deduce the prototype parameter.
+  if (tree info = resolve_constraint_check (expr))
+{
+  // Get function and argument from the resolved check expression and
+  // the prototype parameter. Note that if the first argument was a
+  // pack, we need to extract the first element ot get the prototype.
+  check = TREE_VALUE (info);
+  tree arg = TREE_VEC_ELT (TREE_PURPOSE (info), 0);
+  if (ARGUMENT_PACK_P (arg))
+arg = TREE_VEC_ELT (ARGUMENT_PACK_ARGS (arg), 0);
+  proto = TREE_TYPE (arg);
+  return true;
+}
+  check = proto = NULL_TREE;
+  return false;
+}
+  else
+gcc_unreachable ();
 }
 
 // -- //
@@ -246,6 +261,7 @@ tree normalize_requires (tree);
 tree normalize_expr_req (tree);
 tree normalize_type_req (tree);
 tree normalize_nested_req (tree);
+tree normalize_var (tree);
 tree normalize_template_id (tree);
 tree normalize_stmt_list (tree);
 
@@ -439,6 +455,36 @@ normalize_call (tree t)
   return result;
 }
 
+// Reduction rules for a variable template-id T.
+//
+// If T is a constraint, instantiate its initializer and recursively reduce its
+// 

Re: [PATCH] libstdc++: add uniform on sphere distribution

[Bin.Cheng]

On Sun, Aug 10, 2014 at 2:00 AM, Ulrich Drepper  wrote:
> On Sat, Aug 9, 2014 at 1:40 PM, Marc Glisse  wrote:
>> __x = result_type(2.0) * __aurng() - 1.0;
>
> You're right, we of course need the negatives as well.
>
>> Assuming the 2 coordinates are obtained through a rescaling x->2*x-1, if
>> __sq is not exactly 0, it must be between 2^-103 and 1 (for ieee
>> double), so I am not sure hypot gains that much (at least in my mind
>> hypot was mostly a gain close to 0 or infinity, but maybe it has more
>> advantages). It can only hurt speed though, so not a big issue.
>
> Depending on how similar in size the two values are, not using hypot()
> can drop quite a few bits.  Especially with the scaling through
> division this error can be noticeable.  Better be sure.  Maybe at some
> point I have time to investigate the worst case scenario for the
> numbers in question but until this shows hypot isn't needed it's best
> to leave it in.
>
> I've committed the patch.

Hi,

This causes lots of tests under libstdc++-v3/testsuite/ext/ failed on
aarch64-none-elf and arm-none-eabi with below log message.

In file included from
/home/binche01/work/oban-work/build-aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/ext/random:3494:0,
 from
/home/binche01/work/oban-work/src/gcc/libstdc++-v3/testsuite/ext/random/arcsine_distribution/cons/default.cc:23:
/home/binche01/work/oban-work/src/gcc/libstdc++-v3/include/ext/random.tcc:
In member function
'__gnu_cxx::{anonymous}::uniform_on_sphere_helper<2ul,
_RealType>::result_type
__gnu_cxx::{anonymous}::uniform_on_sphere_helper<2ul,
_RealType>::operator()(_NormalDistribution&,
_UniformRandomNumberGenerator&)':
/home/binche01/work/oban-work/src/gcc/libstdc++-v3/include/ext/random.tcc:1609:18:
error: 'hypot' is not a member of 'std'
auto __norm = std::hypot(__ret[0], __ret[1]);
  ^
/home/binche01/work/oban-work/src/gcc/libstdc++-v3/include/ext/random.tcc:1609:18:
note: suggested alternative:
In file included from
/home/binche01/work/oban-work/build-aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/cmath:44:0,
 from
/home/binche01/work/oban-work/build-aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/random:38,
 from
/home/binche01/work/oban-work/build-aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/ext/random:38,
 from
/home/binche01/work/oban-work/src/gcc/libstdc++-v3/testsuite/ext/random/arcsine_distribution/cons/default.cc:23:
/home/binche01/work/oban-work/target-aarch64-none-elf/aarch64-none-elf/include/math.h:306:15:
note:   'hypot'
 extern double hypot _PARAMS((double, double));
   ^

FAIL: ext/random/arcsine_distribution/cons/default.cc (test for excess errors)
Excess errors:
/home/binche01/work/oban-work/src/gcc/libstdc++-v3/include/ext/random.tcc:1609:18:
error: 'hypot' is not a member of 'std'

Thanks,
bin

Re: [PATCH] libstdc++: add uniform on sphere distribution

[Bin.Cheng]

On Wed, Aug 13, 2014 at 3:36 PM, Bin.Cheng  wrote:
> On Sun, Aug 10, 2014 at 2:00 AM, Ulrich Drepper  wrote:
>> On Sat, Aug 9, 2014 at 1:40 PM, Marc Glisse  wrote:
>>> __x = result_type(2.0) * __aurng() - 1.0;
>>
>> You're right, we of course need the negatives as well.
>>
>>> Assuming the 2 coordinates are obtained through a rescaling x->2*x-1, if
>>> __sq is not exactly 0, it must be between 2^-103 and 1 (for ieee
>>> double), so I am not sure hypot gains that much (at least in my mind
>>> hypot was mostly a gain close to 0 or infinity, but maybe it has more
>>> advantages). It can only hurt speed though, so not a big issue.
>>
>> Depending on how similar in size the two values are, not using hypot()
>> can drop quite a few bits.  Especially with the scaling through
>> division this error can be noticeable.  Better be sure.  Maybe at some
>> point I have time to investigate the worst case scenario for the
>> numbers in question but until this shows hypot isn't needed it's best
>> to leave it in.
>>
>> I've committed the patch.
>
> Hi,
>
> This causes lots of tests under libstdc++-v3/testsuite/ext/ failed on
> aarch64-none-elf and arm-none-eabi with below log message.
>
> In file included from
> /home/binche01/work/oban-work/build-aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/ext/random:3494:0,
>  from
> /home/binche01/work/oban-work/src/gcc/libstdc++-v3/testsuite/ext/random/arcsine_distribution/cons/default.cc:23:
> /home/binche01/work/oban-work/src/gcc/libstdc++-v3/include/ext/random.tcc:
> In member function
> '__gnu_cxx::{anonymous}::uniform_on_sphere_helper<2ul,
> _RealType>::result_type
> __gnu_cxx::{anonymous}::uniform_on_sphere_helper<2ul,
> _RealType>::operator()(_NormalDistribution&,
> _UniformRandomNumberGenerator&)':
> /home/binche01/work/oban-work/src/gcc/libstdc++-v3/include/ext/random.tcc:1609:18:
> error: 'hypot' is not a member of 'std'
> auto __norm = std::hypot(__ret[0], __ret[1]);
>   ^
> /home/binche01/work/oban-work/src/gcc/libstdc++-v3/include/ext/random.tcc:1609:18:
> note: suggested alternative:
> In file included from
> /home/binche01/work/oban-work/build-aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/cmath:44:0,
>  from
> /home/binche01/work/oban-work/build-aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/random:38,
>  from
> /home/binche01/work/oban-work/build-aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/ext/random:38,
>  from
> /home/binche01/work/oban-work/src/gcc/libstdc++-v3/testsuite/ext/random/arcsine_distribution/cons/default.cc:23:
> /home/binche01/work/oban-work/target-aarch64-none-elf/aarch64-none-elf/include/math.h:306:15:
> note:   'hypot'
>  extern double hypot _PARAMS((double, double));
>^
>
> FAIL: ext/random/arcsine_distribution/cons/default.cc (test for excess errors)
> Excess errors:
> /home/binche01/work/oban-work/src/gcc/libstdc++-v3/include/ext/random.tcc:1609:18:
> error: 'hypot' is not a member of 'std'
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62118 filed.

Thanks,
bin

Re: [PATCH, ARM] Keep constants in register when expanding

[Zhenqiang Chen]

On 12 August 2014 17:24, Richard Earnshaw  wrote:
> On 05/08/14 10:31, Zhenqiang Chen wrote:
>> Hi,
>>
>> For some large constants, ARM will split them during expanding, which
>> makes impossible to hoist them out the loop or shared by different
>> references (refer the test case in the patch).
>>
>> The patch keeps some constants in registers. If the constant can not
>> be optimized, the cprop and combine passes can optimize them as what
>> we do in current expand pass with
>>
>> define_insn_and_split "*arm_subsi3_insn"
>> define_insn_and_split "*arm_andsi3_insn"
>> define_insn_and_split "*iorsi3_insn"
>> define_insn_and_split "*arm_xorsi3"
>>
>> The patch does not modify addsi3 since the define_insn_and_split
>> "*arm_addsi3" is only valid when (reload_completed ||
>> !arm_eliminable_register (operands[1])). The cprop and combine passes
>> can not optimize the large constant if we put it in register, which
>> will lead to regression.
>>
>> For logic operators, the patch skips changes for constants:
>>
>> INTVAL (operands[2]) < 0 && const_ok_for_arm (-INTVAL (operands[2])
>>
>> since expand pass always uses "sign-extend" to get the value
>> (trunc_int_for_mode called from immed_wide_int_const) for rtl, and
>> logs show most negative values are UNSIGNED when they are TREE node.
>> And combine pass is smart enough to recover the negative value to
>> positive value.
>>
>> Bootstrap and no make check regression on Chrome book.
>> For coremark, dhrystone and eembcv1, no any code size and performance
>> change on Cortex-M4.
>> No any file in CSiBE has code size change for Cortex-A15 and Cortex-M4.
>> No Spec2000 performance regression on Chrome book and dumped assemble
>> codes only show very few difference.
>>
>> OK for trunk?
>>
>
> Not yet.
>
> I think the principle is sound, but there are some issues that need
> sorting out.
>
> 1) We shouldn't do this when not optimizing; there's no advantage to
> hoisting out the constants in that case.  Indeed, it may not be
> worth-while at -O1 either.

Updated. Only apply it when optimize >= 2

> 2) I think you should be using const_ok_for_op rather than working
> through all the permitted values.  If that function isn't doing the
> right thing, then it probably needs extending to handle those cases as well.

There are some difference. I want to filter cases for which
arm_split_constant will get better result. Patch is updated to add a
function const_ok_for_split, in which

(i < 0) && const_ok_for_arm (-i) and 0x can not fit into const_ok_for_op.

> 3) Why haven't you handled addsi3?

As I had mentioned in the original mail, since the
define_insn_and_split "*arm_addsi3" is only valid when
(reload_completed || !arm_eliminable_register (operands[1])). The
cprop and combine passes can not optimize the large constant if we put
it in register (and it is not hoisted out of the loop), which will
lead to regression.

Any reason for *arm_addsi3 with additional condition (reload_completed
|| !arm_eliminable_register (operands[1]))? Without it, addsi3 can be
handled as subsi3.

> See below for some specific comments.

All are updated.

Thanks!
-Zhenqiang

>>
>> ChangeLog:
>> 2014-08-05  Zhenqiang Chen  
>>
>> * config/arm/arm.md (subsi3, andsi3, iorsi3, xorsi3): Keep some
>> large constants in register other than split them.
>>
>> testsuite/ChangeLog:
>> 2014-08-05  Zhenqiang Chen  
>>
>> * gcc.target/arm/maskdata.c: New test.
>>
>>
>> skip-split.patch
>>
>>
>> diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
>> index bd8ea8f..c8b3001 100644
>> --- a/gcc/config/arm/arm.md
>> +++ b/gcc/config/arm/arm.md
>> @@ -1162,9 +1162,16 @@
>>  {
>>if (TARGET_32BIT)
>>  {
>> -  arm_split_constant (MINUS, SImode, NULL_RTX,
>> -   INTVAL (operands[1]), operands[0],
>> -   operands[2], optimize && can_create_pseudo_p ());
>> +   if (!const_ok_for_arm (INTVAL (operands[1]))
>> +   && can_create_pseudo_p ())
>> + {
>> +   operands[1] = force_reg (SImode, operands[1]);
>> +   emit_insn (gen_subsi3 (operands[0], operands[1], operands[2]));
>
> The final emit_insn shouldn't be be needed.  Once you've forced
> operands[1] into a register, you can just fall out the bottom of the
> pattern and let the default expansion take over.  But...
>> + }
>> +   else
>> + arm_split_constant (MINUS, SImode, NULL_RTX,
>> + INTVAL (operands[1]), operands[0], operands[2],
>> + optimize && can_create_pseudo_p ());
>>DONE;
>
> ... You'll need to move the DONE inside the else clause.
>
>>   }
>>else /* TARGET_THUMB1 */
>> @@ -2077,6 +2084,17 @@
>> emit_insn (gen_thumb2_zero_extendqisi2_v6 (operands[0],
>>operands[1]));
>>   }
>> +   else if (!(const_ok_for_arm (INTVAL (operands[2]))
>> +  

Re: [PATCH] cygwin: fix --tsaware, add --large-address-aware

[Kai Tietz]

2014-08-13 7:14 GMT+02:00 Yaakov Selkowitz :
> This patch fixes two issues with LINK_SPEC on Cygwin targets:
>
> 1) --tsaware makes sense only for EXEs, not DLLs.
>
> 2) Under WoW64 (32-bit Cygwin on 64-bit Windows), Cygwin applications can
> access up to 4 GiB of address space (for DLLs, Cygwin heap, mmap()s, etc.)
> if they are linked with --large-address-aware.  Because of how Cygwin
> implements fork(), the ability to use this extra space is a huge benefit.
> This flag too is only for EXEs, not DLLs.
>
> Patch attached.
>
> --
> Yaakov Selkowitz
> Associate Software Engineer, ARM
> Red Hat, Inc.

Hi Yaakov,

patch is ok.  I will apply it for you today.

Thanks,
Kai

RE: [PATCH, ARM] Fix incorrect alignment of small values in minipool

[Thomas Preud'homme]

> From: Richard Earnshaw
> Sent: Monday, August 11, 2014 4:54 PM
> 
> I think this is the wrong place for this sort of fix up.  HFmode values
> are fixed up in the consttable_4 pattern and it looks wrong to be that
> HImode values are then fixed up in a different place.  We should be
> consistent and do all the fix ups in one location.

Sorry for the delay in answering.

The problem is that in the pattern for constable_4 we don't have the information
about the access mode for this entry. In the testcase along this patch the rtx
manipulated in the pattern is VOIDmode while the access mode is HImode. In
dump_minipool on the other hand the information can be found in mp->mode.

Best regards,

Thomas

Re: [GSoC] Elimination of CLooG library installation dependency

[Roman Gareev]

If I’m not mistaken all tree nodes, which have pointer type, can be
divided into two groups:  the type is a  is a pointer to data member
(TYPE_PTRMEM_P is true for it),  the type is a pointer type, and the
pointee is not a data member (TYPE_PTR_P is true for it). I think that
we’re interested in disabling of the second group handling. It can
also be divided into two  groups:  the type is a pointer to function
type (TYPE_PTRFN_P is true for it), the type is a pointer to object
type (TYPE_PTROB_P is true for it). In my opinion, the second one is
worth to be considered. It contains, for example, nop_expr (these
nodes are used to represent conversions that do not require any
code-generation) integer_cst (these nodes represent integer
constants), ssa_name. I haven’t found all types, which are contained
in it. However, I think that we could disable other types, if it is
necessary in the future.

> What we should do later is to build a run-time check that ensures
> no pointer overflow is happening and then just create code without it.

I think that it is better to do this when the pointer handling is completed.

I’ve attached a Change_Log, which corresponds to the previous patch.
Are they fine for trunk? Could we give a headsup on the GCC mailing
list and ask other people to try the new isl support in case this
patch is committed?

-- 
Cheers, Roman Gareev.
2014-07-12  Roman Gareev  

gcc/
* graphite-scop-detection.c:
Add inclusion of cp-tree.h.
(graphite_can_represent_scev): Disables the handling of SSA_NAME nodes
in case they are pointers to object types.

Re: Fix libgomp crash without TLS (PR42616)

[Varvara Rainchik]

*Ping*

Thanks,
Varvara

2014-08-06 14:05 GMT+04:00 Varvara Rainchik :
> Hi,
>
> The issue was firstly observed on NDK gcc since TLS is not supported
> in Android bionic. I also see the same failure on gcc configured for
> linux with –disable-tls, libgomp make check log:
>
> FAIL: libgomp.c/affinity-1.c execution test
> FAIL: libgomp.c/icv-2.c execution test
> FAIL: libgomp.c/lock-3.c execution test
> FAIL: libgomp.c/target-6.c execution test
>
> These tests except affinity-1.c fail because gomp_thread () function
> returns null pointer. I’ve found 2 bugs, first one addresses this
> problem on Windows:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616;
> second one addresses original problem (for both cases, with and without TLS):
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36242.
> Tests from both bugs fail with –disable-tls. So, it seems that non TLS
> case was fixed just partially. The following patch solves the problem.
> With this patch 3 tests from make check pass, affinity-1.c fails, but
> I think it’s other non TLS problem.
> Changes are bootstrapped and regtested on x86_64-linux.
>
>
> 2014-08-06  Varvara Rainchik  
>
> * libgomp.h (gomp_thread): For non TLS case create thread data.
> * team.c (create_non_tls_thread_data): New function.
>
>
> ---
> diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h
> index a1482cc..cf3ec8f 100644
> --- a/libgomp/libgomp.h
> +++ b/libgomp/libgomp.h
> @@ -479,9 +479,15 @@ static inline struct gomp_thread *gomp_thread (void)
> }
> #else
> extern pthread_key_t gomp_tls_key;
> +extern struct gomp_thread *create_non_tls_thread_data (void);
> static inline struct gomp_thread *gomp_thread (void)
> {
> -  return pthread_getspecific (gomp_tls_key);
> +  struct gomp_thread *thr = pthread_getspecific (gomp_tls_key);
> +  if (thr == NULL)
> +  {
> +thr = create_non_tls_thread_data ();
> +  }
> +  return thr;
> }
> #endif
>
> diff --git a/libgomp/team.c b/libgomp/team.c
> index e6a6d8f..bf8bd4b 100644
> --- a/libgomp/team.c
> +++ b/libgomp/team.c
> @@ -927,6 +927,17 @@ initialize_team (void)
>  gomp_fatal ("could not create thread pool destructor.");
> }
>
> +#ifndef HAVE_TLS
> +struct gomp_thread *create_non_tls_thread_data (void)
> +{
> +  struct gomp_thread *thr = gomp_malloc (sizeof (struct gomp_thread));
> +  pthread_setspecific (gomp_tls_key, thr);
> +  gomp_sem_init (&thr->release, 0);
> +
> +  return thr;
> +}
> +#endif
> +
> static void __attribute__((destructor))
> team_destructor (void)
> {
> ---
>
>
> Is it ok?
>
>
> Best regards,
>
> Varvara

Re: [PATCH i386 AVX512] [7/n] Extend mask logic.

[Kirill Yukhin]

Hello Uroš,
On 12 Aug 20:06, Uros Bizjak wrote:
> Please leave TARGET_AVX512F in the insn constraint, it shortcuts the
> pattern recognition for non AVX512F targets.
Sure, removed (will bootstrap, regtest before check in).

> > (set_attr "prefix" "vex")])
> > @@ -7580,10 +7607,10 @@
> >  })
> 
> The patterns above can be macroized using conditional modes, but we
> can live with the above for now. Maybe add a TODO marker here.
I'll add a TODO and we'll try to implement it in 5.0


Thanks for review!

--
K

RE: [PATCH] Fix incorrect folding of bitfield in a union on big endian target

[Thomas Preud'homme]

> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Monday, August 11, 2014 8:29 PM
> 
> That's now extra compares (the operand_equal_p check now does
> a check that can be derived transitively).
> 
> So - ok with the operand_equal_p cehck removed.
> 
> Also see if this can be backported.

I checked and the bug is present for in both GCC 4.8 and 4.9 branches. The
patch applies cleanly in both cases as well. I did the same testing as for trunk
on the GCC 4.8 branch, that is:

1) bootstrap of GCC on x86_64-linux-gnu
2) arm-none-eabi cross compiler (defaulting to little endian) with testsuite
run under qemu emulqting a Cortex M4
3) arm-none-eabi cross compiler (defaulting to big endian, thanks to patch at 
[1])
with testsuite run under qemu emulating a Cortex M3.

I'm going to do the same testing for GCC 4.9 now. May I commit the backports?

Best regards,

Thomas

Re: [PATCH AArch64 1/3] Don't disparage add/sub in SIMD registers

[James Greenhalgh]

On Tue, Aug 12, 2014 at 04:53:38PM +0100, pins...@gmail.com wrote:
> 
> 
> > On Aug 12, 2014, at 7:40 AM, Alan Lawrence  wrote:
> > 
> > (It is no more expensive.)
> 
> Yes on some processors it could be. 

Haven't we been here before [1]?

This disparaging mechanism is still not going to give what we are trying to
achieve (assigning cost at the -mcpu/-mtune level, rather than the
target level). 

Recall that '!' gives a static cost of 600 [2] and that this cost is
only applied to the alternative if any operand in that alternative needs
reloading - otherwise, LRA sees a set of matching operands and does not
bother checking costs [3]. IRA, as far as I can see, does not care about
'!', but unconditionally adds 2 to the cost of an alternative for '?' [4].

Even if LRA did try to do a more complete job of always picking the
alternative with lowest cost (rather than the current first-matching
behaviour) "600" would be far too high a cost for the operation.

If IRA took '!' into account, we would be as well to remove the alternative
entirely.

So, I still can't agree that we want these exclamation marks - and we are
now in a halfway state where some instructions have them and some don't.
We have to pick a consistent policy or we are going to see some very poor
code generation.

In an ideal world, we would have a sensible way of describing a
(per-core granularity) alternative cost, which would be considered by
the register allocators. I've played about with doing this using attributes,
but it ends up as a messy patch and I can't bring myself to add yet another
cost framework to the back end.

Do you have any ideas as to how we can make some progress? Maybe Vladimir
has some suggestions?

Thanks,
James

[1] https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01627.html
[2] regoc.c::preprocess_constraints
[3] I may have misread this, but that seems to be what the final condition
of the main loop of lra-constraints::process_alt_operands implies.
[4] ira-costs.c::record_reg_classes

Re: [PATCH] libstdc++: add uniform on sphere distribution

[Paolo Carlini]

Ulrich--

On 08/13/2014 09:36 AM, Bin.Cheng wrote:

On Sun, Aug 10, 2014 at 2:00 AM, Ulrich Drepper  wrote:

On Sat, Aug 9, 2014 at 1:40 PM, Marc Glisse  wrote:

 __x = result_type(2.0) * __aurng() - 1.0;

You're right, we of course need the negatives as well.


Assuming the 2 coordinates are obtained through a rescaling x->2*x-1, if
__sq is not exactly 0, it must be between 2^-103 and 1 (for ieee
double), so I am not sure hypot gains that much (at least in my mind
hypot was mostly a gain close to 0 or infinity, but maybe it has more
advantages). It can only hurt speed though, so not a big issue.

Depending on how similar in size the two values are, not using hypot()
can drop quite a few bits.  Especially with the scaling through
division this error can be noticeable.  Better be sure.  Maybe at some
point I have time to investigate the worst case scenario for the
numbers in question but until this shows hypot isn't needed it's best
to leave it in.

I've committed the patch.

Hi,

This causes lots of tests under libstdc++-v3/testsuite/ext/ failed on
aarch64-none-elf and arm-none-eabi with below log message.
Please follow our usual rules, don't unconditionally use C99 functions 
like std::hypot,  use _GLIBCXX_USE_C99_MATH_TR1 (many examples, eg in 
random.tcc).


Thanks!
Paolo.

Re: [PATCH] Fix incorrect folding of bitfield in a union on big endian target

[Jakub Jelinek]

On Wed, Aug 13, 2014 at 04:21:24PM +0800, Thomas Preud'homme wrote:
> > From: Richard Biener [mailto:richard.guent...@gmail.com]
> > Sent: Monday, August 11, 2014 8:29 PM
> > 
> > That's now extra compares (the operand_equal_p check now does
> > a check that can be derived transitively).
> > 
> > So - ok with the operand_equal_p cehck removed.
> > 
> > Also see if this can be backported.
> 
> I checked and the bug is present for in both GCC 4.8 and 4.9 branches. The
> patch applies cleanly in both cases as well. I did the same testing as for 
> trunk
> on the GCC 4.8 branch, that is:
> 
> 1) bootstrap of GCC on x86_64-linux-gnu
> 2) arm-none-eabi cross compiler (defaulting to little endian) with testsuite
> run under qemu emulqting a Cortex M4
> 3) arm-none-eabi cross compiler (defaulting to big endian, thanks to patch at 
> [1])
> with testsuite run under qemu emulating a Cortex M3.
> 
> I'm going to do the same testing for GCC 4.9 now. May I commit the backports?

Ok.

Jakub

Re: [GSoC] Elimination of CLooG library installation dependency

[Tobias Grosser]

On 13/08/2014 16:07, Roman Gareev wrote:

If I’m not mistaken all tree nodes, which have pointer type, can be
divided into two groups:  the type is a  is a pointer to data member
(TYPE_PTRMEM_P is true for it),  the type is a pointer type, and the
pointee is not a data member (TYPE_PTR_P is true for it). I think that
we’re interested in disabling of the second group handling. It can
also be divided into two  groups:  the type is a pointer to function
type (TYPE_PTRFN_P is true for it), the type is a pointer to object
type (TYPE_PTROB_P is true for it). In my opinion, the second one is
worth to be considered. It contains, for example, nop_expr (these
nodes are used to represent conversions that do not require any
code-generation) integer_cst (these nodes represent integer
constants), ssa_name. I haven’t found all types, which are contained
in it. However, I think that we could disable other types, if it is
necessary in the future.


What we should do later is to build a run-time check that ensures
no pointer overflow is happening and then just create code without it.


I think that it is better to do this when the pointer handling is completed.

I’ve attached a Change_Log, which corresponds to the previous patch.
Are they fine for trunk? Could we give a headsup on the GCC mailing
list and ask other people to try the new isl support in case this
patch is committed?


Two minor thinks:

 - I assume you verified this passes all graphite tests.
 - Please add a brief comment in the source code regarding why we
   do not want to detect such SCoPs.

Otherwise LGTM.

Cheers,
Tobias

Re: PR tree-optimization/52904 testcase

[Richard Biener]

On Tue, Aug 12, 2014 at 2:34 PM, Kugan
 wrote:
 Did you verify the testcase fails before the revision that fixed it?
 Esp. the placement of the dg-bogus looks bogus to me.
>>>
>>> I tried it on Linaro 4.9 (It should be the same in fsf gcc 4.9 branch)
>>> and the test cases is failing there. Passes on trunk.
>>
>> Well, it probably fails because of excess errors, not because of
>> the dg-bogus failing.  The dg-bogus has to be on the line that
>> the warning triggers on.
>
> It was indeed excess errors and I wrongly assumed that this was the
> error I should expect. I have now moved the dg-bogus to the place where
> warning is being generated and verified that I am getting the error from
> test for bogus messages.
>
>>
>>> In any case, I have moved it to the top and reverified. I have also
>>> trimmed the warning pattern to check as there was some changes there
>>> from 4.9 to trunk.
>>>

 Also don't use -S in dg-options, use lower-case filenames and
 avoid spurious vertical white-space.  The VRP dump scan is
 also very unspecific - I suggest to drop it entirely.

>>>
>>> Done.
>>>
>>>
>>> Is this OK?
>>
>> Err.
>>
>> @@ -0,0 +1,24 @@
>> +
>>
>> Excessive vertical space
>>
>> +/* { dg-do compile } */
>> +/* { dg-options "-Wstrict-overflow -O2" } */
>> +/* { dg-bogus "assuming signed overflow does not occur when simplifying" */
>> +
> I have fixed it.
>
> Is this OK?

Ok!

Thanks,
Richard.

> Thanks,
> Kugan

Re: [PATCH] Fix for PR62037

[Richard Biener]

On Tue, Aug 12, 2014 at 6:40 PM, Felix Yang  wrote:
> Hi Richard,
>
> I find that you missed the testcase with when committing the patch.

I don't think so.

> GCC 4.8 & 4.9 branch also has the same issue, may be we need to
> fix for them too?

Yeah, I'll backport it.

Thanks,
Richard.

> Cheers,
> Felix
>
>
> On Mon, Aug 11, 2014 at 7:24 PM, Richard Biener
>  wrote:
>> On Sat, Aug 9, 2014 at 6:28 AM, Felix Yang  wrote:
>>> Attached please find the patch and testcase for PR62037.
>>>
>>> DEF1 can be a GIMPLE_NOP and gimple_bb will be NULL then. The patch
>>> checks for that.
>>> Bootstrapped on x86_64-suse-linux. OK for trunk? Please commit this
>>> patch if it's OK.
>>>
>>
>> Thanks - applied.
>>
>> Richard.
>>
>>> Index: gcc/ChangeLog
>>> ===
>>> --- gcc/ChangeLog(revision 213772)
>>> +++ gcc/ChangeLog(working copy)
>>> @@ -1,3 +1,9 @@
>>> +2014-08-09  Felix Yang  
>>> +
>>> +PR tree-optimization/62073
>>> +* tree-vect-loop.c (vect_is_simple_reduction_1): Check that DEF1 has
>>> +a basic block.
>>> +
>>>  2014-08-08  Guozhi Wei  
>>>
>>>  * config/rs6000/rs6000.md (*movdi_internal64): Add a new constraint.
>>> Index: gcc/testsuite/gcc.dg/vect/pr62073.c
>>> ===
>>> --- gcc/testsuite/gcc.dg/vect/pr62073.c(revision 0)
>>> +++ gcc/testsuite/gcc.dg/vect/pr62073.c(revision 0)
>>> @@ -0,0 +1,41 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O1 -ftree-vectorize" } */
>>> +
>>> +struct S0
>>> +{
>>> +int f7;
>>> +};
>>> +struct S0 g_50;
>>> +int g_70;
>>> +int g_76;
>>> +
>>> +
>>> +int foo (long long p_56, int * p_57)
>>> +{
>>> +int *l_77;
>>> +int l_101;
>>> +
>>> +for (; g_70;)
>>> +{
>>> +int **l_78 = &l_77;
>>> +if (g_50.f7)
>>> +continue;
>>> +*l_78 = 0;
>>> +}
>>> +for (g_76 = 1; g_76 >= 0; g_76--)
>>> +{
>>> +int *l_90;
>>> +for (l_101 = 4; l_101 >= 0; l_101--)
>>> +if (l_101)
>>> +*l_90 = 0;
>>> +else
>>> +{
>>> +int **l_113 = &l_77;
>>> +*l_113 = p_57;
>>> +}
>>> +}
>>> +
>>> +return *l_77;
>>> +}
>>> +
>>> +/* { dg-final { cleanup-tree-dump "vect" } } */
>>> Index: gcc/testsuite/ChangeLog
>>> ===
>>> --- gcc/testsuite/ChangeLog(revision 213772)
>>> +++ gcc/testsuite/ChangeLog(working copy)
>>> @@ -1,3 +1,8 @@
>>> +2014-08-09  Felix Yang  
>>> +
>>> +PR tree-optimization/62073
>>> +* gcc.dg/vect/pr62073.c: New test.
>>> +
>>>  2014-08-08  Richard Biener  
>>>
>>>  * gcc.dg/strlenopt-8.c: Remove XFAIL.
>>> Index: gcc/tree-vect-loop.c
>>> ===
>>> --- gcc/tree-vect-loop.c(revision 213772)
>>> +++ gcc/tree-vect-loop.c(working copy)
>>> @@ -2321,7 +2321,8 @@ vect_is_simple_reduction_1 (loop_vec_info loop_inf
>>>  }
>>>
>>>def1 = SSA_NAME_DEF_STMT (op1);
>>> -  if (flow_bb_inside_loop_p (loop, gimple_bb (def_stmt))
>>> +  if (gimple_bb (def1)
>>> +  && flow_bb_inside_loop_p (loop, gimple_bb (def_stmt))
>>>&& loop->inner
>>>&& flow_bb_inside_loop_p (loop->inner, gimple_bb (def1))
>>>&& is_gimple_assign (def1))
>>>
>>>
>>> Cheers,
>>> Felix

Re: RFC: Patch for switch elimination (PR 54742)

[Richard Biener]

On Tue, Aug 12, 2014 at 10:40 PM, Jeff Law  wrote:
> On 08/12/14 14:23, Richard Biener wrote:
>>
>> On August 12, 2014 8:31:16 PM CEST, Jeff Law  wrote:
>>>
>>> On 08/12/14 11:46, Steve Ellcey wrote:

 After talking to Jeff Law at the GCC Cauldron I have updated my
>>>
>>> switch

 shortcut plugin pass to try and address this optimization in the
>>>
>>> hopes of

 getting it added to GCC as a static pass.  I fixed the code to build
>>>
>>> with

 the various C++ changes that have been happening in GCC but the
>>>
>>> current

 version I have included in this email is not working yet.  When I run
>>>
>>> it

 on coremark I get errors like:

 core_state.c: In function 'core_bench_state':
 core_state.c:43:8: error: size of loop 16 should be 13, not 5
ee_u16 core_bench_state(ee_u32 blksize, ee_u8 *memblock,
   ^
 core_state.c:43:8: error: bb 15 does not belong to loop 16
 core_state.c:43:8: error: bb 113 does not belong to loop 16
 core_state.c:43:8: error: bb 118 does not belong to loop 16
 core_state.c:43:8: error: bb 117 does not belong to loop 16
 (etc)

 Apparently there have been some changes to the loop information that
 is built since GCC 4.9.  I had hoped that adding a call to
>>>
>>> fix_loop_structure

 after recalculating the dominance information would fix this but it
>>>
>>> didn't.


 Does anyone have any ideas on how to fix up the loop information that
>>>
>>> my

 optimization has messed as it duplicates blocks?  I tried adding a
>>>
>>> call

 'loop_optimizer_init (LOOPS_NORMAL)' before the fix_loop_structure
>>>
>>> but that

 did not seem to have any affect.
>>>
>>> Try setting the header & latch fields for the loop structure to NULL,
>>> then call loops_set_state (LOOPS_NEED_FIXUP).
>>
>>
>> But that is _not_ the appropriate way of keeping loops preserved!
>
> I think that's done when we've scrogged the loop beyond repair and want the
> structures rebuilt.  IIRC, that's what you recommended we do.

I don't see that this pass should "scrog" a loop beyond repair.  Btw,
the "proper" way of just fixing loops up (assuming that all loop
headers are still at their appropriate place) is to _just_ do
loops_set_state (LOOPS_NEED_FIXUP).

The next pass doing a loop_optimizer_init () then will fixup loops.

So the case you mention is when you totally screw the loop by
creating new entry edges that not go to its header for example.
But still this is in theory very bad as you cause important annotations
to be lost.  If the loop is truly gone, ok, but if it just re-materializes
then you've done a bad job here.  Consider the case where a
loop becomes a loop nest - you'd want to preserve the loop header
as the header of the outer loop (which you'd have to identify its
header in some way - dominator checks to the rescue!) and let
fixup discover the new inner loop.

Yes, we may have little utility for dealing with the more complex
cases and I've been hesitant to enforce not dropping loops on the
floor an ICE (well, mainly because we can't even bootstrap with
such check ...), but in the end we should arrive there.

Richard.

> jeff

Re: [patch] No allocation for empty unordered containers

[Jonathan Wakely]

On 12/08/14 21:53 +0200, François Dumont wrote:

On 12/08/2014 21:39, Marc Glisse wrote:

On Tue, 12 Aug 2014, François Dumont wrote:

  Based on your feedbacks I think we should stay with just 
targeting good QoI by not allocating on default construction. As I 
said the noexcept qualification would need to not conform strictly 
to the Standard.


The standard explicitly says that you may add noexcept wherever you 
like. It is constexpr that we can only add in GNU mode.


   That's not what I meant. For unordered containers there is no real 
default constructor. it is in fact a constructor with parameters which 
have all default values. This is why you can only say that it won't 
throw at runtime and so you can't qualify it noexcept.


Yes you can, it's conforming to replace a (non-virtual) member function
with default arguments by two or more member functions. We do it all
the time.

See 17.6.5.5 [member.functions] p2.

Re: RFC: Patch for switch elimination (PR 54742)

[Richard Biener]

On Wed, Aug 13, 2014 at 4:54 AM, Bin.Cheng  wrote:
> On Wed, Aug 13, 2014 at 4:40 AM, Jeff Law  wrote:
>> On 08/12/14 14:23, Richard Biener wrote:
>>>
>>> On August 12, 2014 8:31:16 PM CEST, Jeff Law  wrote:

 On 08/12/14 11:46, Steve Ellcey wrote:
>
> After talking to Jeff Law at the GCC Cauldron I have updated my

 switch
>
> shortcut plugin pass to try and address this optimization in the

 hopes of
>
> getting it added to GCC as a static pass.  I fixed the code to build

 with
>
> the various C++ changes that have been happening in GCC but the

 current
>
> version I have included in this email is not working yet.  When I run

 it
>
> on coremark I get errors like:
>
> core_state.c: In function 'core_bench_state':
> core_state.c:43:8: error: size of loop 16 should be 13, not 5
>ee_u16 core_bench_state(ee_u32 blksize, ee_u8 *memblock,
>   ^
> core_state.c:43:8: error: bb 15 does not belong to loop 16
> core_state.c:43:8: error: bb 113 does not belong to loop 16
> core_state.c:43:8: error: bb 118 does not belong to loop 16
> core_state.c:43:8: error: bb 117 does not belong to loop 16
> (etc)
>
> Apparently there have been some changes to the loop information that
> is built since GCC 4.9.  I had hoped that adding a call to

 fix_loop_structure
>
> after recalculating the dominance information would fix this but it

 didn't.
>
>
> Does anyone have any ideas on how to fix up the loop information that

 my
>
> optimization has messed as it duplicates blocks?  I tried adding a

 call
>
> 'loop_optimizer_init (LOOPS_NORMAL)' before the fix_loop_structure

 but that
>
> did not seem to have any affect.

 Try setting the header & latch fields for the loop structure to NULL,
 then call loops_set_state (LOOPS_NEED_FIXUP).
>>>
>>>
>>> But that is _not_ the appropriate way of keeping loops preserved!
>>
>> I think that's done when we've scrogged the loop beyond repair and want the
>> structures rebuilt.  IIRC, that's what you recommended we do.
>
> Sorry for disturbing with this patch irrelevant question.  If I
> understand correctly, we are now trying best to preserve loop
> structure and LOOPS_NEED_FIXUP still works.  My question is how we
> decide when we can rebuild loop structure and when we need to preserve
> it?  If there is meta data stored in loop structure, does that mean it
> should never be re-built?

Meta-data is associated with loops and ultimately loops are associated
with their header basic-block.  LOOPS_NEED_FIXUP tells the
machinery to re-scan the body for loops but keep the existing
header basic-block to loop structure association.  The only case it
does not do that is when you explicitely NULL a loop->header (you
signal the loop is now no longer a loop) or when the discovery process
discovers a loop which header basic-block didn't previously have a
loop associated with or if a loops recorded header basic-block is
no longer a loop header (by means of finding a latch edge going to it).

I'd like to make both discovering a new loop and removing an existing
loop (that wasn't marked for removal) an error.  All that passes need
to do is properly allocate a new loop structure for new loops headers
and mark loops that no longer are loops properly.  And of course
do it "the right way".

Note that the suspicious activity is logged in passes dump-files
(well, in the pass performing the fix_loop_structure call) with
TDF_DETAILS level as "fix_loop_structure: removing loop %d"
and "flow_loops_find: discovered new loop %d with header %d".

One issue with marking loops for removal is that we do that by
NULL-ing its header which makes spurious removal detection
impossible (as we no longer know its former header).  We should
fix that implementation detail.

Richard.

>
> Thanks,
> bin
>
>>
>> jeff

Re: [GSoC] Elimination of CLooG library installation dependency

[Richard Biener]

On Wed, Aug 13, 2014 at 10:07 AM, Roman Gareev  wrote:
> If I’m not mistaken all tree nodes, which have pointer type, can be
> divided into two groups:  the type is a  is a pointer to data member
> (TYPE_PTRMEM_P is true for it),  the type is a pointer type, and the
> pointee is not a data member (TYPE_PTR_P is true for it).

Both are C++ frontend concepts and not relevant for the middle-end
and thus GRAPHITE.

 I think that
> we’re interested in disabling of the second group handling. It can
> also be divided into two  groups:  the type is a pointer to function
> type (TYPE_PTRFN_P is true for it), the type is a pointer to object
> type (TYPE_PTROB_P is true for it). In my opinion, the second one is
> worth to be considered. It contains, for example, nop_expr (these
> nodes are used to represent conversions that do not require any
> code-generation) integer_cst (these nodes represent integer
> constants), ssa_name. I haven’t found all types, which are contained
> in it. However, I think that we could disable other types, if it is
> necessary in the future.
>
>> What we should do later is to build a run-time check that ensures
>> no pointer overflow is happening and then just create code without it.

I think you can assume that pointers don't overflow.

Richard.

> I think that it is better to do this when the pointer handling is completed.
>
> I’ve attached a Change_Log, which corresponds to the previous patch.
> Are they fine for trunk? Could we give a headsup on the GCC mailing
> list and ask other people to try the new isl support in case this
> patch is committed?
>
> --
> Cheers, Roman Gareev.

Re: [PATCH 005/236] Introduce as_a_nullable

[Martin Jambor]

Hi,

On Wed, Aug 06, 2014 at 01:19:44PM -0400, David Malcolm wrote:
> In many circumstances, is_a_helper ::test assumes that the pointer is
> non-NULL, but sometimes you have a pointer of type T that can be NULL.
> 
> Earlier versions of this patch kit made numerous uses of the ternary
> operator to handle nullable pointers e.g.:
> 
>   return insn ? as_a  (insn) : NULL;
> 
> but this was ugly.  Instead, introduce an as_a_nullable variant that
> adds a check for NULL, so the above can be written simply as:
> 
>   return as_a_nullable  (insn);

A tiny bikeshedding, disregard it if you don't like it: however, the
"nullable" part of the name suggests the pointer can be NULLed in the
process.  I think that variants of functions that survive NULL
arguments are traditionally called "safe" in gcc, so what about
"safe_as" (or safely_as)?

Martin


> 
> gcc/
>   * is-a.h (template as_a_nullable ) New function.
> ---
>  gcc/is-a.h | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/gcc/is-a.h b/gcc/is-a.h
> index a14e344..f50e62c 100644
> --- a/gcc/is-a.h
> +++ b/gcc/is-a.h
> @@ -46,6 +46,14 @@ TYPE as_a  (pointer)
>  
>do_something_with (as_a  *ptr);
>  
> +TYPE as_a_nullable  (pointer)
> +
> +Like as_a  (pointer), but where pointer could be NULL.  This
> +adds a check against NULL where the regular is_a_helper hook for TYPE
> +assumes non-NULL.
> +
> +  do_something_with (as_a_nullable  *ptr);
> +
>  TYPE dyn_cast  (pointer)
>  
>  Converts pointer to TYPE if and only if "is_a  pointer".  
> Otherwise,
> @@ -185,6 +193,22 @@ as_a (U *p)
>return is_a_helper ::cast (p);
>  }
>  
> +/* Similar to as_a<>, but where the pointer can be NULL, even if
> +   is_a_helper doesn't check for NULL.  */
> +
> +template 
> +inline T
> +as_a_nullable (U *p)
> +{
> +  if (p)
> +{
> +  gcc_checking_assert (is_a  (p));
> +  return is_a_helper ::cast (p);
> +}
> +  else
> +return NULL;
> +}
> +
>  /* A generic checked conversion from a base type U to a derived type T.  See
> the discussion above for when to use this function.  */
>  
> -- 
> 1.8.5.3
> 

Re: [PATCH 005/236] Introduce as_a_nullable

[Richard Biener]

On Wed, Aug 13, 2014 at 12:01 PM, Martin Jambor  wrote:
> Hi,
>
> On Wed, Aug 06, 2014 at 01:19:44PM -0400, David Malcolm wrote:
>> In many circumstances, is_a_helper ::test assumes that the pointer is
>> non-NULL, but sometimes you have a pointer of type T that can be NULL.
>>
>> Earlier versions of this patch kit made numerous uses of the ternary
>> operator to handle nullable pointers e.g.:
>>
>>   return insn ? as_a  (insn) : NULL;
>>
>> but this was ugly.  Instead, introduce an as_a_nullable variant that
>> adds a check for NULL, so the above can be written simply as:
>>
>>   return as_a_nullable  (insn);
>
> A tiny bikeshedding, disregard it if you don't like it: however, the
> "nullable" part of the name suggests the pointer can be NULLed in the
> process.  I think that variants of functions that survive NULL
> arguments are traditionally called "safe" in gcc, so what about
> "safe_as" (or safely_as)?

Ok, I resisted at first starting the bike-shedding but I agree on
the badness of "nullable" (what does that mean anyway?).
as_a_safe or safe_as_a both work for me.

Richard.

>
> Martin
>
>
>>
>> gcc/
>>   * is-a.h (template as_a_nullable ) New function.
>> ---
>>  gcc/is-a.h | 24 
>>  1 file changed, 24 insertions(+)
>>
>> diff --git a/gcc/is-a.h b/gcc/is-a.h
>> index a14e344..f50e62c 100644
>> --- a/gcc/is-a.h
>> +++ b/gcc/is-a.h
>> @@ -46,6 +46,14 @@ TYPE as_a  (pointer)
>>
>>do_something_with (as_a  *ptr);
>>
>> +TYPE as_a_nullable  (pointer)
>> +
>> +Like as_a  (pointer), but where pointer could be NULL.  This
>> +adds a check against NULL where the regular is_a_helper hook for TYPE
>> +assumes non-NULL.
>> +
>> +  do_something_with (as_a_nullable  *ptr);
>> +
>>  TYPE dyn_cast  (pointer)
>>
>>  Converts pointer to TYPE if and only if "is_a  pointer".  
>> Otherwise,
>> @@ -185,6 +193,22 @@ as_a (U *p)
>>return is_a_helper ::cast (p);
>>  }
>>
>> +/* Similar to as_a<>, but where the pointer can be NULL, even if
>> +   is_a_helper doesn't check for NULL.  */
>> +
>> +template 
>> +inline T
>> +as_a_nullable (U *p)
>> +{
>> +  if (p)
>> +{
>> +  gcc_checking_assert (is_a  (p));
>> +  return is_a_helper ::cast (p);
>> +}
>> +  else
>> +return NULL;
>> +}
>> +
>>  /* A generic checked conversion from a base type U to a derived type T.  See
>> the discussion above for when to use this function.  */
>>
>> --
>> 1.8.5.3
>>

[PATCH] Fix for PR/62089 (enable missing Asan checks)

[Yury Gribov]

Hi all,

GCC Asan may currently fail to generate checks for accesses to wide 
structure fields due to unfortunate intermix with code that handles 
bitfields. This patch fixes it and also adds a bunch of tests.


Bootstrapped, regtested and asan-bootstrapped on x64.

Ok to commit?

-Y
commit 5a10147cef710e6f43365567615f37261d7e70c5
Author: Yury Gribov 
Date:   Mon Aug 11 15:09:45 2014 +0400

2014-08-12  Yury Gribov  

gcc/
	PR sanitizer/62089
	* asan.c (instrument_derefs): Fix bitfield check.

gcc/testsuite/
	PR sanitizer/62089
	* c-c++-common/asan/pr62089.c: New test.
	* c-c++-common/asan/bitfield-1.c: New test.
	* c-c++-common/asan/bitfield-2.c: New test.
	* c-c++-common/asan/bitfield-3.c: New test.
	* c-c++-common/asan/bitfield-4.c: New test.

diff --git a/gcc/asan.c b/gcc/asan.c
index 4e6f438..b38264b 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1690,9 +1690,7 @@ instrument_derefs (gimple_stmt_iterator *iter, tree t,
   int volatilep = 0, unsignedp = 0;
   tree inner = get_inner_reference (t, &bitsize, &bitpos, &offset,
 &mode, &unsignedp, &volatilep, false);
-  if (((size_in_bytes & (size_in_bytes - 1)) == 0
-   && (bitpos % (size_in_bytes * BITS_PER_UNIT)))
-  || bitsize != size_in_bytes * BITS_PER_UNIT)
+  if (bitpos % BITS_PER_UNIT || bitsize != size_in_bytes * BITS_PER_UNIT)
 {
   if (TREE_CODE (t) == COMPONENT_REF
 	  && DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1)) != NULL_TREE)
@@ -1704,8 +1702,6 @@ instrument_derefs (gimple_stmt_iterator *iter, tree t,
 	}
   return;
 }
-  if (bitpos % BITS_PER_UNIT)
-return;
 
   if (TREE_CODE (inner) == VAR_DECL
   && offset == NULL_TREE
diff --git a/gcc/testsuite/c-c++-common/asan/bitfield-1.c b/gcc/testsuite/c-c++-common/asan/bitfield-1.c
new file mode 100644
index 000..b3f300c
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/bitfield-1.c
@@ -0,0 +1,25 @@
+/* Check that Asan correctly instruments bitfields with non-round size.  */
+
+/* { dg-do run } */
+/* { dg-shouldfail "asan" } */
+
+struct A
+{
+  char base;
+  int : 4;
+  long x : 7;
+};
+
+int __attribute__ ((noinline, noclone))
+f (void *p) {
+  return ((struct A *)p)->x;
+}
+
+int
+main ()
+{
+  char a = 0;
+  return f (&a);
+}
+
+/* { dg-output "ERROR: AddressSanitizer: stack-buffer-overflow" } */
diff --git a/gcc/testsuite/c-c++-common/asan/bitfield-2.c b/gcc/testsuite/c-c++-common/asan/bitfield-2.c
new file mode 100644
index 000..8ab0f80
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/bitfield-2.c
@@ -0,0 +1,25 @@
+/* Check that Asan correctly instruments bitfields with non-round offset.  */
+
+/* { dg-do run } */
+/* { dg-shouldfail "asan" } */
+
+struct A
+{
+  char base;
+  int : 7;
+  int x : 8;
+};
+
+int __attribute__ ((noinline, noclone))
+f (void *p) {
+  return ((struct A *)p)->x;
+}
+
+int
+main ()
+{
+  char a = 0;
+  return f (&a);
+}
+
+/* { dg-output "ERROR: AddressSanitizer: stack-buffer-overflow" } */
diff --git a/gcc/testsuite/c-c++-common/asan/bitfield-3.c b/gcc/testsuite/c-c++-common/asan/bitfield-3.c
new file mode 100644
index 000..c590778
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/bitfield-3.c
@@ -0,0 +1,25 @@
+/* Check that Asan correctly instruments bitfields with round offset.  */
+
+/* { dg-do run } */
+/* { dg-shouldfail "asan" } */
+
+struct A
+{
+  char base;
+  int : 8;
+  int x : 8;
+};
+
+int __attribute__ ((noinline, noclone))
+f (void *p) {
+  return ((struct A *)p)->x;
+}
+
+int
+main ()
+{
+  char a = 0;
+  return f (&a);
+}
+
+/* { dg-output "ERROR: AddressSanitizer: stack-buffer-overflow" } */
diff --git a/gcc/testsuite/c-c++-common/asan/bitfield-4.c b/gcc/testsuite/c-c++-common/asan/bitfield-4.c
new file mode 100644
index 000..94de9a4
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/bitfield-4.c
@@ -0,0 +1,25 @@
+/* Check that Asan correctly instruments bitfields with round offset.  */
+
+/* { dg-do run } */
+/* { dg-shouldfail "asan" } */
+
+struct A
+{
+  char base;
+  int : 0;
+  int x : 8;
+};
+
+int __attribute__ ((noinline, noclone))
+f (void *p) {
+  return ((struct A *)p)->x;
+}
+
+int
+main ()
+{
+  char a = 0;
+  return f (&a);
+}
+
+/* { dg-output "ERROR: AddressSanitizer: stack-buffer-overflow" } */
diff --git a/gcc/testsuite/c-c++-common/asan/pr62089.c b/gcc/testsuite/c-c++-common/asan/pr62089.c
new file mode 100644
index 000..22b877b
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/pr62089.c
@@ -0,0 +1,37 @@
+/* { dg-do run } */
+/* { dg-shouldfail "asan" } */
+
+#include 
+
+struct vfsmount {};
+struct dentry {};
+
+struct path {
+  struct vfsmount *mnt;
+  struct dentry *dentry;
+};
+
+struct fs_struct {
+  int users;
+  int lock;
+  int seq;
+  int umask;
+  int in_exec;
+  struct path root, pwd;
+};
+
+void __attribute__((noinline, noclone))
+copy_fs_struct(struct fs_struct *a, struct fs_struct *b) {
+  a->root = b->root;
+}
+
+struct fs_struct a, b;
+
+int
+main () {
+  __asan_poison_memory_region (&a

Re: [GSoC][match-and-simplify] add few constant-folding tests

[Richard Biener]

On Tue, Aug 12, 2014 at 10:08 PM, Prathamesh Kulkarni
 wrote:
> [gcc/testsuite/gcc.dg/tree-ssa]
>   * match-constant-folding.c: New test-case.

Thanks - applied.

Richard.

> Thanks,
> Prathamesh

Re: [PATCH] Fix for PR/62089 (enable missing Asan checks)

[Jakub Jelinek]

On Wed, Aug 13, 2014 at 02:09:33PM +0400, Yury Gribov wrote:
> --- a/gcc/asan.c
> +++ b/gcc/asan.c
> @@ -1690,9 +1690,7 @@ instrument_derefs (gimple_stmt_iterator *iter, tree t,
>int volatilep = 0, unsignedp = 0;
>tree inner = get_inner_reference (t, &bitsize, &bitpos, &offset,
>   &mode, &unsignedp, &volatilep, false);
> -  if (((size_in_bytes & (size_in_bytes - 1)) == 0
> -   && (bitpos % (size_in_bytes * BITS_PER_UNIT)))
> -  || bitsize != size_in_bytes * BITS_PER_UNIT)
> +  if (bitpos % BITS_PER_UNIT || bitsize != size_in_bytes * BITS_PER_UNIT)
>  {
>if (TREE_CODE (t) == COMPONENT_REF
> && DECL_BIT_FIELD_REPRESENTATIVE (TREE_OPERAND (t, 1)) != NULL_TREE)

I wonder if we just shouldn't handle COMPONENT_REFs with
DECL_BIT_FIELD_REPRESENTATIVE that way unconditionally.
So, do the if (TREE_CODE (t) == COMPONENT_REF ... before the other checks,
and
  else if (bitpos % BITS_PER_UNIT || bitsize != size_in_bytes * BITS_PER_UNIT)
return;

Jakub

Re: [PATCH] Fix some typos

[Sylvestre Ledru]

On 12/08/2014 19:38, Marc Glisse wrote:
> On Tue, 12 Aug 2014, Sylvestre Ledru wrote:
>
>> The patch fixes some typos found by Lintian, the Debian static analyzer.
>
> Did you check them yourself? 
Sure (but I am not a native English speaker).
> We end up with "these information" which doesn't seem correct to me.
>
Where do you see that?

Sylvestre

Re: [PATCH] Fix some typos

[Paolo Carlini]

Hi,

On 08/12/2014 07:29 PM, Sylvestre Ledru wrote:

Hello

The patch fixes some typos found by Lintian, the Debian static analyzer.

(it is mainly the opportunity to test my commit permissions).

Thanks,
Sylvestre

libstdc++-v3/ChangeLog:

2014-08-12  Sylvestre Ledru  

* include/profile/impl/profiler_hash_func.h: Fix a typo
This is also Ok with 'comment typo' instead of just 'typo' in the 
ChangeLog entry and a full stop at the end.


Thanks!
Paolo.

Re: [PATCH AArch64 3/3] Fix XOR_one_cmpl pattern; add SIMD-reg variants for BIC,ORN,EON

[Alan Lawrence]

So my reasoning was that the alternative is likely to be more expensive *on all 
cores*, as it is split to two instructions, whereas add/sub "could" be more 
expensive for *some* processors.


But yes I can see the argument, by my own logic and James Greenhalgh's, for 
removing the '?': it still doesn't really say what we want to say, which is that 
the instruction itself is more expensive, rather than anything to do with moving 
values into registers if/when reloading. At this point in time we don't have a 
framework that allows us to say that...


--Alan

Kugan wrote:

On 13/08/14 00:55, Alan Lawrence wrote:

...patch attached...

Alan Lawrence wrote:

[When I wrote that xor was broken on GPRs and this fixes it, I meant
xor_one_cmpl rather than xor, sorry!]

The pattern for xor_one_cmpl never matched, due to the action of
combine_simplify_rtx; hence, separate this pattern out from that for
ORN/BIC.

ORN/BIC have equivalent SIMD-reg variants, so add those for the
benefit of values in vector registers (e.g. passed as [u]int64x1_t
parameters).

EON does not have a SIMD-reg variant; however, it seems better to
split it (to XOR + NOT) than to move both arguments to GPRs, perform
EON, and move the result back.




+;; (xor (not a) b) is simplify_rtx-ed down to (not (xor a b)).
+;; eon does not operate on SIMD registers so the vector variant must be
split.
+(define_insn_and_split "*xor_one_cmpl3"
+  [(set (match_operand:GPI 0 "register_operand" "=r,w")
+(not:GPI (xor:GPI (match_operand:GPI 1 "register_operand" "r,?w")

Hi Alan,

Is there any specific reason for why you are disparaging slightly this
alternative  with ‘?’. Your earlier patch removes '!' from subdi3.

Thanks,
Kugan


+  (match_operand:GPI 2 "register_operand"
"r,w"]
+  ""
+  "eon\\t%0, %1, %2" ;; For GPR registers (only).
+  "reload_completed && (which_alternative == 1)" ;; For SIMD registers.
+  [(set (match_operand:GPI 0 "register_operand" "=w")
+(xor:GPI (match_operand:GPI 1 "register_operand" "w")
+ (match_operand:GPI 2 "register_operand" "w")))
+   (set (match_dup 0) (not:GPI (match_dup 0)))]

Re: [PATCH] Fix some typos

[Marc Glisse]

On Wed, 13 Aug 2014, Sylvestre Ledru wrote:


On 12/08/2014 19:38, Marc Glisse wrote:

On Tue, 12 Aug 2014, Sylvestre Ledru wrote:


The patch fixes some typos found by Lintian, the Debian static analyzer.


Did you check them yourself?

Sure (but I am not a native English speaker).


I am not a native speaker either, but several sentences could do with more 
that removing an 's'. The "of" right after "information" in 
URIException.java doesn't make sense to me, for instance.



We end up with "these information" which doesn't seem correct to me.


Where do you see that?


gcc/ada/s-interr.ads

--
Marc Glisse

Re: [PATCH] libstdc++: add uniform on sphere distribution

[Paolo Carlini]

... fixed with the below.

Thanks,
Paolo.

//
2014-08-13  Paolo Carlini  

PR libstdc++/62118
* include/ext/random.tcc (uniform_on_sphere_helper<2, _RealType>::
operator()): Use std::hypot only when _GLIBCXX_USE_C99_MATH_TR1.
Index: include/ext/random.tcc
===
--- include/ext/random.tcc  (revision 213898)
+++ include/ext/random.tcc  (working copy)
@@ -1547,10 +1547,12 @@
 template
   class uniform_on_sphere_helper
   {
-   typedef typename uniform_on_sphere_distribution<_Dimen, 
_RealType>::result_type result_type;
+   typedef typename uniform_on_sphere_distribution<_Dimen, _RealType>::
+ result_type result_type;
 
   public:
-   template
+   template
result_type operator()(_NormalDistribution& __nd,
   _UniformRandomNumberGenerator& __urng)
 {
@@ -1604,9 +1606,13 @@
}
  while (__sq == _RealType(0) || __sq > _RealType(1));
 
+#if _GLIBCXX_USE_C99_MATH_TR1
  // Yes, we do not just use sqrt(__sq) because hypot() is more
  // accurate.
  auto __norm = std::hypot(__ret[0], __ret[1]);
+#else
+ auto __norm = std::sqrt(__ret[0] * __ret[0] + __ret[1] * __ret[1]);
+#endif
  __ret[0] /= __norm;
  __ret[1] /= __norm;
 

Re: [PATCH] libstdc++: add uniform on sphere distribution

[Marc Glisse]

On Wed, 13 Aug 2014, Paolo Carlini wrote:


... fixed with the below.


Could you please use __sq instead of recomputing it?

--
Marc Glisse

[wwwdocs] Update GCC5 changes.html

[Marek Polacek]

I've put together a few lines describing what I (except
-fsanitize=alignment) implemented for GCC 5.
It's the file wwwdocs/htdocs/gcc-5/changes.html.

Ok?

--- changes.html.mp 2014-08-13 12:21:57.059610612 +0200
+++ changes.html2014-08-13 13:22:00.683597815 +0200
@@ -16,11 +16,53 @@
 
 General Optimizer Improvements
 
+  
+UndefinedBehaviorSanitizer gained a few new sanitization options:
+
+  -fsanitize=float-divide-by-zero: detect floating-point
+  division by zero;
+  -fsanitize=float-cast-overflow: check that the result
+  of floating-point type to integer conversion does not overflow;
+  -fsanitize=bounds: enable instrumentation of array 
bounds
+ and detect out-of-bounds accesses;
+  -fsanitize=alignment: enable alignment checking, detect
+ various misaligned objects.
+
+
+  
+
 New Languages and Language specific improvements
 
 
-
-
+C family
+
+  
+A new -Wswitch-bool option has been added for the C and 
C++
+   compilers, which warns whenever a switch statement has an
+   index of boolean type.
+A new -Wlogical-not-parentheses option has been added for 
the
+   C and C++ compilers, which warns about logical not used on the left hand
+   side operand of a comparison.
+A new -Wsizeof-array-argument option has been added for 
the
+   C and C++ compilers, which warns when the sizeof operator 
is
+   applied to a parameter that is declared as an array in a function 
definition.
+  
+
+C
+
+  
+A new -Wc90-c99-compat option has been added to warn
+   about features not present in ISO C90, but present in ISO C99.
+It is possible to disable warnings about conversions between pointers
+   that have incompatible types via a new warning option
+   -Wno-incompatible-pointer-types; warnings about implicit
+   incompatible integer to pointer and pointer to integer conversions via
+   a new warning option -Wno-int-conversion; and warnings 
about
+   qualifiers on pointers being discarded via a new warning option
+   -Wno-discarded-qualifiers.
+The C front end now generates more precise caret diagnostics.
+  
+
 
   
 Fortran

Marek

Re: [PATCH] libstdc++: add uniform on sphere distribution

[Paolo Carlini]

On 08/13/2014 01:32 PM, Marc Glisse wrote:

On Wed, 13 Aug 2014, Paolo Carlini wrote:


... fixed with the below.


Could you please use __sq instead of recomputing it?


Patch preapproved, thanks!

Paolo.

Re: [GSoC] Elimination of CLooG library installation dependency

[Roman Gareev]

>  - I assume you verified this passes all graphite tests.

Yes, I’ve found out that there is no regression.

>  - Please add a brief comment in the source code regarding why we
>do not want to detect such SCoPs.

Would you add anything to the following comment: “We disable the
handling of pointer types, because it’s currently not supported by
Graphite with the ISL AST generator. SSA_NAME nodes are the only
nodes, which are disabled in case they are pointers to object types,
but this can be changed.” ?

-- 
Cheers, Roman Gareev.

Re: [GSoC] Elimination of CLooG library installation dependency

[Roman Gareev]

Thank you for the comment!

2014-08-13 15:55 GMT+06:00 Richard Biener :
> On Wed, Aug 13, 2014 at 10:07 AM, Roman Gareev  wrote:
>> If I’m not mistaken all tree nodes, which have pointer type, can be
>> divided into two groups:  the type is a  is a pointer to data member
>> (TYPE_PTRMEM_P is true for it),  the type is a pointer type, and the
>> pointee is not a data member (TYPE_PTR_P is true for it).
>
> Both are C++ frontend concepts and not relevant for the middle-end
> and thus GRAPHITE.
>
>  I think that
>> we’re interested in disabling of the second group handling. It can
>> also be divided into two  groups:  the type is a pointer to function
>> type (TYPE_PTRFN_P is true for it), the type is a pointer to object
>> type (TYPE_PTROB_P is true for it). In my opinion, the second one is
>> worth to be considered. It contains, for example, nop_expr (these
>> nodes are used to represent conversions that do not require any
>> code-generation) integer_cst (these nodes represent integer
>> constants), ssa_name. I haven’t found all types, which are contained
>> in it. However, I think that we could disable other types, if it is
>> necessary in the future.
>>
>>> What we should do later is to build a run-time check that ensures
>>> no pointer overflow is happening and then just create code without it.
>
> I think you can assume that pointers don't overflow.
>
> Richard.
>
>> I think that it is better to do this when the pointer handling is completed.
>>
>> I’ve attached a Change_Log, which corresponds to the previous patch.
>> Are they fine for trunk? Could we give a headsup on the GCC mailing
>> list and ask other people to try the new isl support in case this
>> patch is committed?
>>
>> --
>> Cheers, Roman Gareev.



-- 
Cheers, Roman Gareev.

Re: [PATCH 4.8] libstdc++ pretty-printers: Backport Python 3 support from mainline

[Jonathan Wakely]

On 13/08/14 02:02 -0400, Samuel Bronson wrote:


This was a bit trickier than the backport to 4.9: but the tests pass,
except this one:

UNSUPPORTED: libstdc++-prettyprinters/shared_ptr.cc

This is a bit puzzling, but seems unrelated to my change.


Yes, I see that too without your change applied. Curious.

shared_ptr.gdb:5: Error in sourced command file:
No symbol "esp" in current context.
skipping: shared_ptr.gdb:5: Error in sourced command file:
skipping: No symbol "esp" in current context.

[PATCH] Add Berkeley qsort to libiberty to make GCC host-independent

[Felix Yang]

Hi all,

The qsort library function may have different behavior on
different hosts (say Linux vs MinGW).
We may have different sorting results with qsort when there are
elements with the same key value.
GCC uses qsort a lot. And the output of certain optimizations,
such as IRA, relies on the sorting result of this library function.
The problem is that we may have different assembly code of GCC on
different hosts even with the same source file.
Normally this is not what a GCC user expect to see.
In order to fix this issue, I am adding Berkeley qsort to
libiberty in order to override the one from the library.

Bootstrapped on x86_64-suse-linux, OK for trunk? Please help
commit this patch if it's OK.

Cheers,
Felix
Index: libiberty/ChangeLog
===
--- libiberty/ChangeLog (revision 213873)
+++ libiberty/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2014-08-12  Felix Yang  
+
+   * qsort.c: New file.
+   * Makefile.in (CFILES): Add qsort.c
+   (REQUIRED_OFILES): Add qsort.o.
+   (qsort.o): New target.
+
 2014-06-11  Andrew Burgess  
 
* cplus-dem.c (do_type): Call string_delete even if the call to
Index: libiberty/qsort.c
===
--- libiberty/qsort.c   (revision 0)
+++ libiberty/qsort.c   (revision 0)
@@ -0,0 +1,178 @@
+/*
+ * Copyright (c) 1992, 1993
+ * The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *must display the following acknowledgement:
+ * This product includes software developed by the University of
+ * California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+
+#include 
+
+#define min(a, b)  (a) < (b) ? a : b
+
+/*
+ * Qsort routine from Bentley & McIlroy's "Engineering a Sort Function".
+ */
+#define swapcode(TYPE, parmi, parmj, n)\
+{  \
+  long i = (n) / sizeof (TYPE);\
+  TYPE *pi = (TYPE *) (parmi); \
+  TYPE *pj = (TYPE *) (parmj); \
+  do { \
+TYPE t = *pi;  \
+*pi++ = *pj;   \
+*pj++ = t; \
+  } while (--i > 0);   \
+}
+
+#define SWAPINIT(a, es) swaptype = ((char *)a - (char *)0) % sizeof(long) || \
+   es % sizeof(long) ? 2 : es == sizeof(long)? 0 : 1;
+
+static inline void
+swapfunc (char *a, char *b, int n, int swaptype)
+{
+  if (swaptype <= 1) 
+swapcode (long, a, b, n)
+  else
+swapcode (char, a, b, n)
+}
+
+#define swap(a, b) \
+   if (swaptype == 0) {\
+   long t = *(long *)(a);  \
+   *(long *)(a) = *(long *)(b);\
+   *(long *)(b) = t;   \
+   } else  \
+   swapfunc(a, b, es, swaptype)
+
+#define vecswap(a, b, n)   if ((n) > 0) swapfunc (a, b, n, swaptype)
+
+static inline char *
+med3 (char *a, char *b, char *c, int (*cmp)())
+{
+  return cmp (a, b) < 0 ?
+   (cmp (b, c) < 0 ? b : (cmp (a, c) < 0 ? c : a))
+   : (cmp (b, c) > 0 ? b : (cmp (a, c) < 0 ? a : c));
+}
+
+void
+qsort (void *a, size_t n, size_t es, 

Re: [PATCH i386 AVX512] [8/n] Extend substs for new patterns.

[Kirill Yukhin]

Hello Uroš,
On 12 Aug 20:16, Uros Bizjak wrote:
> In a couple of places,  checks are changed to GET_MODE_SIZE
> (GET_MODE (operands[0])) and in a similar way, mode checks were
> changed to GET_MODE (operands[0]). The previous checks are more
> efficient and are preferred. Is there a reason you need to check
> operands[0] dynamically?

I agree, runtime tests are worse. But this subst attributes are used
in patterns which actually do not contain mode iterators at all.
So, fix will be not only to update subst.md, but also in sse.md, in
patterns which actually employ this attribute.

E.g.
(define_expand "vec_widen_smult_even_v8si"
  [(set (match_operand:V4DI 0 "register_operand")
(mult:V4DI
  (sign_extend:V4DI
(vec_select:V4SI
  (match_operand:V8SI 1 "nonimmediate_operand")
  (parallel [(const_int 0) (const_int 2)
 (const_int 4) (const_int 6)])))
  (sign_extend:V4DI
(vec_select:V4SI
  (match_operand:V8SI 2 "nonimmediate_operand")
  (parallel [(const_int 0) (const_int 2)
 (const_int 4) (const_int 6)])]
  "TARGET_AVX2 && "

Will be replaced with:
(define_expand "vec_widen_smult_even_v8si"
  [(set (match_operand:V4DI 0 "register_operand")
(mult:V4DI
  (sign_extend:V4DI
(vec_select:V4SI
  (match_operand:V8SI 1 "nonimmediate_operand")
  (parallel [(const_int 0) (const_int 2)
 (const_int 4) (const_int 6)])))
  (sign_extend:V4DI
(vec_select:V4SI
  (match_operand:V8SI 2 "nonimmediate_operand")
  (parallel [(const_int 0) (const_int 2)
 (const_int 4) (const_int 6)])]
  "TARGET_AVX2 && (! || TARGET_AVX512VL)"

I am working on patch.

--
Thanks, K

Re: [PATCH] Add Berkeley qsort to libiberty to make GCC host-independent

[Jakub Jelinek]

On Wed, Aug 13, 2014 at 08:12:03PM +0800, Felix Yang wrote:
> The qsort library function may have different behavior on
> different hosts (say Linux vs MinGW).
> We may have different sorting results with qsort when there are
> elements with the same key value.
> GCC uses qsort a lot. And the output of certain optimizations,
> such as IRA, relies on the sorting result of this library function.
> The problem is that we may have different assembly code of GCC on
> different hosts even with the same source file.
> Normally this is not what a GCC user expect to see.
> In order to fix this issue, I am adding Berkeley qsort to
> libiberty in order to override the one from the library.

Why have you picked a BSD one rather than the GNU one?
glibc qsort is highly optimized and has some other nice properties qsort
from many other sources does not have.

Jakub

[PATCH][www] Document versioning scheme for GCC 5 and up

[Richard Biener]

The release management team has aggreed to go forward with the
change to bump the major with each further release.

The following aims to document the details of the versioning scheme we
intend to use for GCC 5 and up.

Summary in non-html: Development of GCC 5 will happen as
GCC 5.0.0 (experimental), once we enter regression-fixing-only mode 
(post-stage3) it will become GCC 5.0.1 (prerelease).  The
GCC 5 release itself will be numbered GCC 5.1.0 and development
on the branch will continue as GCC 5.1.1 followed by a GCC 5.2.0
release and GCC 5.2.1 branch development.  Stage1 of GCC 6 will
bump us to GCC 6.0.0.

Ok for www?

Thanks,
Richard.

2014-08-13  Richard Biener  

* develop.html: Document GCC 5 versioning scheme.

Index: develop.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.143
diff -u -r1.143 develop.html
--- develop.html16 Jul 2014 14:01:06 -  1.143
+++ develop.html13 Aug 2014 12:17:55 -
@@ -230,6 +230,43 @@
 spending undue amounts of time on release testing and packaging.
 
 
+Version Numbering Scheme for GCC 5 and Up
+
+Starting with GCC 5 we will bump the major version number for
+each release.  The version number and DEV-PHASE will develop in the following
+way and on the following timeline:
+
+  VersionDEV-PHASEWhen
+  5.0.0(experimental)
+  during active development of GCC 5 (stage 1 to 3)
+  5.0.1(prerelease)
+  during the stabilization period of GCC 5
+  6.0.0(experimental)
+  during active development of GCC 6 (stage 1 to 3)
+  5.1.0
+  for the first release from the GCC 5 branch
+  5.1.1
+  during development on the branch post the 5.1.0 release
+  5.2.0
+  for the second release from the GCC 5 branch
+  5.2.1
+  during development on the branch post the 5.2.0 release
+  6.0.1(prerelease)
+  during the stabilization period of GCC 6
+  ...
+
+To summarize, the first release of GCC 5 will be GCC 5.1.0 while
+development snapshots will be GCC 5.0.0 and snapshots from the
+release branch GCC 5.n.1.
+
+Rationale
+
+This change allows to more easily identify GCC versions by giving
+each of the development phases distinctive versions.  The change
+also takes advantage of the fact that previously the GCC major
+number carried little to no useful information.
+
+
 Release Timeline
 
 Here is a history of recent and a tentative timeline of upcoming

[PATCH] Fix wrong refactoring in cgraph_node::function_symbol

[Ilya Enkovich]

Hi,

This patch is to fix wrong refactoring for cgraph_node::function_symbol 
introduced by this patch: https://gcc.gnu.org/ml/gcc-cvs/2014-07/msg00805.html. 
 Here is how function was refactored:

-cgraph_function_node (struct cgraph_node *node, enum availability 
*availability)
+cgraph_node *
+cgraph_node::function_symbol (enum availability *availability)
 {
+  cgraph_node *node = NULL;
+
   do
 {
-  node = cgraph_function_or_thunk_node (node, availability);
+  node = ultimate_alias_target (availability);
   if (node->thunk.thunk_p)
{
  node = node->callees->callee;
  if (availability)
{
  enum availability a;
- a = cgraph_function_body_availability (node);
+ a = node->get_availability ();
  if (a < *availability)
*availability = a;
}
- node = cgraph_function_or_thunk_node (node, availability);
+ node = node->ultimate_alias_target (availability);
}
 } while (node && node->thunk.thunk_p);
   return node;
 }

first ultimate_alias_target call always uses 'this' instead of 'node'.  This 
causes infinite loop.

Patch was bootstrapped and regtested on linux-x86_64.  OK for trunk?

Thanks,
Ilya
--

2014-08-13  Ilya Enkovich  

* cgraph.c (cgraph_node::function_symbol): Fix wrong
cgraph_function_node to cgraph_node::function_symbol
refactoring.

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 5a0b903..370a96a 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -3000,11 +3000,11 @@ cgraph_node::verify_cgraph_nodes (void)
 cgraph_node *
 cgraph_node::function_symbol (enum availability *availability)
 {
-  cgraph_node *node = NULL;
+  cgraph_node *node = this;
 
   do
 {
-  node = ultimate_alias_target (availability);
+  node = node->ultimate_alias_target (availability);
   if (node->thunk.thunk_p)
{
  node = node->callees->callee;

Re: [c++-concepts] variable concepts

[Andrew Sutton]

Committed.

Andrew Sutton


On Wed, Aug 13, 2014 at 3:24 AM, Braden Obrzut  wrote:
> This patch adds support for variable concepts.
>
> There is a known issue that prevents concept variables from having requires
> expressions that have parameters.  This issue is not within the scope of
> this patch as it affects adhoc requires expressions as well.
>
> 2014-08-13  Braden Obrzut 
>
> * gcc/cp/constraint.cc (deduce_constrained_parameter): Deduce concept
> from variable concept template-id expressions.
> (normalize_var): New.
> (normalize_template_id): Identify variable concepts.
> (build_concept_check): Handle variable concepts.
> (finish_shorthand_requirement): Handle variable concepts.
> (diagnose_var): New.
> (diagnose_node): Identify variable concepts.
> * gcc/cp/decl.c (grokvardecl): Pass concept flag through to
> check_explicit_specialization.
> (grokdeclarator): Allow variable concepts and pass concept flag through
> grokvardecl.
> * gcc/cp/parser.c (cp_is_constrained_parameter): Accept variable
> concepts.
> (cp_parser_nonclass_name): Accept variable concepts.
> (get_concept_from_constraint): Handle variable concepts.
> * gcc/cp/pt.c (tsubst_copy_and_build): Lookup variable templates.
> (value_dependent_expression_p): Check requires expressions for value
> dependence.
> * gcc/cp/semantics.c (finish_call_expr): Don't instantiate variable
> templates if processing a template declaration.
> * gcc/testsuite/g++.dg/concepts/decl-diagnose.C: Change expected error
> as variable concepts are now handled.
> * gcc/testsuite/g++.dg/concepts/var-concepts1.C: New test.
> * gcc/testsuite/g++.dg/concepts/var-concepts2.C: New test.
>

Re: [PATCH] Fix for PR62037

[Felix Yang]

Hi Richard,

Yeah, the testcase is there. Sorry for my mistake.
Thank you for back-porting this patch to 4.8 & 4.9 branch.

Cheers,
Felix


On Wed, Aug 13, 2014 at 5:30 PM, Richard Biener
 wrote:
> On Tue, Aug 12, 2014 at 6:40 PM, Felix Yang  wrote:
>> Hi Richard,
>>
>> I find that you missed the testcase with when committing the patch.
>
> I don't think so.
>
>> GCC 4.8 & 4.9 branch also has the same issue, may be we need to
>> fix for them too?
>
> Yeah, I'll backport it.
>
> Thanks,
> Richard.
>
>> Cheers,
>> Felix
>>
>>
>> On Mon, Aug 11, 2014 at 7:24 PM, Richard Biener
>>  wrote:
>>> On Sat, Aug 9, 2014 at 6:28 AM, Felix Yang  wrote:
 Attached please find the patch and testcase for PR62037.

 DEF1 can be a GIMPLE_NOP and gimple_bb will be NULL then. The patch
 checks for that.
 Bootstrapped on x86_64-suse-linux. OK for trunk? Please commit this
 patch if it's OK.

>>>
>>> Thanks - applied.
>>>
>>> Richard.
>>>
 Index: gcc/ChangeLog
 ===
 --- gcc/ChangeLog(revision 213772)
 +++ gcc/ChangeLog(working copy)
 @@ -1,3 +1,9 @@
 +2014-08-09  Felix Yang  
 +
 +PR tree-optimization/62073
 +* tree-vect-loop.c (vect_is_simple_reduction_1): Check that DEF1 has
 +a basic block.
 +
  2014-08-08  Guozhi Wei  

  * config/rs6000/rs6000.md (*movdi_internal64): Add a new constraint.
 Index: gcc/testsuite/gcc.dg/vect/pr62073.c
 ===
 --- gcc/testsuite/gcc.dg/vect/pr62073.c(revision 0)
 +++ gcc/testsuite/gcc.dg/vect/pr62073.c(revision 0)
 @@ -0,0 +1,41 @@
 +/* { dg-do compile } */
 +/* { dg-options "-O1 -ftree-vectorize" } */
 +
 +struct S0
 +{
 +int f7;
 +};
 +struct S0 g_50;
 +int g_70;
 +int g_76;
 +
 +
 +int foo (long long p_56, int * p_57)
 +{
 +int *l_77;
 +int l_101;
 +
 +for (; g_70;)
 +{
 +int **l_78 = &l_77;
 +if (g_50.f7)
 +continue;
 +*l_78 = 0;
 +}
 +for (g_76 = 1; g_76 >= 0; g_76--)
 +{
 +int *l_90;
 +for (l_101 = 4; l_101 >= 0; l_101--)
 +if (l_101)
 +*l_90 = 0;
 +else
 +{
 +int **l_113 = &l_77;
 +*l_113 = p_57;
 +}
 +}
 +
 +return *l_77;
 +}
 +
 +/* { dg-final { cleanup-tree-dump "vect" } } */
 Index: gcc/testsuite/ChangeLog
 ===
 --- gcc/testsuite/ChangeLog(revision 213772)
 +++ gcc/testsuite/ChangeLog(working copy)
 @@ -1,3 +1,8 @@
 +2014-08-09  Felix Yang  
 +
 +PR tree-optimization/62073
 +* gcc.dg/vect/pr62073.c: New test.
 +
  2014-08-08  Richard Biener  

  * gcc.dg/strlenopt-8.c: Remove XFAIL.
 Index: gcc/tree-vect-loop.c
 ===
 --- gcc/tree-vect-loop.c(revision 213772)
 +++ gcc/tree-vect-loop.c(working copy)
 @@ -2321,7 +2321,8 @@ vect_is_simple_reduction_1 (loop_vec_info loop_inf
  }

def1 = SSA_NAME_DEF_STMT (op1);
 -  if (flow_bb_inside_loop_p (loop, gimple_bb (def_stmt))
 +  if (gimple_bb (def1)
 +  && flow_bb_inside_loop_p (loop, gimple_bb (def_stmt))
&& loop->inner
&& flow_bb_inside_loop_p (loop->inner, gimple_bb (def1))
&& is_gimple_assign (def1))


 Cheers,
 Felix

Re: [PATCH, ARM] Set max_insns_skipped to MAX_INSN_PER_IT_BLOCK when optimize_size for THUMB2

[Richard Earnshaw]

On 25/02/14 09:34, Zhenqiang Chen wrote:
> Hi,
> 
> Current value for max_insns_skipped is 6. For THUMB2, it needs 2 (IF-THEN)
> or 3 (IF-THEN-ELSE) IT blocks to hold all the instructions. The overhead of
> IT is 4 or 6 BYTES.
> 
> If we do not generate IT blocks, for IF-THEN, the overhead of conditional
> jump is 2 or 4; for IF-THEN-ELSE, the overhead is 4, 6, or 8.
> 
> Most THUMB2 jump instructions are 2 BYTES. Tests on CSiBE show no one file
> has code size regression. So The patch sets max_insns_skipped to
> MAX_INSN_PER_IT_BLOCK.
> 
> No make check regression on cortex-m3.
> For CSiBE, no any file has code size regression. And overall there is >0.01%
> code size improvement for cortex-a9 and cortex-m4.
> 
> Is it OK?
> 
> Thanks!
> -Zhenqiang
> 
> 2014-02-25  Zhenqiang Chen  
> 
>   * config/arm/arm.c (arm_option_override): Set max_insns_skipped
>   to MAX_INSN_PER_IT_BLOCK when optimize_size for THUMB2.
> 
> testsuite/ChangeLog:
> 2014-02-25  Zhenqiang Chen  
> 
>   * gcc.target/arm/max-insns-skipped.c: New test.
> 
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index b49f43e..99cdbc4 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -2743,6 +2743,15 @@ arm_option_override (void)
>/* If optimizing for size, bump the number of instructions that we
>   are prepared to conditionally execute (even on a StrongARM).  */
>max_insns_skipped = 6;
> +
> +  /* For THUMB2, it needs 2 (IF-THEN) or 3 (IF-THEN-ELSE) IT blocks to
> +  hold all the instructions. The overhead of IT is 4 or 6 BYTES.
> +  If we do not generate IT blocks, for IF-THEN, the overhead of
> +  conditional jump is 2 or 4; for IF-THEN-ELSE, the overhead is 4, 6
> +  or 8.  Most THUMB2 jump instructions are 2 BYTES.
> +  So set max_insns_skipped to MAX_INSN_PER_IT_BLOCK.  */
> +  if (TARGET_THUMB2)
> + max_insns_skipped = MAX_INSN_PER_IT_BLOCK;

Replacing a single 2-byte branch with a 2-byte IT insn doesn't save any
space in itself.

Pedantically, we save space with IT blocks if either:
a) we can replace an else clause (saving a branch around that)
b) we can use non-flag setting versions of insns to replace what would
otherwise be 4-byte insns with 2-byte versions.

I agree that multiple IT instructions is probably not a win (the
cond-exec code doesn't know how to reason about the finer points of item
b) and doesn't even really consider a) either).

So this is OK, but I think the comment should be simplified.  Just say,
for thumb2 we limit the conditional sequence to one IT block.

OK with that change.

R.

>  }
>else
>  max_insns_skipped = current_tune->max_insns_skipped;
> diff --git a/gcc/testsuite/gcc.target/arm/max-insns-skipped.c
> b/gcc/testsuite/gcc.target/arm/max-insns-skipped.c
> new file mode 100644
> index 000..0a11554
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/max-insns-skipped.c
> @@ -0,0 +1,21 @@
> +/* { dg-do assemble { target arm_thumb2 } } */
> +/* { dg-options " -Os " } */
> +
> +int t (int a, int b, int c, int d)
> +{
> +  int r;
> +  if (a > 0) {
> +r = a + b;
> +r += 0x456;
> +r *= 0x1234567;
> +}
> +  else {
> +r = b - a;
> +r -= 0x123;
> +r *= 0x12387;
> +r += d;
> +   }
> +  return r;
> +}
> +
> +/* { dg-final { object-size text <= 40 } } */
> 
> 
> 
> 

[PATCH] Fix PR62077

[Richard Biener]

The following fixes the LTO bootstrap miscompares on the branches.
They happen because type_hash_canon can end up returning different
types (a main variant or a variant type) dependent on whether
we garbage collected before or not.

The patch makes us never return a variant type from type_hash_canon
if we fed it a main variant (and vice versa).

LTO bootstrap running on the 4.9 branch, regular bootstrap and testing
running on x86_64-unknown-linux-gnu.

Richard.

2014-08-13  Richard Biener  

PR middle-end/62077
* tree.c (type_hash_eq): Do not treat main variants equal
to non-main-variants.

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 213814)
+++ gcc/tree.c  (working copy)
@@ -6593,7 +6593,9 @@ type_hash_eq (const void *va, const void
   || !attribute_list_equal (TYPE_ATTRIBUTES (a->type),
 TYPE_ATTRIBUTES (b->type))
   || (TREE_CODE (a->type) != COMPLEX_TYPE
-  && TYPE_NAME (a->type) != TYPE_NAME (b->type)))
+  && TYPE_NAME (a->type) != TYPE_NAME (b->type))
+  || ((TYPE_MAIN_VARIANT (a->type) == TYPE_MAIN_VARIANT (a->type))
+ != (TYPE_MAIN_VARIANT (b->type) == TYPE_MAIN_VARIANT (b->type
 return 0;
 
   /* Be careful about comparing arrays before and after the element type

[PATCH] PR61878

[Ilya Tocar]

Hi,

This patch adds missing intrinsics and tests for them.
Ok for trunk?

gcc/ChangeLog:

2014-08-13  Ilya Tocar  

* config/i386/avx512fintrin.h (_mm512_mask_cmpge_epi32_mask): New.
(_mm512_mask_cmpge_epu32_mask): Ditto.
(_mm512_cmpge_epu32_mask): Ditto.
(_mm512_mask_cmpge_epi64_mask): Ditto.
(_mm512_cmpge_epi64_mask): Ditto.
(_mm512_mask_cmpge_epu64_mask): Ditto.
(_mm512_cmpge_epu64_mask): Ditto.
(_mm512_mask_cmple_epi32_mask): Ditto.
(_mm512_cmple_epi32_mask): Ditto.
(_mm512_mask_cmple_epu32_mask): Ditto.
(_mm512_cmple_epu32_mask): Ditto.
(_mm512_mask_cmple_epi64_mask): Ditto.
(_mm512_cmple_epi64_mask): Ditto.
(_mm512_mask_cmple_epu64_mask): Ditto.
(_mm512_cmple_epu64_mask): Ditto.
(_mm512_mask_cmplt_epi32_mask): Ditto.
(_mm512_cmplt_epi32_mask): Ditto.
(_mm512_mask_cmplt_epu32_mask): Ditto.
(_mm512_cmplt_epu32_mask): Ditto.
(_mm512_mask_cmplt_epi64_mask): Ditto.
(_mm512_cmplt_epi64_mask): Ditto.
(_mm512_mask_cmplt_epu64_mask): Ditto.
(_mm512_cmplt_epu64_mask): Ditto.
(_mm512_mask_cmpneq_epi32_mask): Ditto.
(_mm512_mask_cmpneq_epu32_mask): Ditto.
(_mm512_cmpneq_epu32_mask): Ditto.
(_mm512_mask_cmpneq_epi64_mask): Ditto.
(_mm512_cmpneq_epi64_mask): Ditto.
(_mm512_mask_cmpneq_epu64_mask): Ditto.
(_mm512_cmpneq_epu64_mask): Ditto.
(_mm512_castpd_ps): Ditto.
(_mm512_castpd_si512): Ditto.
(_mm512_castps_pd): Ditto.
(_mm512_castps_si512): Ditto.
(_mm512_castsi512_ps): Ditto.
(_mm512_castsi512_pd): Ditto.
(_mm512_castpd512_pd128): Ditto.
(_mm512_castps512_ps128): Ditto.
(_mm512_castsi512_si128): Ditto.
(_mm512_castpd512_pd256): Ditto.
(_mm512_castps512_ps256): Ditto.
(_mm512_castsi512_si256): Ditto.
(_mm512_castpd128_pd512): Ditto.
(_mm512_castps128_ps512): Ditto.
(_mm512_castsi128_si512): Ditto.
(_mm512_castpd256_pd512): Ditto.
(_mm512_castps256_ps512): Ditto.
(_mm512_castsi256_si512): Ditto.
(_mm512_cmpeq_epu32_mask): Ditto.
(_mm512_mask_cmpeq_epu32_mask): Ditto.
(_mm512_mask_cmpeq_epu64_mask): Ditto.
(_mm512_cmpeq_epu64_mask): Ditto.
(_mm512_cmpgt_epu32_mask): Ditto.
(_mm512_mask_cmpgt_epu32_mask): Ditto.
(_mm512_mask_cmpgt_epu64_mask): Ditto.
(_mm512_cmpgt_epu64_mask): Ditto.
* config/i386/i386-builtin-types.def: Add V16SF_FTYPE_V8SF,
V16SI_FTYPE_V8SI, V16SI_FTYPE_V4SI, V8DF_FTYPE_V2DF.
* config/i386/i386.c (enum ix86_builtins): Add
IX86_BUILTIN_SI512_SI256, IX86_BUILTIN_PD512_PD256,
IX86_BUILTIN_PS512_PS256, IX86_BUILTIN_SI512_SI,
IX86_BUILTIN_PD512_PD, IX86_BUILTIN_PS512_PS.
(bdesc_args): Add __builtin_ia32_si512_256si,
__builtin_ia32_ps512_256ps, __builtin_ia32_pd512_256pd,
__builtin_ia32_si512_si, __builtin_ia32_ps512_ps,
__builtin_ia32_pd512_pd.
(ix86_expand_args_builtin): Handle new FTYPEs.
* config/i386/sse.md (castmode): Add 512-bit modes.
(AVX512MODE2P): New.
(avx512f___256

* gcc.target/i386/avx512f-typecast-1.c: New test.
* gcc.target/i386/avx512f-vpcmpequd-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpequd-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpequq-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpequq-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpged-1.c: Add new intrinsic.
* gcc.target/i386/avx512f-vpcmpged-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpgeq-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpgeq-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpgeud-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpgeud-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpgeuq-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpgeuq-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpgtud-1.c: New test.
* gcc.target/i386/avx512f-vpcmpgtud-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpgtuq-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpgtuq-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpled-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpled-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpleq-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpleq-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpleud-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpleud-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpleuq-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpleuq-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpltd-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpltd-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpltq-1.c: Ditto.
* gcc.target/i386/avx512f-vpcmpltq-2.c: Ditto.
* gcc.target/i386/avx512f-vpcmpltud-1.c: Ditto.
* gcc.target

Re: [PATCH][www] Document versioning scheme for GCC 5 and up

[Jakub Jelinek]

On Wed, Aug 13, 2014 at 02:21:29PM +0200, Richard Biener wrote:
> 
> The release management team has aggreed to go forward with the
> change to bump the major with each further release.
> 
> The following aims to document the details of the versioning scheme we
> intend to use for GCC 5 and up.
> 
> Summary in non-html: Development of GCC 5 will happen as
> GCC 5.0.0 (experimental), once we enter regression-fixing-only mode 
> (post-stage3) it will become GCC 5.0.1 (prerelease).  The
> GCC 5 release itself will be numbered GCC 5.1.0 and development
> on the branch will continue as GCC 5.1.1 followed by a GCC 5.2.0
> release and GCC 5.2.1 branch development.  Stage1 of GCC 6 will
> bump us to GCC 6.0.0.
> 
> Ok for www?

Looks good to me, though, can you please add ...
to the title?  Would like to refer to that from index.html.

Here is my current set of changes (note, I have changed bugzilla to use
[4.9/5 Regression] and similar subjects instead of
[4.9/4.10 Regression] and renamed 4.10.0 version and milestones.

Perhaps we should also change all 4.10.0 in Known to work and Known to fail
fields?

--- develop.html16 Jul 2014 14:01:06 -  1.143
+++ develop.html13 Aug 2014 12:40:48 -
@@ -502,6 +502,10 @@ stages of development, branch points, an
| v
|   GCC 4.9.1 release (2014-07-16)
|
+  New GCC versioning scheme announced
+   |
+  GCC 5 Stage 1
+   |
v
 
 
--- index.html  30 Jul 2014 17:57:07 -  1.933
+++ index.html  13 Aug 2014 12:40:48 -
@@ -52,6 +52,10 @@ mission statement.
 
 
 
+New GCC version numbering scheme 
announced
+[2014-08-13]
+
+
 GCC 4.9.1 released
 [2014-07-16]
 
@@ -165,17 +169,17 @@ Any additions?  Don't be shy, send them 
   changes)
 
   Status:
-  
+  
   https://gcc.gnu.org/ml/gcc/2014-04/msg00090.html";>2014-04-11
-  
+  
   (general development, stage 1).
   
   
   https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.10&target_milestone=4.8.4&target_milestone=4.9.2&target_milestone=4.10.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>Serious
+  
href="https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=5&target_milestone=4.8.4&target_milestone=4.9.2&target_milestone=5.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>Serious
   regressions.
   https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.10&target_milestone=4.8.4&target_milestone=4.9.2&target_milestone=4.10.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";>All
+  
href="https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=5&target_milestone=4.8.4&target_milestone=4.9.2&target_milestone=5.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarg

Re: [PATCH] Add Berkeley qsort to libiberty to make GCC host-independent

[Felix Yang]

Hi Jakub,

I did tried to use the glibc qsort. I compared the source of the
two versions.
I found that the BSD one is more self-contained and easy for
integration with libiberty.
That's why the BSD one is preferred.
And we already have several BSD functions there in libiberty
(libiberty/random.c, an example).
Cheers,
Felix


On Wed, Aug 13, 2014 at 8:16 PM, Jakub Jelinek  wrote:
> On Wed, Aug 13, 2014 at 08:12:03PM +0800, Felix Yang wrote:
>> The qsort library function may have different behavior on
>> different hosts (say Linux vs MinGW).
>> We may have different sorting results with qsort when there are
>> elements with the same key value.
>> GCC uses qsort a lot. And the output of certain optimizations,
>> such as IRA, relies on the sorting result of this library function.
>> The problem is that we may have different assembly code of GCC on
>> different hosts even with the same source file.
>> Normally this is not what a GCC user expect to see.
>> In order to fix this issue, I am adding Berkeley qsort to
>> libiberty in order to override the one from the library.
>
> Why have you picked a BSD one rather than the GNU one?
> glibc qsort is highly optimized and has some other nice properties qsort
> from many other sources does not have.
>
> Jakub

Re: [PATCH] Fix wrong refactoring in cgraph_node::function_symbol

[Richard Biener]

On Wed, Aug 13, 2014 at 2:25 PM, Ilya Enkovich  wrote:
> Hi,
>
> This patch is to fix wrong refactoring for cgraph_node::function_symbol 
> introduced by this patch: 
> https://gcc.gnu.org/ml/gcc-cvs/2014-07/msg00805.html.  Here is how function 
> was refactored:
>
> -cgraph_function_node (struct cgraph_node *node, enum availability 
> *availability)
> +cgraph_node *
> +cgraph_node::function_symbol (enum availability *availability)
>  {
> +  cgraph_node *node = NULL;
> +
>do
>  {
> -  node = cgraph_function_or_thunk_node (node, availability);
> +  node = ultimate_alias_target (availability);
>if (node->thunk.thunk_p)
> {
>   node = node->callees->callee;
>   if (availability)
> {
>   enum availability a;
> - a = cgraph_function_body_availability (node);
> + a = node->get_availability ();
>   if (a < *availability)
> *availability = a;
> }
> - node = cgraph_function_or_thunk_node (node, availability);
> + node = node->ultimate_alias_target (availability);
> }
>  } while (node && node->thunk.thunk_p);
>return node;
>  }
>
> first ultimate_alias_target call always uses 'this' instead of 'node'.  This 
> causes infinite loop.
>
> Patch was bootstrapped and regtested on linux-x86_64.  OK for trunk?

Ok.  Do you have a testcase?

Thanks,
Richard.

> Thanks,
> Ilya
> --
>
> 2014-08-13  Ilya Enkovich  
>
> * cgraph.c (cgraph_node::function_symbol): Fix wrong
> cgraph_function_node to cgraph_node::function_symbol
> refactoring.
>
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 5a0b903..370a96a 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -3000,11 +3000,11 @@ cgraph_node::verify_cgraph_nodes (void)
>  cgraph_node *
>  cgraph_node::function_symbol (enum availability *availability)
>  {
> -  cgraph_node *node = NULL;
> +  cgraph_node *node = this;
>
>do
>  {
> -  node = ultimate_alias_target (availability);
> +  node = node->ultimate_alias_target (availability);
>if (node->thunk.thunk_p)
> {
>   node = node->callees->callee;

Re: [PATCH] Add Berkeley qsort to libiberty to make GCC host-independent

[Jakub Jelinek]

On Wed, Aug 13, 2014 at 08:48:52PM +0800, Felix Yang wrote:
> I did tried to use the glibc qsort. I compared the source of the
> two versions.
> I found that the BSD one is more self-contained and easy for
> integration with libiberty.

Being more self-contained is not what we care about, the most significant
thing about qsort from GCC POV is performance, people complain about compile
times and slowing compilation down by a few % just so that libiberty can
contain a single file rather than two files doesn't look to be a good idea.

Jakub

Re: [PATCH][www] Document versioning scheme for GCC 5 and up

[Richard Biener]

On Wed, 13 Aug 2014, Jakub Jelinek wrote:

> On Wed, Aug 13, 2014 at 02:21:29PM +0200, Richard Biener wrote:
> > 
> > The release management team has aggreed to go forward with the
> > change to bump the major with each further release.
> > 
> > The following aims to document the details of the versioning scheme we
> > intend to use for GCC 5 and up.
> > 
> > Summary in non-html: Development of GCC 5 will happen as
> > GCC 5.0.0 (experimental), once we enter regression-fixing-only mode 
> > (post-stage3) it will become GCC 5.0.1 (prerelease).  The
> > GCC 5 release itself will be numbered GCC 5.1.0 and development
> > on the branch will continue as GCC 5.1.1 followed by a GCC 5.2.0
> > release and GCC 5.2.1 branch development.  Stage1 of GCC 6 will
> > bump us to GCC 6.0.0.
> > 
> > Ok for www?
> 
> Looks good to me, though, can you please add ...
> to the title?  Would like to refer to that from index.html.

Will do.

> Here is my current set of changes (note, I have changed bugzilla to use
> [4.9/5 Regression] and similar subjects instead of
> [4.9/4.10 Regression] and renamed 4.10.0 version and milestones.
> 
> Perhaps we should also change all 4.10.0 in Known to work and Known to fail
> fields?

Yeah, I suppose we can script that later when somebody figures out
the mysql database field.

> --- develop.html  16 Jul 2014 14:01:06 -  1.143
> +++ develop.html  13 Aug 2014 12:40:48 -
> @@ -502,6 +502,10 @@ stages of development, branch points, an
> | v
> |   GCC 4.9.1 release (2014-07-16)
> |
> +  New GCC versioning scheme announced
> +   |
> +  GCC 5 Stage 1
> +   |
> v
>  
>  
> --- index.html30 Jul 2014 17:57:07 -  1.933
> +++ index.html13 Aug 2014 12:40:48 -
> @@ -52,6 +52,10 @@ mission statement.
>  
>  
>  
> +New GCC version numbering scheme 
> announced
> +[2014-08-13]
> +
> +
>  GCC 4.9.1 released
>  [2014-07-16]
>  
> @@ -165,17 +169,17 @@ Any additions?  Don't be shy, send them 
>changes)
>  
>Status:
> -  
> +  
>https://gcc.gnu.org/ml/gcc/2014-04/msg00090.html";>2014-04-11
> -  
> +  
>(general development, stage 1).
>
>
> -  
> href="https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.10&target_milestone=4.8.4&target_milestone=4.9.2&target_milestone=4.10.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&fie
 ld0-0-0=noop&type0-0-0=noop&value0-0-0=">Serious
> +  
> href="https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=5&target_milestone=4.8.4&target_milestone=4.9.2&target_milestone=5.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-
 0=noop&type0-0-0=noop&value0-0-0=">Serious
>regressions.
> -  
> href="https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.10&target_milestone=4.8.4&target_milestone=4.9.2&target_milestone=4.10.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=";
 >All
> +  
> href="https://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_t

Re: [PATCH] Fix wrong refactoring in cgraph_node::function_symbol

[Ilya Enkovich]

2014-08-13 16:48 GMT+04:00 Richard Biener :
> On Wed, Aug 13, 2014 at 2:25 PM, Ilya Enkovich  wrote:
>> Hi,
>>
>> This patch is to fix wrong refactoring for cgraph_node::function_symbol 
>> introduced by this patch: 
>> https://gcc.gnu.org/ml/gcc-cvs/2014-07/msg00805.html.  Here is how function 
>> was refactored:
>>
>> -cgraph_function_node (struct cgraph_node *node, enum availability 
>> *availability)
>> +cgraph_node *
>> +cgraph_node::function_symbol (enum availability *availability)
>>  {
>> +  cgraph_node *node = NULL;
>> +
>>do
>>  {
>> -  node = cgraph_function_or_thunk_node (node, availability);
>> +  node = ultimate_alias_target (availability);
>>if (node->thunk.thunk_p)
>> {
>>   node = node->callees->callee;
>>   if (availability)
>> {
>>   enum availability a;
>> - a = cgraph_function_body_availability (node);
>> + a = node->get_availability ();
>>   if (a < *availability)
>> *availability = a;
>> }
>> - node = cgraph_function_or_thunk_node (node, availability);
>> + node = node->ultimate_alias_target (availability);
>> }
>>  } while (node && node->thunk.thunk_p);
>>return node;
>>  }
>>
>> first ultimate_alias_target call always uses 'this' instead of 'node'.  This 
>> causes infinite loop.
>>
>> Patch was bootstrapped and regtested on linux-x86_64.  OK for trunk?
>
> Ok.  Do you have a testcase?

No, I found this problem testing pointer bounds checker, which
produces many instrumentation thunks.  It seems in a regular case we
do not have such thunks chains and one loop iteration is enough.

Ilya

>
> Thanks,
> Richard.
>
>> Thanks,
>> Ilya
>> --
>>
>> 2014-08-13  Ilya Enkovich  
>>
>> * cgraph.c (cgraph_node::function_symbol): Fix wrong
>> cgraph_function_node to cgraph_node::function_symbol
>> refactoring.
>>
>> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
>> index 5a0b903..370a96a 100644
>> --- a/gcc/cgraph.c
>> +++ b/gcc/cgraph.c
>> @@ -3000,11 +3000,11 @@ cgraph_node::verify_cgraph_nodes (void)
>>  cgraph_node *
>>  cgraph_node::function_symbol (enum availability *availability)
>>  {
>> -  cgraph_node *node = NULL;
>> +  cgraph_node *node = this;
>>
>>do
>>  {
>> -  node = ultimate_alias_target (availability);
>> +  node = node->ultimate_alias_target (availability);
>>if (node->thunk.thunk_p)
>> {
>>   node = node->callees->callee;

Re: [PATCH] Add Berkeley qsort to libiberty to make GCC host-independent

[Felix Yang]

Hi Jakub,

I got it. I will update the patch after I finished integrating the
GLIBC qsort with libiberty.
Cheers,
Felix


On Wed, Aug 13, 2014 at 8:55 PM, Jakub Jelinek  wrote:
> On Wed, Aug 13, 2014 at 08:48:52PM +0800, Felix Yang wrote:
>> I did tried to use the glibc qsort. I compared the source of the
>> two versions.
>> I found that the BSD one is more self-contained and easy for
>> integration with libiberty.
>
> Being more self-contained is not what we care about, the most significant
> thing about qsort from GCC POV is performance, people complain about compile
> times and slowing compilation down by a few % just so that libiberty can
> contain a single file rather than two files doesn't look to be a good idea.
>
> Jakub

Re: [PATCH] PR61878

[Uros Bizjak]

On Wed, Aug 13, 2014 at 2:34 PM, Ilya Tocar  wrote:

> This patch adds missing intrinsics and tests for them.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> 2014-08-13  Ilya Tocar  
>
> * config/i386/avx512fintrin.h (_mm512_mask_cmpge_epi32_mask): New.
> (_mm512_mask_cmpge_epu32_mask): Ditto.
> (_mm512_cmpge_epu32_mask): Ditto.
> (_mm512_mask_cmpge_epi64_mask): Ditto.
> (_mm512_cmpge_epi64_mask): Ditto.
> (_mm512_mask_cmpge_epu64_mask): Ditto.
> (_mm512_cmpge_epu64_mask): Ditto.
> (_mm512_mask_cmple_epi32_mask): Ditto.
> (_mm512_cmple_epi32_mask): Ditto.
> (_mm512_mask_cmple_epu32_mask): Ditto.
> (_mm512_cmple_epu32_mask): Ditto.
> (_mm512_mask_cmple_epi64_mask): Ditto.
> (_mm512_cmple_epi64_mask): Ditto.
> (_mm512_mask_cmple_epu64_mask): Ditto.
> (_mm512_cmple_epu64_mask): Ditto.
> (_mm512_mask_cmplt_epi32_mask): Ditto.
> (_mm512_cmplt_epi32_mask): Ditto.
> (_mm512_mask_cmplt_epu32_mask): Ditto.
> (_mm512_cmplt_epu32_mask): Ditto.
> (_mm512_mask_cmplt_epi64_mask): Ditto.
> (_mm512_cmplt_epi64_mask): Ditto.
> (_mm512_mask_cmplt_epu64_mask): Ditto.
> (_mm512_cmplt_epu64_mask): Ditto.
> (_mm512_mask_cmpneq_epi32_mask): Ditto.
> (_mm512_mask_cmpneq_epu32_mask): Ditto.
> (_mm512_cmpneq_epu32_mask): Ditto.
> (_mm512_mask_cmpneq_epi64_mask): Ditto.
> (_mm512_cmpneq_epi64_mask): Ditto.
> (_mm512_mask_cmpneq_epu64_mask): Ditto.
> (_mm512_cmpneq_epu64_mask): Ditto.
> (_mm512_castpd_ps): Ditto.
> (_mm512_castpd_si512): Ditto.
> (_mm512_castps_pd): Ditto.
> (_mm512_castps_si512): Ditto.
> (_mm512_castsi512_ps): Ditto.
> (_mm512_castsi512_pd): Ditto.
> (_mm512_castpd512_pd128): Ditto.
> (_mm512_castps512_ps128): Ditto.
> (_mm512_castsi512_si128): Ditto.
> (_mm512_castpd512_pd256): Ditto.
> (_mm512_castps512_ps256): Ditto.
> (_mm512_castsi512_si256): Ditto.
> (_mm512_castpd128_pd512): Ditto.
> (_mm512_castps128_ps512): Ditto.
> (_mm512_castsi128_si512): Ditto.
> (_mm512_castpd256_pd512): Ditto.
> (_mm512_castps256_ps512): Ditto.
> (_mm512_castsi256_si512): Ditto.
> (_mm512_cmpeq_epu32_mask): Ditto.
> (_mm512_mask_cmpeq_epu32_mask): Ditto.
> (_mm512_mask_cmpeq_epu64_mask): Ditto.
> (_mm512_cmpeq_epu64_mask): Ditto.
> (_mm512_cmpgt_epu32_mask): Ditto.
> (_mm512_mask_cmpgt_epu32_mask): Ditto.
> (_mm512_mask_cmpgt_epu64_mask): Ditto.
> (_mm512_cmpgt_epu64_mask): Ditto.
> * config/i386/i386-builtin-types.def: Add V16SF_FTYPE_V8SF,
> V16SI_FTYPE_V8SI, V16SI_FTYPE_V4SI, V8DF_FTYPE_V2DF.
> * config/i386/i386.c (enum ix86_builtins): Add
> IX86_BUILTIN_SI512_SI256, IX86_BUILTIN_PD512_PD256,
> IX86_BUILTIN_PS512_PS256, IX86_BUILTIN_SI512_SI,
> IX86_BUILTIN_PD512_PD, IX86_BUILTIN_PS512_PS.
> (bdesc_args): Add __builtin_ia32_si512_256si,
> __builtin_ia32_ps512_256ps, __builtin_ia32_pd512_256pd,
> __builtin_ia32_si512_si, __builtin_ia32_ps512_ps,
> __builtin_ia32_pd512_pd.
> (ix86_expand_args_builtin): Handle new FTYPEs.
> * config/i386/sse.md (castmode): Add 512-bit modes.
> (AVX512MODE2P): New.
> (avx512f__ (avx512f__256
> gcc/testsuite/ChangeLog:
>
> 2014-08-13  Ilya Tocar  
>
> * gcc.target/i386/avx512f-typecast-1.c: New test.
> * gcc.target/i386/avx512f-vpcmpequd-1.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpequd-2.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpequq-1.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpequq-2.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpged-1.c: Add new intrinsic.
> * gcc.target/i386/avx512f-vpcmpged-2.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpgeq-1.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpgeq-2.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpgeud-1.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpgeud-2.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpgeuq-1.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpgeuq-2.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpgtud-1.c: New test.
> * gcc.target/i386/avx512f-vpcmpgtud-2.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpgtuq-1.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpgtuq-2.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpled-1.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpled-2.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpleq-1.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpleq-2.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpleud-1.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpleud-2.c: Ditto.
> * gcc.target/i386/avx512f-vpcmpleuq-1.c: Ditto.
> * gcc.target/i386/av

Re: [PATCH i386 AVX512] [8/n] Extend substs for new patterns.

[Uros Bizjak]

On Wed, Aug 13, 2014 at 2:14 PM, Kirill Yukhin  wrote:

>> In a couple of places,  checks are changed to GET_MODE_SIZE
>> (GET_MODE (operands[0])) and in a similar way, mode checks were
>> changed to GET_MODE (operands[0]). The previous checks are more
>> efficient and are preferred. Is there a reason you need to check
>> operands[0] dynamically?
>
> I agree, runtime tests are worse. But this subst attributes are used
> in patterns which actually do not contain mode iterators at all.

IMO, two different subst patterns should be used in this case, one for
patterns with and one for patterns w/o mode iterators.

Uros.

[C++ Patch] Remove "invalid type in declaration" parser error

[Paolo Carlini]

Hi,

thus I have now fully tested the below.

Thanks!
Paolo.

/
/gcc/cp
2014-08-13  Paolo Carlini  

* parser.c (cp_parser_init_declarator): Remove redundant check of
decl_specifiers->type.

/gcc/testsuite
2014-08-13  Paolo Carlini  

* g++.dg/cpp0x/alias-decl-4.C: Adjust for parser change.
* g++.dg/cpp0x/decltype2.C: Likewise.
* g++.dg/cpp0x/decltype3.C: Likewise.
* g++.dg/cpp0x/pr60249.C: Likewise.
* g++.dg/cpp0x/variadic-ex10.C: Likewise.
* g++.dg/cpp0x/variadic-ex14.C: Likewise.
* g++.dg/cpp0x/variadic2.C: Likewise.
* g++.dg/cpp0x/variadic74.C: Likewise.
* g++.dg/parse/error10.C: Likewise.
* g++.dg/parse/error15.C: Likewise.
* g++.dg/parse/error2.C: Likewise.
* g++.dg/template/crash106.C: Likewise.
* g++.dg/template/crash89.C: Likewise.
* g++.dg/template/nontype7.C: Likewise.
* g++.dg/template/void3.C: Likewise.
* g++.dg/template/void7.C: Likewise.

/libstdc++-v3
2014-08-13  Paolo Carlini  

* testsuite/26_numerics/random/linear_congruential_engine/
requirements/non_uint_neg.cc: Adjust for parser change.
* testsuite/tr1/5_numerical_facilities/random/linear_congruential/
requirements/non_uint_neg.cc: Likewise.
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 213898)
+++ gcc/cp/parser.c (working copy)
@@ -16900,17 +16900,6 @@ cp_parser_init_declarator (cp_parser* parser,
  possibly be looking at any other construct.  */
   cp_parser_commit_to_tentative_parse (parser);
 
-  /* If the decl specifiers were bad, issue an error now that we're
- sure this was intended to be a declarator.  Then continue
- declaring the variable(s), as int, to try to cut down on further
- errors.  */
-  if (decl_specifiers->any_specifiers_p
-  && decl_specifiers->type == error_mark_node)
-{
-  cp_parser_error (parser, "invalid type in declaration");
-  decl_specifiers->type = integer_type_node;
-}
-
   /* Enter the newly declared entry in the symbol table.  If we're
  processing a declaration in a class-specifier, we wait until
  after processing the initializer.  */
Index: gcc/testsuite/g++.dg/cpp0x/alias-decl-4.C
===
--- gcc/testsuite/g++.dg/cpp0x/alias-decl-4.C   (revision 213898)
+++ gcc/testsuite/g++.dg/cpp0x/alias-decl-4.C   (working copy)
@@ -11,4 +11,4 @@ template  using B = typename A::U; //
 template  struct A {
 typedef B U;
 };
-B b; // { dg-error "invalid type" }
+B b;
Index: gcc/testsuite/g++.dg/cpp0x/decltype2.C
===
--- gcc/testsuite/g++.dg/cpp0x/decltype2.C  (revision 213898)
+++ gcc/testsuite/g++.dg/cpp0x/decltype2.C  (working copy)
@@ -45,7 +45,6 @@ int bar(int);
 CHECK_DECLTYPE(decltype(foo), int(char));
 
 decltype(bar) z; // { dg-error "overload" "overload" }
-// { dg-error "invalid type" "invalid" { target *-*-* } 47 }
 
 CHECK_DECLTYPE(decltype(&foo), int(*)(char));
 CHECK_DECLTYPE(decltype(*&foo), int(&)(char));
Index: gcc/testsuite/g++.dg/cpp0x/decltype3.C
===
--- gcc/testsuite/g++.dg/cpp0x/decltype3.C  (revision 213898)
+++ gcc/testsuite/g++.dg/cpp0x/decltype3.C  (working copy)
@@ -55,7 +55,7 @@ class B {
 
 CHECK_DECLTYPE(decltype(aa.*&A::a), int&);
 decltype(aa.*&A::b) zz; // { dg-error "cannot create pointer to reference 
member" "cannot" }
-// { dg-error "invalid type" "invalid type" { target *-*-* } 57 }
+
 CHECK_DECLTYPE(decltype(caa.*&A::a), const int&);
 
 class X { 
Index: gcc/testsuite/g++.dg/cpp0x/pr60249.C
===
--- gcc/testsuite/g++.dg/cpp0x/pr60249.C(revision 213898)
+++ gcc/testsuite/g++.dg/cpp0x/pr60249.C(working copy)
@@ -2,5 +2,3 @@
 // { dg-do compile { target c++11 } }
 
 decltype(""_) x; // { dg-error "unable to find string literal operator" }
-
-// { dg-error "invalid type in declaration before" "invalid" { target *-*-* } 
4 }
Index: gcc/testsuite/g++.dg/cpp0x/variadic-ex10.C
===
--- gcc/testsuite/g++.dg/cpp0x/variadic-ex10.C  (revision 213898)
+++ gcc/testsuite/g++.dg/cpp0x/variadic-ex10.C  (working copy)
@@ -6,4 +6,3 @@ Tuple t1; // Types contains one argument: int
 Tuple t2; // Types contains two arguments: int and float
 Tuple<0> error; // { dg-error "mismatch" "mismatch" }
 // { dg-message "expected a type" "expected a type" { target *-*-* } 7 }
-// { dg-error "in declaration" "in declaration" { target *-*-* } 7 }
Index: gcc/testsuite/g++.dg/cpp0x/variadic-ex14.C
===
--- gcc/testsuite/g++.dg/cpp0x/variadic-ex14.C  (revision 213898)
+++ gcc/testsuite/g+

Re: [PATCH] Add Berkeley qsort to libiberty to make GCC host-independent

[Jeff Law]

On 08/13/14 06:12, Felix Yang wrote:

Hi all,

 The qsort library function may have different behavior on
different hosts (say Linux vs MinGW).
 We may have different sorting results with qsort when there are
elements with the same key value.
 GCC uses qsort a lot. And the output of certain optimizations,
such as IRA, relies on the sorting result of this library function.
 The problem is that we may have different assembly code of GCC on
different hosts even with the same source file.
 Normally this is not what a GCC user expect to see.
 In order to fix this issue, I am adding Berkeley qsort to
libiberty in order to override the one from the library.

 Bootstrapped on x86_64-suse-linux, OK for trunk? Please help
commit this patch if it's OK.
Or we find the cases where the sort comparison routine can be tweaked to 
make it stable which makes this class of problems go away.


jeff

[PATCH] Fix UB in diagnostic.c

[Marek Polacek]

This should fix an undefined behavior in diagnostics.c.
Under certain circumstances, max_width is (INT_MAX - 1),
and right_margin is -4 -> the subtraction overflows.
Changing the types to unsigned would involve changing
much more code than just one cast.

BTW, the diagnostics we output for the testcase in the PR
is crap - but I'm not fixing it now.

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

2014-08-13  Marek Polacek  

PR c/62059
* diagnostic.c (adjust_line): Perform the subtraction in unsigned.

diff --git gcc/diagnostic.c gcc/diagnostic.c
index 0cc7593..6bc9a2c 100644
--- gcc/diagnostic.c
+++ gcc/diagnostic.c
@@ -271,7 +271,7 @@ adjust_line (const char *line, int line_width,
   int column = *column_p;
 
   right_margin = MIN (line_width - column, right_margin);
-  right_margin = max_width - right_margin;
+  right_margin = max_width - (unsigned int) right_margin;
   if (line_width >= max_width && column > right_margin)
 {
   line += column - right_margin;

Marek

Re: [PATCH 028/236] cfgexpand.c: Use rtx_insn

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

gcc/
* cfgexpand.c (expand_used_vars): Strengthen return type from rtx
to rtx_insn *; also for local "var_end_seq".
(maybe_dump_rtl_for_gimple_stmt): Likewise for param "since".
(maybe_cleanup_end_of_block): Likewise for param "last" and local
"insn".
(expand_gimple_cond): Likewise for locals "last2" and "last".
(mark_transaction_restart_calls): Likewise for local "insn".
(expand_gimple_stmt): Likewise for return type and locals "last"
and "insn".
(expand_gimple_tailcall): Likewise for locals "last2" and "last".
(avoid_complex_debug_insns): Likewise for param "insn".
(expand_debug_locations): Likewise for locals "insn", "last",
"prev_insn" and "insn2".
(expand_gimple_basic_block): Likewise for local "last".
(construct_exit_block): Likewise for locals "head", "end",
"orig_end".
(pass_expand::execute): Likewise for locals "var_seq",
"var_ret_seq", "next".

OK.
Jeff

Re: [PATCH 029/236] rtl_data.x_parm_birth_insn is an insn

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

gcc/
* function.h (struct rtl_data): Strengthen field
"x_parm_birth_insn" from rtx to rtx_insn *.
* function.c (struct assign_parm_data_all): Strengthen fields
"first_conversion_insn" and "last_conversion_insn" from rtx to
rtx_insn *.
OK.  I think at this point any patch which merely changes the type of 
some variable or in a signature from rtx to rtx_insn (or any of the 
concrete passes) is considered trivial enough to go forward without 
explicit review.


That applies to patches in this series, additions you may need to make 
due to changes in the tree since you last rebased and further 
strengthening you or anyone else may want to tackle.




jeff

Re: [PATCH 031/236] emit_jump_table_data returns an rtx_jump_table_data *

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

gcc/
* emit-rtl.c (emit_jump_table_data): Strengthen return type from
rtx to rtx_jump_table_data *.  Also for local.
* rtl.h (emit_jump_table_data): Likwise.

OK.
jeff

Re: [PATCH 005/236] Introduce as_a_nullable

[Jeff Law]

On 08/13/14 04:07, Richard Biener wrote:

On Wed, Aug 13, 2014 at 12:01 PM, Martin Jambor  wrote:

Hi,

On Wed, Aug 06, 2014 at 01:19:44PM -0400, David Malcolm wrote:

In many circumstances, is_a_helper ::test assumes that the pointer is
non-NULL, but sometimes you have a pointer of type T that can be NULL.

Earlier versions of this patch kit made numerous uses of the ternary
operator to handle nullable pointers e.g.:

   return insn ? as_a  (insn) : NULL;

but this was ugly.  Instead, introduce an as_a_nullable variant that
adds a check for NULL, so the above can be written simply as:

   return as_a_nullable  (insn);


A tiny bikeshedding, disregard it if you don't like it: however, the
"nullable" part of the name suggests the pointer can be NULLed in the
process.  I think that variants of functions that survive NULL
arguments are traditionally called "safe" in gcc, so what about
"safe_as" (or safely_as)?


Ok, I resisted at first starting the bike-shedding but I agree on
the badness of "nullable" (what does that mean anyway?).
as_a_safe or safe_as_a both work for me.

Then let's go with that.

David, pick one of those and adjust accordingly.  Hopefully the cases 
where you have to adjust aren't too many.


Adjusting any patch already approved with the name change is pre-approved.


jeff

Re: [PATCH libstdc++ v3] - Add xmethods for std::vector and std::unique_ptr

[Siva Chandra]

Ping. Any update on this?

On Wed, Aug 6, 2014 at 6:37 AM, Siva Chandra  wrote:
> On Wed, Aug 6, 2014 at 2:47 AM, Jonathan Wakely  wrote:
>> Some GNU/Linux distros already build GDB using Python3, so they will
>> be unable to use these xmethods.
>>
>> However, I think it can be committed now and fixed later.
>
> For the libstdc++ side, it is a very small fix (using 'print' with
> function call syntax in one place.) I have attached a new patch which
> has this fix.
>
>> OK for trunk. Do you need me to do the commit for you?
>
> Yes, you will need to commit it for me.

Re: [PATCH] Add Berkeley qsort to libiberty to make GCC host-independent

[Felix Yang]

Is this possible a Canadian build. I am afread that the qsort then is
from the MinGW/Win host?
Cheers,
Felix


On Wed, Aug 13, 2014 at 9:31 PM, Jeff Law  wrote:
> On 08/13/14 06:12, Felix Yang wrote:
>>
>> Hi all,
>>
>>  The qsort library function may have different behavior on
>> different hosts (say Linux vs MinGW).
>>  We may have different sorting results with qsort when there are
>> elements with the same key value.
>>  GCC uses qsort a lot. And the output of certain optimizations,
>> such as IRA, relies on the sorting result of this library function.
>>  The problem is that we may have different assembly code of GCC on
>> different hosts even with the same source file.
>>  Normally this is not what a GCC user expect to see.
>>  In order to fix this issue, I am adding Berkeley qsort to
>> libiberty in order to override the one from the library.
>>
>>  Bootstrapped on x86_64-suse-linux, OK for trunk? Please help
>> commit this patch if it's OK.
>
> Or we find the cases where the sort comparison routine can be tweaked to
> make it stable which makes this class of problems go away.
>
> jeff

Re: [PATCH] Add Berkeley qsort to libiberty to make GCC host-independent

[Ian Lance Taylor]

On Wed, Aug 13, 2014 at 6:31 AM, Jeff Law  wrote:
> On 08/13/14 06:12, Felix Yang wrote:
>>
>> Hi all,
>>
>>  The qsort library function may have different behavior on
>> different hosts (say Linux vs MinGW).
>>  We may have different sorting results with qsort when there are
>> elements with the same key value.
>>  GCC uses qsort a lot. And the output of certain optimizations,
>> such as IRA, relies on the sorting result of this library function.
>>  The problem is that we may have different assembly code of GCC on
>> different hosts even with the same source file.
>>  Normally this is not what a GCC user expect to see.
>>  In order to fix this issue, I am adding Berkeley qsort to
>> libiberty in order to override the one from the library.
>>
>>  Bootstrapped on x86_64-suse-linux, OK for trunk? Please help
>> commit this patch if it's OK.
>
> Or we find the cases where the sort comparison routine can be tweaked to
> make it stable which makes this class of problems go away.

I tend to agree.  When we want a fully specified sort, it seems to me
we should use a fully specified comparison routine.

Ian

Re: [PATCH 000/236] Introduce rtx subclasses

[Jeff Law]

On 08/12/14 18:26, David Malcolm wrote:

Essentially zero in the work-to-date.

Of the 13 new subclasses of rtx, I only make major use of about half of
them; here are the frequencies (as reported by grep -w in my current
working copy):

   class rtx_def;   /* ~26000 for "rtx" */
 class rtx_expr_list;   /* 73 */
 class rtx_insn_list;   /* 130 */
 class rtx_sequence;/* 71 */
 class rtx_insn;/* ~4300 */
   class rtx_real_insn; /* 17 */
 class rtx_debug_insn;  /* 9 */
 class rtx_nonjump_insn;/* 5 */
 class rtx_jump_insn;   /* 9 */
 class rtx_call_insn;   /* 25 */
   class rtx_jump_table_data;   /* 41 */
   class rtx_barrier;   /* 25 */
   class rtx_code_label;/* 176 */
   class rtx_note;  /* 63 */

i.e. rtx_real_insn is basically unused, as are rtx_debug_insn,
rtx_nonjump_insn and rtx_jump_insn.

I think there's a case for keeping the concrete subclasses (those last
three), but we can drop rtx_real_insn.
Let's go with that.  I wouldn't be surprised if we find more cases where 
we want the more concrete classes in the future, so I'm not worried 
about their low usage at this point.


And we can always re-introduce the real-insn concept in the future if we 
find the need.  I guess I'm rather biased against deep inheritance 
hierarchies after working on projects with unnecessarily deep 
hierarchies in the past.





with an rtx_real_insn you're guaranteed at least a "uuBeiie".  But
nothing is using that in the patches as they stand, so we can simply
drop the class.
And that's the one property I think argues to keep the intermediate 
class.  But with nothing using it right now, let's drop.




Perhaps the class hierarchy diagram in coretypes.h should gain the above
operand annotation?

Sure.  Feel free to add that tidbit whenever you feel.


No strong opinion here.  I think we added NULL_TREE/NULL_RTX.  I could
possibly see extending that to the overall concept of "insn chain
things", but I think doing one for each subclass would probably be overkill.


In the absence of strong opinions, maybe we should proceed with the
patches as written i.e. *without* a NULL_INSN define.

OK.  We can revisit if/when we make things in the chain separate from rtxs.




So out of curiosity, any thoughts on what other big things are out there
that need to be fixed.  I'm keen to keep this stuff moving as much as
possible.


Arguably PATTERN() should require an rtx_insn * rather than a plain rtx,
but it would be an involved patch.

Yea.  That's a good one.  Probably a series unto itself at some point.





Other followups would be to reduce the number of as_a  in
the code; for example grepping for "uncast_" shows quite a few, a
pattern where I strengthen the type of a parameter as seen within the
function without needing to strengthen the param itself, where:

Yea.  These are reasonable to attack independently.





A part of me really wonders if the 6 phases above should have been
submitted independently.  ie, once the scaffolding was done why not go
ahead and get that reviewed & installed, then move on to phase2 patches.
   I bring it up more for future work of a similar nature.

I realize that you had to do a fair amount of the later work to ensure
the scaffolding was right and so that we could see what the end result
would likely look like.  But something feels like it could be staged better.


FWIW What you're seeing is the end result of a *lot* of
"git rebase -i", where I was splitting, combining, and reordering
patches: the phases didn't exist as fully-formed entities until I was
ready to send the patches.

Though I appreciate things were suboptimal here.
Understood.  Just looking for a way where we an move this kind of work 
forward without the level of pain on your side and without having to 
wait for a 236 series patchset before it can be contributed.  Maybe we 
just have to accept that this kind of work is going to be difficult to 
stage for reviews.  Dunno, just feels like we ought to be able to make 
it simpler for both of us and have smaller hunks staging in earlier.


Jeff

Re: [PATCH] Add Berkeley qsort to libiberty to make GCC host-independent

[Jeff Law]

On 08/13/14 07:55, Felix Yang wrote:

Is this possible a Canadian build. I am afread that the qsort then is
from the MinGW/Win host?
The stability of the sort is independent of the underlying qsort 
implementation if the comparison routine is fully specified.


It's somewhat painful, but I'd really prefer to have every qsort 
callback routine fully specified.  So if you have examples where it 
isn't certainly pass them along.



jeff

[PATCH] Fix PR62079

[Richard Biener]

It looks like RTL peep2 can leave unreachable blocks around by
missing to check the currently write-only variable
peep2_do_cleanup_cfg at the end and cleanup the CFG in that
case.

Fixed like so, bootstrap and regtest scheduled on 
x86_64-unknown-linux-gnu.

Richard.

2014-08-13  Richard Biener  

PR rtl-optimization/62079
* recog.c (peephole2_optimize): If peep2_do_cleanup_cfg
run cleanup_cfg.

* g++.dg/pr62079.C: New testcase.

Index: gcc/recog.c
===
--- gcc/recog.c (revision 213909)
+++ gcc/recog.c (working copy)
@@ -3553,6 +3553,8 @@ peephole2_optimize (void)
   BITMAP_FREE (live);
   if (peep2_do_rebuild_jump_labels)
 rebuild_jump_labels (get_insns ());
+  if (peep2_do_cleanup_cfg)
+cleanup_cfg (CLEANUP_CFG_CHANGED);
 }
 #endif /* HAVE_peephole2 */
 
Index: gcc/testsuite/g++.dg/pr62079.C
===
--- gcc/testsuite/g++.dg/pr62079.C  (revision 0)
+++ gcc/testsuite/g++.dg/pr62079.C  (working copy)
@@ -0,0 +1,78 @@
+// { dg-do compile }
+// { dg-options "-std=c++11 -O2 -fnon-call-exceptions" }
+
+template < typename > class allocator;
+
+template < class _CharT > struct char_traits;
+template < typename _CharT, typename _Traits = char_traits < _CharT >,
+  typename _Alloc = allocator < _CharT > >class basic_string;
+typedef basic_string < char >string;
+
+template < typename _Tp > class new_allocator
+{
+  template < typename _Tp1 > struct rebind
+  {
+typedef new_allocator < _Tp1 > other;
+  };
+};
+
+template < typename _Tp > using __allocator_base = new_allocator < _Tp >;
+template < typename _Tp > class allocator:public __allocator_base < _Tp >
+{
+};
+
+template < typename _CharT, typename _Traits, typename _Alloc >
+  class basic_string
+{
+public:
+  basic_string (const _CharT * __s, const _Alloc & __a = _Alloc ());
+  ~basic_string ()noexcept;
+};
+
+template < typename T > struct add_reference
+{
+  typedef T & type;
+};
+
+template < typename ... Values > class tuple;
+template <> class tuple <>
+{
+};
+
+template < typename Head, typename ... Tail > class tuple < Head, Tail ... 
>:private tuple <
+  Tail ...
+  >
+{
+  typedef tuple < Tail ... >inherited;
+public:
+  template < typename ... VValues >
+tuple (const tuple < VValues ... >&other):inherited (other.tail ()),
+m_head (other.head ())
+  {
+  }
+  typename add_reference < const Head >::type head () const
+  {
+return m_head;
+  }
+  const inherited & tail () const
+  {
+return *this;
+  }
+  Head m_head;
+};
+
+template < typename T > struct make_tuple_result
+{
+  typedef T type;
+};
+
+template < typename ... Values >
+  tuple < typename make_tuple_result <
+  Values >::type ... >make_tuple (const Values & ... values);
+
+int
+main ()
+{
+  tuple < int, float, string > t3c =
+make_tuple (17, 2.718281828, string ("Fun"));
+}

[PATCH] Fix PR62090

[Richard Biener]

The following fixes expected fallout from the move of builtins.c
foldings to gimple-fold.c.  Fixed by moving some more.

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

Richard.

2014-08-13  Richard Biener  

PR tree-optimization/62090
* builtins.c (fold_builtin_sprintf): Move to gimple-fold.c.
(fold_builtin_2): Do not fold sprintf.
(fold_builtin_3): Likewise.
* gimple-fold.c (gimple_fold_builtin_sprintf): New function
moved from builtins.c.
(gimple_fold_builtin): Fold sprintf.

* gcc.dg/pr62090.c: New testcase.

Index: gcc/builtins.c
===
--- gcc/builtins.c  (revision 213811)
+++ gcc/builtins.c  (working copy)
@@ -190,7 +190,6 @@ static tree fold_builtin_strrchr (locati
 static tree fold_builtin_strncat (location_t, tree, tree, tree);
 static tree fold_builtin_strspn (location_t, tree, tree);
 static tree fold_builtin_strcspn (location_t, tree, tree);
-static tree fold_builtin_sprintf (location_t, tree, tree, tree, int);
 static tree fold_builtin_snprintf (location_t, tree, tree, tree, tree, int);
 
 static rtx expand_builtin_object_size (tree);
@@ -10234,9 +10233,6 @@ fold_builtin_2 (location_t loc, tree fnd
 case BUILT_IN_VA_START:
   break;
 
-case BUILT_IN_SPRINTF:
-  return fold_builtin_sprintf (loc, arg0, arg1, NULL_TREE, ignore);
-
 case BUILT_IN_OBJECT_SIZE:
   return fold_builtin_object_size (arg0, arg1);
 
@@ -10313,9 +10309,6 @@ fold_builtin_3 (location_t loc, tree fnd
 case BUILT_IN_MEMCMP:
   return fold_builtin_memcmp (loc, arg0, arg1, arg2);;
 
-case BUILT_IN_SPRINTF:
-  return fold_builtin_sprintf (loc, arg0, arg1, arg2, ignore);
-
 case BUILT_IN_SNPRINTF:
   return fold_builtin_snprintf (loc, arg0, arg1, arg2, NULL_TREE, ignore);
 
@@ -11237,94 +11230,6 @@ fold_builtin_next_arg (tree exp, bool va
 }
 
 
-/* Simplify a call to the sprintf builtin with arguments DEST, FMT, and ORIG.
-   ORIG may be null if this is a 2-argument call.  We don't attempt to
-   simplify calls with more than 3 arguments.
-
-   Return NULL_TREE if no simplification was possible, otherwise return the
-   simplified form of the call as a tree.  If IGNORED is true, it means that
-   the caller does not use the returned value of the function.  */
-
-static tree
-fold_builtin_sprintf (location_t loc, tree dest, tree fmt,
- tree orig, int ignored)
-{
-  tree call, retval;
-  const char *fmt_str = NULL;
-
-  /* Verify the required arguments in the original call.  We deal with two
- types of sprintf() calls: 'sprintf (str, fmt)' and
- 'sprintf (dest, "%s", orig)'.  */
-  if (!validate_arg (dest, POINTER_TYPE)
-  || !validate_arg (fmt, POINTER_TYPE))
-return NULL_TREE;
-  if (orig && !validate_arg (orig, POINTER_TYPE))
-return NULL_TREE;
-
-  /* Check whether the format is a literal string constant.  */
-  fmt_str = c_getstr (fmt);
-  if (fmt_str == NULL)
-return NULL_TREE;
-
-  call = NULL_TREE;
-  retval = NULL_TREE;
-
-  if (!init_target_chars ())
-return NULL_TREE;
-
-  /* If the format doesn't contain % args or %%, use strcpy.  */
-  if (strchr (fmt_str, target_percent) == NULL)
-{
-  tree fn = builtin_decl_implicit (BUILT_IN_STRCPY);
-
-  if (!fn)
-   return NULL_TREE;
-
-  /* Don't optimize sprintf (buf, "abc", ptr++).  */
-  if (orig)
-   return NULL_TREE;
-
-  /* Convert sprintf (str, fmt) into strcpy (str, fmt) when
-'format' is known to contain no % formats.  */
-  call = build_call_expr_loc (loc, fn, 2, dest, fmt);
-  if (!ignored)
-   retval = build_int_cst (integer_type_node, strlen (fmt_str));
-}
-
-  /* If the format is "%s", use strcpy if the result isn't used.  */
-  else if (fmt_str && strcmp (fmt_str, target_percent_s) == 0)
-{
-  tree fn;
-  fn = builtin_decl_implicit (BUILT_IN_STRCPY);
-
-  if (!fn)
-   return NULL_TREE;
-
-  /* Don't crash on sprintf (str1, "%s").  */
-  if (!orig)
-   return NULL_TREE;
-
-  /* Convert sprintf (str1, "%s", str2) into strcpy (str1, str2).  */
-  if (!ignored)
-   {
- retval = c_strlen (orig, 1);
- if (!retval || TREE_CODE (retval) != INTEGER_CST)
-   return NULL_TREE;
-   }
-  call = build_call_expr_loc (loc, fn, 2, dest, orig);
-}
-
-  if (call && retval)
-{
-  retval = fold_convert_loc
-   (loc, TREE_TYPE (TREE_TYPE (builtin_decl_implicit (BUILT_IN_SPRINTF))),
-retval);
-  return build2 (COMPOUND_EXPR, TREE_TYPE (retval), call, retval);
-}
-  else
-return call;
-}
-
 /* Simplify a call to the snprintf builtin with arguments DEST, DESTSIZE,
FMT, and ORIG.  ORIG may be null if this is a 3-argument call.  We don't
attempt to simplify calls with more than 4 arguments.
Index: gcc/gimple-fold.c
=

[PATCH] Remove current_function_decl usage from get_polymorphic_call_info

[Ilya Enkovich]

Hi,

Testing 'mpx' branch after merge with trunk I got a segfault in ipa-devirt.c.  
It appears that cgraph_node cloning with indirect edge causes call to 
get_polymorphic_call_info which uses current_function_decl.  It happens in IPA 
pass and therefore current_function_decl is NULL which causes segfault.  Also 
even within a GIMPLE pass it seems wrong to use current_function_decl because 
examined call may belong to another function and passed fndecl should be used 
instead.

Proposed patch was bootstrapped and regtested on linux-x86_64.  OK for trunk?

Thanks,
Ilya
--

2014-08-13  Ilya Enkovich  

* ipa-devirt.c (get_polymorphic_call_info): Use fndecl instead of
current_function_decl.


diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 3650b43..0f38655 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -2319,7 +2319,7 @@ get_polymorphic_call_info (tree fndecl,
 = decl_maybe_in_construction_p (base,
 context->outer_type,
 call,
-current_function_decl);
+fndecl);
  return base;
}
  else

Re: [PATCH] Remove current_function_decl usage from get_polymorphic_call_info

[Richard Biener]

On Wed, Aug 13, 2014 at 4:17 PM, Ilya Enkovich  wrote:
> Hi,
>
> Testing 'mpx' branch after merge with trunk I got a segfault in ipa-devirt.c. 
>  It appears that cgraph_node cloning with indirect edge causes call to 
> get_polymorphic_call_info which uses current_function_decl.  It happens in 
> IPA pass and therefore current_function_decl is NULL which causes segfault.  
> Also even within a GIMPLE pass it seems wrong to use current_function_decl 
> because examined call may belong to another function and passed fndecl should 
> be used instead.
>
> Proposed patch was bootstrapped and regtested on linux-x86_64.  OK for trunk?

Ok.

Thanks,
Richard.

> Thanks,
> Ilya
> --
>
> 2014-08-13  Ilya Enkovich  
>
> * ipa-devirt.c (get_polymorphic_call_info): Use fndecl instead of
> current_function_decl.
>
>
> diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
> index 3650b43..0f38655 100644
> --- a/gcc/ipa-devirt.c
> +++ b/gcc/ipa-devirt.c
> @@ -2319,7 +2319,7 @@ get_polymorphic_call_info (tree fndecl,
>  = decl_maybe_in_construction_p (base,
>  context->outer_type,
>  call,
> -current_function_decl);
> +fndecl);
>   return base;
> }
>   else

Re: [PATCH i386 AVX512] [8/n] Extend substs for new patterns.

[Kirill Yukhin]

On 13 Aug 15:21, Uros Bizjak wrote:
> On Wed, Aug 13, 2014 at 2:14 PM, Kirill Yukhin  
> wrote:
> 
> >> In a couple of places,  checks are changed to GET_MODE_SIZE
> >> (GET_MODE (operands[0])) and in a similar way, mode checks were
> >> changed to GET_MODE (operands[0]). The previous checks are more
> >> efficient and are preferred. Is there a reason you need to check
> >> operands[0] dynamically?
> >
> > I agree, runtime tests are worse. But this subst attributes are used
> > in patterns which actually do not contain mode iterators at all.
> 
> IMO, two different subst patterns should be used in this case, one for
> patterns with and one for patterns w/o mode iterators.

That was my second thought after I hit `send'.

Updated patch in the bottom

Bootstrapped.

(Regtest w/ new tests is in progress).

Is it ok if pass?

gcc/
* config/i386/sse.md: Allow V64QI, V32QI, V32HI, V4HI modes.
* config/i386/subst.md
(define_mode_iterator SUBST_V): Update.
(define_mode_iterator SUBST_A): Ditto.
(define_subst_attr "mask_operand7"): New.
(define_subst_attr "mask_operand10"): New.
(define_subst_attr "mask_operand_arg34") : New.
(define_subst_attr "mask_expand_op3"): New.
(define_subst_attr "mask_mode512bit_condition"): Handle TARGET_AVX512VL.
(define_subst_attr "sd_mask_mode512bit_condition"): Ditto.
(define_subst_attr "mask_avx512vl_condition"): New.
(define_subst_attr "round_mask_operand4"): Ditto.
(define_subst_attr "round_mask_scalar_op3"): Delete.
(define_subst_attr "round_mask_op4"): New.
(define_subst_attr "round_mode512bit_condition"): Allow V8DImode,
V16SImode.
(define_subst_attr "round_modev8sf_condition"): New.
(define_subst_attr "round_modev4sf_condition"): GET_MODE instead of
mode.
(define_subst_attr "round_saeonly_mask_operand4"): New.
(define_subst_attr "round_saeonly_mask_op4"): New.
(define_subst_attr "round_saeonly_mode512bit_condition"): Allow
V8DImode, V16SImode.
(define_subst_attr "round_saeonly_modev8sf_condition"): New.
(define_subst_attr "mask_expand4_name" "mask_expand4"): New.
(define_subst_attr "mask_expand4_args"): New.
(define_subst "mask_expand4"): New.

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 3337104..ebe38f3 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -471,8 +471,8 @@
 
 ;; Mapping of vector modes to corresponding mask size
 (define_mode_attr avx512fmaskmode
-  [(V16QI "HI")
-   (V16HI "HI") (V8HI  "QI")
+  [(V64QI "DI") (V32QI "SI") (V16QI "HI")
+   (V32HI "SI") (V16HI "HI") (V8HI  "QI") (V4HI "QI")
(V16SI "HI") (V8SI  "QI") (V4SI  "QI")
(V8DI  "QI") (V4DI  "QI") (V2DI  "QI")
(V16SF "HI") (V8SF  "QI") (V4SF  "QI")
diff --git a/gcc/config/i386/subst.md b/gcc/config/i386/subst.md
index 1654cba..edb0965 100644
--- a/gcc/config/i386/subst.md
+++ b/gcc/config/i386/subst.md
@@ -20,8 +20,8 @@
 ;; Some iterators for extending subst as much as possible
 ;; All vectors (Use it for destination)
 (define_mode_iterator SUBST_V
-  [V16QI
-   V16HI V8HI
+  [V64QI V32QI V16QI
+   V32HI V16HI V8HI
V16SI V8SI  V4SI
V8DI  V4DI  V2DI
V16SF V8SF  V4SF
@@ -31,8 +31,8 @@
   [QI HI SI DI])
 
 (define_mode_iterator SUBST_A
-  [V16QI
-   V16HI V8HI
+  [V64QI V32QI V16QI
+   V32HI V16HI V8HI
V16SI V8SI  V4SI
V8DI  V4DI  V2DI
V16SF V8SF  V4SF
@@ -47,16 +47,21 @@
 (define_subst_attr "mask_operand3_1" "mask" "" "%%{%%4%%}%%N3") ;; for sprintf
 (define_subst_attr "mask_operand4" "mask" "" "%{%5%}%N4")
 (define_subst_attr "mask_operand6" "mask" "" "%{%7%}%N6")
+(define_subst_attr "mask_operand7" "mask" "" "%{%8%}%N7")
+(define_subst_attr "mask_operand10" "mask" "" "%{%11%}%N10")
 (define_subst_attr "mask_operand11" "mask" "" "%{%12%}%N11")
 (define_subst_attr "mask_operand18" "mask" "" "%{%19%}%N18")
 (define_subst_attr "mask_operand19" "mask" "" "%{%20%}%N19")
 (define_subst_attr "mask_codefor" "mask" "*" "")
-(define_subst_attr "mask_mode512bit_condition" "mask" "1" "( == 
64)")
+(define_subst_attr "mask_operand_arg34" "mask" "" ", operands[3], operands[4]")
+(define_subst_attr "mask_mode512bit_condition" "mask" "1" "( == 64 
|| TARGET_AVX512VL)")
+(define_subst_attr "mask_avx512vl_condition" "mask" "1" "TARGET_AVX512VL")
 (define_subst_attr "store_mask_constraint" "mask" "vm" "v")
 (define_subst_attr "store_mask_predicate" "mask" "nonimmediate_operand" 
"register_operand")
 (define_subst_attr "mask_prefix" "mask" "vex" "evex")
 (define_subst_attr "mask_prefix2" "mask" "maybe_vex" "evex")
 (define_subst_attr "mask_prefix3" "mask" "orig,vex" "evex")
+(define_subst_attr "mask_expand_op3" "mask" "3" "5")
 
 (define_subst "mask"
   [(set (match_operand:SUBST_V 0)
@@ -85,7 +90,7 @@
 (define_subst_attr "sd_mask_op4" "sd" "" "%{%5%}%N4")
 (define_subst_attr "sd_mask_op5" "sd" "" "%{%6%}%N5")
 (define_subst_attr

Re: Patch for constexpr variable templates

[Andrew Sutton]

>> Oohh... I can commit to trunk?
>
> Yes, you're on the write-after-approval list in MAINTAINERS. :)

True, but it's my first commit to trunk :) Incidentally, that's committed now.

Andrew

Re: [PATCH] Fix PR62077

[Richard Biener]

On Wed, 13 Aug 2014, Richard Biener wrote:

> 
> The following fixes the LTO bootstrap miscompares on the branches.
> They happen because type_hash_canon can end up returning different
> types (a main variant or a variant type) dependent on whether
> we garbage collected before or not.
> 
> The patch makes us never return a variant type from type_hash_canon
> if we fed it a main variant (and vice versa).

Ok, that was the wrong idea - type_hash_canon says:

tree
type_hash_canon (unsigned int hashcode, tree type)
{
  tree t1;

  /* The hash table only contains main variants, so ensure that's what we're
 being passed.  */
  gcc_assert (TYPE_MAIN_VARIANT (type) == type);

ok - but if I place an assert that we only get main variants from it
as well like with

@@ -6759,6 +6759,7 @@ type_hash_canon (unsigned int hashcode,
   t1 = type_hash_lookup (hashcode, type);
   if (t1 != 0)
 {
+  gcc_assert (TYPE_MAIN_VARIANT (t1) == t1);
   if (GATHER_STATISTICS)
{
  tree_code_counts[(int) TREE_CODE (type)]--;

then we ICE very quickly because the C++ frontend happily modifies
array types that are already recorded in the type-hash-canon hashtable.

The following patch tries to avoid that and puts in the above assert.

Sofar the patch survived building stage2 in a LTO bootstrap on the
4.9 branch, full testing is scheduled for trunk.  The patch is
aimed at all active branches (where LTO bootstrap is currently
broken because of it).

Jason, are you happy with that (esp. ripping out the odd
type completion stuff that also messes with types recorded in
said hashtable)?  That code was put in to fix PR57325 (the testcase
doesn't ICE after the patch but is rejected) - I suppose the
fix should have been in the processing_template_decl path only
that doesn't go through the type-hash-canon machinery? 
Otherwise can you please take over?

Thanks,
Richard.

2014-08-13  Richard Biener  

PR middle-end/62077
* tree.c (type_hash_canon): Assert we only get main
variants out of the hash.

cp/
* tree.c (build_cplus_array_type): Properly build
qualified types.

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 213814)
+++ gcc/tree.c  (working copy)
@@ -6759,6 +6759,7 @@ type_hash_canon (unsigned int hashcode,
   t1 = type_hash_lookup (hashcode, type);
   if (t1 != 0)
 {
+  gcc_assert (TYPE_MAIN_VARIANT (t1) == t1);
   if (GATHER_STATISTICS)
{
  tree_code_counts[(int) TREE_CODE (type)]--;
Index: gcc/cp/tree.c
===
--- gcc/cp/tree.c   (revision 213814)
+++ gcc/cp/tree.c   (working copy)
@@ -824,7 +824,11 @@ build_cplus_array_type (tree elt_type, t
build_cplus_array_type
  (TYPE_CANONICAL (elt_type),
   index_type ? TYPE_CANONICAL (index_type) : index_type);
-  t = build_array_type (elt_type, index_type);
+  if (elt_type != TYPE_MAIN_VARIANT (elt_type))
+   t = build_cplus_array_type (TYPE_MAIN_VARIANT (elt_type),
+   index_type);
+  else
+   t = build_array_type (elt_type, index_type);
 }
 
   /* Push these needs up so that initialization takes place
@@ -840,37 +844,17 @@ build_cplus_array_type (tree elt_type, t
  element type as well, so fix it up if needed.  */
   if (elt_type != TYPE_MAIN_VARIANT (elt_type))
 {
-  tree m = build_cplus_array_type (TYPE_MAIN_VARIANT (elt_type),
-  index_type);
-
-  if (TYPE_MAIN_VARIANT (t) != m)
+  tree t1;
+  for (t1 = TYPE_MAIN_VARIANT (t); t1; t1 = TYPE_NEXT_VARIANT (t1))
+   if (TREE_TYPE (t1) == elt_type)
+ {
+   t = t1;
+   break;
+ }
+  if (!t1)
{
- if (COMPLETE_TYPE_P (TREE_TYPE (t)) && !COMPLETE_TYPE_P (m))
-   {
- /* m was built before the element type was complete, so we
-also need to copy the layout info from t.  We might
-end up doing this multiple times if t is an array of
-unknown bound.  */
- tree size = TYPE_SIZE (t);
- tree size_unit = TYPE_SIZE_UNIT (t);
- unsigned int align = TYPE_ALIGN (t);
- unsigned int user_align = TYPE_USER_ALIGN (t);
- enum machine_mode mode = TYPE_MODE (t);
- for (tree var = m; var; var = TYPE_NEXT_VARIANT (var))
-   {
- TYPE_SIZE (var) = size;
- TYPE_SIZE_UNIT (var) = size_unit;
- TYPE_ALIGN (var) = align;
- TYPE_USER_ALIGN (var) = user_align;
- SET_TYPE_MODE (var, mode);
- TYPE_NEEDS_CONSTRUCTING (var) = needs_ctor;
- TYPE_HAS_NONTRIVIAL_DESTRUCTOR (var) = needs_dtor;
-   }
-   }
-
- TYPE_MAIN_VARIANT (t) = m;
- TYPE_NEXT_VARIANT (t) = TYPE

Re: [PATCH libstdc++ v3] - Add xmethods for std::vector and std::unique_ptr

[Jonathan Wakely]

On 13 August 2014 14:55, Siva Chandra wrote:
> Ping. Any update on this?

No, I haven't committed it yet, but I will get round to it.

> On Wed, Aug 6, 2014 at 6:37 AM, Siva Chandra  wrote:
>> On Wed, Aug 6, 2014 at 2:47 AM, Jonathan Wakely  
>> wrote:
>>> Some GNU/Linux distros already build GDB using Python3, so they will
>>> be unable to use these xmethods.
>>>
>>> However, I think it can be committed now and fixed later.
>>
>> For the libstdc++ side, it is a very small fix (using 'print' with
>> function call syntax in one place.) I have attached a new patch which
>> has this fix.
>>
>>> OK for trunk. Do you need me to do the commit for you?
>>
>> Yes, you will need to commit it for me.

Re: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Michael Eager]

On 07/06/14 03:26, Chen Gang wrote:


   * microblaze/mocroblaze.md (call_value_intern): Use 'SI' instead of
   'VOID' for operand 1, just like 'call_internal1' has done.

The related warning:

   ../../gcc/gcc/config/microblaze/microblaze.md:2172: warning: operand 1 
missing mode?


Signed-off-by: Chen Gang 
---
  gcc/config/microblaze/microblaze.md | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/microblaze/microblaze.md 
b/gcc/config/microblaze/microblaze.md
index 2bd5d72..9580221 100644
--- a/gcc/config/microblaze/microblaze.md
+++ b/gcc/config/microblaze/microblaze.md
@@ -2171,7 +2171,7 @@

  (define_insn "call_value_intern"
[(set (match_operand:VOID 0 "register_operand" "=d")
-(call (mem (match_operand:VOID 1 "call_insn_operand" "ri"))
+(call (mem (match_operand:SI 1 "call_insn_operand" "ri"))
(match_operand:SI 2 "" "i")))
 (clobber (match_operand:SI 3 "register_operand" "=d"))]
""


This patch causes a test suite regression:

Executing on host: mb-gcc  -fno-diagnostics-show-caret -fdiagnostics-color=never-O0  -w -c 
-mno-xl-soft-mul -mxl-barrel-shift -mcpu=v6.00.a   -o calls.o 
testsuite/gcc.c-torture/compile/calls.c(timeout = 60)

pid is 24832 -24832
testsuite/gcc.c-torture/compile/calls.c: In function 'f1':
testsuite/gcc.c-torture/compile/calls.c:6:1: error: unrecognizable insn:
(call_insn 5 2 8 2 (parallel [
(set (reg:SI 3 r3)
(call (mem:SI (const_int 0 [0]) [0 MEM[(void * (*) 
(void))0B] S4 A32])
(const_int 24 [0x18])))
(clobber (reg:SI 15 r15))
]) testsuite/gcc.c-torture/compile/calls.c:5 -1
 (nil)
(nil))
testsuite/gcc.c-torture/compile/calls.c:6:1: internal compiler error: in 
extract_insn, at recog.c:2204
0x983018 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
/store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:109
0x983041 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/store/Xilinx/repo/fsf/gcc/gcc/rtl-error.c:117
0x9539cd extract_insn(rtx_def*)
/store/Xilinx/repo/fsf/gcc/gcc/recog.c:2204
0x7a5b59 instantiate_virtual_regs_in_insn
/store/Xilinx/repo/fsf/gcc/gcc/function.c:1561
0x7aaa78 instantiate_virtual_regs
/store/Xilinx/repo/fsf/gcc/gcc/function.c:1932



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

Re: [PATCH 125/236] config/aarch64/aarch64.c: Use rtx_insn

[Richard Earnshaw]

On 06/08/14 18:21, David Malcolm wrote:
> gcc/
>   * config/aarch64/aarch64.c (aarch64_load_symref_appropriately):
>   Strengthen local "insns" from rtx to rtx_insn *.
>   (aarch64_set_frame_expr): Likewise for local "insn".
>   (aarch64_save_or_restore_fprs): Likewise.
>   (aarch64_save_or_restore_callee_save_registers): Likewise.
>   (aarch64_expand_prologue): Likewise.
>   (aarch64_expand_epilogue): Likewise.
>   (aarch64_output_mi_thunk): Likewise.
>   (aarch64_split_compare_and_swap): Strengthen locals "label1" and
>   "label2" from rtx to rtx_code_label *.
>   (aarch64_split_atomic_op): Likewise for local "label".

OK.

R.

Re: [PATCH 128/236] config/arm: Use rtx_insn and rtx_code_label

[Richard Earnshaw]

On 06/08/14 18:21, David Malcolm wrote:
> gcc/
> * config/arm/arm-protos.h (arm_final_prescan_insn): Likewise for 
> param.
> (thumb1_final_prescan_insn): Likewise.
> (thumb2_final_prescan_insn): Likewise.
> 
> * config/arm/arm.c (emit_set_insn): Strengthen return type from
> rtx to rtx_insn *.
> (struct minipool_node): Likewise for field "insn".
> (dump_minipool): Likewise for param "scan".
> (create_fix_barrier): Likewise for local "from".  Strengthen local
> "label" from rtx to rtx_code_label *.
> (push_minipool_barrier): Strengthen param "insn" from rtx to
> rtx_insn *.
> (push_minipool_fix): Likewise.
> (note_invalid_constants): Likewise.
> (thumb2_reorg): Likewise for local "insn".
> (arm_reorg): Likewise.
> (thumb2_final_prescan_insn): Likewise for param
> "insn" and local "first_insn".
> (arm_final_prescan_insn): Likewise for param "insn" and locals
> "start_insn", "this_insn".
> (arm_debugger_arg_offset): Likewise for param "insn".
> (thumb1_emit_multi_reg_push): Likewise for return type and local
> "insn".
> (thumb1_final_prescan_insn): Likewise for param "insn".
> (thumb_far_jump_used_p): Likewise for local "insn".
> (thumb1_expand_prologue): Likewise.
> (arm_expand_epilogue_apcs_frame): Likewise.
> (arm_expand_epilogue): Likewise for locals "insn", "tmp".
> (arm_split_compare_and_swap): Strengthen locals "label1", "label2"
> from rtx to rtx_code_label *.
> (arm_split_atomic_op): Likewise for local "label".
> (arm_emit_coreregs_64bit_shift): Likewise for local "done_label".

OK.

R.

Re: [PATCH, AArch64] Use MOVN to generate 64-bit negative immediates where sensible

[Kyrill Tkachov]

On 07/08/14 20:32, Richard Henderson wrote:

On 08/07/2014 02:57 AM, Kyrill Tkachov wrote:

+  if (one_match > zero_match)
+{
+  /* Set either first three quarters or all but the third.  */
+  mask = 0xll << (16 - first_not__match);
+  emit_insn (gen_rtx_SET (VOIDmode, dest,
+ GEN_INT (val | mask | 0xull)));
+
+  /* Now insert other two quarters. */
+  for (i = first_not__match + 16, mask <<= (first_not__match << 1);
+  i < 64; i += 16, mask <<= 16)
{
  if ((val & mask) != mask)
+   emit_insn (gen_insv_immdi (dest, GEN_INT (i),
+  GEN_INT ((val >> i) & 0x)));
}
+  return;
  }
  
if (zero_match == 2)

You should not place this three instruction sequence before the two instruction
sequences that follow.  I.e. place this just before simple_sequence.

Hi Richard,

Is the attached patch ok? It just moves the section as you suggested. I 
did a build of the Linux kernel with and without this patch to make sure 
no code-gen was accidentally affected.




I do wonder if we should be memo-izing these computations so that we only have
to do the complex search for a sequence only once for each constant...


We'd need to store a mapping from constant to RTXes and everytime we 
have a "cache hit" we'd have to tweak them to make sure the registers 
involved are correct. I had a quick play with this but ended up with LRA 
ICEs  :(

Might look at it later on, but it's not high on my priorities right now.

Thanks,
Kyrill

2014-08-13  Kyrylo Tkachov  

* config/aarch64/aarch64.c (aarch64_expand_mov_immediate): Move
one_match > zero_match case to just before simple_sequence.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 20debb9..a4e7158 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1136,24 +1136,6 @@ aarch64_expand_mov_immediate (rtx dest, rtx imm)
   return;
 }
 
-  if (one_match > zero_match)
-{
-  /* Set either first three quarters or all but the third.	 */
-  mask = 0xll << (16 - first_not__match);
-  emit_insn (gen_rtx_SET (VOIDmode, dest,
-			  GEN_INT (val | mask | 0xull)));
-
-  /* Now insert other two quarters.	 */
-  for (i = first_not__match + 16, mask <<= (first_not__match << 1);
-	   i < 64; i += 16, mask <<= 16)
-	{
-	  if ((val & mask) != mask)
-	emit_insn (gen_insv_immdi (dest, GEN_INT (i),
-   GEN_INT ((val >> i) & 0x)));
-	}
-  return;
-}
-
   if (zero_match == 2)
 goto simple_sequence;
 
@@ -1270,6 +1252,24 @@ aarch64_expand_mov_immediate (rtx dest, rtx imm)
 	}
 }
 
+  if (one_match > zero_match)
+{
+  /* Set either first three quarters or all but the third.	 */
+  mask = 0xll << (16 - first_not__match);
+  emit_insn (gen_rtx_SET (VOIDmode, dest,
+			  GEN_INT (val | mask | 0xull)));
+
+  /* Now insert other two quarters.	 */
+  for (i = first_not__match + 16, mask <<= (first_not__match << 1);
+	   i < 64; i += 16, mask <<= 16)
+	{
+	  if ((val & mask) != mask)
+	emit_insn (gen_insv_immdi (dest, GEN_INT (i),
+   GEN_INT ((val >> i) & 0x)));
+	}
+  return;
+}
+
  simple_sequence:
   first = true;
   mask = 0x;

Re: [PATCH] gcc/config/microblaze/microblaze.md: Remove redundant '@' to avoid compiling warning

[Michael Eager]

On 07/05/14 20:59, Chen Gang wrote:


   * microblaze/microblaze.md: Remove redundant '@' to avoid compiling
   warning.

The related warning:

   ../../gcc/gcc/config/microblaze/microblaze.md:516: '@' is redundant for 
output template with single alternative


Signed-off-by: Chen Gang 
---
  gcc/config/microblaze/microblaze.md | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/config/microblaze/microblaze.md 
b/gcc/config/microblaze/microblaze.md
index 7945d96..2bd5d72 100644
--- a/gcc/config/microblaze/microblaze.md
+++ b/gcc/config/microblaze/microblaze.md
@@ -518,8 +518,7 @@
(minus:DI (match_operand:DI 1 "register_operand" "d")
  (match_operand:DI 2 "arith_operand32" "d")))]
""
-  "@
-   rsub\t%L0,%L2,%L1\;rsubc\t%M0,%M2,%M1"
+  "rsub\t%L0,%L2,%L1\;rsubc\t%M0,%M2,%M1"
[(set_attr "type" "darith")
(set_attr "mode"  "DI")
(set_attr "length""8")])



Committed revision 213913.


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

[COMMITTED PATCH] Demangler fuzzer

[Gary Benson]

Ian Lance Taylor wrote:
> On Tue, Aug 12, 2014 at 10:11 AM, Gary Benson  wrote:
> > Ian Lance Taylor wrote:
> > > I think that by default the program should stop.  That will make
> > > it possible to eventually run as part of "make check".  Give it
> > > some number of iterations that stops it in a second or so.  You
> > > can still have it run forever by using -m -1.
> >
> > On my machine it usually fails in 3-5 seconds, so a 1 second run
> > seems a little too short.  How does 10 seconds sound?
> 
> OK, we can start with that, I suppose.

I have committed the patch inlined below.  By default it tries
7.5 million symbols, which takes roughly 10 seconds on my box.
A good seed for testing is 1407772345 which manages 30,123,441
symbols before crashing (about 45 seconds).

Cheers,
Gary

--
2014-08-13  Gary Benson  

* testsuite/demangler-fuzzer.c: New file.
* testsuite/Makefile.in (fuzz-demangler): New rule.
(demangler-fuzzer): Likewise.
(mostlyclean): Clean up demangler fuzzer.

Index: libiberty/testsuite/Makefile.in
===
--- libiberty/testsuite/Makefile.in (revision 213911)
+++ libiberty/testsuite/Makefile.in (revision 213912)
@@ -59,6 +59,10 @@
 check-expandargv: test-expandargv
./test-expandargv
 
+# Run the demangler fuzzer
+fuzz-demangler: demangler-fuzzer
+   ./demangler-fuzzer
+
 TEST_COMPILE = $(CC) @DEFS@ $(LIBCFLAGS) -I.. -I$(INCDIR) $(HDEFINES)
 test-demangle: $(srcdir)/test-demangle.c ../libiberty.a
$(TEST_COMPILE) -o test-demangle \
@@ -72,6 +76,10 @@
$(TEST_COMPILE) -DHAVE_CONFIG_H -I.. -o test-expandargv \
$(srcdir)/test-expandargv.c ../libiberty.a
 
+demangler-fuzzer: $(srcdir)/demangler-fuzzer.c ../libiberty.a
+   $(TEST_COMPILE) -o demangler-fuzzer \
+   $(srcdir)/demangler-fuzzer.c ../libiberty.a
+
 # Standard (either GNU or Cygnus) rules we don't use.
 html install-html info install-info clean-info dvi pdf install-pdf \
 install etags tags installcheck:
@@ -81,6 +89,7 @@
rm -f test-demangle
rm -f test-pexecute
rm -f test-expandargv
+   rm -f demangler-fuzzer
rm -f core
 clean: mostlyclean
 distclean: clean
Index: libiberty/testsuite/demangler-fuzzer.c
===
--- libiberty/testsuite/demangler-fuzzer.c  (revision 0)
+++ libiberty/testsuite/demangler-fuzzer.c  (revision 213912)
@@ -0,0 +1,108 @@
+/* Demangler fuzzer.
+
+   Copyright (C) 2014 Free Software Foundation, Inc.
+
+   This file is part of GNU libiberty.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see .  */
+
+#include 
+#include 
+#include 
+#include 
+#include "demangle.h"
+
+#define MAXLEN 253
+#define ALPMIN 33
+#define ALPMAX 127
+
+static char *program_name;
+
+#define DEFAULT_MAXCOUNT 750
+
+static void
+print_usage (FILE *fp, int exit_value)
+{
+  fprintf (fp, "Usage: %s [OPTION]...\n", program_name);
+  fprintf (fp, "Options:\n");
+  fprintf (fp, "  -h   Display this message.\n");
+  fprintf (fp, "  -s SEED  Select the random seed to be used.\n");
+  fprintf (fp, "   The default is to base one on the");
+  fprintf (fp, " current time.\n");
+  fprintf (fp, "  -m MAXCOUNT  Exit after MAXCOUNT symbols.\n");
+  fprintf (fp, "   The default is %d.", DEFAULT_MAXCOUNT);
+  fprintf (fp, " Set to `-1' for no limit.\n");
+
+  exit (exit_value);
+}
+
+int
+main (int argc, char *argv[])
+{
+  char symbol[2 + MAXLEN + 1] = "_Z";
+  int seed = -1, seed_set = 0;
+  int count = 0, maxcount = DEFAULT_MAXCOUNT;
+  int optchr;
+
+  program_name = argv[0];
+
+  do
+{
+  optchr = getopt (argc, argv, "hs:m:t:");
+  switch (optchr)
+   {
+   case '?':  /* Unrecognized option.  */
+ print_usage (stderr, 1);
+ break;
+
+   case 'h':
+ print_usage (stdout, 0);
+ break;
+
+   case 's':
+ seed = atoi (optarg);
+ seed_set = 1;
+ break;
+
+   case 'm':
+ maxcount = atoi (optarg);
+ break;
+   }
+}
+  while (optchr != -1);
+
+  if (!seed_set)
+seed = time (NULL);
+  srand (seed);
+  printf ("%s: seed = %d\n", program_name, seed);
+
+  while (maxcount < 0 || count < maxcount)
+{
+  char *buffer = symbol + 2;
+  int length, i;
+
+

Re: [PATCH AArch64 1/3] Don't disparage add/sub in SIMD registers

[Vladimir Makarov]

On 2014-08-13, 4:36 AM, James Greenhalgh wrote:

On Tue, Aug 12, 2014 at 04:53:38PM +0100, pins...@gmail.com wrote:




On Aug 12, 2014, at 7:40 AM, Alan Lawrence  wrote:

(It is no more expensive.)


Yes on some processors it could be.


Haven't we been here before [1]?

This disparaging mechanism is still not going to give what we are trying to
achieve (assigning cost at the -mcpu/-mtune level, rather than the
target level).

Recall that '!' gives a static cost of 600 [2] and that this cost is
only applied to the alternative if any operand in that alternative needs
reloading - otherwise, LRA sees a set of matching operands and does not
bother checking costs [3]. IRA, as far as I can see, does not care about
'!', but unconditionally adds 2 to the cost of an alternative for '?' [4].



Yes, correct.  IRA follows the old global RA and the documentation.


Even if LRA did try to do a more complete job of always picking the
alternative with lowest cost (rather than the current first-matching
behaviour) "600" would be far too high a cost for the operation.

If IRA took '!' into account, we would be as well to remove the alternative
entirely.



Yes, that is right.


So, I still can't agree that we want these exclamation marks - and we are
now in a halfway state where some instructions have them and some don't.
We have to pick a consistent policy or we are going to see some very poor
code generation.

In an ideal world, we would have a sensible way of describing a
(per-core granularity) alternative cost, which would be considered by
the register allocators. I've played about with doing this using attributes,
but it ends up as a messy patch and I can't bring myself to add yet another
cost framework to the back end.

Do you have any ideas as to how we can make some progress? Maybe Vladimir
has some suggestions?



Yes, I have some thoughts.  We could provide machine-dependent hooks to 
treat different costs for '!' (which will work only for LRA/reload), and 
'?', and even '*' (to ignore or not the next register constraint for 
register preference).  The hook could get insn for which we calculate 
the costs and of course to have the current default values) for 
compatibility.


It could provide a lot of flexibility for machine-description writers.

Although it would create some conflicts with insn cost attribute 
calculation by alternatives and would create more complication for less 
experienced md writer.   So we need some more consistent solution.  It 
is all about code selection which currently is done in many places 
(combiner, register preferences and finally in reload/LRA).  A lot of 
thinking should be done how to better approach to the solution.


The right approach would be reconsider all the pipeline and probably 
rewriting combiner/register preferencing (which is moved from the old 
regclass.c practically without changes and ignore the fact that the 
alternative should be the same for different operands) / partially LRA. 
 So it is complex task and a big project.  But I am going to work in 
this direction when I start to be less busy.  I am only afraid that the 
quick solutions as mentioned by me above could create a lot of 
complications for the long-term project.



Thanks,
James

[1] https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01627.html
[2] regoc.c::preprocess_constraints
[3] I may have misread this, but that seems to be what the final condition
 of the main loop of lra-constraints::process_alt_operands implies.
[4] ira-costs.c::record_reg_classes

Re: [gomp4] Add tables generation

[Ilya Verbin]

Hi,

Here is the updated patch.  offload_funcs/vars are now declared in omp-low.h,
the functions have a comment.  Also it fixes the issue of offload_funcs/vars
corruption by the garbage collector.  OK for gomp-4_0-branch?

  -- Ilya

---
 gcc/Makefile.in|1 +
 gcc/gengtype.c |2 +-
 gcc/lto-cgraph.c   |  110 
 gcc/lto-section-in.c   |3 +-
 gcc/lto-streamer-out.c |2 +
 gcc/lto-streamer.h |3 +
 gcc/lto/lto.c  |2 +
 gcc/omp-low.c  |   68 ++
 gcc/omp-low.h  |3 +
 9 files changed, 137 insertions(+), 57 deletions(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index bfa5f32..372f586 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2290,6 +2290,7 @@ GTFILES = $(CPP_ID_DATA_H) $(srcdir)/input.h 
$(srcdir)/coretypes.h \
   $(srcdir)/tree-profile.c $(srcdir)/tree-nested.c \
   $(srcdir)/tree-parloops.c \
   $(srcdir)/omp-low.c \
+  $(srcdir)/omp-low.h \
   $(srcdir)/targhooks.c $(out_file) $(srcdir)/passes.c $(srcdir)/cgraphunit.c \
   $(srcdir)/cgraphclones.c \
   $(srcdir)/tree-phinodes.c \
diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index ffe3f94..5bcbbe2 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -1800,7 +1800,7 @@ open_base_files (void)
   "tree-ssa.h", "reload.h", "cpp-id-data.h", "tree-chrec.h",
   "except.h", "output.h",  "cfgloop.h",
   "target.h", "ipa-prop.h", "lto-streamer.h", "target-globals.h",
-  "ipa-inline.h", "dwarf2out.h", NULL
+  "ipa-inline.h", "dwarf2out.h", "omp-low.h", NULL
 };
 const char *const *ifp;
 outf_p gtype_desc_c;
diff --git a/gcc/lto-cgraph.c b/gcc/lto-cgraph.c
index bc05400..64ad599 100644
--- a/gcc/lto-cgraph.c
+++ b/gcc/lto-cgraph.c
@@ -52,6 +52,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "context.h"
 #include "pass_manager.h"
 #include "ipa-utils.h"
+#include "omp-low.h"
 
 /* True when asm nodes has been output.  */
 bool asm_nodes_output = false;
@@ -1044,6 +1045,66 @@ read_string (struct lto_input_block *ib)
   return str;
 }
 
+/* Output function/variable tables that will allow libgomp to look up offload
+   target code.  OFFLOAD_FUNCS is filled in expand_omp_target, OFFLOAD_VARS is
+   filled here just before streaming.  In WHOPR (partitioned) mode during the
+   WPA stage both OFFLOAD_FUNCS and OFFLOAD_VARS are filled by
+   input_offload_tables.  */
+
+void
+output_offload_tables (void)
+{
+  /* Collect all omp-target global variables to offload_vars, if they have not
+ been gathered earlier by input_offload_tables on the WPA stage.  */
+  if (!flag_wpa && vec_safe_is_empty (offload_vars))
+{
+  struct varpool_node *vnode;
+  FOR_EACH_DEFINED_VARIABLE (vnode)
+   {
+ if (!lookup_attribute ("omp declare target",
+DECL_ATTRIBUTES (vnode->decl))
+ || TREE_CODE (vnode->decl) != VAR_DECL
+ || DECL_SIZE (vnode->decl) == 0)
+   continue;
+ vec_safe_push (offload_vars, vnode->decl);
+   }
+}
+
+  if (vec_safe_is_empty (offload_funcs) && vec_safe_is_empty (offload_vars))
+return;
+
+  struct lto_simple_output_block *ob
+= lto_create_simple_output_block (LTO_section_offload_table);
+
+  for (unsigned i = 0; i < vec_safe_length (offload_funcs); i++)
+{
+  streamer_write_enum (ob->main_stream, LTO_symtab_tags,
+  LTO_symtab_last_tag, LTO_symtab_unavail_node);
+  lto_output_fn_decl_index (ob->decl_state, ob->main_stream,
+   (*offload_funcs)[i]);
+}
+
+  for (unsigned i = 0; i < vec_safe_length (offload_vars); i++)
+{
+  streamer_write_enum (ob->main_stream, LTO_symtab_tags,
+  LTO_symtab_last_tag, LTO_symtab_variable);
+  lto_output_var_decl_index (ob->decl_state, ob->main_stream,
+(*offload_vars)[i]);
+}
+
+  streamer_write_uhwi_stream (ob->main_stream, 0);
+  lto_destroy_simple_output_block (ob);
+
+  /* In WHOPR mode during the WPA stage the joint offload tables need to be
+ streamed to one partition only.  That's why we free offload_funcs and
+ offload_vars after the first call of output_offload_tables.  */
+  if (flag_wpa)
+{
+  vec_free (offload_funcs);
+  vec_free (offload_vars);
+}
+}
+
 /* Overwrite the information in NODE based on FILE_DATA, TAG, FLAGS,
STACK_SIZE, SELF_TIME and SELF_SIZE.  This is called either to initialize
NODE or to replace the values in it, for instance because the first
@@ -1739,6 +1800,55 @@ input_symtab (void)
 }
 }
 
+/* Input function/variable tables that will allow libgomp to look up offload
+   target code, and store them into OFFLOAD_FUNCS and OFFLOAD_VARS.  */
+
+void
+input_offload_tables (void)
+{
+  struct lto_file_decl_data **file_data_vec = lto_get_file_decl_data ();
+  struct lto_file_decl_data *file_data;
+  unsigned int j = 0;
+

Re: [PATCH 140/236] config/microblaze/microblaze.c: Use rtx_insn and rtx_code_label

[Michael Eager]

On 08/06/14 10:21, David Malcolm wrote:

gcc/
* config/microblaze/microblaze.c (microblaze_call_tls_get_addr):
Strengthen return type and local "insns" from rtx to rtx_insn *.
(microblaze_legitimize_tls_address): Likewise for local "insns".
(microblaze_block_move_loop): Strengthen local "label" from rtx
to rtx_code_label *.
(microblaze_expand_prologue): Strengthen two locals named "insn"
from rtx to rtx_insn *.
(microblaze_asm_output_mi_thunk): Likewise for local "insn".
(microblaze_expand_divide): Likewise for locals "jump", "cjump",
"insn".  Strengthen locals "div_label", "div_end_label" from rtx
to rtx_code_label *.



OK


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

Re: [C++ Patch] Remove "invalid type in declaration" parser error

[Jason Merrill]

OK.

Jason

Re: [PATCH 029/236] rtl_data.x_parm_birth_insn is an insn

[David Malcolm]

On Wed, 2014-08-13 at 07:44 -0600, Jeff Law wrote:
> On 08/06/14 11:20, David Malcolm wrote:
> > gcc/
> > * function.h (struct rtl_data): Strengthen field
> > "x_parm_birth_insn" from rtx to rtx_insn *.
> > * function.c (struct assign_parm_data_all): Strengthen fields
> > "first_conversion_insn" and "last_conversion_insn" from rtx to
> > rtx_insn *.
> OK.  I think at this point any patch which merely changes the type of 
> some variable or in a signature from rtx to rtx_insn (or any of the 
> concrete passes) is considered trivial enough to go forward without 
   ^^
Presumably you meant "subclasses" here, right?

> explicit review.
> 
> That applies to patches in this series, additions you may need to make 
> due to changes in the tree since you last rebased and further 
> strengthening you or anyone else may want to tackle.

Heh - indeed, patch #30 needs a trivial fixup of the return type of the
helper function
  emit_note_eh_region_end
that was added in r212171, from rtx to rtx_note *.

[yes, I'm working on rebasing it all against today's trunk right now]

Thanks
Dave

Re: [PATCH 029/236] rtl_data.x_parm_birth_insn is an insn

[Jeff Law]

On 08/13/14 11:08, David Malcolm wrote:

On Wed, 2014-08-13 at 07:44 -0600, Jeff Law wrote:

On 08/06/14 11:20, David Malcolm wrote:

gcc/
* function.h (struct rtl_data): Strengthen field
"x_parm_birth_insn" from rtx to rtx_insn *.
* function.c (struct assign_parm_data_all): Strengthen fields
"first_conversion_insn" and "last_conversion_insn" from rtx to
rtx_insn *.

OK.  I think at this point any patch which merely changes the type of
some variable or in a signature from rtx to rtx_insn (or any of the
concrete passes) is considered trivial enough to go forward without

^^
Presumably you meant "subclasses" here, right?

yes.




explicit review.

That applies to patches in this series, additions you may need to make
due to changes in the tree since you last rebased and further
strengthening you or anyone else may want to tackle.


Heh - indeed, patch #30 needs a trivial fixup of the return type of the
helper function
   emit_note_eh_region_end
that was added in r212171, from rtx to rtx_note *.

[yes, I'm working on rebasing it all against today's trunk right now]

:-)
Jeff

Re: [PATCH i386 AVX512] [8/n] Extend substs for new patterns.

[Uros Bizjak]

On Wed, Aug 13, 2014 at 4:23 PM, Kirill Yukhin  wrote:

>> >> In a couple of places,  checks are changed to GET_MODE_SIZE
>> >> (GET_MODE (operands[0])) and in a similar way, mode checks were
>> >> changed to GET_MODE (operands[0]). The previous checks are more
>> >> efficient and are preferred. Is there a reason you need to check
>> >> operands[0] dynamically?
>> >
>> > I agree, runtime tests are worse. But this subst attributes are used
>> > in patterns which actually do not contain mode iterators at all.
>>
>> IMO, two different subst patterns should be used in this case, one for
>> patterns with and one for patterns w/o mode iterators.
>
> That was my second thought after I hit `send'.
>
> Updated patch in the bottom
>
> Bootstrapped.
>
> (Regtest w/ new tests is in progress).
>
> Is it ok if pass?
>
> gcc/
> * config/i386/sse.md: Allow V64QI, V32QI, V32HI, V4HI modes.
> * config/i386/subst.md
> (define_mode_iterator SUBST_V): Update.
> (define_mode_iterator SUBST_A): Ditto.
> (define_subst_attr "mask_operand7"): New.
> (define_subst_attr "mask_operand10"): New.
> (define_subst_attr "mask_operand_arg34") : New.
> (define_subst_attr "mask_expand_op3"): New.
> (define_subst_attr "mask_mode512bit_condition"): Handle 
> TARGET_AVX512VL.
> (define_subst_attr "sd_mask_mode512bit_condition"): Ditto.
> (define_subst_attr "mask_avx512vl_condition"): New.
> (define_subst_attr "round_mask_operand4"): Ditto.
> (define_subst_attr "round_mask_scalar_op3"): Delete.
> (define_subst_attr "round_mask_op4"): New.
> (define_subst_attr "round_mode512bit_condition"): Allow V8DImode,
> V16SImode.
> (define_subst_attr "round_modev8sf_condition"): New.
> (define_subst_attr "round_modev4sf_condition"): GET_MODE instead of
> mode.
> (define_subst_attr "round_saeonly_mask_operand4"): New.
> (define_subst_attr "round_saeonly_mask_op4"): New.
> (define_subst_attr "round_saeonly_mode512bit_condition"): Allow
> V8DImode, V16SImode.
> (define_subst_attr "round_saeonly_modev8sf_condition"): New.
> (define_subst_attr "mask_expand4_name" "mask_expand4"): New.
> (define_subst_attr "mask_expand4_args"): New.
> (define_subst "mask_expand4"): New.

This is OK.

Thanks,
Uros.

Re: [PATCH] Fix PR62077

[Jason Merrill]

On 08/13/2014 10:28 AM, Richard Biener wrote:

Sofar the patch survived building stage2 in a LTO bootstrap on the
4.9 branch, full testing is scheduled for trunk.


The patch breaks a lot of C++ testcases, such as
g++.old-deja/g++.other/cvt1.C; I think you need to share the "set the 
canonical type" code with the template path.



Jason, are you happy with that (esp. ripping out the odd
type completion stuff that also messes with types recorded in
said hashtable)?


I'm nervous about it, since it leads to ARRAY_TYPEs with different 
TYPE_ALIGN than their elements, though I'm not sure this actually breaks 
anything.  Perhaps we could copy TYPE_ALIGN and TYPE_USER_ALIGN at the 
same place we copy TYPE_NEEDS_CONSTRUCTING.


Jason

Re: [PATCH 032/236] emit_* functions return rtx_insn

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

More scaffolding: strengthen the return types from the various emit_
functions from rtx to rtx_insn * (or to the rtx_barrier * subclass in a
few cases).

These will ultimately have their params strengthened also, but we
postpone that until much later in the patch series.  So for now there
are also various checked casts to ensure we really got an insn when
returning such params back.

Doing so requires a minor tweak to config/sh/sh.c

gcc/
* emit-rtl.h (emit_copy_of_insn_after): Strengthen return type
from rtx to rtx_insn *.

* rtl.h (emit_insn_before): Likewise.
(emit_insn_before_noloc): Likewise.
(emit_insn_before_setloc): Likewise.
(emit_jump_insn_before): Likewise.
(emit_jump_insn_before_noloc): Likewise.
(emit_jump_insn_before_setloc): Likewise.
(emit_call_insn_before): Likewise.
(emit_call_insn_before_noloc): Likewise.
(emit_call_insn_before_setloc): Likewise.
(emit_debug_insn_before): Likewise.
(emit_debug_insn_before_noloc): Likewise.
(emit_debug_insn_before_setloc): Likewise.
(emit_label_before): Likewise.
(emit_insn_after): Likewise.
(emit_insn_after_noloc): Likewise.
(emit_insn_after_setloc): Likewise.
(emit_jump_insn_after): Likewise.
(emit_jump_insn_after_noloc): Likewise.
(emit_jump_insn_after_setloc): Likewise.
(emit_call_insn_after): Likewise.
(emit_call_insn_after_noloc): Likewise.
(emit_call_insn_after_setloc): Likewise.
(emit_debug_insn_after): Likewise.
(emit_debug_insn_after_noloc): Likewise.
(emit_debug_insn_after_setloc): Likewise.
(emit_label_after): Likewise.
(emit_insn): Likewise.
(emit_debug_insn): Likewise.
(emit_jump_insn): Likewise.
(emit_call_insn): Likewise.
(emit_label): Likewise.
(gen_clobber): Likewise.
(emit_clobber): Likewise.
(gen_use): Likewise.
(emit_use): Likewise.
(emit): Likewise.

(emit_barrier_before): Strengthen return type from rtx to
rtx_barrier *.
(emit_barrier_after): Likewise.
(emit_barrier): Likewise.

* emit-rtl.c (emit_pattern_before_noloc):  Strengthen return type
from rtx to rtx_insn *.  Add checked casts for now when converting
"last" from rtx to rtx_insn *.
(emit_insn_before_noloc): Likewise for return type.
(emit_jump_insn_before_noloc): Likewise.
(emit_call_insn_before_noloc): Likewise.
(emit_debug_insn_before_noloc): Likewise.
(emit_barrier_before): Strengthen return type and local "insn"
from rtx to rtx_barrier *.
(emit_label_before): Strengthen return type from rtx to
rtx_insn *.  Add checked cast for now when returning param
(emit_pattern_after_noloc): Strengthen return type from rtx to
rtx_insn *.  Add checked casts for now when converting "last" from
rtx to rtx_insn *.
(emit_insn_after_noloc): Strengthen return type from rtx to
rtx_insn *.
(emit_jump_insn_after_noloc): Likewise.
(emit_call_insn_after_noloc): Likewise.
(emit_debug_insn_after_noloc): Likewise.
(emit_barrier_after): Strengthen return type from rtx to
rtx_barrier *.
(emit_label_after): Strengthen return type from rtx to rtx_insn *.
Add checked cast for now when converting "label" from rtx to
rtx_insn *.
(emit_pattern_after_setloc): Strengthen return type from rtx to
rtx_insn *.  Add checked casts for now when converting "last" from
rtx to rtx_insn *.
(emit_pattern_after): Strengthen return type from rtx to
rtx_insn *.
(emit_insn_after_setloc): Likewise.
(emit_insn_after): Likewise.
(emit_jump_insn_after_setloc): Likewise.
(emit_jump_insn_after): Likewise.
(emit_call_insn_after_setloc): Likewise.
(emit_call_insn_after): Likewise.
(emit_debug_insn_after_setloc): Likewise.
(emit_debug_insn_after): Likewise.
(emit_pattern_before_setloc): Likewise.  Add checked casts for now
when converting "last" from rtx to rtx_insn *.
(emit_pattern_before): Strengthen return type from rtx to
rtx_insn *.
(emit_insn_before_setloc): Likewise.
(emit_insn_before): Likewise.
(emit_jump_insn_before_setloc): Likewise.
(emit_jump_insn_before): Likewise.
(emit_call_insn_before_setloc): Likewise.
(emit_call_insn_before): Likewise.
(emit_debug_insn_before_setloc): Likewise.
(emit_debug_insn_before): Likewise.
(emit_insn): Strengthen return type and locals "last", "insn",
"next" from rtx to rtx_insn *.  Add checked cast to rtx_insn
within cases where we know we have an insn.
(emit_debug_insn): Likewise.
(emit_jump_in

Re: [PATCH 033/236] emit_move et al return rtx_insn *

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

gcc/
* expr.h (emit_move_insn): Strengthen return type from rtx to
rtx_insn *.
(emit_move_insn_1): Likewise.
(emit_move_complex_push): Likewise.
(emit_move_complex_parts): Likewise.

* expr.c (emit_move_via_integer): Strengthen return type from rtx
to rtx_insn *.  Replace use of NULL_RTX with NULL when working
with insns.
(emit_move_complex_push): Strengthen return type from rtx to
rtx_insn *.
(emit_move_complex): Likewise, also for local "ret".
(emit_move_ccmode): Likewise.
(emit_move_multi_word): Likewise for return type and locals
"last_insn", "seq".
(emit_move_insn_1): Likewise for return type and locals "result",
"ret".
(emit_move_insn): Likewise for return type and local "last_insn".
(compress_float_constant): Likewise.

OK.
jeff

Re: [PATCH 034/236] next_cc0_user and prev_cc0_setter scaffolding

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

gcc/
* rtl.h (next_cc0_user): Strengthen return type from rtx to
rtx_insn *.
(prev_cc0_setter): Likewise.

* emit-rtl.c (next_cc0_user): Strengthen return type from rtx to
rtx_insn *, adding checked casts for now as necessary.
(prev_cc0_setter): Likewise.

OK.
jeff

Re: [PATCH 035/236] Return types of unlink_insn_chain and duplicate_insn_chain

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

gcc/
* rtl.h (unlink_insn_chain): Strengthen return type from rtx to
rtx_insn *.
(duplicate_insn_chain): Likewise.
* cfgrtl.c (unlink_insn_chain): Strengthen return type from rtx to
rtx_insn *, also for locals "prevfirst" and "nextlast".  Add a
checked cast for now (until we can strengthen the params in the
same way).
(duplicate_insn_chain): Likewise.

OK.
jeff

Re: [PATCH 036/236] get_last_bb_insn returns an rtx_insn

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

gcc/
* basic-block.h (get_last_bb_insn): Strengthen return type from
rtx to rtx_insn *.
* cfgrtl.c (get_last_bb_insn): Likewise, and for locals "tmp" and
end".

OK.
jeff

Re: [PATCH 037/236] sel_bb_{head|end} return rtx_insn

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

gcc/
* sel-sched-ir.h (exit_insn): Strengthen from rtx to rtx_insn *.
(sel_bb_head): Strengthen return type insn_t (currently just an
rtx) to rtx_insn *.
(sel_bb_end): Likewise.

* sel-sched-ir.c (exit_insn): Strengthen from rtx to rtx_insn *.
(sel_bb_head): Strengthen return type and local "head" from
insn_t (currently just an rtx) to rtx_insn *.
(sel_bb_end): Likewise for return type.
(free_nop_and_exit_insns): Replace use of NULL_RTX with NULL when
working with insn.

OK.
Jeff

Re: [PATCH] Add Berkeley qsort to libiberty to make GCC host-independent

[Mike Stump]

On Aug 13, 2014, at 5:12 AM, Felix Yang  wrote:
>The qsort library function may have different behavior on
> different hosts (say Linux vs MinGW).

> OK for trunk?

I just have one question.  Why if we want to use a stable sort, and we program 
in C++, would we not want to just use C++:

  http://www.cplusplus.com/reference/algorithm/stable_sort/

I’m hoping that performance doesn’t fall off the cliff with it...

Re: [PATCH 038/236] find_first_parameter_load returns an rtx_insn

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

gcc/
* rtl.h (find_first_parameter_load): Strengthen return type from
rtx to rtx_insn *.
* rtlanal.c (find_first_parameter_load): Strengthen return type
from rtx to rtx_insn *.  Add checked cast for now, to postpone
strengthening the params.

OK.
jeff

Re: [PATCH 039/236] create_insn_rtx_from_pattern and create_copy_of_insn_rtx return rtx_insn

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

gcc/
* sel-sched-ir.h (create_insn_rtx_from_pattern): Strengthen return
type from rtx to rtx_insn *.
* sel-sched-ir.h (create_copy_of_insn_rtx): Likewise.
* sel-sched-ir.c (create_insn_rtx_from_pattern): Likewise.
* sel-sched-ir.c (create_copy_of_insn_rtx): Likewise, also for
local "res".

OK.
jeff

Fwd: [PATCH] Add Berkeley qsort to libiberty to make GCC host-independent

[Mike Stump]

[ dup sorry ]

On Aug 13, 2014, at 5:12 AM, Felix Yang  wrote:
>   The qsort library function may have different behavior on
> different hosts (say Linux vs MinGW).

> OK for trunk?

I just have one question.  Why if we want to use a stable sort, and we program 
in C++, would we not want to just use C++:

 http://www.cplusplus.com/reference/algorithm/stable_sort/

I’m hoping that performance doesn’t fall off the cliff with it...

Re: [PATCH 040/236] Use rtx_insn internally within generated functions

[Jeff Law]

On 08/06/14 11:20, David Malcolm wrote:

With this patch, "insn" and "curr_insn" as used from C++ fragments in .md
files are strengthened from rtx to rtx_insn *, allowing numerous
target-specific functions to have their params be similiar strengthened.

The top-level interfaces ("recog", "split", "peephole2") continue to take
a plain rtx for "insn", to avoid introducing dependencies on other
patches.

gcc/
* recog.h (insn_output_fn): Update this function typedef to match
the changes below to the generated output functions, strengthening
the 2nd param from rtx to rtx_insn *.

* final.c (get_insn_template): Add a checked cast to rtx_insn * on
insn when invoking an output function, to match the new signature
of insn_output_fn with a stronger second param.

* genconditions.c (write_header): In the generated code for
gencondmd.c, strengthen the global "insn" from rtx to rtx_insn *
to match the other changes in this patch.

* genemit.c (gen_split): Strengthen the 1st param "curr_insn" of
the generated "gen_" functions from rtx to rtx_insn * within their
implementations.

* genrecog.c (write_subroutine): Strengthen the 2nd param "insn" of
the subfunctions within the generated "recog_", "split", "peephole2"
function trees from rtx to rtx_insn *.  For now, the top-level
generated functions ("recog", "split", "peephole2") continue to
take a plain rtx for "insn", to avoid introducing dependencies on
other patches.  Rename this 2nd param from "insn" to
"uncast_insn", and reintroduce "insn" as a local variable of type
rtx_insn *, initialized at the top of the generated function with
a checked cast on "uncast_insn".
(make_insn_sequence): Strengthen the 1st param "curr_insn" of
the generated "gen_" functions from rtx to rtx_insn * within their
prototypes.

* genoutput.c (process_template): Strengthen the 2nd param within
the generated "output_" functions "insn" from rtx to rtx_insn *.

OK.
Jeff