Re: [patch] PR54645 move location_adhoc_data map into GC

[Eric Botcazou]

> gcc/ChangeLog:
> 2012-09-21  Dehao Chen  
> 
>   PR middle-end/54645
>   * c-family/c-pch.c (c_common_read_pch): Rebuild the location_adhoc_data
>   map when read in the pch.

Wrong ChangeLog file, you want gcc/c-family/ChangeLog (and remove c-family/).

-- 
Eric Botcazou

Ping: [Patch] PR54635: Add addr_space_t argument to mode_dependent_address_p

[Georg-Johann Lay]

http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01448.html

Adds an addr_space_t argument to targetm.mode_dependent_address_p.

Up to now the change is a no-op, but the avr backend needs this.

Johann

Re: [Patch][AArch64] Tighten predicate for CMP pattern.

[Marcus Shawcroft]

On 10/09/12 16:11, Tejas Belagod wrote:

Hi,

This patch tightens the predicate for the CMP pattern. It makes it restrictive
to accept reg or zero as prescribed by the architecture.

Regression-tested on aarch64-none-elf. OK for aarch64-branch?

Thanks,
Tejas Belagod
ARM.

PS: This patch applies over vldn-vstn.txt sent out earlier.

Changelog:

2012-09-10  Tejas Belagod

gcc/
* config/aarch64/aarch64-simd.md (aarch64_cm): Tighten
predicate for operand 2 of the compare pattern to accept register
or zero.
* config/aarch64/predicates.md (aarch64_simd_reg_or_zero): New.


Tejas

This patch duplicated the definition of aarch64_simd_reg_or_zero 
introduced by the earlier vld234 patch.  I've committed the attached fix 
to aarch64-branch and aarch64-4.7-branch


Cheers
/Marcus


2012-09-26  Marcus Shawcroft 

* config/aarch64/predicates.md (aarch64_simd_reg_or_zero): Remove
duplicate.Index: gcc/config/aarch64/predicates.md
===
--- gcc/config/aarch64/predicates.md	(revision 191754)
+++ gcc/config/aarch64/predicates.md	(working copy)
@@ -295,9 +295,3 @@
 {
   return aarch64_simd_imm_zero_p (op, mode);
 })
