[avr,committed] Make 1-byte loads from MEMX one byte shorted.

[Georg-Johann Lay]

http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=201121

Applied this obvious improvement of the sequence to load one byte from address
space memx (provided no ELPM is need).

The old sequence was

SBRC msb
LD   reg, Z  ; read from RAM
SBRS msp
LPM  reg, Z  ; read from flash

and the new one is

LPM  reg, Z  ; read from flash
SBRC msb
LD   reg, Z  ; read from RAM

This is legal because LPM never causes side effects.

Johann

* config/avr/avr.c (avr_out_xload): No SBIS around LPM so that
instruction sequence is 1 byte shorter.

Index: config/avr/avr.c
===
--- config/avr/avr.c(revision 201119)
+++ config/avr/avr.c(working copy)
@@ -3079,14 +3079,10 @@ avr_out_xload (rtx insn ATTRIBUTE_UNUSED
   xop[2] = lpm_addr_reg_rtx;
   xop[3] = AVR_HAVE_LPMX ? op[0] : lpm_reg_rtx;

-  if (plen)
-*plen = 0;
+  avr_asm_len (AVR_HAVE_LPMX ? lpm %3,%a2 : lpm, xop, plen, -1);

   avr_asm_len (sbrc %1,7 CR_TAB
-   ld %3,%a2 CR_TAB
-   sbrs %1,7, xop, plen, 3);
-
-  avr_asm_len (AVR_HAVE_LPMX ? lpm %3,%a2 : lpm, xop, plen, 1);
+   ld %3,%a2, xop, plen, 2);

   if (REGNO (xop[0]) != REGNO (xop[3]))
 avr_asm_len (mov %0,%3, xop, plen, 1);

Re: [PATCH] Fix pr57637

[Zhenqiang Chen]

On 22 July 2013 17:56, Eric Botcazou ebotca...@adacore.com wrote:
 The patch is updated based the comments: it will check GEN set of LIVE
 if df_live exists. Otherwise, just give up.

 The patch is missing a ChangeLog.  Otherwise it looks good, modulo:

 + /* DF_LR_BB_INFO (bb)-def does not kill the DF_REF_PARTIAL and
 +DF_REF_CONDITIONAL defs.  So if DF_LIVE doesn't exist, i.e.

 does not comprise

 + at -O1, just give up to search NEXT_BLOCK

 just give up searching

Updated.

 I'm not sure this matters in practice, but don't we need to set the 
 appropriate
 bit in the GEN set of BB at the end of the function if df_live is non-zero, at
 least for the sake of consistency?

And if df_live is non-zero, do we need update df_lr's IN and OUT? I think we
need another patch to make all these consistency.

 And a testcase is included in the attached patch.

 Thanks.  We generally try to make the testcases self-contained, i.e. remove 
 the
 #include's as much as possible.  It seems that stdlib.h is included for abort;
 if so, remove it and use __builtin_abort instead.  Would it be possible to
 remove stdio.h as well?

Update abort to __builtin_abort and malloc to __builtin_malloc. And
remove all the include.

ChangeLog
2013-07-22  Zhenqiang Chen  zhenqiang.c...@linaro.org

* function.c (move_insn_for_shrink_wrap): check gen of df_live if it
exists, otherwise (-O1) give up searching.

gcc/testsuite/ChangeLog
2013-07-22  Zhenqiang Chen  zhenqiang.c...@linaro.org

* gcc.target/arm/pr57637.c: New added.

Is it OK?

Thanks!
-Zhenqiang


pr57637-updated2.patch
Description: Binary data

[testsuite,committed] ad PR52641 skip more tests on int16

[Georg-Johann Lay]

http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=201123

Applied this skip for int16 platforms that will obviously fail there.

Johann

PR testsuite/52641
* gcc.c-torture/execute/pr57124.x: Skip int16 platforms.
* gcc.c-torture/execute/pr53366-1.x: New: Skip int16 platforms.

Index: gcc.c-torture/execute/pr57124.x
===
--- gcc.c-torture/execute/pr57124.x (revision 201119)
+++ gcc.c-torture/execute/pr57124.x (working copy)
@@ -1,2 +1,9 @@
+load_lib target-supports.exp
+
 set additional_flags -fno-strict-overflow
+
+if { [check_effective_target_int16] } {
+   return 1
+}
+
 return 0
Index: gcc.c-torture/execute/pr53366-1.x
===
--- gcc.c-torture/execute/pr53366-1.x   (revision 0)
+++ gcc.c-torture/execute/pr53366-1.x   (revision 0)
@@ -0,0 +1,7 @@
+load_lib target-supports.exp
+
+if { [check_effective_target_int16] } {
+   return 1
+}
+
+return 0

[ubsan] Add more testing

[Marek Polacek]

This adds more testing to the ubsan testsuite.  It still doesn't
test everything, but it's better than nothing and I've already found
one bug (already fixed).

Tested with RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}.
Commited to ubsan branch.

2013-07-22  Marek Polacek  pola...@redhat.com

* c-c++-common/ubsan/div-by-zero-3.c: Add more testing.
* c-c++-common/ubsan/div-by-zero-1.c: Likewise.
* c-c++-common/ubsan/shift-1.c: Likewise.
* c-c++-common/ubsan/shift-2.c: Likewise.
* c-c++-common/ubsan/div-by-zero-2.c: Likewise.

--- gcc/testsuite/c-c++-common/ubsan/div-by-zero-3.c.mp 2013-07-22 
13:41:13.375402476 +0200
+++ gcc/testsuite/c-c++-common/ubsan/div-by-zero-3.c2013-07-22 
13:41:45.031527627 +0200
@@ -6,7 +6,16 @@
 int
 main (void)
 {
+  volatile int min = INT_MIN;
+  volatile int zero = 0;
+
   INT_MIN / -1;
+  min / -1;
+  min / (10 * zero - (2 - 1));
+
   return 0;
 }
- /* { dg-output division of -2147483648 by -1 cannot be represented in type 
int } */
+
+/* { dg-output division of -2147483648 by -1 cannot be represented in type 
int(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*division of -2147483648 by -1 cannot be represented 
in type int(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*division of -2147483648 by -1 cannot be represented 
in type int(\n|\r\n|\r) } */
--- gcc/testsuite/c-c++-common/ubsan/div-by-zero-1.c.mp 2013-07-22 
13:41:13.370402454 +0200
+++ gcc/testsuite/c-c++-common/ubsan/div-by-zero-1.c2013-07-22 
13:41:45.030527622 +0200
@@ -4,7 +4,21 @@
 int
 main (void)
 {
+  volatile int a = 0;
+  volatile long long int b = 0;
+  volatile unsigned int c = 1;
+
+  a / b;
   0 / 0;
+  a / 0;
+  0 / b;
+  2 / --c;
+
   return 0;
 }
- /* { dg-output division by zero } */
+
+/* { dg-output division by zero(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*division by zero(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*division by zero(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*division by zero(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*division by zero(\n|\r\n|\r) } */
--- gcc/testsuite/c-c++-common/ubsan/shift-1.c.mp   2013-07-22 
13:41:13.377402486 +0200
+++ gcc/testsuite/c-c++-common/ubsan/shift-1.c  2013-07-22 13:41:45.032527632 
+0200
@@ -1,11 +1,31 @@
 /* { dg-do run } */
 /* { dg-options -fsanitize=shift -w } */
 
+typedef const unsigned long long int CULLI;
+typedef volatile int VI;
+struct s { signed long int a; };
+
 int
 main (void)
 {
   int a = 1;
+  struct s s = { .a = 400 };
+  CULLI culli = 42;
+  VI vi = 370;
+  volatile int shiftcount = 153;
+
   a = 152;
+  1  shiftcount;
+  1  154;
+  culli  524;
+  1  vi++;
+  (long) 1  (s.a + 2);
+
   return 0;
 }
-/* { dg-output shift exponent 152 is too large for \[^\n\r]*-bit type int } 
*/
+/* { dg-output shift exponent 152 is too large for \[^\n\r]*-bit type 
int(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*shift exponent 153 is too large for \[^\n\r]*-bit 
type int(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*shift exponent 154 is too large for \[^\n\r]*-bit 
type int(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*shift exponent 524 is too large for \[^\n\r]*-bit 
type long long unsigned int(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*shift exponent 370 is too large for \[^\n\r]*-bit 
type int(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*shift exponent 402 is too large for \[^\n\r]*-bit 
type long int(\n|\r\n|\r) } */
--- gcc/testsuite/c-c++-common/ubsan/shift-2.c.mp   2013-07-22 
13:41:13.378402491 +0200
+++ gcc/testsuite/c-c++-common/ubsan/shift-2.c  2013-07-22 13:41:45.033527637 
+0200
@@ -5,7 +5,19 @@ int
 main (void)
 {
   int a = 1;
-  a = -3;
+  volatile int b = -5;
+  long long int c = -6;
+
+  a  -3;
+  1  -4;
+  1  b;
+  a  c;
+  a  (b + c);
+
   return 0;
 }
-/* { dg-output shift exponent -3 is negative } */
+/* { dg-output shift exponent -3 is negative(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*shift exponent -4 is negative(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*shift exponent -5 is negative(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*shift exponent -6 is negative(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*shift exponent -11 is negative(\n|\r\n|\r) } */
--- gcc/testsuite/c-c++-common/ubsan/div-by-zero-2.c.mp 2013-07-22 
13:41:13.374402471 +0200
+++ gcc/testsuite/c-c++-common/ubsan/div-by-zero-2.c2013-07-22 
13:41:45.031527627 +0200
@@ -4,7 +4,20 @@
 int
 main (void)
 {
+  volatile const unsigned long int o = 1UL;
+  int zero = 0;
+
+  o / 0;
   1UL / 0;
+  1UL / zero;
+  o / zero;
+  o / (++zero - 1);
+
   return 0;
 }
- /* { dg-output division by zero } */
+
+/* { dg-output division by zero(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*division by zero(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*division by zero(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*division by zero(\n|\r\n|\r) } */
+/* { dg-output \[^\n\r]*division by zero(\n|\r\n|\r) } */

Marek

Re: [ARM][Insn classification refactoring 6/N] Delete insn attribute and update MOV classification

[Ramana Radhakrishnan]

On 07/22/13 10:52, Sofiane Naci wrote:

Oops sorry.

Patch attached now.



Ok

Thanks,
Ramana



-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Ramana Radhakrishnan
Sent: 22 July 2013 10:26
To: gcc-patches@gcc.gnu.org
Subject: Re: [ARM][Insn classification refactoring 6/N] Delete insn
attribute and update MOV classification

On 07/19/13 15:10, Sofiane Naci wrote:

Hi,

This patch is part of the ongoing work of ARM instruction

classification

cleanup.

This patch deletes the insn attribute and moves the MOV/MVN

instruction

classification to the type attribute, where it is split into

several types

for a finer-grained classification.

This has been tested with a full arm-none-eabi toolchain build and
regression run, as well as using random code generation tests to

compare the

output versus a baseline compiler.

OK for trunk?



ENOPATCH .

Ramana




Thanks
Sofiane

-

ChangeLog:

* config/arm/arm.md (attribute insn): Delete.
(attribute type): Add mov_imm, mov_reg, mov_shift,
mov_shift_reg, mvn_imm, mvn_reg, mvn_shift and
mvn_shift_reg.
(not_shiftsi): Update for attribute change.
(not_shiftsi_compare0): Likewise.
(not_shiftsi_compare0_scratch): Likewise.
(arm_one_cmplsi2): Likewise.
(thumb1_one_cmplsi2): Likewise.
(notsi_compare0): Likewise.
(notsi_compare0_scratch): Likewise.
(thumb1_movdi_insn): Likewise.
(arm_movsi_insn): Likewise.
(movhi_insn_arch4): Likewise.
(movhi_bytes): Likewise.
(arm_movqi_insn): Likewise.
(thumb1_movqi_insn): Likewise.
(arm32_movhf): Likewise.
(thumb1_movhf): Likewise.
(arm_movsf_soft_insn): Likewise.
(thumb1_movsf_insn): Likewise.
(thumb_movdf_insn): Likewise.
(movsicc_insn): Likewise.
(movsfcc_soft_insn): Likewise.
(and_scc): Likewise.
(cond_move): Likewise.
(if_move_not): Likewise.
(if_not_move): Likewise.
(if_shift_move): Likewise.
(if_move_shift): Likewise.
(if_shift_shift): Likewise.
(if_not_arith): Likewise.
(if_arith_not): Likewise.
(cond_move_not): Likewise.
* config/arm/neon.md (neon_movmode): Update for attribute

change.

(neon_movmode): Likewise.
* config/arm/vfp.md (arm_movsi_vfp): Update for attribute change.
(thumb2_movsi_vfp): Likewise.
(movsf_vfp): Likewise.
(thumb2_movsf_vfp): Likewise.
* config/arm/arm.c (xscale_sched_adjust_cost): Update for

attribute

change.
(cortexa7_older_only): Likewise.
(cortexa7_younger): Likewise.
* config/arm/arm1020e.md (1020alu_op): Update for attribute

change.

(1020alu_shift_op): Likewise.
(1020alu_shift_reg_op): Likewise.
* config/arm/arm1026ejs.md (alu_op): Update for attribute change.
(alu_shift_op): Likewise.
(alu_shift_reg_op): Likewise.
* config/arm/arm1136jfs.md (11_alu_op): Update for attribute

change.

(11_alu_shift_op): Likewise.
(11_alu_shift_reg_op): Likewise.
* config/arm/arm926ejs.md (9_alu_op): Update for attribute

change.

(9_alu_shift_reg_op): Likewise.
* config/arm/cortex-a15.md (cortex_a15_alu): Update for attribute
change.
(cortex_a15_alu_shift): Likewise.
(cortex_a15_alu_shift_reg): Likewise.
* config/arm/cortex-a5.md (cortex_a5_alu): Update for attribute
change.
(cortex_a5_alu_shift): Likewise.
* config/arm/cortex-a53.md (cortex_a53_alu): Update for attribute
change.
(cortex_a53_alu_shift): Likewise.
* config/arm/cortex-a7.md (cortex_a7_alu_imm): Update for

attribute

change.
(cortex_a7_alu_reg): Likewise.
(cortex_a7_alu_shift): Likewise.
* config/arm/cortex-a8.md (cortex_a8_alu): Update for attribute
change.
(cortex_a8_alu_shift): Likewise.
(cortex_a8_alu_shift_reg): Likewise.
(cortex_a8_mov): Likewise.
* config/arm/cortex-a9.md (cortex_a9_dp): Update for attribute
change.
(cortex_a9_dp_shift): Likewise.
* config/arm/cortex-m4.md (cortex_m4_alu): Update for attribute
change.
* config/arm/cortex-r4.md (cortex_r4_alu): Update for attribute
change.
(cortex_r4_mov): Likewise.
(cortex_r4_alu_shift): Likewise.
(cortex_r4_alu_shift_reg): Likewise.
* config/arm/fa526.md (526_alu_op): Update for attribute change.
(526_alu_shift_op): Likewise.
* config/arm/fa606te.md (606te_alu_op): Update for attribute

