[PATCH][match-and-simplify] Fix last commit

[Richard Biener]

Committed.

Richard.

2014-09-10  Richard Biener  

* match-conversions.pd: Fix unsigned type used for
shortened multiplication.

Index: gcc/match-conversions.pd
===
--- gcc/match-conversions.pd(revision 215057)
+++ gcc/match-conversions.pd(working copy)
@@ -59,10 +59,9 @@
   && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@0)))
   (if (TYPE_OVERFLOW_WRAPS (type))
(mult (convert @0) (convert @1)))
-  (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
+  (with { tree utype = unsigned_type_for (type); }
(convert (mult (convert:utype @0) (convert:utype @1))
 
-
 /* For integral conversions with the same precision or pointer
conversions use a NOP_EXPR instead.  */
 (simplify

RE: [Patch ARM v2] Fix PR target/56846

[Tony Wang]

> -Original Message-
> From: Jonathan Wakely [mailto:jwak...@redhat.com]
> Sent: Tuesday, September 09, 2014 6:40 PM
> To: Tony Wang
> Cc: Ramana Radhakrishnan; gcc-patches; libstd...@gcc.gnu.org
> Subject: Re: [Patch ARM v2] Fix PR target/56846
> 
> On 09/09/14 17:47 +0800, Tony Wang wrote:
> >Hi there,
> >
> >This is a updated patch to fix pr56846. Bootstrapped on 
> >x86_64-unknown-linux-gnu and no regression for
> >regression test on Linux and a cross regression test on arm-none-eabi.
> >
> >OK for the trunk?
> >
> >gcc/libstdc++-v3/ChangeLog:
> >2014-09-09   Tony Wang 
> >
> > PR target/56846
> > * libsupc++/eh_personality.cc(PERSONALITY_FUNCTION):
>^
> There should be a space after the file name (look at existing
> changelog entries)
> 
> OK with that change.

Committed with your comment on trunk, and also tested on 4.9 branch with no 
regression. So is it ok to back
port to 4.9 branch?

BR,
Tony

Re: [PATCH] -fsanitize=nonnull-attribute and -fsanitize=returns-nonnull-attribute support

[Richard Biener]

On Tue, 9 Sep 2014, Jakub Jelinek wrote:

> Hi!
> 
> On Fri, Jun 27, 2014 at 09:13:07AM +0200, Jakub Jelinek wrote:
> > The patch adds two new (trivial handlers) to libubsan, as it is maintained
> > in llvm's compiler-rt, will talk to them if they are interested in those
> > and what exact wording and form (AFAIK clang also added the gcc
> > {,returns_}nonnull attributes).  If they wouldn't be interested, guess
> > we could add them in a separate, gcc owned, source file in ubsan (like we
> > own Makefile*).
> 
> Now that the compiler-rt bits landed up upstream, here is an updated
> version of the patch.
> 
> First here is mostly ubsan infrastructure change so that ubsan_create_data
> can handle more cases, together with an improvement not to emit UBSAN_BOUNDS
> when it already during gimplification provably can't overflow.
> What the ubsan_create_data changes allow is more than one locus at the
> beginning and arbitrary data, not just mismatch pair, after all the
> typedescriptors.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Thanks,
Richard.

> 2014-09-09  Jakub Jelinek  
> 
>   * ubsan.h (struct ubsan_mismatch_data): Removed.
>   (ubsan_create_data): Remove MISMATCH argument, add LOCCNT argument.
>   * ubsan.c (ubsan_source_location): For unknown locations,
>   pass { NULL, 0, 0 } instead of { "", x, y }.
>   (ubsan_create_data): Remove MISMATCH argument, add LOCCNT argument.
>   Allow more than one location and arbitrary extra arguments passed
>   in ... instead of through MISMATCH pointer.
>   (ubsan_instrument_unreachable, ubsan_expand_bounds_ifn,
>   ubsan_expand_null_ifn, ubsan_build_overflow_builtin,
>   instrument_bool_enum_load, ubsan_instrument_float_cast): Adjust
>   callers.
> c-family/
>   * c-ubsan.c (ubsan_instrument_division, ubsan_instrument_shift,
>   ubsan_instrument_vla, ubsan_instrument_return): Adjust
>   ubsan_create_data callers.
>   (ubsan_instrument_bounds): Don't emit UBSAN_BOUNDS at all if
>   index is constant or BIT_AND_EXPR with constant mask and is
>   small enough for the bound.
>   * c-gimplify.c (ubsan_walk_array_refs_r): For ADDR_EXPR of
>   ARRAY_REF, make sure the inner ARRAY_REF is not walked again.
> 
> --- gcc/ubsan.h.jj2014-09-08 22:12:27.591741242 +0200
> +++ gcc/ubsan.h   2014-09-09 09:35:04.461393547 +0200
> @@ -38,17 +38,10 @@ enum ubsan_print_style {
>UBSAN_PRINT_ARRAY
>  };
>  
> -/* An extra data used by ubsan pointer checking.  */
> -struct ubsan_mismatch_data {
> -  tree align;
> -  tree ckind;
> -};
> -
>  extern bool ubsan_expand_bounds_ifn (gimple_stmt_iterator *);
>  extern bool ubsan_expand_null_ifn (gimple_stmt_iterator *);
>  extern tree ubsan_instrument_unreachable (location_t);
> -extern tree ubsan_create_data (const char *, const location_t *,
> -const struct ubsan_mismatch_data *, ...);
> +extern tree ubsan_create_data (const char *, int, const location_t *, ...);
>  extern tree ubsan_type_descriptor (tree, enum ubsan_print_style = 
> UBSAN_PRINT_NORMAL);
>  extern tree ubsan_encode_value (tree, bool = false);
>  extern bool is_ubsan_builtin_p (tree);
> --- gcc/ubsan.c.jj2014-09-08 22:12:27.553741427 +0200
> +++ gcc/ubsan.c   2014-09-09 09:40:23.908791347 +0200
> @@ -242,17 +242,24 @@ ubsan_source_location (location_t loc)
>tree type = ubsan_source_location_type ();
>  
>xloc = expand_location (loc);
> +  tree str;
>if (xloc.file == NULL)
> -xloc.file = "";
> -
> -  /* Fill in the values from LOC.  */
> -  size_t len = strlen (xloc.file);
> -  tree str = build_string (len + 1, xloc.file);
> -  TREE_TYPE (str) = build_array_type (char_type_node,
> -   build_index_type (size_int (len)));
> -  TREE_READONLY (str) = 1;
> -  TREE_STATIC (str) = 1;
> -  str = build_fold_addr_expr (str);
> +{
> +  str = build_int_cst (ptr_type_node, 0);
> +  xloc.line = 0;
> +  xloc.column = 0;
> +}
> +  else
> +{
> +  /* Fill in the values from LOC.  */
> +  size_t len = strlen (xloc.file);
> +  str = build_string (len + 1, xloc.file);
> +  TREE_TYPE (str) = build_array_type (char_type_node,
> +   build_index_type (size_int (len)));
> +  TREE_READONLY (str) = 1;
> +  TREE_STATIC (str) = 1;
> +  str = build_fold_addr_expr (str);
> +}
>tree ctor = build_constructor_va (type, 3, NULL_TREE, str, NULL_TREE,
>   build_int_cst (unsigned_type_node,
>  xloc.line), NULL_TREE,
> @@ -451,20 +458,20 @@ ubsan_type_descriptor (tree type, enum u
>  }
>  
>  /* Create a structure for the ubsan library.  NAME is a name of the new
> -   structure.  The arguments in ... are of __ubsan_type_descriptor type
> -   and there are at most two of them.  MISMATCH are data used by ubsan
> -   pointer checking.  */
> +  

Re: [PATCH] -fsanitize=nonnull-attribute and -fsanitize=returns-nonnull-attribute support

[Richard Biener]

On Tue, 9 Sep 2014, Jakub Jelinek wrote:

> On Fri, Jun 27, 2014 at 09:13:07AM +0200, Jakub Jelinek wrote:
> > The patch adds two new (trivial handlers) to libubsan, as it is maintained
> > in llvm's compiler-rt, will talk to them if they are interested in those
> > and what exact wording and form (AFAIK clang also added the gcc
> > {,returns_}nonnull attributes).  If they wouldn't be interested, guess
> > we could add them in a separate, gcc owned, source file in ubsan (like we
> > own Makefile*).
> 
> And here is the actual new version of the patch, including cherry-picked
> libsanitizer changes.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Thanks,
Richard.

> 2014-09-09  Jakub Jelinek  
> 
> gcc/
>   * flag-types.h (enum sanitize_code): Add SANITIZE_NONNULL_ATTRIBUTE
>   and SANITIZE_RETURNS_NONNULL_ATTRIBUTE, or them into SANITIZE_UNDEFINED.
>   * opts.c (common_handle_option): Handle SANITIZE_NONNULL_ATTRIBUTE and
>   SANITIZE_RETURNS_NONNULL_ATTRIBUTE and disable
>   flag_delete_null_pointer_checks for them.
>   * sanitizer.def (BUILT_IN_UBSAN_HANDLE_NONNULL_ARG,
>   BUILT_IN_UBSAN_HANDLE_NONNULL_ARG_ABORT,
>   BUILT_IN_UBSAN_HANDLE_NONNULL_RETURN,
>   BUILT_IN_UBSAN_HANDLE_NONNULL_RETURN_ABORT): New.
>   * ubsan.c (instrument_bool_enum_load): Set *gsi back to
>   stmt's iterator.
>   (instrument_nonnull_arg, instrument_nonnull_return): New functions.
>   (pass_ubsan::gate): Return true even for SANITIZE_NONNULL_ATTRIBUTE
>   or SANITIZE_RETURNS_NONNULL_ATTRIBUTE.
>   (pass_ubsan::execute): Call instrument_nonnull_{arg,return}.
>   * doc/invoke.texi (-fsanitize=nonnull-attribute,
>   -fsanitize=returns-nonnull-attribute): Document.
> gcc/testsuite/
>   * c-c++-common/ubsan/attrib-3.c: New test.
>   * c-c++-common/ubsan/nonnull-1.c: New test.
>   * c-c++-common/ubsan/nonnull-2.c: New test.
>   * c-c++-common/ubsan/nonnull-3.c: New test.
>   * c-c++-common/ubsan/nonnull-4.c: New test.
>   * c-c++-common/ubsan/nonnull-5.c: New test.
> libsanitizer/
>   * ubsan/ubsan_handlers.cc, ubsan/ubsan_handlers.h: Cherry pick
>   upstream r215485, r217389, r217391 and r217400.
> 
> --- gcc/sanitizer.def.jj  2014-09-08 22:12:27.671740863 +0200
> +++ gcc/sanitizer.def 2014-09-09 11:59:18.694180701 +0200
> @@ -417,3 +417,19 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HAN
> "__ubsan_handle_out_of_bounds_abort",
> BT_FN_VOID_PTR_PTR,
> ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
> +DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_NONNULL_ARG,
> +   "__ubsan_handle_nonnull_arg",
> +   BT_FN_VOID_PTR_PTRMODE,
> +   ATTR_COLD_NOTHROW_LEAF_LIST)
> +DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_NONNULL_ARG_ABORT,
> +   "__ubsan_handle_nonnull_arg_abort",
> +   BT_FN_VOID_PTR_PTRMODE,
> +   ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
> +DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_NONNULL_RETURN,
> +   "__ubsan_handle_nonnull_return",
> +   BT_FN_VOID_PTR,
> +   ATTR_COLD_NOTHROW_LEAF_LIST)
> +DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_NONNULL_RETURN_ABORT,
> +   "__ubsan_handle_nonnull_return_abort",
> +   BT_FN_VOID_PTR,
> +   ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
> --- gcc/flag-types.h.jj   2014-09-09 11:59:18.693180712 +0200
> +++ gcc/flag-types.h  2014-09-09 12:00:26.780842334 +0200
> @@ -234,10 +234,14 @@ enum sanitize_code {
>SANITIZE_FLOAT_CAST = 1 << 15,
>SANITIZE_BOUNDS = 1 << 16,
>SANITIZE_ALIGNMENT = 1 << 17,
> +  SANITIZE_NONNULL_ATTRIBUTE = 1 << 18,
> +  SANITIZE_RETURNS_NONNULL_ATTRIBUTE = 1 << 19,
>SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | 
> SANITIZE_UNREACHABLE
>  | SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
>  | SANITIZE_SI_OVERFLOW | SANITIZE_BOOL | SANITIZE_ENUM
> -| SANITIZE_BOUNDS | SANITIZE_ALIGNMENT,
> +| SANITIZE_BOUNDS | SANITIZE_ALIGNMENT
> +| SANITIZE_NONNULL_ATTRIBUTE
> +| SANITIZE_RETURNS_NONNULL_ATTRIBUTE,
>SANITIZE_NONDEFAULT = SANITIZE_FLOAT_DIVIDE | SANITIZE_FLOAT_CAST
>  };
>  
> --- gcc/ubsan.c.jj2014-09-09 14:08:22.938445806 +0200
> +++ gcc/ubsan.c   2014-09-09 13:58:14.381504541 +0200
> @@ -1090,6 +1090,7 @@ instrument_bool_enum_load (gimple_stmt_i
>  }
>gimple_set_location (g, loc);
>gsi_insert_before (&gsi2, g, GSI_SAME_STMT);
> +  *gsi = gsi_for_stmt (stmt);
>  }
>  
>  /* Instrument float point-to-integer conversion.  TYPE is an integer type of
> @@ -1215,6 +1216,122 @@ ubsan_instrument_float_cast (location_t
> fn, integer_zero_node);
>  }
>  
> +/* Instrument values passed to function arguments with nonnull attribute.  */
>

[PATCHv2] Vimrc config with GNU formatting

[Yury Gribov]

Hi all,

This is a second version of patch which adds a Vim config (.local.vimrc)
to root folder to allow automatic setup of GNU formatting for 
C/C++/Java/Lex GCC files.


I've updated the code with comments from Richard and Bernhard (which 
fixed formatting

of lonely closing bracket).

The patch caused a lively debate with Segher who wanted .local.vimrc to 
not be enabled

by default. We basically have two options:
1) put .local.vimrc to root (just like .dir-locals.el config for Emacs)
2) put both .local.vimrc and .dir-locals.el to contrib and add Makefile 
targets

to create symlinks in root folder per user's request
I personally prefer 2) because this would IMHO improve the quality of 
patches

(e.g. no more silly tab-whitespace formatting bugs).

Thoughts? Ok to commit?

-Y



commit 879cd3e9bdcab780a9b96aff759ef684e3597d0c
Author: Yury Gribov 
Date:   Thu Sep 4 16:55:44 2014 +0400

2014-09-10  Laurynas Biveinis  
	Yury Gribov  

	* .local.vimrc: New file.

diff --git a/.local.vimrc b/.local.vimrc
new file mode 100644
index 000..98f3135
--- /dev/null
+++ b/.local.vimrc
@@ -0,0 +1,39 @@
+" Vim settings.
+"
+" To autorun install thinca's localrc plugin. Otherwise just source via
+" :so .local.vimrc
+
+" Copyright (C) 2014 Free Software Foundation, Inc.
+"
+" 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 .
+
+function! SetStyle()
+  let l:fname = expand("%:p")
+  let l:non_gnu_dirs = ['libsanitizer']
+  if index(l:non_gnu_dirs, l:fname) != -1
+return
+  endif
+  let l:ext = fnamemodify(l:fname, ":e")
+  let l:c_exts = ['c', 'h', 'cpp', 'cc', 'C', 'H', 'def', 'java', 'l']
+  if index(l:c_exts, l:ext) != -1
+setlocal cindent
+setlocal shiftwidth=2
+setlocal softtabstop=2
+setlocal cinoptions=>2s,n-s,{s,^-s,:s,=s,g0,hs,p5,t0,+s,(0,u0,w1,m0
+setlocal textwidth=79
+setlocal fo-=ro fo+=cql
+  endif
+endfunction
+
+call SetStyle()

Re: [PATCH ARM]memset inlining patch for arm

[Bin.Cheng]

On Sat, Sep 6, 2014 at 3:33 AM, Evandro Menezes  wrote:
> Bin,
>
> This is perhaps a plus for Aarch64 as well.  Is there any plan to add a
> 64-bit version of this patch or should a bug be open for this?
Hi Evandro,

Yes, AARCH64 may want this too.  I think Ramana/Marcus should have the
answer/plan to this question?

Thanks,
bin
>
> Thank you,
>
> --
> Evandro Menezes  Austin, TX
>
>
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
> On Behalf Of Bin Cheng
> Sent: Thursday, September 04, 2014 1:08
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH ARM]memset inlining patch for arm
>

Re: [PATCH ARM]memset inlining patch for arm

[Bin.Cheng]

On Tue, Sep 9, 2014 at 6:49 PM, Richard Earnshaw  wrote:
> On 04/09/14 07:08, Bin Cheng wrote:
>> @@ -1872,7 +1892,9 @@ const struct tune_params arm_cortex_a53_tune =
>>{true, true},  /* Prefer non short 
>> circuit.  */
>>&arm_default_vec_cost, /* Vectorizer costs.  */
>>false, /* Prefer Neon for 64-bits 
>> bitops.  */
>> -  false, false  /* Prefer 32-bit encodings. 
>>  */
>> +  false, false, /* Prefer 32-bit encodings. 
>>  */
>> +  false, /* Prefer Neon for stringops.  
>> */
>> +  8  /* Maximum insns to inline 
>> memset.  */
>>  };
>>
>>  const struct tune_params arm_cortex_a57_tune =
>> @@ -1889,7 +1911,9 @@ const struct tune_params arm_cortex_a57_tune =
>>{true, true},/* Prefer non short circuit. 
>>  */
>>&arm_default_vec_cost,   /* Vectorizer costs.  */
>>false,   /* Prefer Neon for 64-bits 
>> bitops.  */
>> -  true, true   /* Prefer 32-bit encodings.  
>> */
>> +  true, true,  /* Prefer 32-bit encodings.  
>> */
>> +  false, /* Prefer Neon for stringops.  
>> */
>> +  8  /* Maximum insns to inline 
>> memset.  */
>>  };
>
> Why don't we use Neon for Cortex-(A53,A57)?  We've used it for
> Cortex-(A7,A8,A15).
Hi Richard,

Since changes in aarch64.md is needed, also the bug and patch are for
arm only, I left this behind for aarch64.  Another aarch64 patch
should be worked for this in the near (?) future.

Thanks,
bin

Re: [PATCHv2] Vimrc config with GNU formatting

[Yury Gribov]

> I personally prefer 2)

Sorry, I meant 1) of course that is enable vimrc config by default.

-Y

Re: [PATCH][ARM][1/7] Convert FP mnemonics to UAL | mov patterns

[Christophe Lyon]

Hi,


On 9 September 2014 13:02, Ramana Radhakrishnan
 wrote:
> On Tue, Aug 19, 2014 at 4:22 PM, Kyrill Tkachov  
> wrote:
>> Hi all,
>>
>> In this patch the move patterns are updated.
>> For the fconst case where the constant is encoded in a decimal
>> representation before going into the immediate field of the assembly
>> instruction UAL syntax allows for the real operand to be output directly
>> and leaves the assembler to do the encoding.
>> This simplifies the logic in arm_print_operand a bit.
>>
>> fp_immediate_constant is deleted and it seems that the function was not
>> meant to be used anyway (it returned "0" for all inputs!)
>>
>> Ok for trunk?
>
> Ok.
>
> Ramana
>

I've noticed that your patch makes
gcc.target/arm/memset-inline-5.c
fail when the compiler generates code for a57 + crypto-neon-fp-armv8.

Passed now fails  [PASS => FAIL]:
  gcc.target/arm/memset-inline-5.c scan-assembler-not vstr

You can have a look at:
http://cbuild.validation.linaro.org/build/cross-validation/gcc/trunk/215050/report-build-info.html
(search for the a57 lines)

(The other lines marked as regressions can be ignored: they are caused
by your changes in the tests output, I not yet able to associate the
new pass with the new fail)

Thanks,

Christophe.

>>
>> Thanks,
>> Kyrill
>>
>> 2014-08-19  Kyrylo Tkachov  
>>
>>  * config/arm/arm.c (output_move_vfp): Use UAL syntax for load/store
>>  multiple.
>>  (arm_print_operand): Don't convert real values to decimal
>>  representation in default case.
>>  (fp_immediate_constant): Delete.
>>  * config/arm/arm-protos.h (fp_immediate_constant): Likewise.
>>  * config/arm/vfp.md (*arm_movsi_vfp): Convert to VFP moves to UAL
>>  syntax.
>>  (*thumb2_movsi_vfp): Likewise.
>>  (*movdi_vfp): Likewise.
>>  (*movdi_vfp_cortexa8): Likewise.
>>  (*movhf_vfp_neon): Likewise.
>>  (*movhf_vfp): Likewise.
>>  (*movsf_vfp): Likewise.
>>  (*thumb2_movsf_vfp): Likewise.
>>  (*movdf_vfp): Likewise.
>>  (*thumb2_movdf_vfp): Likewise.
>>  (*movsfcc_vfp): Likewise.
>>  (*thumb2_movsfcc_vfp): Likewise.
>>  (*movdfcc_vfp): Likewise.
>>  (*thumb2_movdfcc_vfp): Likewise.
>>
>> 2014-08-19  Kyrylo Tkachov  
>>
>>  * gcc.target/arm/pr51835.c: Update expected assembly.
>>  * gcc.target/arm/vfp-1.c: Likewise.
>>  * gcc.target/arm/vfp-ldmdbd.c: Likewise.
>>  * gcc.target/arm/vfp-ldmdbs.c: Likewise.
>>  * gcc.target/arm/vfp-ldmiad.c: Likewise.
>>  * gcc.target/arm/vfp-ldmias.c: Likewise.
>>  * gcc.target/arm/vfp-stmdbd.c: Likewise.
>>  * gcc.target/arm/vfp-stmdbs.c: Likewise.
>>  * gcc.target/arm/vfp-stmiad.c: Likewise.
>>  * gcc.target/arm/vfp-stmias.c: Likewise.

[PATCH] S/390: Implement SD<->TD conversions

[Andreas Krebbel]

Hi,

on S/390 we have DFP conversions for SD<->DD and DD<->TD but miss
SD<->TD. The attached patch expands the missing patterns to SD->DD->TD
and TD->DD->SD to avoid library calls being emitted.

No regressions on s390 and s390x.

Bye,

-Andreas-

2014-09-10  Andreas Krebbel  

* config/s390/s390.md ("trunctdsd2", "extendsdtd2"): New
expanders.

2014-09-10  Andreas Krebbel  

* gcc.target/s390/dfp-conv1.c: New testcase.

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index bcfe8f9..73ac0dc 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -4406,6 +4406,18 @@
   [(set_attr "op_type" "RRF")
(set_attr "type""ftruncsd")])
 
+(define_expand "trunctdsd2"
+  [(parallel
+[(set (match_dup 3)
+ (float_truncate:DD (match_operand:TD 1 "register_operand" "")))
+ (clobber (match_scratch:TD 2 ""))])
+   (set (match_operand:SD 0 "register_operand" "")
+   (float_truncate:SD (match_dup 3)))]
+  "TARGET_HARD_DFP"
+{
+  operands[3] = gen_reg_rtx (DDmode);
+})
+
 ;
 ; extend(sf|df)(df|tf)2 instruction pattern(s).
 ;
@@ -4442,6 +4454,16 @@
   [(set_attr "op_type" "RRF")
(set_attr "type""fsimptf")])
 
+(define_expand "extendsdtd2"
+  [(set (match_dup 2)
+   (float_extend:DD (match_operand:SD 1 "register_operand" "")))
+   (set (match_operand:TD 0 "register_operand" "")
+   (float_extend:TD (match_dup 2)))]
+  "TARGET_HARD_DFP"
+{
+  operands[2] = gen_reg_rtx (DDmode);
+})
+
 ; Binary Floating Point - load fp integer
 
 ; Expanders for: floor, btrunc, round, ceil, and nearbyint
diff --git a/gcc/testsuite/gcc.target/s390/dfp-conv1.c 
b/gcc/testsuite/gcc.target/s390/dfp-conv1.c
new file mode 100644
index 000..3c553a3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/dfp-conv1.c
@@ -0,0 +1,22 @@
+/* We do not have hardware instructions which do a direct conversion
+   between the 32 and 128 bit DFP types.  But we can easily do it in
+   two steps.  Older libdfp implementations require this not to call
+   into a lib in order to prevent an endless loop.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=z10 -mzarch" } */
+
+_Decimal32 
+foo (_Decimal128 a)
+{
+  return (_Decimal32)a;
+}
+
+_Decimal128
+bar (_Decimal32 a)
+{
+  return (_Decimal128)a;
+}
+
+/* Make sure no library call is emitted.  */
+/* { dg-final { scan-assembler-not "brasl" } } */
-- 
1.7.11.4

[PATCH] S/390: PR62662 Fix r14 restore optimization

[Andreas Krebbel]

Hi,

this fixes a problem with the prologue optimization in machine
dependent reorg.  For more details please see PR62662.

No regressions on s390 and s390x.

-Andreas-


2014-09-10  Andreas Krebbel  

PR target/62662
* config/s390/s390.c (s390_emit_epilogue): When doing the return
address load optimization force s390_optimize_prologue to leave it
that way.  Only do the optimization if we already decided to push
r14 into a stack slot.

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index f7a95dd..161efd9 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -9082,11 +9082,14 @@ s390_emit_epilogue (bool sibcall)
   if (! sibcall)
{
  /* Fetch return address from stack before load multiple,
-this will do good for scheduling.  */
-
- if (cfun_frame_layout.save_return_addr_p
- || (cfun_frame_layout.first_restore_gpr < BASE_REGNUM
- && cfun_frame_layout.last_restore_gpr > RETURN_REGNUM))
+this will do good for scheduling.
+
+Only do this if we already decided that r14 needs to be
+saved to a stack slot. (And not just because r14 happens to
+be in between two GPRs which need saving.)  Otherwise it
+would be difficult to take that decision back in
+s390_optimize_prologue.  */
+ if (cfun_gpr_save_slot (RETURN_REGNUM) == -1)
{
  int return_regnum = find_unused_clobbered_reg();
  if (!return_regnum)
@@ -9101,6 +9104,13 @@ s390_emit_epilogue (bool sibcall)
  addr = gen_rtx_MEM (Pmode, addr);
  set_mem_alias_set (addr, get_frame_alias_set ());
  emit_move_insn (return_reg, addr);
+
+ /* Once we did that optimization we have to make sure
+s390_optimize_prologue does not try to remove the
+store of r14 since we will not be able to find the
+load issued here.  */
+ cfun_frame_layout.save_return_addr_p = true;
+ cfun_gpr_save_slot (RETURN_REGNUM) = -1;
}
}
 
-- 
1.7.11.4

Re: [PATCH ARM]memset inlining patch for arm

[Ramana Radhakrishnan]

On Wed, Sep 10, 2014 at 9:16 AM, Bin.Cheng  wrote:
> On Tue, Sep 9, 2014 at 6:49 PM, Richard Earnshaw  wrote:
>> On 04/09/14 07:08, Bin Cheng wrote:
>>> @@ -1872,7 +1892,9 @@ const struct tune_params arm_cortex_a53_tune =
>>>{true, true},  /* Prefer non short 
>>> circuit.  */
>>>&arm_default_vec_cost, /* Vectorizer costs.  */
>>>false, /* Prefer Neon for 64-bits 
>>> bitops.  */
>>> -  false, false  /* Prefer 32-bit 
>>> encodings.  */
>>> +  false, false, /* Prefer 32-bit 
>>> encodings.  */
>>> +  false, /* Prefer Neon for stringops. 
>>>  */
>>> +  8  /* Maximum insns to inline 
>>> memset.  */
>>>  };
>>>
>>>  const struct tune_params arm_cortex_a57_tune =
>>> @@ -1889,7 +1911,9 @@ const struct tune_params arm_cortex_a57_tune =
>>>{true, true},/* Prefer non short 
>>> circuit.  */
>>>&arm_default_vec_cost,   /* Vectorizer costs.  */
>>>false,   /* Prefer Neon for 64-bits 
>>> bitops.  */
>>> -  true, true   /* Prefer 32-bit encodings. 
>>>  */
>>> +  true, true,  /* Prefer 32-bit encodings. 
>>>  */
>>> +  false, /* Prefer Neon for stringops. 
>>>  */
>>> +  8  /* Maximum insns to inline 
>>> memset.  */
>>>  };
>>
>> Why don't we use Neon for Cortex-(A53,A57)?  We've used it for
>> Cortex-(A7,A8,A15).
> Hi Richard,
>
> Since changes in aarch64.md is needed, also the bug and patch are for
> arm only, I left this behind for aarch64.  Another aarch64 patch
> should be worked for this in the near (?) future.

We should fix that up. Cortex-A57 and Cortex-A53 can run AArch32 code,
that's why you have that support in the ARM backend.

Ramana

>
> Thanks,
> bin

Re: [PATCH][ARM][1/7] Convert FP mnemonics to UAL | mov patterns

[Kyrill Tkachov]

On 10/09/14 09:40, Christophe Lyon wrote:

Hi,

Hi Christophe,



On 9 September 2014 13:02, Ramana Radhakrishnan
 wrote:

On Tue, Aug 19, 2014 at 4:22 PM, Kyrill Tkachov  wrote:

Hi all,

In this patch the move patterns are updated.
For the fconst case where the constant is encoded in a decimal
representation before going into the immediate field of the assembly
instruction UAL syntax allows for the real operand to be output directly
and leaves the assembler to do the encoding.
This simplifies the logic in arm_print_operand a bit.

fp_immediate_constant is deleted and it seems that the function was not
meant to be used anyway (it returned "0" for all inputs!)

Ok for trunk?

Ok.

Ramana


I've noticed that your patch makes
gcc.target/arm/memset-inline-5.c
fail when the compiler generates code for a57 + crypto-neon-fp-armv8.


I've managed to reproduce the failure as well (don't forget the 
-mfloat-abi=hard), however
I tried with and without my patch and could still see the failure. 
Looking at the test itself I don't