-
-(define_predicate "aarch64_simd_reg_or_zero"
-  (and (match_code "reg,subreg,const_int,const_vector")
-   (ior (match_operand 0 "register_operand")
-	(ior (match_test "op == const0_rtx")
-		  (match_test "aarch64_simd_imm_zero_p (op, mode)")

[PATCH, ARM] Fix PR44557 (Thumb-1 ICE)

[Chung-Lin Tang]

There was a patch of mine here from over an year ago:
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01846.html

That old patch contained a constraint modification that was a point of
discussion at the time, but upon re-testing I found it was unneeded for
fixing the PR (don't remember why I included it)

Resubmitting the patch adapted, basically a single-liner adding
CORE_REGS to the preferred reload class under Thumb-1. Cross-tested
with no regressions under "-march=armv5te -mthumb". Okay for trunk?

Thanks,
Chung-Lin

2012-09-26  Chung-Lin Tang  

PR target/44557
* config/arm/arm.c (arm_preferred_reload_class): Add CORE_REGS
to Thumb-1 case.

testsuite/
PR target/44557
* gcc.target/arm/pr44557.c: New test.
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 191753)
+++ config/arm/arm.c(working copy)
@@ -6254,6 +6254,7 @@ arm_preferred_reload_class (rtx x ATTRIBUTE_UNUSED
   else
 {
   if (rclass == GENERAL_REGS
+ || rclass == CORE_REGS
  || rclass == HI_REGS
  || rclass == NO_REGS
  || rclass == STACK_REG)
Index: testsuite/gcc.target/arm/pr44557.c
===
--- testsuite/gcc.target/arm/pr44557.c  (revision 0)
+++ testsuite/gcc.target/arm/pr44557.c  (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-mthumb -O1 -march=armv5te -fno-omit-frame-pointer 
-fno-forward-propagate" }  */
+/* { dg-require-effective-target arm_thumb1_ok } */
+
+struct S
+{
+  short x, y;
+};
+
+void foo (struct S *p, struct S *q, char *t, int n)
+{
+  struct S *c, d;
+  int x = 1;
+
+  while (n--)
+{
+  if (*t && p)
+  c = p;
+  q->x = d.x + c->x + c->y;
+  if (x)
+  {
+x = 0;
+  d.x += c->x;
+  }
+}
+}

Ping^3: [PATCH 3/6] Thread pointer built-in functions, arm

[Chung-Lin Tang]

On 2012/9/16 05:15 PM, Richard Sandiford wrote:
> Second ping for the ARM part of Chung-Lin's __builtin_thread_pointer patch:
> 
> http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01914.html
> 
> I think this is the only part that hasn't been approved.
> 
> Thanks,
> Richard
> 

Ping again.

(and thanks to Richard S. for doing the last one :)

Thanks,
Chung-Lin

Re: [Patch] catch builtin_bswap16 construct

[Richard Guenther]

On Fri, Sep 21, 2012 at 10:04 AM, Christophe Lyon
 wrote:
> On 20 September 2012 09:55, Christophe Lyon  
> wrote:
>> On 20 September 2012 09:12, Eric Botcazou  wrote:
 The attached patch catches C constructs:
 (A << 8) | (A >> 8)
 where A is unsigned 16 bits
 and maps them to builtin_bswap16(A) which can provide more efficient
 implementations on some targets.
>>>
>>> This belongs in tree-ssa-math-opts.c:execute_optimize_bswap instead.
>>>
>> OK I'll have a look at that. Actually I modified fold-const.c because
>> it's here that the similar 32 bits pattern is turned into a rotate.
>>
>>> When I implemented __builtin_bswap16, I didn't add this because I thought 
>>> this
>>> would be overkill since the RTL combiner should be able to catch the 
>>> pattern.
>>> Have you investigated on this front?  But I don't have a strong opinion.
>>>
>> No I didn't. As I said above, I looked at where the 32 bits pattern
>> was handled and added the 16 bits one.
>>
>> Christophe.
>
> Here is a new patch, modifying tree-ssa-math-opts.c as you suggested.
> It's indeed simpler :-)
>
> Validated with qemu-arm on target arm-none-linux-gnueabi.
>
> OK?

Assuming this one was the lastest patch ...

Ok.

Thanks,
Richard.

> Christophe.

Re: RFA: update config-list.mk

[Richard Guenther]

On Tue, Sep 25, 2012 at 7:10 PM, Joern Rennecke
 wrote:
> A few arm targets were removed from config.gcc, and picochip is only
> available with --enable-obsolete.  This patch brings config-list.mk
> up-to-date in these respects.
>
> 2012-09-24  Joern Rennecke  
>
> * contrib-list.mk (LIST): Remove arm-freebsd6, arm-linux,
> arm-ecos-elf, arm-rtems, arm-elf and arm-wince-pe.
> Use --enable-obsolete for picochip-elf.

Ok.

Thanks,
Richard.

> Index: contrib/config-list.mk
> ===
> --- contrib/config-list.mk  (revision 191658)
> +++ contrib/config-list.mk  (working copy)
> @@ -13,9 +13,9 @@
>  # v850e1-elf is rejected by config.sub
>  LIST = alpha-linux-gnu alpha-freebsd6 alpha-netbsd alpha-openbsd \
>alpha64-dec-vms alpha-dec-vms am33_2.0-linux \
> -  arm-wrs-vxworks arm-freebsd6 arm-netbsdelf arm-linux \
> -  arm-linux-androideabi arm-uclinux_eabi arm-ecos-elf arm-eabi \
> -  arm-symbianelf arm-rtems arm-elf arm-wince-pe avr-rtems avr-elf \
> +  arm-wrs-vxworks arm-netbsdelf \
> +  arm-linux-androideabi arm-uclinux_eabi arm-eabi \
> +  arm-symbianelf avr-rtems avr-elf \
>bfin-elf bfin-uclinux bfin-linux-uclibc bfin-rtems bfin-openbsd \
>c6x-elf c6x-uclinux cr16-elf cris-elf cris-linux crisv32-elf
> crisv32-linux \
>epiphany-elf epiphany-elfOPT-with-stack-offset=16 fido-elf \
> @@ -42,7 +42,8 @@ LIST = alpha-linux-gnu alpha-freebsd6 al
>mipsisa64-elfoabi mipsisa64r2el-elf mipsisa64sr71k-elf mipsisa64sb1-elf \
>mipsel-elf mips64-elf mips64vr-elf mips64orion-elf mips-rtems \
>mips-wrs-vxworks mipstx39-elf mmix-knuth-mmixware mn10300-elf moxie-elf \
> -  moxie-uclinux moxie-rtems pdp11-aout picochip-elf powerpc-darwin8 \
> +  moxie-uclinux moxie-rtems pdp11-aout picochip-elfOPT-enable-obsolete \
> +  powerpc-darwin8 \
>powerpc-darwin7 powerpc64-darwin powerpc-freebsd6 powerpc-netbsd \
>powerpc-eabispe powerpc-eabisimaltivec powerpc-eabisim ppc-elf \
>powerpc-eabialtivec powerpc-xilinx-eabi powerpc-eabi \
>

Re: [PATCH] Refactor the code to remove IS_UNKNOWN_LOCATION

[Richard Guenther]

On Wed, Sep 26, 2012 at 6:29 AM, Dehao Chen  wrote:
> IS_UNKNOWN_LOCATION is very misleading. This patch removes this macro
> from input.h. For sites when checking LOCUS is intended, we explicit
> use LOCATION_LOCUS and compare it to UNKNOWN_LOCATION.
>
> Bootstrapped and passed all gcc regression tests.
>
> Ok for trunk?

I thought that

   LOCATION_LOCUS (loc) != UNKNOWN_LOCATION

was very verbose and maybe renaming IS_UNKNOWN_LOCATION to

  HAS_UNKNOWN_LOCATION_LOCUS (loc)

would be an improvement.  But I see that this may be as confusing as
the original IS_UNKNOWN_LOCATION.

Thus the patch is ok if nobody objects within 24h.

Thanks,
Richard.

> Thanks,
> Dehao
>
> gcc/ChangeLog:
>
> 2012-09-25  Dehao Chen  
>
> * gcc/tree.h (tree_constructor): Remove IS_UNKNOWN_LOCATION.
> (extern void protected_set_expr_location): Likewise.
> (function_args_iter_next): Likewise.
> (inlined_function_outer_scope_p): Likewise.
> * gcc/input.h (IS_UNKNOWN_LOCATION): Likewise.
> * gcc/fold-const.c (expr_location_or): Likewise.
> * gcc/lto-cgraph.c (output_node_opt_summary): Likewise.
> * gcc/dwarf2out.c (add_src_coords_attributes): Likewise.
> * gcc/tree-eh.c (lower_try_finally_dup_block): Likewise.
> * gcc/profile.c (branch_prob):
> * gcc/cfgexpand.c (expand_gimple_cond): Likewise.
> (expand_gimple_basic_block): Likewise.
> (construct_exit_block): Likewise.
> (gimple_expand_cfg): Likewise.
> * gcc/cfgcleanup.c (try_forward_edges): Likewise.
> * gcc/tree-ssa-live.c (remove_unused_scope_block_p): Likewise.
> (dump_scope_block): Likewise.
> * gcc/ipa-prop.c (ipa_write_jump_function): Likewise.
> * gcc/rtl.h (extern void rtl_check_failed_flag): Likewise.
> * gcc/gimple.h (gimple_set_location): Likewise.
> (gimple_has_location): Likewise.
> * gcc/cfgrtl.c (unique_locus_on_edge_between_p): Likewise.
> (force_nonfallthru_and_redirect): Likewise.
> (fixup_reorder_chain): Likewise.
> (cfg_layout_merge_blocks): Likewise.

Re: Ping: [Patch] PR54635: Add addr_space_t argument to mode_dependent_address_p

[Richard Guenther]

On Wed, Sep 26, 2012 at 10:37 AM, Georg-Johann Lay  wrote:
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01448.html
>
> Adds an addr_space_t argument to targetm.mode_dependent_address_p.
>
> Up to now the change is a no-op, but the avr backend needs this.

Ok.

Thanks,
Richard.

> Johann

[PATCH] Fix up simplify_binary_operation_1 for vector float AND (PR target/54703)

[Jakub Jelinek]

Hi!

At least i?86 and rs6000 backends use V*[SD]F AND/IOR/XOR/NOT
operations, seems most of the simplify-rtx.c code is properly guarded for
that with INTEGRAL_MODE_P (mode), but the
(x - (x & y)) -> (x & ~y)
optimization was not, eventhough it is only valid for integral modes.
Fixed thusly, bootstrapped/regtested on x86_64-linux/i686-linux, ok for
trunk/4.7?

2012-09-26  Jakub Jelinek  

PR target/54703
* simplify-rtx.c (simplify_binary_operation_1): Perform
(x - (x & y)) -> (x & ~y) optimization only for integral
modes.

* gcc.target/i386/pr54703.c: New test.

--- gcc/simplify-rtx.c.jj   2012-09-25 11:59:44.0 +0200
+++ gcc/simplify-rtx.c  2012-09-25 16:02:39.309652457 +0200
@@ -2239,7 +2239,7 @@ simplify_binary_operation_1 (enum rtx_co
neg_const_int (mode, op1));
 
   /* (x - (x & y)) -> (x & ~y) */
-  if (GET_CODE (op1) == AND)
+  if (INTEGRAL_MODE_P (mode) && GET_CODE (op1) == AND)
{
  if (rtx_equal_p (op0, XEXP (op1, 0)))
{
--- gcc/testsuite/gcc.target/i386/pr54703.c.jj  2012-09-25 16:19:19.017248505 
+0200
+++ gcc/testsuite/gcc.target/i386/pr54703.c 2012-09-25 16:21:10.740650488 
+0200
@@ -0,0 +1,36 @@
+/* PR target/54703 */
+/* { dg-do run { target sse2_runtime } } */
+/* { dg-options "-O -msse2" } */
+/* { dg-additional-options "-mavx -mtune=bdver1" { target avx_runtime } } */
+
+extern void abort (void);
+typedef double V __attribute__((vector_size(16)));
+
+union {
+  unsigned long long m[2];
+  V v;
+} u = { { 0xff00ULL, 0xff00ULL } };
+
+static inline V
+foo (V x)
+{
+  V y = __builtin_ia32_andpd (x, u.v);
+  V z = __builtin_ia32_subpd (x, y);
+  return __builtin_ia32_mulpd (y, z);
+}
+
+void
+test (V *x)
+{
+  V a = { 2.1, 2.1 };
+  *x = foo (foo (a));
+}
+
+int
+main ()
+{
+  test (&u.v);
+  if (u.m[0] != 0x3acbf487f0a30550ULL || u.m[1] != u.m[0])
+abort ();
+  return 0;
+}

Jakub

Re: [PATCH] Fix up simplify_binary_operation_1 for vector float AND (PR target/54703)

[Richard Guenther]

On Wed, Sep 26, 2012 at 11:29 AM, Jakub Jelinek  wrote:
> Hi!
>
> At least i?86 and rs6000 backends use V*[SD]F AND/IOR/XOR/NOT
> operations, seems most of the simplify-rtx.c code is properly guarded for
> that with INTEGRAL_MODE_P (mode), but the
> (x - (x & y)) -> (x & ~y)
> optimization was not, eventhough it is only valid for integral modes.
> Fixed thusly, bootstrapped/regtested on x86_64-linux/i686-linux, ok for
> trunk/4.7?

Ok.

Thanks,
Richard.

> 2012-09-26  Jakub Jelinek  
>
> PR target/54703
> * simplify-rtx.c (simplify_binary_operation_1): Perform
> (x - (x & y)) -> (x & ~y) optimization only for integral
> modes.
>
> * gcc.target/i386/pr54703.c: New test.
>
> --- gcc/simplify-rtx.c.jj   2012-09-25 11:59:44.0 +0200
> +++ gcc/simplify-rtx.c  2012-09-25 16:02:39.309652457 +0200
> @@ -2239,7 +2239,7 @@ simplify_binary_operation_1 (enum rtx_co
> neg_const_int (mode, op1));
>
>/* (x - (x & y)) -> (x & ~y) */
> -  if (GET_CODE (op1) == AND)
> +  if (INTEGRAL_MODE_P (mode) && GET_CODE (op1) == AND)
> {
>   if (rtx_equal_p (op0, XEXP (op1, 0)))
> {
> --- gcc/testsuite/gcc.target/i386/pr54703.c.jj  2012-09-25 16:19:19.017248505 
> +0200
> +++ gcc/testsuite/gcc.target/i386/pr54703.c 2012-09-25 16:21:10.740650488 
> +0200
> @@ -0,0 +1,36 @@
> +/* PR target/54703 */
> +/* { dg-do run { target sse2_runtime } } */
> +/* { dg-options "-O -msse2" } */
> +/* { dg-additional-options "-mavx -mtune=bdver1" { target avx_runtime } } */
> +
> +extern void abort (void);
> +typedef double V __attribute__((vector_size(16)));
> +
> +union {
> +  unsigned long long m[2];
> +  V v;
> +} u = { { 0xff00ULL, 0xff00ULL } };
> +
> +static inline V
> +foo (V x)
> +{
> +  V y = __builtin_ia32_andpd (x, u.v);
> +  V z = __builtin_ia32_subpd (x, y);
> +  return __builtin_ia32_mulpd (y, z);
> +}
> +
> +void
> +test (V *x)
> +{
> +  V a = { 2.1, 2.1 };
> +  *x = foo (foo (a));
> +}
> +
> +int
> +main ()
> +{
> +  test (&u.v);
> +  if (u.m[0] != 0x3acbf487f0a30550ULL || u.m[1] != u.m[0])
> +abort ();
> +  return 0;
> +}
>
> Jakub

[PATCH] normal_distribution performance improvement with SSE

[Ulrich Drepper]

Here is a patch to accelerate the __generate function for the
normal_distribution class.  The speed-up is quite significant,
the amount depending on which random number engine is used.

mt19937+20%

mt19937_64 +30%

sfmt19937  +30%

sfmt19937_64   +30%


This patch introduces a header with optimizations for .  No
changes to existing code needed, this is a straight-forward
specialization.  Tested on x86_64-linux.  More optimizations follow,
there is still quite a bit of inefficiency in the existing interfaces.
 OK to commit?


2012-09-21  Ulrich Drepper  

Optimize bulk mode for normal_distribution for SSE3.
* configure.host: Define cpu_opt_bits_random.
* configure.ac: Substitute CPU_OPT_BITS_RANDOM.
* configure: Regenerated.
* include/Makefile.am (bits_headers): Add ${bits_host_headers}.
(bits_host_headers): Define.
* include/bits/random.tcc: Move __details::_Power_of_2 to...
* include/bits/random.h: ...here.
* include/std/random: Include .
* config/cpu/i486/opt/bits/opt_random.h: New file.
* config/cpu/generic/opt/bits/opt_random.h: New file.


d-random-opt-normal-sse
Description: Binary data

Re: [PATCH] normal_distribution performance improvement with SSE

[Paolo Carlini]

Hi,

On 09/26/2012 01:16 PM, Ulrich Drepper wrote:

Here is a patch to accelerate the __generate function for the
normal_distribution class.  The speed-up is quite significant,
the amount depending on which random number engine is used.

mt19937+20%

mt19937_64 +30%

sfmt19937  +30%

sfmt19937_64   +30%


This patch introduces a header with optimizations for .  No
changes to existing code needed, this is a straight-forward
specialization.  Tested on x86_64-linux.  More optimizations follow,
there is still quite a bit of inefficiency in the existing interfaces.
  OK to commit?

Looks fine to me. I suppose you want _Power_of_2 inline?

Paolo.

Re: [PATCH] normal_distribution performance improvement with SSE

[Jakub Jelinek]

On Wed, Sep 26, 2012 at 07:16:09AM -0400, Ulrich Drepper wrote:
> Here is a patch to accelerate the __generate function for the
> normal_distribution class.  The speed-up is quite significant,
> the amount depending on which random number engine is used.
> 
> mt19937+20%
> 
> mt19937_64 +30%
> 
> sfmt19937  +30%
> 
> sfmt19937_64   +30%
> 
> 
> This patch introduces a header with optimizations for .  No
> changes to existing code needed, this is a straight-forward
> specialization.  Tested on x86_64-linux.  More optimizations follow,
> there is still quite a bit of inefficiency in the existing interfaces.
>  OK to commit?

Have you considered also an __AVX__ version handling 4 elements at a time?
Without __AVX2__ one would need to cast __m256i to __m256d for and/or, as
AVX1 doesn't have _mm256_and_si256 or _mm256_or_si256, but _mm256_and_pd
or _mm256_or_pd could be used instead.

Jakub

[PATCH] Fix PR54709

[Richard Guenther]

This fixes PR54709, the location change broke DECL_IS_BUILTIN which
is bogously used by streamer_handle_as_builtin_p.  I am reverting
the previous lto-symtab.c change as it is not necessary for fixing
the testcases.  LTO bootstrap fails with this again with

/tmp/cca0yEEE.ltrans17.ltrans.o: In function `is_ctor_or_dtor.16889':
/space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5506: undefined 
reference to `alloca'
/space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5507: undefined 
reference to `alloca'
/tmp/cca0yEEE.ltrans17.ltrans.o: In function `d_demangle_callback.16926':
/space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5227: undefined 
reference to `alloca'
/space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5228: undefined 
reference to `alloca'
collect2: error: ld returned 1 exit status

but we want a testcase for this instead of having it magically "fixed"
without being analyzed.

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

Richard.

2012-09-26  Richard Guenther  

PR lto/54709
* tree.h (DECL_IS_BUILTIN): Compare LOCATION_LOCUS.
* tree-streamer.h (streamer_handle_as_builtin_p): Use DECL_BUILT_IN.
* lto-symtab.c (lto_symtab_merge_cgraph_nodes_1): Revert previous
change.

* gcc.dg/lto/pr54709_0.c: New testcase.
* gcc.dg/lto/pr54709_1.c: Likewise.

Index: gcc/tree.h
===
*** gcc/tree.h  (revision 191756)
--- gcc/tree.h  (working copy)
*** struct function;
*** 2617,2623 
  #define DECL_SOURCE_LINE(NODE) LOCATION_LINE (DECL_SOURCE_LOCATION (NODE))
  #define DECL_SOURCE_COLUMN(NODE) LOCATION_COLUMN (DECL_SOURCE_LOCATION (NODE))
  #define DECL_IS_BUILTIN(DECL) \
!   (DECL_SOURCE_LOCATION (DECL) <= BUILTINS_LOCATION)
  
  /*  For FIELD_DECLs, this is the RECORD_TYPE, UNION_TYPE, or
  QUAL_UNION_TYPE node that the field is a member of.  For VAR_DECL,
--- 2617,2623 
  #define DECL_SOURCE_LINE(NODE) LOCATION_LINE (DECL_SOURCE_LOCATION (NODE))
  #define DECL_SOURCE_COLUMN(NODE) LOCATION_COLUMN (DECL_SOURCE_LOCATION (NODE))
  #define DECL_IS_BUILTIN(DECL) \
!   (LOCATION_LOCUS (DECL_SOURCE_LOCATION (DECL)) <= BUILTINS_LOCATION)
  
  /*  For FIELD_DECLs, this is the RECORD_TYPE, UNION_TYPE, or
  QUAL_UNION_TYPE node that the field is a member of.  For VAR_DECL,
Index: gcc/tree-streamer.h
===
*** gcc/tree-streamer.h (revision 191756)
--- gcc/tree-streamer.h (working copy)
*** struct streamer_tree_cache_d
*** 57,66 
  static inline bool
  streamer_handle_as_builtin_p (tree expr)
  {
!   return (TREE_CODE (expr) == FUNCTION_DECL
! && DECL_IS_BUILTIN (expr)
! && (DECL_BUILT_IN_CLASS (expr) == BUILT_IN_NORMAL
! || DECL_BUILT_IN_CLASS (expr) == BUILT_IN_MD));
  }
  
  /* In tree-streamer-in.c.  */
--- 57,63 
  static inline bool
  streamer_handle_as_builtin_p (tree expr)
  {
!   return (TREE_CODE (expr) == FUNCTION_DECL && DECL_BUILT_IN (expr));
  }
  
  /* In tree-streamer-in.c.  */
Index: gcc/lto-symtab.c
===
*** gcc/lto-symtab.c(revision 191756)
--- gcc/lto-symtab.c(working copy)
*** lto_symtab_merge_cgraph_nodes_1 (symtab_
*** 629,636 
  
if (!symtab_real_symbol_p (e))
continue;
!   if (symtab_function_p (e)
! && !DECL_BUILT_IN (e->symbol.decl))
lto_cgraph_replace_node (cgraph (e), cgraph (prevailing));
if (symtab_variable_p (e))
lto_varpool_replace_node (varpool (e), varpool (prevailing));
--- 629,635 
  
if (!symtab_real_symbol_p (e))
continue;
!   if (symtab_function_p (e))
lto_cgraph_replace_node (cgraph (e), cgraph (prevailing));
if (symtab_variable_p (e))
lto_varpool_replace_node (varpool (e), varpool (prevailing));
Index: gcc/testsuite/gcc.dg/lto/pr54709_0.c
===
*** gcc/testsuite/gcc.dg/lto/pr54709_0.c(revision 0)
--- gcc/testsuite/gcc.dg/lto/pr54709_0.c(working copy)
***
*** 0 
--- 1,9 
+ /* { dg-lto-do link } */
+ /* { dg-require-visibility "hidden" } */
+ /* { dg-extra-ld-options { -shared } } */
+ /* { dg-lto-options { { -w -fPIC -fvisibility=hidden -flto } } } */
+ 
+ foo ()
+ {
+   memcpy (0, 1, 1);
+ }
Index: gcc/testsuite/gcc.dg/lto/pr54709_1.c
===
*** gcc/testsuite/gcc.dg/lto/pr54709_1.c(revision 0)
--- gcc/testsuite/gcc.dg/lto/pr54709_1.c(working copy)
***
*** 0 
--- 1,5 
+ void * memcpy (void *, void *, long);
+ bar ()
+ {
+   memcpy (0, 1, 1);
+ }

Re: [PATCH] normal_distribution performance improvement with SSE

[Ulrich Drepper]

On Wed, Sep 26, 2012 at 7:32 AM, Jakub Jelinek  wrote:
> Have you considered also an __AVX__ version handling 4 elements at a time?
> Without __AVX2__ one would need to cast __m256i to __m256d for and/or, as
> AVX1 doesn't have _mm256_and_si256 or _mm256_or_si256, but _mm256_and_pd
> or _mm256_or_pd could be used instead.

One step to do first.  Currently the random number engine interface is
inefficient since it returns a single number.  What we need is an
additional interface to return vectors.  I'd love to use the gcc
vector extensions.  For engines like sfmt this is natural.  There are
a few issues with C++ support for the vector extensions.  Operations
available in C are not supported in C++ yet.

[PATCH] Do not mark pseudo-copies decomposable during first lower-subreg pass

[Ulrich Weigand]

Hello,

a while ago Andrew Stubbs noticed that the lower-subreg pass seems a little
too aggressive in splitting up DImode moves into SImode moves.  See the
discussion starting at:
http://gcc.gnu.org/ml/gcc/2012-04/msg00676.html

The conclusion of this thread was that the mere presence of a DImode move
between pseudo registers should *not* be sufficient on its own (i.e. if
the pseudos in question are nowhere accessed via subreg) to trigger a
split of the pseudo during the *first* pass of lower-subreg.  However,
Andrew never got around to submitting a patch implementing this
suggestion.

The patch below does so.  As Andrew already noted, this gives a significant
improvement on ARM with NEON, and a slight improvement in size on ARM
without NEON overall.  In addition, I've done size testing on PowerPC
and System z and found a slight but consistent improvement there as well.

Note that the patch disables the lower-subreg-1.c test case on ARM targets,
since the test case assumes a 64-bit logical or ought to be split; this is
currently not the case on ARM if NEON is available, since we provide an
iordi3 pattern in that case.  (Without the patch, some spurious moves
trigger the split anyway, hiding the issue.)

Tested on arm-linux-gnueabi, powerpc(64)-linux and s390(x)-linux.
OK for mainline?

Bye,
Ulrich


ChangeLog:

* lower-subreg.c (enum classify_move_insn): Rename
SIMPLE_PSEUDO_REG_MOVE to DECOMPOSABLE_SIMPLE_MOVE.
(find_decomposable_subregs): Update.
(decompose_multiword_subregs): Add DECOMPOSE_COPIES parameter.
Only mark pseudo-to-pseudo copies as DECOMPOSABLE_SIMPLE_MOVE
if that parameter is true.
(rest_of_handle_lower_subreg): Call decompose_multiword_subregs
with DECOMPOSE_COPIES false.
(rest_of_handle_lower_subreg2): Call decompose_multiword_subregs
with DECOMPOSE_COPIES true.

testsuite/ChangeLog:

* gcc.dg/lower-subreg-1.c: Disable on arm-*-* targets.


Index: gcc/testsuite/gcc.dg/lower-subreg-1.c
===
*** gcc/testsuite/gcc.dg/lower-subreg-1.c   (revision 191254)
--- gcc/testsuite/gcc.dg/lower-subreg-1.c   (working copy)
***
*** 1,4 
! /* { dg-do compile { target { ! { mips64 || { ia64-*-* spu-*-* tilegx-*-* } } 
} } } */
  /* { dg-options "-O -fdump-rtl-subreg1" } */
  /* { dg-skip-if "" { { i?86-*-* x86_64-*-* } && x32 } { "*" } { "" } } */
  /* { dg-require-effective-target ilp32 } */
--- 1,4 
! /* { dg-do compile { target { ! { mips64 || { arm-*-* ia64-*-* spu-*-* 
tilegx-*-* } } } } } */
  /* { dg-options "-O -fdump-rtl-subreg1" } */
  /* { dg-skip-if "" { { i?86-*-* x86_64-*-* } && x32 } { "*" } { "" } } */
  /* { dg-require-effective-target ilp32 } */
Index: gcc/lower-subreg.c
===
*** gcc/lower-subreg.c  (revision 191254)
--- gcc/lower-subreg.c  (working copy)
*** enum classify_move_insn
*** 440,448 
  {
/* Not a simple move from one location to another.  */
NOT_SIMPLE_MOVE,
!   /* A simple move from one pseudo-register to another.  */
!   SIMPLE_PSEUDO_REG_MOVE,
!   /* A simple move involving a non-pseudo-register.  */
SIMPLE_MOVE
  };
  
--- 440,448 
  {
/* Not a simple move from one location to another.  */
NOT_SIMPLE_MOVE,
!   /* A simple move we want to decompose.  */
!   DECOMPOSABLE_SIMPLE_MOVE,
!   /* Any other simple move.  */
SIMPLE_MOVE
  };
  
*** find_decomposable_subregs (rtx *px, void
*** 518,524 
  
 If this is not a simple copy from one location to another,
 then we can not decompose this register.  If this is a simple
!copy from one pseudo-register to another, and the mode is right
 then we mark the register as decomposable.
 Otherwise we don't say anything about this register --
 it could be decomposed, but whether that would be
--- 518,524 
  
 If this is not a simple copy from one location to another,
 then we can not decompose this register.  If this is a simple
!copy we want to decompose, and the mode is right,
 then we mark the register as decomposable.
 Otherwise we don't say anything about this register --
 it could be decomposed, but whether that would be
*** find_decomposable_subregs (rtx *px, void
*** 537,543 
case NOT_SIMPLE_MOVE:
  bitmap_set_bit (non_decomposable_context, regno);
  break;
!   case SIMPLE_PSEUDO_REG_MOVE:
  if (MODES_TIEABLE_P (GET_MODE (x), word_mode))
bitmap_set_bit (decomposable_context, regno);
  break;
--- 537,543 
case NOT_SIMPLE_MOVE:
  bitmap_set_bit (non_decomposable_context, regno);
  break;
!   case DECOMPOSABLE_SIMPLE_MOVE:
  if (MODES_TIEABLE_P (GET_MODE (x), word_mode))
   

Re: [PATCH] Cilk Plus merging to trunk (2 of n)

[Richard Guenther]

On Mon, Sep 24, 2012 at 5:05 PM, Iyer, Balaji V  wrote:
> Hi Richard,
> Please see my comments embedded below.
>
>>-Original Message-
>>From: Richard Guenther [mailto:richard.guent...@gmail.com]
>>Sent: Monday, September 24, 2012 5:53 AM
>>To: Iyer, Balaji V
>>Cc: gcc-patches@gcc.gnu.org; al...@redhat.com; r...@redhat.com;
>>l...@redhat.com
>>Subject: Re: [PATCH] Cilk Plus merging to trunk (2 of n)
>>
>>On Sun, Sep 23, 2012 at 2:01 AM, Iyer, Balaji V  
>>wrote:
>>> Hello Everyone,
>>> Attached, please find a patch that will implement Cilk Plus Array 
>>> Notations for
>>the C compiler. Array notations are indented to allow programmers to directly
>>express parallelism in their programs. Array notations can be used to 
>>possibly see
>>a more predictable performance improvement, hardware resource-utilization and
>>vectorization. To enable the compiler recognize array notation syntax, we have
>>added a flag "-fcilkplus." If this flag is not used, none of these changes 
>>are visible
>>to the compiler user. For more information and examples about array notations
>>please see Chapter 4 in the Cilk Plus Specification
>>(http://software.intel.com/sites/default/files/m/6/3/1/cilk_plus_language_specif
>>ication.pdf).
>>>
>>> Here are the ChangeLog entries for the changes I have made in this patch.
>>
>>Just a few comments on the middle-end side:
>>
>>+/* Array Notation expression.
>>+   Operand 0 is the array; operand 1 is the starting array index
>>+   Operand 2 contains the number of elements you need to access.
>>+   Operand 3 is the stride.
>>+   Operand 4 is the element size measured in units of alignments of
>>+   element type. */
>>+DEFTREECODE (ARRAY_NOTATION_REF, "array_notation_ref", tcc_reference,
>>+5)
>>
>>I suppose that similar to ARRAY_RANGE_REF the type of the expression specifies
>>the size of the result which is an array itself?  ARRAY_NOTATION_REF is then
>>ARRAY_RANGE_REF with stride possibly != 1.  Thus please instead change
>>ARRAY_RANGE_REF to contain an explicit stride.
>
> IIRC ARRAY_RANGE_REF holds the start index and the end-index with no stride. 
> Whereas ARRAY_NOTATION_REF holds start_index, the number of elements you need 
> to access in the array and the stride. So, they both hold different 
> information. Converting one to another can cause some implementation and 
> performance complexities when we have assignments  that have different stride 
> while accessing the same number of elements.  Also, I did not see much (if 
> any) usage of Array_range_ref in C or C++. The only place that I saw were 
> using it were in Fortran and Ada. Adding the extra field for one thing can 
> require modifications those front-ends. This I felt was a bit unnecessary and 
> excessive. I am replacing the ARRAY_NOTATION_REF tree with the appropriate 
> array_ref and a loop. Thus, having a tree that holds array  notation 
> information made things look straightforward.
>
>>
>>+  case ARRAY_NOTATION_REF:
>>+/* Nothing should happen here.  We just return ALL_DONE.  */
>>+ret = GS_ALL_DONE;
>>+break;
>>+
>>
>>I don't believe that.  You should not restrict GENERIC to put gimplfied 
>>operands
>>into the operand slots.  See how ARRAY_RANGE_REF is handled.
>>The exception may be if ARRAY_NOTATION_REF never survives until gimplfication
>>(and thus is not part of GENERIC but a frontend specific tree).
>
> ARRAY_NOTATION_REF does not survive gimplifcation. It gets broken up toward 
> the end of parsing. In hindsight, I should have done something like this:
>
> case ARRAY_NOTATION_REF:
>gcc_unreachable ();

You should instead add ARRAY_NOTATION_REF to c-family/c-common.def
as C-family specific tree code then.

Richard.

> Thanks,
>
> Balaji V. Iyer.
>
>>
>>Richard.
>>
>>> gcc/ChangeLog:
>>> 2012-09-22  Balaji V. Iyer  
>>> * tree.h (array_notation_reduce_type): Added new enumerator.
>>> (ARRAY_NOTATION_ARRAY): Added new #define.
>>> (ARRAY_NOTATION_CHECK): Likewise.
>>> (ARRAY_NOTATION_START): Likewise.
>>> (ARRAY_NOTATION_LENGTH): Likewise.
>>> (ARRAY_NOTATION_STRIDE): Likewise.
>>> (ARRAY_NOTATION_TYPE): Likewise.
>>> * gimplify.c (gimplify_expr): Added a ARRAY_NOTATION_REF case.
>>> * tree.def: Added new tree ARRAY_NOTATION_REF.
>>> * Makefile.in (OBJS): Added array-notation-common.o.
>>> * doc/passes.texi (Cilk Plus Transformation): Documented array 
>>> notation
>>overall transformations for Cilk Plus.
>>> * doc/invoke.texi (C Dialect Options): Documented -fcilkplus flag.
>>> * doc/generic.texi (Storage References): Documented
>>ARRAY_NOTATION_REF
>>> tree addition.
>>> * array-notation-common.c: New file.
>>>
>>> gcc/c/ChangeLog
>>> 2012-09-22  Balaji V. Iyer  
>>> * c-typeck.c (convert_arguments): Added a check if tree contains
>>> array notation expressions before throwing errors or doing anything.
>>> * Make-lang

Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)

[Michael Matz]

Hi,

On Tue, 25 Sep 2012, Lawrence Crowl wrote:

> On 8/15/12, Richard Henderson  wrote:
> > On 2012-08-15 07:29, Richard Guenther wrote:
> > > +   typedef typename Element::Element_t Element_t;
> >
> > Can we use something less ugly than Element_t?
> > Such as
> >
> >   typedef typename Element::T T;
> >
> > ?  Given that this name is scoped anyway...
> 
> I've been finding the use of T as a typedef confusing.

Why?  As type placeholder in templates it's quite customary, as the "most 
interesting to users of this template".  I would have no trouble at all to 
see declarations like "T x = getme();" in a function.  In some way I even 
prefer that to some lower-case variant, because it reminds me that this 
specific "T" is actually variant.

A lower-case type name indicates to me a non-changing type, i.e. nothing 
that depends on a template.  In C we only had such types so we used 
lower-case names everywhere.  With C++ and templates I think we should 
start using upper case for some very specific use cases, like first letter 
of dependend types.

> It sort of flies in the face of all existing convention.

If you talk about the conventions used for the c++ standard library, then 
they are IMHO quite ugly and we should not follow them.


Ciao,
Michael.

Re: [PATCH] Add option for dumping to stderr (issue6190057)

[Richard Guenther]

On Mon, Sep 24, 2012 at 10:10 PM, Sharad Singhai  wrote:
> Ping.

Some minor issues:

* c/c-decl.c (c_write_global_declarations): Use different method to
determine if the dump has ben initialized.
* cp/decl2.c (cp_write_global_declarations): Ditto.
* testsuite/gcc.target/i386/vect-double-1.c: Fix test.

these subdirs all have their separate ChangeLog entry from where the
directory name is omitted.

Index: tree-dump.c
===
--- tree-dump.c (revision 191490)
+++ tree-dump.c (working copy)
@@ -24,9 +24,11 @@ along with GCC; see the file COPYING3.  If not see
 #include "coretypes.h"
 #include "tm.h"
 #include "tree.h"
+#include "gimple-pretty-print.h"
 #include "splay-tree.h"
 #include "filenames.h"
 #include "diagnostic-core.h"
+#include "rtl.h"

what do you need gimple-pretty-print.h and rtl.h for?

+
+extern void dump_bb (FILE *, basic_block, int, int);
+

that should be declared in some header

+/* Dump gimple statement GS with SPC indentation spaces and
+   EXTRA_DUMP_FLAGS on the dump streams if DUMP_KIND is enabled.  */
+
+void
+dump_gimple_stmt (int dump_kind, int extra_dump_flags, gimple gs, int spc)
+{

the gimple stuff really belongs in to gimple-pretty-print.c

(parts of tree-dump.c should be moved to a new file dumpfile.c)

+/* Dump tree T using EXTRA_DUMP_FLAGS on dump streams if DUMP_KIND is
+   enabled.  */
+
+void
+dump_generic_expr (int dump_kind, int extra_dump_flags, tree t)
+{

belongs to tree-pretty-print.c (to where the routines are it calls)

+int
+dump_start (int phase, int *flag_ptr)
+{

perfect candidate for dumpfile.c

You can do this re-shuffling as followup, but please try to not include rtl.h
or gimple-pretty-print.h from tree-dump.c.  Thus re-shuffling required by that
do now.  tree-dump.c should only know about dumping 'tree'.

Index: tree-dump.h
===
--- tree-dump.h (revision 191490)
+++ tree-dump.h (working copy)
@@ -22,6 +22,7 @@ along with GCC; see the file COPYING3.  If not see
 #ifndef GCC_TREE_DUMP_H
 #define GCC_TREE_DUMP_H

+#include "input.h"

probably no longer required.

Index: dumpfile.h
===
--- dumpfile.h  (revision 191490)
+++ dumpfile.h  (working copy)
@@ -22,6 +22,9 @@ along with GCC; see the file COPYING3.  If not see
 #ifndef GCC_DUMPFILE_H
 #define GCC_DUMPFILE_H 1

+#include "coretypes.h"
+#include "input.h"

likewise for input.h.

Index: testsuite/gcc.target/i386/vect-double-1.c
===
--- testsuite/gcc.target/i386/vect-double-1.c   (revision 191490)
+++ testsuite/gcc.target/i386/vect-double-1.c   (working copy)
@@ -32,5 +32,5 @@ sse2_test (void)
 }
 }

-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
+/* { dg-final { scan-tree-dump-times "Vectorized loops: 1" 1 "vect" } } */
 /* { dg-final { cleanup-tree-dump "vect" } } */

I am sure you need a gazillion more testsuite adjustments?  Thus, did you
really test the patch by a bootstrap and a toplevel make -k check for
regressions?

Index: opts.c
===
--- opts.c  (revision 191490)
+++ opts.c  (working copy)
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "system.h"
 #include "intl.h"
 #include "coretypes.h"
+#include "dumpfile.h"

I don't see that you add a use for this.  Please double-check all your include
file changes.

Index: gimple-pretty-print.c
===
--- gimple-pretty-print.c   (revision 191490)
+++ gimple-pretty-print.c   (working copy)
@@ -69,7 +69,7 @@ maybe_init_pretty_print (FILE *file)
 }
...
Index: gimple-pretty-print.h
===
--- gimple-pretty-print.h   (revision 191490)
+++ gimple-pretty-print.h   (working copy)
@@ -31,6 +31,6 @@ extern void debug_gimple_seq (gimple_seq);
 extern void print_gimple_seq (FILE *, gimple_seq, int, int);
 extern void print_gimple_stmt (FILE *, gimple, int, int);
 extern void print_gimple_expr (FILE *, gimple, int, int);
-extern void dump_gimple_stmt (pretty_printer *, gimple, int, int);
+extern void pp_gimple_stmt_1 (pretty_printer *, gimple, int, int);

it looks like changes to these files are only renaming of existing
dump_ functions
to print_ functions.  Consider testing and applying those separately (hereby
pre-approved).

Index: profile.c
===
--- profile.c   (revision 191490)
+++ profile.c   (working copy)
@@ -52,6 +52,7 @@ along with GCC; see the file COPYING3.  If not see

please leave further changes to passes as followup, thus omit changes to this
file for the initial commit and submit it separately.


Index: rtl.h

Re: [PATCH] Fix PR54709

[Richard Guenther]

On Wed, 26 Sep 2012, Richard Guenther wrote:

> 
> This fixes PR54709, the location change broke DECL_IS_BUILTIN which
> is bogously used by streamer_handle_as_builtin_p.  I am reverting
> the previous lto-symtab.c change as it is not necessary for fixing
> the testcases.  LTO bootstrap fails with this again with
> 
> /tmp/cca0yEEE.ltrans17.ltrans.o: In function `is_ctor_or_dtor.16889':
> /space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5506: undefined 
> reference to `alloca'
> /space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5507: undefined 
> reference to `alloca'
> /tmp/cca0yEEE.ltrans17.ltrans.o: In function `d_demangle_callback.16926':
> /space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5227: undefined 
> reference to `alloca'
> /space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5228: undefined 
> reference to `alloca'
> collect2: error: ld returned 1 exit status
> 
> but we want a testcase for this instead of having it magically "fixed"
> without being analyzed.
> 
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Which revealed issues.  Thus, I'm going with the following, simpler.

LTO bootstrapped (yay) on x86_64-unknown-linux-gnu, testing in progress.

2012-09-26  Richard Guenther  

PR lto/54709
* tree.h (DECL_IS_BUILTIN): Compare LOCATION_LOCUS.

* gcc.dg/lto/pr54709_0.c: New testcase.
* gcc.dg/lto/pr54709_1.c: Likewise.

Index: gcc/tree.h
===
*** gcc/tree.h  (revision 191756)
--- gcc/tree.h  (working copy)
*** struct function;
*** 2617,2623 
  #define DECL_SOURCE_LINE(NODE) LOCATION_LINE (DECL_SOURCE_LOCATION (NODE))
  #define DECL_SOURCE_COLUMN(NODE) LOCATION_COLUMN (DECL_SOURCE_LOCATION (NODE))
  #define DECL_IS_BUILTIN(DECL) \
!   (DECL_SOURCE_LOCATION (DECL) <= BUILTINS_LOCATION)
  
  /*  For FIELD_DECLs, this is the RECORD_TYPE, UNION_TYPE, or
  QUAL_UNION_TYPE node that the field is a member of.  For VAR_DECL,
--- 2617,2623 
  #define DECL_SOURCE_LINE(NODE) LOCATION_LINE (DECL_SOURCE_LOCATION (NODE))
  #define DECL_SOURCE_COLUMN(NODE) LOCATION_COLUMN (DECL_SOURCE_LOCATION (NODE))
  #define DECL_IS_BUILTIN(DECL) \
!   (LOCATION_LOCUS (DECL_SOURCE_LOCATION (DECL)) <= BUILTINS_LOCATION)
  
  /*  For FIELD_DECLs, this is the RECORD_TYPE, UNION_TYPE, or
  QUAL_UNION_TYPE node that the field is a member of.  For VAR_DECL,
Index: gcc/testsuite/gcc.dg/lto/pr54709_0.c
===
*** gcc/testsuite/gcc.dg/lto/pr54709_0.c(revision 0)
--- gcc/testsuite/gcc.dg/lto/pr54709_0.c(working copy)
***
*** 0 
--- 1,9 
+ /* { dg-lto-do link } */
+ /* { dg-require-visibility "hidden" } */
+ /* { dg-extra-ld-options { -shared } } */
+ /* { dg-lto-options { { -w -fPIC -fvisibility=hidden -flto } } } */
+ 
+ foo ()
+ {
+   memcpy (0, 1, 1);
+ }
Index: gcc/testsuite/gcc.dg/lto/pr54709_1.c
===
*** gcc/testsuite/gcc.dg/lto/pr54709_1.c(revision 0)
--- gcc/testsuite/gcc.dg/lto/pr54709_1.c(working copy)
***
*** 0 
--- 1,5 
+ void * memcpy (void *, void *, long);
+ bar ()
+ {
+   memcpy (0, 1, 1);
+ }

RE: [PATCH] Cilk Plus merging to trunk (2 of n)

[Iyer, Balaji V]

>-Original Message-
>From: Richard Guenther [mailto:richard.guent...@gmail.com]
>Sent: Wednesday, September 26, 2012 8:16 AM
>To: Iyer, Balaji V
>Cc: gcc-patches@gcc.gnu.org; al...@redhat.com; r...@redhat.com;
>l...@redhat.com
>Subject: Re: [PATCH] Cilk Plus merging to trunk (2 of n)
>
>On Mon, Sep 24, 2012 at 5:05 PM, Iyer, Balaji V  
>wrote:
>> Hi Richard,
>> Please see my comments embedded below.
>>
>>>-Original Message-
>>>From: Richard Guenther [mailto:richard.guent...@gmail.com]
>>>Sent: Monday, September 24, 2012 5:53 AM
>>>To: Iyer, Balaji V
>>>Cc: gcc-patches@gcc.gnu.org; al...@redhat.com; r...@redhat.com;
>>>l...@redhat.com
>>>Subject: Re: [PATCH] Cilk Plus merging to trunk (2 of n)
>>>
>>>On Sun, Sep 23, 2012 at 2:01 AM, Iyer, Balaji V 
>wrote:
 Hello Everyone,
 Attached, please find a patch that will implement Cilk Plus
 Array Notations for
>>>the C compiler. Array notations are indented to allow programmers to
>>>directly express parallelism in their programs. Array notations can be
>>>used to possibly see a more predictable performance improvement,
>>>hardware resource-utilization and vectorization. To enable the
>>>compiler recognize array notation syntax, we have added a flag
>>>"-fcilkplus." If this flag is not used, none of these changes are
>>>visible to the compiler user. For more information and examples about
>>>array notations please see Chapter 4 in the Cilk Plus Specification
>>>(http://software.intel.com/sites/default/files/m/6/3/1/cilk_plus_langu
>>>age_specif
>>>ication.pdf).

 Here are the ChangeLog entries for the changes I have made in this patch.
>>>
>>>Just a few comments on the middle-end side:
>>>
>>>+/* Array Notation expression.
>>>+   Operand 0 is the array; operand 1 is the starting array index
>>>+   Operand 2 contains the number of elements you need to access.
>>>+   Operand 3 is the stride.
>>>+   Operand 4 is the element size measured in units of alignments of
>>>+   element type. */
>>>+DEFTREECODE (ARRAY_NOTATION_REF, "array_notation_ref",
>tcc_reference,
>>>+5)
>>>
>>>I suppose that similar to ARRAY_RANGE_REF the type of the expression
>>>specifies the size of the result which is an array itself?
>>>ARRAY_NOTATION_REF is then ARRAY_RANGE_REF with stride possibly != 1.
>>>Thus please instead change ARRAY_RANGE_REF to contain an explicit stride.
>>
>> IIRC ARRAY_RANGE_REF holds the start index and the end-index with no stride.
>Whereas ARRAY_NOTATION_REF holds start_index, the number of elements you
>need to access in the array and the stride. So, they both hold different
>information. Converting one to another can cause some implementation and
>performance complexities when we have assignments  that have different stride
>while accessing the same number of elements.  Also, I did not see much (if any)
>usage of Array_range_ref in C or C++. The only place that I saw were using it
>were in Fortran and Ada. Adding the extra field for one thing can require
>modifications those front-ends. This I felt was a bit unnecessary and 
>excessive. I
>am replacing the ARRAY_NOTATION_REF tree with the appropriate array_ref and
>a loop. Thus, having a tree that holds array  notation information made things
>look straightforward.
>>
>>>
>>>+  case ARRAY_NOTATION_REF:
>>>+/* Nothing should happen here.  We just return ALL_DONE.  */
>>>+ret = GS_ALL_DONE;
>>>+break;
>>>+
>>>
>>>I don't believe that.  You should not restrict GENERIC to put
>>>gimplfied operands into the operand slots.  See how ARRAY_RANGE_REF is
>handled.
>>>The exception may be if ARRAY_NOTATION_REF never survives until
>>>gimplfication (and thus is not part of GENERIC but a frontend specific tree).
>>
>> ARRAY_NOTATION_REF does not survive gimplifcation. It gets broken up
>toward the end of parsing. In hindsight, I should have done something like 
>this:
>>
>> case ARRAY_NOTATION_REF:
>>gcc_unreachable ();
>
>You should instead add ARRAY_NOTATION_REF to c-family/c-common.def as C-
>family specific tree code then.

I actually took out the ARRAY_NOTATION_REF case from gimplify_expr (will send 
out the fixed patch soon). And, I can do what you suggested. But the reason why 
I put it as a common tree is because if someone in future wants to implement 
array notations for other languages, they can do so without much difficulty.

If I did put the tree in c-common.def, where do I document the tree node (Or do 
I even need to document it)? I tried grepping the existing tree names (in 
c-common.def) in the doc directory and I don't see any hits.

Thanks,

Balaji V. Iyer.

>
>Richard.
>
>> Thanks,
>>
>> Balaji V. Iyer.
>>
>>>
>>>Richard.
>>>
 gcc/ChangeLog:
 2012-09-22  Balaji V. Iyer  
 * tree.h (array_notation_reduce_type): Added new enumerator.
 (ARRAY_NOTATION_ARRAY): Added new #define.
 (ARRAY_NOTATION_CHECK): Likewise.
 (ARRAY_NOTATION_START): Likewise.
 (ARRAY_NOTATION_

Re: [PATCH] Fix instability of -fschedule-insn for x86

[Yuri Rumyantsev]

Ping.

2012/9/18 Yuri Rumyantsev :
> Hi All,
>
> Forgot to attch the patch.
>
> 2012/9/18 Yuri Rumyantsev :
>> Hi All,
>>
>> This patch aims to fix all stability issues related to using the first
>> scheduler in gcc
>> for x86 target (there several reported issues related to this problem).
>>
>> Main idea of this activity is mostly to provide user a possibility to
>> safely turn on first scheduler for his codes. In some cases this could
>> positively affect performance, especially for in-order Atom.
>>
>> Below is short description of proposed changes.
>>
>> Main idea of this patch is to restrict code motion of instructions
>> having likely spilled HW registers as their operands - in general
>> all these instructions are unloading of incoming function argument
>> in the function entry and passing of outgoing function arguments.
>> This is essential for correct scheduling since live range of such insns
>> is not defined before register allocation phase.
>> This done through 2 hooks:
>>
>> 1. ix86_adjust_priority which sets up the priority of moves from
>> likely spilled HW registers to maximum that allows us to schedule
>> such insns as soon as possible, i.e. all moves correspondent to
>> incoming function arguments will be scheduled at the top of
>> function entry and moves correspondent to function return
>> value will be scheduled immediately after call.
>> 2. ix86_dependencies_evaluation_hook which insert additional
>> dependencies for outgoing function arguments passed in likely
>> spilled HW registers to avoid their code motion. This is done
>> through the following steps:
>> - scan the current schedule region to find all call instructions in
>>   reverse order;
>> - find out the first argument that passed in likely spilled HW
>>   register. Starting from it insert output dependency between it and
>>   possible previous argument (it does not matter if it passed in likely
>>   spilled register or not). This is done in add_parameter_dependencies;
>>   after it all arguments starting from the first one that is passed in
>>   likely spilled register are pairwise connected through output
>>   dependency.
>> - add dependencies to the first function argument on
>>   the rest of instructions in the current block (until next call)  to avoid
>>   intra block code motion.
>> - to avoid possible interblock code motion we also check if the first
>>   argument has dependee in another blocks and if so insert dependency to
>>   the last non-jump set instruction.
>>
>> This patch was deeply tested on Atom (eembc_2_0, spec2000 in base/peak mode)
>>  and Big Core (spec2006 in base/peak mode).
>> Also gcc full bootstrapping with turned on 1st scheduler by default was done.
>>
>> Tested for i386 and x86-64, ok for trunk?
>>
>> ChangeLog:
>>
>> 2012-09-18  Yuri Rumyantsev  
>>
>> * config/i386/i386.c (ix86_dep_by_shift_count_body) : Add
>> check on reload_completed since it can be invoked before
>> register allocation phase in 1st scheduler.
>> (ia32_multipass_dfa_lookahead) : Do not use dfa_lookahead for 1st
>> Scheduler to save compile time.
>> (ix86_sched_reorder) : Do not perform ready list reordering for 1st
>> Scheduler to save compile time.
>> (insn_is_function_arg) : New function. Returns true if lhs of insn is
>> HW function argument register.
>> (add_parameter_dependencies) : New function. Add output dependencies
>> for chain of function adjacent arguments if only there is a move to
>> likely spilled HW registers. Return first argument if at least one
>> dependence was added or NULL otherwise.
>> (avoid_func_arg_motion) : New function. Add output or anti dependency
>> from insn to first_arg to restrict code motion.
>> (add_dependee_for_func_arg) : New function. Avoid cross block motion 
>> of
>> function argument through adding dependency from the first non-jump
>> insn in bb.
>> (ix86_dependencies_evaluation_hook) : New function. Hook for 
>> schedule1:
>> avoid motion of function arguments passed in passed in likely spilled
>> HW registers.
>> (ix86_adjust_priority) : New function. Hook for schedule1: set 
>> priority
>> of moves from likely spilled HW registers to maximum to schedule them
>> as soon as possible.
>> (ix86_sched_init_global): Do not perform multipass scheduling for 1st
>> Scheduler to save compile time.


i386-fschedule-insn_for_x86.diff
Description: Binary data

Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)

[Gabriel Dos Reis]

On Tue, Sep 25, 2012 at 4:30 PM, Lawrence Crowl  wrote:
> On 8/15/12, Richard Henderson  wrote:
>> On 2012-08-15 07:29, Richard Guenther wrote:
>> > +   typedef typename Element::Element_t Element_t;
>>
>> Can we use something less ugly than Element_t?
>> Such as
>>
>>   typedef typename Element::T T;
>>
>> ?  Given that this name is scoped anyway...
>
> I've been finding the use of T as a typedef confusing.  It sort of
> flies in the face of all existing convention.  The C++ standard would
> use either element_type or value_type.  I suggest a rename, but I'm
> guessing that folks don't want something as verbose as element_type.
> How about elemtype?  Any objections to me changing it to that?
>


In general, we would be better off following standard convention.
It does not seem to me that we have enough reasons and benefits in
building our own universe around this issue.  Consequently, I would suggest
that we use value_type or element_type in the interface -- which is better
served being readable: this is the *interface*.

I am pretty sure that people will quickly resort to local typedefs that are
more readable even if we adopt a short (therefore cryptic) abbreviations
such as T in the interface.  It is one more hurdle that has no reason to be.

-- Gaby

Re: [doc] vector extensions

[Marc Glisse]

http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01041.html

Hmm, maybe I shouldn't put "trivial" in a post, that makes it sound like I 
am not waiting for comments.


Comments?

On Fri, 14 Sep 2012, Marc Glisse wrote:

A fairly trivial follow-up to the patch with the code. I added a line for PR 
53024 while I was there...


2012-09-14  Marc Glisse  

PR c/53024
PR c++/54427
* doc/extend.texi (Vector Extensions): C++ improvements.
Power of 2 size requirement.


--
Marc Glisse

Re: [doc] vector extensions

[Richard Guenther]

On Wed, Sep 26, 2012 at 4:39 PM, Marc Glisse  wrote:
> http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01041.html
>
> Hmm, maybe I shouldn't put "trivial" in a post, that makes it sound like I
> am not waiting for comments.
>
> Comments?

Ok.

Thanks,
Richard.

>
> On Fri, 14 Sep 2012, Marc Glisse wrote:
>
>> A fairly trivial follow-up to the patch with the code. I added a line for
>> PR 53024 while I was there...
>>
>> 2012-09-14  Marc Glisse  
>>
>> PR c/53024
>> PR c++/54427
>> * doc/extend.texi (Vector Extensions): C++ improvements.
>> Power of 2 size requirement.
>
>
> --
> Marc Glisse

Re: [patch] PR54645 move location_adhoc_data map into GC

[Dehao Chen]

Sorry, I'll change that with my next patch.

Dehao

On Wed, Sep 26, 2012 at 12:20 AM, Eric Botcazou  wrote:
>> gcc/ChangeLog:
>> 2012-09-21  Dehao Chen  
>>
>>   PR middle-end/54645
>>   * c-family/c-pch.c (c_common_read_pch): Rebuild the location_adhoc_data
>>   map when read in the pch.
>
> Wrong ChangeLog file, you want gcc/c-family/ChangeLog (and remove c-family/).
>
> --
> Eric Botcazou

Re: [rtl] combine a vec_concat of 2 vec_selects from the same vector

[Marc Glisse]

Hello,

RTL optimizers looks like a promising category, and Eric like a nice 
maintainer for it, adding in Cc: ;-)


(I bothered Richard Sandiford last time)

On Tue, 11 Sep 2012, Marc Glisse wrote:


On Sun, 9 Sep 2012, Marc Glisse wrote:


Hello,

this patch lets the compiler try to rewrite:

(vec_concat (vec_select x [a]) (vec_select x [b]))

as:

vec_select x [a b]

or even just "x" if appropriate.

In a first iteration I was restricting it to b-a==1, but it seemed better 
not to: it helps for {v[1],v[0]} and doesn't change anything for unknown 
patterns.


Note that I am planning to do a similar optimization at tree level, but it 
shouldn't make this one useless because such patterns can be created during 
rtl passes. The testcase may need an additional -fno-tree-xxx to still be 
useful at that point though.


Since the tree-ssa patch was reviewed faster, assume there is a 
-fno-tree-forwprop in dg-options for the testcase.



bootstrap+testsuite on x86_64-linux-gnu.

2012-09-09  Marc Glisse  

gcc/
* simplify-rtx.c (simplify_binary_operation_1): Handle vec_concat
of vec_selects from the same vector.

gcc/testsuite/
* gcc.target/i386/vect-rebuild.c: New testcase.


http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00540.html


--
Marc Glisse

Re: [PATCH] Fix PR54709

[Richard Guenther]

On Wed, 26 Sep 2012, Richard Guenther wrote:

> On Wed, 26 Sep 2012, Richard Guenther wrote:
> 
> > 
> > This fixes PR54709, the location change broke DECL_IS_BUILTIN which
> > is bogously used by streamer_handle_as_builtin_p.  I am reverting
> > the previous lto-symtab.c change as it is not necessary for fixing
> > the testcases.  LTO bootstrap fails with this again with
> > 
> > /tmp/cca0yEEE.ltrans17.ltrans.o: In function `is_ctor_or_dtor.16889':
> > /space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5506: undefined 
> > reference to `alloca'
> > /space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5507: undefined 
> > reference to `alloca'
> > /tmp/cca0yEEE.ltrans17.ltrans.o: In function `d_demangle_callback.16926':
> > /space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5227: undefined 
> > reference to `alloca'
> > /space/rguenther/src/svn/trunk2/libiberty/cp-demangle.c:5228: undefined 
> > reference to `alloca'
> > collect2: error: ld returned 1 exit status
> > 
> > but we want a testcase for this instead of having it magically "fixed"
> > without being analyzed.
> > 
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> 
> Which revealed issues.  Thus, I'm going with the following, simpler.

Which doesn't fix the issue.  The following does, though, and removes
code which is even better.

Eyed by Honza, LTO bootstrap and regtest running on 
x86_64-unknown-linux-gnu.

I will commit this tomorrow if all things go well.

Richard.

2012-09-26  Richard Guenther  

PR lto/54709
* lto-symtab.c (resolution_guessed_p): Remove.
(set_resolution_guessed): Likewise.
(lto_symtab_register_decl): Remove assert.
(lto_symtab_resolve_symbols): Do not alter symbol resolutions
and return the prevailing symbol, checking for multiple prevailing
symbols here.
(lto_symtab_merge_decls_1): Use the result from
lto_symtab_resolve_symbols.  Do not alter symbol resolutions.

* gcc.dg/lto/pr54709_0.c: New testcase.
* gcc.dg/lto/pr54709_1.c: Likewise.

Index: gcc/lto-symtab.c
===
*** gcc/lto-symtab.c(revision 191756)
--- gcc/lto-symtab.c(working copy)
*** along with GCC; see the file COPYING3.
*** 32,52 
  /* Vector to keep track of external variables we've seen so far.  */
  VEC(tree,gc) *lto_global_var_decls;
  
- /* Return true if the resolution was guessed and not obtained from
-the file.  */
- static inline bool
- resolution_guessed_p (symtab_node node)
- {
-   return node->symbol.aux != NULL;
- }
- 
- /* Set guessed flag for NODE.  */
- static inline void
- set_resolution_guessed (symtab_node node, bool value)
- {
-   node->symbol.aux = (void *)(size_t)value;
- }
- 
  /* Registers DECL with the LTO symbol table as having resolution RESOLUTION
 and read from FILE_DATA. */
  
--- 32,37 
*** lto_symtab_register_decl (tree decl,
*** 78,84 
  {
node->symbol.resolution = resolution;
gcc_assert (node->symbol.lto_file_data == file_data);
-   gcc_assert (!resolution_guessed_p (node));
  }
  }
  
--- 63,68 
*** lto_symtab_resolve_can_prevail_p (symtab
*** 303,309 
  /* Resolve the symbol with the candidates in the chain *SLOT and store
 their resolutions.  */
  
! static void
  lto_symtab_resolve_symbols (symtab_node first)
  {
symtab_node e;
--- 287,293 
  /* Resolve the symbol with the candidates in the chain *SLOT and store
 their resolutions.  */
  
! static symtab_node
  lto_symtab_resolve_symbols (symtab_node first)
  {
symtab_node e;
*** lto_symtab_resolve_symbols (symtab_node
*** 315,341 
&& (e->symbol.resolution == LDPR_PREVAILING_DEF_IRONLY
|| e->symbol.resolution == LDPR_PREVAILING_DEF_IRONLY_EXP
|| e->symbol.resolution == LDPR_PREVAILING_DEF))
!   prevailing = e;
  
/* If the chain is already resolved there is nothing else to do.  */
if (prevailing)
! return;
  
/* Find the single non-replaceable prevailing symbol and
   diagnose ODR violations.  */
for (e = first; e; e = e->symbol.next_sharing_asm_name)
  {
if (!lto_symtab_resolve_can_prevail_p (e))
!   {
! e->symbol.resolution = LDPR_RESOLVED_IR;
!   set_resolution_guessed (e, true);
! continue;
!   }
  
!   /* Set a default resolution - the final prevailing one will get
!  adjusted later.  */
!   e->symbol.resolution = LDPR_PREEMPTED_IR;
!   set_resolution_guessed (e, true);
if (!lto_symtab_resolve_replaceable_p (e))
{
  if (prevailing)
--- 299,331 
&& (e->symbol.resolution == LDPR_PREVAILING_DEF_IRONLY
|| e->symbol.resolution == LDPR_PREVAILING_DEF_IRONLY_EXP
|| e->symbol.resolution == LDPR_PREVAILING_DEF))
!   {
!   prevailing = e;
!   break;
!   }
  
/* If th

Re: Memset/memcpy patch

[H.J. Lu]

On Fri, Aug 31, 2012 at 1:54 AM, Jan Hubicka  wrote:
>> On Mon, Dec 12, 2011 at 6:02 AM, Jan Hubicka  wrote:
>> >> Any update?
>> >
>> > I will look into it today, but anyway I think it is stage1 material, so we 
>> > have some time to progress on it.
>> >
>> > Honza
>>
>> Hi Honza,
>>
>> The old patch was reverted and the new patch was posted at
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00336.html
>>
>> Have you got a chance to review it?
>
> I am in China till 5th, I will try to return to it shortly after returning.
> Ping me again if not - there seems to be a lot of work left on this patch...
>

Hi Honza, Michael,

Any changes to get it into GCC 4.8?

Thanks.


-- 
H.J.

Re: [i386] recognize haddpd

[Marc Glisse]

Adding an x86 maintainer in Cc:

On Tue, 11 Sep 2012, Marc Glisse wrote:


Hello,

any advice?
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00044.html


On Sun, 2 Sep 2012, Marc Glisse wrote:


Hello,

this patch passes bootstrap+testsuite. It is probably wrong in many ways, 
but I don't know enough to do more without some advice.


The goal is to recognize that v[0]+v[1] can be computed with haddpd. With 
the patch, v[0]-v[1] becomes hsubpd and v[1]+v[0] becomes haddpd. Also, 
thanks to it, {v[0]-v[1], w[0]-w[1]} is now recognized as a single hsubpd.


1) Is a define_insn the right tool?
2) {v[0]-v[1], v[0]-v[1]} is not recognized as a hsubpd because 
vec_duplicate doesn't match vec_concat. Do we really need to duplicate (no 
pun intended) the pattern?
3) v[0]+v[1] is not recognized. Some pass changed their order, and nothing 
tries the reverse order. I can see 3 ways: canonicalize the order at some 
point, let combine try both orders for commutative operators or make the 
patterns more flexible (I don't know how many would need changing).
4) I don't understand the set_attr part. I copied it from the haddpd 
define_insn, and removed (set_attr "type" "sseadd") because it crashed the 
compiler. isa and prefix make sense and they match the alternatives, but I 
am not sure about "mode" (removing it still works IIRC).



2012-09-02  Marc Glisse  

gcc/
* config/i386/sse.md (*sse3_hv2df3_low): New.

gcc/testsuite/
* gcc.target/i386/pr54400.c: New testcase.


--
Marc Glisse

[google] mis-fired error message on extern alias (LIPO mode)

[Xinliang David Li]

The following patch fixes a mis-fired error on extern alias
(same-body). The assembler hash related code needs rework to avoid
patches like this. (The bug was found during a large grouping stress
test).

David


extern_alias.p
Description: Binary data

Re: Ping: PATCH RFA: Print backtrace on ICE

[H.J. Lu]

On Thu, Sep 20, 2012 at 10:33 PM, Ian Lance Taylor  wrote:
> Ping.
>
> The patch is the same, so I didn't attach it again.  It may be found
> at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01174.html . I think
> I've replied to all comments.
>

It breaks Linux/i686 build:

../../src-trunk/gcc/diagnostic.c: In function 'int bt_callback(void*,
uintptr_t, const char*, int, const char*)':
../../src-trunk/gcc/diagnostic.c:370:11: error: format '%lx' expects
argument of type 'long unsigned int', but argument 3 has type
'uintptr_t {aka unsigned int}' [-Werror=format]
 lineno);
   ^

-- 
H.J.

Re: [CPP] Add pragmas for emitting diagnostics

[Basile Starynkevitch]

On Tue, Sep 25, 2012 at 04:25:08PM +0200, Florian Weimer wrote:
> This patch adds support for #pragma GCC warning and #pragma GCC
> error. These pragmas can be used from preprocessor macros, unlike
> the existing #warning and #error directives.  Library authors can
> use these pragmas to add deprecation warnings to macros they define.
> 
> Bootstrapped and tested on x86_64-redhat-linux-gnu, with no apparent
> regressions.  Okay for trunk?


I can't approve your patch, but I find it useful and wish it would be accepted.

Cheers.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[patch, testsuite, pr37303] Fix testcase on MIPS

[Steve Ellcey]

The test gcc.dg/pr37303.c fails on mips because mips uses rdata instead
of rodata and the test scans for rodata in the assembly file.  Rather
then make an special check on mips I modified the test to scan for rodata
or rdata on any plaforms.

Tested on MIPS, OK to checkin?

Steve Ellcey
sell...@mips.com


2012-09-26  Steve Ellcey  

PR c/37303
* gcc.dg/pr37303.c: Check for rdata or rodata.


diff --git a/gcc/testsuite/gcc.dg/pr37303.c b/gcc/testsuite/gcc.dg/pr37303.c
index 434fc9d..ea0827c 100644
--- a/gcc/testsuite/gcc.dg/pr37303.c
+++ b/gcc/testsuite/gcc.dg/pr37303.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target *-*-elf* *-*-linux-gnu* } } */
 /* { dg-options "-std=c99" }
-/* { dg-final { scan-assembler "rodata" } } */
+/* { dg-final { scan-assembler "rdata|rodata" } } */
 
 struct S { const int *x; } s = { (const int[]){1, 2, 3} };

Re: [PATCH] normal_distribution performance improvement with SSE

[Marc Glisse]

On Wed, 26 Sep 2012, Ulrich Drepper wrote:


On Wed, Sep 26, 2012 at 7:32 AM, Jakub Jelinek  wrote:

Have you considered also an __AVX__ version handling 4 elements at a time?
Without __AVX2__ one would need to cast __m256i to __m256d for and/or, as
AVX1 doesn't have _mm256_and_si256 or _mm256_or_si256, but _mm256_and_pd
or _mm256_or_pd could be used instead.


Or we can just use '|' on __m256i vectors, which generates a suitable 
instruction depending on -mavx/-mavx2.



One step to do first.


:-)


Currently the random number engine interface is
inefficient since it returns a single number.  What we need is an
additional interface to return vectors.


Isn't the __generate interface good enough?

--
Marc Glisse

PS: mixed scalar-vector operations are posted here:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01557.html

after that, C and C++ should be at the same level.

Re: Ping: PATCH RFA: Print backtrace on ICE

[Rainer Orth]

"H.J. Lu"  writes:

> On Thu, Sep 20, 2012 at 10:33 PM, Ian Lance Taylor  wrote:
>> Ping.
>>
>> The patch is the same, so I didn't attach it again.  It may be found
>> at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01174.html . I think
>> I've replied to all comments.
>>
>
> It breaks Linux/i686 build:
>
> ../../src-trunk/gcc/diagnostic.c: In function 'int bt_callback(void*,
> uintptr_t, const char*, int, const char*)':
> ../../src-trunk/gcc/diagnostic.c:370:11: error: format '%lx' expects
> argument of type 'long unsigned int', but argument 3 has type
> 'uintptr_t {aka unsigned int}' [-Werror=format]
>  lineno);
>^

... and sparc-sun-solaris2*.

Rainer

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

Re: [PATCH] normal_distribution performance improvement with SSE

[Ulrich Drepper]

On Wed, Sep 26, 2012 at 12:14 PM, Marc Glisse  wrote:
>> Currently the random number engine interface is
>> inefficient since it returns a single number.  What we need is an
>> additional interface to return vectors.
>
>
> Isn't the __generate interface good enough?

__generate is for the distributions.  I'm talking about the engines.
Bulk access isn't that easy there.  The stream is deterministic and if
I request 32 bytes of entropy although I only need 16 bytes I cannot
push back the remaining 16 bytes.  Without that the next use of the
engine would produce different bits.

Re: [PATCH] Do not mark pseudo-copies decomposable during first lower-subreg pass

[Richard Sandiford]

"Ulrich Weigand"  writes:
> ChangeLog:
>
>   * lower-subreg.c (enum classify_move_insn): Rename
>   SIMPLE_PSEUDO_REG_MOVE to DECOMPOSABLE_SIMPLE_MOVE.
>   (find_decomposable_subregs): Update.
>   (decompose_multiword_subregs): Add DECOMPOSE_COPIES parameter.
>   Only mark pseudo-to-pseudo copies as DECOMPOSABLE_SIMPLE_MOVE
>   if that parameter is true.
>   (rest_of_handle_lower_subreg): Call decompose_multiword_subregs
>   with DECOMPOSE_COPIES false.
>   (rest_of_handle_lower_subreg2): Call decompose_multiword_subregs
>   with DECOMPOSE_COPIES true.

OK, thanks.

Richard

Re: Ping: PATCH RFA: Print backtrace on ICE

[Ian Lance Taylor]

On Wed, Sep 26, 2012 at 8:32 AM, H.J. Lu  wrote:
> On Thu, Sep 20, 2012 at 10:33 PM, Ian Lance Taylor  wrote:
>> Ping.
>>
>> The patch is the same, so I didn't attach it again.  It may be found
>> at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01174.html . I think
>> I've replied to all comments.
>>
>
> It breaks Linux/i686 build:
>
> ../../src-trunk/gcc/diagnostic.c: In function 'int bt_callback(void*,
> uintptr_t, const char*, int, const char*)':
> ../../src-trunk/gcc/diagnostic.c:370:11: error: format '%lx' expects
> argument of type 'long unsigned int', but argument 3 has type
> 'uintptr_t {aka unsigned int}' [-Werror=format]

Sorry about that.  Fixed like so.  Committed to mainline.

Ian


2012-09-26  Ian Lance Taylor  

* diagnostic.c (bt_callback): Cast pc when calling fprintf.


foo.patch
Description: Binary data

Re: [PATCH, rtl-optimization]: Fix PR54457, [x32] Fail to combine 64bit index + constant

[Richard Sandiford]

Uros Bizjak  writes:
> The solution is, to transform operands of PLUS and MINUS RTX in the
> form of (subreg:M (op:N A C) 0) to (op:M (subreg:N (A 0)) C), as is
> done for standalone subreg operation in 32bit case.

I agree (subreg:M (op:N A C) 0) to (op:M (subreg:N (A 0)) C) is
a good transformation, but why do we need to handle as special
the case where the subreg is itself the operand of a plus or minus?
I think it should happen regardless of where the subreg occurs.

On the face of it, this feels like something that could legimately
go in simplify_subreg.

Richard

Re: [patch, testsuite, pr37303] Fix testcase on MIPS

[Richard Sandiford]

"Steve Ellcey "  writes:
> 2012-09-26  Steve Ellcey  
>
>   PR c/37303
>   * gcc.dg/pr37303.c: Check for rdata or rodata.

OK, thanks.

Richard

Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)

[Lawrence Crowl]

On 9/26/12, Michael Matz  wrote:
> On Tue, 25 Sep 2012, Lawrence Crowl wrote:
> > On 8/15/12, Richard Henderson  wrote:
> > > On 2012-08-15 07:29, Richard Guenther wrote:
> > > > typedef typename Element::Element_t Element_t;
> > >
> > > Can we use something less ugly than Element_t?
> > > Such as typedef typename Element::T T;
> > > ?  Given that this name is scoped anyway...
> >
> > I've been finding the use of T as a typedef confusing.
>
> Why?  As type placeholder in templates it's quite customary,
> as the "most interesting to users of this template".  I would
> have no trouble at all to see declarations like "T x = getme();"
> in a function.  In some way I even prefer that to some lower-case
> variant, because it reminds me that this specific "T" is actually
> variant.

The problem is that while T is customary as a template parameter, I
have never seen it used as a typedef name.  And that's the situation
that we are in now.

> A lower-case type name indicates to me a non-changing type,
> i.e. nothing that depends on a template.  In C we only had
> such types so we used lower-case names everywhere.  With C++
> and templates I think we should start using upper case for some
> very specific use cases, like first letter of dependend types.

How would you distinguish them from template parameter names,
which by convention have an upper case first letter?

What about non-type dependent names?

I think we really do need a separate convention for the two,
because dependent members of class templates often need special
access syntax.

> > It sort of flies in the face of all existing convention.
>
> If you talk about the conventions used for the c++ standard
> library, then they are IMHO quite ugly and we should not follow
> them.

The advantage to following them is that they will surprise no one.
Do you have an alternate suggestion, one that does not confuse
template parameters and dependent names?

-- 
Lawrence Crowl

Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)

[Gabriel Dos Reis]

On Wed, Sep 26, 2012 at 1:09 PM, Lawrence Crowl  wrote:
>
> The problem is that while T is customary as a template parameter, I
> have never seen it used as a typedef name.  And that's the situation
> that we are in now.

this should be a no-brainer: T should be reserved for the name of the
template parameter.
[...]

> I think we really do need a separate convention for the two,
> because dependent members of class templates often need special
> access syntax.

Yes.

-- Gaby

[PATCH] Fix some nits in clear_unused_block_pointer

[Dehao Chen]

This patch fixes some small nits.

Bootstrapped and passed gcc regression tests.

Is it ok for trunk?

Thanks,
Dehao

gcc/ChangeLog:

2012-09-26  Dehao Chen  

* tree-ssa-live.c (clear_unused_block_pointer): Fix two small nits.

Index: gcc/tree-ssa-live.c
===
--- gcc/tree-ssa-live.c (revision 191765)
+++ gcc/tree-ssa-live.c (working copy)
@@ -627,7 +627,7 @@
so that they will not be streamed out.  */

 static void
-clear_unused_block_pointer ()
+clear_unused_block_pointer (void)
 {
   basic_block bb;
   gimple_stmt_iterator gsi;
@@ -814,7 +814,7 @@
 }

   FOR_EACH_EDGE (e, ei, bb->succs)
- if (e->goto_locus)
+ if (LOCATION_BLOCK (e->goto_locus))
   TREE_USED (LOCATION_BLOCK (e->goto_locus)) = true;
 }

Re: [CPP] Add pragmas for emitting diagnostics

[Tom Tromey]

> "Florian" == Florian Weimer  writes:

Florian> This patch adds support for #pragma GCC warning and #pragma GCC
Florian> error. These pragmas can be used from preprocessor macros,
Florian> unlike the existing #warning and #error directives.  Library
Florian> authors can use these pragmas to add deprecation warnings to
Florian> macros they define.

I'm not sure if my libcpp review powers extend to an extension like
this.

It seems reasonable to me though.

Florian> Index: gcc/doc/cpp.texi
[...]
Florian> +contained in the pragma must be a single string literal.  Similary,

Typo, "similarly" -- missing "l".

Florian> +@code{#pragma GCC error "message"} issues an error message.  Unlike
Florian> +the @samp{#warning} and @samp{#error} directives provided by
Florian> +compilers, these pragmas can be embedded in preprocessor macros using

I would just remove "provided by compilers".

Florian> +  cpp_error (pfile, CPP_DL_ERROR, "invalid #pragma GCC %s 
directive",

It seems to me that the '#pragma GCC %s' part should have quotes around
it.

Tom

[PATCH] [MELT] An alternative probe for GCC MELT

[Alexandre Lissy]

Hello,

As I reported on the gcc-m...@googlegroups.com list, I experienced bad
behavior of the GtkMM probe for MELT. I identified the issue as linked
to the amount of inline buttons added in the source code, but was not
able to fix or identify the root of the issue. Since I'm not very
skilled with C++ and Gtk, I decided to provide another implementation of
the probe, writing it using Qt4 and Python. I hope it makes the source
easier to read and hack.

It's now nearly as functionnal as the original one, so I'm proposing the
attached patch that adds this probe under the contrib/ directory.
>From 4f32b3261c730a0002a4c316bc64c4ae40fc5eb7 Mon Sep 17 00:00:00 2001
From: Alexandre Lissy 
Date: Wed, 26 Sep 2012 18:26:39 +0200
Subject: [PATCH] 2012-09-26  Alexandre Lissy  

[contrib/]
* simplemelt-pyqt4-probe.py: Introducing another implementation of
  the MELT probe, written in Python and Qt4.
---
 contrib/ChangeLog.MELT|3 +
 contrib/simplemelt-pyqt4-probe.py |  780 +
 2 files changed, 783 insertions(+)
 create mode 100644 contrib/simplemelt-pyqt4-probe.py

diff --git a/contrib/ChangeLog.MELT b/contrib/ChangeLog.MELT
index bb529ed..56e83d0 100644
--- a/contrib/ChangeLog.MELT
+++ b/contrib/ChangeLog.MELT
@@ -1,3 +1,6 @@
+2012-09-26  Alexandre Lissy  
+
+	* simplemelt-pyqt4-probe.py: Adding Python/Qt4 probe
 
 2012-09-24  Basile Starynkevitch  
 
diff --git a/contrib/simplemelt-pyqt4-probe.py b/contrib/simplemelt-pyqt4-probe.py
new file mode 100644
index 000..4271763
--- /dev/null
+++ b/contrib/simplemelt-pyqt4-probe.py
@@ -0,0 +1,780 @@
+#!/usr/bin/python
+# -*- coding: utf-8 -*-
+# vim: set ts=4 sw=4 et:
+
+#  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 .
+
+"""
+MELT probe in PyQt
+"""
+
+import sys
+import os
+import argparse
+import select
+import pprint
+import re
+import logging
+from datetime import datetime
+from threading import Thread
+from PyQt4.QtGui import *
+from PyQt4.QtCore import *
+from PyQt4.Qsci import *
+
+MELT_SIGNAL_UNHANDLED_COMMAND = SIGNAL("unhandledCommand(PyQt_PyObject)")
+MELT_SIGNAL_DISPATCH_COMMAND = SIGNAL("dispatchCommand(PyQt_PyObject)")
+MELT_SIGNAL_APPEND_TRACE_COMMAND = SIGNAL("appendCommand(PyQt_PyObject)")
+MELT_SIGNAL_APPEND_TRACE_REQUEST = SIGNAL("appendRequest(PyQt_PyObject)")
+MELT_SIGNAL_SOURCE_SHOWFILE = SIGNAL("sourceShowfile(PyQt_PyObject)")
+MELT_SIGNAL_SOURCE_MARKLOCATION = SIGNAL("sourceMarklocation(PyQt_PyObject)")
+MELT_SIGNAL_SOURCE_INFOLOCATION = SIGNAL("sourceInfoLocation(PyQt_PyObject)")
+MELT_SIGNAL_ASK_INFOLOCATION = SIGNAL("askInfoLocation(PyQt_PyObject)")
+MELT_SIGNAL_MOVE_TO_INDICATOR = SIGNAL("moveToIndicator(PyQt_PyObject)")
+
+MELT_SIGNAL_SOURCE_STARTINFOLOC = SIGNAL("startInfoLocation(PyQt_PyObject)")
+MELT_SIGNAL_SOURCE_ADDINFOLOC = SIGNAL("addInfoLocation(PyQt_PyObject)")
+
+MELT_SIGNAL_SHOWFILE_COMPLETE = SIGNAL("showfileComplete(PyQt_PyObject)")
+
+MELT_SIGNAL_INFOLOC_COMPLETE = SIGNAL("infolocComplete(PyQt_PyObject)")
+
+MELT_SIGNAL_INFOLOC_QUIT = SIGNAL("quitInfoloc()")
+
+MELT_SIGNAL_UPDATECOUNT = SIGNAL("updateCount(PyQt_PyObject)")
+MELT_SIGNAL_UPDATECURRENT = SIGNAL("updateCurrent(PyQt_PyObject)")
+
+MELT_SIGNAL_GETVERSION = SIGNAL("getVersion(PyQt_PyObject)")
+
+logger = logging.getLogger('melt-probe')
+console = logging.StreamHandler()
+formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
+console.setFormatter(formatter)
+logger.addHandler(console)
+
+class MeltInfoLoc(QMainWindow):
+INFOLOC_IDENT_RE = re.compile(r"(\d+):(.*)")
+
+def __init__(self):
+QMainWindow.__init__(self)
+self.handled_marknums = {}
+self.initUI()
+
+def initUI(self):
+window = QWidget()
+self.vlayout = QVBoxLayout()
+self.tree = QTreeWidget()
+# {'marknum': 543, 'command': 'addinfoloc', 'filenum': 1, 'payload': [' "1:Basic Block #10 Gimple Seq', '[drivers/media/rc/imon.c : 1247:10] rel_x.11 = (signed char) rel_x;\\n[drivers/media/rc/imon.c : 1247:10] D.21223 = rel_x.11 | -16;\\n[drivers/media/rc/imon.c : 1247:10] rel_x = (char) D.21223;\\n"  ']}
+# columns:
+#  - "1" -> infolocid
+#  - "Basic Block #10 Gimple Seq" -> bb
+#  - ... -> content
+self.tree.setColumnCount(3)
+self.tree.setHeaderLabels(["ID", "Block", "Content"])
+self.vlayout.addWidget(self.tre

[patch, doc] Fix example of multiple baseboards, PR 54711

[Steve Ellcey]

While doing some testing and trying to run multiple versions of the GCC
testsuite (big-endian, little-endian, etc) I looked at the example at
http://gcc.gnu.org/install/test.html and thought I could run multiple
versions by using multiple --target_board flags in RUNTESTFLAGS.  It turns
out this does not work and what you want to do is use one target_board
flag with a space seperated list of boardnames/options.

This patch changes the example to make that more clear.

OK to checkin?

Steve Ellcey
sell...@mips.com


2012-09-26  Steve Ellcey  

PR web/54711
* doc/install.texi: Fix example.


diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index d4384e8..bc692d4 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2567,14 +2567,14 @@ The following will run each testsuite eight times using 
the @samp{arm-sim}
 target, as if you had specified all possible combinations yourself:
 
 @smallexample
---target_board=arm-sim/-mhard-float/-O1
---target_board=arm-sim/-mhard-float/-O2
---target_board=arm-sim/-mhard-float/-O3
---target_board=arm-sim/-mhard-float
---target_board=arm-sim/-msoft-float/-O1
---target_board=arm-sim/-msoft-float/-O2
---target_board=arm-sim/-msoft-float/-O3
---target_board=arm-sim/-msoft-float
+--target_board='arm-sim/-mhard-float/-O1 \
+arm-sim/-mhard-float/-O2 \
+arm-sim/-mhard-float/-O3 \
+arm-sim/-mhard-float \
+arm-sim/-msoft-float/-O1 \
+arm-sim/-msoft-float/-O2 \
+arm-sim/-msoft-float/-O3 \
+arm-sim/-msoft-float'
 @end smallexample
 
 They can be combined as many times as you wish, in arbitrary ways.  This

Re: [PATCH] [MELT] An alternative probe for GCC MELT

[Basile Starynkevitch]

On Wed, Sep 26, 2012 at 10:28:14PM +0200, Alexandre Lissy wrote:
> Hello,
> 
> As I reported on the gcc-m...@googlegroups.com list, I experienced bad
> behavior of the GtkMM probe for MELT. I identified the issue as linked
> to the amount of inline buttons added in the source code, but was not
> able to fix or identify the root of the issue. Since I'm not very
> skilled with C++ and Gtk, I decided to provide another implementation of
> the probe, writing it using Qt4 and Python. I hope it makes the source
> easier to read and hack.
> 
> It's now nearly as functionnal as the original one, so I'm proposing the
> attached patch that adds this probe under the contrib/ directory.


Thanks. I just commited svn rev 191773 on the MELT branch

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Ping: PATCH RFA: Print backtrace on ICE

[Dominique Dhumieres]

On Thu, Sep 20, 2012 at 10:33 PM, Ian Lance Taylor  wrote:
> Ping.
>
> The patch is the same, so I didn't attach it again.  It may be found
> at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01174.html . I think
> I've replied to all comments.
>

It also breaks the building of the Ada tools:

...
../../xgcc -B../../  -I- -I../rts -I. -I/opt/gcc/work/gcc/ada -DIN_GCC  -g -O2 
-W -Wall  -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o aspects.o 
s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o 
einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o 
fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o 
lib.o make.o makeusg.o makeutl.o mlib.o mlib-fil.o mlib-prj.o mlib-tgt.o 
mlib-tgt-specific.o mlib-utl.o namet.o nlists.o opt.o osint.o osint-m.o 
output.o prj.o prj-attr.o prj-attr-pm.o prj-com.o prj-dect.o prj-env.o 
prj-conf.o prj-pp.o prj-err.o prj-ext.o prj-nmsc.o prj-pars.o prj-part.o 
prj-proc.o prj-strt.o prj-tree.o prj-util.o restrict.o rident.o s-exctab.o 
s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o 
s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o sinput.o sinput-c.o 
sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o 
switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o 
uname.o urealp.o usage.o widechar.o  \
targext.o link.o ../../ggc-none.o ../../libcommon-target.a 
../../libcommon.a ../../../libcpp/libcpp.a ../rts/libgnat.a 
../../../intl/libintl.a -liconv  ../../../libiberty/libiberty.a  
Undefined symbols:
  "_backtrace_full", referenced from:
  diagnostic_action_after_output(diagnostic_context*, diagnostic_info*) 
[clone .isra.3] in libcommon.a(diagnostic.o)
  "_backtrace_create_state", referenced from:
  diagnostic_action_after_output(diagnostic_context*, diagnostic_info*) 
[clone .isra.3] in libcommon.a(diagnostic.o)
ld: symbol(s) not found
collect2: error: ld returned 1 exit status
make[3]: *** [../../gnatmake] Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [gnattools-native] Error 2
make[1]: *** [all-gnattools] Error 2
make: *** [all] Error 2

and so on at stage 3; I worked around the problem by adding
../../../libbacktrace/.libs/libbacktrace.a to TOOLS_LIBS in
gcc/ada/gcc-interface/Makefile (yes, I know this is not the right fix;-)

TIA

Dominique

Re: [Patch] catch builtin_bswap16 construct

[Oleg Endo]

On Mon, 2012-09-24 at 09:47 +0200, Oleg Endo wrote:
> On Mon, 2012-09-24 at 09:15 +0200, Eric Botcazou wrote:
> > > A while ago I've tried doing that for SH (implementing bswap16 with RTL
> > > combine).  It was like an explosion of patterns, because combine would
> > > try out a lot of things depending on the surrounding code around the
> > > actual bswap16.  In the end I decided to drop that stuff for the most
> > > part.
> > 
> > OK, thanks for your feedback.  Note that you won't get the benefit of the 
> > optimization for SH if you don't define a bswaphi2 pattern.
> 
> Sure sure.  I'll resume my efforts after Christophe's patch is in.
> 
> > 
> > > BTW, the built-in documentation says:
> > > 
> > > Built-in Function: int16_t __builtin_bswap16 (int16_t x)
> > > Built-in Function: int32_t __builtin_bswap32 (int32_t x)
> > > 
> > > However, it seems the result is always unsigned for those.
> > 
> > Yes, builtins.def contains:
> > 
> > DEF_GCC_BUILTIN(BUILT_IN_BSWAP16, "bswap16", BT_FN_UINT16_UINT16, 
> > ATTR_CONST_NOTHROW_LEAF_LIST)
> > DEF_GCC_BUILTIN(BUILT_IN_BSWAP32, "bswap32", BT_FN_UINT32_UINT32, 
> > ATTR_CONST_NOTHROW_LEAF_LIST)
> > DEF_GCC_BUILTIN(BUILT_IN_BSWAP64, "bswap64", BT_FN_UINT64_UINT64, 
> > ATTR_CONST_NOTHROW_LEAF_LIST)
> > 
> > The documentation indeed needs to be fixed.
> > 
> 
> OK, I'll check it out.

I have committed the attached obvious patch as rev 191774.

Cheers,
Oleg


ChangeLog:

* doc/extend.texi (bswap Builtins): Change signed types to
unsigned types.

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 191773)
+++ gcc/doc/extend.texi	(working copy)
@@ -8611,18 +8611,18 @@
 are @code{long double}.
 @end deftypefn
 
-@deftypefn {Built-in Function} int16_t __builtin_bswap16 (int16_t x)
+@deftypefn {Built-in Function} uint16_t __builtin_bswap16 (uint16_t x)
 Returns @var{x} with the order of the bytes reversed; for example,
 @code{0xaabb} becomes @code{0xbbaa}.  Byte here always means
 exactly 8 bits.
 @end deftypefn
 
-@deftypefn {Built-in Function} int32_t __builtin_bswap32 (int32_t x)
+@deftypefn {Built-in Function} uint32_t __builtin_bswap32 (uint32_t x)
 Similar to @code{__builtin_bswap16}, except the argument and return types
 are 32-bit.
 @end deftypefn
 
-@deftypefn {Built-in Function} int64_t __builtin_bswap64 (int64_t x)
+@deftypefn {Built-in Function} uint64_t __builtin_bswap64 (uint64_t x)
 Similar to @code{__builtin_bswap32}, except the argument and return types
 are 64-bit.
 @end deftypefn

Re: [CPP] Add pragmas for emitting diagnostics

[Robert Dewar]

On 9/26/2012 4:19 PM, Tom Tromey wrote:

"Florian" == Florian Weimer  writes:


Florian> This patch adds support for #pragma GCC warning and #pragma GCC
Florian> error. These pragmas can be used from preprocessor macros,
Florian> unlike the existing #warning and #error directives.  Library
Florian> authors can use these pragmas to add deprecation warnings to
Florian> macros they define.

I'm not sure if my libcpp review powers extend to an extension like
this.

It seems reasonable to me though.


To me too, these correspond to the Compile_Time_Warning and 
Compile_Time_Error in Ada, and are definitely very useful!

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

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

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

[Translation Project Robot]

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

New Swedish PO file for 'gcc' (version 4.7.2)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: [PATCH, rtl-optimization]: Fix PR54457, [x32] Fail to combine 64bit index + constant

[Eric Botcazou]

> I agree (subreg:M (op:N A C) 0) to (op:M (subreg:N (A 0)) C) is
> a good transformation, but why do we need to handle as special
> the case where the subreg is itself the operand of a plus or minus?
> I think it should happen regardless of where the subreg occurs.

Don't we need to restrict this to the low part though?

-- 
Eric Botcazou

[ping patch] Predict for loop exits in short-circuit conditions

[Dehao Chen]

http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01975.html

Thanks,
Dehao

Re: Memset/memcpy patch

[Michael Zolotukhin]

Hi HJ,
The last-year patch is currently almost useless, as efforts needed for
its rebase seem to be almost the same as efforts needed for writing it
from scratch. I hoped to make a patch covering at least subset of
cases, but unfortunately haven't had time even for it yet.

What time do we have for it now, when does stage1 finish?

Thanks, Michael

On 26 September 2012 19:00, H.J. Lu  wrote:
> On Fri, Aug 31, 2012 at 1:54 AM, Jan Hubicka  wrote:
>>> On Mon, Dec 12, 2011 at 6:02 AM, Jan Hubicka  wrote:
>>> >> Any update?
>>> >
>>> > I will look into it today, but anyway I think it is stage1 material, so 
>>> > we have some time to progress on it.
>>> >
>>> > Honza
>>>
>>> Hi Honza,
>>>
>>> The old patch was reverted and the new patch was posted at
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00336.html
>>>
>>> Have you got a chance to review it?
>>
>> I am in China till 5th, I will try to return to it shortly after returning.
>> Ping me again if not - there seems to be a lot of work left on this patch...
>>
>
> Hi Honza, Michael,
>
> Any changes to get it into GCC 4.8?
>
> Thanks.
>
>
> --
> H.J.



-- 
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.

Re: [PATCH] Fix some nits in clear_unused_block_pointer

[Ian Lance Taylor]

On Wed, Sep 26, 2012 at 12:46 PM, Dehao Chen  wrote:
> This patch fixes some small nits.
>
> Bootstrapped and passed gcc regression tests.
>
> Is it ok for trunk?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog:
>
> 2012-09-26  Dehao Chen  
>
> * tree-ssa-live.c (clear_unused_block_pointer): Fix two small nits.

I know it's tedious, but this is meaningless to a future reader.
Better to say what you changed.  E.g.,

* tree-ssa-live.c (clear_unused_block_pointer): Use explicit
(void) for parameters.  Don't use LOCATION_BLOCK if it is NULL.

>  static void
> -clear_unused_block_pointer ()
> +clear_unused_block_pointer (void)

I don't think we need to say (void) any more now that we use C++.  But
I guess it does no harm.

>FOR_EACH_EDGE (e, ei, bb->succs)
> - if (e->goto_locus)
> + if (LOCATION_BLOCK (e->goto_locus))
>TREE_USED (LOCATION_BLOCK (e->goto_locus)) = true;

Please write if (LOCATION_BLOCK (e->goto_locus) != NULL).

This is OK with those changes.

Thanks.

Ian

RFA: Improve doloop_begin support

[Joern Rennecke]

ARCompact is one of the architectures that have zero-overhead loops that
are initiated with an instruction at the loop top.  There is a way to
set up loops before jumping into their middle, by poking values into
control registers, but that method is more costly and thus only pays off
with a higher minimum iteration count.
Thus, the iteration count to doloop_end isn't all that helpful without an
indication if the loop is entered at its top.

Also, loops that are well-formed ones entered at the top can at rtl expansion
time can get mangled by the rtl optimizers, and/or their doloop_begin pattern
moved away so that it no longer matches the loop.  In order to give the port
a chance at machine_dependent_reorg / instruction output time to verify if
there are matching patterns present, it first has to be able to record which
doloop_begin and doloop_end statements belong together.

The patch attached below as doloop-patch-2-2 addresses these two issue by
adding an operand to doloop_end to indicate if the loop is entered at its
top, and one to doloop_begin which is the doloop_end instruction.

I have tested this patch with a variant of contrib/config-list.mk that
I trimmed to test configurations existing ports with doloop_end  
patterns, i.e.:

LIST = \
  arm-linux-androideabi arm-uclinux_eabi arm-eabi \
  arm-symbianelf \
  bfin-elf bfin-uclinux bfin-linux-uclibc bfin-rtems bfin-openbsd \
  c6x-elf c6x-uclinux \
  ia64-elf \
  ia64-freebsd6 ia64-linux ia64-hpux \
  mep-elf \
  powerpc-darwin8 \
  powerpc-darwin7 powerpc64-darwin powerpc-freebsd6 powerpc-netbsd \
  powerpc-eabispe powerpc-eabisimaltivec powerpc-eabisim ppc-elf \
  powerpc-eabialtivec powerpc-xilinx-eabi powerpc-eabi \
  powerpc-rtems4.11OPT-enable-threads=yes powerpc-linux_spe \
  powerpc-linux_paired powerpc64-linux_altivec \
  powerpc-wrs-vxworks powerpc-wrs-vxworksae powerpc-lynxos powerpcle-elf \
  powerpcle-eabisim powerpcle-eabi rs6000-ibm-aix4.3 rs6000-ibm-aix5.1.0 \
  rs6000-ibm-aix5.2.0 rs6000-ibm-aix5.3.0 rs6000-ibm-aix6.0 \
  s390-linux-gnu s390x-linux-gnu s390x-ibm-tpf sh-elf \
  shle-linux sh-netbsdelf sh-superh-elf sh5el-netbsd sh64-netbsd sh64-linux \
  sh64-elfOPT-with-newlib sh-rtems sh-wrs-vxworks \
  spu-elf tilegx-linux-gnu tilepro-linux-gnu \

FWIW, I left out arm-wrs-vxworks, arm-netbsdelf and ia64-hp-vms because
these configurations are currently broken and there are sufficient  
working configurations to cover arm / ia64.


As baseline for testing I used revision 191658, with a patch set to get
c6x / mep / rs6000 tilegx / tilepro to build, to be found in the
second attachment loop-patch-2-1 .  This allows the above mentioned list of
configurations to build, except for powerpc*-darwin*.

To be clear, I'm asking here for approval of doloop-patch-2-2, not the
collection of patches to get a working baseline.
If/how c6x / mep / rs6000 / tilegx / tilepro ports should be fixed
would be subject to separate discussions.
2012-09-26  J"orn Rennecke  

* loop-doloop.c (doloop_modify): Pass doloop_end pattern to
gen_doloop_begin.
* loop-doloop.c (doloop_optimize): Pass flag to indicate if loop is
entered at top to gen_doloop_end.
* config/arm/thumb2.md (doloop_end): Accept extra operand.
* config/bfin/bfin.md (doloop_end): Likewise.
* config/c6x/c6x.md (doloop_end): Likewise.
* config/ia64/ia64.md (doloop_end): Likewise.
* config/mep/mep.md (doloop_begin, doloop_end): Likewise.
* config/rs6000/rs6000.md (doloop_end): Likewise.
* config/s390/s390.md (doloop_end): Likewise.
* config/sh/sh.md (doloop_end): Likewise.
* config/spu/spu.md (doloop_end): Likewise.
* config/tilegx/tilegx.md (doloop_end): Likewise.
* config/tilepro/tilepro.md (doloop_end): Likewise.
* doc/md.texi (doloop_end): Document new operand.

Index: gcc/gcc/config/arm/thumb2.md
===
--- gcc/gcc/config/arm/thumb2.md(revision 191658)
+++ gcc/gcc/config/arm/thumb2.md(working copy)
@@ -996,7 +996,8 @@ (define_expand "doloop_end"
(use (match_operand 1 "" ""))  ; iterations; zero if unknown
(use (match_operand 2 "" ""))  ; max iterations
(use (match_operand 3 "" ""))  ; loop level
-   (use (match_operand 4 "" ""))] ; label
+   (use (match_operand 4 "" ""))  ; label
+   (use (match_operand 5 "" ""))] ; flag: 1 if loop entered at top, else 0
   "TARGET_32BIT"
   "
  {
Index: gcc/gcc/config/bfin/bfin.md
===
--- gcc/gcc/config/bfin/bfin.md (revision 191658)
+++ gcc/gcc/config/bfin/bfin.md (working copy)
@@ -1933,6 +1933,7 @@ (define_insn "*tablejump_internal"
 ; operand 2 is the maximum number of loop iterations
 ; operand 3 is the number of levels of enclosed loops
 ; operand 4 is the label to jump to at the top of the loop
+; operand 5 indicates if the loop is entered at the top

Re: [PATCH, ARM] Fix PR44557 (Thumb-1 ICE)

[Janis Johnson]

On 09/26/2012 01:58 AM, Chung-Lin Tang wrote:

+/* { dg-do compile } */
+/* { dg-options "-mthumb -O1 -march=armv5te -fno-omit-frame-pointer 
-fno-forward-propagate" }  */
+/* { dg-require-effective-target arm_thumb1_ok } */

This test will fail to compile for test flags that conflict with
the -march option, and the specified -march option might be
overridden with similar options from other test flags.  The problem
might have also been seen for other -march options.  I recommend
leaving it off and omitting the dg-require so the test can be run
for more multilibs.

Janis

Re: [patch, doc] Fix example of multiple baseboards, PR 54711

[Mike Stump]

On Sep 26, 2012, at 1:28 PM, Steve Ellcey  wrote:
> While doing some testing and trying to run multiple versions of the GCC
> testsuite (big-endian, little-endian, etc) I looked at the example at
> http://gcc.gnu.org/install/test.html and thought I could run multiple
> versions by using multiple --target_board flags in RUNTESTFLAGS.  It turns
> out this does not work and what you want to do is use one target_board
> flag with a space seperated list of boardnames/options.
> 
> This patch changes the example to make that more clear.
> 
> OK to checkin?

Ok.  This sort of patch makes be nervous, I wonder if someone broke a feature 
along the way…

Make sure you review in a web browser to ensure it looks the way you want.

[testsuite] gcc.target/arm/unsigned-extend-1.c: omit -march option

[Janis Johnson]

Test gcc.target/arm/unsigned-extend-1.c specifies option -march=armv6,
which causes compile failures when that option conflicts with other
test flags, such as for multilibs.  It can also be overridden by other
test flags.  The test is scanning that instruction "uxtb" is not
issued.  Leaving off the option won't hurt when the effective target
doesn't support the instruction, and will allow the test to be tried
with other newer processors as well.

OK for trunk?

Janis
2012-09-26  Janis Johnson  

* gcc.target/arm/unsigned-extend-1.c: Omit -march option.

Index: gcc.target/arm/unsigned-extend-1.c
===
--- gcc.target/arm/unsigned-extend-1.c  (revision 191765)
+++ gcc.target/arm/unsigned-extend-1.c  (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -march=armv6" } */
+/* { dg-options "-O2" } */
 
 unsigned char foo (unsigned char c)
 {

[testsuite] gcc.target/arm/pr42879.c: handle big-endian

[Janis Johnson]

Test gcc.target/arm/pr42879.c fails for big-endian multilibs.  Julian
Brown suggested this fix.

Tested on arm-none-eabi with several multilibs, checked in on trunk.

Janis
2012-09-26  Janis Johnson  

* gcc.target/arm/pr42879.c: Handle big-endian.

Index: gcc.target/arm/pr42879.c
===
--- gcc.target/arm/pr42879.c(revision 191765)
+++ gcc.target/arm/pr42879.c(working copy)
@@ -4,6 +4,9 @@
 
 struct A
 {
+#ifdef __ARMEB__
+  int dummy:31;
+#endif
   int v:1;
 };
 

[testsuite] gcc.target/arm/combine-movs.c: fix effective target

[Janis Johnson]

Test gcc.target/arm/combine-movs.c uses the wrong effective-target
keyword on dg-final scans; arm_thumb2_ok says that the target will
support THUMB2 if -mthumb is specified, and arm_thumb2 says that
with the current options it is supported.

Tested on arm-none-eabi with multiple flags, checked in on trunk.

Janis
2012-09-26  Janis Johnson  

* gcc.target/arm/combine-movs.c: Use effective target arm_thumb2.

Index: gcc.target/arm/combine-movs.c
===
--- gcc.target/arm/combine-movs.c   (revision 191765)
+++ gcc.target/arm/combine-movs.c   (working copy)
@@ -9,5 +9,5 @@
 r[i] = 0;
 }
 
-/* { dg-final { scan-assembler "lsrs\tr\[0-9\]" { target arm_thumb2_ok } } } */
-/* { dg-final { scan-assembler "movs\tr\[0-9\]" { target { ! arm_thumb2_ok} } 
} } */
+/* { dg-final { scan-assembler "lsrs\tr\[0-9\]" { target arm_thumb2 } } } */
+/* { dg-final { scan-assembler "movs\tr\[0-9\]" { target { ! arm_thumb2 } } } 
} */

[testsuite] gcc.target/arm/mmx-2.c: specify -mcpu=iwmmxt

[Janis Johnson]

Test gcc.target/arm/mmx-2.c tests ARM iWMMXt functionality but fails to
compile if the compiler under test does not support that by default.
This patch adds -mcpu=iwmmxt.  Now instead of failing to compile due to
unrecognized builtins, it fails with the ICE described in PR54338.

Tested on arm-none-eabi for multiple flags, checked in on trunk.

Janis
2012-09-26  Janis Johnson  

* gcc.target/arm/mmx-2.c: Specify -mcpu=iwmmxt.

Index: gcc.target/arm/mmx-2.c
===
--- gcc.target/arm/mmx-2.c  (revision 191765)
+++ gcc.target/arm/mmx-2.c  (working copy)
@@ -5,7 +5,7 @@
 /* { dg-skip-if "Test is specific to ARM mode" { arm*-*-* } { "-mthumb" } { "" 
} } */
 /* { dg-require-effective-target arm32 } */
 /* { dg-require-effective-target arm_iwmmxt_ok } */
-/* { dg-options "-flax-vector-conversions -std=gnu99" } */
+/* { dg-options "-mcpu=iwmmxt -flax-vector-conversions -std=gnu99" } */
 
 /* Internal data types for implementing the intrinsics.  */
 typedef int __v2si __attribute__ ((vector_size (8)));

[testsuite] gcc.target/arm/div64-unwinding.c: xfail for linux

[Janis Johnson]

Test gcc.target/arm/div64-unwinding.c is known to fail for GNU/Linux 
targets, as described in PR54732.  This patch adds an XFAIL.

Tested on arm-none-eabi and arm-none-linux-gnueabi, checked in on trunk.

Janis
2012-09-26  Janis Johnson  

* gcc.target/arm/div64-unwinding.c: XFAIL for GNU/Linux.

Index: gcc.target/arm/div64-unwinding.c
===
--- gcc.target/arm/div64-unwinding.c(revision 191765)
+++ gcc.target/arm/div64-unwinding.c(working copy)
@@ -1,6 +1,7 @@
 /* Performing a 64-bit division should not pull in the unwinder.  */
 
-/* { dg-do run } */
+/* The test is expected to fail for GNU/Linux; see PR54723.  */
+/* { dg-do run { xfail *-*-linux* } } */
 /* { dg-options "-O0" } */
 
 #include 

[v3] libstdc++/53515

[Paolo Carlini]

Hi,

tested x86_64-linux, committed to mainline.

Paolo.

///
2012-09-26  Akira Takahashi  

PR libstdc++/53515
* include/bits/stl_iterator_base_funcs.h (__advance(_InputIterator&,
_Distance, input_iterator_tag)): Add _GLIBCXX_DEBUG_ASSERT(__n >= 0).
Index: include/bits/stl_iterator_base_funcs.h
===
--- include/bits/stl_iterator_base_funcs.h  (revision 191781)
+++ include/bits/stl_iterator_base_funcs.h  (working copy)
@@ -1,7 +1,6 @@
 // Functions used by iterators -*- C++ -*-
 
-// Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-// Free Software Foundation, Inc.
+// Copyright (C) 2001-2012 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -63,6 +62,7 @@
 #pragma GCC system_header
 
 #include 
+#include 
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -124,6 +124,7 @@
 {
   // concept requirements
   __glibcxx_function_requires(_InputIteratorConcept<_InputIterator>)
+  _GLIBCXX_DEBUG_ASSERT(__n >= 0);
   while (__n--)
++__i;
 }

[v3] libstdc++/54314

[Benjamin Kosnik]

adds in exports for more vtable bits, as per bugzilla

-benjamin 

tested x86/linux
tested x86/linux --enable-symvers=gnu-versioned-namespace012-09-26  Benjamin Kosnik  

   PR libstdc++/54314
   * config/abi/pre/gnu.ver: Add vtable exports.
   * config/abi/pre/gnu-versioned-namespace.ver: Same.



diff --git a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
index e7e9162..5f25374 100644
--- a/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
+++ b/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
@@ -27,20 +27,11 @@ GLIBCXX_7.0 {
 # Names inside the 'extern' block are demangled names.
 extern "C++"
 {
+  std::*;
   std::__7::*;
-  std::*
+  std::random_device::*
 };
 
-# locale
-_ZNSt3__79has_facetINS_*;
-
-# hash 
-_ZNSt8__detail3__712__prime_listE;
-_ZNSt3tr18__detail3__712__prime_listE;
-
-# thread/mutex/condition_variable/future
-__once_proxy;
-
 # operator new(size_t)
 _Znw[jmy];
 # operator new(size_t, std::nothrow_t const&)
@@ -64,13 +55,33 @@ GLIBCXX_7.0 {
 # function-scope static objects requires a guard variable.
 _ZGVNSt*;
 
-_ZTT*;
-_ZTV*;
+# construction vtable
+_ZTCNSt*;
 
-_ZTI*;
-_ZTS*;
+# VTT structure
+_ZTTNSt*;
 
-_ZTv0_n*;
+# vtable
+_ZTVNSt*;
+
+# thunk
+_ZTv0_n24_NS*;
+
+# typeinfo structure
+_ZTINSt*;
+
+# typeinfo name
+_ZTSNSt*;
+
+# locale
+_ZNSt3__79has_facetINS_*;
+
+# hash 
+_ZNSt8__detail3__712__prime_listE;
+_ZNSt3tr18__detail3__712__prime_listE;
+
+# thread/mutex/condition_variable/future
+__once_proxy;
 
 # std::__detail::_List_node_base
 _ZNSt8__detail3__715_List_node_base7_M_hook*;
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index 5265b21..396feec 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1322,6 +1322,7 @@ GLIBCXX_3.4.17 {
 } GLIBCXX_3.4.16;
 
 GLIBCXX_3.4.18 {
+
   global:
 
 # Names inside the 'extern' block are demangled names.
@@ -1330,6 +1331,9 @@ GLIBCXX_3.4.18 {
   std::random_device::*;
 };
 
+# construction vtable
+_ZTCSt*;
+
 } GLIBCXX_3.4.17;
 
 # Symbols in the support library (libsupc++) have their own tag.

[v3] Add missing include checks to ext/random

[Paolo Carlini]

Hi,

tested x86_64-linux, committed.

Thanks,
Paolo.

/
2012-09-26  Paolo Carlini  

* include/ext/random: Add include checks for c++11 and .
Index: include/ext/random
===
--- include/ext/random  (revision 191781)
+++ include/ext/random  (working copy)
@@ -31,12 +31,17 @@
 
 #pragma GCC system_header
 
+#ifndef __GXX_EXPERIMENTAL_CXX0X__
+# include 
+#else
+
 #include 
 #include 
 #ifdef __SSE2__
 # include 
 #endif
 
+#ifdef _GLIBCXX_USE_C99_STDINT_TR1
 
 namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
 {
@@ -1846,4 +1851,8 @@
 #include "opt_random.h"
 #include "random.tcc"
 
-#endif /* _EXT_RANDOM */
+#endif // _GLIBCXX_USE_C99_STDINT_TR1
+
+#endif // __GXX_EXPERIMENTAL_CXX0X__
+
+#endif // _EXT_RANDOM

Re: Ping: PATCH RFA: Print backtrace on ICE

[Ian Lance Taylor]

On Wed, Sep 26, 2012 at 1:52 PM, Dominique Dhumieres  wrote:
>
> It also breaks the building of the Ada tools:
>
> ...
> ../../xgcc -B../../  -I- -I../rts -I. -I/opt/gcc/work/gcc/ada -DIN_GCC  -g 
> -O2 -W -Wall  -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o 
> aspects.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o 
> debug.o elists.o einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o 
> fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o 
> i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o makeutl.o mlib.o mlib-fil.o 
> mlib-prj.o mlib-tgt.o mlib-tgt-specific.o mlib-utl.o namet.o nlists.o opt.o 
> osint.o osint-m.o output.o prj.o prj-attr.o prj-attr-pm.o prj-com.o 
> prj-dect.o prj-env.o prj-conf.o prj-pp.o prj-err.o prj-ext.o prj-nmsc.o 
> prj-pars.o prj-part.o prj-proc.o prj-strt.o prj-tree.o prj-util.o restrict.o 
> rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o scans.o scng.o 
> sdefault.o sfn_scan.o s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o 
> sinput.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o 
> system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o 
> types.o uintp.o uname.o urealp.o usage.o widechar.o  \
> targext.o link.o ../../ggc-none.o 
> ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a 
> ../rts/libgnat.a ../../../intl/libintl.a -liconv  
> ../../../libiberty/libiberty.a
> Undefined symbols:
>   "_backtrace_full", referenced from:
>   diagnostic_action_after_output(diagnostic_context*, diagnostic_info*) 
> [clone .isra.3] in libcommon.a(diagnostic.o)
>   "_backtrace_create_state", referenced from:
>   diagnostic_action_after_output(diagnostic_context*, diagnostic_info*) 
> [clone .isra.3] in libcommon.a(diagnostic.o)
> ld: symbol(s) not found
> collect2: error: ld returned 1 exit status
> make[3]: *** [../../gnatmake] Error 1
> make[3]: *** Waiting for unfinished jobs
> make[2]: *** [gnattools-native] Error 2
> make[1]: *** [all-gnattools] Error 2
> make: *** [all] Error 2
>
> and so on at stage 3; I worked around the problem by adding
> ../../../libbacktrace/.libs/libbacktrace.a to TOOLS_LIBS in
> gcc/ada/gcc-interface/Makefile (yes, I know this is not the right fix;-)

Fixed like so.  Committed to mainline as obvious.

Thanks for reporting the problem, and sorry about the breakage.

Ian


2012-09-26  Ian Lance Taylor  

* gcc-interface/Makefile.in (LIBBACKTRACE): New variable.
(LIBS): Add $(LIBBACKTRACE).
(LIBDEPS): Add $(LIBBACKTRACE).
(TOOLS_LIBS): Add ../../../libbacktrace/.libs/libbacktrace.a.


foo.patch
Description: Binary data

Go patch committed: Better error message for missing comma

[Ian Lance Taylor]

This patch to the Go frontend gives a better error message for a missing
comma in a composite literal.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline and 4.7 branch.

Ian

diff -r f47f5449a663 go/parse.cc
--- a/go/parse.cc	Mon Sep 24 15:20:45 2012 -0700
+++ b/go/parse.cc	Wed Sep 26 22:21:36 2012 -0700
@@ -2723,7 +2723,11 @@
 	}
   else
 	{
-	  error_at(this->location(), "expected %<,%> or %<}%>");
+	  if (token->is_op(OPERATOR_SEMICOLON))
+	error_at(this->location(),
+		 "need trailing comma before newline in composite literal");
+	  else
+	error_at(this->location(), "expected %<,%> or %<}%>");
 
 	  this->gogo_->mark_locals_used();
 	  int depth = 0;