change.

* config/arm/fa626te.md (626te_alu_op): Update for attribute

change.

(626te_alu_shift_op): Likewise.
* config/arm/fa726te.md (726te_shift_op): Update for attribute
change.
(726te_alu_op): Likewise.
(726te_alu_shift_op): Likewise.
(726te_alu_shift_reg_op): Likewise.
  

[v3] libstdc++/57920

[Paolo Carlini]

Hi,

see audit trail for details. I tested on x86_64-linux (with/without 
_GLIBCXX_X86_RDRAND artificially undefined) the below straightforward 
patch and checked by hand the strace. I'm going to apply it soon.


Thanks,
Paolo.

///
2013-07-22  Paolo Carlini  paolo.carl...@oracle.com

PR c++/57920
* src/c++11/random.cc (random_device::_M_getval): If possible, use
read instead of std::fread.
* include/std/random: Do not include cstdio unnecessarily.
Index: include/std/random
===
--- include/std/random  (revision 201122)
+++ include/std/random  (working copy)
@@ -36,7 +36,6 @@
 #else
 
 #include cmath
-#include cstdio
 #include cstdlib
 #include string
 #include iosfwd
Index: src/c++11/random.cc
===
--- src/c++11/random.cc (revision 201122)
+++ src/c++11/random.cc (working copy)
@@ -30,7 +30,12 @@
 # include cpuid.h
 #endif
 
+#include cstdio
 
+#ifdef _GLIBCXX_HAVE_UNISTD_H
+# include unistd.h
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 
@@ -126,8 +131,12 @@
 #endif
 
 result_type __ret;
+#ifdef _GLIBCXX_HAVE_UNISTD_H
+read(fileno(_M_file), reinterpret_castvoid*(__ret), 
sizeof(result_type));
+#else
 std::fread(reinterpret_castvoid*(__ret), sizeof(result_type),
   1, _M_file);
+#endif
 return __ret;
   }
 

[Patch, Fortran, committed] Plug two memory leaks

[Tobias Burnus]

Found by Coverity. In the first case, error gets overridden if status 
is not NULL_TREE. The second case is rather obvious.


Committed as Rev. 201125 after built on x86-64-gnu-linux.

Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 201124)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2013-07-21  Tobias Burnus  bur...@net-b.de
+
+	* trans-array.c (gfc_array_allocate,
+	gfc_trans_deferred_array): Plug memory leak.
+
 2013-07-21   Ondřej Bílka  nel...@seznam.cz
 
 	* trans-decl.c: Fix comment typos.
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c	(Revision 201124)
+++ gcc/fortran/trans-array.c	(Arbeitskopie)
@@ -5209,7 +5209,7 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr,
 			  se-pre, set_descriptor_block, overflow,
 			  expr3_elem_size, nelems, expr3, ts);
 
-  if (dimension)
+  if (status == NULL_TREE  dimension)
 {
 
   var_overflow = gfc_create_var (integer_type_node, overflow);
@@ -5223,8 +5223,7 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr,
   error = build_call_expr_loc (input_location, gfor_fndecl_runtime_error,
    1, msg);
 }
-
-  if (status != NULL_TREE)
+  else if (status != NULL_TREE)
 {
   tree status_type = TREE_TYPE (status);
   stmtblock_t set_status_block;
@@ -8525,10 +8524,12 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wr
!sym-attr.save  !sym-attr.result
!sym-ns-proc_name-attr.is_main_program)
 {
+  gfc_expr *e;
+  e = has_finalizer ? gfc_lval_expr_from_sym (sym) : NULL;
   tmp = gfc_trans_dealloc_allocated (sym-backend_decl,
-	 sym-attr.codimension,
-	 has_finalizer
-	 ? gfc_lval_expr_from_sym (sym) : NULL);
+	 sym-attr.codimension, e);
+  if (e)
+	gfc_free_expr (e);
   gfc_add_expr_to_block (cleanup, tmp);
 }
 

Re: RFC: Gimple combine/folding interface

[Florian Weimer]

On 07/20/2013 02:09 AM, Andrew Pinski wrote:

   gimple_combine(bool reas) : nonzerobitsf(NULL), valueizerv(NULL),
allow_full_reassiocation(reas) {}


I think this constructor should be marked explicit.

--
Florian Weimer / Red Hat Product Security Team

Re: [PATCH] Fix pr57637

[Eric Botcazou]

 And if df_live is non-zero, do we need update df_lr's IN and OUT? I think
 we need another patch to make all these consistency.

Possibly, but this would belong to another patch.  I nevertheless think that we 
should set the bit in the GEN set because we'll be testing the GEN set now.

The patch is OK with this change if it passes the usual testing.

 ChangeLog
 2013-07-22  Zhenqiang Chen  zhenqiang.c...@linaro.org
 
 * function.c (move_insn_for_shrink_wrap): check gen of df_live if
 it exists, otherwise (-O1) give up searching.

Capital letter at the beginning, and I'd expand a little on it, something like:

* function.c (move_insn_for_shrink_wrap): Also check the GEN set of the
LIVE problem for the liveness analysis if it exists, otherwise give up.

 gcc/testsuite/ChangeLog
 2013-07-22  Zhenqiang Chen  zhenqiang.c...@linaro.org
 
 * gcc.target/arm/pr57637.c: New added.

New testcase

-- 
Eric Botcazou

[google] Fix target specifier for testsuite/g++.dg/pr57878.C

[Diego Novillo]

This test was failing with -m64 because it was forcing -m32
instead of asking for ilp32.

Committed to google/gcc-4_8 and trunk.


Diego.

Index: gcc/testsuite/g++.dg/pr57878.C
===
--- gcc/testsuite/g++.dg/pr57878.C  (revision 201124)
+++ gcc/testsuite/g++.dg/pr57878.C  (working copy)
@@ -1,5 +1,5 @@
-/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
-/* { dg-options -m32 -O2 -fno-omit-frame-pointer -fPIC -std=gnu++11 } */
+/* { dg-do compile { target { { i?86-*-* x86_64-*-* }  ilp32 } } } */
+/* { dg-options -O2 -fno-omit-frame-pointer -fPIC -std=gnu++11 } */

 typedef int int32;
 typedef long long int64;

libbacktrace: walk the elf_syminfo_data chain in elf_syminfo

[Alexander Monakov]

Hello,

this fixes a bug (found by inspection) that would prevent elf_syminfo from
looking up symbols defined in modules other than the executable.

Bootstrapped and regtested together with the next patch on x86_64-linux
(excluding Java, including Go), OK for trunk?

libbacktrace/Changelog:
2013-07-22  Alexander Monakov  amona...@ispras.ru

* elf.c (elf_syminfo): Loop over the elf_syminfo_data chain.

diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index ef9bcdf..a90afaa 100644
--- a/libbacktrace/elf.c
+++ b/libbacktrace/elf.c
@@ -454,12 +454,15 @@ elf_syminfo (struct backtrace_state *state, uintptr_t pc,
 void *data)
 {
   struct elf_syminfo_data *edata;
-  struct elf_symbol *sym;
+  struct elf_symbol *sym = NULL;
+
+  for (edata = (struct elf_syminfo_data *) state-syminfo_data;
+   edata  sym == NULL;
+   edata = edata-next)
+sym = ((struct elf_symbol *)
+  bsearch (pc, edata-symbols, edata-count,
+   sizeof (struct elf_symbol), elf_symbol_search));
 
-  edata = (struct elf_syminfo_data *) state-syminfo_data;
-  sym = ((struct elf_symbol *)
-bsearch (pc, edata-symbols, edata-count,
- sizeof (struct elf_symbol), elf_symbol_search));
   if (sym == NULL)
 callback (data, pc, NULL, 0);
   else

[PATCH] Don't include gimple.h twice

[Marek Polacek]

I don't think there's a reason to include gimple.h twice...
Regtested/bootstrapped on x86_64-linux, will commit as obvious soon.

2013-07-22  Marek Polacek  pola...@redhat.com

* gimplify.c: Don't include gimple.h twice.

--- gcc/gimplify.c.mp   2013-07-22 15:29:17.202468003 +0200
+++ gcc/gimplify.c  2013-07-22 15:29:25.891502560 +0200
@@ -42,7 +42,6 @@ along with GCC; see the file COPYING3.
 #include pointer-set.h
 #include splay-tree.h
 #include vec.h
-#include gimple.h
 
 #include langhooks-def.h /* FIXME: for lhd_set_decl_assembler_name */
 #include tree-pass.h /* FIXME: only for PROP_gimple_any */

Marek

Re: [Patch, Fortran, committed] Plug two memory leaks

[Tobias Burnus]

Tobias Burnus wrote:
Found by Coverity. In the first case, error gets overridden if 
status is not NULL_TREE. The second case is rather obvious.


I managed to commit an early draft of the patch - I meant to apply the 
one attached (relative diff) instead.


Committed follow-up fix as Rev. 201129  after building and regtesting on 
x86-64-gnu-linux.


Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 201125)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,9 @@
 2013-07-22  Tobias Burnus  bur...@net-b.de
 
+	* trans-array.c (gfc_array_allocate): Correct memory-leak patch.
+
+2013-07-22  Tobias Burnus  bur...@net-b.de
+
 	* trans-array.c (gfc_array_allocate,
 	gfc_trans_deferred_array): Plug memory leak.
 
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c	(Revision 201125)
+++ gcc/fortran/trans-array.c	(Arbeitskopie)
@@ -5209,29 +5209,31 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr,
 			  se-pre, set_descriptor_block, overflow,
 			  expr3_elem_size, nelems, expr3, ts);
 