see what my patch could have changed in this department...

I'm cc'ing Bin since he added the test for his recent memset inlining work.
Bin, could you have a look please?

Thanks,
Kyrill

Passed now fails  [PASS => FAIL]:
   gcc.target/arm/memset-inline-5.c scan-assembler-not vstr

You can have a look at:
http://cbuild.validation.linaro.org/build/cross-validation/gcc/trunk/215050/report-build-info.html
(search for the a57 lines)

(The other lines marked as regressions can be ignored: they are caused
by your changes in the tests output, I not yet able to associate the
new pass with the new fail)

Thanks,

Christophe.


Thanks,
Kyrill

2014-08-19  Kyrylo Tkachov  

  * config/arm/arm.c (output_move_vfp): Use UAL syntax for load/store
  multiple.
  (arm_print_operand): Don't convert real values to decimal
  representation in default case.
  (fp_immediate_constant): Delete.
  * config/arm/arm-protos.h (fp_immediate_constant): Likewise.
  * config/arm/vfp.md (*arm_movsi_vfp): Convert to VFP moves to UAL
  syntax.
  (*thumb2_movsi_vfp): Likewise.
  (*movdi_vfp): Likewise.
  (*movdi_vfp_cortexa8): Likewise.
  (*movhf_vfp_neon): Likewise.
  (*movhf_vfp): Likewise.
  (*movsf_vfp): Likewise.
  (*thumb2_movsf_vfp): Likewise.
  (*movdf_vfp): Likewise.
  (*thumb2_movdf_vfp): Likewise.
  (*movsfcc_vfp): Likewise.
  (*thumb2_movsfcc_vfp): Likewise.
  (*movdfcc_vfp): Likewise.
  (*thumb2_movdfcc_vfp): Likewise.

2014-08-19  Kyrylo Tkachov  

  * gcc.target/arm/pr51835.c: Update expected assembly.
  * gcc.target/arm/vfp-1.c: Likewise.
  * gcc.target/arm/vfp-ldmdbd.c: Likewise.
  * gcc.target/arm/vfp-ldmdbs.c: Likewise.
  * gcc.target/arm/vfp-ldmiad.c: Likewise.
  * gcc.target/arm/vfp-ldmias.c: Likewise.
  * gcc.target/arm/vfp-stmdbd.c: Likewise.
  * gcc.target/arm/vfp-stmdbs.c: Likewise.
  * gcc.target/arm/vfp-stmiad.c: Likewise.
  * gcc.target/arm/vfp-stmias.c: Likewise.

DBL_DENORM_MIN should never be 0

[Marc Glisse]

Hello,

according to the C++ standard, numeric_limits::denorm_min should return 
min (not 0) when there are no denormals.


Tested with bootstrap+testsuite on x86_64-linux-gnu. I also tested a basic 
make all-gcc for vax (only target without denormals apparently) and the 
macro did change as expected.


The next step might be to define has_denorm as false in more cases 
(-mno-ieee on alpha, -ffast-math on x86, etc) but that's a different 
issue.


(this is C++ but I believe Joseph is the floating-point expert, hence the 
cc)


gcc/c-family/

2014-09-10  Marc Glisse  

* c-cppbuiltin.c (builtin_define_float_constants): Correct
__*_DENORM_MIN__ without denormals.

--
Marc GlisseIndex: gcc/c-family/c-cppbuiltin.c
===
--- gcc/c-family/c-cppbuiltin.c (revision 215103)
+++ gcc/c-family/c-cppbuiltin.c (working copy)
@@ -264,34 +264,27 @@ builtin_define_float_constants (const ch
   sprintf (name, "__%s_EPSILON__", name_prefix);
   if (fmt->pnan < fmt->p)
 /* This is an IBM extended double format, so 1.0 + any double is
representable precisely.  */
   sprintf (buf, "0x1p%d", fmt->emin - fmt->p);
 else
   sprintf (buf, "0x1p%d", 1 - fmt->p);
   builtin_define_with_hex_fp_value (name, type, decimal_dig, buf, fp_suffix, 
fp_cast);
 
   /* For C++ std::numeric_limits::denorm_min.  The minimum denormalized
- positive floating-point number, b**(emin-p).  Zero for formats that
- don't support denormals.  */
+ positive floating-point number, b**(emin-p).  The minimum normalized
+ positive floating-point number for formats that don't support
+ denormals.  */
   sprintf (name, "__%s_DENORM_MIN__", name_prefix);
-  if (fmt->has_denorm)
-{
-  sprintf (buf, "0x1p%d", fmt->emin - fmt->p);
-  builtin_define_with_hex_fp_value (name, type, decimal_dig,
-   buf, fp_suffix, fp_cast);
-}
-  else
-{
-  sprintf (buf, "0.0%s", fp_suffix);
-  builtin_define_with_value (name, buf, 0);
-}
+  sprintf (buf, "0x1p%d", fmt->emin - (fmt->has_denorm ? fmt->p : 1));
+  builtin_define_with_hex_fp_value (name, type, decimal_dig,
+   buf, fp_suffix, fp_cast);
 
   sprintf (name, "__%s_HAS_DENORM__", name_prefix);
   builtin_define_with_value (name, fmt->has_denorm ? "1" : "0", 0);
 
   /* For C++ std::numeric_limits::has_infinity.  */
   sprintf (name, "__%s_HAS_INFINITY__", name_prefix);
   builtin_define_with_int_value (name,
 MODE_HAS_INFINITIES (TYPE_MODE (type)));
   /* For C++ std::numeric_limits::has_quiet_NaN.  We do not have a
  predicate to distinguish a target that has both quiet and

[C++, OpenMP] Crash when OpenMP target's array section handling is used with templates

[Thomas Schwinge]

Hi!

Are the following issues known?

template 
void f(T A, T B)
{
  extern int *v;
  T a = 2;
  T b = 4;

#pragma omp target map(to: v[a:b])
  v[a] = 0;

#pragma omp target map(to: v[A:B])
  v[a] = 0;
}

void g()
{
  f(1, 5);
}

../../openacc/T.C: In function 'void f(T, T)':
../../openacc/T.C:8:35: internal compiler error: Segmentation fault
0xc1833f crash_signal
../../source/gcc/toplev.c:339
0x697f0d tree_class_check
../../source/gcc/tree.h:2851
0x697f0d cp_omp_mappable_type(tree_node*)
../../source/gcc/cp/decl2.c:1393
0x764777 finish_omp_clauses(tree_node*)
../../source/gcc/cp/semantics.c:5671
0x6d3d39 cp_parser_omp_all_clauses
../../source/gcc/cp/parser.c:28680
0x6c6265 cp_parser_omp_target
../../source/gcc/cp/parser.c:30649
[...]

The following patch avoids the crash but doesn't resolve the issue
itself:

../../openacc/T.C: In function 'void f(T, T)':
../../openacc/T.C:8:28: error: array section does not have mappable type in 
'map' clause
 #pragma omp target map(to: v[a:b])
^
../../openacc/T.C:11:28: error: array section does not have mappable type 
in 'map' clause
 #pragma omp target map(to: v[A:B])
^

diff --git gcc/cp/decl2.c gcc/cp/decl2.c
index 4be4847..b418156 100644
--- gcc/cp/decl2.c
+++ gcc/cp/decl2.c
@@ -1390,7 +1390,7 @@ bool
 cp_omp_mappable_type (tree type)
 {
   /* Mappable type has to be complete.  */
-  if (type == error_mark_node || !COMPLETE_TYPE_P (type))
+  if (type == error_mark_node || !type || !COMPLETE_TYPE_P (type))
 return false;
   /* Arrays have mappable type if the elements have mappable type.  */
   while (TREE_CODE (type) == ARRAY_TYPE)


For additional fun, replace »v[a] = 0;« with just »;«, and see:

../../openacc/T.C: In function 'void f(T, T)':
../../openacc/T.C:8:28: error: array section does not have mappable type in 
'map' clause
 #pragma omp target map(to: v[a:b])
^
../../openacc/T.C:11:28: error: array section does not have mappable type 
in 'map' clause
 #pragma omp target map(to: v[A:B])
^
../../openacc/T.C: In instantiation of 'void f(T, T) [with T = int]':
../../openacc/T.C:17:9:   required from here
../../openacc/T.C:4:15: warning: unused variable 'v' [-Wunused-variable]
   extern int *v;
   ^
../../openacc/T.C: In function 'void f(T, T) [with T = int]':
../../openacc/T.C:8:9: internal compiler error: Segmentation fault
 #pragma omp target map(to: v[a:b])
 ^
0xc1833f crash_signal
../../source/gcc/toplev.c:339
0xa51624 gimplify_omp_workshare
../../source/gcc/gimplify.c:7137
0xa3facb gimplify_expr(tree_node**, gimple_statement_base**, 
gimple_statement_base**, bool (*)(tree_node*), int)
../../source/gcc/gimplify.c:8144
0xa432c6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../source/gcc/gimplify.c:5416
0xa3ec93 gimplify_statement_list
../../source/gcc/gimplify.c:1450
0xa3ec93 gimplify_expr(tree_node**, gimple_statement_base**, 
gimple_statement_base**, bool (*)(tree_node*), int)
../../source/gcc/gimplify.c:8090
0xa432c6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../source/gcc/gimplify.c:5416
0xa44147 gimplify_bind_expr
../../source/gcc/gimplify.c:1099
[...]

Program received signal SIGSEGV, Segmentation fault.
gimplify_omp_workshare (expr_p=expr_p@entry=0x76845988, 
pre_p=pre_p@entry=0x7fffca68) at ../../source/gcc/gimplify.c:7137
7137  if (gimple_code (g) == GIMPLE_BIND)
(gdb) print g
$1 = (gimple) 0x0
(gdb) list
7132  gimplify_scan_omp_clauses (&OMP_CLAUSES (expr), pre_p, ort);
7133  if (ort == ORT_TARGET || ort == ORT_TARGET_DATA)
7134{
7135  push_gimplify_context ();
7136  gimple g = gimplify_and_return_first (OMP_BODY (expr), &body);
7137  if (gimple_code (g) == GIMPLE_BIND)
7138pop_gimplify_context (g);
7139  else
7140pop_gimplify_context (NULL);
7141  if (ort == ORT_TARGET_DATA)
(gdb) print expr
$2 = (tree) 0x76835988
(gdb) call debug_tree(expr)
 >
side-effects tree_1
arg 0 
head (nil) tail (nil) stmts
>
../../openacc/T.C:8:9>


Grüße,
 Thomas


pgpZTBL1VTJxo.pgp
Description: PGP signature

Re: [C++ Patch] Add default arguments to cp_parser_assignment_expression and cp_parser_constant_expression

[Paolo Carlini]

Hi,

On 08/19/2014 02:18 PM, Paolo Carlini wrote:

Hi,

two more functions. Tested x86_64-linux.

I'm pinging this.

https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01853.html

Frankly, the cp_parser_constant_expression bits seem rather 
straightforward to me. As regards the cp_parser_assignment_expression 
bits, I realize that it's debatable whether moving the cp_id_kind * 
parameter before the bool parameters is really an improvement from say 
the readibility point of view, but I did that already for 
cp_parser_expression, in case we should revert the latter change, for 
consistency.


Paolo.

Re: [PATCH ARM]memset inlining patch for arm

[Richard Earnshaw]

On 10/09/14 09:16, Bin.Cheng wrote:

On Tue, Sep 9, 2014 at 6:49 PM, Richard Earnshaw  wrote:

On 04/09/14 07:08, Bin Cheng wrote:

@@ -1872,7 +1892,9 @@ const struct tune_params arm_cortex_a53_tune =
{true, true},  /* Prefer non short 
circuit.  */
&arm_default_vec_cost, /* Vectorizer costs.  */
false, /* Prefer Neon for 64-bits 
bitops.  */
-  false, false  /* Prefer 32-bit encodings.  */
+  false, false, /* Prefer 32-bit encodings.  */
+  false, /* Prefer Neon for stringops.  */
+  8  /* Maximum insns to inline 
memset.  */
  };

  const struct tune_params arm_cortex_a57_tune =
@@ -1889,7 +1911,9 @@ const struct tune_params arm_cortex_a57_tune =
{true, true},/* Prefer non short circuit.  
*/
&arm_default_vec_cost,   /* Vectorizer costs.  */
false,   /* Prefer Neon for 64-bits 
bitops.  */
-  true, true   /* Prefer 32-bit encodings.  */
+  true, true,  /* Prefer 32-bit encodings.  */
+  false, /* Prefer Neon for stringops.  */
+  8  /* Maximum insns to inline 
memset.  */
  };


Why don't we use Neon for Cortex-(A53,A57)?  We've used it for
Cortex-(A7,A8,A15).

Hi Richard,

Since changes in aarch64.md is needed, also the bug and patch are for
arm only, I left this behind for aarch64.  Another aarch64 patch
should be worked for this in the near (?) future.



No, that can't be; these definitions are in arm.c, so can't impact aarch64.

R.


Thanks,
bin

Re: [PATCH][ARM][1/7] Convert FP mnemonics to UAL | mov patterns

[Bin.Cheng]

On Wed, Sep 10, 2014 at 4:57 PM, Kyrill Tkachov  wrote:
>
> On 10/09/14 09:40, Christophe Lyon wrote:
>>
>> Hi,
>
> Hi Christophe,
>
>>
>> On 9 September 2014 13:02, Ramana Radhakrishnan
>>  wrote:
>>>
>>> On Tue, Aug 19, 2014 at 4:22 PM, Kyrill Tkachov 
>>> wrote:

 Hi all,

 In this patch the move patterns are updated.
 For the fconst case where the constant is encoded in a decimal
 representation before going into the immediate field of the assembly
 instruction UAL syntax allows for the real operand to be output directly
 and leaves the assembler to do the encoding.
 This simplifies the logic in arm_print_operand a bit.

 fp_immediate_constant is deleted and it seems that the function was not
 meant to be used anyway (it returned "0" for all inputs!)

 Ok for trunk?
>>>
>>> Ok.
>>>
>>> Ramana
>>>
>> I've noticed that your patch makes
>> gcc.target/arm/memset-inline-5.c
>> fail when the compiler generates code for a57 + crypto-neon-fp-armv8.
>
>
> I've managed to reproduce the failure as well (don't forget the
> -mfloat-abi=hard), however
> I tried with and without my patch and could still see the failure. Looking
> at the test itself I don't
> see what my patch could have changed in this department...
>
> I'm cc'ing Bin since he added the test for his recent memset inlining work.
> Bin, could you have a look please?
I will have a look tomorrow.

Thanks,
bin
>
> Thanks,
> Kyrill
>
>> Passed now fails  [PASS => FAIL]:
>>gcc.target/arm/memset-inline-5.c scan-assembler-not vstr
>>
>> You can have a look at:
>>
>> http://cbuild.validation.linaro.org/build/cross-validation/gcc/trunk/215050/report-build-info.html
>> (search for the a57 lines)
>>
>> (The other lines marked as regressions can be ignored: they are caused
>> by your changes in the tests output, I not yet able to associate the
>> new pass with the new fail)
>>
>> Thanks,
>>
>> Christophe.
>>
 Thanks,
 Kyrill

 2014-08-19  Kyrylo Tkachov  

   * config/arm/arm.c (output_move_vfp): Use UAL syntax for
 load/store
   multiple.
   (arm_print_operand): Don't convert real values to decimal
   representation in default case.
   (fp_immediate_constant): Delete.
   * config/arm/arm-protos.h (fp_immediate_constant): Likewise.
   * config/arm/vfp.md (*arm_movsi_vfp): Convert to VFP moves to UAL
   syntax.
   (*thumb2_movsi_vfp): Likewise.
   (*movdi_vfp): Likewise.
   (*movdi_vfp_cortexa8): Likewise.
   (*movhf_vfp_neon): Likewise.
   (*movhf_vfp): Likewise.
   (*movsf_vfp): Likewise.
   (*thumb2_movsf_vfp): Likewise.
   (*movdf_vfp): Likewise.
   (*thumb2_movdf_vfp): Likewise.
   (*movsfcc_vfp): Likewise.
   (*thumb2_movsfcc_vfp): Likewise.
   (*movdfcc_vfp): Likewise.
   (*thumb2_movdfcc_vfp): Likewise.

 2014-08-19  Kyrylo Tkachov  

   * gcc.target/arm/pr51835.c: Update expected assembly.
   * gcc.target/arm/vfp-1.c: Likewise.
   * gcc.target/arm/vfp-ldmdbd.c: Likewise.
   * gcc.target/arm/vfp-ldmdbs.c: Likewise.
   * gcc.target/arm/vfp-ldmiad.c: Likewise.
   * gcc.target/arm/vfp-ldmias.c: Likewise.
   * gcc.target/arm/vfp-stmdbd.c: Likewise.
   * gcc.target/arm/vfp-stmdbs.c: Likewise.
   * gcc.target/arm/vfp-stmiad.c: Likewise.
   * gcc.target/arm/vfp-stmias.c: Likewise.
>
>
>

Re: [C++, OpenMP] Crash when OpenMP target's array section handling is used with templates

[Jakub Jelinek]

On Wed, Sep 10, 2014 at 12:12:03PM +0200, Thomas Schwinge wrote:
> Are the following issues known?

No, please file a PR.  Supposedly either we should call cp_omp_mappable_type
only for non-type-dependent expressions, or not at all if
processing_template_decl and only do that once finish_omp_clauses is called
with !processing_template_decl.

> 
> template 
> void f(T A, T B)
> {
>   extern int *v;
>   T a = 2;
>   T b = 4;
> 
> #pragma omp target map(to: v[a:b])
>   v[a] = 0;
> 
> #pragma omp target map(to: v[A:B])
>   v[a] = 0;
> }
> 
> void g()
> {
>   f(1, 5);
> }

Jakub

[OpenMP] Spurious »set but not used« warnings when actually used in OpenMP target's array section's lower-bound and length

[Thomas Schwinge]

Hi!

This is similar to what has previously been addressed in
,
:

int f(int A, int B)
{
  int r = 0;
  extern int *v;
  int a = 2;
  int b = 4;
  int n = 3;

  v[n] = 0;

#pragma omp target map(to: v[a:b])
  r |= v[n];

#pragma omp target map(to: v[A:B])
  r |= v[n];

  return r;
}

../../openacc/w.c: In function 'f':
../../openacc/w.c:6:7: warning: variable 'b' set but not used 
[-Wunused-but-set-variable]
   int b = 4;
   ^
../../openacc/w.c:5:7: warning: variable 'a' set but not used 
[-Wunused-but-set-variable]
   int a = 2;
   ^
../../openacc/w.c:1:11: warning: parameter 'A' set but not used 
[-Wunused-but-set-parameter]
 int f(int A, int B)
   ^
../../openacc/w.c:1:18: warning: parameter 'B' set but not used 
[-Wunused-but-set-parameter]
 int f(int A, int B)
  ^

The following patch fixes this for C:

diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index 3f4a92b..bba6edb 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -9887,7 +9887,10 @@ c_parser_omp_variable_list (c_parser *parser,
 
  c_parser_consume_token (parser);
  if (!c_parser_next_token_is (parser, CPP_COLON))
-   low_bound = c_parser_expression (parser).value;
+   {
+ low_bound = c_parser_expression (parser).value;
+ mark_exp_read (low_bound);
+   }
  if (c_parser_next_token_is (parser, CPP_CLOSE_SQUARE))
length = integer_one_node;
  else
@@ -9900,7 +9903,10 @@ c_parser_omp_variable_list (c_parser *parser,
  break;
}
  if (!c_parser_next_token_is (parser, CPP_CLOSE_SQUARE))
-   length = c_parser_expression (parser).value;
+   {
+ length = c_parser_expression (parser).value;
+ mark_exp_read (length);
+   }
}
  /* Look for the closing `]'.  */
  if (!c_parser_require (parser, CPP_CLOSE_SQUARE,

How to fix it in C++?  In gcc/cp/parser.c:cp_parser_omp_var_list_no_open
similar to the C fix, or in gcc/cp/semantics.c:finish_omp_clauses as done
for PR51360?  I guess the latter is required for C++ templates?  This I
can't currently test due to
.


I have not yet tested whether such an issue might also exist for Fortran.


Grüße,
 Thomas


pgpNFODfwTtiL.pgp
Description: PGP signature

RE: [PATCH][MIPS] Fix ICE in bitmap routines with LRA and inline assembly language

[Matthew Fortune]

> The patch is ok to commit.  I think I made a typo as other analogous
> code contains '|='.
> 
> Thanks for fixing this, Robert.

The LRA part of this is committed as r215119.

Eric: Is the test OK to commit for MIPS? I suggest removing the
dg-skip-if as the test is for successful compilation, not inspecting
the generated code.

Thanks,
Matthew

> 
> >
> > 2014-09-09  Robert Suchanek  
> >
> > gcc/testsuite/
> > * gcc.target/mips/20140909.c: New test.

> > diff --git a/gcc/testsuite/gcc.target/mips/20140909.c
> b/gcc/testsuite/gcc.target/mips/20140909.c
> > new file mode 100644
> > index 000..dbdfb30
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/mips/20140909.c
> > @@ -0,0 +1,20 @@
> > +/* { dg-do compile } */
> > +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
> > +
> > +NOMIPS16 int NoBarrier_AtomicIncrement(volatile int* ptr, int
> increment) {
> > +  int temp, temp2;
> > +  __asm__ __volatile__(".set push\n"
> > +   ".set noreorder\n"
> > +   "1:\n"
> > +   "ll %0, 0(%3)\n"
> > +   "addu %1, %0, %2\n"
> > +   "sc %1, 0(%3)\n"
> > +   "beqz %1, 1b\n"
> > +   "addu %1, %0, %2\n"
> > +   ".set pop\n"
> > +   : "=&r" (temp), "=&r" (temp2)
> > +   : "Ir" (increment), "r" (ptr)
> > +   : "memory");
> > +
> > +  return temp2;
> > +}
> >

Re: [PATCH 4/5] recog_memoized works on an rtx_insn *

[Andreas Schwab]

Tested on m68k-suse-linux, installed as obvious.

Andreas.

* coretypes.h (struct _dont_use_rtx_insn_here_, rtx_insn)
[USED_FOR_TARGET]: Define.

diff --git a/gcc/coretypes.h b/gcc/coretypes.h
index 9951f10..c850ff4 100644
--- a/gcc/coretypes.h
+++ b/gcc/coretypes.h
@@ -199,11 +199,13 @@ namespace gcc {
 
 struct _dont_use_rtx_here_;
 struct _dont_use_rtvec_here_;
+struct _dont_use_rtx_insn_here_;
 union _dont_use_tree_here_;
 #define rtx struct _dont_use_rtx_here_ *
 #define const_rtx struct _dont_use_rtx_here_ *
 #define rtvec struct _dont_use_rtvec_here *
 #define const_rtvec struct _dont_use_rtvec_here *
+#define rtx_insn struct _dont_use_rtx_insn_here_
 #define tree union _dont_use_tree_here_ *
 #define const_tree union _dont_use_tree_here_ *
 
-- 
2.1.0


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

[PATCH] doc/install.texi: add documentation for --disable-libsanitizer

[Markus Trippelsdorf]

This patch adds an item for --disable-libsanitizer to the configuration
documentation. 
The option is especially useful during bisection, because it reduces
build time a lot.

Ok for trunk and 4.9 branch?

Thanks.

2014-09-10  Markus Trippelsdorf  

* doc/install.texi (Options specification): add 
--disable-libsanitizer item.

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 31b8c8bf39df..d511edf34b1a 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1451,6 +1451,10 @@ be built.  This can be useful for debugging, or for 
compatibility with
 previous Ada build procedures, when it was required to explicitly
 do a @samp{make -C gcc gnatlib_and_tools}.
 
+@item --disable-libsanitizer
+Specify that the run-time libraries for the various sanitizers should
+not be built.
+
 @item --disable-libssp
 Specify that the run-time libraries for stack smashing protection
 should not be built.
-- 
Markus

[PATCH][match-and-simplify] More flexible 'for', polish match-builtins.pd

[Richard Biener]

This completes match-builtins.pd by handling all builtin variants
in all present patterns.  That requires a little more flexibility
in the 'for' handling to support for example

 /* Optimize sqrt(expN(x)) = expN(x*0.5).  */
 (for expfn (BUILT_IN_EXP10F BUILT_IN_EXP10 BUILT_IN_EXP10L
 BUILT_IN_POW10F BUILT_IN_POW10 BUILT_IN_POW10L
 BUILT_IN_EXPF BUILT_IN_EXP BUILT_IN_EXPL
 BUILT_IN_EXP2F BUILT_IN_EXP2 BUILT_IN_EXP2L)
  SQRT (BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL)
  (simplify
   (SQRT (expfn @0))
   (expfn (mult @0 { build_real (type, dconsthalf); }

without having to repeat the SQRT substitutions four times
to match the expfn substitution length.  Now we just repeat
the substitution vector as needed (but require all lengths
to be a multiple of the smallest one, just as a sanity check).

The patch also fixes the cabs() patterns and completes them
from fold_builtin_cabs.  Similarly it fixes the x * pow(x, c) -> pow (x, 
c+1) pattern to match that from fold-const.c but in addition requires
-fno-math-errno (errno differences can occur - this seems to be
a common issue with all math builtin foldings that are just
conditionalized on flag_unsafe_math_optimizations...).

Committed.

Richard.

2014-09-10  Richard Biener  

* genmatch.c (parse_for): Allow more flexible replacement counts.
* match-builtins.pd: Fix initial patterns and complete them
from the source functions.  Properly handle all builtin variants.

Index: gcc/genmatch.c
===
--- gcc/genmatch.c  (revision 215057)
+++ gcc/genmatch.c  (working copy)
@@ -2414,7 +2414,7 @@ parse_for (cpp_reader *r, source_locatio
   vec user_ids = vNULL;
   vec< vec > opers_vec = vNULL;
   const cpp_token *token;
-  unsigned n_opers = 0;
+  unsigned min_n_opers = 0, max_n_opers = 0;
 
   while (1)
 {
@@ -2445,13 +2445,29 @@ parse_for (cpp_reader *r, source_locatio
  
  opers.safe_push (oper);
}
+  token = expect (r, CPP_CLOSE_PAREN);
+  if (opers.length () == 0)
+   fatal_at (token, "A user-defined identifier must have at least one 
substitution");
+  if (opers_vec.length () == 0)
+   {
+ min_n_opers = opers.length ();
+ max_n_opers = opers.length ();
+   }
+  else
+   {
+ if (opers.length () % min_n_opers != 0
+ && min_n_opers % opers.length () != 0)
+   fatal_at (token, "All user-defined identifiers must have a "
+ "multiple number of operator substitutions of the "
+ "smallest number of substitutions");
+ if (opers.length () < min_n_opers)
+   min_n_opers = opers.length ();
+ else if (opers.length () > max_n_opers)
+   max_n_opers = opers.length ();
+   }
+
   opers_vec.safe_push (opers);
-  if (n_opers == 0)
-   n_opers = opers.length ();
-  else if (n_opers != opers.length ())
-   fatal_at (token, "All user-defined identifiers must have same number of 
operator substitutions");
-  eat_token (r, CPP_CLOSE_PAREN);
-}
+}
 
   if (user_ids.length () == 0)
 fatal_at (token, "for requires at least one user-defined identifier");
@@ -2474,12 +2490,8 @@ parse_for (cpp_reader *r, source_locatio
 {
   simplify *s = for_simplifiers[ix];
 
-  for (unsigned j = 0; j < n_opers; ++j)
+  for (unsigned j = 0; j < max_n_opers; ++j)
{
- vec opers = vNULL;
- for (unsigned i = 0; i < opers_vec.length (); ++i)
-   opers.safe_push (opers_vec[i][j]);
- 
  operand *match_op = s->match;
  operand *result_op = s->result;
  vec ifexpr_vec = vNULL;
@@ -2489,16 +2501,17 @@ parse_for (cpp_reader *r, source_locatio
 
  for (unsigned i = 0; i < n_ids; ++i)
{
- match_op = replace_id (match_op, user_ids[i], opers[i]);
- result_op = replace_id (result_op, user_ids[i], opers[i]);
+ const char *oper = opers_vec[i][j % opers_vec[i].length ()];
+ match_op = replace_id (match_op, user_ids[i], oper);
+ result_op = replace_id (result_op, user_ids[i], oper);
 
  for (unsigned k = 0; k < s->ifexpr_vec.length (); ++k)
-   ifexpr_vec[k].cexpr = replace_id (ifexpr_vec[k].cexpr, 
user_ids[i], opers[i]);
+   ifexpr_vec[k].cexpr = replace_id (ifexpr_vec[k].cexpr, 
user_ids[i], oper);
 
}
-   simplify *ns = new simplify (s->name, match_op, s->match_location,
-result_op, s->result_location, 
ifexpr_vec);
-   simplifiers.safe_push (ns);
+ simplify *ns = new simplify (s->name, match_op, s->match_location,
+  result_op, s->result_location, 
ifexpr_vec);
+ simplifiers.safe_push (ns);
}
 }
 } 
Index: gcc/match-builtin.pd
=

[wwwdocs] Mention Cilk Plus support

[Zamyatin, Igor]

Hi!

Following change mentions that now all Cilk Plus features added to GCC

Index: htdocs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.936
diff -p -r1.936 index.html
*** htdocs/index.html   14 Aug 2014 09:04:23 -  1.936
--- htdocs/index.html   10 Sep 2014 12:04:19 -
*** mission statement.
*** 52,57 
--- 52,61 

  

+ Complete support for http://cilk.org";>Cilk Plus 
features was added to GCC
+ [2014-09-02]
+ Contributed by Jakub Jelinek, Iyer Balaji and Igor Zamyatin.
+
  New GCC version numbering scheme announced
  [2014-08-13]
  


Pre-approved by Gerald

Thanks,
Igor

[PING][PATCH] Asan optimization for aligned accesses.

[Marat Zakirov]

On 09/02/2014 07:09 PM, Marat Zakirov wrote:

Hi all!

Here's a simple optimization patch for Asan. It stores alignment 
information into ASAN_CHECK which is then extracted by sanopt to 
reduce number of "and 0x7" instructions for sufficiently aligned 
accesses. I checked it on linux kernel by comparing results of 
objdump -d -j .text vmlinux | grep "and.*0x7," for optimized and 
regular cases. It eliminates 12% of and 0x7's.


No regressions. Sanitized GCC was successfully Asan-bootstrapped. No 
false positives were found in kernel.


--Marat



gcc/ChangeLog:

2014-09-02  Marat Zakirov  

	* asan.c (build_check_stmt): Alignment arg was added.
	(asan_expand_check_ifn): Optimization for alignment >= 8.

gcc/testsuite/ChangeLog:

2014-09-02  Marat Zakirov  

	* c-c++-common/asan/red-align-1.c: New test.
	* c-c++-common/asan/red-align-2.c: New test.

diff --git a/gcc/asan.c b/gcc/asan.c
index 58e7719..aed5ede 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1639,9 +1639,11 @@ build_check_stmt (location_t loc, tree base, tree len,
   if (end_instrumented)
 flags |= ASAN_CHECK_END_INSTRUMENTED;
 
-  g = gimple_build_call_internal (IFN_ASAN_CHECK, 3,
+  g = gimple_build_call_internal (IFN_ASAN_CHECK, 4,
   build_int_cst (integer_type_node, flags),
-  base, len);
+  base, len,
+  build_int_cst (integer_type_node,
+		 align/BITS_PER_UNIT));
   gimple_set_location (g, loc);
   if (before_p)
 gsi_insert_before (&gsi, g, GSI_SAME_STMT);
@@ -2434,6 +2436,7 @@ asan_expand_check_ifn (gimple_stmt_iterator *iter, bool use_calls)
 
   tree base = gimple_call_arg (g, 1);
   tree len = gimple_call_arg (g, 2);
+  HOST_WIDE_INT align = tree_to_shwi (gimple_call_arg (g, 3));
 
   HOST_WIDE_INT size_in_bytes
 = is_scalar_access && tree_fits_shwi_p (len) ? tree_to_shwi (len) : -1;
@@ -2547,7 +2550,10 @@ asan_expand_check_ifn (gimple_stmt_iterator *iter, bool use_calls)
 	  gimple shadow_test = build_assign (NE_EXPR, shadow, 0);
 	  gimple_seq seq = NULL;
 	  gimple_seq_add_stmt (&seq, shadow_test);
-	  gimple_seq_add_stmt (&seq, build_assign (BIT_AND_EXPR, base_addr, 7));
+	  /* Aligned (>= 8 bytes) access do not need & 7.  */
+	  if (align < 8)
+	gimple_seq_add_stmt (&seq, build_assign (BIT_AND_EXPR,
+		 base_addr, 7));
 	  gimple_seq_add_stmt (&seq, build_type_cast (shadow_type,
 		  gimple_seq_last (seq)));
 	  if (real_size_in_bytes > 1)
diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
index 7ae60f3..54ade9f 100644
--- a/gcc/internal-fn.def
+++ b/gcc/internal-fn.def
@@ -55,4 +55,4 @@ DEF_INTERNAL_FN (UBSAN_CHECK_SUB, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (UBSAN_CHECK_MUL, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
 DEF_INTERNAL_FN (ABNORMAL_DISPATCHER, ECF_NORETURN, NULL)
 DEF_INTERNAL_FN (BUILTIN_EXPECT, ECF_CONST | ECF_LEAF | ECF_NOTHROW, NULL)
-DEF_INTERNAL_FN (ASAN_CHECK, ECF_TM_PURE | ECF_LEAF | ECF_NOTHROW, ".W..")
+DEF_INTERNAL_FN (ASAN_CHECK, ECF_TM_PURE | ECF_LEAF | ECF_NOTHROW, ".W...")
diff --git a/gcc/testsuite/c-c++-common/asan/red-align-1.c b/gcc/testsuite/c-c++-common/asan/red-align-1.c
new file mode 100644
index 000..1edb3a2
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/red-align-1.c
@@ -0,0 +1,20 @@
+/* This tests aligment propagation to structure elem and
+   abcense of redudant & 7.  */
+
+/* { dg-options "-fdump-tree-sanopt" } */
+/* { dg-do compile } */
+/* { dg-skip-if "" { *-*-* } { "-flto" } { "" } } */
+
+struct st {
+  int a;
+  int b;
+  int c;
+} __attribute__((aligned(16)));
+
+int foo (struct st * s_p)
+{
+  return s_p->a;
+}
+
+/* { dg-final { scan-tree-dump-times "& 7" 0 "sanopt" } } */
+/* { dg-final { cleanup-tree-dump "sanopt" } } */
diff --git a/gcc/testsuite/c-c++-common/asan/red-align-2.c b/gcc/testsuite/c-c++-common/asan/red-align-2.c
new file mode 100644
index 000..161fe3c
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/red-align-2.c
@@ -0,0 +1,20 @@
+/* This tests aligment propagation to structure elem and
+   abcense of redudant & 7.  */
+
+/* { dg-options "-fdump-tree-sanopt" } */
+/* { dg-do compile } */
+/* { dg-skip-if "" { *-*-* } { "-flto" } { "" } } */
+
+struct st {
+  int a;
+  int b;
+  int c;
+} __attribute__((aligned(16)));
+
+int foo (struct st * s_p)
+{
+  return s_p->b;
+}
+
+/* { dg-final { scan-tree-dump-times "& 7" 1 "sanopt" } } */
+/* { dg-final { cleanup-tree-dump "sanopt" } } */

[PATCH i386 AVX512] [34/n] AVX-512. Extend vpermvar insn patterns.

[Kirill Yukhin]

Hello,
patch in the bottom extends PERMVAR based patterns.

Hello,

Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.

Is it ok for trunk?

gcc/
* config/i386/sse.md
(define_mode_attr avx2_avx512): Rename from avx2_avx512bw.
(define_mode_iterator VI48F_256_512): Extend to AVX-512VL.
(define_insn "_permvar"): Rename from
"_permvar".
(define_insn "_permvar"): New.
(define_insn "_ashrv" with
VI48_AVX512F_AVX512VL mode iterator): Rename from
"_ashrv".
(define_insn "_ashrv" with
VI2_AVX512VL mode iterator): Ditto.
(define_insn "_v" with
VI48_AVX512F mode iterator): Rename from
"_v".
(define_insn "_v" with
VI2_AVX512VL mode iterator): Rename from
"_v".

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 42f6f18..91ec8fd 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -449,7 +449,7 @@
(V8SF "avx2") (V16SF "avx512f")
(V4DF "avx2") (V8DF "avx512f")])
 
-(define_mode_attr avx2_avx512bw
+(define_mode_attr avx2_avx512
   [(V4SI "avx2") (V8SI "avx2") (V16SI "avx512f")
(V2DI "avx2") (V4DI "avx2") (V8DI "avx512f")
(V4SF "avx2") (V8SF "avx2") (V16SF "avx512f")
@@ -515,7 +515,8 @@
 (define_mode_iterator VI48F_256_512
   [V8SI V8SF
   (V16SI "TARGET_AVX512F") (V16SF "TARGET_AVX512F")
-  (V8DI  "TARGET_AVX512F") (V8DF  "TARGET_AVX512F")])
+  (V8DI  "TARGET_AVX512F") (V8DF  "TARGET_AVX512F")
+  (V4DI  "TARGET_AVX512VL") (V4DF  "TARGET_AVX512VL")])
 (define_mode_iterator VI48F_512 [V16SI V16SF V8DI V8DF])
 (define_mode_iterator VI48F
   [V16SI V16SF V8DI V8DF
@@ -15202,7 +15203,7 @@
(set_attr "prefix" "vex")
(set_attr "mode" "")])
 
-(define_insn "_permvar"
+(define_insn "_permvar"
   [(set (match_operand:VI48F_256_512 0 "register_operand" "=v")
(unspec:VI48F_256_512
  [(match_operand:VI48F_256_512 1 "nonimmediate_operand" "vm")
@@ -15214,6 +15215,18 @@
(set_attr "prefix" "")
(set_attr "mode" "")])
 
+(define_insn "_permvar"
+  [(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
+   (unspec:VI2_AVX512VL
+ [(match_operand:VI2_AVX512VL 1 "nonimmediate_operand" "vm")
+  (match_operand: 2 "register_operand" "v")]
+ UNSPEC_VPERMVAR))]
+  "TARGET_AVX512BW && "
+  "vperm\t{%1, %2, %0|%0, %2, %1}"
+  [(set_attr "type" "sselog")
+   (set_attr "prefix" "")
+   (set_attr "mode" "")])
+
 (define_expand "_perm"
   [(match_operand:VI8F_256_512 0 "register_operand")
(match_operand:VI8F_256_512 1 "nonimmediate_operand")
@@ -16171,7 +16184,7 @@
   DONE;
 })
 
-(define_insn "_ashrv"
+(define_insn "_ashrv"
   [(set (match_operand:VI48_AVX512F_AVX512VL 0 "register_operand" "=v")
(ashiftrt:VI48_AVX512F_AVX512VL
  (match_operand:VI48_AVX512F_AVX512VL 1 "register_operand" "v")
@@ -16182,7 +16195,7 @@
(set_attr "prefix" "maybe_evex")
(set_attr "mode" "")])
 
-(define_insn "_ashrv"
+(define_insn "_ashrv"
   [(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
(ashiftrt:VI2_AVX512VL
  (match_operand:VI2_AVX512VL 1 "register_operand" "v")
@@ -16193,7 +16206,7 @@
(set_attr "prefix" "maybe_evex")
(set_attr "mode" "")])
 
-(define_insn "_v"
+(define_insn "_v"
   [(set (match_operand:VI48_AVX512F 0 "register_operand" "=v")
(any_lshift:VI48_AVX512F
  (match_operand:VI48_AVX512F 1 "register_operand" "v")
@@ -16204,7 +16217,7 @@
(set_attr "prefix" "maybe_evex")
(set_attr "mode" "")])
 
-(define_insn "_v"
+(define_insn "_v"
   [(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
(any_lshift:VI2_AVX512VL
  (match_operand:VI2_AVX512VL 1 "register_operand" "v")

Re: [PATCH, c++ testsuite]: Improve g++.dg/abi/mangle33.C scan-asm pattern

[Mike Stump]

[ originally sent off list ]

>> I filed:
>> 
>>  http://core.tcl.tk/tcl/tktview/267b7e2334ee2e9de34c4b00d6e72e2f1997085f

> Slightly more than a year, but this is your wake-up call.
> 
> The referred tcl bug is fixed with 8.6.1. This version is able to
> finish gcc testsuite without issues.

Thanks.

2014-09-10  Mike Stump  

* doc/install.texi (Prerequisites): Note Tcl 8.6 bug fixed in
8.6.1.

Index: install.texi
===
--- install.texi(revision 214981)
+++ install.texi(working copy)
@@ -451,7 +451,7 @@ Necessary to run the GCC testsuite; see 
 details.  Tcl 8.6 has a known regression in RE pattern handling that
 make parts of the testsuite fail.  See
 @uref{http://core.tcl.tk/tcl/tktview/267b7e2334ee2e9de34c4b00d6e72e2f1997085f}
-for more information.
+for more information.  This bug has been fixed in 8.6.1.
 
 @item autogen version 5.5.4 (or later) and
 @itemx guile version 1.4.1 (or later)

Re: PR debug/60655, debug loc expressions

[Maciej W. Rozycki]

On Tue, 9 Sep 2014, Alan Modra wrote:

> This cures PR60655 on PowerPC by passing the horrible debug_loc
> expressions we have through simplify_rtx.  Not only do we get
>   reg10 + &.LANCHOR0 + const(0x14f - &.LANCHOR0) and
>   reg10 + &modulus + const(~&d_data),
> the two expressions that cause the PR due to (CONST (MINUS ..)) and
> (CONST (NOT ..)), but also things like
>~reg5 - reg31 + reg5 + reg10 + &modulus
> where "~reg5 + reg5" is an inefficient way to write "-1".
> 
> It turns out that merely passing these expression through simplify_rtx
> isn't enough.  Some tweaking is necessary to make (CONST (NOT ..)) and
> (CONST (MINUS ..)) recognised by simplify_plus_minus, and even after
> doing that, the two reg5 terms are not cancelled.
> 
> The reg5 case starts off with the simplify_plus_minus sorted ops array
> effectively containing the expression
> -reg31 + reg10 + reg5 + -reg5 + &modulus + -1
> 
> The first combination tried is &modulus + -1, which is rejected to
> prevent recursion.  The next combination tried is -reg5 + -1, which is
> simlified to ~reg5.  Well, that is a valid simplification, but the
> trouble is that this prevents "reg5 + -reg5" being simplified to 0.
> What's more, "&modulus + -1" is no more expensive than "&modulus",
> since they are both emitted as an address field with a symbol+addend
> relocation.  For that reason, I believe we should not consider
> combining a const_int with any other term after finding that it can be
> combined with a symbol_ref or other similar term.
> 
> Bootstrapped and regression tested powerpc64-linux and x86_64-linux.
> I measured before/after bootstrap times on x86_64-linux because I was
> concerned about the extra simplify_rtx calls, and was pleasantly
> surprised to see a 0.23% improvement in bootstrap time.  (Which of
> course is likely just noise.)  OK to apply?

 Thanks for your work on this issue, I have tested your change with my 
usual powerpc-gnu-linux multilibs with the old and new result for
gcc.c-torture/compile/pr60655-2.c noted on the right:

-mcpu=603e  FAIL -> PASS
-mcpu=603e -msoft-float FAIL -> PASS
-mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe  FAIL -> PASS
-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe  FAIL -> PASS
-mcpu=7400 -maltivec -mabi=altivec  FAIL -> PASS
-mcpu=e6500 -maltivec -mabi=altivec FAIL -> PASS
-mcpu=e5500 -m64PASS -> PASS
-mcpu=e6500 -m64 -maltivec -mabi=altivecPASS -> PASS

-- please note that the test case used to pass for 64-bit multilibs even 
before your fix so unless your powerpc64-linux configuration includes 
32-bit multilibs as well, it does not really provide suitable coverage.

 Once your fix has been put in place the old ARM hack made for 4.9, that 
my original proposal has been based on:

2014-04-10  Ramana Radhakrishnan  

PR debug/60655
* config/arm/arm.c (TARGET_CONST_NOT_OK_FOR_DEBUG_P): Define
(arm_const_not_ok_for_debug_p): Reject MINUS with SYM_REF's
ameliorating the cases where it can be.

can I suppose be reverted too.

  Maciej

[PATCH i386 AVX512] [35/n] Add vperm[it]2 insns support.

[Kirill Yukhin]

Hello,
Patch in the bottom extends perm[t|i] patterns.

Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.

Is it ok for trunk?

gcc/
* config/i386/sse.md
(define_expand "_vpermi2var3_maskz" with VI48F
mode iterator): Rename from
"avx512f_vpermi2var3_maskz" and update mode iterator.
(define_expand "_vpermi2var3_maskz" with
VI2_AVX512VL mode iterator): New.
(define_insn "_vpermi2var3" with
VI48F): Renamefrom "avx512f_vpermi2var3"
and update mode iterator.
(define_insn "_vpermi2var3" with
VI2_AVX512VL): New.
(define_insn "_vpermi2var3_mask" with VI48F
mode iterator): Rename from "avx512f_vpermi2var3_mask"
and update mode iterator.
(define_insn "_vpermi2var3_mask" with VI2_AVX512VL
mode iterator): New.
(define_expand "_vpermt2var3_maskz" with VI48F
mode iterator): Rename from "avx512f_vpermt2var3_maskz" and
update mode iterator.
(define_expand "_vpermt2var3_maskz" with VI2_AVX512VL
mode iterator): New.
(define_insn "_vpermt2var3" with VI48F
mode iterator): Rename from "avx512f_vpermt2var3"
and update mode iterator.
(define_insn "_vpermt2var3" with
VI2_AVX512VL mode iterator): New.
(define_insn "_vpermt2var3_mask" with VI48F mode
iterator): Rename from "avx512f_vpermt2var3_mask" and update mode
iterator.
(define_insn "_vpermt2var3_mask" with VI2_AVX512VL
mode iterator): New.

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 91ec8fd..e182582 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -15662,26 +15662,40 @@
(set_attr "prefix" "")
(set_attr "mode" "")])
 
-(define_expand "avx512f_vpermi2var3_maskz"
-  [(match_operand:VI48F_512 0 "register_operand" "=v")
-   (match_operand:VI48F_512 1 "register_operand" "v")
+(define_expand "_vpermi2var3_maskz"
+  [(match_operand:VI48F 0 "register_operand" "=v")
+   (match_operand:VI48F 1 "register_operand" "v")
(match_operand: 2 "register_operand" "0")
-   (match_operand:VI48F_512 3 "nonimmediate_operand" "vm")
+   (match_operand:VI48F 3 "nonimmediate_operand" "vm")
(match_operand: 4 "register_operand" "Yk")]
   "TARGET_AVX512F"
 {
-  emit_insn (gen_avx512f_vpermi2var3_maskz_1 (
+  emit_insn (gen__vpermi2var3_maskz_1 (
operands[0], operands[1], operands[2], operands[3],
CONST0_RTX (mode), operands[4]));
   DONE;
 })
 
-(define_insn "avx512f_vpermi2var3"
-  [(set (match_operand:VI48F_512 0 "register_operand" "=v")
-   (unspec:VI48F_512
- [(match_operand:VI48F_512 1 "register_operand" "v")
+(define_expand "_vpermi2var3_maskz"
+  [(match_operand:VI2_AVX512VL 0 "register_operand" "=v")
+   (match_operand:VI2_AVX512VL 1 "register_operand" "v")
+   (match_operand: 2 "register_operand" "0")
+   (match_operand:VI2_AVX512VL 3 "nonimmediate_operand" "vm")
+   (match_operand: 4 "register_operand" "Yk")]
+  "TARGET_AVX512BW"
+{
+  emit_insn (gen__vpermi2var3_maskz_1 (
+   operands[0], operands[1], operands[2], operands[3],
+   CONST0_RTX (mode), operands[4]));
+  DONE;
+})
+
+(define_insn "_vpermi2var3"
+  [(set (match_operand:VI48F 0 "register_operand" "=v")
+   (unspec:VI48F
+ [(match_operand:VI48F 1 "register_operand" "v")
   (match_operand: 2 "register_operand" "0")
-  (match_operand:VI48F_512 3 "nonimmediate_operand" "vm")]
+  (match_operand:VI48F 3 "nonimmediate_operand" "vm")]
  UNSPEC_VPERMI2))]
   "TARGET_AVX512F"
   "vpermi2\t{%3, %1, %0|%0, %1, %3}"
@@ -15689,13 +15703,26 @@
(set_attr "prefix" "evex")
(set_attr "mode" "")])
 
-(define_insn "avx512f_vpermi2var3_mask"
-  [(set (match_operand:VI48F_512 0 "register_operand" "=v")
-   (vec_merge:VI48F_512
- (unspec:VI48F_512
-   [(match_operand:VI48F_512 1 "register_operand" "v")
+(define_insn "_vpermi2var3"
+  [(set (match_operand:VI2_AVX512VL 0 "register_operand" "=v")
+   (unspec:VI2_AVX512VL
+ [(match_operand:VI2_AVX512VL 1 "register_operand" "v")
+  (match_operand: 2 "register_operand" "0")
+  (match_operand:VI2_AVX512VL 3 "nonimmediate_operand" "vm")]
+ UNSPEC_VPERMI2))]
+  "TARGET_AVX512BW"
+  "vpermi2\t{%3, %1, %0|%0, %1, %3}"
+  [(set_attr "type" "sselog")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
+(define_insn "_vpermi2var3_mask"
+  [(set (match_operand:VI48F 0 "register_operand" "=v")
+   (vec_merge:VI48F
+ (unspec:VI48F
+   [(match_operand:VI48F 1 "register_operand" "v")
(match_operand: 2 "register_operand" "0")
-   (match_operand:VI48F_512 3 "nonimmediate_operand" "vm")]
+   (match_operand:VI48F 3 "nonimmediate_operand" "vm")]
UNSPEC_VPERMI2_MASK)
  (match_dup 0)
  (match_operand: 4 "register_operand" "Yk")))]
@@ -15705,26 +15732,56 @@
(set_attr "

Re: PR debug/60655, debug loc expressions

[Alan Modra]

On Wed, Sep 10, 2014 at 01:43:22PM +0100, Maciej W. Rozycki wrote:
>  Thanks for your work on this issue, I have tested your change with my 
> usual powerpc-gnu-linux multilibs with the old and new result for
> gcc.c-torture/compile/pr60655-2.c noted on the right:
> 
> -mcpu=603eFAIL -> PASS
> -mcpu=603e -msoft-float   FAIL -> PASS
> -mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=speFAIL -> PASS
> -mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=speFAIL -> PASS
> -mcpu=7400 -maltivec -mabi=altivecFAIL -> PASS
> -mcpu=e6500 -maltivec -mabi=altivec   FAIL -> PASS
> -mcpu=e5500 -m64  PASS -> PASS
> -mcpu=e6500 -m64 -maltivec -mabi=altivec  PASS -> PASS
> 
> -- please note that the test case used to pass for 64-bit multilibs even 
> before your fix so unless your powerpc64-linux configuration includes 
> 32-bit multilibs as well, it does not really provide suitable coverage.

I always build powerpc64-linux with --enable-targets=powerpc-linux and
regression test with RUNTESTFLAGS=--target_board=unix/'{-m32,-m64}',
so my "bootstrapped and regression tested powerpc64-linux" claim
includes a -m32 regression test too.  Not quite as comprehensive a
test as you've done (thanks!), but I did see the FAIL->PASS for -m32.

-- 
Alan Modra
Australia Development Lab, IBM

[PATCH i386 AVX512] [36/n] Extend gather insn patterns.

[Kirill Yukhin]

Hello,
Patch in the bottom extends gather instructions support.

Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.

Is it ok for trunk?

gcc/
* config/i386/sse.md
(define_expand "_gathersi"): Rename from
"avx512f_gathersi".
(define_insn "*avx512f_gathersi"): Use VI48F.
(define_insn "*avx512f_gathersi_2"): Ditto.
(define_expand "_gatherdi"): Rename from
"avx512f_gatherdi".
(define_insn "*avx512f_gatherdi"): Use VI48F.
(define_insn "*avx512f_gatherdi_2"): Use VI48F, add 128/256-bit
wide versions.
(define_expand "_scattersi"): Rename from
"avx512f_scattersi".
(define_insn "*avx512f_scattersi"): Use VI48F.
(define_expand "_scatterdi"): Rename from
"avx512f_scatterdi".
(define_insn "*avx512f_scatterdi"): Use VI48F.

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index e182582..40b8f83 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -16650,10 +16650,10 @@
(set_attr "prefix" "vex")
(set_attr "mode" "")])
 
-(define_expand "avx512f_gathersi"
-  [(parallel [(set (match_operand:VI48F_512 0 "register_operand")
-  (unspec:VI48F_512
-[(match_operand:VI48F_512 1 "register_operand")
+(define_expand "_gathersi"
+  [(parallel [(set (match_operand:VI48F 0 "register_operand")
+  (unspec:VI48F
+[(match_operand:VI48F 1 "register_operand")
  (match_operand: 4 "register_operand")
  (mem:
(match_par_dup 6
@@ -16670,9 +16670,9 @@
 })
 
 (define_insn "*avx512f_gathersi"
-  [(set (match_operand:VI48F_512 0 "register_operand" "=&v")
-   (unspec:VI48F_512
- [(match_operand:VI48F_512 1 "register_operand" "0")
+  [(set (match_operand:VI48F 0 "register_operand" "=&v")
+   (unspec:VI48F
+ [(match_operand:VI48F 1 "register_operand" "0")
   (match_operand: 7 "register_operand" "2")
   (match_operator: 6 "vsib_mem_operator"
 [(unspec:P
@@ -16689,8 +16689,8 @@
(set_attr "mode" "")])
 
 (define_insn "*avx512f_gathersi_2"
-  [(set (match_operand:VI48F_512 0 "register_operand" "=&v")
-   (unspec:VI48F_512
+  [(set (match_operand:VI48F 0 "register_operand" "=&v")
+   (unspec:VI48F
  [(pc)
   (match_operand: 6 "register_operand" "1")
   (match_operator: 5 "vsib_mem_operator"
@@ -16708,9 +16708,9 @@
(set_attr "mode" "")])
 
 
-(define_expand "avx512f_gatherdi"
-  [(parallel [(set (match_operand:VI48F_512 0 "register_operand")
-  (unspec:VI48F_512
+(define_expand "_gatherdi"
+  [(parallel [(set (match_operand:VI48F 0 "register_operand")
+  (unspec:VI48F
 [(match_operand: 1 "register_operand")
  (match_operand:QI 4 "register_operand")
  (mem:
@@ -16728,8 +16728,8 @@
 })
 
 (define_insn "*avx512f_gatherdi"
-  [(set (match_operand:VI48F_512 0 "register_operand" "=&v")
-   (unspec:VI48F_512
+  [(set (match_operand:VI48F 0 "register_operand" "=&v")
+   (unspec:VI48F
  [(match_operand: 1 "register_operand" "0")
   (match_operand:QI 7 "register_operand" "2")
   (match_operator: 6 "vsib_mem_operator"
@@ -16747,8 +16747,8 @@
(set_attr "mode" "")])
 
 (define_insn "*avx512f_gatherdi_2"
-  [(set (match_operand:VI48F_512 0 "register_operand" "=&v")
-   (unspec:VI48F_512
+  [(set (match_operand:VI48F 0 "register_operand" "=&v")
+   (unspec:VI48F
  [(pc)
   (match_operand:QI 6 "register_operand" "1")
   (match_operator: 5 "vsib_mem_operator"
@@ -16762,22 +16762,27 @@
   "TARGET_AVX512F"
 {
   if (mode != mode)
-return "vgatherq\t{%5, %t0%{%1%}|%t0%{%1%}, 
%g5}";
+{
+  if (GET_MODE_SIZE (mode) != 64)
+   return "vgatherq\t{%5, 
%x0%{%1%}|%t0%{%1%}, %g5}";
+  else
+   return "vgatherq\t{%5, 
%t0%{%1%}|%t0%{%1%}, %g5}";
+}
   return "vgatherq\t{%5, %0%{%1%}|%0%{%1%}, %g5}";
 }
   [(set_attr "type" "ssemov")
(set_attr "prefix" "evex")
(set_attr "mode" "")])
 
-(define_expand "avx512f_scattersi"
-  [(parallel [(set (mem:VI48F_512
+(define_expand "_scattersi"
+  [(parallel [(set (mem:VI48F
 (match_par_dup 5
   [(match_operand 0 "vsib_address_operand")
(match_operand: 2 "register_operand")
(match_operand:SI 4 "const1248_operand")]))
-  (unspec:VI48F_512
+  (unspec:VI48F
 [(match_operand: 1 "register_operand")
- (match_operand:VI48F_512 3 "register_operand")]
+ (match_operand:VI48F 3 "register_operand")]
 UNSPEC_SCATTER))
  (clobber (match_scratch: 6))])]
   "TARGET_AVX512F"
@@ -16788,15 +16793,15 @@
 })
 
 (define_insn "*avx512f_scattersi"
-

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

[Jonathan Wakely]

On 04/09/14 05:56 -0700, Siva Chandra wrote:

On Wed, Sep 3, 2014 at 3:47 PM, Siva Chandra  wrote:

On Wed, Sep 3, 2014 at 3:35 PM, Jonathan Wakely  wrote:

I was waiting to see which version of the patch actually works, so
that users can use the xmethods. There's no point committing the patch
if they aren't installed and can't be used!


Doesn't the latest version of the patch I posted work for you:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02516.html

If not, what errors or missing things do you see?


To clarify, the reason I am asking for errors or missing pieces is
because things work as expected for me with the latest patch; The
xmethods get installed and GDB automatically loads them.


I've committed the v5 patch to trunk now.

It would be nice to address Tom's comment at some future time, so we
only have one entry point in the hook.in file.

Re: [PATCH] RE: gcc parallel make check

[Jakub Jelinek]

On Tue, Sep 09, 2014 at 03:14:08PM +, VandeVondele  Joost wrote:
> Attached is a further revision of the patch, now dealing with check-c++. 
> Roughly 50% speedup here at '-j32' (18m vs 12m). For my setup 
> (--enable-languages=c,c++,fortran) I have now improved all targets called in 
> 'make -j32 -k check'. The latter is now 30% faster (15m vs 20m). Note that 
> there are +- 1m fluctuations in these numbers, easily.
> 
> I currently have no plans to work on other check targets before this patch is 
> committed.
> 
> OK for trunk ?

So, I've tested your patch on a few years old 16way AMD,
--enable-checking=yes and with make check -j1 and make check -j2
(the former doesn't parallelize, the latter does).

First of all, the -j2 testing shows more tests tested in gcc and libstdc++:

=== gcc Summary ===
 
-# of expected passes   108100
+# of expected passes   108130
 # of unexpected failures   175
 # of unexpected successes  33
 # of expected failures 262
...
=== libstdc++ Summary ===
 
-# of expected passes   10133
+# of expected passes   10152

In gcc testsuite the difference seems to be (according to sorted PASS
lines from *.sum files):
+PASS: gcc.target/i386/vect-args.c -m3dnow -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -m3dnow -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -m3dnow -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -m3dnow  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -m3dnow  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -m3dnow  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -mmmx -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -mmmx -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -mmmx -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -mmmx  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -mmmx  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -mmmx  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse2 -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse2 -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse2 -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse2  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse2  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse2  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c -msse  (test for excess errors)
+PASS: gcc.target/i386/vect-args.c  -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c  -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c  -O (test for excess errors)
+PASS: gcc.target/i386/vect-args.c   (test for excess errors)
+PASS: gcc.target/i386/vect-args.c   (test for excess errors)
+PASS: gcc.target/i386/vect-args.c   (test for excess errors)
and in libstdc++:
+PASS: 23_containers/map/modifiers/erase/abi_tag.cc scan-assembler 
_ZNSt3mapIiiSt4lessIiESaISt4pairIKiiEEE5eraseB5cxx11ESt17_Rb_tree_iteratorIS4_E
+PASS: 23_containers/map/modifiers/erase/abi_tag.cc (test for excess errors)
+PASS: 23_containers/multimap/modifiers/erase/abi_tag.cc scan-assembler 
_ZNSt8multimapIiiSt4lessIiESaISt4pairIKiiEEE5eraseB5cxx11ESt17_Rb_tree_iteratorIS4_E
+PASS: 23_containers/multimap/modifiers/erase/abi_tag.cc (test for excess 
errors)
+PASS: 23_containers/multiset/modifiers/erase/abi_tag.cc scan-assembler 
_ZNSt8multisetIiSt4lessIiESaIiEE5eraseB5cxx11ESt23_Rb_tree_const_iteratorIiE
+PASS: 23_containers/multiset/modifiers/erase/abi_tag.cc scan-assembler 
_ZNSt8multisetIiSt4lessIiESaIiEE5eraseB5cxx11ESt23_Rb_tree_const_iteratorIiES5_
+PASS: 23_containers/multiset/modifiers/erase/abi_tag.cc (test for excess 
errors)
+PASS: 23_containers/set/modifiers/erase/abi_tag.cc scan-assembler 
_ZNSt3setIiSt4lessIiESaIiEE5eraseB5cxx11ESt23_Rb_tree_const_iteratorIiE
+PASS: 23_containers/set/modifiers/erase/abi_tag.cc scan-assembler 
_ZNSt3setIiSt4lessIiESaIiEE5eraseB5cxx11ESt23_Rb_tree_const_iteratorIiES5_
+PASS: 23_containers/set/modifiers/erase/abi_tag.cc (test for excess errors)
+PASS: 26_numerics/complex/abi_tag.cc scan-assembler 
_ZNKSt7complexIdE4imagB5cxx11Ev
+PASS: 26_numerics/complex/abi_tag.cc scan-assembler 
_ZNKSt7complexIdE4realB5cxx11Ev
+PASS: 26_numerics/complex/abi_tag.cc scan-assembler 
_ZNKSt7complexI[eg]E4imagB5cxx11Ev
+PASS: 26_numerics/complex/abi_tag.cc scan-assembler 
_ZNKSt7complexI[eg]E4realB5cxx11Ev
+PASS: 26_numerics/complex/abi_tag.cc scan-assembler 
_ZNKSt7complexIfE4imagB5cxx11Ev
+PASS: 26_numerics/complex/abi_tag.cc scan-assembler 
_ZNKSt7complex

Re: PR debug/60655, debug loc expressions

[Maciej W. Rozycki]

On Wed, 10 Sep 2014, Alan Modra wrote:

> I always build powerpc64-linux with --enable-targets=powerpc-linux and
> regression test with RUNTESTFLAGS=--target_board=unix/'{-m32,-m64}',
> so my "bootstrapped and regression tested powerpc64-linux" claim
> includes a -m32 regression test too.  Not quite as comprehensive a
> test as you've done (thanks!), but I did see the FAIL->PASS for -m32.

 OK, good, I just wanted to be sure we're on the same page.  Thanks!

  Maciej

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

[Siva Chandra]

On Wed, Sep 10, 2014 at 6:18 AM, Jonathan Wakely  wrote:
> I've committed the v5 patch to trunk now.

Thanks a lot.

> It would be nice to address Tom's comment at some future time, so we
> only have one entry point in the hook.in file.

I will do it before I add more xmethods.

Thanks,
Siva Chandra

RE: [PATCH] RE: gcc parallel make check

[VandeVondele Joost]

Thanks for testing.

The vect-args.c I explained earlier, and is indeed due to i386.exp hardcoding 
those.

The libstdc++ double counts didn't appear in my testing, but I'll have  a look. 
Note that these patterns are handwritten, so error prone.

The long tests in libstdc++ come from (in timing order, from my machine):
  normal1) \
dirs="`cd $$srcdir; echo e*/*`";; \
  normal2) \
dirs="`cd $$srcdir; echo 28_*/a*`";; \
  normal3) \
dirs="`cd $$srcdir; echo 23_*/[lu]*`";; \
  normal4) \
dirs="`cd $$srcdir; echo 2[459]_*/*`";; \

Re: [wwwdocs] Mention Cilk Plus support

[Gerald Pfeifer]

Hi Igor,

On Wed, 10 Sep 2014, Zamyatin, Igor wrote:
> + Complete support for http://cilk.org";>Cilk Plus 
> features was added to GCC
> + [2014-09-02]
> + Contributed by Jakub Jelinek, Iyer Balaji and Igor Zamyatin.

can you please make this "Cilk Plus support" or "Full Cilk Plus support"
in the title, and then use the current title as the first part of the
more detailed description?  (You can use the latest AVX announcement as
an example.)

Gerald

Re: [PATCH] RE: gcc parallel make check

[Jakub Jelinek]

On Wed, Sep 10, 2014 at 01:57:01PM +, VandeVondele  Joost wrote:
> Thanks for testing.
> 
> The vect-args.c I explained earlier, and is indeed due to i386.exp hardcoding 
> those.

IMHO the best fix for that is following, use the same predicate whether to
run the vect-args.c tests or not as is used for all other tests.

Ok for trunk?

2014-09-10  Jakub Jelinek  

* gcc.target/i386/i386.exp: Only run vect-args.c tests
if runtest_file_p says they should be run.

--- gcc/testsuite/gcc.target/i386/i386.exp.jj   2014-06-10 07:58:09.0 
+0200
+++ gcc/testsuite/gcc.target/i386/i386.exp  2014-09-10 16:09:31.572493879 
+0200
@@ -316,13 +316,16 @@ if ![info exists DEFAULT_CFLAGS] then {
 dg-init
 clearcap-init
 
+global runtests
 # Special case compilation of vect-args.c so we don't have to
 # replicate it 10 times.
-foreach type { "" -mmmx -m3dnow -msse -msse2 } {
-  foreach level { "" -O } {
-set flags "$type $level"
-verbose -log "Testing vect-args, $flags" 1
-dg-test $srcdir/$subdir/vect-args.c $flags ""
+if [runtest_file_p $runtests $srcdir/$subdir/vect-args.c] {
+  foreach type { "" -mmmx -m3dnow -msse -msse2 } {
+foreach level { "" -O } {
+  set flags "$type $level"
+  verbose -log "Testing vect-args, $flags" 1
+  dg-test $srcdir/$subdir/vect-args.c $flags ""
+}
   }
 }
 

Jakub

C++ PATCH to 4.9 for c++/61659 (devirt referencing undefined comdats)

[Jason Merrill]

My change to always set DECL_COMDAT on vague-linkage decls has caused 
various problems on the trunk, so I'm not comfortable applying it to 
4.9.  So this patch does a much more limited version of the same thing: 
only set it on vague-linkage functions that might not be defined, and 
don't set it until after we are done with any front-end semantics that 
might be implied.


Tested x86_64-pc-linux-gnu, applying to 4.9.
commit e26f8f5e9cb8048ccf7183c6d8a27fa38b5b7a62
Author: Jason Merrill 
Date:   Tue Jul 29 17:28:44 2014 -0400

	PR lto/53808
	PR c++/61659
	* decl2.c (note_comdat_fn): New.
	(set_comdat): New.
	(cp_write_global_declarations): Call set_comdat.
	* method.c (implicitly_declare_fn): Call note_comdat_fn.
	* pt.c (tsubst_decl) [FUNCTION_DECL]: Likewise.
	* decl2.c (mark_needed): Mark clones.
	(import_export_decl): Not here.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 0b52dff..99cc7ec 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5352,6 +5352,7 @@ extern tree get_tls_wrapper_fn			(tree);
 extern void mark_needed(tree);
 extern bool decl_needed_p			(tree);
 extern void note_vague_linkage_fn		(tree);
+extern void note_comdat_fn			(tree);
 extern tree build_artificial_parm		(tree, tree);
 extern bool possibly_inlined_p			(tree);
 extern int parm_index   (tree);
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 6c52e53..a2626d4 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -99,6 +99,10 @@ static GTY(()) vec *pending_statics;
may need to emit outline anyway.  */
 static GTY(()) vec *deferred_fns;
 
+/* A list of functions which we might want to set DECL_COMDAT on at EOF.  */
+
+static GTY(()) vec *maybe_comdat_fns;
+
 /* A list of decls that use types with no linkage, which we need to make
sure are defined.  */
 static GTY(()) vec *no_linkage_decls;
@@ -1896,6 +1900,12 @@ mark_needed (tree decl)
 	 definition.  */
   struct cgraph_node *node = cgraph_get_create_node (decl);
   node->forced_by_abi = true;
+
+  /* #pragma interface and -frepo code can call mark_needed for
+  maybe-in-charge 'tors; mark the clones as well.  */
+  tree clone;
+  FOR_EACH_CLONE (clone, decl)
+	mark_needed (clone);
 }
   else if (TREE_CODE (decl) == VAR_DECL)
 {
@@ -2678,17 +2688,7 @@ import_export_decl (tree decl)
 {
   /* The repository indicates that this entity should be defined
 	 here.  Make sure the back end honors that request.  */
-  if (VAR_P (decl))
-	mark_needed (decl);
-  else if (DECL_MAYBE_IN_CHARGE_CONSTRUCTOR_P (decl)
-	   || DECL_MAYBE_IN_CHARGE_DESTRUCTOR_P (decl))
-	{
-	  tree clone;
-	  FOR_EACH_CLONE (clone, decl)
-	mark_needed (clone);
-	}
-  else
-	mark_needed (decl);
+  mark_needed (decl);
   /* Output the definition as an ordinary strong definition.  */
   DECL_EXTERNAL (decl) = 0;
   DECL_INTERFACE_KNOWN (decl) = 1;
@@ -4231,6 +4231,34 @@ dump_tu (void)
 }
 }
 
+/* Much like the above, but not necessarily defined.  4.9 hack for setting
+   DECL_COMDAT on DECL_EXTERNAL functions, along with set_comdat.  */
+
+void
+note_comdat_fn (tree decl)
+{
+  vec_safe_push (maybe_comdat_fns, decl);
+}
+
+/* DECL is a function with vague linkage that was not
+   instantiated/synthesized in this translation unit.  Set DECL_COMDAT for
+   the benefit of can_refer_decl_in_current_unit_p.  */
+
+static void
+set_comdat (tree decl)
+{
+  DECL_COMDAT (decl) = true;
+
+  tree clone;
+  FOR_EACH_CLONE (clone, decl)
+set_comdat (clone);
+
+  if (DECL_VIRTUAL_P (decl))
+for (tree thunk = DECL_THUNKS (decl); thunk;
+	 thunk = DECL_CHAIN (thunk))
+  DECL_COMDAT (thunk) = true;
+}
+
 /* This routine is called at the end of compilation.
Its job is to create all the code needed to initialize and
destroy the global aggregates.  We do the destruction
@@ -4608,6 +4636,10 @@ cp_write_global_declarations (void)
   vtv_build_vtable_verify_fndecl ();
 }
 
+  FOR_EACH_VEC_SAFE_ELT (maybe_comdat_fns, i, decl)
+if (!DECL_COMDAT (decl) && vague_linkage_p (decl))
+  set_comdat (decl);
+
   finalize_compilation_unit ();
 
   if (flag_vtable_verify)
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 11bff7f..b074d74 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1773,6 +1773,7 @@ implicitly_declare_fn (special_function_kind kind, tree type,
   DECL_EXTERNAL (fn) = true;
   DECL_NOT_REALLY_EXTERN (fn) = 1;
   DECL_DECLARED_INLINE_P (fn) = 1;
+  note_comdat_fn (fn);
   gcc_assert (!TREE_USED (fn));
 
   /* Restore PROCESSING_TEMPLATE_DECL.  */
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3296fda..91ff32a 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10677,6 +10677,9 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
 		 the type earlier (template/friend54.C).  */
 	  RETURN (new_r);
 
+	if (!DECL_FRIEND_P (r))
+	  note_comdat_fn (r);
+
 	/* We're not supposed to instantiate default arguments

Re: [Patch ARM v2] Fix PR target/56846

[Jonathan Wakely]

On 10/09/14 15:41 +0800, Tony Wang wrote:

-Original Message-
From: Jonathan Wakely [mailto:jwak...@redhat.com]
Sent: Tuesday, September 09, 2014 6:40 PM
To: Tony Wang
Cc: Ramana Radhakrishnan; gcc-patches; libstd...@gcc.gnu.org
Subject: Re: [Patch ARM v2] Fix PR target/56846

On 09/09/14 17:47 +0800, Tony Wang wrote:
>Hi there,
>
>This is a updated patch to fix pr56846. Bootstrapped on 
x86_64-unknown-linux-gnu and no regression for
>regression test on Linux and a cross regression test on arm-none-eabi.
>
>OK for the trunk?
>
>gcc/libstdc++-v3/ChangeLog:
>2014-09-09   Tony Wang 
>
> PR target/56846
> * libsupc++/eh_personality.cc(PERSONALITY_FUNCTION):
   ^
There should be a space after the file name (look at existing
changelog entries)

OK with that change.


Committed with your comment on trunk, and also tested on 4.9 branch with no 
regression. So is it ok to back
port to 4.9 branch?


I'd at least like to see it working OK on trunk for a while without
regressions, and I don't know the EABI code well enough to be
confident it's safe to backport.

So in this case I'd request approval from one of the Release Managers
and/or ARM maintainers.

[PATCH, committed] insn_extract takes an rtx_insn

[David Malcolm]

The attached trivial patch strengthens the param of the generated
"insn_extract" function, from rtx to rtx_insn *, and thus falls under
the pre-approval granted by Jeff here:
  https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01310.html

Bootstrapped on x86_64-unknown-linux-gnu (Fedora 20), and has been
rebuilt as part of a config-list.mk build for all working configurations
(albeit with other patches for the latter case).

Committed to trunk as r215132
Index: gcc/genextract.c
===
--- gcc/genextract.c	(revision 215131)
+++ gcc/genextract.c	(revision 215132)
@@ -367,7 +367,7 @@
 
   puts ("\
 void\n\
-insn_extract (rtx insn)\n{\n\
+insn_extract (rtx_insn *insn)\n{\n\
   rtx *ro = recog_data.operand;\n\
   rtx **ro_loc = recog_data.operand_loc;\n\
   rtx pat = PATTERN (insn);\n\
Index: gcc/ChangeLog
===
--- gcc/ChangeLog	(revision 215131)
+++ gcc/ChangeLog	(revision 215132)
@@ -1,3 +1,10 @@
+2014-09-10  David Malcolm  
+
+	* genextract.c (print_header): When writing out insn_extract to
+	insn-extract.c, strengthen the param "insn" from rtx to rtx_insn *.
+	* recog.h (insn_extract): Strengthen the param from rtx to
+	rtx_insn *.
+
 2014-09-10  Mike Stump  
 
 	* doc/install.texi (Prerequisites): Note Tcl 8.6 bug fixed in
Index: gcc/recog.h
===
--- gcc/recog.h	(revision 215131)
+++ gcc/recog.h	(revision 215132)
@@ -132,7 +132,7 @@
 #endif
 extern void add_clobbers (rtx, int);
 extern int added_clobbers_hard_reg_p (int);
-extern void insn_extract (rtx);
+extern void insn_extract (rtx_insn *);
 extern void extract_insn (rtx_insn *);
 extern void extract_constrain_insn_cached (rtx_insn *);
 extern void extract_insn_cached (rtx_insn *);

[PATCH, committed] error_for_asm and warning_for_asm take const rtx_insn *

[David Malcolm]

The attached patch strengthens various diagnostic-reporting rtx from rtx
to rtx_insn *, and thus falls under the pre-approval granted by Jeff
here:
  https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01310.html

Bootstrapped on x86_64-unknown-linux-gnu (Fedora 20), and has been
rebuilt as part of a config-list.mk build for all working configurations
(albeit with other patches for the latter case).

Committed to trunk as r215133.

Index: gcc/rtl-error.c
===
--- gcc/rtl-error.c	(revision 215132)
+++ gcc/rtl-error.c	(revision 215133)
@@ -29,12 +29,13 @@
 #include "intl.h"
 #include "diagnostic.h"
 
-static location_t location_for_asm (const_rtx);
-static void diagnostic_for_asm (const_rtx, const char *, va_list *, diagnostic_t) ATTRIBUTE_GCC_DIAG(2,0);
+static location_t location_for_asm (const rtx_insn *);
+static void diagnostic_for_asm (const rtx_insn *, const char *, va_list *,
+diagnostic_t) ATTRIBUTE_GCC_DIAG(2,0);
 
 /* Figure the location of the given INSN.  */
 static location_t
-location_for_asm (const_rtx insn)
+location_for_asm (const rtx_insn *insn)
 {
   rtx body = PATTERN (insn);
   rtx asmop;
@@ -65,7 +66,7 @@
of the insn INSN.  This is used only when INSN is an `asm' with operands,
and each ASM_OPERANDS records its own source file and line.  */
 static void
-diagnostic_for_asm (const_rtx insn, const char *msg, va_list *args_ptr,
+diagnostic_for_asm (const rtx_insn *insn, const char *msg, va_list *args_ptr,
 		diagnostic_t kind)
 {
   diagnostic_info diagnostic;
@@ -76,7 +77,7 @@
 }
 
 void
-error_for_asm (const_rtx insn, const char *gmsgid, ...)
+error_for_asm (const rtx_insn *insn, const char *gmsgid, ...)
 {
   va_list ap;
 
@@ -86,7 +87,7 @@
 }
 
 void
-warning_for_asm (const_rtx insn, const char *gmsgid, ...)
+warning_for_asm (const rtx_insn *insn, const char *gmsgid, ...)
 {
   va_list ap;
 
Index: gcc/rtl-error.h
===
--- gcc/rtl-error.h	(revision 215132)
+++ gcc/rtl-error.h	(revision 215133)
@@ -20,5 +20,7 @@
 #include "rtl.h"
 #include "diagnostic-core.h"
 
-extern void error_for_asm (const_rtx, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);
-extern void warning_for_asm (const_rtx, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);
+extern void error_for_asm (const rtx_insn *, const char *,
+			   ...) ATTRIBUTE_GCC_DIAG(2,3);
+extern void warning_for_asm (const rtx_insn *, const char *,
+			 ...) ATTRIBUTE_GCC_DIAG(2,3);
Index: gcc/final.c
===
--- gcc/final.c	(revision 215132)
+++ gcc/final.c	(revision 215133)
@@ -151,7 +151,7 @@
 /* Nonzero while outputting an `asm' with operands.
This means that inconsistencies are the user's fault, so don't die.
The precise value is the insn being output, to pass to error_for_asm.  */
-rtx this_is_asm_operands;
+const rtx_insn *this_is_asm_operands;
 
 /* Number of operands of this insn, for an `asm' with operands.  */
 static unsigned int insn_noperands;
Index: gcc/ChangeLog
===
--- gcc/ChangeLog	(revision 215132)
+++ gcc/ChangeLog	(revision 215133)
@@ -1,5 +1,16 @@
 2014-09-10  David Malcolm  
 
+	* final.c (this_is_asm_operands): Strengthen this variable from
+	rtx to const rtx_insn *.
+	* output.h (this_is_asm_operands): Likewise.
+	* rtl-error.c (location_for_asm): Strengthen param "insn" from
+	const_rtx to const rtx_insn *.
+	(diagnostic_for_asm): Likewise.
+	* rtl-error.h (error_for_asm): Likewise.
+	(warning_for_asm): Likewise.
+
+2014-09-10  David Malcolm  
+
 	* genextract.c (print_header): When writing out insn_extract to
 	insn-extract.c, strengthen the param "insn" from rtx to rtx_insn *.
 	* recog.h (insn_extract): Strengthen the param from rtx to
Index: gcc/output.h
===
--- gcc/output.h	(revision 215132)
+++ gcc/output.h	(revision 215133)
@@ -328,7 +328,7 @@
 /* Nonzero while outputting an `asm' with operands.
This means that inconsistencies are the user's fault, so don't die.
The precise value is the insn being output, to pass to error_for_asm.  */
-extern rtx this_is_asm_operands;
+extern const rtx_insn *this_is_asm_operands;
 
 /* Carry information from ASM_DECLARE_OBJECT_NAME
to ASM_FINISH_DECLARE_OBJECT.  */

[PATCH] Fix up libffi linux64*.S for ppc32-linux

[Jakub Jelinek]

Hi!

I've noticed that on 4.8 branch libgo recently (in the last few months)
started being linked with
  GNU_STACK  0x00 0x 0x 0x0 0x0 RWE 0x10
i.e. requiring executable stack on powerpc-linux (32-bit).

The problem is that we link into libffi linux64.o and linux64_closure.o
unconditionally, both for 32-bit and 64-bit compilations, just for 32-bit
ones all the assembly is ifdefed out, so they have just empty sections.
The .note.GNU-stack section isn't emitted in that case either, which means
that the linker conservatively treats those as possibly needing executable
stack.

The following patch should fix that, ok for trunk/4.9/4.8?

BTW, I wonder if e.g. libffi/src/arm/trampoline.S or
libffi/src/aarch64/sysv.S shouldn't have those notes too (note, both of
those were added after 2008 when most of the *.S files were marked that
way).

2014-09-10  Jakub Jelinek  

* src/powerpc/linux64.S: Emit .note.GNU-stack even when
POWERPC64 is not defined.
* src/powerpc/linux64_closure.S: Likewise.  Also test _CALL_ELF == 2.

--- libffi/src/powerpc/linux64.S.jj 2013-12-10 08:52:16.0 +0100
+++ libffi/src/powerpc/linux64.S2014-09-10 16:36:23.881137722 +0200
@@ -254,7 +254,8 @@ ffi_call_LINUX64:
.align 3
 .LEFDE1:
 
-# if (defined __ELF__ && defined __linux__) || _CALL_ELF == 2
+#endif
+
+#if (defined __ELF__ && defined __linux__) || _CALL_ELF == 2
.section.note.GNU-stack,"",@progbits
-# endif
 #endif
--- libffi/src/powerpc/linux64_closure.S.jj 2013-12-10 08:52:16.0 
+0100
+++ libffi/src/powerpc/linux64_closure.S2014-09-10 16:37:38.104747027 
+0200
@@ -381,7 +381,8 @@ ffi_closure_LINUX64:
.align 3
 .LEFDE1:
 
-# if defined __ELF__ && defined __linux__
+#endif
+
+#if (defined __ELF__ && defined __linux__) || _CALL_ELF == 2
.section.note.GNU-stack,"",@progbits
-# endif
 #endif

Jakub

Re: [PATCH, 4.9, PR 61654] Handle newly truly expanded artificial_thunks

[Martin Jambor]

On Wed, Sep 03, 2014 at 10:45:34AM +0200, Martin Jambor wrote:
> Hi,
> 
> I did not think it was possible, but it can happen that when
> duplicate_thunk_for_node creates a duplicate of a thunk which
> previously expand_thunk left alone to be expanded into assembly by the
> back end, the newly created thunk does get expanded by expand_thunk.
> When this happens, we end up with an un-analyzed node which triggers
> an assert later on.
> 
> This patch deals with the situation by analyzing the newly expanded
> thunk.  This revealed that DECL_ARGUMENTS were insufficiently copied
> for the new decl and it was sharing them with the old one.  So this
> patch fixes this as well.
> 
> Bootstrapped and tested on x86_64-linux and i686-linux (where the bug
> triggered), OK for trunk and the 4.9 branch?
> 

After Jeff's approval, I have committed the patch to the trunk.  The
patch for 4.9 is however slightly larger, because before cgraph API
C++ification analyze function was a static function (now it is a
method of cgraph_node).  Because my fix needs to call it from another
compilation unit, I need to make it externally visible.  The 4.9 patch
is below, it also passes bootstrap and test on an x86_64-linux, i386
testing is underway.  Given that the original patch has been approved,
I intend to commit this one to the branch tomorrow if the test
finishes fine.

Thanks,

Martin


2014-09-10  Martin Jambor  

PR ipa/61654
* cgraph.h (cgraph_analyze_function): Declare.
* cgraphunit.c: (analyze_function): Remove forward declaration,
rename to cgraph_analyze_function, made external.
* cgraphclones.c (duplicate_thunk_for_node): Copy arguments of the
new decl properly.  Analyze the new thunk if it is expanded.

gcc/testsuite/
* g++.dg/ipa/pr61654.C: New test.

diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 6c3be6d..0d13ebe 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -797,6 +797,7 @@ void cgraph_unnest_node (struct cgraph_node *);
 
 enum availability cgraph_function_body_availability (struct cgraph_node *);
 void cgraph_add_new_function (tree, bool);
+void cgraph_analyze_function (struct cgraph_node *);
 const char* cgraph_inline_failed_string (cgraph_inline_failed_t);
 cgraph_inline_failed_type_t cgraph_inline_failed_type (cgraph_inline_failed_t);
 
diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index 972ca07..9ad76dd 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -334,6 +334,22 @@ duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node 
*node)
node->clone.args_to_skip,
false);
 }
+
+  tree *link = &DECL_ARGUMENTS (new_decl);
+  int i = 0;
+  for (tree pd = DECL_ARGUMENTS (thunk->decl); pd; pd = DECL_CHAIN (pd), i++)
+{
+  if (!node->clone.args_to_skip
+ || !bitmap_bit_p (node->clone.args_to_skip, i))
+   {
+ tree nd = copy_node (pd);
+ DECL_CONTEXT (nd) = new_decl;
+ *link = nd;
+ link = &DECL_CHAIN (nd);
+   }
+}
+  *link = NULL_TREE;
+
   gcc_checking_assert (!DECL_STRUCT_FUNCTION (new_decl));
   gcc_checking_assert (!DECL_INITIAL (new_decl));
   gcc_checking_assert (!DECL_RESULT (new_decl));
@@ -358,6 +374,11 @@ duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node 
*node)
   cgraph_call_edge_duplication_hooks (thunk->callees, e);
   if (!expand_thunk (new_thunk, false))
 new_thunk->analyzed = true;
+  else
+{
+  new_thunk->thunk.thunk_p = false;
+  cgraph_analyze_function (new_thunk);
+}
   cgraph_call_node_duplication_hooks (thunk, new_thunk);
   return new_thunk;
 }
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 8abdc5d..f486055 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -219,7 +219,6 @@ cgraph_node_set cgraph_new_nodes;
 static void expand_all_functions (void);
 static void mark_functions_to_output (void);
 static void expand_function (struct cgraph_node *);
-static void analyze_function (struct cgraph_node *);
 static void handle_alias_pairs (void);
 
 FILE *cgraph_dump_file;
@@ -331,7 +330,7 @@ cgraph_process_new_functions (void)
 
  gimple_register_cfg_hooks ();
  if (!node->analyzed)
-   analyze_function (node);
+   cgraph_analyze_function (node);
  push_cfun (DECL_STRUCT_FUNCTION (fndecl));
  if (cgraph_state == CGRAPH_STATE_IPA_SSA
  && !gimple_in_ssa_p (DECL_STRUCT_FUNCTION (fndecl)))
@@ -541,7 +540,7 @@ cgraph_add_new_function (tree fndecl, bool lowered)
if (lowered)
  node->lowered = true;
node->definition = true;
-   analyze_function (node);
+   cgraph_analyze_function (node);
push_cfun (DECL_STRUCT_FUNCTION (fndecl));
gimple_register_cfg_hooks ();
bitmap_obstack_initialize (NULL);
@@ -598,8 +597,8 @@ output_asm_statements (void)
 }
 
 /* Analyze the function scheduled to be output.  */
-static void
-analyze_function 

Re: [C++, OpenMP] Crash when OpenMP target's array section handling is used with templates

[Thomas Schwinge]

Hi!

On Wed, 10 Sep 2014 12:23:04 +0200, Jakub Jelinek  wrote:
> On Wed, Sep 10, 2014 at 12:12:03PM +0200, Thomas Schwinge wrote:
> > Are the following issues known?
> 
> No, please file a PR.

Will do tomorrow.

> Supposedly either we should call cp_omp_mappable_type
> only for non-type-dependent expressions, or not at all if
> processing_template_decl and only do that once finish_omp_clauses is called
> with !processing_template_decl.

Thanks for the suggestion.  I tried experimenting with that, but with no
experience in the C++ front end, I didn't get useful results -- I got
past the original error, but then got ICEs in omp-low.

> > template 
> > void f(T A, T B)
> > {
> >   extern int *v;
> >   T a = 2;
> >   T b = 4;
> > 
> > #pragma omp target map(to: v[a:b])
> >   v[a] = 0;
> > 
> > #pragma omp target map(to: v[A:B])
> >   v[a] = 0;
> > }
> > 
> > void g()
> > {
> >   f(1, 5);
> > }


Grüße,
 Thomas


pgp5OvbQq4AXz.pgp
Description: PGP signature

Re: [PATCH ARM] Fix PR target/63209

[Xinliang David Li]

With gcc regression test, no regressions are found.

David

On Tue, Sep 9, 2014 at 11:45 AM, Xinliang David Li  wrote:
> Richard, thanks for the review. The revised patch is attached. Is this
> one OK (after testing is done)?
>
> David
>
>
> 2014-09-08  Xinliang David Li  
>
> PR target/63209
> * config/arm/arm.md (movcond_addsi): Handle case where source
> and target operands are the same
>
> 2014-09-08  Xinliang David Li  
>
> PR target/63209
> * gcc.c-torture/execute/pr63209.c: New test
>
>
>
> On Tue, Sep 9, 2014 at 10:31 AM, Richard Earnshaw  wrote:
>> On 09/09/14 16:58, Xinliang David Li wrote:
>>> The attached patch fixed the problem reported in PR63209. The problem
>>> exists in both gcc4.9 and trunk.
>>>
>>> Regression test on arm-unknown-linux-gnueabi passes.
>>>
>>> Ok for gcc-4.9 and trunk?
>>>
>>
>> No, this isn't right.  I don't think you need a new pattern here (you
>> certainly don't want a new insn - at most you would just need a new
>> split).  But I think you just need some special case code in the
>> existing pattern to handle the overlap case.
>>
>> Also, please do not post ChangeLog entries in patch format; they won't
>> apply by the time the patch is ready to be committed.
>>
>> R.
>>
>>
>>> (I sent the patch last night, but it got lost somehow)
>>>
>>>
>>> David
>>>
>>>
>>> pr63209.txt
>>>
>>>
>>> Index: ChangeLog
>>> ===
>>> --- ChangeLog (revision 215039)
>>> +++ ChangeLog (working copy)
>>> @@ -1,3 +1,9 @@
>>> +2014-09-08  Xinliang David Li  
>>> +
>>> + PR target/63209
>>> + * config/arm/arm.md (movcond_addsi_1): New pattern.
>>> + (movcond_addsi): Add a constraint.
>>> +
>>>  2014-09-08  Trevor Saunders  
>>>
>>>   * common/config/picochip/picochip-common.c: Remove.
>>> Index: config/arm/arm.md
>>> ===
>>> --- config/arm/arm.md (revision 215039)
>>> +++ config/arm/arm.md (working copy)
>>> @@ -9302,6 +9302,43 @@
>>> (set_attr "type" "multiple")]
>>>  )
>>>
>>> +(define_insn_and_split "movcond_addsi_1"
>>> +   [(set (match_operand:SI 0 "s_register_operand" "=r,l,r")
>>> +(if_then_else:SI
>>> + (match_operator 4 "comparison_operator"
>>> +  [(plus:SI (match_operand:SI 2 "s_register_operand" "r,r,r")
>>> +(match_operand:SI 3 "arm_add_operand" "rIL,rIL,rIL"))
>>> + (const_int 0)])
>>> + (match_operand:SI 1 "arm_rhs_operand" "rI,rPy,r")
>>> + (match_dup:SI 0)))
>>> +(clobber (reg:CC CC_REGNUM))]
>>> +"TARGET_32BIT"
>>> +"#"
>>> +"&& reload_completed"
>>> +   [(set (reg:CC_NOOV CC_REGNUM)
>>> +(compare:CC_NOOV
>>> + (plus:SI (match_dup 2)
>>> +  (match_dup 3))
>>> + (const_int 0)))
>>> +(cond_exec (match_dup 5)
>>> +  (set (match_dup 0) (match_dup 1)))]
>>> +   "
>>> +   {
>>> + enum machine_mode mode = SELECT_CC_MODE (GET_CODE (operands[4]),
>>> + operands[2], operands[3]);
>>> + enum rtx_code rc = GET_CODE (operands[4]);
>>> +
>>> + operands[5] = gen_rtx_REG (mode, CC_REGNUM);
>>> + gcc_assert (!(mode == CCFPmode || mode == CCFPEmode));
>>> + operands[5] = gen_rtx_fmt_ee (rc, VOIDmode, operands[5], const0_rtx);
>>> +  }
>>> +  "
>>> +  [(set_attr "conds" "clob")
>>> +   (set_attr "enabled_for_depr_it" "no,yes,yes")
>>> +   (set_attr "type" "multiple")]
>>> +)
>>> +
>>> +
>>>  (define_insn_and_split "movcond_addsi"
>>>[(set (match_operand:SI 0 "s_register_operand" "=r,l,r")
>>>   (if_then_else:SI
>>> @@ -9312,7 +9349,7 @@
>>>(match_operand:SI 1 "arm_rhs_operand" "rI,rPy,r")
>>>(match_operand:SI 2 "arm_rhs_operand" "rI,rPy,r")))
>>> (clobber (reg:CC CC_REGNUM))]
>>> -   "TARGET_32BIT"
>>> +   "TARGET_32BIT && REGNO (operands[2]) != REGNO (operands[0])"
>>> "#"
>>> "&& reload_completed"
>>>[(set (reg:CC_NOOV CC_REGNUM)
>>> Index: testsuite/ChangeLog
>>> ===
>>> --- testsuite/ChangeLog   (revision 215039)
>>> +++ testsuite/ChangeLog   (working copy)
>>> @@ -1,3 +1,8 @@
>>> +2014-09-08  Xinliang David Li  
>>> +
>>> + PR target/63209
>>> + * gcc.c-torture/execute/pr63209.c: New test
>>> +
>>>  2014-09-08  Jakub Jelinek  
>>>
>>>   PR tree-optimization/60196
>>> Index: testsuite/gcc.c-torture/execute/pr63209.c
>>> ===
>>> --- testsuite/gcc.c-torture/execute/pr63209.c (revision 0)
>>> +++ testsuite/gcc.c-torture/execute/pr63209.c (revision 0)
>>> @@ -0,0 +1,27 @@
>>> +static int Sub(int a, int b) {
>>> +  return  b -a;
>>> +}
>>> +
>>> +static unsigned Select(unsigned a, unsigned b, unsigned c) {
>>> +  const int pa_minus_pb =
>>> +  Sub((a >>  8) & 0xff, (b >>  8) & 0xff) +
>>> +  Sub((a >>  0) & 0xff, (b >

Re: PR debug/60655, debug loc expressions

[Ramana Radhakrishnan]

2014-04-10  Ramana Radhakrishnan  

PR debug/60655
* config/arm/arm.c (TARGET_CONST_NOT_OK_FOR_DEBUG_P): Define
(arm_const_not_ok_for_debug_p): Reject MINUS with SYM_REF's
ameliorating the cases where it can be.

can I suppose be reverted too.


That was always something to help get 4.9 out of the door - I still mean 
to do the proper work for 5.0 where we look at all possible types of 
output generated but it won't happen this month either.


If this fixes it properly it would be nice to revert the change - I 
can't take this on for a few weeks as I am travelling. If you want to 
take that up please verify that the original testcase is fixed and the 
usual caveats of testing apply.


Thanks,
Ramana



   Maciej

Re: [ARM][tests] Make input and output arrays 128-bit aligned in vectorisation tests

[Ramana Radhakrishnan]

On 09/09/14 16:14, Kyrill Tkachov wrote:

Hi all,

As Christophe mentioned at
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00202.html
These tests fail on big-endian. The reason is that the input is not
aligned to 128 bit forcing the use of a movmisalign which we don't
support on big-endian.

A solution is to force the alignment of the arrays, allowing for the use
of normal loads and stores.
We can look into enabling misaligned loads on big-endian with the
appropriate reversal logic as a separate
piece of work...

Ok for trunk?

2014-09-09  Kyrylo Tkachov  

  * gcc.target/arm/vect-lceilf_1.c: Make input and output arrays global
  and 16-byte aligned.
  * gcc.target/arm/vect-lfloorf_1.c: Likewise.
  * gcc.target/arm/vect-lroundf_1.c: Likewise.
  * gcc.target/arm/vect-rounding-btruncf.c: Likewise.
  * gcc.target/arm/vect-rounding-ceilf.c: Likewise.
  * gcc.target/arm/vect-rounding-floorf.c: Likewise.
  * gcc.target/arm/vect-rounding-roundf.c: Likewise.




Ok.

Ramana

Re: [Patch ARM v2] Fix PR target/56846

[Ramana Radhakrishnan]

On 10/09/14 15:38, Jonathan Wakely wrote:

On 10/09/14 15:41 +0800, Tony Wang wrote:

-Original Message-
From: Jonathan Wakely [mailto:jwak...@redhat.com]
Sent: Tuesday, September 09, 2014 6:40 PM
To: Tony Wang
Cc: Ramana Radhakrishnan; gcc-patches; libstd...@gcc.gnu.org
Subject: Re: [Patch ARM v2] Fix PR target/56846

On 09/09/14 17:47 +0800, Tony Wang wrote:

Hi there,

This is a updated patch to fix pr56846. Bootstrapped on 
x86_64-unknown-linux-gnu and no regression for
regression test on Linux and a cross regression test on arm-none-eabi.

OK for the trunk?

gcc/libstdc++-v3/ChangeLog:
2014-09-09   Tony Wang 

 PR target/56846
 * libsupc++/eh_personality.cc(PERSONALITY_FUNCTION):

^
There should be a space after the file name (look at existing
changelog entries)

OK with that change.


Committed with your comment on trunk, and also tested on 4.9 branch with no 
regression. So is it ok to back
port to 4.9 branch?


I'd at least like to see it working OK on trunk for a while without
regressions, and I don't know the EABI code well enough to be
confident it's safe to backport.


I am reasonably sure it's ok from my reading of the explanation and the 
code considered, and I'd also to some extent take Andrew's word for it 
since he's been involved in this space.


I'd like it to bake on trunk for a few days before we ask for this to be 
backported. It would give all autotesters that run for ARM a chance to 
catch up and make sure we aren't missing anything.


From my p.o.v. this is an RM decision.

regards
Ramana

Re: [patch,avr] Make jump tables work with bootloader

[Denis Chertykov]

2014-09-08 21:12 GMT+04:00 Georg Lay :
> avr-gcc puts jump tables in section .progmem.gcc_sw_table and assumes that
> .text starts at 0, i.e. LPM is on order to read table entries.
>
> This is no more the case if .text starts ata higher address like typically
> used with boot loaders.
>
> This patch adds the few instructions to set RAMPZ and make casesi and
> __tablejump2__ more generic.  __tablejump__ and __tablejump_elpm__ are no
> more needed.  Moreover, using gs() for a jump table is odd because the
> linker should never generate a stub for this; thus use pm_lo8 etc. instead
> of gs() for >128k devices.
>
> Ok for trunk?

Ok.

Denis.

[Patch, MIPS] Add .note.GNU-stack section

[Steve Ellcey]

Someone noticed that the MIPS GCC compiler was not putting out the
.note.GNU-stack section.  This simple patch fixes that problem by
calling the standard file_end_indicate_exec_stack function.

Tested on mips-mti-linux-gnu, OK to checkin?

Steve Ellcey
sell...@mips.com



2014-09-10  Steve Ellcey  

* config/mips/mips.c (TARGET_ASM_FILE_END): Define.


diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 646bb4d..bcaa9cd 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -19146,6 +19146,9 @@ mips_lra_p (void)
 #undef TARGET_LRA_P
 #define TARGET_LRA_P mips_lra_p
 
+#undef TARGET_ASM_FILE_END
+#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 #include "gt-mips.h"

Re: [Patch, MIPS] Add .note.GNU-stack section

[pinskia]

> On Sep 10, 2014, at 9:24 AM, "Steve Ellcey "  wrote:
> 
> Someone noticed that the MIPS GCC compiler was not putting out the
> .note.GNU-stack section.  This simple patch fixes that problem by
> calling the standard file_end_indicate_exec_stack function.
> 
> Tested on mips-mti-linux-gnu, OK to checkin?

This works except you did not update the assembly files in libgcc or glibc. We 
(Cavium) have the same patch in our tree for a few released versions. 

Thanks,
Andrew

> 
> Steve Ellcey
> sell...@mips.com
> 
> 
> 
> 2014-09-10  Steve Ellcey  
> 
>* config/mips/mips.c (TARGET_ASM_FILE_END): Define.
> 
> 
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index 646bb4d..bcaa9cd 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -19146,6 +19146,9 @@ mips_lra_p (void)
> #undef TARGET_LRA_P
> #define TARGET_LRA_P mips_lra_p
> 
> +#undef TARGET_ASM_FILE_END
> +#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
> +
> struct gcc_target targetm = TARGET_INITIALIZER;
> 
> #include "gt-mips.h"

Re: [Ping v2][PATCH] Add patch for debugging compiler ICEs.

[Joseph S. Myers]

On Wed, 10 Sep 2014, Jakub Jelinek wrote:

> On Tue, Sep 09, 2014 at 10:51:23PM +, Joseph S. Myers wrote:
> > On Thu, 28 Aug 2014, Maxim Ostapenko wrote:
> > 
> > > diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
> > > index 0cc7593..67b8c5b 100644
> > > --- a/gcc/diagnostic.c
> > > +++ b/gcc/diagnostic.c
> > > @@ -492,7 +492,7 @@ diagnostic_action_after_output (diagnostic_context 
> > > *context,
> > >   real_abort ();
> > >diagnostic_finish (context);
> > >fnotice (stderr, "compilation terminated.\n");
> > > -  exit (FATAL_EXIT_CODE);
> > > +  exit (ICE_EXIT_CODE);
> > 
> > Why?  This is the case for fatal_error.  FATAL_EXIT_CODE seems right for 
> > this, and ICE_EXIT_CODE wrong.
> 
> So that the driver can understand the difference between an ICE and other
> fatal errors (e.g. sorry etc.).
> Users are typically using the driver and for them it matters what exit code
> is returned from the driver, not from cc1/cc1plus etc.

Well, I think the next revision of the patch submission needs more 
explanation in this area.  What exit codes do cc1 and the driver now 
return for (normal error, fatal error, ICE), and what do they return after 
the patch, and how does the change to the fatal_error case avoid incorrect 
changes if either cc1 or the driver called fatal_error (as opposed to 
either cc1 or the driver having an ICE)?  Maybe that explanation should be 
in the form of a comment on this exit call, explaining why the 
counterintuitive use of ICE_EXIT_CODE in the DK_FATAL case is correct.

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

Re: DBL_DENORM_MIN should never be 0

[Joseph S. Myers]

On Wed, 10 Sep 2014, Marc Glisse wrote:

> Hello,
> 
> according to the C++ standard, numeric_limits::denorm_min should return min
> (not 0) when there are no denormals.
> 
> Tested with bootstrap+testsuite on x86_64-linux-gnu. I also tested a basic
> make all-gcc for vax (only target without denormals apparently) and the macro
> did change as expected.
> 
> The next step might be to define has_denorm as false in more cases (-mno-ieee
> on alpha, -ffast-math on x86, etc) but that's a different issue.
> 
> (this is C++ but I believe Joseph is the floating-point expert, hence the cc)

This is a C issue as well (for C11 *_TRUE_MIN).

> gcc/c-family/
> 
> 2014-09-10  Marc Glisse  
> 

PR target/58757

>   * c-cppbuiltin.c (builtin_define_float_constants): Correct
>   __*_DENORM_MIN__ without denormals.

I think there should be some sort of testcase that these values aren't 0.

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

Re: [PATCH i386 AVX512] [34/n] AVX-512. Extend vpermvar insn patterns.

[Uros Bizjak]

On Wed, Sep 10, 2014 at 2:37 PM, Kirill Yukhin  wrote:
> Hello,
> patch in the bottom extends PERMVAR based patterns.
>
> Hello,
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/sse.md
> (define_mode_attr avx2_avx512): Rename from avx2_avx512bw.
> (define_mode_iterator VI48F_256_512): Extend to AVX-512VL.
> (define_insn "_permvar"): Rename from
> "_permvar".
> (define_insn "_permvar"): New.
> (define_insn "_ashrv" with
> VI48_AVX512F_AVX512VL mode iterator): Rename from

You can use extended forms of the mode attributes to distinguish
various same-name patterns:

(define_insn "_ashrv"):
Rename ...

It is up to you, the description you provided is also OK.

> "_ashrv".
> (define_insn "_ashrv" with
> VI2_AVX512VL mode iterator): Ditto.
> (define_insn "_v" with
> VI48_AVX512F mode iterator): Rename from
> "_v".
> (define_insn "_v" with
> VI2_AVX512VL mode iterator): Rename from
> "_v".

OK for mainline.

Thanks,
Uros.

Re: [PATCH i386 AVX512] [35/n] Add vperm[it]2 insns support.

[Uros Bizjak]

On Wed, Sep 10, 2014 at 3:05 PM, Kirill Yukhin  wrote:
> Hello,
> Patch in the bottom extends perm[t|i] patterns.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/sse.md
> (define_expand "_vpermi2var3_maskz" with VI48F
> mode iterator): Rename from
> "avx512f_vpermi2var3_maskz" and update mode iterator.
> (define_expand "_vpermi2var3_maskz" with
> VI2_AVX512VL mode iterator): New.
> (define_insn "_vpermi2var3" with
> VI48F): Renamefrom "avx512f_vpermi2var3"
> and update mode iterator.
> (define_insn "_vpermi2var3" with
> VI2_AVX512VL): New.
> (define_insn "_vpermi2var3_mask" with VI48F
> mode iterator): Rename from "avx512f_vpermi2var3_mask"
> and update mode iterator.
> (define_insn "_vpermi2var3_mask" with VI2_AVX512VL
> mode iterator): New.
> (define_expand "_vpermt2var3_maskz" with VI48F
> mode iterator): Rename from "avx512f_vpermt2var3_maskz" and
> update mode iterator.
> (define_expand "_vpermt2var3_maskz" with VI2_AVX512VL
> mode iterator): New.
> (define_insn "_vpermt2var3" with VI48F
> mode iterator): Rename from "avx512f_vpermt2var3"
> and update mode iterator.
> (define_insn "_vpermt2var3" with
> VI2_AVX512VL mode iterator): New.
> (define_insn "_vpermt2var3_mask" with VI48F mode
> iterator): Rename from "avx512f_vpermt2var3_mask" and update 
> mode
> iterator.
> (define_insn "_vpermt2var3_mask" with VI2_AVX512VL
> mode iterator): New.

I'd personally prefer extended mode attribute names here, as described
in my previous mail.

OK.

Thanks,
Uros.

[GOOGLE] Fix gcda build info support

[Teresa Johnson]

While porting recent support for a build info section in the gcda from
google/4_8 to 4_9 and doing manual testing, I discovered that it does
not interact well with the COMDAT fixup handling. This patch fixes the
issue, and adds a test case that exposes the problem without the fix.

Here is the google/4_8 patch - I plan to commit there first then port
it along with the original build info patch to 4_9.

Passes regression tests - ok for google branches?

Thanks,
Teresa

2014-09-10  Teresa Johnson  

libgcc:
* libgcov-driver.c (gcov_scan_to_function_data): Rename from
gcov_scan_summary_end, scan past BUILD_INFO section.
(gcov_dump_module_info): Rename gcov_scan_summary_end to
gcov_scan_to_function_data.

gcc/testsuite:
* g++.dg/tree-prof/lipo/buildinfo.txt: Input for
-fprofile-generate-buildinfo option.
* g++.dg/tree-prof/lipo/comdat_fixup_0.C: New test.
* g++.dg/tree-prof/lipo/comdat_fixup_1.C: Ditto.
* g++.dg/tree-prof/lipo/comdat_fixup_2.C: Ditto.
* g++.dg/tree-prof/lipo/comdat_fixup.h: Ditto.
* lib/profopt.exp: Declare srcdir for use in test options.

Index: libgcc/libgcov-driver.c
===
--- libgcc/libgcov-driver.c (revision 214976)
+++ libgcc/libgcov-driver.c (working copy)
@@ -428,13 +428,15 @@ struct gcov_filename_aux{
 #include "libgcov-driver-system.c"

 /* Scan through the current open gcda file corresponding to GI_PTR
-   to locate the end position of the last summary, returned in
-   SUMMARY_END_POS_P.  Return 0 on success, -1 on error.  */
+   to locate the end position just before function data should be rewritten,
+   returned in SUMMARY_END_POS_P. E.g. scan past the last summary and other
+   sections that won't be rewritten, like the build info.  Return 0 on success,
+   -1 on error.  */
 static int
-gcov_scan_summary_end (struct gcov_info *gi_ptr,
-   gcov_position_t *summary_end_pos_p)
+gcov_scan_to_function_data (struct gcov_info *gi_ptr,
+gcov_position_t *summary_end_pos_p)
 {
-  gcov_unsigned_t tag, version, stamp;
+  gcov_unsigned_t tag, version, stamp, i, length;
   tag = gcov_read_unsigned ();
   if (tag != GCOV_DATA_MAGIC)
 {
@@ -467,6 +469,28 @@ static int
 return -1;
 }

+  /* If there is a build info section, scan past it as well.  */
+  if (tag == GCOV_TAG_BUILD_INFO)
+{
+  length = gcov_read_unsigned ();
+  gcov_unsigned_t num_strings = 0;
+  char **build_info_strings = gcov_read_build_info (length, &num_strings);
+  if (!build_info_strings)
+{
+  gcov_error ("profiling:%s:Error reading build info\n", gi_filename);
+  return -1;
+}
+
+  for (i = 0; i < num_strings; i++)
+free (build_info_strings[i]);
+  free (build_info_strings);
+
+  *summary_end_pos_p = gcov_position ();
+  tag = gcov_read_unsigned ();
+}
+  /* The next section should be the function counters.  */
+  gcc_assert (tag == GCOV_TAG_FUNCTION);
+
   return 0;
 }

@@ -1031,10 +1055,10 @@ gcov_dump_module_info (struct gcov_filename_aux *g

   if (changed)
 {
-  /* Scan file to find the end of the summary section, which is
+  /* Scan file to find the start of the function section, which is
  where we will start re-writing the counters.  */
   gcov_position_t summary_end_pos;
-  if (gcov_scan_summary_end (gi_ptr, &summary_end_pos) == -1)
+  if (gcov_scan_to_function_data (gi_ptr, &summary_end_pos) == -1)
 gcov_error ("profiling:%s:Error scanning summaries\n",
 gi_filename);
   else
Index: gcc/testsuite/g++.dg/tree-prof/lipo/buildinfo.txt
===
--- gcc/testsuite/g++.dg/tree-prof/lipo/buildinfo.txt   (revision 0)
+++ gcc/testsuite/g++.dg/tree-prof/lipo/buildinfo.txt   (revision 0)
@@ -0,0 +1 @@
+Test -fprofile-generate-buildinfo option
Index: gcc/testsuite/g++.dg/tree-prof/lipo/comdat_fixup_0.C
===
--- gcc/testsuite/g++.dg/tree-prof/lipo/comdat_fixup_0.C(revision 0)
+++ gcc/testsuite/g++.dg/tree-prof/lipo/comdat_fixup_0.C(revision 0)
@@ -0,0 +1,9 @@
+/* { dg-options "-O2 -fno-inline
-fprofile-generate-buildinfo=$srcdir/g++.dg/tree-prof/lipo/buildinfo.txt"
} */
+#include 
+
+extern int foo1(int x);
+extern int foo2(int x);
+int main()
+{
+  printf ("Result = %d\n", foo1(1) + foo2(1));
+}
Index: gcc/testsuite/g++.dg/tree-prof/lipo/comdat_fixup_1.C
===
--- gcc/testsuite/g++.dg/tree-prof/lipo/comdat_fixup_1.C(revision 0)
+++ gcc/testsuite/g++.dg/tree-prof/lipo/comdat_fixup_1.C(revision 0)
@@ -0,0 +1,7 @@
+/* { dg-options "-O2 -fno-inline" } */
+#include "comdat_fixup.h"
+int foo1(int x)
+{
+  Foo f;
+  ret

Re: PR debug/60655, debug loc expressions

[Maciej W. Rozycki]

On Wed, 10 Sep 2014, Ramana Radhakrishnan wrote:

> > 2014-04-10  Ramana Radhakrishnan  
> > 
> > PR debug/60655
> > * config/arm/arm.c (TARGET_CONST_NOT_OK_FOR_DEBUG_P): Define
> > (arm_const_not_ok_for_debug_p): Reject MINUS with SYM_REF's
> > ameliorating the cases where it can be.
> > 
> > can I suppose be reverted too.
> 
> That was always something to help get 4.9 out of the door - I still mean to do
> the proper work for 5.0 where we look at all possible types of output
> generated but it won't happen this month either.
> 
> If this fixes it properly it would be nice to revert the change - I can't take
> this on for a few weeks as I am travelling. If you want to take that up please
> verify that the original testcase is fixed and the usual caveats of testing
> apply.

 This is supposed to properly fix the issue the test case covers I 
believe.  I'm not going to do anything for the ARM target here, I just 
thought you might want to know that PR debug/60655 has now been further 
addressed, as it may be easy to miss mailing list traffic (especially as 
ARM has been only sparsely mentioned in the discussion).  And what you do 
with this knowledge is up to you. :)

  Maciej

Another C++ PATCH for c++/61659 (DECL_COMDAT and devirt)

[Jason Merrill]

After

* decl.c (maybe_commonize_var): Don't use DECL_COMDAT to trigger
comdat_linkage.

targets without weak symbol support started getting link errors 
bootstrapping GCC.  This ought to fix that.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit e3859ec10649526a24b439301db79a34d7b90ba3
Author: Jason Merrill 
Date:   Tue Sep 9 12:21:03 2014 -0400

	PR c++/61659
	* decl.c (grokfndecl): Don't set DECL_COMDAT on static inlines.
	(duplicate_decls, start_decl): Likewise.
	* pt.c (check_explicit_specialization): Likewise.
	(push_template_decl_real): Or static templates.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index d8fb35e..6e195bb 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -2215,7 +2215,8 @@ duplicate_decls (tree newdecl, tree olddecl, bool newdecl_is_friend)
 		  olddecl);
 
 	  SET_DECL_TEMPLATE_SPECIALIZATION (olddecl);
-	  DECL_COMDAT (newdecl) = DECL_DECLARED_INLINE_P (newdecl);
+	  DECL_COMDAT (newdecl) = (TREE_PUBLIC (newdecl)
+   && DECL_DECLARED_INLINE_P (newdecl));
 
 	  /* Don't propagate visibility from the template to the
 	 specialization here.  We'll do that in determine_visibility if
@@ -4718,7 +4719,8 @@ start_decl (const cp_declarator *declarator,
 	{
 	  SET_DECL_TEMPLATE_SPECIALIZATION (decl);
 	  if (TREE_CODE (decl) == FUNCTION_DECL)
-	DECL_COMDAT (decl) = DECL_DECLARED_INLINE_P (decl);
+	DECL_COMDAT (decl) = (TREE_PUBLIC (decl)
+  && DECL_DECLARED_INLINE_P (decl));
 	  else
 	DECL_COMDAT (decl) = false;
 
@@ -7699,7 +7701,8 @@ grokfndecl (tree ctype,
   if (inlinep)
 {
   DECL_DECLARED_INLINE_P (decl) = 1;
-  DECL_COMDAT (decl) = 1;
+  if (publicp)
+	DECL_COMDAT (decl) = 1;
 }
   if (inlinep & 2)
 DECL_DECLARED_CONSTEXPR_P (decl) = true;
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 44569e2..3c93178 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -2813,7 +2813,8 @@ check_explicit_specialization (tree declarator,
 	SET_DECL_IMPLICIT_INSTANTIATION (decl);
 	  else if (TREE_CODE (decl) == FUNCTION_DECL)
 	/* A specialization is not necessarily COMDAT.  */
-	DECL_COMDAT (decl) = DECL_DECLARED_INLINE_P (decl);
+	DECL_COMDAT (decl) = (TREE_PUBLIC (decl)
+  && DECL_DECLARED_INLINE_P (decl));
 	  else if (TREE_CODE (decl) == VAR_DECL)
 	DECL_COMDAT (decl) = false;
 
@@ -5059,6 +5060,7 @@ template arguments to %qD do not match original template %qD",
 
   if (flag_implicit_templates
   && !is_friend
+  && TREE_PUBLIC (decl)
   && VAR_OR_FUNCTION_DECL_P (decl))
 /* Set DECL_COMDAT on template instantiations; if we force
them to be emitted by explicit instantiation or -frepo,
diff --git a/gcc/testsuite/g++.dg/abi/no-weak1.C b/gcc/testsuite/g++.dg/abi/no-weak1.C
new file mode 100644
index 000..663643f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/abi/no-weak1.C
@@ -0,0 +1,21 @@
+// { dg-options "-fno-weak" }
+// { dg-final { scan-assembler "local\[ \t\]*_ZZL1fvE1i" { target x86_64-*-*gnu } } }
+// { dg-final { scan-assembler "local\[ \t\]*_ZZ1gIiEvvE1i" { target x86_64-*-*gnu } } }
+
+static inline void f()
+{
+  static int i;
+  ++i;
+};
+
+template  static void g()
+{
+  static int i;
+  ++i;
+}
+
+int main()
+{
+  f();
+  g();
+}

Re: [PATCH i386 AVX512] [36/n] Extend gather insn patterns.

[Uros Bizjak]

On Wed, Sep 10, 2014 at 3:12 PM, Kirill Yukhin  wrote:
> Hello,
> Patch in the bottom extends gather instructions support.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/sse.md
> (define_expand "_gathersi"): Rename from
> "avx512f_gathersi".
> (define_insn "*avx512f_gathersi"): Use VI48F.
> (define_insn "*avx512f_gathersi_2"): Ditto.
> (define_expand "_gatherdi"): Rename from
> "avx512f_gatherdi".
> (define_insn "*avx512f_gatherdi"): Use VI48F.
> (define_insn "*avx512f_gatherdi_2"): Use VI48F, add 128/256-bit
> wide versions.
> (define_expand "_scattersi"): Rename from
> "avx512f_scattersi".
> (define_insn "*avx512f_scattersi"): Use VI48F.
> (define_expand "_scatterdi"): Rename from
> "avx512f_scatterdi".
> (define_insn "*avx512f_scatterdi"): Use VI48F.
>

...

>  (define_insn "*avx512f_gatherdi_2"
> -  [(set (match_operand:VI48F_512 0 "register_operand" "=&v")
> -   (unspec:VI48F_512
> +  [(set (match_operand:VI48F 0 "register_operand" "=&v")
> +   (unspec:VI48F
>   [(pc)
>(match_operand:QI 6 "register_operand" "1")
>(match_operator: 5 "vsib_mem_operator"
> @@ -16762,22 +16762,27 @@
>"TARGET_AVX512F"
>  {
>if (mode != mode)
> -return "vgatherq\t{%5, %t0%{%1%}|%t0%{%1%}, 
> %g5}";
> +{
> +  if (GET_MODE_SIZE (mode) != 64)

Something is wrong here. Mode iterator is VI48F that always has mode
size != 64, so the condition is always true.

> +   return "vgatherq\t{%5, 
> %x0%{%1%}|%t0%{%1%}, %g5}";
> +  else
> +   return "vgatherq\t{%5, 
> %t0%{%1%}|%t0%{%1%}, %g5}";
> +}
>return "vgatherq\t{%5, %0%{%1%}|%0%{%1%}, 
> %g5}";

Uros.

RFA: PATCH to ipa-devirt for c++/58678

[Jason Merrill]

The failure with -flto is due to make_decl_local clearing DECL_COMDAT, 
so the check in ipa_devirt allows devirtualization to an implicitly 
declared destructor.  It's not clear to me why make_decl_local needs to 
clear DECL_COMDAT, but it's simpler to just remove that check from 
ipa_devirt.


Tested x86_64-pc-linux-gnu.  OK for trunk and 4.9?
commit f88473ffec00cd8b537f7d92102f99fbd855b685
Author: Jason Merrill 
Date:   Fri Aug 29 12:44:54 2014 -0400

	PR c++/58678
	* ipa-devirt.c (ipa_devirt): Don't check DECL_COMDAT.

diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index f98a18e..948ae23 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -3952,8 +3952,7 @@ ipa_devirt (void)
 	/* Don't use an implicitly-declared destructor (c++/58678).  */
 	struct cgraph_node *non_thunk_target
 	  = likely_target->function_symbol ();
-	if (DECL_ARTIFICIAL (non_thunk_target->decl)
-		&& DECL_COMDAT (non_thunk_target->decl))
+	if (DECL_ARTIFICIAL (non_thunk_target->decl))
 	  {
 		if (dump_file)
 		  fprintf (dump_file, "Target is artificial\n\n");
diff --git a/gcc/testsuite/g++.dg/ipa/devirt-28a.C b/gcc/testsuite/g++.dg/ipa/devirt-28a.C
new file mode 100644
index 000..bdd1682
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/devirt-28a.C
@@ -0,0 +1,15 @@
+// PR c++/58678
+// { dg-options "-O3 -flto -shared -fPIC -Wl,--no-undefined" }
+// { dg-do link { target { gld && fpic } } }
+
+struct A {
+  virtual ~A();
+};
+struct B : A {
+  virtual int m_fn1();
+};
+void fn1(B* b) {
+  delete b;
+}
+
+int main() {}

[C++ Patch] PR 61489

[Paolo Carlini]

Hi,

the bug (Jon, in fact) argues that probably we shouldn't 
-Wmissing-field-initializers warn for cases like obj11 below (or 
warn5.C). I noticed that in practice this is also the specific behavior 
which clang++ implements for their warning with the same name.


Tested x86_64-linux.

Thanks,
Paolo.

/
/cp
2014-09-10  Paolo Carlini  

PR c++/61489
* typeck2.c (process_init_constructor_record): Do not warn about
missing field initializer if EMPTY_CONSTRUCTOR_P (init).

/testsuite
2014-09-10  Paolo Carlini  

PR c++/61489
* g++.dg/warn/Wmissing-field-initializers-1.C: New.
* g++.old-deja/g++.other/warn5.C: Adjust.
Index: cp/typeck2.c
===
--- cp/typeck2.c(revision 215117)
+++ cp/typeck2.c(working copy)
@@ -1359,7 +1359,8 @@ process_init_constructor_record (tree type, tree i
  next = massage_init_elt (TREE_TYPE (field), next, complain);
 
  /* Warn when some struct elements are implicitly initialized.  */
- if (complain & tf_warning)
+ if ((complain & tf_warning)
+ && !EMPTY_CONSTRUCTOR_P (init))
warning (OPT_Wmissing_field_initializers,
 "missing initializer for member %qD", field);
}
@@ -1382,7 +1383,8 @@ process_init_constructor_record (tree type, tree i
 
  /* Warn when some struct elements are implicitly initialized
 to zero.  */
- if (complain & tf_warning)
+ if ((complain & tf_warning)
+ && !EMPTY_CONSTRUCTOR_P (init))
warning (OPT_Wmissing_field_initializers,
 "missing initializer for member %qD", field);
 
Index: testsuite/g++.dg/warn/Wmissing-field-initializers-1.C
===
--- testsuite/g++.dg/warn/Wmissing-field-initializers-1.C   (revision 0)
+++ testsuite/g++.dg/warn/Wmissing-field-initializers-1.C   (working copy)
@@ -0,0 +1,31 @@
+// PR c++/61489
+// { dg-options "-Wmissing-field-initializers" }
+
+struct mystruct1 {
+  int a, b;
+};
+
+struct aux2 {
+  aux2();
+};
+
+struct mystruct2 {
+  aux2 a, b;
+};
+
+struct aux3 {
+  int x;
+};
+
+struct mystruct3 {
+  aux3 a, b;
+};
+
+mystruct1 obj11 = {};
+mystruct1 obj12 = {0};   // { dg-warning "missing field initializer" }
+
+mystruct2 obj21 = {};
+mystruct2 obj22 = {aux2()};  // { dg-warning "missing field initializer" }
+
+mystruct3 obj31 = {};
+mystruct3 obj32 = {0};   // { dg-warning "missing field initializer" }
Index: testsuite/g++.old-deja/g++.other/warn5.C
===
--- testsuite/g++.old-deja/g++.other/warn5.C(revision 215117)
+++ testsuite/g++.old-deja/g++.other/warn5.C(working copy)
@@ -16,4 +16,4 @@ X *foo ()
   return new X ();  // gets bogus warning
 }
 
-X x = {};   // { dg-warning "" } missing initializer
+X x = {};

Re: [PATCH] gcc parallel make check

[Mike Stump]

On Sep 10, 2014, at 7:16 AM, Jakub Jelinek  wrote:
> IMHO the best fix for that is following, use the same predicate whether to
> run the vect-args.c tests or not as is used for all other tests.
> 
> Ok for trunk?

Looks suspiciously looks familiar.  Ok.  Thanks.

Re: [PATCH] gcc parallel make check

[Mike Stump]

On Sep 9, 2014, at 8:14 AM, VandeVondele Joost  
wrote:
> Attached is a further revision of the patch, now dealing with check-c++.

So when last I played in this area, I wanted a command line tool that would 
bin-pack from the command line.  I would then grab the seconds per for each 
.exp, and bin pack to the fixed N, where N was the core count or related to it 
like, like N+1, N*1.1+1, N*2, ceil(N*1.1)).  Then, I would just have 60-100 
bins, and that -j64 run would be nicer.  The only reason why I didn’t push that 
patch up was I didn’t know of any such program.  :-(  I mention this in case 
someone knows of such a tool that is open source, hopefully GNU software.  The 
idea being, if a user has a 64 cores or want the .exp files to be more balanced 
on their target, they can be bothered to download the tool, don’t have it, and 
you get something a little more static.

Another way is to just make the buckets 60 seconds apiece.  This way, have  
nice box, 60 seconds to test, otherwise, the test time is at most 1 minute 
unbalanced.

Re: [PATCH ARM] Fix PR target/63209

[Richard Earnshaw]

On 09/09/14 19:45, Xinliang David Li wrote:
> Richard, thanks for the review. The revised patch is attached. Is this
> one OK (after testing is done)?
> 
> David
> 
> 

OK, but ...

> 2014-09-08  Xinliang David Li  
> 
> PR target/63209
> * config/arm/arm.md (movcond_addsi): Handle case where source
> and target operands are the same

Full stop at end of sentence.

> 
> 2014-09-08  Xinliang David Li  
> 
> PR target/63209
> * gcc.c-torture/execute/pr63209.c: New test
> 

Likewise.

> pr63209.txt
> 
> 
> Index: config/arm/arm.md
> ===
> --- config/arm/arm.md (revision 215039)
> +++ config/arm/arm.md (working copy)
> @@ -9328,10 +9328,16 @@
>  enum machine_mode mode = SELECT_CC_MODE (GET_CODE (operands[5]),
>operands[3], operands[4]);
>  enum rtx_code rc = GET_CODE (operands[5]);
> -
>  operands[6] = gen_rtx_REG (mode, CC_REGNUM);
>  gcc_assert (!(mode == CCFPmode || mode == CCFPEmode));
> -rc = reverse_condition (rc);
> +if (REGNO (operands[2]) != REGNO (operands[0]))
> +  rc = reverse_condition (rc);
> +else 
> +  {
> +rtx tmp = operands[1];
> + operands[1] = operands[2];
> + operands[2] = tmp;  

Please use tabs and white space consistently (use tabs).  Also, you seem
to have some trailing white space at the end of some lines.

> +  }
>  
>  operands[6] = gen_rtx_fmt_ee (rc, VOIDmode, operands[6], const0_rtx);
>}
> Index: testsuite/gcc.c-torture/execute/pr63209.c
> ===
> --- testsuite/gcc.c-torture/execute/pr63209.c (revision 0)
> +++ testsuite/gcc.c-torture/execute/pr63209.c (revision 0)
> @@ -0,0 +1,27 @@
> +static int Sub(int a, int b) {
> +  return  b -a;
> +}
> +
> +static unsigned Select(unsigned a, unsigned b, unsigned c) {
> +  const int pa_minus_pb =
> +  Sub((a >>  8) & 0xff, (b >>  8) & 0xff) + 
> +  Sub((a >>  0) & 0xff, (b >>  0) & 0xff); 
> +  return (pa_minus_pb <= 0) ? a : b;
> +}
> +
> +__attribute__((noinline)) unsigned Predictor(unsigned left, const unsigned* 
> const top) {
> +  const unsigned pred = Select(top[1], left, top[0]);
> +  return pred;
> +}
> +
> +int main(void) {
> +  const unsigned top[2] = {0xff7a7a7a, 0xff7a7a7a};
> +  const unsigned left = 0xff7b7b7b;
> +  const unsigned pred = Predictor(left, top /*+ 1*/);
> +  if (pred == left)
> +return 0;
> +  return 1;
> +}
> +
> +
> +
> 

Re: [PATCH] rs6000: Use xori for HTM builtins and vector compares

[Peter Bergner]

On Tue, 2014-09-09 at 19:28 -0400, David Edelsohn wrote:
> On Tue, Sep 9, 2014 at 3:29 PM, Segher Boessenkool
> > 2014-09-09  Segher Boessenkool  
> >
> > * config/rs6000/htm.md (tabort, tabortdc, tabortdci, tabortwc,
> > tabortwci, tbegin, tcheck, tend, trechkpt, treclaim, tsr): Use xor
> > instead of minus.
> > * config/rs6000/vector.md (cr6_test_for_zero_reverse,
> > cr6_test_for_lt_reverse): Ditto.
> 
> This is okay with me, but let me give Peter a chance to comment if
> there was a specific reason to use subfic instead of xori. This may
> have been a carry-over from Z, which does not have the same CA clobber
> issue.

Actually, I just copied the usage in cr6_test_for_zero_reverse and
cr6_test_for_lt_reverse, so I'm not against using xori...as long as
compiling a "if __builtin_tbegin (0) {...}" still ends up with a
.tbegin followed immediately by a branch (ie, no interleaving copy
from CR and compare instruction).

Peter

[jit] Merger from trunk into dmalcolm/jit

[David Malcolm]

I've merged svn trunk r215090 (2014-09-09) into the dmalcolm/jit git
branch [1], bringing in all changes since r203980 (2013-10-23); i.e.
about 10.5 months of changes from trunk.

Various manual fixes were necessary to enable the code to compile, and
for the test suite to run successfully.
With these changes, I see 4281 passes (and no failures) from jit.exp.

gcc/ChangeLog.jit:

* cgraph.c (cgraph_c_finalize): Update to reflect the movement of
many globals into fields of the "symtab" object.
* cgraphunit.c (graphunit_c_finalize): Likewise.
* symtab.c (symtab_c_finalize): Likewise.

* toplev.c (initialize_rtl): Move static local "initialized_once"
into file scope, and rename to...
(rtl_initialized): New variable.
(toplev::finalize): Clear rtl_initialized and
this_target_rtl->target_specific_initialized so that RTL will be
reinitialized when the compiler is run more than once in-process.

gcc/jit/ChangeLog.jit:

* dummy-frontend.c: Fix up for the header file flattening on
trunk by adding includes of signop.h, tree-core.h, stor-layout.h,
tree-ssa-alias.h, gimple-expr.h.
(jit_langhook_write_globals): Update call to
finalize_compilation_unit to symtab->finalize_compilation_unit to
track change made on trunk in r214422.

* internal-api.c: Fix up for the header file flattening on trunk
by adding includes of gimple-expr.h, tree-ssa-alias.h,
stringpool.h, stor-layout.h, print-tree.h, gimplify.h.
(new_rvalue_from_int): Update call to real_from_integer.
(gcc::jit::playback::wrapper::operator new): Use
ggc_internal_cleared_alloc rather than
ggc_internal_cleared_alloc_stat.
(gcc::jit::playback::function::postprocess): Update call to
cgraph_finalize_function tocgraph_node::finalize_function.
(gcc::jit::playback::block::add_comment): Update call to
ggc_internal_alloc_stat to ggc_internal_alloc.

gcc/testsuite/ChangeLog.jit:

* jit.dg/jit.exp: Load target-supports.exp.

Conflicts:
gcc/cgraph.h
gcc/cgraphunit.c
gcc/ipa-pure-const.c
gcc/ipa.c
gcc/symtab.c
gcc/toplev.c


[1] The commit in question is 7bc0466c739987845f0cd81354f414cd54d44e97.

[jit] Update the TODO

[David Malcolm]

Committed to branch dmalcolm/jit:

gcc/jit/ChangeLog.jit:

* TODO.rst (Test suite): Multithreaded test is done.
---
 gcc/jit/ChangeLog.jit | 4 
 gcc/jit/TODO.rst  | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 0e663cd..029e29a 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,9 @@
 2014-09-10  David Malcolm  
 
+   * TODO.rst (Test suite): Multithreaded test is done.
+
+2014-09-10  David Malcolm  
+
* dummy-frontend.c: Fix up for the header file flattening on
trunk by adding includes of signop.h, tree-core.h, stor-layout.h,
tree-ssa-alias.h, gimple-expr.h.
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index fd7b07c..ed8ffcc 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -104,10 +104,6 @@ Test suite
 ==
 * get DejaGnu to build and run C++ testcases
 
-* add a multi-threaded test (perhaps based on test-combination.c, with a
-  thread pool working through multiple instances of the various underlying
-  tests, each thread having a separate gcc_jit_context)
-
 Future milestones
 =
 * try porting llvmpipe to gcc
-- 
1.8.5.3

Re: [PATCHv2] Vimrc config with GNU formatting

[Segher Boessenkool]

On Wed, Sep 10, 2014 at 12:09:25PM +0400, Yury Gribov wrote:
> The patch caused a lively debate with Segher who wanted .local.vimrc to 
> not be enabled
> by default.

No, that is not what I said.  I am saying it is very anti-social to make
people's editor behave differently from what they are used to.  Wars have
been started for much less.

But there are more problems with your approach.  First, you are encouraging
the use of a plugin that is a gaping wide security hole.  I do not think
GCC should encourage this.

Secondly, this is a very poor imitation of the mechanism Vim has for dealing
with filetypes, namely, ftplugins.

> We basically have two options:
> 1) put .local.vimrc to root (just like .dir-locals.el config for Emacs)
> 2) put both .local.vimrc and .dir-locals.el to contrib and add Makefile 
> targets
> to create symlinks in root folder per user's request

As I said before, Emacs is not Vim.  The Emacs dir-locals file simply
configures some settings for files with certain major modes in that dir.
For example, ours says that c-mode files should use GNU style.  This is
quite harmless, and probably what most Emacs users want.

Your script on the other hand does something totally different: it overrides
a bunch of settings the user has made elsewhere.

[Snipped some overly optimistic stuff about this all increasing the quality
of posted patches.  Hint: the most frequently made formatting error is
forgetting to put two spaces at the end of a sentence.  Which this script
does not handle at all (I'm not saying it should, it is hard to do reliably).
The patch itself however does introduce another one of these.]


Segher

Re: [PATCH] rs6000: Use xori for HTM builtins and vector compares

[Segher Boessenkool]

On Wed, Sep 10, 2014 at 01:38:13PM -0500, Peter Bergner wrote:
> On Tue, 2014-09-09 at 19:28 -0400, David Edelsohn wrote:
> > On Tue, Sep 9, 2014 at 3:29 PM, Segher Boessenkool
> > > 2014-09-09  Segher Boessenkool  
> > >
> > > * config/rs6000/htm.md (tabort, tabortdc, tabortdci, tabortwc,
> > > tabortwci, tbegin, tcheck, tend, trechkpt, treclaim, tsr): Use xor
> > > instead of minus.
> > > * config/rs6000/vector.md (cr6_test_for_zero_reverse,
> > > cr6_test_for_lt_reverse): Ditto.
> > 
> > This is okay with me, but let me give Peter a chance to comment if
> > there was a specific reason to use subfic instead of xori. This may
> > have been a carry-over from Z, which does not have the same CA clobber
> > issue.
> 
> Actually, I just copied the usage in cr6_test_for_zero_reverse and
> cr6_test_for_lt_reverse, so I'm not against using xori...as long as
> compiling a "if __builtin_tbegin (0) {...}" still ends up with a
> .tbegin followed immediately by a branch (ie, no interleaving copy
> from CR and compare instruction).

Huh, interesting.  I assumed 1-(0_or_1) and (0_or_1)^1 would look the
same to combine, but no.

With subfic, combine optimises it all to a branch on cr0.  With xori,
for some reason combine has a much easier job, and it optimises the lot
to a copy of cr0 to some cc, and then branch on that.  The RA of course
gets rid of the copy.  The extra freedom will more likely help than hurt.

The simple testcase ends up as just "tbegin. 0; beqlr 0" in either case.

So, okay?


Segher

Committed: update simtest-howto.html

[Hans-Peter Nilsson]

(Thanks to people CC'ed and others forgotten; I hope I
incorporated at least some of everyone's suggestions.)

First, as noted, the instructions are outdated due to repos merging,
splitting, moving and switching, with fallout such as it now seemed
odd as-is with one minor component randomly being named "src".  (It's
a CVS artefact: when the "-d topdir" option is used, cvs-1.11.22 gets
confused over the "newlib" subdirectory different to the "newlib" CVS
module; add -N and you get the "src" subdirectory anyway, within
"topdir".  Love CVS!  If someone has a simple working solution just
using options and it works for me too, we can call the newlib topdir
something else than "src".  In the meantime, not going there.)

There was other outdated information, such as gcc-2.95 being a valid
host-gcc.  Hah!  Better point to the general build prerequisites.

Also, the idea of using a *combined* tree here, has been challenged,
so I toned down the wording from the actual "require" to the
negation(!)  and added an apologetic blurb.  (For my own autotester, I
use a separate install as mentioned in the blurb, if only to simplify
not depending on a simultaneous working state, but I wouldn't do a
separate build just for newlib, so some kind of combination
instructions seems called for anyway.)

There has also historically been people doing their edits in the
combined tree.  (Understandable; that's where gdb points...)
Better add a few words about that.

With the combined binutils-gdb.git used as-is, now GDB has to be
manually disabled so we don't have to worry about its target
obsoletion triggers.  The gdb we're likely to use it probably the host
gdb anyway.  (If it's recent enough that is; if not, it might be a
good idea to install a native build somewhere locally, to apply on the
cross-gcc.)

Also arm-elf is obsoleted, so let's choose arm-eabi for the example.
Except when trying that, thebuild gets lost building libjava.

(Target maintainers: don't be afraid to add a clause for your target
in the *first* case in top/configure.ac where unsupported_languages is
set for a target, for languages you never use and never intend to
build.  For example, I know vax should do a
'unsupported_languages="$unsupported_languages
"', as last time I checked, it didn't build for
c++ and when checked, only C support was intended.)

Rather than choosing a target which mostly by coincidence doesn't
enable java (lack of libffi), I just added a language option to make
it more likely for a random build for a random target to complete.
ISTR reports to the gcc-testresults@ for several targets but just for
c and c++ enabled.  If you think this is a bad move, I'd value work
fixing the situation in the right way (see above) higher than just an
opinion.  Also, the reason is explained and people are free to not use
--enable-languages when testing.  I see mcore-elf build; I could use
that instead but let's not go to far off main-stream.  I could use
cris-elf if I also wanted decent test-results, but I'm probably too
biased to offer that with a straight face. ;)

As a future step, we may want to just drop the status-ish table at the
end, for one it's out of date by a decade.

Briefly watched locally, committed; watched again on-line to catch
glaring mark-up errors.

Index: simtest-howto.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/simtest-howto.html,v
retrieving revision 1.29
retrieving revision 1.30
diff -p -u -r1.29 -r1.30
--- simtest-howto.html  27 Jun 2014 11:48:46 -  1.29
+++ simtest-howto.html  10 Sep 2014 19:37:25 -  1.30
@@ -16,22 +16,32 @@

 Set up sources

-Testing with a simulator requires use of a combined tree;
+Testing with a simulator makes use of a combined tree here;
 you can't easily build newlib, required for simulator testing,
 outside of a combined tree, and the build of the other components
-is easiest in a combined tree.
+is easiest in a combined tree.  A combined tree is not a
+requirement for testing with a simulator; other alternatives
+exist.  For example, binutils and simulators can be built for the
+target, and installed beforehand.  However, we use a combined tree
+here as it's a convenient example and does not require separate
+installation steps or parameters.

-The combined tree contains GCC sources plus several modules of
-the src tree: binutils and
-newlib for the build and sim for the
+The combined tree contains GCC sources plus binutils and
+newlib for the generated code and sim for the
 simulators. If you already build with a combined tree you can use
 your current setup; if not, these instructions will get you the
 sources you need.

-Check out initial CVS trees
+

-If you don't yet have either tree you'll need to do an initial
-check-outs.
+Check out initial trees
+
+We check out each component from each separate project's
+version-c

Re: [PATCH ARM] Fix PR target/63209

[Xinliang David Li]

Fixed the formatting and committed it to trunk: r215136. Will backport
it to gcc-4_9 branch.

thanks,

David


On Wed, Sep 10, 2014 at 11:24 AM, Richard Earnshaw  wrote:
> On 09/09/14 19:45, Xinliang David Li wrote:
>> Richard, thanks for the review. The revised patch is attached. Is this
>> one OK (after testing is done)?
>>
>> David
>>
>>
>
> OK, but ...
>
>> 2014-09-08  Xinliang David Li  
>>
>> PR target/63209
>> * config/arm/arm.md (movcond_addsi): Handle case where source
>> and target operands are the same
>
> Full stop at end of sentence.
>
>>
>> 2014-09-08  Xinliang David Li  
>>
>> PR target/63209
>> * gcc.c-torture/execute/pr63209.c: New test
>>
>
> Likewise.
>
>> pr63209.txt
>>
>>
>> Index: config/arm/arm.md
>> ===
>> --- config/arm/arm.md (revision 215039)
>> +++ config/arm/arm.md (working copy)
>> @@ -9328,10 +9328,16 @@
>>  enum machine_mode mode = SELECT_CC_MODE (GET_CODE (operands[5]),
>>operands[3], operands[4]);
>>  enum rtx_code rc = GET_CODE (operands[5]);
>> -
>>  operands[6] = gen_rtx_REG (mode, CC_REGNUM);
>>  gcc_assert (!(mode == CCFPmode || mode == CCFPEmode));
>> -rc = reverse_condition (rc);
>> +if (REGNO (operands[2]) != REGNO (operands[0]))
>> +  rc = reverse_condition (rc);
>> +else
>> +  {
>> +rtx tmp = operands[1];
>> + operands[1] = operands[2];
>> + operands[2] = tmp;
>
> Please use tabs and white space consistently (use tabs).  Also, you seem
> to have some trailing white space at the end of some lines.
>
>> +  }
>>
>>  operands[6] = gen_rtx_fmt_ee (rc, VOIDmode, operands[6], const0_rtx);
>>}
>> Index: testsuite/gcc.c-torture/execute/pr63209.c
>> ===
>> --- testsuite/gcc.c-torture/execute/pr63209.c (revision 0)
>> +++ testsuite/gcc.c-torture/execute/pr63209.c (revision 0)
>> @@ -0,0 +1,27 @@
>> +static int Sub(int a, int b) {
>> +  return  b -a;
>> +}
>> +
>> +static unsigned Select(unsigned a, unsigned b, unsigned c) {
>> +  const int pa_minus_pb =
>> +  Sub((a >>  8) & 0xff, (b >>  8) & 0xff) +
>> +  Sub((a >>  0) & 0xff, (b >>  0) & 0xff);
>> +  return (pa_minus_pb <= 0) ? a : b;
>> +}
>> +
>> +__attribute__((noinline)) unsigned Predictor(unsigned left, const unsigned* 
>> const top) {
>> +  const unsigned pred = Select(top[1], left, top[0]);
>> +  return pred;
>> +}
>> +
>> +int main(void) {
>> +  const unsigned top[2] = {0xff7a7a7a, 0xff7a7a7a};
>> +  const unsigned left = 0xff7b7b7b;
>> +  const unsigned pred = Predictor(left, top /*+ 1*/);
>> +  if (pred == left)
>> +return 0;
>> +  return 1;
>> +}
>> +
>> +
>> +
>>
>
>

Re: Committed: update simtest-howto.html

[Oleg Endo]

Hi,

On Wed, 2014-09-10 at 15:46 -0400, Hans-Peter Nilsson wrote:
> (Thanks to people CC'ed and others forgotten; I hope I
> incorporated at least some of everyone's suggestions.)
> 
> [...]
> Also, the idea of using a *combined* tree here, has been challenged,
> so I toned down the wording from the actual "require" to the
> negation(!)  and added an apologetic blurb.

It says:
"Testing with a simulator makes use of a combined tree here; you can't
easily build newlib, required for simulator testing,..."

I don't understand why newlib can't be built for simulator testing
easily outside of a combined tree.  Are you referring to the separate
make all-gcc - build newlib - continue with full gcc build?  Or is it
just a coincidence that it works rather easily on SH?

" other alternatives exist. For example, binutils and simulators can be
built for the target, and installed beforehand."

I still think we should somehow document how to do that.  The info is
scattered out there on the net, but it'd be easier to have it on the
official doc pages.

Cheers,
Oleg

[PATCH], Fix constraints on VSX Fma, Fix, and Reduce options

[Michael Meissner]

In doing work on improving power8 fusion support, I noticed that in several of
the patterns (vector fused multiply-add, optimization of float (fix (x)), and
vector reduction), I used the "ws" constraint which is the constraint for
scalar double precision floating point (currently FLOAT_REGS) in cases where
the operand is a vector, where we should use "wd" (preferred constraint for
V2DF), "wf" (preferred constraint for V4SF) or even "wa" (any VSX register).
This means the register allocator might generate extra code due to preferring
the traditional floating point registers.

I was curious about the code generation changes, so I built power8 versions of
the Spec 2006 benchmark suite, and compared the number of instructions
generated, using the same options.  Most of the floating point benchmarks had
some changes in code generation, including fewer scalar floating loads/stores
(where the RA picked a traditional scalar register, which meant elsewere a
scalar was spilled to the stack), and different encodings of the FMA
instructions.

I did a run of the FP spec benchmarks on a big endian power8 system.  There
were no regressions that were significant, and the cactusADM benchmark sped up
by 2%.

I did a bootstrap/make check comparison, and there were no regressions.  Is it
ok to install in trunk and the active PowerPC branches?

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 214455)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -905,11 +905,11 @@ (define_insn "*vsx_tsqrt2_internal
 ;; multiply.
 
 (define_insn "*vsx_fmav4sf4"
-  [(set (match_operand:V4SF 0 "vsx_register_operand" "=ws,ws,?wa,?wa,v")
+  [(set (match_operand:V4SF 0 "vsx_register_operand" "=wf,wf,?wa,?wa,v")
(fma:V4SF
- (match_operand:V4SF 1 "vsx_register_operand" "%ws,ws,wa,wa,v")
- (match_operand:V4SF 2 "vsx_register_operand" "ws,0,wa,0,v")
- (match_operand:V4SF 3 "vsx_register_operand" "0,ws,0,wa,v")))]
+ (match_operand:V4SF 1 "vsx_register_operand" "%wf,wf,wa,wa,v")
+ (match_operand:V4SF 2 "vsx_register_operand" "wf,0,wa,0,v")
+ (match_operand:V4SF 3 "vsx_register_operand" "0,wf,0,wa,v")))]
   "VECTOR_UNIT_VSX_P (V4SFmode)"
   "@
xvmaddasp %x0,%x1,%x2
@@ -920,11 +920,11 @@ (define_insn "*vsx_fmav4sf4"
   [(set_attr "type" "vecfloat")])
 
 (define_insn "*vsx_fmav2df4"
-  [(set (match_operand:V2DF 0 "vsx_register_operand" "=ws,ws,?wa,?wa")
+  [(set (match_operand:V2DF 0 "vsx_register_operand" "=wd,wd,?wa,?wa")
(fma:V2DF
- (match_operand:V2DF 1 "vsx_register_operand" "%ws,ws,wa,wa")
- (match_operand:V2DF 2 "vsx_register_operand" "ws,0,wa,0")
- (match_operand:V2DF 3 "vsx_register_operand" "0,ws,0,wa")))]
+ (match_operand:V2DF 1 "vsx_register_operand" "%wd,wd,wa,wa")
+ (match_operand:V2DF 2 "vsx_register_operand" "wd,0,wa,0")
+ (match_operand:V2DF 3 "vsx_register_operand" "0,wd,0,wa")))]
   "VECTOR_UNIT_VSX_P (V2DFmode)"
   "@
xvmaddadp %x0,%x1,%x2
@@ -1360,8 +1360,8 @@ (define_insn "*vsx_float_fix_2"
 (define_insn "vsx_concat_"
   [(set (match_operand:VSX_D 0 "vsx_register_operand" "=,?")
(vec_concat:VSX_D
-(match_operand: 1 "vsx_register_operand" "ws,")
-(match_operand: 2 "vsx_register_operand" "ws,")))]
+(match_operand: 1 "vsx_register_operand" ",")
+(match_operand: 2 "vsx_register_operand" 
",")))]
   "VECTOR_MEM_VSX_P (mode)"
 {
   if (BYTES_BIG_ENDIAN)
@@ -2018,7 +2018,7 @@ (define_insn_and_split "*vsx_reduc__v2df_scalar"
-  [(set (match_operand:DF 0 "vfloat_operand" "=&ws,&?wa,ws,?wa")
+  [(set (match_operand:DF 0 "vfloat_operand" "=&ws,&?ws,ws,?ws")
(vec_select:DF
 (VEC_reduc:V2DF
  (vec_concat:V2DF

Re: [PATCH] rs6000: Use xori for HTM builtins and vector compares

[Peter Bergner]

On Wed, 2014-09-10 at 14:29 -0500, Segher Boessenkool wrote:
> Huh, interesting.  I assumed 1-(0_or_1) and (0_or_1)^1 would look the
> same to combine, but no.
> 
> With subfic, combine optimises it all to a branch on cr0.  With xori,
> for some reason combine has a much easier job, and it optimises the lot
> to a copy of cr0 to some cc, and then branch on that.  The RA of course
> gets rid of the copy.  The extra freedom will more likely help than hurt.
> 
> The simple testcase ends up as just "tbegin. 0; beqlr 0" in either case.
> 
> So, okay?

No objections from me then.

Peter

RE: [PATCH] RE: gcc parallel make check

[VandeVondele Joost]

> You mean enhancing the script to split across arbitrarily long prefixes?
> That would be great.

I've now a script that does something like that:

~/test$ find /data/vjoost/gnu/gcc_trunk/gcc/gcc/testsuite/gfortran.dg/ 
-maxdepth 1 -type f -printf "%f\n" | ./generate_patterns.py 500 foo
All  3947  files matched the pattern ^[0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+ 
without exception
Final  12  patterns and match count:
(^[j-z_#+-][p-z_#+-][0-9A-Za-i][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+|^[j-z_#+-][0-9A-Za-o][0-9A-Za-m]([.][0-9A-Za-z_#+-]+)+)
  matching  469  files
(^[0-9A-Za-i][0-9A-Za-n][0-9A-Za-n][0-9A-Za-o][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+|^([.][0-9A-Za-z_#+-]+)+)
  matching  433  files
(^[j-z_#+-][0-9A-Za-o][n-z_#+-][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+|^[0-9A-Za-i][0-9A-Za-n][o-z_#+-]([.][0-9A-Za-z_#+-]+)+)
  matching  400  files
(^[j-z_#+-][p-z_#+-][j-z_#+-][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+|^[0-9A-Za-i]([.][0-9A-Za-z_#+-]+)+)
  matching  371  files
(^[0-9A-Za-i][o-z_#+-][s-z_#+-][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+|^[0-9A-Za-i][0-9A-Za-n][0-9A-Za-n]([.][0-9A-Za-z_#+-]+)+)
  matching  323  files
(^[0-9A-Za-i][o-z_#+-][0-9A-Za-r][o-z_#+-][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+|^[j-z_#+-][p-z_#+-]([.][0-9A-Za-z_#+-]+)+)
  matching  314  files
(^[0-9A-Za-i][o-z_#+-][0-9A-Za-r][0-9A-Za-n][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+|^[j-z_#+-][0-9A-Za-o]([.][0-9A-Za-z_#+-]+)+)
  matching  314  files
(^[j-z_#+-][0-9A-Za-o][0-9A-Za-m][0-9A-Za-i][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+|^[j-z_#+-]([.][0-9A-Za-z_#+-]+)+)
  matching  272  files
(^[0-9A-Za-i][0-9A-Za-n][0-9A-Za-n][p-z_#+-][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+|^[0-9A-Za-i][o-z_#+-]([.][0-9A-Za-z_#+-]+)+)
  matching  270  files
(^[0-9A-Za-i][0-9A-Za-n][o-z_#+-][0-9A-Za-l][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+|^[0-9A-Za-i][0-9A-Za-n]([.][0-9A-Za-z_#+-]+)+)
  matching  265  files
(^[0-9A-Za-i][0-9A-Za-n][o-z_#+-][m-z_#+-][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+|^[0-9A-Za-i][o-z_#+-][0-9A-Za-r]([.][0-9A-Za-z_#+-]+)+)
  matching  260  files
^[j-z_#+-][0-9A-Za-o][0-9A-Za-m][j-z_#+-][0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+ 
 matching  256  files

It is a set of patterns that will match any file of the form 
'^[0-9A-Za-z_#+-]*([.][0-9A-Za-z_#+-]+)+', but such that it splits a list of 
input files roughly in equal chunks (e.g. between 500 and 500/2 in this 
example), even if files have long overlapping prefixes. However, I'm unsure 
if/how this can be integrated, i.e. what precisely is allowed for testsuite 
filenames, and if this regexp format can be employed in gcc makefiles / tcl / 
expect harness, suggestions/help appreciated.

Re: [PATCH] gcc parallel make check

[David Malcolm]

On Wed, 2014-09-10 at 11:19 -0700, Mike Stump wrote:
> On Sep 9, 2014, at 8:14 AM, VandeVondele Joost
>  wrote:
> > Attached is a further revision of the patch, now dealing with
> check-c++.
> 
> So when last I played in this area, I wanted a command line tool that
> would bin-pack from the command line.  I would then grab the seconds
> per for each .exp, and bin pack to the fixed N, where N was the core
> count or related to it like, like N+1, N*1.1+1, N*2, ceil(N*1.1)).
> Then, I would just have 60-100 bins, and that -j64 run would be nicer.
> The only reason why I didn’t push that patch up was I didn’t know of
> any such program.  :-(  I mention this in case someone knows of such a
> tool that is open source, hopefully GNU software.  The idea being, if
> a user has a 64 cores or want the .exp files to be more balanced on
> their target, they can be bothered to download the tool, don’t have
> it, and you get something a little more static.
> 
> Another way is to just make the buckets 60 seconds apiece.  This way,
> have  nice box, 60 seconds to test, otherwise, the test time is at
> most 1 minute unbalanced.

Perhaps this is a silly question, but has anyone tried going the whole
way and not having buckets, going to an extremely fine-grained approach:
split out all of the dj work into three phases:
(A) test discovery; write out a fine-grained Makefile in which *every*
testcase is its own make target (to the extreme limit of
parallelizability e.g. on the per-input-file level)
(B) invoke the Makefile, with -jN; each make target invokes dejagnu for
an individual testcase, and gets its own .log file
(C) combine the results

That way all parallelization in (B) relies on "make" to do the right
thing in terms of total number running jobs, available cores, load
average etc, albeit with a performance hit for all of the extra
reinvocations of "expect" (and a reordering of the results, but we can
impose a stable sort in phase (C) I guess).

Has anyone tried this?

Hope this is constructive
Dave

Re: [PATCH], Fix constraints on VSX Fma, Fix, and Reduce options

[David Edelsohn]

On Wed, Sep 10, 2014 at 4:16 PM, Michael Meissner
 wrote:
> In doing work on improving power8 fusion support, I noticed that in several of
> the patterns (vector fused multiply-add, optimization of float (fix (x)), and
> vector reduction), I used the "ws" constraint which is the constraint for
> scalar double precision floating point (currently FLOAT_REGS) in cases where
> the operand is a vector, where we should use "wd" (preferred constraint for
> V2DF), "wf" (preferred constraint for V4SF) or even "wa" (any VSX register).
> This means the register allocator might generate extra code due to preferring
> the traditional floating point registers.
>
> I was curious about the code generation changes, so I built power8 versions of
> the Spec 2006 benchmark suite, and compared the number of instructions
> generated, using the same options.  Most of the floating point benchmarks had
> some changes in code generation, including fewer scalar floating loads/stores
> (where the RA picked a traditional scalar register, which meant elsewere a
> scalar was spilled to the stack), and different encodings of the FMA
> instructions.
>
> I did a run of the FP spec benchmarks on a big endian power8 system.  There
> were no regressions that were significant, and the cactusADM benchmark sped up
> by 2%.
>
> I did a bootstrap/make check comparison, and there were no regressions.  Is it
> ok to install in trunk and the active PowerPC branches?

Needs a ChangeLog.

Okay.

thanks, David

Re: [PATCH], Fix constraints on VSX Fma, Fix, and Reduce options

[Michael Meissner]

On Wed, Sep 10, 2014 at 04:42:06PM -0400, David Edelsohn wrote:
> Needs a ChangeLog.

Whoops, I forgot to include it:

2014-09-10  Michael Meissner  

* config/rs6000/vsx.md (vsx_fmav4sf4): Use correct constraints for
V2DF, V4SF, DF, and DI modes.
(vsx_fmav2df2): Likewise.
(vsx_float_fix_2): Likewise.
(vsx_reduc__v2df_scalar): Likewise.


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

[Bug libstdc++/62313] Data race in debug iterators

[François Dumont]

Hi

Here is a proposal to fix this data race issue.

I finally generalized bitset approach to fix it by inheriting from 
the normal iterator first and then the _Safe_iterator_base type. None of 
the libstdc++ iterator types are final so it is fine. Surprisingly, 
despite inheritance being private gcc got confused between 
_Safe_iterator_base _M_next and forward_list _M_next so I need to adapt 
some code to make usage of _Safe_iterator_base _M_next explicit.


I also consider any operator where normal iterator is being 
modified while the safe iterator is linked to the list of iterators. 
This is necessary to make sure that thread sanatizer won't consider a 
race condition. I didn't touch to bitset::reference because list 
references are only access on bitset destruction which is clearly not an 
operation allowed to do while playing with references in another thread.


Do you see any way to check for this problem in the testsuite ? Is 
there a thread sanitizer we could use ?


2014-09-10  François Dumont  

PR libstdc++/62313
* include/debug/safe_base.h
(_Safe_iterator_base(const _Safe_iterator_base&)): Delete declaration.
(_Safe_iterator_base& operator=(const _Safe_iterator_base&)): Likewise.
* include/debug/safe_iterator.h (_Safe_iterator<>): Move normal 
iterator
before _Safe_iterator_base in memory. Lock before modifying the 
iterator

in numerous places.
* include/debug/safe_local_iterator.h
(_Safe_local_iterator_base(const _Safe_local_iterator_base&)): Delete
declaration.
(_Safe_local_iterator_base& operator=(const 
_Safe_local_iterator_base&)):

Likewise.
* include/debug/safe_unordered_base.h (_Safe_local_iterator<>):  Move
normal iterator before _Safe_iterator_base in memory. Lock before
modifying the iterator in numerous places.
* include/debug/forward_list (_Safe_forward_list<>::_M_swap_aux): 
Adapt.

* include/debug/safe_sequence.tcc
(_Safe_sequence<>::_M_transfer_from_if): Adapt.

Tested under Linux x86_64 debug mode.

Ok to commit ?

François
Index: include/debug/forward_list
===
--- include/debug/forward_list	(revision 215134)
+++ include/debug/forward_list	(working copy)
@@ -86,24 +86,26 @@
   for (_Safe_iterator_base* __iter = __lhs_iterators; __iter;)
 	{
 	  // Even iterator is cast to const_iterator, not a problem.
-	  const_iterator* __victim = static_cast(__iter);
+	  _Safe_iterator_base* __victim_base = __iter;
+	  const_iterator* __victim =
+	static_cast(__victim_base);
 	  __iter = __iter->_M_next;
 	  if (__victim->base() == __rseq._M_base().cbefore_begin())
 	{
 	  __victim->_M_unlink();
-	  if (__lhs_iterators == __victim)
-		__lhs_iterators = __victim->_M_next;
+	  if (__lhs_iterators == __victim_base)
+		__lhs_iterators = __victim_base->_M_next;
 	  if (__bbegin_its)
 		{
-		  __victim->_M_next = __bbegin_its;
-		  __bbegin_its->_M_prior = __victim;
+		  __victim_base->_M_next = __bbegin_its;
+		  __bbegin_its->_M_prior = __victim_base;
 		}
 	  else
-		__last_bbegin = __victim;
-	  __bbegin_its = __victim;
+		__last_bbegin = __victim_base;
+	  __bbegin_its = __victim_base;
 	}
 	  else
-	__victim->_M_sequence = &__lhs;
+	__victim_base->_M_sequence = &__lhs;
 	}
 
   if (__bbegin_its)
Index: include/debug/safe_base.h
===
--- include/debug/safe_base.h	(revision 215134)
+++ include/debug/safe_base.h	(working copy)
@@ -95,12 +95,6 @@
 : _M_sequence(0), _M_version(0), _M_prior(0), _M_next(0)
 { this->_M_attach(__x._M_sequence, __constant); }
 
-_Safe_iterator_base&
-operator=(const _Safe_iterator_base&);
-
-explicit
-_Safe_iterator_base(const _Safe_iterator_base&);
-
 ~_Safe_iterator_base() { this->_M_detach(); }
 
 /** For use in _Safe_iterator. */
Index: include/debug/safe_iterator.h
===
--- include/debug/safe_iterator.h	(revision 215134)
+++ include/debug/safe_iterator.h	(working copy)
@@ -109,16 +109,21 @@
*  %_Safe_iterator has member functions for iterator invalidation,
*  attaching/detaching the iterator from sequences, and querying
*  the iterator's state.
+   *
+   *  Note that _Iterator must rely first in the type memory layout so that it
+   *  gets initialized before the iterator is being attached to the container
+   *  list of iterators and it is being dettached before _Iterator get
+   *  destroy. Otherwise it would result in a data race.
*/
   template
-class _Safe_iterator : public _Safe_iterator_base
+class _Safe_iterator
+: private _Iterator,
+  public _Safe_iterator_base
 {
-  typedef _Safe_iterator _Self;
+  typedef _Iterator _Ite_base;
+  typedef _Safe_iterator_base _Safe_base;
   typedef typename _Sequence::const_iterator _Const_iterator;
 
- 

Re: Committed: update simtest-howto.html

[Hans-Peter Nilsson]

On Wed, 10 Sep 2014, Oleg Endo wrote:
> On Wed, 2014-09-10 at 15:46 -0400, Hans-Peter Nilsson wrote:
> > (Thanks to people CC'ed and others forgotten; I hope I
> > incorporated at least some of everyone's suggestions.)
> >
> > [...]
> > Also, the idea of using a *combined* tree here, has been challenged,
> > so I toned down the wording from the actual "require" to the
> > negation(!)  and added an apologetic blurb.
>
> It says:
> "Testing with a simulator makes use of a combined tree here; you can't
> easily build newlib, required for simulator testing,..."
>
> I don't understand why newlib can't be built for simulator testing
> easily outside of a combined tree.

Why would that be an improvement?  At most it'd be break-even.

>  Are you referring to the separate
> make all-gcc - build newlib - continue with full gcc build?

It's not clear to me what you mean and I haven't done a build
from newlib sources separate from gcc in any way.  It seems to
add at least one step and just remove the merge of the newlib
tree.  You'd also have to point at the newlib sources with
separate configure-options.  Why a separate "make all-gcc" if
you can point it at the newlib sources from the beginning?
Maybe it's still easier than "can't easily", maybe better with
some other wording?  I forgot to say "suggestions are welcome"
(but wholesale rewrites aren't, sorry for sounding apologetic).

>  Or is it
> just a coincidence that it works rather easily on SH?

I don't know, have you actually tried it on other targets?
I'd suggest you do that before any improvement suggestion.
(I built arm-eabi and mcore-elf with the updated
simtest-howto.html)

Have you inspected the configuration and build logs? I see
sh-elf doesn't use libgloss, so I'm leaning towards a tentative
"yes" to your question.

> " other alternatives exist. For example, binutils and simulators can be
> built for the target, and installed beforehand."
>
> I still think we should somehow document how to do that.

I assume you mean the general configure && make all install, as in
binu+gdb/configure --target=... --prefix=... && make all install
(Not forgetting to include .../bin in your $PATH.)

>  The info is
> scattered out there on the net, but it'd be easier to have it on the
> official doc pages.

Maybe but please put that in the official documentation.

This page isn't that; that'd be in the .texi pages or maybe the
wiki depending on your taste.  This is not the "build and
install a simulator toolchain to develop your own programs"
documentation, this is the "build a simulator to test gcc"
howto.  IMO this page will not improve by adding detailed
instructions for several alternatives.  The intended audience is
people working on gcc but just about grasping the concept of a
cross-compiler and who actually wants a reasonably simple way to
test their patches on a wider set of targets than their native
x86_64 box.

brgds, H-P

Re: [PATCH] gcc parallel make check

[Mike Stump]

On Sep 10, 2014, at 1:38 PM, David Malcolm  wrote:
> Perhaps this is a silly question, but has anyone tried going the whole
> way and not having buckets, going to an extremely fine-grained approach

No, we fear the overhead, but do not know what it is.

Re: [PATCH] gcc parallel make check

[Joseph S. Myers]

On Wed, 10 Sep 2014, David Malcolm wrote:

> (A) test discovery; write out a fine-grained Makefile in which *every*
> testcase is its own make target (to the extreme limit of
> parallelizability e.g. on the per-input-file level)

The DejaGnu design doesn't allow test discovery in general (as the set of 
tests can depend on the results of previous tests; tests are run through 
arbitrary Tcl code in .exp files which both enumerates them and runs 
them).  Hopefully the GCC tests are well enough structured not to run into 
this problem.

(Being able to enumerate tests separately from running them, and to run 
each test independently, is the QMTest model, though there are other 
issues with how that handles some things that come up in toolchain 
testing.)

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

Re: [PATCH] gcc parallel make check

[Jakub Jelinek]

On Wed, Sep 10, 2014 at 04:38:32PM -0400, David Malcolm wrote:
> > So when last I played in this area, I wanted a command line tool that
> > would bin-pack from the command line.  I would then grab the seconds
> > per for each .exp, and bin pack to the fixed N, where N was the core
> > count or related to it like, like N+1, N*1.1+1, N*2, ceil(N*1.1)).
> > Then, I would just have 60-100 bins, and that -j64 run would be nicer.
> > The only reason why I didn’t push that patch up was I didn’t know of
> > any such program.  :-(  I mention this in case someone knows of such a
> > tool that is open source, hopefully GNU software.  The idea being, if
> > a user has a 64 cores or want the .exp files to be more balanced on
> > their target, they can be bothered to download the tool, don’t have
> > it, and you get something a little more static.
> > 
> > Another way is to just make the buckets 60 seconds apiece.  This way,
> > have  nice box, 60 seconds to test, otherwise, the test time is at
> > most 1 minute unbalanced.
> 
> Perhaps this is a silly question, but has anyone tried going the whole
> way and not having buckets, going to an extremely fine-grained approach:
> split out all of the dj work into three phases:
> (A) test discovery; write out a fine-grained Makefile in which *every*
> testcase is its own make target (to the extreme limit of
> parallelizability e.g. on the per-input-file level)
> (B) invoke the Makefile, with -jN; each make target invokes dejagnu for
> an individual testcase, and gets its own .log file
> (C) combine the results
> 
> That way all parallelization in (B) relies on "make" to do the right
> thing in terms of total number running jobs, available cores, load
> average etc, albeit with a performance hit for all of the extra
> reinvocations of "expect" (and a reordering of the results, but we can
> impose a stable sort in phase (C) I guess).
> 
> Has anyone tried this?

I fear that is going to be too expensive, because e.g. all the caching that
dejagnu and our tcl stuff does would be gone, all the tests for lp64 etc.
would need to be repeated for each test.

Perhaps better approach might be if we have some way how to synchronize among
multiple expect processes and spawn only as many expects (of course, per
check target) as there are CPUs.  E.g. if mkdir is atomic on all
hosts/filesystems we care about, we could have some shared directory that
make would clear before spawning all the expects, and after checking
runtest_file_p we could attempt to mkdir something (e.g. testcase filename
with $(srcdir) part removed, or *.exp filename / counter what test are we
considering or something similar) in the shared directory, if that would
succeed, it would tell us that we are the process that should run the test,
if that failed, we'd know some other runtest did that.
Or perhaps not for every single test, but every 10 or 100 tests or
something.

E.g. we could just override runtest_file_p itself, so that it would first
call the original dejagnu version, and then do this check.

Jakub

PR 63186 (fnsplit and forced labels)

[Jan Hubicka]

Hi,
this patch fixes the testcasein PR63186. Here a forced label is used and fnsplit
decides to split its use from definition that does not work.  There is code that
is supposed to prevent this. It however works on non-ssa declarations in general
and it has an optimization - it allows the non-ssa declarations to be split when
their liveranes do not overlap by skipping all the definitions in header
parts that do not lead to function call.  This doesn't work for labels: we 
really
want to consider all label definitions in this case.

I also added minor optimization skipping all non-forced labels to save non-ssa
verficiation pass when there are no non-ssa vars involved (the common case)

Bootstrapped/regtested x86_64-linux, will commit it tomorrow if there are
no complains.

Honza
PR tree-optimization/63186
* gcc.dg/pr63186.c: New testcase.
* ipa-split.c (test_nonssa_use): Skip non-forced labels.
(verify_non_ssa_vars): Verify blocks not leading to the call
for label definitions.
(mark_nonssa_use): Skip non-forced labels.
Index: testsuite/gcc.dg/pr63186.c
===
--- testsuite/gcc.dg/pr63186.c  (revision 0)
+++ testsuite/gcc.dg/pr63186.c  (revision 0)
@@ -0,0 +1,30 @@
+/* { dg-do link } */
+/* { dg-options "-O2" } */
+void *a;
+int b, c, d;
+
+void
+bar ()
+{
+  switch (c)
+{
+case 0:
+lab:
+  __asm__ ("");
+  return;
+default:
+  break;
+}
+  b = 0;
+  d = 0;
+  a = &&lab;
+}
+
+void
+foo ()
+{
+  bar ();
+}
+main()
+{
+}
Index: ipa-split.c
===
--- ipa-split.c (revision 215104)
+++ ipa-split.c (working copy)
@@ -167,7 +167,11 @@ test_nonssa_use (gimple, tree t, tree, v
   || (TREE_CODE (t) == VAR_DECL
  && auto_var_in_fn_p (t, current_function_decl))
   || TREE_CODE (t) == RESULT_DECL
-  || TREE_CODE (t) == LABEL_DECL)
+/* Normal labels are part of CFG and will be handled gratefuly.
+   Forced labels however can be used directly by statements and
+   need to stay in one partition along with their uses.  */
+  || (TREE_CODE (t) == LABEL_DECL
+ && FORCED_LABEL (t)))
 return bitmap_bit_p ((bitmap)data, DECL_UID (t));
 
   /* For DECL_BY_REFERENCE, the return value is actually a pointer.  We want
@@ -213,6 +217,7 @@ verify_non_ssa_vars (struct split_point
   edge e;
   edge_iterator ei;
   bool ok = true;
+  basic_block bb;
 
   FOR_EACH_EDGE (e, ei, current->entry_bb->preds)
 if (e->src != ENTRY_BLOCK_PTR_FOR_FN (cfun)
@@ -225,8 +230,8 @@ verify_non_ssa_vars (struct split_point
   while (!worklist.is_empty ())
 {
   gimple_stmt_iterator bsi;
-  basic_block bb = worklist.pop ();
 
+  bb = worklist.pop ();
   FOR_EACH_EDGE (e, ei, bb->preds)
if (e->src != ENTRY_BLOCK_PTR_FOR_FN (cfun)
&& bitmap_set_bit (seen, e->src->index))
@@ -250,10 +255,10 @@ verify_non_ssa_vars (struct split_point
  if (gimple_code (stmt) == GIMPLE_LABEL
  && test_nonssa_use (stmt, gimple_label_label (stmt),
  NULL_TREE, non_ssa_vars))
- {
-   ok = false;
-   goto done;
- }
+   {
+ ok = false;
+ goto done;
+   }
}
   for (bsi = gsi_start_phis (bb); !gsi_end_p (bsi); gsi_next (&bsi))
{
@@ -286,6 +291,27 @@ verify_non_ssa_vars (struct split_point
}
}
 }
+
+  /* Verify that the rest of function does not define any label
+ used by the split part.  */
+  FOR_EACH_BB_FN (bb, cfun)
+if (!bitmap_bit_p (current->split_bbs, bb->index)
+   && !bitmap_bit_p (seen, bb->index))
+  {
+gimple_stmt_iterator bsi;
+for (bsi = gsi_start_bb (bb); !gsi_end_p (bsi); gsi_next (&bsi))
+ if (gimple_code (gsi_stmt (bsi)) == GIMPLE_LABEL
+ && test_nonssa_use (gsi_stmt (bsi),
+ gimple_label_label (gsi_stmt (bsi)),
+ NULL_TREE, non_ssa_vars))
+   {
+ ok = false;
+ goto done;
+   }
+ else if (gimple_code (gsi_stmt (bsi)) != GIMPLE_LABEL)
+   break;
+  }
+
 done:
   BITMAP_FREE (seen);
   worklist.release ();
@@ -735,7 +761,8 @@ mark_nonssa_use (gimple, tree t, tree, v
   if ((TREE_CODE (t) == VAR_DECL
&& auto_var_in_fn_p (t, current_function_decl))
   || TREE_CODE (t) == RESULT_DECL
-  || TREE_CODE (t) == LABEL_DECL)
+  || (TREE_CODE (t) == LABEL_DECL
+ && FORCED_LABEL (t)))
 bitmap_set_bit ((bitmap)data, DECL_UID (t));
 
   /* For DECL_BY_REFERENCE, the return value is actually a pointer.  We want

Re: [PATCH] gcc parallel make check

[Jakub Jelinek]

On Wed, Sep 10, 2014 at 11:08:22PM +0200, Jakub Jelinek wrote:
> Perhaps better approach might be if we have some way how to synchronize among
> multiple expect processes and spawn only as many expects (of course, per
> check target) as there are CPUs.  E.g. if mkdir is atomic on all
> hosts/filesystems we care about, we could have some shared directory that
> make would clear before spawning all the expects, and after checking
> runtest_file_p we could attempt to mkdir something (e.g. testcase filename
> with $(srcdir) part removed, or *.exp filename / counter what test are we
> considering or something similar) in the shared directory, if that would
> succeed, it would tell us that we are the process that should run the test,
> if that failed, we'd know some other runtest did that.
> Or perhaps not for every single test, but every 10 or 100 tests or
> something.
> 
> E.g. we could just override runtest_file_p itself, so that it would first
> call the original dejagnu version, and then do this check.

Seems file mkdir in tcl doesn't error on pre-existing directory, so perhaps
[open $path {WRONLY EXCL CREAT}] ?
Now, does this work properly on all hosts we care about?

Jakub

Re: [PATCH] gcc parallel make check

[Mike Stump]

On Sep 10, 2014, at 2:23 PM, Jakub Jelinek  wrote:
> Seems file mkdir in tcl doesn't error on pre-existing directory,

shell mkdir will.  :-)

Re: [GOOGLE] Fix gcda build info support

[Xinliang David Li]

Can you share the buildinfo reader code with the merger by defininig
some hooks for different callbacks?

David

On Wed, Sep 10, 2014 at 10:24 AM, Teresa Johnson  wrote:
> While porting recent support for a build info section in the gcda from
> google/4_8 to 4_9 and doing manual testing, I discovered that it does
> not interact well with the COMDAT fixup handling. This patch fixes the
> issue, and adds a test case that exposes the problem without the fix.
>
> Here is the google/4_8 patch - I plan to commit there first then port
> it along with the original build info patch to 4_9.
>
> Passes regression tests - ok for google branches?
>
> Thanks,
> Teresa
>
> 2014-09-10  Teresa Johnson  
>
> libgcc:
> * libgcov-driver.c (gcov_scan_to_function_data): Rename from
> gcov_scan_summary_end, scan past BUILD_INFO section.
> (gcov_dump_module_info): Rename gcov_scan_summary_end to
> gcov_scan_to_function_data.
>
> gcc/testsuite:
> * g++.dg/tree-prof/lipo/buildinfo.txt: Input for
> -fprofile-generate-buildinfo option.
> * g++.dg/tree-prof/lipo/comdat_fixup_0.C: New test.
> * g++.dg/tree-prof/lipo/comdat_fixup_1.C: Ditto.
> * g++.dg/tree-prof/lipo/comdat_fixup_2.C: Ditto.
> * g++.dg/tree-prof/lipo/comdat_fixup.h: Ditto.
> * lib/profopt.exp: Declare srcdir for use in test options.
>
> Index: libgcc/libgcov-driver.c
> ===
> --- libgcc/libgcov-driver.c (revision 214976)
> +++ libgcc/libgcov-driver.c (working copy)
> @@ -428,13 +428,15 @@ struct gcov_filename_aux{
>  #include "libgcov-driver-system.c"
>
>  /* Scan through the current open gcda file corresponding to GI_PTR
> -   to locate the end position of the last summary, returned in
> -   SUMMARY_END_POS_P.  Return 0 on success, -1 on error.  */
> +   to locate the end position just before function data should be rewritten,
> +   returned in SUMMARY_END_POS_P. E.g. scan past the last summary and other
> +   sections that won't be rewritten, like the build info.  Return 0 on 
> success,
> +   -1 on error.  */
>  static int
> -gcov_scan_summary_end (struct gcov_info *gi_ptr,
> -   gcov_position_t *summary_end_pos_p)
> +gcov_scan_to_function_data (struct gcov_info *gi_ptr,
> +gcov_position_t *summary_end_pos_p)
>  {
> -  gcov_unsigned_t tag, version, stamp;
> +  gcov_unsigned_t tag, version, stamp, i, length;
>tag = gcov_read_unsigned ();
>if (tag != GCOV_DATA_MAGIC)
>  {
> @@ -467,6 +469,28 @@ static int
>  return -1;
>  }
>
> +  /* If there is a build info section, scan past it as well.  */
> +  if (tag == GCOV_TAG_BUILD_INFO)
> +{
> +  length = gcov_read_unsigned ();
> +  gcov_unsigned_t num_strings = 0;
> +  char **build_info_strings = gcov_read_build_info (length, 
> &num_strings);
> +  if (!build_info_strings)
> +{
> +  gcov_error ("profiling:%s:Error reading build info\n", 
> gi_filename);
> +  return -1;
> +}
> +
> +  for (i = 0; i < num_strings; i++)
> +free (build_info_strings[i]);
> +  free (build_info_strings);
> +
> +  *summary_end_pos_p = gcov_position ();
> +  tag = gcov_read_unsigned ();
> +}
> +  /* The next section should be the function counters.  */
> +  gcc_assert (tag == GCOV_TAG_FUNCTION);
> +
>return 0;
>  }
>
> @@ -1031,10 +1055,10 @@ gcov_dump_module_info (struct gcov_filename_aux *g
>
>if (changed)
>  {
> -  /* Scan file to find the end of the summary section, which is
> +  /* Scan file to find the start of the function section, which is
>   where we will start re-writing the counters.  */
>gcov_position_t summary_end_pos;
> -  if (gcov_scan_summary_end (gi_ptr, &summary_end_pos) == -1)
> +  if (gcov_scan_to_function_data (gi_ptr, &summary_end_pos) == -1)
>  gcov_error ("profiling:%s:Error scanning summaries\n",
>  gi_filename);
>else
> Index: gcc/testsuite/g++.dg/tree-prof/lipo/buildinfo.txt
> ===
> --- gcc/testsuite/g++.dg/tree-prof/lipo/buildinfo.txt   (revision 0)
> +++ gcc/testsuite/g++.dg/tree-prof/lipo/buildinfo.txt   (revision 0)
> @@ -0,0 +1 @@
> +Test -fprofile-generate-buildinfo option
> Index: gcc/testsuite/g++.dg/tree-prof/lipo/comdat_fixup_0.C
> ===
> --- gcc/testsuite/g++.dg/tree-prof/lipo/comdat_fixup_0.C(revision 0)
> +++ gcc/testsuite/g++.dg/tree-prof/lipo/comdat_fixup_0.C(revision 0)
> @@ -0,0 +1,9 @@
> +/* { dg-options "-O2 -fno-inline
> -fprofile-generate-buildinfo=$srcdir/g++.dg/tree-prof/lipo/buildinfo.txt"
> } */
> +#include 
> +
> +extern int foo1(int x);
> +extern int foo2(int x);
> +int main()
> +{
> +  printf ("Result = %d\n", foo1(1) + foo2(1));

Re: RFA: PATCH to ipa-devirt for c++/58678

[Jan Hubicka]

> The failure with -flto is due to make_decl_local clearing
> DECL_COMDAT, so the check in ipa_devirt allows devirtualization to
> an implicitly declared destructor.  It's not clear to me why
> make_decl_local needs to clear DECL_COMDAT, but it's simpler to just
> remove that check from ipa_devirt.
> 
> Tested x86_64-pc-linux-gnu.  OK for trunk and 4.9?

> commit f88473ffec00cd8b537f7d92102f99fbd855b685
> Author: Jason Merrill 
> Date:   Fri Aug 29 12:44:54 2014 -0400
> 
>   PR c++/58678
>   * ipa-devirt.c (ipa_devirt): Don't check DECL_COMDAT.
> 
> diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
> index f98a18e..948ae23 100644
> --- a/gcc/ipa-devirt.c
> +++ b/gcc/ipa-devirt.c
> @@ -3952,8 +3952,7 @@ ipa_devirt (void)
>   /* Don't use an implicitly-declared destructor (c++/58678).  */
>   struct cgraph_node *non_thunk_target
> = likely_target->function_symbol ();
> - if (DECL_ARTIFICIAL (non_thunk_target->decl)
> - && DECL_COMDAT (non_thunk_target->decl))
> + if (DECL_ARTIFICIAL (non_thunk_target->decl))

If we know that we are going to output the destructor in current unit (i.e. it 
is not COMDAT or EXTERNAL
and it have definition), I think we ought to devirtualize to it.
So (DECL_COMDAT || DECL_EXTERNAL), but then it won't helpif the function was 
localized.

OK, I see:
_ZN1BD2Ev/3 (__base_dtor ) @0x7756b000
  Type: function definition analyzed
  Visibility: externally_visible public weak comdat comdat_group:_ZN1BD5Ev 
one_only artificial
  Same comdat group as: _ZN1BD1Ev/4
  Address is taken.
  References: _ZTV1B/7 (addr)
  Referring: _ZN1BD1Ev/4 (alias)
  Read from file: t.o
  First run: 0
  Function flags:
  Called by:
  Calls: _ZN1AD2Ev/8 (0.00 per call) (can throw external)

so we have comdat destructor that we do not want to access.  Next we do:

_ZN1BD2Ev/3 (__base_dtor ) @0x7756b000
  Type: function definition analyzed
  Visibility: prevailing_def_ironly artificial
  Address is taken.
  References: _ZTV1B/7 (addr)
  Referring: _ZN1BD1Ev/4 (alias)
  Read from file: t.o
  Availability: available
  First run: 0
  Function flags:
  Called by:
  Calls: _ZN1AD2Ev/8 (0.00 per call) (can throw external)

i.e. we bring the comdat local because we know we are only user of it in DSO.
>From this point on it is a normal static function and therefore everyone is
welcome to refer to it.

Again - I think main problem is that we provide a middle end a function body
that it is not allowed to use.  We do not really have a concept of function
definitions that we may not use and worse yet, we are preventing that just in
one special case - i.e. in the speculative devirtualization. It is kind of semi
useful to have these because we can still analyze their side effects. Otherwise
i would say we should never get them out of FE.

I guess best approach would be avoid localizing those odd beasts, so add logic
into comdat_can_be_unshared_p_1 that will check for abstract destructors and
for those check if they do have some real references to them (other than from
another COMDAT/EXTERN symbols) and return false if they doesn't?

I wonder how many extra symbols we introduce this way, but for 4.9 it is
probably the way to go. For mainline we can play with localizing them later 
if it turns out to be important for bigger C++ libraries.
(localization brings quite nice reductions to dynamic linker tables that
is always iportant)

Honza
> {
>   if (dump_file)
> fprintf (dump_file, "Target is artificial\n\n");
> diff --git a/gcc/testsuite/g++.dg/ipa/devirt-28a.C 
> b/gcc/testsuite/g++.dg/ipa/devirt-28a.C
> new file mode 100644
> index 000..bdd1682
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/ipa/devirt-28a.C
> @@ -0,0 +1,15 @@
> +// PR c++/58678
> +// { dg-options "-O3 -flto -shared -fPIC -Wl,--no-undefined" }
> +// { dg-do link { target { gld && fpic } } }
> +
> +struct A {
> +  virtual ~A();
> +};
> +struct B : A {
> +  virtual int m_fn1();
> +};
> +void fn1(B* b) {
> +  delete b;
> +}
> +
> +int main() {}

Re: RFA: PATCH to ipa-devirt for c++/58678

[Jan Hubicka]

Hi
and forgot to add, I can implement the change if it seems to make sense to you 
;)

Honza

Re: [PATCH] Fix up libffi linux64*.S for ppc32-linux

[Alan Modra]

On Wed, Sep 10, 2014 at 04:48:33PM +0200, Jakub Jelinek wrote:
>   * src/powerpc/linux64.S: Emit .note.GNU-stack even when
>   POWERPC64 is not defined.
>   * src/powerpc/linux64_closure.S: Likewise.  Also test _CALL_ELF == 2.

Looks reasononable to me, and oops, I think I introduced this problem
when adding ELFv2 support by moving those notes.

-- 
Alan Modra
Australia Development Lab, IBM

[PATCH] Introduce LABEL_REF_LABEL

[David Malcolm]

The following patch adds a macro:

  /* Get the label that a LABEL_REF references.  */
  #define LABEL_REF_LABEL(LABREF) XCEXP (LABREF, 0, LABEL_REF)

and uses it in place of XEXP (foo, 0) for "foo" known to be a
LABEL_REF, throughout the "gcc" directory, in the hope of
(A) improving the clarity of the code
(B) perhaps making it easier to make things typesafe in future patches.

It's rather verbose compared to XEXP (x, 0), but I think it's clearer,
and easier to grep for.  Maybe "LABEL_REF_LAB"?

I haven't gone through the config subfirectories yet.

Bootstrapped on x86_64-unknown-linux-gnu (Fedora 20), and has been
rebuilt as part of a config-list.mk build for all working
configurations.

OK for trunk?

gcc/ChangeLog:
* rtl.h (LABEL_REF_LABEL): New macro.

* alias.c (rtx_equal_for_memref_p): Use LABEL_REF_LABEL in place
of XEXP (, 0), where we know that we have a LABEL_REF.
* cfgbuild.c (make_edges): Likewise.
(purge_dead_tablejump_edges): Likewise.
* cfgexpand.c (convert_debug_memory_address): Likewise.
* cfgrtl.c (patch_jump_insn): Likewise.
* combine.c (distribute_notes): Likewise.
* cse.c (hash_rtx_cb): Likewise.
(exp_equiv_p): Likewise.
(fold_rtx): Likewise.
(check_for_label_ref): Likewise.
* cselib.c (rtx_equal_for_cselib_1): Likewise.
(cselib_hash_rtx): Likewise.
* emit-rtl.c (mark_label_nuses): Likewise.
* explow.c (convert_memory_address_addr_space): Likewise.
* final.c (output_asm_label): Likewise.
(output_addr_const): Likewise.
* gcse.c (add_label_notes): Likewise.
* genconfig.c (walk_insn_part): Likewise.
* genrecog.c (validate_pattern): Likewise.
* ifcvt.c (cond_exec_get_condition): Likewise.
(noce_emit_store_flag): Likewise.
(noce_get_alt_condition): Likewise.
(noce_get_condition): Likewise.
* jump.c (maybe_propagate_label_ref): Likewise.
(mark_jump_label_1): Likewise.
(redirect_exp_1): Likewise.
(rtx_renumbered_equal_p): Likewise.
* lra-constraints.c (operands_match_p): Likewise.
* reload.c (operands_match_p): Likewise.
(find_reloads): Likewise.
* reload1.c (set_label_offsets): Likewise.
* reorg.c (get_branch_condition): Likewise.
* rtl.c (rtx_equal_p_cb): Likewise.
(rtx_equal_p): Likewise.
* rtlanal.c (reg_mentioned_p): Likewise.
(rtx_referenced_p): Likewise.
(get_condition): Likewise.
* sched-vis.c (print_value): Likewise.
* varasm.c (const_hash_1): Likewise.
(compare_constant): Likewise.
(const_rtx_hash_1): Likewise.
(output_constant_pool_1): Likewise.
---
 gcc/alias.c   |  2 +-
 gcc/cfgbuild.c|  4 ++--
 gcc/cfgexpand.c   |  2 +-
 gcc/cfgrtl.c  |  2 +-
 gcc/combine.c |  4 ++--
 gcc/cse.c | 20 ++--
 gcc/cselib.c  |  4 ++--
 gcc/emit-rtl.c|  4 ++--
 gcc/explow.c  |  2 +-
 gcc/final.c   |  4 ++--
 gcc/gcse.c|  6 +++---
 gcc/genconfig.c   |  4 ++--
 gcc/genrecog.c|  4 ++--
 gcc/ifcvt.c   |  8 
 gcc/jump.c| 16 
 gcc/lra-constraints.c |  2 +-
 gcc/reload.c  | 13 +++--
 gcc/reload1.c |  6 +++---
 gcc/reorg.c   |  6 +++---
 gcc/rtl.c |  4 ++--
 gcc/rtl.h |  4 
 gcc/rtlanal.c |  8 +---
 gcc/sched-vis.c   |  2 +-
 gcc/varasm.c  | 11 ++-
 24 files changed, 75 insertions(+), 67 deletions(-)

diff --git a/gcc/alias.c b/gcc/alias.c
index 602e9e0..a098cb7 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -1521,7 +1521,7 @@ rtx_equal_for_memref_p (const_rtx x, const_rtx y)
   return REGNO (x) == REGNO (y);
 
 case LABEL_REF:
-  return XEXP (x, 0) == XEXP (y, 0);
+  return LABEL_REF_LABEL (x) == LABEL_REF_LABEL (y);
 
 case SYMBOL_REF:
   return XSTR (x, 0) == XSTR (y, 0);
diff --git a/gcc/cfgbuild.c b/gcc/cfgbuild.c
index e5ac8d6..00dab3e 100644
--- a/gcc/cfgbuild.c
+++ b/gcc/cfgbuild.c
@@ -277,7 +277,7 @@ make_edges (basic_block min, basic_block max, int update_p)
  && GET_CODE (SET_SRC (tmp)) == IF_THEN_ELSE
  && GET_CODE (XEXP (SET_SRC (tmp), 2)) == LABEL_REF)
make_label_edge (edge_cache, bb,
-XEXP (XEXP (SET_SRC (tmp), 2), 0), 0);
+LABEL_REF_LABEL (XEXP (SET_SRC (tmp), 2)), 0);
}
 
  /* If this is a computed jump, then mark it as reaching
@@ -415,7 +415,7 @@ purge_dead_tablejump_edges (basic_block bb, 
rtx_jump_table_data *table)
&& SET_DEST (tmp) == pc_rtx
&& GET_CODE (SET_SRC (tmp)) == IF_THEN_ELSE
&& GET_CODE (XEXP (SET_SRC (tmp), 2)) == LABEL_REF)
-mark_tablejump_edge (XEXP (XEXP (SET_SRC (tmp), 2), 0));
+mark_tablejum

Re: RFA: PATCH to ipa-devirt for c++/58678

[Jason Merrill]

On 09/10/2014 06:47 PM, Jan Hubicka wrote:

Again - I think main problem is that we provide a middle end a function body
that it is not allowed to use.  We do not really have a concept of function
definitions that we may not use and worse yet, we are preventing that just in
one special case - i.e. in the speculative devirtualization.


Because that special case is the only time we want to prevent it, as I 
argued in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678#c19


My patch shouldn't change any behavior except for fixing this LTO bug, 
since implicitly-declared member functions always have vague linkage. 
It seems to me a simple, safe fix.


Jason

[Ping] Port of VTV for Cygwin and MinGW

[Patrick Wollgast]

Ping for https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02559.html

Also added Caroline Tice, as libvtv maintainer, to cc and attached
virtual_func_test_min_UAF.cpp, which I forgot in the original mail.

Patrick

On 28.08.2014 13:03, Patrick Wollgast wrote:
> This patch contains a port of VTV -fvtable-verify=std for Cygwin and MinGW.
> 
> Since weak symbols on Windows and Linux are implemented differently, and
> VTV should have the possibility to be switched on and off, the structure
> of the feature had to be modified.
> On Linux libstdc++ contains the weak stub functions of VTV. For Cygwin
> and MinGW they have been removed, due to the difference of weak symbols.
> On Linux and on Windows libstdc++ itself gets build with
> -fvtable-verify=std. Since libvtv gets build after libstdc++, and
> libstdc++ doesn't contain the stub functions any more, 'undefined
> reference' errors are thrown during linking of libstdc++. To prevent
> these errors during the linking process a libvtv-0.dll gets build from
> the stub functions before libstdc++-6.dll is linked.
> At the end of the build process two VTV dlls have been build. One is
> called libvtv-0.dll, containing the real functions, the other is called
> libvtv_stubs-0.dll, containing the stub functions. Depending on whether
> libvtv-0.dll is first found in the dll search path or
> libvtv_stubs-0.dll, renamed to libvtv-0.dll, the real functions or the
> stub functions are used.
> 
> Testing:
> The test builds were configured the following way:
> Linux 64bit (from patched and unpatched trunk):
> /path/to/configure --prefix=/prefix/gcc-vtv-bin-64
> --enable-libstdcxx-threads --enable-vtable-verify=yes
> MinGW 32bit cross compiled:
> /path/to/configure --target=i686-w64-mingw32
> --prefix=/prefix/mingw-vtv-bin-32 --with-gnu-ld --with-gnu-as
> --enable-fully-dynamic-string --disable-multilib
> --enable-libstdcxx-threads --enable-vtable-verify=yes
> MinGW 64bit cross compiled:
> /path/to/configure --target=x86_64-w64-mingw32
> --prefix=/prefix/mingw-vtv-bin-64 --with-gnu-ld --with-gnu-as
> --enable-fully-dynamic-string --disable-multilib
> --enable-libstdcxx-threads --enable-vtable-verify=yes
> Cygwin 64bit:
> /path/to/configure --enable-languages=c,c++ --enable-libstdcxx-threads
> --enable-vtable-verify=yes
> 
> At Linux the patched and unpatched version resulted in the same number
> of passed tests with 'make check-target-libvtv'.
> 
> Since MinGW was cross compiled the test cases couldn't be built and run
> with 'make check-target-libvtv'. Therefore they were built with the
> attached makefiles and tested afterwards on Windows 7 64bit. Some test
> cases contain Linux specific parts and weren't tested. See the makefiles
> for further information. Additionally virtual_func_test_min_UAF.cpp was
> also built and tested. All built tests passed.
> 
> Cygwin was just tested on gcc 4.9.0, because the current trunk isn't
> building for me. Even the clean trunk without the patch attached to this
> mail. On Cygwin with gcc 4.9.0 VTV worked.
> 
> Besides the test cases Botan was also built and tested (gcc 4.9.0) with
> MinGW 32bit and VTV.
> 
> regards
> 

-- 
Beste Grüße,
Patrick
#include
#include

/*
 * Demonstrates an use after free c++ internally by deleting an object
 * and resetting its vtable pointing to legitimate functions
 */

// set pointer size and integer size dependent on architechture
#if __x86_64__
/* 64-bit */
const char* arch = "x86_64";
int ptrSize = 8;
typedef long long myInt;// 8 byte
#else
/* 32-bit */
const char* arch = "x86";
int ptrSize = 4;
typedef int myInt;  // 4 byte
#endif
//

using namespace std;


// BASE CLASS
class Addition{
protected:
// member variables
int s1,s2;
public:
// virtual member function will be implemented in derived class
virtual int add(int a,int b){
};
int i;
};
//

// inherit new class
class Add: public Addition{
public:
// constructor:
/*
Add(int a, int b){
s1 = a;
s2 = b;
};
*/
void setvals(int a, int b){
s1 = a;
s2 = b;
}
// implement virtual function
virtual int TRIGGER(){
couti = 6;
A->j = 7;

// get vtable address
myInt vtablePTR = NULL;
vtablePTR = *((myInt*)A);

printf("vtable: %.16x\n", vtablePTR);
//function 1
printf("%.16x : %.16x\n", vtablePTR, *((myInt*)vtablePTR));
//function 2
printf("%.16x : %.16x\n", vtablePTR + ptrSize, *((myInt*)(vtablePTR + ptrSize)));

// call instantiated virtual function (legitimate)
A->TRIGGER();

// FREE OBJECT !
delete A;
//A = NULL; // this prevents use after free

// get objects address as it is still valid
myInt* ObjPTR = (myInt*)A;

// let object point to old vtable (inject old vtable)
*ObjPTR = vtablePTR;

// NOT legitimate
  

Re: [PATCHv2] Vimrc config with GNU formatting

[Yury Gribov]

Segher Boessenkool  kernel.crashing.org> writes:
> I am saying it is very anti-social to make
> people's editor behave differently from what they are used to.
> ...
> The Emacs dir-locals file simply
> configures some settings for files with certain major modes in that 
dir.
> For example, ours says that c-mode files should use GNU style.  This 
is
> quite harmless, and probably what most Emacs users want.

Hm, so autoformatting in Emacs is good because that's what most users 
want but autoformatting in Vim is bad because that's not what people are 
used to?

> First, you are encouraging
> the use of a plugin that is a gaping wide security hole.

I don't think so. The comment mentions that user can either install a 
(rather widespread btw) plugin or just call config from his .vimrc.

> Secondly, this is a very poor imitation of the mechanism Vim has for 
dealing
> with filetypes, namely, ftplugins.

I'm ready to accept technical suggestions on how to do the thing 
properly. So what exactly do you propose?

> [Snipped some overly optimistic stuff about this all increasing the 
quality
> of posted patches.  Hint: the most frequently made formatting error is
> forgetting to put two spaces at the end of a sentence.

Dunno, I was relying on personal experience. And searching for "two|2 
spaces" on http://gcc.gnu.org/ml/gcc-patches returns 2000 results 
whereas "eight|8 spaces" only 700.

-Y

Re: [middle-end/PATCH 0/2] Fix AARCH64 ILP32 ld.so miscompiling

[Andrew Pinski]

Ping.

On Fri, Aug 8, 2014 at 8:51 PM, Andrew Pinski  wrote:
> The problem is that HJL's patch in 2011 to try and fix his miscompiling of x32
> ld.so was in fact incorrect and causes problems with AARCH64 ILP32.
> The testcase which is being miscompiled after HJL's patch (which he was also
> trying to fix up with his patch on x32):
> void f(int *a, int b, long long d) __attribute__((noinline,noclone));
> void f(int *a, int b, long long d)
> {
>if((0x6eff - b) < 11)
>  a[(0x6eff - b) +34+0+16+3+12] = d;
> }
>
> int main(void)
> {
>   int *d = (int*)(int)0xfffefe90;
>   f(d, 0x6eff, -1);
>   if (d[34+0+16+3+12] != -1)
> __builtin_abort();
>
>   __builtin_printf("Works.\n");
>   return 0;
> }
> --- CUT ---
> The tree level in optimized for AARCH64 looks like:
>   _72 = _48 * 4294967292;
>   _73 = _72 + 3221224704;
>   _74 = &MEM[(struct link_map *)&FRAME.21].l_info + _73;
>   *_74 = dyn_15;
>
> Expand then comes along and does not the addition with a zero extend so we
> get the following AARCH64 assembly code:
> maddw2, w2, w6, w0
> mov x0, -1073741825
> movkx0, 0xfac8, lsl 0
> str w3, [x2, x0]
>
> Notice how we have an addition inside the store, since the address will
> overflow we get the incorrect address where the store is happening (the
> address would have the 33rd bit set).
>
> These two patches have been tested on aarch64-linux-gnu (including testing
> with ILP32 multi-lib) with no regression.
>
> The first patch reverts HJL's patch and the second one fixes the issue
> which HJL was trying to fix in the first place; I will explain how
> in the email with the patch.
>
> Thanks,
> Andrew Pinski
>
>
> Andrew Pinski (2):
>   Revert: 2011-08-19  H.J. Lu  
>   Fix ILP32 ld.so.
>
>  gcc/explow.c |   53 -
>  1 files changed, 32 insertions(+), 21 deletions(-)
>
> --
> 1.7.2.5
>

Re: RFA: PATCH to ipa-devirt for c++/58678

[Jan Hubicka]

> On 09/10/2014 06:47 PM, Jan Hubicka wrote:
> >Again - I think main problem is that we provide a middle end a function body
> >that it is not allowed to use.  We do not really have a concept of function
> >definitions that we may not use and worse yet, we are preventing that just in
> >one special case - i.e. in the speculative devirtualization.
> 
> Because that special case is the only time we want to prevent it, as
> I argued in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678#c19
> 
> My patch shouldn't change any behavior except for fixing this LTO
> bug, since implicitly-declared member functions always have vague
> linkage. It seems to me a simple, safe fix.

Your patch disables speuclative devirtualization to all implicitely produced
destructors.  At LTO, in typical case, we can safely devirtualize those. This
is because constructors and thus virutal tables are likely all part of the
given LTO translation unit (if it is close to whole program) and thus the body
of virtual destructor will be output anyway. That is why I think we can
just avoid privatizing of these when they are not used directly already.

But I guess especially for 4.9 branch you patch is safe and practical, so lets
go with it (both mainline and branch) and I will try to get some stats on
how many devirtualizations are missed this way.

Honza

Re: DBL_DENORM_MIN should never be 0

[Marc Glisse]

On Wed, 10 Sep 2014, Joseph S. Myers wrote:


On Wed, 10 Sep 2014, Marc Glisse wrote:


Hello,

according to the C++ standard, numeric_limits::denorm_min should return min
(not 0) when there are no denormals.

Tested with bootstrap+testsuite on x86_64-linux-gnu. I also tested a basic
make all-gcc for vax (only target without denormals apparently) and the macro
did change as expected.

The next step might be to define has_denorm as false in more cases (-mno-ieee
on alpha, -ffast-math on x86, etc) but that's a different issue.

(this is C++ but I believe Joseph is the floating-point expert, hence the cc)


This is a C issue as well (for C11 *_TRUE_MIN).


Ah, indeed. I am updating the comment. And also simplifying float.h. I 
could instead do the same #ifdef in C++, but since both users of 
__FLT_DENORM_MIN__ want the same thing, it seems better to provide that 
directly.



gcc/c-family/

2014-09-10  Marc Glisse  



PR target/58757


* c-cppbuiltin.c (builtin_define_float_constants): Correct
__*_DENORM_MIN__ without denormals.


I think there should be some sort of testcase that these values aren't 0.


I don't know what kind of test you have in mind, so I added a runtime 
test. I am just guessing that it probably fails on alpha because of PR 
58757, I can't test. Computing d+d may be even more likely to trigger 
potential issues, if that's the goal.


Passes bootstrap+testsuite on x86_64-linux-gnu.

2014-09-11  Marc Glisse  

PR target/58757
gcc/c-family/
* c-cppbuiltin.c (builtin_define_float_constants): Correct
__*_DENORM_MIN__ without denormals.
gcc/
* ginclude/float.h (FLT_TRUE_MIN, DBL_TRUE_MIN, LDBL_TRUE_MIN):
Directly forward to __*_DENORM_MIN__.
gcc/testsuite/
* gcc.dg/c11-true_min-1.c: New testcase.

--
Marc GlisseIndex: gcc/c-family/c-cppbuiltin.c
===
--- gcc/c-family/c-cppbuiltin.c (revision 215134)
+++ gcc/c-family/c-cppbuiltin.c (working copy)
@@ -263,35 +263,28 @@ builtin_define_float_constants (const ch
  representable in the given floating point type, b**(1-p).  */
   sprintf (name, "__%s_EPSILON__", name_prefix);
   if (fmt->pnan < fmt->p)
 /* This is an IBM extended double format, so 1.0 + any double is
representable precisely.  */
   sprintf (buf, "0x1p%d", fmt->emin - fmt->p);
 else
   sprintf (buf, "0x1p%d", 1 - fmt->p);
   builtin_define_with_hex_fp_value (name, type, decimal_dig, buf, fp_suffix, 
fp_cast);
 
-  /* For C++ std::numeric_limits::denorm_min.  The minimum denormalized
- positive floating-point number, b**(emin-p).  Zero for formats that
- don't support denormals.  */
+  /* For C++ std::numeric_limits::denorm_min and C11 *_TRUE_MIN.
+ The minimum denormalized positive floating-point number, b**(emin-p).
+ The minimum normalized positive floating-point number for formats
+ that don't support denormals.  */
   sprintf (name, "__%s_DENORM_MIN__", name_prefix);
-  if (fmt->has_denorm)
-{
-  sprintf (buf, "0x1p%d", fmt->emin - fmt->p);
-  builtin_define_with_hex_fp_value (name, type, decimal_dig,
-   buf, fp_suffix, fp_cast);
-}
-  else
-{
-  sprintf (buf, "0.0%s", fp_suffix);
-  builtin_define_with_value (name, buf, 0);
-}
+  sprintf (buf, "0x1p%d", fmt->emin - (fmt->has_denorm ? fmt->p : 1));
+  builtin_define_with_hex_fp_value (name, type, decimal_dig,
+   buf, fp_suffix, fp_cast);
 
   sprintf (name, "__%s_HAS_DENORM__", name_prefix);
   builtin_define_with_value (name, fmt->has_denorm ? "1" : "0", 0);
 
   /* For C++ std::numeric_limits::has_infinity.  */
   sprintf (name, "__%s_HAS_INFINITY__", name_prefix);
   builtin_define_with_int_value (name,
 MODE_HAS_INFINITIES (TYPE_MODE (type)));
   /* For C++ std::numeric_limits::has_quiet_NaN.  We do not have a
  predicate to distinguish a target that has both quiet and
Index: gcc/ginclude/float.h
===
--- gcc/ginclude/float.h(revision 215134)
+++ gcc/ginclude/float.h(working copy)
@@ -171,35 +171,23 @@ see the files COPYING3 and COPYING.RUNTI
 #undef DBL_HAS_SUBNORM
 #undef LDBL_HAS_SUBNORM
 #define FLT_HAS_SUBNORM__FLT_HAS_DENORM__
 #define DBL_HAS_SUBNORM__DBL_HAS_DENORM__
 #define LDBL_HAS_SUBNORM   __LDBL_HAS_DENORM__
 
 /* Minimum positive values, including subnormals.  */
 #undef FLT_TRUE_MIN
 #undef DBL_TRUE_MIN
 #undef LDBL_TRUE_MIN
-#if __FLT_HAS_DENORM__
 #define FLT_TRUE_MIN   __FLT_DENORM_MIN__
-#else
-#define FLT_TRUE_MIN   __FLT_MIN__
-#endif
-#if __DBL_HAS_DENORM__
 #define DBL_TRUE_MIN   __DBL_DENORM_MIN__
-#else
-#define DBL_TRUE_MIN   __DBL_MIN__
-#endif
-#if __LDBL_HAS_DENORM__
 #define LDBL_TRUE_MIN  __LDBL_DENORM_MIN__
-#else
-#define LDBL_TRUE_MIN  __LDBL_MIN__
-#endif
 
 #end

RE: [PATCH] RE: gcc parallel make check

[VandeVondele Joost]

Jakub,

> First of all, the -j2 testing shows more tests tested in gcc and libstdc++:
>
>-# of expected passes   10133
>+# of expected passes   10152
>
>+PASS: 23_containers/set/modifiers/erase/abi_tag.cc (test for excess errors)
>[...]
>
>Not sure where the bug is, could be e.g. in i386.exp for gcc, but for
>libstdc++ less likely to be there rather than in the split.

I looked into this, and believe this problem is already in current trunk, and 
not due to my patch. I.e. unmodified trunk also has these tests executed 
several times:

libstdc++-v3/testsuite/normal4/libstdc++.log.sep:PASS: 
23_containers/map/modifiers/erase/abi_tag.cc
libstdc++-v3/testsuite/normal1/libstdc++.log.sep:PASS: 
23_containers/map/modifiers/erase/abi_tag.cc

 I believe the current trunk pattern could indeed match those twice 
(Makefile.in in trunk):
  normal1) \
dirs="`cd $$srcdir; echo [ab]* de* [ep]*/*`";; \
  normal4) \
dirs="`cd $$srcdir; echo 23_*/[a-km-tw-z]*`";; \

could it be that the pattern in normal1 should have been '[ab]*/ de*/ [ep]*/*' ?


Joost