-  if (status == NULL_TREE  dimension)
+  if (dimension)
 {
-
   var_overflow = gfc_create_var (integer_type_node, overflow);
   gfc_add_modify (se-pre, var_overflow, overflow);
 
-  /* Generate the block of code handling overflow.  */
-  msg = gfc_build_addr_expr (pchar_type_node,
-		gfc_build_localized_cstring_const
+  if (status == NULL_TREE)
+	{
+	  /* Generate the block of code handling overflow.  */
+	  msg = gfc_build_addr_expr (pchar_type_node,
+		gfc_build_localized_cstring_const
   			(Integer overflow when calculating the amount of 
   			 memory to allocate));
-  error = build_call_expr_loc (input_location, gfor_fndecl_runtime_error,
-   1, msg);
-}
-  else if (status != NULL_TREE)
-{
-  tree status_type = TREE_TYPE (status);
-  stmtblock_t set_status_block;
+	  error = build_call_expr_loc (input_location,
+   gfor_fndecl_runtime_error, 1, msg);
+	}
+  else
+	{
+	  tree status_type = TREE_TYPE (status);
+	  stmtblock_t set_status_block;
 
-  gfc_start_block (set_status_block);
-  gfc_add_modify (set_status_block, status,
-		  build_int_cst (status_type, LIBERROR_ALLOCATION));
-  error = gfc_finish_block (set_status_block);
+	  gfc_start_block (set_status_block);
+	  gfc_add_modify (set_status_block, status,
+			  build_int_cst (status_type, LIBERROR_ALLOCATION));
+	  error = gfc_finish_block (set_status_block);
+	}
 }
 
   gfc_start_block (elseblock);

libbacktrace: allow using DWARF if the main executable lacks it

[Alexander Monakov]

This fixes a bug that would prevent using DWARF debug info available in
dynamically linked libraries when the main executable did not have DWARF debug
info.

pd.fileline_fn is not examined after dl_iterate_phdr in backtrace_initialize,
so updating *fileline_fn in dl_iterate_phdr is useless as later it is
overwritten from elf_fileline_fn.  OK for trunk?

2013-07-22  Alexander Monakov  amona...@ispras.ru

* elf.c (backtrace_initialize): Pass elf_fileline_fn to
dl_iterate_phdr callbacks.

diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index a90afaa..fde884a 100644
--- a/libbacktrace/elf.c
+++ b/libbacktrace/elf.c
@@ -865,7 +865,7 @@ backtrace_initialize (struct backtrace_state *state, int 
descriptor,
   pd.state = state;
   pd.error_callback = error_callback;
   pd.data = data;
-  pd.fileline_fn = fileline_fn;
+  pd.fileline_fn = elf_fileline_fn;
   pd.found_sym = found_sym;
   pd.found_dwarf = found_dwarf;
 

Re: Go patch committed: Update libgo to 1.1.1

[Uros Bizjak]

Hello!

 I have committed a large patch to update libgo to the library that was
 part of the Go 1.1.1 release.  As usual, I'm not including the entire
 patch in this e-mail message, because it is too large.  I'm only
 including the changes to the files that are partially gccgo-specific.
 Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
 Committed to mainline and 4.8 branch.

 I have hit following build failure on non-USING_SPLIT_STACK target
 (alpha-linux-gnu):

 Thanks.  Fixed like so.  Committed to mainline and 4.8 branch.

 Thanks, with your patch, I was able to compile libgo without problems.
 The testsuite run exposes a timeout in net/http, I am looking into it.

I have also managed to trigger the timeout on x86_64-pc-linux-gnu.

The test was re-run with GOTESTFLAGS=--keep. When running the
resulting a.out with strace -f -o strace-x86_64 ./a.out from the
saved test directory, the test behaved in the same way as on alpha -
it hever finished. I have attached the resulting trace (the test was
killed with ctrl-c after some time).

Uros.


strace-x86_64.bz2
Description: BZip2 compressed data

Re: [Patch, PR 57790] Waste work in can_move_insns_across()

[Jeff Law]

On 07/21/2013 07:45 PM, pcha...@cs.wisc.edu wrote:

Hi,

The problem appears in revision 201034 in version 4.9.  I attached a
one-line patch that fixes it.  I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57790

I bootstrapped and ran the regression tests for this patch on x86_64-linux
and all tests pass.

In method can_move_insns_across() in df-problems.c, the loop on line
4038 should break immediately after fail is set to 1. All the iterations
after fail set to 1 do not perform any useful work, at best they just
set fail again to 1.

Thanks.  I'll install shortly.

In the future if you could also include a ChangeLog entry it would be 
appreciated.  It's format is pretty simple.  Here's the one I'll use for 
this change:


2013-07-22  Chang  pcha...@cs.wisc.edu

* df-problems.c (can_move_insns_across): Exit loop once we
find a non-fixed, non-global register.

Re: [ubsan] Add libcall arguments

[Jason Merrill]

On 07/19/2013 02:45 PM, Marek Polacek wrote:

 /* This type represents an entry in the hash table.  */
 struct ubsan_typedesc
 {
+  /* This represents the type of a variable.  */
   tree type;
+
+  /* This is the VAR_DECL of the type.  */
   tree decl;
 };


What I was looking for was something along the lines of this hash table 
maps from a TYPE to a ubsan type descriptor VAR_DECL for that type.


Jason

Re: [PATCH] Don't include gimple.h twice

[Jeff Law]

On 07/22/2013 07:31 AM, Marek Polacek wrote:

I don't think there's a reason to include gimple.h twice...
Regtested/bootstrapped on x86_64-linux, will commit as obvious soon.

2013-07-22  Marek Polacek  pola...@redhat.com

* gimplify.c: Don't include gimple.h twice.

OK.
jeff

Re: libbacktrace: walk the elf_syminfo_data chain in elf_syminfo

[Ian Lance Taylor]

On Mon, Jul 22, 2013 at 6:26 AM, Alexander Monakov amona...@ispras.ru wrote:

 this fixes a bug (found by inspection) that would prevent elf_syminfo from
 looking up symbols defined in modules other than the executable.

 Bootstrapped and regtested together with the next patch on x86_64-linux
 (excluding Java, including Go), OK for trunk?

 libbacktrace/Changelog:
 2013-07-22  Alexander Monakov  amona...@ispras.ru

 * elf.c (elf_syminfo): Loop over the elf_syminfo_data chain.

Thanks for noticing the problem.  This patch isn't enough by itself.
The code has to protect itself against the list changing in
mid-stream.  See dwarf_fileline in dwarf.c.

Ian

Re: libbacktrace: allow using DWARF if the main executable lacks it

[Ian Lance Taylor]

On Mon, Jul 22, 2013 at 6:34 AM, Alexander Monakov amona...@ispras.ru wrote:

 2013-07-22  Alexander Monakov  amona...@ispras.ru

 * elf.c (backtrace_initialize): Pass elf_fileline_fn to
 dl_iterate_phdr callbacks.

This is OK.

Thanks.

Ian

Re: [Patch, PR57803] Wasted work in gfc_build_dummy_array_decl()

[Jeff Law]

On 07/19/2013 04:59 PM, pcha...@cs.wisc.edu wrote:

Hi,

The problem appears in revision 201034 in version 4.9.  I attached a
one-line patch that fixes it.  I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57803

I bootstrapped and ran the regression tests for this patch on x86_64-linux
and all tests pass.

In method gfc_build_dummy_array_decl() in gcc/fortran/trans-decl.c,
the loop on line 978 should break immediately after packed is set to
PACKED_PARTIAL. All the iterations after packed set to
PACKED_PARTIAL do not perform any useful work, at best they just set
packed again to PACKED_PARTIAL.
Thanks.  I've installed the patches from all of your emails which 
address these issues.


I'm a bit curious, are you finding these by inspection of the sources or 
via some kind of analysis code?


Thanks again,
Jeff

[C++ testcase, committed] PR 52816

[Paolo Carlini]

Hi,

testcase committed to mainline.

Thanks,
Paolo.

///
2013-07-22  Paolo Carlini  paolo.carl...@oracle.com

PR c++/52816
* g++.dg/cpp0x/decltype56.C: New.
Index: g++.dg/cpp0x/decltype56.C
===
--- g++.dg/cpp0x/decltype56.C   (revision 0)
+++ g++.dg/cpp0x/decltype56.C   (working copy)
@@ -0,0 +1,11 @@
+// PR c++/52816
+// { dg-do compile { target c++11 } }
+
+class c {
+  int f;
+  public:
+  template typename A
+  decltype(f) m(A) const;
+};
+
+decltype(c{}.m(0)) i;

[Patch, PR 57811] Wasted work in find_reloads()

[pchang9]

Hi,

The problem appears in revision 201034 in version 4.9.  I attached
one-line patches that fixes it.  I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811

Bootstrap and regression-tested on x86_64-linux.

In method find_reloads() in gcc/reload.c, the loop on line 3324  should
break immediately after badop is set to 1. Also, the loop on line 4641
 should break after ok is set to 0.


2013-07-22  Chang  pcha...@cs.wisc.edu

* reload.c (find_reloads): Exit loop once we find this operand
  cannot be reloaded somehow for this alternative.

* reload.c (find_reloads): Exit loop once we find a
  hard register.



Index: gcc/reload.c
===
--- gcc/reload.c(revision 201034)
+++ gcc/reload.c(working copy)
@@ -3324,7 +3324,10 @@
  for (j = 0; j  i; j++)
if (this_alternative_matches[j]
== this_alternative_matches[i])
- badop = 1;
+ {
+   badop = 1;
+   break;
+ }
break;

  case 'p':
Index: gcc/reload.c
===
--- gcc/reload.c(revision 201034)
+++ gcc/reload.c(working copy)
@@ -4640,7 +4640,10 @@

for (nri = 1; nri  nr; nri ++)
  if (! TEST_HARD_REG_BIT (reg_class_contents[rld[i].rclass], regno
+ nri))
-   ok = 0;
+   {
+ ok = 0;
+ break;
+   }

if (ok)
  rld[i].reg_rtx = dest;

-Chang
Index: gcc/reload.c
===
--- gcc/reload.c(revision 201034)
+++ gcc/reload.c(working copy)
@@ -3324,7 +3324,10 @@
  for (j = 0; j  i; j++)
if (this_alternative_matches[j]
== this_alternative_matches[i])
- badop = 1;
+ {
+   badop = 1;
+   break;
+ }
break;
 
  case 'p':Index: gcc/reload.c
===
--- gcc/reload.c(revision 201034)
+++ gcc/reload.c(working copy)
@@ -4640,7 +4640,10 @@
 
for (nri = 1; nri  nr; nri ++)
  if (! TEST_HARD_REG_BIT (reg_class_contents[rld[i].rclass], regno 
+ nri))
-   ok = 0;
+   {
+ ok = 0;
+ break;
+   }
 
if (ok)
  rld[i].reg_rtx = dest;

[Patch, PR 57812] Wasted work in computed_jump_p()

[pchang9]

Hi,

The problem appears in revision 201034 in version 4.9. I also reported
this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57812.

Bootstrap and regression-tested on x86_64-linux.

In method computed_jump_p() in gcc/rtlanal.c, the loop on line 2801
should break immediately after has_use_labelref is set to 1.


2013-07-22  Chang  pcha...@cs.wisc.edu

* rtlanal.c (computed_jump_p): Exit loop once we find label
  reference is used.

Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c   (revision 201034)
+++ gcc/rtlanal.c   (working copy)
@@ -2802,7 +2802,10 @@
if (GET_CODE (XVECEXP (pat, 0, i)) == USE
 (GET_CODE (XEXP (XVECEXP (pat, 0, i), 0))
== LABEL_REF))
- has_use_labelref = 1;
+ {
+   has_use_labelref = 1;
+   break;
+ }

  if (! has_use_labelref)
for (i = len - 1; i = 0; i--)


-Chang
Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c   (revision 201034)
+++ gcc/rtlanal.c   (working copy)
@@ -2802,7 +2802,10 @@
if (GET_CODE (XVECEXP (pat, 0, i)) == USE
 (GET_CODE (XEXP (XVECEXP (pat, 0, i), 0))
== LABEL_REF))
- has_use_labelref = 1;
+ {
+   has_use_labelref = 1;
+   break;
+ }
 
  if (! has_use_labelref)
for (i = len - 1; i = 0; i--)

Re: [Patch, PR 57811] Wasted work in find_reloads()

[Marek Polacek]

On Mon, Jul 22, 2013 at 11:39:38AM -0500, pcha...@cs.wisc.edu wrote:
 Hi,
 
 The problem appears in revision 201034 in version 4.9.  I attached
 one-line patches that fixes it.  I also reported this problem
 at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811
 
 Bootstrap and regression-tested on x86_64-linux.
 
 In method find_reloads() in gcc/reload.c, the loop on line 3324  should
 break immediately after badop is set to 1. Also, the loop on line 4641
  should break after ok is set to 0.
 
 
 2013-07-22  Chang  pcha...@cs.wisc.edu
 
 * reload.c (find_reloads): Exit loop once we find this operand
   cannot be reloaded somehow for this alternative.
 
 * reload.c (find_reloads): Exit loop once we find a
   hard register.

Perhaps just

2013-07-22  Chang  pcha...@cs.wisc.edu

* reload.c (find_reloads): Exit loop after setting badop.
Exit loop after setting ok.

Otherwise looks ok, just note that your MTA mangled the second patch.

Marek

[Patch, Fortran, committed] PR57762 - Fix memleak in gfortran.dg/class_array_7.f03

[Tobias Burnus]

That's a patch of the category: Make the testers happy (here: Dominque).

gfortran (in GCC 4.9) no longer frees allocatable at the end of the main 
program as they get implicitly the SAVE attribute (cf. Fortran 2008) - 
and that's now detectable due to finalizers.


Result: gfortran.dg/class_array_7.f03 now leaks memory, which clutters 
the valgrind output of the test suite. As the test itself is agnostic to 
a tailing deallocate, I added one.


Committed as Rev. 201137.

Tobias
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 201136)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2013-07-22  Tobias Burnus  bur...@net-b.de
+
+	PR fortran/57762
+	* gfortran.dg/class_array_7.f03: Fix memory leak.
+
 2013-07-22  Paolo Carlini  paolo.carl...@oracle.com
 
 	PR c++/52816
Index: gcc/testsuite/gfortran.dg/class_array_7.f03
===
--- gcc/testsuite/gfortran.dg/class_array_7.f03	(Revision 201136)
+++ gcc/testsuite/gfortran.dg/class_array_7.f03	(Arbeitskopie)
@@ -54,4 +54,5 @@ program main
   if (trim (print_type (a, a)) .ne. a is extended_type) call abort
   call reallocate (a)
   if (trim (print_type (a, a)) .ne. a is base_type) call abort
+  deallocate (a)
 end program main
module VEC_REAL_MODULE
contains
   pure function VEC_REAL_norm(self) result(res)
 real, dimension(:), intent(in) :: self
 res = self(1)
   end function
   function MAT_REAL_row_norms(self) result(res)
  real, dimension(:,:) :: self
  real, dimension(size(self,1)) :: res
  do i = 1,size(self,1)
 res(i) = VEC_REAL_norm(self(i,:))
  end do
   end function
   pure subroutine MAT_REAL_zero_small_values(self,eps)
   real(8), dimension(:,:) :: self
  intent(inout) :: self
  real(8), intent(in) :: eps
  where (abs(self)eps)
  end where
   end subroutine
end module

[PATCH][4.8 backport] Fix PR57735

[Kyrylo Tkachov]

Hi all,

The fix for PR57735 is in current trunk (for a different issue I think), just
needs a backport to 4.8.
It is r198462 by Richard Sandiford:

2013-04-30 Richard Sandiford rsand...@linux.vnet.ibm.com

* explow.c (plus_constant): Pass mode to immed_double_int_const.
Use gen_int_mode rather than GEN_INT.

Ok to backport to the 4.8 branch?

I've attached the testcase that exposed the ICE. I think the ChangeLog would
look like this:


2013-07-22  Kyrylo Tkachov  kyrylo.tkac...@arm.com

PR target/57735
Backport from mainline
2013-04-30  Richard Sandiford  rsand...@linux.vnet.ibm.com

* explow.c (plus_constant): Pass mode to
immed_double_int_const.
Use gen_int_mode rather than GEN_INT.

2013-07-22  Kyrylo Tkachov  kyrylo.tkac...@arm.com

PR target/57735
* g++.dg/ext/pr57735.C: New test.



Thanks,
Kyrill

pr57735-test.patch
Description: Binary data

Re: [ubsan] Add libcall arguments

[Marek Polacek]

On Mon, Jul 22, 2013 at 10:09:00AM -0400, Jason Merrill wrote:
 On 07/19/2013 02:45 PM, Marek Polacek wrote:
  /* This type represents an entry in the hash table.  */
  struct ubsan_typedesc
  {
 +  /* This represents the type of a variable.  */
tree type;
 +
 +  /* This is the VAR_DECL of the type.  */
tree decl;
  };
 
 What I was looking for was something along the lines of this hash
 table maps from a TYPE to a ubsan type descriptor VAR_DECL for that
 type.

Ah.  Hopefully it's ok this time around; I already commited previous
patch, thus this patchlet.

2013-07-22  Marek Polacek  pola...@redhat.com

* ubsan.c (struct ubsan_typedesc): Improve comment.

--- gcc/ubsan.c.mp  2013-07-22 16:14:16.266199381 +0200
+++ gcc/ubsan.c 2013-07-22 16:19:48.335517383 +0200
@@ -31,7 +31,8 @@ along with GCC; see the file COPYING3.
 #include ubsan.h
 #include c-family/c-common.h
 
-/* This type represents an entry in the hash table.  */
+/* This type represents an entry in the hash table; this hash table
+   maps from a TYPE to a ubsan type descriptor VAR_DECL for that type.  */
 struct ubsan_typedesc
 {
   /* This represents the type of a variable.  */

Marek

[PATCH, PowerPC] rs6000_expand_vector_init selects wrong field for splat in LE mode

[Bill Schmidt]

In little-endian mode, the field selected for use in a vector splat is
numbered differently than in big-endian mode.  This patch corrects the
code generated for little-endian.  This addresses 45 test failures when
running the test-suite in little-endian mode.

Bootstrapped and tested on powerpc64-unknown-linux-gnu with no new
regressions.  Ok for trunk?

Patch by Anton Blanchard.

Thanks,
Bill


2013-07-22  Bill Schmidt  wschm...@vnet.linux.ibm.com
for Anton Blanchard an...@au1.ibm.com

* config/rs6000/rs6000.c (rs6000_expand_vector_init): Fix
endianness when selecting field to splat.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 201131)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5177,6 +5177,7 @@ rs6000_expand_vector_init (rtx target, rtx vals)
  of 64-bit items is not supported on Altivec.  */
   if (all_same  GET_MODE_SIZE (inner_mode) = 4)
 {
+  rtx field;
   mem = assign_stack_temp (mode, GET_MODE_SIZE (inner_mode));
   emit_move_insn (adjust_address_nv (mem, inner_mode, 0),
  XVECEXP (vals, 0, 0));
@@ -5187,9 +5188,11 @@ rs6000_expand_vector_init (rtx target, rtx vals)
  gen_rtx_SET (VOIDmode,
   target, mem),
  x)));
+  field = (BYTES_BIG_ENDIAN ? const0_rtx
+  : GEN_INT (GET_MODE_NUNITS (mode) - 1));
   x = gen_rtx_VEC_SELECT (inner_mode, target,
  gen_rtx_PARALLEL (VOIDmode,
-   gen_rtvec (1, const0_rtx)));
+   gen_rtvec (1, field)));
   emit_insn (gen_rtx_SET (VOIDmode, target,
  gen_rtx_VEC_DUPLICATE (mode, x)));
   return;

Re: [PATCH 1/*] Fix common typos.

[Mike Stump]

On Jul 21, 2013, at 2:21 PM, Joseph S. Myers jos...@codesourcery.com wrote:
 On Sun, 21 Jul 2013, Mike Stump wrote:
 
 -   /* Now we have to go throught the whole table
 +   /* Now we have to go thought the whole table
 
 Again, throught - through.
 
 Fixed.
 
 Again, the checked-in change is incorrect (though).

Fixed.

Index: libiberty/regex.c
===
--- libiberty/regex.c   (revision 201138)
+++ libiberty/regex.c   (revision 201139)
@@ -3396,7 +3396,7 @@ PREFIX(regex_compile) (const char *ARG_P
   class.  */
PATFETCH (c);
 
-   /* Now we have to go though the whole table
+   /* Now we have to go through the whole table
   and find all characters which have the same
   first level weight.
 

Re: [PATCH 1/*] Fix common typos.

[Mike Stump]

On Jul 21, 2013, at 2:18 PM, Joseph S. Myers jos...@codesourcery.com wrote:
 On Sun, 21 Jul 2013, Mike Stump wrote:
 
 diff --git a/gcc/testsuite/c-c++-common/pr41779.c 
 b/gcc/testsuite/c-c++-common/pr41779.c
 index 80c8e6b..f80412c 100644
 --- a/gcc/testsuite/c-c++-common/pr41779.c
 +++ b/gcc/testsuite/c-c++-common/pr41779.c
 @@ -1,4 +1,4 @@
 -/* PR41779: Wconversion cannot see throught real*integer promotions. */
 +/* PR41779: Wconversion cannot see thought real*integer promotions. */
 
 This change is not ok (eh, OK), it should've been through.
 
 The checked-in version of this file is still wrong, it now has though 
 which should be through.

Fixed, thanks.

Re: [Patch, Fortran] PR57906 - fix issue with coarray component assignment

[Steve Kargl]

On Mon, Jul 22, 2013 at 07:17:50PM +0200, Tobias Burnus wrote:
 For coarrays, an assignment does not affect the allocation status. That 
 also implies that the type parameters, shape and effective types between 
 the LHS and RHS have to match.
 
 For coarrays components, that's handled (since Rev. 200955) by 
 re-assigning the saved data after the assignment:
 
   tmp  = LHS;
   LHS = RHS;
   LHS.caf = RHS.caf;
 
 However, as the PR shows, the middle end for some reasons optimizes the 
 latter assignment away. My impression is that that's due to the 
 restrict issue (PR45586). The patch now only assigns the data 
 component, which seems to work:
 
   tmp  = LHS;
   LHS = RHS;
   LHS.caf.data = RHS.caf.data;
 
 Other changes:
 - Change space+tab to tab
 - Add a test case, which I seemingly forgot to include in r200955
 
 Build and regtested on x86-64-gnu-linux.
 OK for the trunk?
 

OK.

-- 
Steve

[Patch, Fortran] PR57906 - fix issue with coarray component assignment

[Tobias Burnus]

For coarrays, an assignment does not affect the allocation status. That 
also implies that the type parameters, shape and effective types between 
the LHS and RHS have to match.


For coarrays components, that's handled (since Rev. 200955) by 
re-assigning the saved data after the assignment:


 tmp  = LHS;
 LHS = RHS;
 LHS.caf = RHS.caf;

However, as the PR shows, the middle end for some reasons optimizes the 
latter assignment away. My impression is that that's due to the 
restrict issue (PR45586). The patch now only assigns the data 
component, which seems to work:


 tmp  = LHS;
 LHS = RHS;
 LHS.caf.data = RHS.caf.data;

Other changes:
- Change space+tab to tab
- Add a test case, which I seemingly forgot to include in r200955


Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias
2013-07-22  Tobias Burnus  bur...@net-b.de

	PR fortran/57906
	PR fortran/52052
	* class.c (gfc_build_class_symbol): Set coarray_comp.
	* trans-array.c (structure_alloc_comps): For coarrays,
	directly use the data pointer address.

2013-07-22  Tobias Burnus  bur...@net-b.de

	PR fortran/57906
	PR fortran/52052
	* coarray/lib_realloc_1.f90: Permit optimization.
	* gfortran.dg/coarray_31.f90: New.

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index ba8efa9..51bfd56 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -666,6 +666,7 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
 
   fclass-attr.extension = ts-u.derived-attr.extension + 1;
   fclass-attr.alloc_comp = ts-u.derived-attr.alloc_comp;
+  fclass-attr.coarray_comp = ts-u.derived-attr.coarray_comp;
 }
 
   fclass-attr.is_class = 1;
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 3fdd8d9..0aac678 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7589,9 +7589,9 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
 
 	  if ((c-ts.type == BT_DERIVED  !c-attr.pointer)
 	  || (c-ts.type == BT_CLASS  !CLASS_DATA (c)-attr.class_pointer))
- 	{
- 	  comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
-   decl, cdecl, NULL_TREE);
+	{
+	  comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
+  decl, cdecl, NULL_TREE);
 
 	  /* The finalizer frees allocatable components.  */
 	  called_dealloc_with_status
@@ -7737,8 +7737,17 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
   cdecl, NULL_TREE);
 	  dcmp = fold_build3_loc (input_location, COMPONENT_REF, ctype, dest,
   cdecl, NULL_TREE);
+
 	  if (c-attr.codimension)
-	gfc_add_modify (fnblock, dcmp, comp);
+	{
+	  if (c-ts.type == BT_CLASS)
+		{
+		  comp = gfc_class_data_get (comp);
+		  dcmp = gfc_class_data_get (dcmp);
+		}
+	  gfc_conv_descriptor_data_set (fnblock, dcmp,
+	   gfc_conv_descriptor_data_get (comp));
+	}
 	  else
 	{
 	  tmp = structure_alloc_comps (c-ts.u.derived, comp, dcmp,
diff --git a/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90 b/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90
index ed906f5..f3d7f35 100644
--- a/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90
+++ b/gcc/testsuite/gfortran.dg/coarray/lib_realloc_1.f90
@@ -1,5 +1,4 @@
 ! { dg-do run }
-! { dg-options -O0 }
 !
 ! Test that for CAF components _gfortran_caf_deregister is called
 ! Test that norealloc happens for CAF components during assignment
--- /dev/null	2013-07-22 10:09:57.614189406 +0200
+++ gcc/gcc/testsuite/gfortran.dg/coarray_31.f90	2013-07-22 19:13:40.460945010 +0200
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! { dg-options -fdump-tree-original -fcoarray=single }
+!
+! PR fortran/57906
+! PR fortran/52052
+!
+type t
+  integer, allocatable :: x(:)[:]
+  class(*), allocatable :: z(:)[:]
+  class(*), allocatable :: d[:]
+end type t
+type t2
+  type(t) :: y
+end type t2
+type(t2) :: a, b
+a = b
+end
+
+! { dg-final { scan-tree-dump a.y.x.data = D.\[0-9\]+.y.x.data; original } }
+! { dg-final { scan-tree-dump a.y.z._data.data = D.\[0-9\]+.y.z._data.data; original } }
+! { dg-final { scan-tree-dump a.y.d._data.data = D.\[0-9\]+.y.d._data.data; original } }
+! { dg-final { cleanup-tree-dump original } }

Re: [PATCH 1/*] Fix common typos.

[Mike Stump]

On Jul 21, 2013, at 2:09 PM, Joseph S. Myers jos...@codesourcery.com wrote:
 On Sun, 21 Jul 2013, Mike Stump wrote:
 
 I've reviewed and applied the gcc/doc changes that were trivial.  The 
 only patches not applied were the ok-OK patches.
 
 *For formal documentation* such as gcc/doc, I think changing ok-OK is 
 appropriate;

I agree.  Formal prose is different, so here are the instances that I found in 
doc/*.  Thanks for the review.

Index: doc/tm.texi
===
--- doc/tm.texi (revision 201137)
+++ doc/tm.texi (working copy)
@@ -4959,7 +4959,7 @@ the function prologue.  Normally, the pr
 @cindex tail calls
 
 @deftypefn {Target Hook} bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree @var{decl}, 
tree @var{exp})
-True if it is ok to do sibling call optimization for the specified
+True if it is OK to do sibling call optimization for the specified
 call expression @var{exp}.  @var{decl} will be the called function,
 or @code{NULL} if this is an indirect call.
 
@@ -9861,7 +9861,7 @@ needed.
 
 @deftypefn {Target Hook} bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P 
(const_tree @var{fndecl})
 @cindex inlining
-This target hook returns @code{true} if it is ok to inline @var{fndecl}
+This target hook returns @code{true} if it is OK to inline @var{fndecl}
 into the current function, despite its having target-specific
 attributes, @code{false} otherwise.  By default, if a function has a
 target specific attribute attached to it, it will not be inlined.
Index: target.def
===
--- target.def  (revision 201137)
+++ target.def  (working copy)
@@ -1880,7 +1880,7 @@ needed.,
 DEFHOOK
 (function_attribute_inlinable_p,
  @cindex inlining\n\
-This target hook returns @code{true} if it is ok to inline @var{fndecl}\n\
+This target hook returns @code{true} if it is OK to inline @var{fndecl}\n\
 into the current function, despite its having target-specific\n\
 attributes, @code{false} otherwise.  By default, if a function has a\n\
 target specific attribute attached to it, it will not be inlined.,
@@ -2529,7 +2529,7 @@ The default value of this hook is based 
this is an indirect call.  */
 DEFHOOK
 (function_ok_for_sibcall,
- True if it is ok to do sibling call optimization for the specified\n\
+ True if it is OK to do sibling call optimization for the specified\n\
 call expression @var{exp}.  @var{decl} will be the called function,\n\
 or @code{NULL} if this is an indirect call.\n\
 \n\

[C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?

[Paolo Carlini]

Hi all, Jason,

while looking a bit into c++/57942, I noticed (again) that in the 
definition of the predicate DERIVED_FROM_P we use tf_warning_or_error, 
not tf_none, which seems weird for a predicate, being in general able to 
produce hard errors (*). I tested the below with no regressions.


Thanks,
Paolo.

(*) Note that, depending on how it's called, the predicate can currently 
produce errors anyway, for example because it calls complete_type. This 
may or may not be all there is to c++/57942.



Index: cp-tree.h
===
--- cp-tree.h   (revision 201122)
+++ cp-tree.h   (working copy)
@@ -1320,8 +1320,7 @@ enum languages { lang_c, lang_cplusplus, lang_java
 /* Nonzero iff TYPE is derived from PARENT. Ignores accessibility and
ambiguity issues.  */
 #define DERIVED_FROM_P(PARENT, TYPE) \
-  (lookup_base ((TYPE), (PARENT), ba_any, NULL, tf_warning_or_error)\
-   != NULL_TREE)
+  (lookup_base ((TYPE), (PARENT), ba_any, NULL, tf_none) != NULL_TREE)
 
 /* Gives the visibility specification for a class type.  */
 #define CLASSTYPE_VISIBILITY(TYPE) \

[Patch, PR 57787] Wasted work in ix86_pad_returns()

[pchang9]

Hi,

The problem appears in revision 201034 in version 4.9. I also reported
this problem at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57787.

Bootstrap and regression-tested on x86_64-linux.

In method ix86_pad_returns() in i386.c, the loop on line 35723 should
break immediately after replace is set to true.


2013-07-22  Chang  pcha...@cs.wisc.edu

* i386.c (ix86_pad_returns): Exit loop after setting replace.


Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 201034)
+++ gcc/config/i386/i386.c  (working copy)
@@ -35723,7 +35723,10 @@
  FOR_EACH_EDGE (e, ei, bb-preds)
if (EDGE_FREQUENCY (e)  e-src-index = 0
 !(e-flags  EDGE_FALLTHRU))
- replace = true;
+ {
+   replace = true;
+   break;
+ }
}
   if (!replace)
{


-Chang

Re: [PATCH 1/*] Fix common typos.

[Oleg Endo]

On Sun, 2013-07-21 at 09:35 -0700, Mike Stump wrote:
 On Jul 21, 2013, at 7:32 AM, Ondřej Bílka nel...@seznam.cz wrote:
  This is series of typo fixing patches. They are generated with stylepp
  https://github.com/neleai/stylepp
  which makes patch generation very effective.
 
 I've checked in most changes to Objective-C things and test suite things 
 after reviewing all those changes.  I agreed with most of the work, except ok 
 - OK.  We don't need to scream in the source, and ok I feel is a fine 
 english word, despite what an expert might think (they would burn us (me) at 
 the grammar stake.  They merely trail us in language adoption.  :-)
 
 One part I will throw out here, in gcc/testsuite/gcc.target/sh/pr54760-4.c:
 
 -   and its use when a function call is inbetween, when GBR is a call used
 +   and its use when a function call is between, when GBR is a call used
 
 I think this should be:
 
 -   and its use when a function call is inbetween, when GBR is a call used
 +   and its use when a function call is in-between, when GBR is a call used
 
 If someone wants to try and counter this, please, I'd favor an expert that 
 can clarify why it would be preferable.

If I remember correctly, it was me who wrote it in the first place.
It should be 'a function call in between, when'.

Thanks for catching it.
Cheers,
Oleg

Re: libbacktrace: walk the elf_syminfo_data chain in elf_syminfo

[Alexander Monakov]

On Mon, 22 Jul 2013, Ian Lance Taylor wrote:
 Thanks for noticing the problem.  This patch isn't enough by itself.
 The code has to protect itself against the list changing in
 mid-stream.  See dwarf_fileline in dwarf.c.

Thank you.  Here's the updated patch, however I have to admit it's not
entirely clear to me what __sync_bool_compare_and_swap should achieve.  Is it
only to ensure that we do not use a partially updated pointer (which shouldn't
happen with a naturally aligned pointer on hardware that updates cache lines
atomically)?

2013-07-22  Alexander Monakov  amona...@ispras.ru

* elf.c (elf_syminfo): Loop over the elf_syminfo_data chain.

diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index ef9bcdf..1d64a1f 100644
--- a/libbacktrace/elf.c
+++ b/libbacktrace/elf.c
@@ -454,12 +454,46 @@ elf_syminfo (struct backtrace_state *state, uintptr_t pc,
 void *data)
 {
   struct elf_syminfo_data *edata;
-  struct elf_symbol *sym;
+  struct elf_symbol *sym = NULL;
+
+  if (!state-threaded)
+{
+  for (edata = (struct elf_syminfo_data *) state-syminfo_data;
+  edata;
+  edata = edata-next)
+   {
+ sym = ((struct elf_symbol *)
+bsearch (pc, edata-symbols, edata-count,
+ sizeof (struct elf_symbol), elf_symbol_search));
+ if (sym != NULL)
+   break;
+   }
+}
+  else
+{
+  struct elf_syminfo_data **pp;
+
+  pp = (struct elf_syminfo_data **) (void *) state-syminfo_data;
+  while (1)
+   {
+ edata = *pp;
+ /* Atomic load.  */
+ while (!__sync_bool_compare_and_swap (pp, edata, edata))
+   edata = *pp;
+
+ if (edata == NULL)
+   break;
+
+ sym = ((struct elf_symbol *)
+bsearch (pc, edata-symbols, edata-count,
+ sizeof (struct elf_symbol), elf_symbol_search));
+ if (sym != NULL)
+   break;
+
+ pp = edata-next;
+   }
+}

-  edata = (struct elf_syminfo_data *) state-syminfo_data;
-  sym = ((struct elf_symbol *)
-bsearch (pc, edata-symbols, edata-count,
- sizeof (struct elf_symbol), elf_symbol_search));
   if (sym == NULL)
 callback (data, pc, NULL, 0);
   else

Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro

[Martin Jambor]

Hi,

On Wed, Jul 17, 2013 at 09:18:22PM -0400, David Malcolm wrote:
 gcc/
 
   Explicitly number the instances of passes within passes.def.
 
   This is needed by a subsequent patch so that we can create
   fields within the pipeline class for each pass instance (to help
   locate pass instances when debugging).
 

I don't really understand what you want to achieve.  Are you sure the
benefits are worth the work necessary to implement the processing of
passes.def.in?  Especially given that we already initialize
static_pass_number at run time and copy stuff around in
make_pass_instance when it is already set.  I assume this would
somehow allow us to directly dump data of say forwprop3 as apposed to
forwprop2 to but that would require constant awareness of the sequence
number of the currently running pass, which I think is also unpleasant
and error-prone.

I mean, you may have perfectly legitimate reasons for doing this, I'm
just wondering whether we are perhaps over-engineering this a bit.

Thanks,

Martin

Re: [PATCH][4.8 backport] Fix PR57735

[Richard Sandiford]

Kyrylo Tkachov kyrylo.tkac...@arm.com writes:
 Hi all,

 The fix for PR57735 is in current trunk (for a different issue I think), just
 needs a backport to 4.8.
 It is r198462 by Richard Sandiford:

 2013-04-30 Richard Sandiford rsand...@linux.vnet.ibm.com
   
   * explow.c (plus_constant): Pass mode to immed_double_int_const.
   Use gen_int_mode rather than GEN_INT.

 Ok to backport to the 4.8 branch?

Sorry for dropping the ball.  It's already been approved for 4.8,
and I think I even remembered to test it ready for commit.  I just
never actually hit commit afterwards :-(

Thanks,
Richard

Re: [PATCH][4.8 backport] Fix PR57735

[Richard Sandiford]

Richard Sandiford rdsandif...@googlemail.com writes:
 Kyrylo Tkachov kyrylo.tkac...@arm.com writes:
 Hi all,

 The fix for PR57735 is in current trunk (for a different issue I think), just
 needs a backport to 4.8.
 It is r198462 by Richard Sandiford:

 2013-04-30 Richard Sandiford rsand...@linux.vnet.ibm.com
  
  * explow.c (plus_constant): Pass mode to immed_double_int_const.
  Use gen_int_mode rather than GEN_INT.

 Ok to backport to the 4.8 branch?

 Sorry for dropping the ball.  It's already been approved for 4.8,
 and I think I even remembered to test it ready for commit.  I just
 never actually hit commit afterwards :-(

*sigh*.  Scratch that.  I'd confused it with:

2013-05-22  Richard Sandiford  rsand...@linux.vnet.ibm.com

* recog.c (offsettable_address_addr_space_p): Fix calculation of
address mode.  Move pointer mode initialization to the same place.

which I _did_ apply to 4.8.  Sorry about the confusion instead...

Richard

Re: [PATCH] FPU IEEE 754 for MIPS r5900

[Richard Sandiford]

Hi Jürgen,

Thanks for the update, looks good.

Jürgen Urban juergenur...@gmx.de writes:
 Index: gcc/config.gcc
 ===
 --- gcc/config.gcc(Revision 200583)
 +++ gcc/config.gcc(Arbeitskopie)
 @@ -3080,7 +3080,7 @@
esac
  fi
  
 -# Infer a default setting for --with-float.
 +# Infer a default setting for --with-float and --with-fpu.
  if test x$with_float = x; then
case ${target} in
  mips64r5900-*-* | mips64r5900el-*-* | mipsr5900-*-* | mipsr5900el-*-*)
 @@ -3089,6 +3089,17 @@
with_float=soft
;;
esac
 +else
 +  case ${target} in
 +mips64r5900-*-* | mips64r5900el-*-* | mipsr5900-*-* | mipsr5900el-*-*)
 +  if test $with_float = hard; then
 +if test x$with_fpu = x; then
 +   # The FPU of the R5900 is 32 bit.
 +   with_fpu=single
 +fi
 +  fi
 +  ;;
 +  esac
  fi

I think the --with-fpu default should be independent of the --with-float
default.  Passing -mhard-float to the default soft-float configuration
should produce the same code as configuring with --with-float=hard.

 Index: gcc/config/mips/mips.c
 ===
 --- gcc/config/mips/mips.c(Revision 200583)
 +++ gcc/config/mips/mips.c(Arbeitskopie)
 @@ -16830,6 +16830,19 @@
   target_flags = ~MASK_FLOAT64;
  }
  
 +  if (TARGET_HARD_FLOAT_ABI  TARGET_FLOAT64  TARGET_MIPS5900)
 +{
 +  /* FPU of r5900 only supports 32 bit. */
 +  error (unsupported combination: %s, -march=r5900 -mfp64 
 -mhard-float);
 +}
 +
 +  if (TARGET_HARD_FLOAT_ABI  TARGET_DOUBLE_FLOAT  TARGET_MIPS5900)
 +{
 +  /* FPU of r5900 only supports 32 bit. */
 +  error (unsupported combination: %s,
 + -march=r5900 -mdouble-float -mhard-float);
 +}

Only one of these should be needed, since we complain about -mfp64
-msingle-float earlier in the function.  Also, the coding conventions
say that there should be no braces for single-statement if blocks.

Here's what I installed.  Please let me know if I managed to mangle
things somehow.

Thanks,
Richard


gcc/
2013-07-26  Jürgen Urban  juergenur...@gmx.de

* config.gcc (mips*-*-*): Add --with-fpu support.  Make single the
default for R5900 targets.
* config/mips/mips.h (OPTION_DEFAULT_SPECS): Handle --with-fpu.
(ISA_HAS_LDC1_SDC1): Set to false for TARGET_MIPS5900.
* config/mips/mips.c (mips_option_override): Report an error for
-march=r5900 -mhard-float -mdouble-float.  Use spu_single_format
for -march=r5900 -mhard-float.


Index: gcc/config.gcc
===
--- gcc/config.gcc  2013-07-17 08:36:01.712940987 +0100
+++ gcc/config.gcc  2013-07-22 19:09:28.435708983 +0100
@@ -3091,6 +3091,16 @@ if test x$with_float = x; then
   esac
 fi
 
+# Infer a default setting for --with-fpu.
+if test x$with_fpu = x; then
+  case ${target} in
+mips64r5900-*-* | mips64r5900el-*-* | mipsr5900-*-* | mipsr5900el-*-*)
+  # The R5900 FPU only supports single precision.
+  with_fpu=single
+  ;;
+  esac
+fi
+
 # Support --with-fpmath.
 if test x$with_fpmath != x; then
   case ${target} in
@@ -3469,7 +3479,7 @@ case ${target} in
;;
 
mips*-*-*)
-   supported_defaults=abi arch arch_32 arch_64 float tune tune_32 
tune_64 divide llsc mips-plt synci
+   supported_defaults=abi arch arch_32 arch_64 float fpu tune 
tune_32 tune_64 divide llsc mips-plt synci
 
case ${with_float} in
 | soft | hard)
@@ -3480,6 +3490,16 @@ case ${target} in
exit 1
;;
esac
+
+   case ${with_fpu} in
+| single | double)
+   # OK
+   ;;
+   *)
+   echo Unknown fpu type used in --with-fpu=$with_fpu 
12
+   exit 1
+   ;;
+   esac
 
case ${with_abi} in
 | 32 | o64 | n32 | 64 | eabi)
Index: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h  2013-07-17 08:36:01.756941409 +0100
+++ gcc/config/mips/mips.h  2013-07-22 09:19:36.822510281 +0100
@@ -754,6 +754,7 @@ #define OPTION_DEFAULT_SPECS \
   {tune_64, %{ OPT_ARCH64 :%{!mtune=*:-mtune=%(VALUE)}} }, \
   {abi, %{!mabi=*:-mabi=%(VALUE)} }, \
   {float, %{!msoft-float:%{!mhard-float:-m%(VALUE)-float}} }, \
+  {fpu, %{!msingle-float:%{!mdouble-float:-m%(VALUE)-float}} }, \
   {divide, %{!mdivide-traps:%{!mdivide-breaks:-mdivide-%(VALUE)}} }, \
   {llsc, %{!mllsc:%{!mno-llsc:-m%(VALUE)}} }, \
   {mips-plt, %{!mplt:%{!mno-plt:-m%(VALUE)}} }, \
@@ -859,7 +860,9 @@ #define ISA_HAS_CONDMOVE(ISA_HAS
 || TARGET_LOONGSON_2EF)
 
 /* ISA has LDC1 and 

Re: [PATCH 1/*] Fix common typos.

[Mike Stump]

On Jul 22, 2013, at 11:20 AM, Oleg Endo oleg.e...@t-online.de wrote:
 On Sun, 2013-07-21 at 09:35 -0700, Mike Stump wrote:
 On Jul 21, 2013, at 7:32 AM, Ondřej Bílka nel...@seznam.cz wrote:
 This is series of typo fixing patches. They are generated with stylepp
 https://github.com/neleai/stylepp
 which makes patch generation very effective.
 
 I've checked in most changes to Objective-C things and test suite things 
 after reviewing all those changes.  I agreed with most of the work, except 
 ok - OK.  We don't need to scream in the source, and ok I feel is a fine 
 english word, despite what an expert might think (they would burn us (me) at 
 the grammar stake.  They merely trail us in language adoption.  :-)
 
 One part I will throw out here, in gcc/testsuite/gcc.target/sh/pr54760-4.c:
 
 -   and its use when a function call is inbetween, when GBR is a call used
 +   and its use when a function call is between, when GBR is a call used
 
 I think this should be:
 
 -   and its use when a function call is inbetween, when GBR is a call used
 +   and its use when a function call is in-between, when GBR is a call used
 
 If someone wants to try and counter this, please, I'd favor an expert that 
 can clarify why it would be preferable.
 
 If I remember correctly, it was me who wrote it in the first place.
 It should be 'a function call in between, when'.

Thanks.

Index: testsuite/gcc.target/sh/pr54760-4.c
===
--- testsuite/gcc.target/sh/pr54760-4.c (revision 201137)
+++ testsuite/gcc.target/sh/pr54760-4.c (working copy)
@@ -1,5 +1,5 @@
 /* Check that the GBR address optimization does not combine a gbr store
-   and its use when a function call is in-between, when GBR is a call used
+   and its use when a function call is in between, when GBR is a call used
register, i.e. it is invalidated by function calls.  */
 /* { dg-do compile { target sh*-*-* } } */
 /* { dg-options -O1 -fcall-used-gbr } */

Re: [C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?

[Jason Merrill]

OK.


(*) Note that, depending on how it's called, the predicate can currently 
produce errors anyway, for example because it calls complete_type. This may or 
may not be all there is to c++/57942.


It looks like lookup_base seems to deliberately avoid trying to complete 
the base, so the call to complete_type is coming from elsewhere.


Jason

Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro

[David Malcolm]

On Mon, 2013-07-22 at 20:25 +0200, Martin Jambor wrote:
 Hi,
 
 On Wed, Jul 17, 2013 at 09:18:22PM -0400, David Malcolm wrote:
  gcc/
  
  Explicitly number the instances of passes within passes.def.
  
  This is needed by a subsequent patch so that we can create
  fields within the pipeline class for each pass instance (to help
  locate pass instances when debugging).
  
 
 I don't really understand what you want to achieve.  Are you sure the
 benefits are worth the work necessary to implement the processing of
 passes.def.in?  Especially given that we already initialize
 static_pass_number at run time and copy stuff around in
 make_pass_instance when it is already set.  I assume this would
 somehow allow us to directly dump data of say forwprop3 as apposed to
 forwprop2 to but that would require constant awareness of the sequence
 number of the currently running pass, which I think is also unpleasant
 and error-prone.
 
 I mean, you may have perfectly legitimate reasons for doing this, I'm
 just wondering whether we are perhaps over-engineering this a bit.

The main goal here is part of eliminating global variables from gcc [1],
to be able to create:

class pipeline
{
  /* omitting various other fields for clarity */

  opt_pass *pass_warn_unused_result;
  opt_pass *pass_diagnose_omp_blocks;
  opt_pass *pass_diagnose_tm_blocks;
  opt_pass *pass_mudflap_1;
  opt_pass *pass_lower_omp;
  opt_pass *pass_lower_cf;
  opt_pass *pass_lower_tm;
  opt_pass *pass_refactor_eh;
  opt_pass *pass_lower_eh;
  opt_pass *pass_build_cfg;
  opt_pass *pass_warn_function_return;
  opt_pass *pass_expand_omp;
  opt_pass *pass_build_cgraph_edges;
  opt_pass *pass_ipa_free_lang_data;
  opt_pass *pass_ipa_function_and_variable_visibility;
  opt_pass *pass_early_local_passes;
  opt_pass *pass_fixup_cfg;
  opt_pass *pass_init_datastructures;
  /* etc */
  opt_pass *pass_clean_state;
};

without having to list all of the pass kinds again, thus reusing the
pass description from passes.def.  Without the numbering, I couldn't see
a good way to avoid duplicate field names in the class.  So the
numbering gives us uniqueness of field names in that class (and also
makes debugging slightly easier, but that's a minor side-benefit).

Hope that makes sense

[BTW I've just spent much of the day fighting awk trying to write a
script to generate a pass-instances.def from passes.def, but have given
up in frustration for now (how hard can it be to capture a group from a
regex, track it in a dictionary, and print a substitution with a key and
dict lookup?  hard for me in awk, it seems); am working on fixing the
bad interaction of PCH with GTY-marking of per-pass data in the
meantime].

[1] http://dmalcolm.fedorapeople.org/gcc/global-state/

Re: RFC: Gimple combine/folding interface

[Jeff Law]

On 07/21/2013 08:14 PM, Andrew Pinski wrote:

On Fri, Jul 19, 2013 at 5:09 PM, Andrew Pinski pins...@gmail.com wrote:

I was creating a new gimple/folding interface and wanted some opinions
on the interface.

typedef double_int (*nonzerobits_t)(tree var);
typedef tree (*valueizer_t)(tree var);

class gimple_combine
{
public:
   gimple_combine(nonzerobits_t a, valueizer_t b) : nonzerobitsf(a),
IIRC, the zero/nonzero bits stuff in combine is mostly good at pruning 
sign/zero extensions, eliminating bit masking in the low bits for alphas 
and for cleaning up addressing of varargs arguments that were on the 
stack.  Yea, there are times when it can do other stuff, but that's my 
recollection for what it was actually good at.


Before designing an interface which inherently includes that information 
we should think hard about if it's valuable and if a tree combiner is 
the right place.


I have high hopes that we can get the zero/sign extension elimination we 
want by carrying VRP information and querying it.


As Richi has mentioned, we really want a folder we can call 
independently of whatever pass we're in.  Though I'd also like a folder 
that can query for pass specific information if it's handy and useful.


One of the interesting things we're going to need to figure out is when 
walking the use-def chains do we want to build the more complex 
expression, then fold it, keeping the result if it's gimple.  Or do we 
want to work strictly with an exploded operator/operands represenation.


Jeff

Re: RFC: Gimple combine/folding interface

[Jakub Jelinek]

On Mon, Jul 22, 2013 at 01:36:17PM -0600, Jeff Law wrote:
 Before designing an interface which inherently includes that
 information we should think hard about if it's valuable and if a
 tree combiner is the right place.
 
 I have high hopes that we can get the zero/sign extension
 elimination we want by carrying VRP information and querying it.
 
 As Richi has mentioned, we really want a folder we can call
 independently of whatever pass we're in.  Though I'd also like a
 folder that can query for pass specific information if it's handy
 and useful.

For the preservation of VRP info we already have patch in process of review:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00121.html

As for zero bits info, I've recently run into a case where having the zero
bits information preserved alongside of the VRP info could be helpful,
for optimizing away the vectorizer scalar loop for bound.  If non-zero bits
computation proves or e.g. user asserts through if (val % 32)
__builtin_unreachable () or similar, even when the bounds of the loop aren't
constant, we could figure out that the number of iterations is a multiply of
vectorization factor and avoid computing that

So, perhaps let vrp{1,2} compute the vrp info and preserve (plus if not
specified just set nonzero bits to all ones), and this pass or other compute
the nonzero bits?  Sign bit copies is just an int, perhaps also track that.

Jakub

Re: [C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?

[Paolo Carlini]

On 07/22/2013 09:22 PM, Jason Merrill wrote:

OK.

Thanks, applied.
(*) Note that, depending on how it's called, the predicate can 
currently produce errors anyway, for example because it calls 
complete_type. This may or may not be all there is to c++/57942.
It looks like lookup_base seems to deliberately avoid trying to 
complete the base, so the call to complete_type is coming from elsewhere.

I see, indeed the comment in lookup_base:

  /* If BASE is incomplete, it can't be a base of T--and instantiating it
 might cause an error.  */

is very clear. Now, I tell you briefly what is going on: 
standard_conversion calls ptr_reasonably_similar, which, in turn calls 
comptypes. The latter, via structural_comptypes, does:


  if ((strict  COMPARE_BASE)  DERIVED_FROM_P (t1, t2))
break;
  else if ((strict  COMPARE_DERIVED)  DERIVED_FROM_P (t2, t1))
break;

you see, DERIVED_FROM_P, thus lookup_base, handles *both* the pair 
(base, derived) and the swapped pair (derived, base), thus for sure in 
one case the above comment / code doesn't help, because it protects vs 
the instantiation of the base argument not vs the instantiation of the t 
argument... bummer. I guess fixing the issue must be rather doable but 
at the moment I'm not clear about where to act...


Thanks!
Paolo.

[PATCH] Use CHECKSUM_ macros and ULEB128 checksum for DIE tag

[Eric Christopher]

Hi Cary,

This patch changes the ODR checker to use the CHECKSUM_ macros and
instead of depending on size of int to use the ULEB128 of the tag
(similar to the deep hash) to compute the values.

Thoughts?

-eric

2013-07-22  Eric Christopher  echri...@gmail.com

* dwarf2out.c (die_odr_checksum): New function to use
CHECKSUM_ macros and ULEB128 for DIE tag.
(generate_type_signature): Use.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 198904)
+++ gcc/dwarf2out.c (working copy)
@@ -6097,6 +6097,13 @@
   CHECKSUM_ULEB128 (0);
 }
 
+static void
+die_odr_checksum (dw_die_ref die, md5_ctx *ctx)
+{
+  CHECKSUM_ULEB128(die-die_tag);
+  CHECKSUM_STRING(get_AT_string(die, DW_AT_name));
+}
+
 #undef CHECKSUM
 #undef CHECKSUM_STRING
 #undef CHECKSUM_ATTR
@@ -6128,7 +6135,6 @@
   /* First, compute a signature for just the type name (and its surrounding
  context, if any.  This is stored in the type unit DIE for link-time
  ODR (one-definition rule) checking.  */
-
   if (is_cxx()  name != NULL)
 {
   md5_init_ctx (ctx);
@@ -6137,8 +6143,8 @@
   if (parent != NULL)
 checksum_die_context (parent, ctx);
 
-  md5_process_bytes (die-die_tag, sizeof (die-die_tag), ctx);
-  md5_process_bytes (name, strlen (name) + 1, ctx);
+  /* Checksum the current DIE. */
+  die_odr_checksum(die, ctx);
   md5_finish_ctx (ctx, checksum);
 
   add_AT_data8 (type_node-root_die, DW_AT_GNU_odr_signature, 
checksum[8]);

Re: [PATCH] Use CHECKSUM_ macros and ULEB128 checksum for DIE tag

[Jakub Jelinek]

On Mon, Jul 22, 2013 at 01:15:15PM -0700, Eric Christopher wrote:
 --- gcc/dwarf2out.c   (revision 198904)
 +++ gcc/dwarf2out.c   (working copy)
 @@ -6097,6 +6097,13 @@
CHECKSUM_ULEB128 (0);
  }
  

I guess you should add a function comment, plus spaces before ( everywhere
(and while you're at it, you can change also the is_cxx() ).  Will leave the
rest to Cary.

 +static void
 +die_odr_checksum (dw_die_ref die, md5_ctx *ctx)
 +{
 +  CHECKSUM_ULEB128(die-die_tag);
 +  CHECKSUM_STRING(get_AT_string(die, DW_AT_name));
 +}
 +
  #undef CHECKSUM
  #undef CHECKSUM_STRING
  #undef CHECKSUM_ATTR
 @@ -6128,7 +6135,6 @@
/* First, compute a signature for just the type name (and its surrounding
   context, if any.  This is stored in the type unit DIE for link-time
   ODR (one-definition rule) checking.  */
 -
if (is_cxx()  name != NULL)
  {
md5_init_ctx (ctx);
 @@ -6137,8 +6143,8 @@
if (parent != NULL)
  checksum_die_context (parent, ctx);
  
 -  md5_process_bytes (die-die_tag, sizeof (die-die_tag), ctx);
 -  md5_process_bytes (name, strlen (name) + 1, ctx);
 +  /* Checksum the current DIE. */
 +  die_odr_checksum(die, ctx);
md5_finish_ctx (ctx, checksum);
  
add_AT_data8 (type_node-root_die, DW_AT_GNU_odr_signature, 
 checksum[8]);


Jakub

Re: libbacktrace: walk the elf_syminfo_data chain in elf_syminfo

[Ian Lance Taylor]

On Mon, Jul 22, 2013 at 11:20 AM, Alexander Monakov amona...@ispras.ru wrote:
 On Mon, 22 Jul 2013, Ian Lance Taylor wrote:
 Thanks for noticing the problem.  This patch isn't enough by itself.
 The code has to protect itself against the list changing in
 mid-stream.  See dwarf_fileline in dwarf.c.

 Thank you.  Here's the updated patch, however I have to admit it's not
 entirely clear to me what __sync_bool_compare_and_swap should achieve.  Is it
 only to ensure that we do not use a partially updated pointer (which shouldn't
 happen with a naturally aligned pointer on hardware that updates cache lines
 atomically)?

We not only need to get a valid pointer, we need to ensure when thread
T1 creates the pointer and thread T2 loads the pointer, thread T2 sees
all the global stores that thread T1 made before T1 set the pointer.
That is, we need an acquire-load.  The hope here is that any sane
implementation of __sync_bool_compare_and_swap would ensure sequential
consistency between T1 and T2, implying an acquire-load.  On x86 every
load is an acquire-load, but that is not true on other processors.

If we added some configure tests, or didn't worry about letting people
use this library with older versions of GCC, we could use
__atomic_load_n (pp, __ATOMIC_ACQUIRE) here, and use something like
__atomic_compare_exchange_n (pp, NULL, edata, true, __ATOMIC_RELEASE,
__ATOMIC_RELAXED) in elf_add_syminfo_data.  I don't think it would
make any difference on x86, though.

 2013-07-22  Alexander Monakov  amona...@ispras.ru

 * elf.c (elf_syminfo): Loop over the elf_syminfo_data chain.


 +  for (edata = (struct elf_syminfo_data *) state-syminfo_data;
 +  edata;

Please explicitly write edata != NULL.

This is OK with that change.

Thanks.

Ian

Re: [PATCH] Use CHECKSUM_ macros and ULEB128 checksum for DIE tag

[Cary Coutant]

-  md5_process_bytes (die-die_tag, sizeof (die-die_tag), ctx);
-  md5_process_bytes (name, strlen (name) + 1, ctx);
+  /* Checksum the current DIE. */
+  die_odr_checksum(die, ctx);

Since we've already gone to the trouble of getting the name of this
DIE, it seems wasteful to have die_odr_checksum call get_AT_string
again. Why not just pass name as a parameter?

 I guess you should add a function comment, plus spaces before ( everywhere
 (and while you're at it, you can change also the is_cxx() ).  Will leave the
 rest to Cary.

Agree with the function comment and the spaces.

 2013-07-22  Eric Christopher  echri...@gmail.com

 * dwarf2out.c (die_odr_checksum): New function to use
 CHECKSUM_ macros and ULEB128 for DIE tag.
 (generate_type_signature): Use.

This is OK with those changes. Thanks!

-cary

Re: [C++ Patch / RFC] Change DERIVED_FROM_P to use tf_none?!?

[Jason Merrill]

I guess ptr_reasonably_similar should return false if one of the target 
types is incomplete.


Jason

[SPARC] Work around data cache nullify issues on LEON3

[Eric Botcazou]

This enhances -mfix-ut699 to work around the data cache nullify issues recently 
uncovered on the LEON3 processor, as documented in the relevant errata sheet.

Tested on SPARC/Solaris, applied on the mainline.


2013-07-22  Eric Botcazou  ebotca...@adacore.com

* config.gcc (sparc*-*-*): Accept leon3 processor.
(sparc-leon*-*): Merge with sparc*-*-* and add leon3 support.
* doc/invoke.texi (SPARC Options): Adjust -mfix-ut699 entry.
* config/sparc/sparc-opts.h (enum processor_type): Add PROCESSOR_LEON3.
* config/sparc/sparc.opt (enum processor_type): Add leon3.
(mfix-ut699): Adjust comment.
* config/sparc/sparc.h (TARGET_CPU_leon3): New define.
(CPP_CPU32_DEFAULT_SPEC): Add leon3 support.
(CPP_CPU_SPEC): Likewise.
(ASM_CPU_SPEC): Likewise.
* config/sparc/sparc.c (leon3_cost): New constant.
(sparc_option_override): Add leon3 support.
(mem_ref): New function.
(sparc_gate_work_around_errata): Return true if -mfix-ut699 is enabled.
(sparc_do_work_around_errata): Look into the instruction in the delay
slot and adjust accordingly.  Add fix for the data cache nullify issues
of the UT699.  Change insertion position for the NOP.
* config/sparc/leon.md (leon_fpalu, leon_fpmds, write_buf): Delete.
(leon3_load): New reservation.
(leon_store): Bump latency to 2.
(grfpu): New automaton.
(grfpu_alu): New unit.
(grfpu_ds): Likewise.
(leon_fp_alu): Adjust.
(leon_fp_mult): Delete.
(leon_fp_div): Split into leon_fp_divs and leon_fp_divd.
(leon_fp_sqrt): Split into leon_fp_sqrts and leon_fp_sqrtd.
* config/sparc/sparc.md (cpu): Add leon3.
* config/sparc/sync.md (atomic_exchangesi): Disable if -mfix-ut699.
(swapsi): Likewise.
(atomic_test_and_set): Likewise.
(ldstub): Likewise.


-- 
Eric Botcazou
Index: config.gcc
===
--- config.gcc	(revision 201053)
+++ config.gcc	(working copy)
@@ -3642,7 +3642,7 @@ case ${target} in
 			case ${val} in
 			 | sparc | sparcv9 | sparc64 \
 			| v7 | cypress \
-			| v8 | supersparc | hypersparc | leon \
+			| v8 | supersparc | hypersparc | leon | leon3 \
 			| sparclite | f930 | f934 | sparclite86x \
 			| sparclet | tsc701 \
 			| v9 | ultrasparc | ultrasparc3 | niagara | niagara2 \
@@ -3799,15 +3799,6 @@ case ${target} in
 		cxx_target_objs=${cxx_target_objs} sh-c.o
 		;;
 
-	sparc-leon*-*)
-		if test x$with_tune = x ; then
-		  with_tune=leon;
-		fi
-
-		# The SPARC port checks this value at compile-time.
-		target_cpu_default2=TARGET_CPU_$with_cpu
-		;;
-
 	sparc*-*-*)
 		# Some standard aliases.
 		case x$with_cpu in
@@ -3819,6 +3810,17 @@ case ${target} in
 			;;
 		esac
 
+		if test x$with_tune = x ; then
+		  case ${target} in
+		  *-leon-*)
+			  with_tune=leon
+			  ;;
+		  *-leon[3-9]*)
+			  with_tune=leon3
+			  ;;
+		  esac
+		fi
+
 		# The SPARC port checks this value at compile-time.
 		target_cpu_default2=TARGET_CPU_$with_cpu
 		;;
Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 201053)
+++ doc/invoke.texi	(working copy)
@@ -19491,8 +19491,8 @@ processor (which corresponds to erratum
 
 @item -mfix-ut699
 @opindex mfix-ut699
-Enable the documented workarounds for the floating-point errata of the UT699
-processor.
+Enable the documented workarounds for the floating-point errata and the data
+cache nullify errata of the UT699 processor.
 @end table
 
 These @samp{-m} options are supported in addition to the above
Index: config/sparc/sparc.md
===
--- config/sparc/sparc.md	(revision 201053)
+++ config/sparc/sparc.md	(working copy)
@@ -206,7 +206,7 @@ (define_mode_iterator F [SF DF TF])
 ;; 'f' for all DF/TFmode values, including those that are specific to the v8.
 
 ;; Attribute for cpu type.
-;; These must match the values for enum processor_type in sparc.h.
+;; These must match the values of the enum processor_type in sparc-opts.h.
 (define_attr cpu
   v7,
cypress,
@@ -214,6 +214,7 @@ (define_attr cpu
supersparc,
hypersparc,
leon,
+   leon3,
sparclite,
f930,
f934,
Index: config/sparc/sparc.opt
===
--- config/sparc/sparc.opt	(revision 201053)
+++ config/sparc/sparc.opt	(working copy)
@@ -146,6 +146,9 @@ EnumValue
 Enum(sparc_processor_type) String(leon) Value(PROCESSOR_LEON)
 
 EnumValue
+Enum(sparc_processor_type) String(leon3) Value(PROCESSOR_LEON3)
+
+EnumValue
 Enum(sparc_processor_type) String(sparclite) Value(PROCESSOR_SPARCLITE)
 
 EnumValue
@@ -203,7 +206,7 @@ Enable workaround for single erratum of
 
 mfix-ut699
 Target Report RejectNegative Var(sparc_fix_ut699)
-Enable workarounds for the FP errata of the UT699 

Re: [SPARC] Work around data cache nullify issues on LEON3

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Mon, 22 Jul 2013 23:34:29 +0200

 This enhances -mfix-ut699 to work around the data cache nullify issues 
 recently 
 uncovered on the LEON3 processor, as documented in the relevant errata sheet.
 
 Tested on SPARC/Solaris, applied on the mainline.

Looks good, nice work Eric.

Re: [PATCH] Use CHECKSUM_ macros and ULEB128 checksum for DIE tag

[Eric Christopher]

On Mon, Jul 22, 2013 at 1:30 PM, Cary Coutant ccout...@google.com wrote:
 -  md5_process_bytes (die-die_tag, sizeof (die-die_tag), ctx);
 -  md5_process_bytes (name, strlen (name) + 1, ctx);
 +  /* Checksum the current DIE. */
 +  die_odr_checksum(die, ctx);

 Since we've already gone to the trouble of getting the name of this
 DIE, it seems wasteful to have die_odr_checksum call get_AT_string
 again. Why not just pass name as a parameter?


Was mostly being cute and assuming it'd get removed. I'll just pass
both of them down into the function for now. If we decide later that
we want to change what's hashed we can change the function.

 I guess you should add a function comment, plus spaces before ( everywhere
 (and while you're at it, you can change also the is_cxx() ).  Will leave the
 rest to Cary.

 Agree with the function comment and the spaces.

Oh yeah, thanks. Sorry, it's been a while.


 2013-07-22  Eric Christopher  echri...@gmail.com

 * dwarf2out.c (die_odr_checksum): New function to use
 CHECKSUM_ macros and ULEB128 for DIE tag.
 (generate_type_signature): Use.

 This is OK with those changes. Thanks!


Committed thusly:

ghostwheel:~/sources/gcc svn ci
Sendinggcc/ChangeLog
Sendinggcc/dwarf2out.c
Transmitting file data ..
Committed revision 201148.

Thanks!

-eric

[Patch, PR 57782] Wasted work in remove_path()

[pchang9]

Hi,

The problem appears in revision 200945 in version 4.9.  I attached
a one-line patch that fixes it.  I also reported this problem at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57782

In method remove_path() in cfgloopmanip.c, the loop on line 343
should break immediately after irred_invalidated is set to true.


2013-07-22  Chang  pcha...@cs.wisc.edu

* cfgloopmanip.c (remove_path): Exit loop after
setting irred_invalidated.


Index: gcc/cfgloopmanip.c
===
--- gcc/cfgloopmanip.c  (revision 201034)
+++ gcc/cfgloopmanip.c  (working copy)
@@ -343,7 +343,11 @@
 FOR_EACH_EDGE (ae, ei, e-src-succs)
   if (ae != e  ae-dest != EXIT_BLOCK_PTR  !bitmap_bit_p (seen,  
ae-dest-index)
   ae-flags  EDGE_IRREDUCIBLE_LOOP)
-   irred_invalidated = true;
+   {
+ irred_invalidated = true;
+ break;
+   }
+
   for (i = 0; i  nrem; i++)
 {
   bb = rem_bbs[i];


-ChangIndex: gcc/cfgloopmanip.c
===
--- gcc/cfgloopmanip.c  (revision 201034)
+++ gcc/cfgloopmanip.c  (working copy)
@@ -343,7 +343,11 @@
 FOR_EACH_EDGE (ae, ei, e-src-succs)
   if (ae != e  ae-dest != EXIT_BLOCK_PTR  !bitmap_bit_p (seen, 
ae-dest-index)
   ae-flags  EDGE_IRREDUCIBLE_LOOP)
-   irred_invalidated = true;
+   {
+ irred_invalidated = true;
+ break;
+   }
+
   for (i = 0; i  nrem; i++)
 {
   bb = rem_bbs[i];

Re: [PATCH, PowerPC] rs6000_expand_vector_init selects wrong field for splat in LE mode

[David Edelsohn]

On Mon, Jul 22, 2013 at 1:12 PM, Bill Schmidt
wschm...@linux.vnet.ibm.com wrote:
 In little-endian mode, the field selected for use in a vector splat is
 numbered differently than in big-endian mode.  This patch corrects the
 code generated for little-endian.  This addresses 45 test failures when
 running the test-suite in little-endian mode.

 Bootstrapped and tested on powerpc64-unknown-linux-gnu with no new
 regressions.  Ok for trunk?

 Patch by Anton Blanchard.

 Thanks,
 Bill


 2013-07-22  Bill Schmidt  wschm...@vnet.linux.ibm.com
 for Anton Blanchard an...@au1.ibm.com

 * config/rs6000/rs6000.c (rs6000_expand_vector_init): Fix
 endianness when selecting field to splat.

Okay.

But please either only list Anton in the ChangeLog or list both you
and Anton, but not for Anton.

Thanks, David

[PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode

[Bill Schmidt]

This patch is another fix for vector handling in little endian mode.
The first two operands for a pack pattern are two vector registers that
form a contiguous array of inputs.  In LE mode the order of the operands
must be reversed so that the array remains contiguous in the reverse
order.

This fixes a failure in the testsuite when run little-endian
(gcc.dg/vect/no-scevccp-outer-18.c).  Bootstrapped and tested big-endian
on powerpc64-unknown-linux-gnu with no new regressions.  Ok for trunk?

Patch by Anton Blanchard.

Thanks,
Bill


2013-07-22  Bill Schmidt  wschm...@linux.vnet.ibm.com
Anton Blanchard an...@au1.ibm.com

* config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Reverse
two operands for little-endian.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 201131)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -28526,7 +28529,12 @@ altivec_expand_vec_perm_const (rtx operands[4])
x = target;
  else
x = gen_reg_rtx (omode);
- emit_insn (GEN_FCN (icode) (x, op0, op1));
+ /* For little-endian, the two input operands must be swapped
+to ensure proper right-to-left numbering from 0 to 2N-1.  */
+ if (BYTES_BIG_ENDIAN)
+   emit_insn (GEN_FCN (icode) (x, op0, op1));
+ else
+   emit_insn (GEN_FCN (icode) (x, op1, op0));
  if (omode != V16QImode)
emit_move_insn (target, gen_lowpart (V16QImode, x));
  return true;

RE: [ping] Re: [patch 0/4] reimplement -fstrict-volatile-bitfields, v3

[Bernd Edlinger]

Hello Hans-Peter,

 On Sat, 13 Jul 2013, Bernd Edlinger wrote:
 Hi Sandra,

 On Fri, 5 Jul 2013, Hans-Peter Nilsson wrote
 Or - maybe more acceptable - an optional warning, say
 -Wportable-volatility, to warn about code for which separate
 incompatbile definitions on different platforms (or between C
 and C++) exist even within gcc.  It would be usable for driver
 code you want to be usable on different architectures, say, in
 an OS commonly compiled with gcc, if you can think of some. :)


 I like this idea, and this warning would add some real value for everyone.
 Therefore I added that option as part 5 of this patch series, I hope you 
 don't mind :)

 Definitely not. Thanks for picking up the ball!

 I really hope that the GCC maintainers can accept this patch now, as the
 current state of -fstrict-volatile-bitfields is very painful to all of us.

 I guess I should offer a first-hand review of the warnings part.

 I've got nothing on the code, however the documentation ties the
 warning only to -fstrict-volatile-bitfields, which it shouldn't;
 it should be stated generic, but perhaps with
 -fstrict-volatile-bitfields as an *example*. (And for those who
 now feel the need to say but volatile behavior is undefined
 without reading the rest of the thread, remember that this is
 intended to cover cases where some definition actually *exist*
 whether in some language standard or some target-specific ABI
 document.)

 It also needs test-cases, both for some positive cases (warning
 hits) and some case where it doesn't (and shouldn't).

 ...and ChangeLog entries.

 Thanks again!

 brgds, H-P


thanks a lot for your Feedback, I created a change log entry,
revised the documentation as you suggested, and added two
new almost identical test cases:
One with -fstrict-volatile-bitfields and one without.

This warning should only be emitted if the code is significantly
different when -fstrict-volatile-bitfields is used or not.
It should not be emitted for the code which is not affected by this
option.

In other words, it should be emitted on all bit-fields when the
definition or the context is volatile, except when the whole
structure is not AAPCS ABI compliant, i.e. packed or unaligned.

On the other hand you should always get the same
warnings if you combine -Wportable-volatility with
-fstrict-volatile-bitfields or not. And of course it should not
depend on the specific target that is used to compile.

However when I tried to write simple test cases, I realized that
my initial code was emitting almost no warnings when
-fno-strict-volatile-bitfields is used.

I analyzed that and came to the conclusion, that the function
strict_volatile_bitfield_p() is not the best place to emit this warning,
even if is is always executed with -fstrict-volatile-bitfields.

But with -fno-strict-volatile-bitfields the program flow in store_expr()
may divert to emit_move_insn(), especially in trivial cases.

Well, I decided that the best place to emit that warning would be the
function expand_assignment() and expand_expr_real_1(), because
here we have a rtx and the tree object plus the bitsize and bitnum
all together.

However the first time when the flag_strict_volatile_bitfields is used,
is in stor_layout.c:
Here a bit-field int a:8 is replaced by char a if that is possible.
Therefore I decided that this optimization is in the way of 
-Wportable-volatility,
and has to be disabled for the same reasons as with -fstrict-volatle-bitfields.

The next problem was in fold-const.c: optimize_bit_field_compare() can
replace the COMPONENT_REF with a BIT_FIELD_REF, even for volatile
objects. But that conversion looses too much information to recover the
bit-field's DECL_BIT_FIELD_TYPE. Therefore this warning has to be skipped
at least for volatile lhs or rhs arguments if -Wportable-volatility is used.

I boot-strapped this on a i686-pc-linux-gnu and all Wportable-volatility
test cases are passed for C and C++.

I used a cross-compiler for arm-eabi to manually cross-check that
the warnings are independent of the target platform.

Sandra's test case pr23623 does emit exactly 4 warnings if compiled
with -Wportable-volatilty, which is correct. All other test cases from part 3
use unaligned or packed structures which are not AAPCS compliant at all.
Therefore they do not emit any warnings, which is also correct, because
they emit exactly the same code, regardless of the -fstrict-volatile-bitfield
setting. This may however deserve a warning on it's own.

H-P: I hope you can approve my little patch for trunk now,
although it turned out to be less trivial than I'd have expected.

Of course it is dependent on Sandra's patch part 1 and part 2,
which must be applied first.

As far as I can see, the part 2 is still missing a formal approval of
one of the global reviewers. Could some one please do that now?

Sandra, regarding Part 3, I have a small recommendation on it:
The test programs pr56997-*.c depend on stdint.h and other headers.
Could you please 

Re: [PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode

[David Edelsohn]

On Mon, Jul 22, 2013 at 7:05 PM, Bill Schmidt
wschm...@linux.vnet.ibm.com wrote:
 This patch is another fix for vector handling in little endian mode.
 The first two operands for a pack pattern are two vector registers that
 form a contiguous array of inputs.  In LE mode the order of the operands
 must be reversed so that the array remains contiguous in the reverse
 order.

 This fixes a failure in the testsuite when run little-endian
 (gcc.dg/vect/no-scevccp-outer-18.c).  Bootstrapped and tested big-endian
 on powerpc64-unknown-linux-gnu with no new regressions.  Ok for trunk?

 Patch by Anton Blanchard.

 Thanks,
 Bill


 2013-07-22  Bill Schmidt  wschm...@linux.vnet.ibm.com
 Anton Blanchard an...@au1.ibm.com

 * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Reverse
 two operands for little-endian.

Wouldn't it be better to handle this where the code is performing a
swap a few lines above?

Thanks, David

Re: [PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode

[Bill Schmidt]

On Mon, 2013-07-22 at 19:49 -0400, David Edelsohn wrote:
 On Mon, Jul 22, 2013 at 7:05 PM, Bill Schmidt
 wschm...@linux.vnet.ibm.com wrote:
  This patch is another fix for vector handling in little endian mode.
  The first two operands for a pack pattern are two vector registers that
  form a contiguous array of inputs.  In LE mode the order of the operands
  must be reversed so that the array remains contiguous in the reverse
  order.
 
  This fixes a failure in the testsuite when run little-endian
  (gcc.dg/vect/no-scevccp-outer-18.c).  Bootstrapped and tested big-endian
  on powerpc64-unknown-linux-gnu with no new regressions.  Ok for trunk?
 
  Patch by Anton Blanchard.
 
  Thanks,
  Bill
 
 
  2013-07-22  Bill Schmidt  wschm...@linux.vnet.ibm.com
  Anton Blanchard an...@au1.ibm.com
 
  * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Reverse
  two operands for little-endian.
 
 Wouldn't it be better to handle this where the code is performing a
 swap a few lines above?

Hm, I don't think so.  The reason for that swap has nothing to do with
endianness, so I think it would just confuse matters.  Also there's a
three-way swap going on with x, op0, and op1 there, and we just want to
swap op0 and op1.  I think the patch as it stands is probably easier to
grok.

Thanks,
Bill
 
 Thanks, David
 

Re: [PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode

[Bill Schmidt]

On Mon, 2013-07-22 at 19:56 -0500, Bill Schmidt wrote:
 
 On Mon, 2013-07-22 at 19:49 -0400, David Edelsohn wrote:
  On Mon, Jul 22, 2013 at 7:05 PM, Bill Schmidt
  wschm...@linux.vnet.ibm.com wrote:
   This patch is another fix for vector handling in little endian mode.
   The first two operands for a pack pattern are two vector registers that
   form a contiguous array of inputs.  In LE mode the order of the operands
   must be reversed so that the array remains contiguous in the reverse
   order.
  
   This fixes a failure in the testsuite when run little-endian
   (gcc.dg/vect/no-scevccp-outer-18.c).  Bootstrapped and tested big-endian
   on powerpc64-unknown-linux-gnu with no new regressions.  Ok for trunk?
  
   Patch by Anton Blanchard.
  
   Thanks,
   Bill
  
  
   2013-07-22  Bill Schmidt  wschm...@linux.vnet.ibm.com
   Anton Blanchard an...@au1.ibm.com
  
   * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Reverse
   two operands for little-endian.
  
  Wouldn't it be better to handle this where the code is performing a
  swap a few lines above?
 
 Hm, I don't think so.  The reason for that swap has nothing to do with
 endianness, so I think it would just confuse matters.  Also there's a
 three-way swap going on with x, op0, and op1 there, and we just want to
 swap op0 and op1.  I think the patch as it stands is probably easier to
 grok.

Bleah, sorry, wasn't paying enough attention.  Didn't notice x was being
reused as an intermediate there instead of its regular use.

It still seems a bit confusing to mix the two reasons for swapping, but
I'll look at it.

Thanks,
Bill
 
 Thanks,
 Bill
  
  Thanks, David
  

Re: [PATCH, PowerPC] altivec_expand_vec_perm_const reverses pack pattern arguments in little endian mode

[Bill Schmidt]

On Mon, 2013-07-22 at 19:49 -0400, David Edelsohn wrote:
 On Mon, Jul 22, 2013 at 7:05 PM, Bill Schmidt
 wschm...@linux.vnet.ibm.com wrote:
  This patch is another fix for vector handling in little endian mode.
  The first two operands for a pack pattern are two vector registers that
  form a contiguous array of inputs.  In LE mode the order of the operands
  must be reversed so that the array remains contiguous in the reverse
  order.
 
  This fixes a failure in the testsuite when run little-endian
  (gcc.dg/vect/no-scevccp-outer-18.c).  Bootstrapped and tested big-endian
  on powerpc64-unknown-linux-gnu with no new regressions.  Ok for trunk?
 
  Patch by Anton Blanchard.
 
  Thanks,
  Bill
 
 
  2013-07-22  Bill Schmidt  wschm...@linux.vnet.ibm.com
  Anton Blanchard an...@au1.ibm.com
 
  * config/rs6000/rs6000.c (altivec_expand_vec_perm_const): Reverse
  two operands for little-endian.
 
 Wouldn't it be better to handle this where the code is performing a
 swap a few lines above?

OK, currently testing the following.  OK if it passes?

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 201149)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -28518,6 +28518,11 @@ altivec_expand_vec_perm_const (rtx operands[4])
  enum machine_mode omode = insn_data[icode].operand[0].mode;
  enum machine_mode imode = insn_data[icode].operand[1].mode;
 
+ /* For little-endian, the two input operands must be swapped
+(or swapped back) to ensure proper right-to-left numbering
+from 0 to 2N-1.  */
+  if (!BYTES_BIG_ENDIAN)
+swapped = !swapped;
  if (swapped)
x = op0, op0 = op1, op1 = x;
  if (imode != V16QImode)

Thanks,
Bill

 
 Thanks, David
 

[Patch, PR 57780] Waste work in subst_dup()

[pchang9]

Hi,

The problem appears in revision 201034 in version 4.9.  I attached a
one-line patch that fixes it.  I also reported this problem
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57780

Bootstrap and regression-tested on x86_64-linux.

In method subst_dup() in gensupport.c, the loop on line 2181
should not be executed when code equals to MATCH_DUP or MATCH_OP_DUP.


2013-07-22  Chang  pcha...@cs.wisc.edu

* gensupport.c (subst_dup): Avoid loop if code is not
MATCH_DUP nor MATCH_OP_DUP.


Index: gcc/gensupport.c
===
--- gcc/gensupport.c(revision 201034)
+++ gcc/gensupport.c(working copy)
@@ -2178,8 +2178,8 @@
  if (XVEC (pattern, i) == NULL)
break;
case 'E':
- for (j = XVECLEN (pattern, i) - 1; j = 0; --j)
-   if (code != MATCH_DUP  code != MATCH_OP_DUP)
+ if (code != MATCH_DUP  code != MATCH_OP_DUP)
+   for (j = XVECLEN (pattern, i) - 1; j = 0; --j)
  XVECEXP (pattern, i, j) = subst_dup (XVECEXP (pattern, i, j),
   n_alt, n_subst_alt);
  break;


-ChangIndex: gcc/gensupport.c
===
--- gcc/gensupport.c(revision 201034)
+++ gcc/gensupport.c(working copy)
@@ -2178,8 +2178,8 @@
  if (XVEC (pattern, i) == NULL)
break;
case 'E':
- for (j = XVECLEN (pattern, i) - 1; j = 0; --j)
-   if (code != MATCH_DUP  code != MATCH_OP_DUP)
+ if (code != MATCH_DUP  code != MATCH_OP_DUP)
+   for (j = XVECLEN (pattern, i) - 1; j = 0; --j)
  XVECEXP (pattern, i, j) = subst_dup (XVECEXP (pattern, i, j),
   n_alt, n_subst_alt);
  break;

Re: RFA: implement C11 _Generic

[Joseph S. Myers]

I have now revised this patch from a year ago in line with my
understanding of how _Generic ought to handle the various special
cases (selector undergoes lvalue-to-rvalue conversion, and decay of
functions and arrays to pointers, because nothing says it doesn't -
The controlling expression of a generic selection was very carefully
not added to the list of contexts in which lvalue conversion is not
done and type qualification is discarded, the minutes say - and no
rvalues can have qualified type), which seems to accord with the
committee discussion in the Delft minutes, added corresponding
testcases, and committed this patch.  Bootstrapped with no regressions
on x86_64-unknown-linux-gnu.

The committee discussion includes a further point to ensure rvalues
can have qualified type: treating qualified function return types the
same as unqualified, like the way qualified function parameter types
are treated.  If that gets adopted, some further changes will be
needed elsewhere (but all those will do is cause some code to be
accepted that's currently rejected).

c-family:
2013-07-23  Tom Tromey  tro...@redhat.com

* c-common.h (enum rid) RID_GENERIC: New constant.
* c-common.c (c_common_reswords): Add _Generic.

c:
2013-07-23  Tom Tromey  tro...@redhat.com
Joseph Myers  jos...@codesourcery.com

* c-parser.c (struct c_generic_association): New.
(c_generic_association_d): New typedef.
(c_parser_generic_selection): New function.
(c_parser_postfix_expression): Handle RID_GENERIC.

testsuite:
2013-07-23  Tom Tromey  tro...@redhat.com
Joseph Myers  jos...@codesourcery.com

* gcc.dg/c11-generic-1.c: New file.
* gcc.dg/c11-generic-2.c: New file.

Index: c/c-parser.c
===
--- c/c-parser.c(revision 201131)
+++ c/c-parser.c(working copy)
@@ -6232,7 +6232,226 @@ c_parser_get_builtin_args (c_parser *parser, const
   return true;
 }
 
+/* This represents a single generic-association.  */
 
+struct c_generic_association
+{
+  /* The location of the starting token of the type.  */
+  location_t type_location;
+  /* The association's type, or NULL_TREE for 'default'..  */
+  tree type;
+  /* The association's expression.  */
+  struct c_expr expression;
+};
+
+/* Parse a generic-selection.  (C11 6.5.1.1).
+   
+   generic-selection:
+ _Generic ( assignment-expression , generic-assoc-list )
+ 
+   generic-assoc-list:
+ generic-association
+ generic-assoc-list , generic-association
+   
+   generic-association:
+ type-name : assignment-expression
+ default : assignment-expression
+*/
+
+static struct c_expr
+c_parser_generic_selection (c_parser *parser)
+{
+  vecc_generic_association associations = vNULL;
+  struct c_expr selector, error_expr;
+  tree selector_type;
+  struct c_generic_association matched_assoc;
+  bool match_found = false;
+  location_t generic_loc, selector_loc;
+
+  error_expr.original_code = ERROR_MARK;
+  error_expr.original_type = NULL;
+  error_expr.value = error_mark_node;
+  matched_assoc.type_location = UNKNOWN_LOCATION;
+  matched_assoc.type = NULL_TREE;
+  matched_assoc.expression = error_expr;
+
+  gcc_assert (c_parser_next_token_is_keyword (parser, RID_GENERIC));
+  generic_loc = c_parser_peek_token (parser)-location;
+  c_parser_consume_token (parser);
+  if (!flag_isoc11)
+{
+  if (flag_isoc99)
+   pedwarn (generic_loc, OPT_Wpedantic,
+ISO C99 does not support %_Generic%);
+  else
+   pedwarn (generic_loc, OPT_Wpedantic,
+ISO C90 does not support %_Generic%);
+}
+
+  if (!c_parser_require (parser, CPP_OPEN_PAREN, expected %(%))
+return error_expr;
+
+  c_inhibit_evaluation_warnings++;
+  selector_loc = c_parser_peek_token (parser)-location;
+  selector = c_parser_expr_no_commas (parser, NULL);
+  selector = default_function_array_conversion (selector_loc, selector);
+  c_inhibit_evaluation_warnings--;
+
+  if (selector.value == error_mark_node)
+{
+  c_parser_skip_until_found (parser, CPP_CLOSE_PAREN, NULL);
+  return selector;
+}
+  selector_type = TREE_TYPE (selector.value);
+  /* In ISO C terms, rvalues (including the controlling expression of
+ _Generic) do not have qualified types.  */
+  if (TREE_CODE (selector_type) != ARRAY_TYPE)
+selector_type = TYPE_MAIN_VARIANT (selector_type);
+  /* In ISO C terms, _Noreturn is not part of the type of expressions
+ such as abort, but in GCC it is represented internally as a type
+ qualifier.  */
+  if (FUNCTION_POINTER_TYPE_P (selector_type)
+   TYPE_QUALS (TREE_TYPE (selector_type)) != TYPE_UNQUALIFIED)
+selector_type
+  = build_pointer_type (TYPE_MAIN_VARIANT (TREE_TYPE (selector_type)));
+
+  if (!c_parser_require (parser, CPP_COMMA, expected %,%))
+{
+  c_parser_skip_until_found (parser, CPP_CLOSE_PAREN, NULL);
+  return error_expr;
+}
+
+  

Re: RFA: implement C11 _Generic

[Joseph S. Myers]

On Tue, 23 Jul 2013, Joseph S. Myers wrote:

 The committee discussion includes a further point to ensure rvalues
 can have qualified type: treating qualified function return types the

(to ensure they *can't* have qualified type, that is)

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

libgo patch committed: Ignore SIGPROF on non-Go thread

[Ian Lance Taylor]

This patch to libgo ignores a SIGPROF signal if it is received on a
non-Go thread.  This permits the Go library profiling support to work in
a program that calls C/C++ code that starts threads.  Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu.  Committed to mainline and
4.8 branch.

Ian

diff -r f1650653ba7d libgo/runtime/go-signal.c
--- a/libgo/runtime/go-signal.c	Tue Jul 16 15:42:30 2013 -0700
+++ b/libgo/runtime/go-signal.c	Mon Jul 22 21:39:43 2013 -0700
@@ -166,21 +166,22 @@
   int i;
 
   m = runtime_m ();
+
+#ifdef SIGPROF
+  if (sig == SIGPROF)
+{
+  if (m != NULL  gp != m-g0  gp != m-gsignal)
+	runtime_sigprof ();
+  return;
+}
+#endif
+
   if (m == NULL)
 {
   runtime_badsignal (sig);
   return;
 }
 
-#ifdef SIGPROF
-  if (sig == SIGPROF)
-{
-  if (gp != runtime_m ()-g0  gp != runtime_m ()-gsignal)
-	runtime_sigprof ();
-  return;
-}
-#endif
-
   for (i = 0; runtime_sigtab[i].sig != -1; ++i)
 {
   SigTab *t;

Re: [Patch, PR 57812] Wasted work in computed_jump_p()

[Chung-Ju Wu]

2013/7/23  pcha...@cs.wisc.edu:

 2013-07-22  Chang  pcha...@cs.wisc.edu

 * rtlanal.c (computed_jump_p): Exit loop once we find label
   reference is used.


The second line is supposed to be aligned with '*' character at first line.
Like this:

* rtlanal.c (computed_jump_p): Exit loop once we find label
reference is used.


Best regards,
jasonwucj

Add more info to google/gcc-4_8 powerpc64 xfails file.

[Brooks Moses]

Diego -

The attached patch adds a little more analysis info to the powerpc64
xfails file.  Ok to commit?

Thanks,
- Brooks


2013-07-22_xfail-more-info.diff
Description: Binary data

Re: [Patch, microblaze]: Add -fstack-usage support

[David Holsgrove]

Hi Eric / Chung-Ju,

On 21 July 2013 01:33, Chung-Ju Wu jasonw...@gmail.com wrote:
 On 7/20/13 4:14 PM, Eric Botcazou wrote:

 2013-03-18  David Holsgrove david.holsgr...@xilinx.com

   * gcc/config/microblaze/microblaze.c (microblaze_expand_prologue):
 Add check for flag_stack_usage to handle -fstack-usage support

 Signed-off-by: David Holsgrove david.holsgr...@xilinx.com


 Patch remains the same, please apply when ready.


 The patch is incorrect, please adjust it to match the other architectures.


 Hi, David,

 Specifically speaking, what Eric meant is to check
 flag_stack_usage_info rather than flag_stack_usage
 due to the changes after gcc-4.7.


Ah, thanks for the catch - patch had been sitting in my tree for quite a while,
hadn't realised the variable name had changed on trunk.

Patch attached which adjusts microblaze's usage to align with other archs.

thanks,
David


 Best regards,
 jasonwucj



0001-Patch-microblaze-Update-flag_stack_usage-variable-na.patch
Description: Binary data