Re: [patch] [libstdc++] Fix build failure with --enable-libstdcxx-debug

2012-12-10 Thread Matthias Klose
Am 10.12.2012 08:19, schrieb Matthias Klose:
 Seen with a x86_64 x arm x arm cross build and --enable-libstdcxx-debug. The
 ../config.h should not be hard-coded. Using the macro guarantees that the
 rewritten macros for the debug builds are used. However I fail to see why the
 unpatched version does work for the native build.
 
 Ok for the trunk and the 4.7 branch?

and attaching the patch ...


# DP: Fix cross build failure with --enable-libstdcxx-debug.

	* src/Makefile.am (libstdc++-symbols.ver): Use CONFIG_HEADER.
	* src/Makefile.in: Regenerate.

--- libstdc++-v3/src/Makefile.am~	2012-12-09 11:55:15.357516806 +0100
+++ libstdc++-v3/src/Makefile.am	2012-12-09 14:48:31.545377728 +0100
@@ -213,7 +213,7 @@
 	  fi; \
 	fi
 	$(EGREP) -v '^[ 	]*#(#| |$$)' $@.tmp | \
-	  $(CC) -E -P -include ../config.h -  $@ || (rm -f $@ ; exit 1)
+	  $(CC) -E -P -include $(CONFIG_HEADER) -  $@ || (rm -f $@ ; exit 1)
 	rm -f $@.tmp
 
 CLEANFILES = libstdc++-symbols.ver


Re: [patch] [libstdc++] Fix build failure with --enable-libstdcxx-debug

2012-12-10 Thread Jonathan Wakely
On 10 December 2012 08:22, Matthias Klose d...@ubuntu.com wrote:
 Am 10.12.2012 08:19, schrieb Matthias Klose:
 Seen with a x86_64 x arm x arm cross build and --enable-libstdcxx-debug. The
 ../config.h should not be hard-coded. Using the macro guarantees that the
 rewritten macros for the debug builds are used. However I fail to see why the
 unpatched version does work for the native build.

 Ok for the trunk and the 4.7 branch?

OK, thanks

 and attaching the patch ...




Re: PATCH: PR lto/55466: Revision 191466 destroyed DWARF debug info

2012-12-10 Thread Richard Biener
On Fri, Dec 7, 2012 at 11:59 PM, H.J. Lu hongjiu...@intel.com wrote:
 Hi,

 Since revision 191466, LTO no longer maintains its own symbol table and
 it uses varpool for variables instead.  As the result, debug info on
 variables is lost when GCC is configured with

 --enable-bootstrap --with-build-config=bootstrap-lto

 This patch record the global variables if WPA isn't enabled.  It
 works when GCC is configured with

 --enable-bootstrap --with-build-config=bootstrap-lto 
 --enable-languages=c,c++,fortran,java,lto,objc,obj-c++

 However, when go is added, I got

 lto1: internal compiler error: in add_AT_specification, at
 dwarf2out.c:3985
 0x629ad9 add_AT_specification
 /export/gnu/import/git/gcc/gcc/dwarf2out.c:3985
 0x64dabb gen_variable_die
 /export/gnu/import/git/gcc/gcc/dwarf2out.c:18327
 0x65336b gen_decl_die
 /export/gnu/import/git/gcc/gcc/dwarf2out.c:20033
 0x653fcd dwarf2out_decl(tree_node*)
 /export/gnu/import/git/gcc/gcc/dwarf2out.c:20348
 0x6535f9 dwarf2out_global_decl
 /export/gnu/import/git/gcc/gcc/dwarf2out.c:20083
 0x997703 emit_debug_global_declarations(tree_node**, int)
 /export/gnu/import/git/gcc/gcc/toplev.c:530
 0x521aaa lto_write_globals
 /export/gnu/import/git/gcc/gcc/lto/lto-lang.c:1067
 Please submit a full bug report,
 with preprocessed source if appropriate.
 Please include the complete backtrace with any bug report.
 See http://gcc.gnu.org/bugs.html for instructions.
 make[6]: *** [/tmp/cc3yYR7d.ltrans4.ltrans.o] Error 1
 lto-wrapper: make returned 2 exit status
 /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
 collect2: error: ld returned 1 exit status
 make[5]: *** [go1] Error 1

 This is latent without my patch since no DWARF info on varaibles are
  generated.  OK to install?

 Thanks.


 H.J.
 ---
 2012-12-07  H.J. Lu  hongjiu...@intel.com

 PR lto/55466
 * lto-symtab.c (lto_symtab_merge_decls_1): Don't record
 the prevailing variable.
 * lto.c (lto_main): Record the global variables if WPA isn't
 enabled.

 diff --git a/gcc/lto-symtab.c b/gcc/lto-symtab.c
 index 0b0cdac..295fd37 100644
 --- a/gcc/lto-symtab.c
 +++ b/gcc/lto-symtab.c
 @@ -443,10 +443,6 @@ lto_symtab_merge_decls_1 (symtab_node first)

symtab_prevail_in_asm_name_hash (prevailing);

 -  /* Record the prevailing variable.  */
 -  if (TREE_CODE (prevailing-symbol.decl) == VAR_DECL)
 -vec_safe_push (lto_global_var_decls, prevailing-symbol.decl);
 -

As this is not necessary, the push in lto.c:lto_register_var_decl_in_symtab
for statics should not be necessary either (we even call
rest_of_decl_compilation
there).

Ok with that push removed as well.

Please make sure to file a bugreport for the go LTO bootstrap issue.

Thanks,
Richard.

/* Diagnose mismatched objects.  */
for (e = prevailing-symbol.next_sharing_asm_name;
 e; e = e-symbol.next_sharing_asm_name)
 diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
 index 376af85..e567cb0 100644
 --- a/gcc/lto/lto.c
 +++ b/gcc/lto/lto.c
 @@ -3380,6 +3380,8 @@ lto_main (void)
 do_whole_program_analysis ();
else
 {
 + struct varpool_node *vnode;
 +
   timevar_start (TV_PHASE_OPT_GEN);

   materialize_cgraph ();
 @@ -3397,6 +3399,10 @@ lto_main (void)
  this.  */
   if (flag_lto_report)
 print_lto_report_1 ();
 +
 + /* Record the global variables.  */
 + FOR_EACH_DEFINED_VARIABLE (vnode)
 +   vec_safe_push (lto_global_var_decls, vnode-symbol.decl);
 }
  }



Re: Fix ICE on loop over constant vector at -O

2012-12-10 Thread Richard Biener
On Sat, Dec 8, 2012 at 12:42 PM, Eric Botcazou ebotca...@adacore.com wrote:
 This is an internal error in for_each_index at -O:

 +===GNAT BUG DETECTED==+
 | 4.8.0 20121208 (experimental) [trunk revision 194319] (x86_64-suse-linux)
 GCC error:|
 | in for_each_index, at tree-ssa-loop-im.c:324 |
 | Error detected around vect9.adb:45:1|

 The callback is invoked on a vector CONST_DECL and stops.  That's an unusual
 situation (the CONST_DECL is wrapped up in a VIEW_CONVERT_EXPR to array type)
 but IMO there is no reason to accept other DECLs and stop on CONST_DECLs.

 Tested on x86_64-suse-linux, applied on the mainline as obvious.

Well ... I would have expected that we'd have folded the CONST_DECL to
its DECL_INITIAL.  At least that is what we do for all other CONST_DECLs.
The only way CONST_DECLs should appear in the IL (after some optimization
of course) is when you take their address.

So - if you can burn some extra cycles to figure out why it's not
replaced by its DECL_INITIAL ...?

Richard.

 2012-12-08  Eric Botcazou  ebotca...@adacore.com

 * tree-ssa-loop-im.c (for_each_index) CONST_DECL: New case.


 2012-12-08  Eric Botcazou  ebotca...@adacore.com

 * gnat.dg/vect9.ad[sb]: New test.
 * gnat.dg/vect9_pkg.ads: New helper.


 --
 Eric Botcazou


Re: [patch stmt.c]: 6 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32

2012-12-10 Thread Richard Biener
On Sun, Dec 9, 2012 at 4:58 PM, NightStrike nightstr...@gmail.com wrote:
 On Sat, Dec 1, 2012 at 11:13 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Ping

 2012/11/29 Kai Tietz ktiet...@googlemail.com:
 Hello,

 this trivial patch fixes a bootstrap issue on LLP64 hosts.

 ChangeLog

 2012-11-29 Kai Tietz

 PR target/53912
 * stmt.c (compute_cases_per_edge): Cast from pointer via intptr_t.
 (expand_case): Likewise.

 Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
 x86_64-unknown-gnu-linux. Ok for apply?

 Regards,
 Kai

 Index: stmt.c
 ===
 --- stmt.c  (Revision 193925)
 +++ stmt.c  (Arbeitskopie)
 @@ -2061,7 +2061,7 @@ compute_cases_per_edge (gimple stmt)
tree lab = CASE_LABEL (elt);
basic_block case_bb = label_to_block_fn (cfun, lab);
edge case_edge = find_edge (bb, case_bb);
 -  case_edge-aux = (void *)((long)(case_edge-aux) + 1);
 +  case_edge-aux = (void *)((intptr_t)(case_edge-aux) + 1);
  }
  }

 @@ -2176,7 +2176,7 @@ expand_case (gimple stmt)
edge case_edge = find_edge (bb, case_bb);
case_list = add_case_node (
case_list, low, high, lab,
 -  case_edge-probability / (long)(case_edge-aux),
 +  case_edge-probability / (intptr_t)(case_edge-aux),
case_node_pool);
  }
pointer_set_destroy (seen_labels);

 Ping x2

Ok.

Thanks,
Richard.


Re: [patch stmt.c]: Fix SjLj exception handling

2012-12-10 Thread Richard Biener
On Sun, Dec 9, 2012 at 5:17 PM, NightStrike nightstr...@gmail.com wrote:
 On Sat, Dec 1, 2012 at 12:28 PM, Steven Bosscher stevenb@gmail.com 
 wrote:
 On Sat, Dec 1, 2012 at 10:59 PM, Kai Tietz wrote:
 Hi,

 recent 4,8 has regressions in g++.old-deja/g++.eh for the catch*.C
 tests, if exception-mechanism is SjLj.  This is due an off by one
 failure in an decreasing loop.

 ChangeLog

 2012-12-01  Kai Tietz

 * stmt.c (expand_sjlj_dispatch_table): Fix off by one.

 Tested for i686-w64-mingw32, x86_64-unknown-linux-gnu.  Ok for apply?

 Regards,
 Kai


 Index: stmt.c
 ===
 --- stmt.c  (Revision 193985)
 +++ stmt.c  (Arbeitskopie)
 @@ -2282,7 +2282,7 @@ expand_sjlj_dispatch_table (rtx dispatch_index,
tree range = maxval;
rtx default_label = gen_label_rtx ();

 -  for (int i = ncases - 1; i  0; --i)
 +  for (int i = ncases - 1; i = 0; --i)
 {
   tree elt = dispatch_table[i];
   tree low = CASE_LOW (elt);


 I can't approve this, but it's obvious. The normal switch expander
 (expand_case) expects the default case in slot 0, but the SJLJ
 dispatch table doesn't have a default case.

 Ciao!
 Steven

 Ping.

Ok.

Thanks,
Richard.


Re: [patch print-tree.c]: 5 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32

2012-12-10 Thread Richard Biener
On Sun, Dec 9, 2012 at 5:18 PM, NightStrike nightstr...@gmail.com wrote:
 On Sat, Dec 1, 2012 at 11:12 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Ping

 2012/11/29 Kai Tietz ktiet...@googlemail.com:
 Hello,

 this trivial patch fixes a bootstrap issue on LLP64 hosts.

 ChangeLog

 2012-11-29 Kai Tietz

 PR target/53912
 * print-tree.c (print_node): Cast from pointer via uintptr_t.

 Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
 x86_64-unknown-gnu-linux. Ok for apply?

 Regards,
 Kai

 Index: print-tree.c
 ===
 --- print-tree.c(Revision 193925)
 +++ print-tree.c(Arbeitskopie)
 @@ -255,7 +255,7 @@ print_node (FILE *file, const char *prefix, tree n
/* Allow this function to be called if the table is not there.  */
if (table)
  {
 -  hash = ((unsigned long) node) % HASH_SIZE;
 +  hash = ((uintptr_t) node) % HASH_SIZE;

/* If node is in the table, just mention its address.  */
for (b = table[hash]; b; b = b-next)

 Ping.

Ok.

Thanks,
Richard.


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread Janus Weil
2012/12/10 David Edelsohn dje@gmail.com:
 There has been no progress on this bug for over two months.  I have
 opened PR fortran/55636.  This must be fixed before GCC 4.8 ships.

Thanks for pinging, David. I almost forgot about it ...

Here is a re-diffed version of my previous patch. I'd be grateful for
comments. In particular: Does it fix all the problems on AIX? (For
more open questions, see below.)

Cheers,
Janus



 On Thu, Oct 4, 2012 at 5:04 PM, Janus Weil ja...@gcc.gnu.org wrote:

 unfortunately my previous patch regressed on the proc_ptr_result test
 cases (due to problems with implicit typing of symbols with leading
 underscores, which also were the reason for using a suffix instead of
 a prefix for proc-ptr results in the first place). So I have taken out
 the 'ppr' parts, leaving only Tobias' original cases and the OOP
 stuff, which at least should be regression-free now.

 There are some more double-underscore cases which one could also
 change into the new _F convention. Should I keep going in this
 direction, or should we rather restrict this to the leading dot
 cases for now? I guess this is a question of how much ABI breaking we
 are willing to take. Opinions?

 Cheers,
 Janus


mangling_v3.diff
Description: Binary data


Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs

2012-12-10 Thread Richard Biener
On Sun, Dec 9, 2012 at 2:50 PM, Uros Bizjak ubiz...@gmail.com wrote:
 Hello!

 I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
 SP adjustment instead of a sequence of pushes/pops. The preference to
 the MOVs are good for old CPU micro-architectures (before pentium-4,
 K10), because it breaks the data dependency.  In modern
 micro-architecture, push/pop is implemented using a mechanism called
 stack engine. The data dependency is removed by the hardware, and
 push/pop becomes very cheap (1 uOp, 1 cycle latency), and they are
 smaller. There is no longer the need to avoid using them.   This is
 also what ICC does.

 2012-12-08  Xinliang David Li  davi...@google.com
* config/i386/i386.c: Eanble push/pop in pro/epilogue for moderen 
 CPUs.

 s/moderen/modern

 OK for mainline SVN.

It's also more costly for unwind info in the prologue/epilogue.  Thus, did you
measure the effect on CFI size?

Thanks,
Richard.

 Thanks,
 Uros.


Re: [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules

2012-12-10 Thread Tobias Burnus

Hi Janus,

I think the patch below is okay, especially in light of patch 
PR49110/51055 which also contains a slight ABI breakage. Can you mention 
the potential ABI issue in the release notes (gfortran wiki).


Tobias

On 09.04.2012 18:31 Janus Weil wrote:

Hi all,

here is a simple patch for a problem recently reported by Andrew
Benson: Procedure pointers inside a module don't receive the proper
name mangling, which can lead to name collisions (as the test case
demonstrates).

The patch fixes this and regtests cleanly on x86_64-unknown-linux-gnu.
I am aware that it will break the ABI, but only for programs involving
procedure pointers (which still is a 'relatively' new feature,
supported since gfortran 4.4). So, ok for trunk?

Btw, speaking of ABI breaking: What are the chances of the array
descriptor update and ABI cleanup happening for the 4.8 release? I
know such an ABI breaking has been planned for some time, but I
haven't followed the gfortran mailing list in detail during the last
weeks and months, so I'm not sure what the current status is.

Cheers,
Janus



2012-04-09  Janus Weil  ja...@gcc.gnu.org

PR fortran/52909
* trans-decl.c (get_proc_pointer_decl): Apply name mangling.


2012-04-09  Janus Weil  ja...@gcc.gnu.org

PR fortran/52909
* gfortran.dg/proc_ptr_37.f90: New test case.




Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread Jakub Jelinek
On Mon, Dec 10, 2012 at 10:22:30AM +0100, Janus Weil wrote:
 2012/12/10 David Edelsohn dje@gmail.com:
  There has been no progress on this bug for over two months.  I have
  opened PR fortran/55636.  This must be fixed before GCC 4.8 ships.
 
 Thanks for pinging, David. I almost forgot about it ...
 
 Here is a re-diffed version of my previous patch. I'd be grateful for
 comments. In particular: Does it fix all the problems on AIX? (For
 more open questions, see below.)

IMHO there is no point to mangle automatic vars or PARM_DECLs that way,
i.e. anything that won't be TREE_STATIC.  And, what will be TREE_STATIC
should have dot or $ character in the symbol name if the target allows it,
to avoid unnecessary clashes with e.g. the C library etc.

Jakub


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread Janus Weil
 Here is a re-diffed version of my previous patch. I'd be grateful for
 comments. In particular: Does it fix all the problems on AIX? (For
 more open questions, see below.)

 IMHO there is no point to mangle automatic vars or PARM_DECLs that way,
 i.e. anything that won't be TREE_STATIC.  And, what will be TREE_STATIC
 should have dot or $ character in the symbol name if the target allows it,
 to avoid unnecessary clashes with e.g. the C library etc.

well, I'm not an expert for C/C++ name mangling, but this patch was
motivated by David's earlier statement:

 For C and C++, identifiers beginning with underscore and upper case
 letter or with two underscores are reserve to the implementation.

See the previous discussion in this thread ...

Cheers,
Janus


Re: Fix ICE on loop over constant vector at -O

2012-12-10 Thread Eric Botcazou
 Well ... I would have expected that we'd have folded the CONST_DECL to
 its DECL_INITIAL.  At least that is what we do for all other CONST_DECLs.
 The only way CONST_DECLs should appear in the IL (after some optimization
 of course) is when you take their address.

That's what (essentially) happens here.  The CONST_DECL is wrapped up in a 
VIEW_CONVERT_EXPR to array type and a component with non-constant index is 
extracted from it.

 So - if you can burn some extra cycles to figure out why it's not
 replaced by its DECL_INITIAL ...?

We specifically prevent that in gigi because it will need to be spilled to 
memory given the above access pattern, so I don't really see the problem.
Here's the access in .optimized:

_38 = MEM[symbol: pkg__zero_unit, index: ivtmp.38_27, step: 4, offset: -4B];

-- 
Eric Botcazou


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread Jakub Jelinek
On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
  For C and C++, identifiers beginning with underscore and upper case
  letter or with two underscores are reserve to the implementation.
 
 See the previous discussion in this thread ...

That's true, but the implementation isn't just GCC, it is also C libraries
which aren't provided by GCC.  Including a character (if possible) that
will make it unaccessible from C/C++ is desirable.  And, not changing the
names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
in the debug info from time to time, so making them unnecessarily larger
results in .debug_info size increases.

Jakub


Re: [PATCH][ARM][3/3] AArch32 NEON vrint builtins and intrinsics

2012-12-10 Thread Ramana Radhakrishnan

On 11/29/12 14:27, Kyrylo Tkachov wrote:

Hi all,
This patch adds the intrinsics support for the vrnd intrinsics that are
implemented by the vrint instructions.
The .ml scripts contain the new information and should used to regenerate
the arm_neon.h header file, tests and documentation.
In particular:
* config/arm/arm_neon.h should be regenerated using config/arm/neon-gen.ml.
* doc/arm-neon-intrinsics.texi should be regenerated using
config/arm/neon-docgen.ml.
* The tests in testsuite/gcc.target/arm/neon/ should be generated using
config/arm/neon-testgen.ml.
All three of these scripts should be linked against the compiled neon.ml
file i.e:
$ ocamlc -c neon.ml
$ ocamlc -o neon-gen neon.cmo neon-gen.ml


The following intrinsics are defined:
vrnd_f32 (float32x2_t a)   (generating a vrintz instruction)
vrndq_f32 (float32x4_t a)  (generating a vrintz instruction)
vrnda_f32 (float32x2_t a)  (generating a vrinta instruction)
vrndqa_f32 (float32x4_t a) (generating a vrinta instruction)
vrndm_f32 (float32x2_t a)  (generating a vrintm instruction)
vrndqm_f32 (float32x4_t a) (generating a vrintm instruction)
vrndn_f32 (float32x2_t a)  (generating a vrintn instruction)
vrndqn_f32 (float32x4_t a) (generating a vrintn instruction)
vrndp_f32 (float32x2_t a)  (generating a vrintp instruction)
vrndqp_f32 (float32x4_t a) (generating a vrintp instruction)

Note that AArch32 NEON does not support double precision floats, so we don't
have _f64 versions.

Tested on arm-none-eabi. New tests pass, no regressions (once the effective
target checks patch is added).

Ok for trunk?


Please add 2012 as a copyright year for arm_neon.h in the generator program.

When I regenerated the documents, it did look like there were more 
changes in arm-neon-intrinsics.texi but my suspicion is this is because 
the document hasn't been regenerated in some time. The main change here 
is the order in which some of the intrinsics are listed which has 
changed over time.


Ok with that change.


regards,
Ramana





Re: [patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

2012-12-10 Thread Richard Sandiford
H.J. Lu hjl.to...@gmail.com writes:
 On Sat, Dec 8, 2012 at 2:14 AM, Richard Sandiford
 rdsandif...@googlemail.com wrote:

 As far as the dwarf2out.c bits go, I think the original dbx_reg_number 
 assert:

   gcc_assert (regno != INVALID_REGNUM);

 should become:

   gcc_assert (regno != INVALID_REGNUM  regno != IGNORED_DWARF_REGNUM);

 since it's the caller's job to handle this case.


 I don't think if it will work since dbx_reg_number is called
 to get debug register number and the register is ignored
 if its return value is IGNORED_DWARF_REGNUM.

Er, quite.  What was I thinking?

So please ignore that stupid suggestion.  The comments about the MIPS
parts still stand of course.

Richard


[PATCH] SPU: Fix build failure on 64 bit hosts

2012-12-10 Thread Andreas Krebbel
Hi,

building an SPU compiler on a 64 bit host system currently fails with:

spu.md:4394: error: cast from ‘rtx_def**’ to ‘int’ loses precision

In the SPU backend several patterns mention the operands array in the
insn condition in order to prevent a warning about missing modes to be
issued.  Interpreting the term operands as condition fails when it
is evaluated on a 64 bit host.  Turning it into a comparison fixes
this for me.

Ok to apply?

Bye,

-Andreas-


2012-12-10  Andreas Krebbel  andreas.kreb...@de.ibm.com

* config/spu/spu.md: Replace operands with operands != NULL in
insn conditions.

---
 gcc/config/spu/spu.md |   16 
 1 file changed, 16 modifications(!)

Index: gcc/config/spu/spu.md
===
*** gcc/config/spu/spu.md.orig
--- gcc/config/spu/spu.md
***
*** 1066,1072 
[(set (match_operand:CBOP 0 spu_reg_operand =r)
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)] UNSPEC_CG))]
!   operands
cg\t%0,%1,%2)
  
  (define_insn cgx_mode
--- 1066,1072 
[(set (match_operand:CBOP 0 spu_reg_operand =r)
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)] UNSPEC_CG))]
!   operands != NULL
cg\t%0,%1,%2)
  
  (define_insn cgx_mode
***
*** 1074,1080 
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)
  (match_operand 3 spu_reg_operand 0)] UNSPEC_CGX))]
!   operands
cgx\t%0,%1,%2)
  
  (define_insn addx_mode
--- 1074,1080 
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)
  (match_operand 3 spu_reg_operand 0)] UNSPEC_CGX))]
!   operands != NULL
cgx\t%0,%1,%2)
  
  (define_insn addx_mode
***
*** 1082,1088 
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)
  (match_operand 3 spu_reg_operand 0)] UNSPEC_ADDX))]
!   operands
addx\t%0,%1,%2)
  
  
--- 1082,1088 
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)
  (match_operand 3 spu_reg_operand 0)] UNSPEC_ADDX))]
!   operands != NULL
addx\t%0,%1,%2)
  
  
***
*** 1189,1195 
[(set (match_operand:CBOP 0 spu_reg_operand =r)
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)] UNSPEC_BG))]
!   operands
bg\t%0,%2,%1)
  
  (define_insn bgx_mode
--- 1189,1195 
[(set (match_operand:CBOP 0 spu_reg_operand =r)
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)] UNSPEC_BG))]
!   operands != NULL
bg\t%0,%2,%1)
  
  (define_insn bgx_mode
***
*** 1197,1203 
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)
  (match_operand 3 spu_reg_operand 0)] UNSPEC_BGX))]
!   operands
bgx\t%0,%2,%1)
  
  (define_insn sfx_mode
--- 1197,1203 
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)
  (match_operand 3 spu_reg_operand 0)] UNSPEC_BGX))]
!   operands != NULL
bgx\t%0,%2,%1)
  
  (define_insn sfx_mode
***
*** 1205,1211 
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)
  (match_operand 3 spu_reg_operand 0)] UNSPEC_SFX))]
!   operands
sfx\t%0,%2,%1)
  
  (define_insn subti3
--- 1205,1211 
(unspec:CBOP [(match_operand 1 spu_reg_operand r)
  (match_operand 2 spu_reg_operand r)
  (match_operand 3 spu_reg_operand 0)] UNSPEC_SFX))]
!   operands != NULL
sfx\t%0,%2,%1)
  
  (define_insn subti3
*** selb\t%0,%4,%0,%3
*** 4018,4024 
  (define_insn extend_comparemode
[(set (match_operand:ALL 0 spu_reg_operand =r)
(unspec:ALL [(match_operand 1 spu_reg_operand r)] 
UNSPEC_EXTEND_CMP))]
!   operands
fsm\t%0,%1
[(set_attr type shuf)])
  
--- 4018,4024 
  (define_insn extend_comparemode
[(set (match_operand:ALL 0 spu_reg_operand =r)
(unspec:ALL [(match_operand 1 spu_reg_operand r)] 
UNSPEC_EXTEND_CMP))]
!   operands != NULL
fsm\t%0,%1
[(set_attr type shuf)])
  
*** selb\t%0,%4,%0,%3
*** 4391,4397 
(unspec [(match_operand 1 spu_reg_operand r)
 (match_operand 2 spu_reg_operand r)
 (match_operand:TI 3 spu_reg_operand r)] UNSPEC_SHUFB))]
!   operands
shufb\t%0,%1,%2,%3
[(set_attr type shuf)])
  
--- 4391,4397 

Re: [asan] Instrument STRING_CSTs

2012-12-10 Thread Dodji Seketeli
Jakub Jelinek ja...@redhat.com writes:

 2012-12-05  Jakub Jelinek  ja...@redhat.com

   * asan.c (asan_init_shadow_ptr_types): Move earlier in the file.
   Call initialize_sanitizer_builtins at the end.
   (asan_pp_string): Use TREE_TYPE (shadow_ptr_types[0])
   as character type instead of char_type_node.
   (asan_emit_stack_protection): Call asan_init_shadow_ptr_types
   if shadow_ptr_types isn't initialized.
   (asan_protect_global): Return true for STRING_CSTs except those
   created by asan_pp_string.
   (count_string_csts, add_string_csts): New functions.
   (struct asan_add_string_csts_data): New type.
   (asan_finish_file): Clear flag_asan at the beginning, restore at the
   end.  Traverse constant_pool_htab () to look for protected
   STRING_CSTs.  Don't call initialize_sanitizer_builtins,
   instead call asan_init_shadow_ptr_types if shadow_ptr_types isn't
   initialized yet.
   (asan_instrument): Don't call initialize_sanitizer_builtins.
   * varasm.c (output_constant_def_contents): If STRING_CST should be
   asan protected, align it sufficiently and emit padding after it.
   (categorize_decl_for_section): If flag_asan, don't put STRING_CSTs
   that should be asan protected into mergeable sections.  For
   -fmerge-all-constants, ignore it for -fmudflap or if decl is
   asan protected.

This seems OK to me, thanks.

-- 
Dodji


[patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features

2012-12-10 Thread Matthias Klose
During bootstrap some things are built which are not required for the bootstrap:

 - multilib libraries
 - libstdc++ debug library, when configured with --enable-libstdcxx-debug
 - libstdc++ precompiled header files

The attached patch disables building these during the bootstrap stages. The
additional dependencies on all-target-libgcc are necessary for multilib'd
builds, or else the configury bails out finding the wrong libgcc. I can't see a
way to add these dependencies for the multilib enabled build only.

Ok for the trunk?

  Matthias
	* Makefile.tpl (configure-stage[+id+]-[+prefix+][+module+]): Pass
	bootstrap_configure_flags.
	* Makefile.def (target_modules): Pass bootstrap_configure_flags
	for libgcc, libgomp, libstdc++-v3.
	(dependencies): For all target libraries, depend on all-target-libgcc.
	
--- Makefile.tpl~	2012-11-29 17:44:18.0 +0100
+++ Makefile.tpl	2012-12-10 12:03:00.716683469 +0100
@@ -1060,7 +1060,9 @@
 	  --target=[+target_alias+] $${srcdiroption} [+ IF prev +]\
 	  --with-build-libsubdir=$(HOST_SUBDIR) [+ ENDIF prev +]\
 	  $(STAGE[+id+]_CONFIGURE_FLAGS)[+ IF extra_configure_flags +] \
-	  [+extra_configure_flags+][+ ENDIF extra_configure_flags +]
+	  [+extra_configure_flags+][+ ENDIF extra_configure_flags +] \
+	  [+ IF bootstrap_configure_flags +][+bootstrap_configure_flags+] \
+	  [+ ENDIF bootstrap_configure_flags +]
 @endif [+prefix+][+module+]-bootstrap
 [+ ENDFOR bootstrap_stage +]
 [+ ENDIF bootstrap +]
--- Makefile.def~	2012-12-01 22:34:06.0 +0100
+++ Makefile.def	2012-12-10 12:51:08.444647333 +0100
@@ -117,12 +117,14 @@
 target_modules = { module= libstdc++-v3;
 		   bootstrap=true;
 		   lib_path=src/.libs;
-		   raw_cxx=true; };
+		   raw_cxx=true;
+		   bootstrap_configure_flags='--disable-multilib --disable-libstdcxx-debug --disable-libstdcxx-pch'; };
 target_modules = { module= libmudflap; lib_path=.libs; };
 target_modules = { module= libsanitizer; lib_path=.libs; };
 target_modules = { module= libssp; lib_path=.libs; };
 target_modules = { module= newlib; };
-target_modules = { module= libgcc; bootstrap=true; no_check=true; };
+target_modules = { module= libgcc; bootstrap=true; no_check=true;
+	   	   bootstrap_configure_flags='--disable-multilib'; };
 target_modules = { module= libbacktrace; };
 target_modules = { module= libquadmath; };
 target_modules = { module= libgfortran; };
@@ -142,7 +144,8 @@
 target_modules = { module= boehm-gc; };
 target_modules = { module= rda; };
 target_modules = { module= libada; };
-target_modules = { module= libgomp; bootstrap= true; lib_path=.libs; };
+target_modules = { module= libgomp; bootstrap= true; lib_path=.libs;
+	   	   bootstrap_configure_flags='--disable-multilib'; };
 target_modules = { module= libitm; lib_path=.libs; };
 target_modules = { module= libatomic; lib_path=.libs; };
 
@@ -504,6 +507,19 @@
 dependencies = { module=configure-target-libobjc; on=configure-target-boehm-gc; };
 dependencies = { module=all-target-libobjc; on=all-target-boehm-gc; };
 dependencies = { module=configure-target-libstdc++-v3; on=configure-target-libgomp; };
+dependencies = { module=configure-target-libada; on=all-target-libgcc; };
+dependencies = { module=configure-target-libatomic; on=all-target-libgcc; };
+dependencies = { module=configure-target-libbacktrace; on=all-target-libgcc; };
+dependencies = { module=configure-target-libdecnumber; on=all-target-libgcc; };
+dependencies = { module=configure-target-libffi; on=all-target-libgcc; };
+dependencies = { module=configure-target-libgfortran; on=all-target-libgcc; };
+dependencies = { module=configure-target-libgomp; on=all-target-libgcc; };
+dependencies = { module=configure-target-libitm; on=all-target-libgcc; };
+dependencies = { module=configure-target-libmudflap; on=all-target-libgcc; };
+dependencies = { module=configure-target-libquadmath; on=all-target-libgcc; };
+dependencies = { module=configure-target-libssp; on=all-target-libgcc; };
+dependencies = { module=configure-target-libstdc++-v3; on=all-target-libgcc; };
+dependencies = { module=configure-target-zlib; on=all-target-libgcc; };
 dependencies = { module=configure-target-libsanitizer; on=all-target-libstdc++-v3; };
 // parallel_list.o and parallel_settings.o depend on omp.h, which is
 // generated by the libgomp configure.  Unfortunately, due to the use of


Re: [patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features

2012-12-10 Thread Andrew Pinski
On Mon, Dec 10, 2012 at 4:16 AM, Matthias Klose d...@ubuntu.com wrote:
 During bootstrap some things are built which are not required for the 
 bootstrap:

  - multilib libraries
  - libstdc++ debug library, when configured with --enable-libstdcxx-debug
  - libstdc++ precompiled header files

 The attached patch disables building these during the bootstrap stages. The
 additional dependencies on all-target-libgcc are necessary for multilib'd
 builds, or else the configury bails out finding the wrong libgcc. I can't see 
 a
 way to add these dependencies for the multilib enabled build only.

 Ok for the trunk?

Does this work when someone supplies BOOT_CFLAGS a multlib option like
say -m32 ?

Thanks,
Andrew Pinski


[asan, committed] Sync asan_test.cc from upstream

2012-12-10 Thread Jakub Jelinek
Hi!

I've committed as obvious this change to sync the test from upstream
to avoid one unnecessary FAIL.

2012-12-10  Jakub Jelinek  ja...@redhat.com

* g++.dg/asan/asan_test.cc: Sync from upstream.
* g++.dg/asan/asan_test_utils.h: Likewise.

--- gcc/testsuite/g++.dg/asan/asan_test.cc  2012-12-03 12:44:13.828811869 
+0100
+++ gcc/testsuite/g++.dg/asan/asan_test.cc  2012-12-05 19:06:52.288213731 
+0100
@@ -1604,7 +1606,7 @@ NOINLINE static int LargeFunction(bool d
 TEST(AddressSanitizer, DISABLED_LargeFunctionSymbolizeTest) {
   int failing_line = LargeFunction(false);
   char expected_warning[128];
-  sprintf(expected_warning, LargeFunction.*asan_test.cc:%d, failing_line);
+  sprintf(expected_warning, LargeFunction.*asan_test.*:%d, failing_line);
   EXPECT_DEATH(LargeFunction(true), expected_warning);
 }
 
@@ -1748,7 +1750,7 @@ TEST(AddressSanitizer, FileNameInGlobalR
   static char zoo[10];
   const char *p = Ident(zoo);
   // The file name should be present in the report.
-  EXPECT_DEATH(Ident(p[15]), zoo.*asan_test.cc);
+  EXPECT_DEATH(Ident(p[15]), zoo.*asan_test.);
 }
 
 int *ReturnsPointerToALocalObject() {
--- gcc/testsuite/g++.dg/asan/asan_test_utils.h 2012-12-03 12:44:48.868608115 
+0100
+++ gcc/testsuite/g++.dg/asan/asan_test_utils.h 2012-12-05 19:06:52.308213631 
+0100
@@ -53,7 +55,7 @@ typedef __int64  int64_t;
 
 // Make the compiler thinks that something is going on there.
 inline void break_optimization(void *arg) {
-  __asm__ __volatile__ ( : : r (arg) : memory);
+  __asm__ __volatile__( : : r (arg) : memory);
 }
 
 // This function returns its parameter but in such a way that compiler

Jakub


Re: Fix ICE on loop over constant vector at -O

2012-12-10 Thread Richard Biener
On Mon, Dec 10, 2012 at 10:55 AM, Eric Botcazou ebotca...@adacore.com wrote:
 Well ... I would have expected that we'd have folded the CONST_DECL to
 its DECL_INITIAL.  At least that is what we do for all other CONST_DECLs.
 The only way CONST_DECLs should appear in the IL (after some optimization
 of course) is when you take their address.

 That's what (essentially) happens here.  The CONST_DECL is wrapped up in a
 VIEW_CONVERT_EXPR to array type and a component with non-constant index is
 extracted from it.

Ah, ok ...

 So - if you can burn some extra cycles to figure out why it's not
 replaced by its DECL_INITIAL ...?

 We specifically prevent that in gigi because it will need to be spilled to
 memory given the above access pattern, so I don't really see the problem.
 Here's the access in .optimized:

 _38 = MEM[symbol: pkg__zero_unit, index: ivtmp.38_27, step: 4, offset: -4B];

... so if would really be a pessimization doing that.  Of course handling
CONST_DECL in for_each_index is indeed obvious - I just was curios if
it was a missed-optimization opportunity as well.

Thanks for clarifying,
Richard.

 --
 Eric Botcazou


Re: [PATCH] SPU: Fix build failure on 64 bit hosts

2012-12-10 Thread Richard Biener
On Mon, Dec 10, 2012 at 12:31 PM, Andreas Krebbel
kreb...@linux.vnet.ibm.com wrote:
 Hi,

 building an SPU compiler on a 64 bit host system currently fails with:

 spu.md:4394: error: cast from ‘rtx_def**’ to ‘int’ loses precision

 In the SPU backend several patterns mention the operands array in the
 insn condition in order to prevent a warning about missing modes to be
 issued.  Interpreting the term operands as condition fails when it
 is evaluated on a 64 bit host.  Turning it into a comparison fixes
 this for me.

 Ok to apply?

Looks obvious to me.  It even looks less weird this way.

Thanks,
Richard.

 Bye,

 -Andreas-


 2012-12-10  Andreas Krebbel  andreas.kreb...@de.ibm.com

 * config/spu/spu.md: Replace operands with operands != NULL in
 insn conditions.

 ---
  gcc/config/spu/spu.md |   16 
  1 file changed, 16 modifications(!)

 Index: gcc/config/spu/spu.md
 ===
 *** gcc/config/spu/spu.md.orig
 --- gcc/config/spu/spu.md
 ***
 *** 1066,1072 
 [(set (match_operand:CBOP 0 spu_reg_operand =r)
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)] UNSPEC_CG))]
 !   operands
 cg\t%0,%1,%2)

   (define_insn cgx_mode
 --- 1066,1072 
 [(set (match_operand:CBOP 0 spu_reg_operand =r)
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)] UNSPEC_CG))]
 !   operands != NULL
 cg\t%0,%1,%2)

   (define_insn cgx_mode
 ***
 *** 1074,1080 
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)
   (match_operand 3 spu_reg_operand 0)] UNSPEC_CGX))]
 !   operands
 cgx\t%0,%1,%2)

   (define_insn addx_mode
 --- 1074,1080 
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)
   (match_operand 3 spu_reg_operand 0)] UNSPEC_CGX))]
 !   operands != NULL
 cgx\t%0,%1,%2)

   (define_insn addx_mode
 ***
 *** 1082,1088 
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)
   (match_operand 3 spu_reg_operand 0)] UNSPEC_ADDX))]
 !   operands
 addx\t%0,%1,%2)


 --- 1082,1088 
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)
   (match_operand 3 spu_reg_operand 0)] UNSPEC_ADDX))]
 !   operands != NULL
 addx\t%0,%1,%2)


 ***
 *** 1189,1195 
 [(set (match_operand:CBOP 0 spu_reg_operand =r)
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)] UNSPEC_BG))]
 !   operands
 bg\t%0,%2,%1)

   (define_insn bgx_mode
 --- 1189,1195 
 [(set (match_operand:CBOP 0 spu_reg_operand =r)
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)] UNSPEC_BG))]
 !   operands != NULL
 bg\t%0,%2,%1)

   (define_insn bgx_mode
 ***
 *** 1197,1203 
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)
   (match_operand 3 spu_reg_operand 0)] UNSPEC_BGX))]
 !   operands
 bgx\t%0,%2,%1)

   (define_insn sfx_mode
 --- 1197,1203 
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)
   (match_operand 3 spu_reg_operand 0)] UNSPEC_BGX))]
 !   operands != NULL
 bgx\t%0,%2,%1)

   (define_insn sfx_mode
 ***
 *** 1205,1211 
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)
   (match_operand 3 spu_reg_operand 0)] UNSPEC_SFX))]
 !   operands
 sfx\t%0,%2,%1)

   (define_insn subti3
 --- 1205,1211 
 (unspec:CBOP [(match_operand 1 spu_reg_operand r)
   (match_operand 2 spu_reg_operand r)
   (match_operand 3 spu_reg_operand 0)] UNSPEC_SFX))]
 !   operands != NULL
 sfx\t%0,%2,%1)

   (define_insn subti3
 *** selb\t%0,%4,%0,%3
 *** 4018,4024 
   (define_insn extend_comparemode
 [(set (match_operand:ALL 0 spu_reg_operand =r)
 (unspec:ALL [(match_operand 1 spu_reg_operand r)] 
 UNSPEC_EXTEND_CMP))]
 !   operands
 fsm\t%0,%1
 [(set_attr type shuf)])

 --- 4018,4024 
   (define_insn extend_comparemode
 [(set (match_operand:ALL 0 spu_reg_operand =r)
 (unspec:ALL [(match_operand 1 spu_reg_operand r)] 
 UNSPEC_EXTEND_CMP))]
 !   operands != NULL
 fsm\t%0,%1
 [(set_attr type shuf)])

 *** selb\t%0,%4,%0,%3
 *** 4391,4397 
 (unspec 

Re: [patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features

2012-12-10 Thread Richard Biener
On Mon, Dec 10, 2012 at 1:18 PM, Andrew Pinski pins...@gmail.com wrote:
 On Mon, Dec 10, 2012 at 4:16 AM, Matthias Klose d...@ubuntu.com wrote:
 During bootstrap some things are built which are not required for the 
 bootstrap:

  - multilib libraries
  - libstdc++ debug library, when configured with --enable-libstdcxx-debug
  - libstdc++ precompiled header files

 The attached patch disables building these during the bootstrap stages. The
 additional dependencies on all-target-libgcc are necessary for multilib'd
 builds, or else the configury bails out finding the wrong libgcc. I can't 
 see a
 way to add these dependencies for the multilib enabled build only.

 Ok for the trunk?

 Does this work when someone supplies BOOT_CFLAGS a multlib option like
 say -m32 ?

I don't think that was ever supported without adjusting the target/host triplet
to i686-linux for example.  Was it?

Richard.

 Thanks,
 Andrew Pinski


Re: [patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features

2012-12-10 Thread Matthias Klose
Am 10.12.2012 13:16, schrieb Matthias Klose:
 During bootstrap some things are built which are not required for the 
 bootstrap:
 
  - multilib libraries
  - libstdc++ debug library, when configured with --enable-libstdcxx-debug
  - libstdc++ precompiled header files
 
 The attached patch disables building these during the bootstrap stages. The
 additional dependencies on all-target-libgcc are necessary for multilib'd
 builds, or else the configury bails out finding the wrong libgcc. I can't see 
 a
 way to add these dependencies for the multilib enabled build only.

Here is a reduced version which keeps building the multilibs, maybe better
suited for stage3.

  Matthias


Index: Makefile.tpl
===
--- Makefile.tpl	(Revision 194357)
+++ Makefile.tpl	(Arbeitskopie)
@@ -1060,7 +1060,9 @@
 	  --target=[+target_alias+] $${srcdiroption} [+ IF prev +]\
 	  --with-build-libsubdir=$(HOST_SUBDIR) [+ ENDIF prev +]\
 	  $(STAGE[+id+]_CONFIGURE_FLAGS)[+ IF extra_configure_flags +] \
-	  [+extra_configure_flags+][+ ENDIF extra_configure_flags +]
+	  [+extra_configure_flags+][+ ENDIF extra_configure_flags +] \
+	  [+ IF bootstrap_configure_flags +][+bootstrap_configure_flags+] \
+	  [+ ENDIF bootstrap_configure_flags +]
 @endif [+prefix+][+module+]-bootstrap
 [+ ENDFOR bootstrap_stage +]
 [+ ENDIF bootstrap +]
Index: Makefile.def
===
--- Makefile.def	(Revision 194357)
+++ Makefile.def	(Arbeitskopie)
@@ -117,7 +117,8 @@
 target_modules = { module= libstdc++-v3;
 		   bootstrap=true;
 		   lib_path=src/.libs;
-		   raw_cxx=true; };
+		   raw_cxx=true;
+		   bootstrap_configure_flags='--disable-libstdcxx-debug --disable-libstdcxx-pch'; };
 target_modules = { module= libmudflap; lib_path=.libs; };
 target_modules = { module= libsanitizer; lib_path=.libs; };
 target_modules = { module= libssp; lib_path=.libs; };


[PATCH] Fix PR55107

2012-12-10 Thread Richard Biener

This fixes PR55107 - the way we dealt with fully redundant values
found by PRE phi-translation breaks existing SETs, so don't special
case it in a hacky way but instead create a simple assignment.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2012-12-10  Richard Biener  rguent...@suse.de

PR tree-optimization/55107
* tree-ssa-pre.c (struct pre_stats): Remove constified field.
(bitmap_set_replace_value): Add gcc_unreachable.
(do_regular_insertion): Re-write all_same handling.  Insert
an assignment instead of a PHI in this case.
(eliminate_bb): Record availability also for SSA names defined
by a constant.
(do_pre): Do not record constified events.
(execute_fre): Likewise.

* gcc.dg/torture/pr55107.c: New testcase.
* gcc.dg/tree-ssa/ssa-pre-5.c: Adjust.

Index: gcc/tree-ssa-pre.c
===
*** gcc/tree-ssa-pre.c  (revision 194345)
--- gcc/tree-ssa-pre.c  (working copy)
*** static struct
*** 446,455 
  
/* The number of new PHI nodes added by PRE.  */
int phis;
- 
-   /* The number of values found constant.  */
-   int constified;
- 
  } pre_stats;
  
  static bool do_partial_partial;
--- 446,451 
*** bitmap_set_replace_value (bitmap_set_t s
*** 867,872 
--- 863,870 
  return;
}
  }
+ 
+   gcc_unreachable ();
  }
  
  /* Return true if two bitmap sets are equal.  */
*** do_regular_insertion (basic_block block,
*** 3325,3331 
  
FOR_EACH_VEC_ELT (exprs, i, expr)
  {
!   if (expr-kind != NAME)
{
  unsigned int val;
  bool by_some = false;
--- 3323,3330 
  
FOR_EACH_VEC_ELT (exprs, i, expr)
  {
!   if (expr-kind == NARY
! || expr-kind == REFERENCE)
{
  unsigned int val;
  bool by_some = false;
*** do_regular_insertion (basic_block block,
*** 3435,3469 
  /* If all edges produce the same value and that value is
 an invariant, then the PHI has the same value on all
 edges.  Note this.  */
! else if (!cant_insert  all_same  eprime
!   (edoubleprime-kind == CONSTANT
!  || edoubleprime-kind == NAME)
!   !value_id_constant_p (val))
{
! unsigned int j;
! bitmap_iterator bi;
! bitmap exprset = value_expressions[val];
! 
! unsigned int new_val = get_expr_value_id (edoubleprime);
! EXECUTE_IF_SET_IN_BITMAP (exprset, 0, j, bi)
!   {
! pre_expr expr = expression_for_id (j);
  
! if (expr-kind == NAME)
!   {
! vn_ssa_aux_t info = VN_INFO (PRE_EXPR_NAME (expr));
! /* Just reset the value id and valnum so it is
!the same as the constant we have discovered.  */
! if (edoubleprime-kind == CONSTANT)
!   {
! info-valnum = PRE_EXPR_CONSTANT (edoubleprime);
! pre_stats.constified++;
!   }
! else
!   info-valnum = VN_INFO (PRE_EXPR_NAME 
(edoubleprime))-valnum;
! info-value_id = new_val;
!   }
!   }
}
}
  }
--- 3434,3461 
  /* If all edges produce the same value and that value is
 an invariant, then the PHI has the same value on all
 edges.  Note this.  */
! else if (!cant_insert  all_same)
{
! gcc_assert (edoubleprime-kind == CONSTANT
! || edoubleprime-kind == NAME);
  
! tree temp = make_temp_ssa_name (get_expr_type (expr),
! NULL, pretmp);
! gimple assign = gimple_build_assign (temp,
!  edoubleprime-kind == 
CONSTANT ? PRE_EXPR_CONSTANT (edoubleprime) : PRE_EXPR_NAME (edoubleprime));
! gimple_stmt_iterator gsi = gsi_after_labels (block);
! gsi_insert_before (gsi, assign, GSI_NEW_STMT);
! 
! gimple_set_plf (assign, NECESSARY, false);
! VN_INFO_GET (temp)-value_id = val;
! VN_INFO (temp)-valnum = sccvn_valnum_from_value_id (val);
! if (VN_INFO (temp)-valnum == NULL_TREE)
!   VN_INFO (temp)-valnum = temp;
! bitmap_set_bit (inserted_exprs, SSA_NAME_VERSION (temp));
! pre_expr newe = get_or_alloc_expr_for_name (temp);
! add_to_value (val, newe);
! bitmap_value_replace_in_set (AVAIL_OUT (block), newe);
! bitmap_insert_into_set (NEW_SETS (block), newe);
}
}
  }
*** do_partial_partial_insertion 

Re: [patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features

2012-12-10 Thread H.J. Lu
On Mon, Dec 10, 2012 at 5:53 AM, Matthias Klose d...@ubuntu.com wrote:
 Am 10.12.2012 13:16, schrieb Matthias Klose:
 During bootstrap some things are built which are not required for the 
 bootstrap:

  - multilib libraries
  - libstdc++ debug library, when configured with --enable-libstdcxx-debug
  - libstdc++ precompiled header files

 The attached patch disables building these during the bootstrap stages. The
 additional dependencies on all-target-libgcc are necessary for multilib'd
 builds, or else the configury bails out finding the wrong libgcc. I can't 
 see a
 way to add these dependencies for the multilib enabled build only.

 Here is a reduced version which keeps building the multilibs, maybe better
 suited for stage3.


Can I still use -m32 with stage1 and stage2 compilers on
Linux/x86-64?


-- 
H.J.


Re: PATCH: PR lto/55466: Revision 191466 destroyed DWARF debug info

2012-12-10 Thread H.J. Lu
On Mon, Dec 10, 2012 at 1:09 AM, Richard Biener
richard.guent...@gmail.com wrote:
 On Fri, Dec 7, 2012 at 11:59 PM, H.J. Lu hongjiu...@intel.com wrote:
 Hi,

 Since revision 191466, LTO no longer maintains its own symbol table and
 it uses varpool for variables instead.  As the result, debug info on
 variables is lost when GCC is configured with

 --enable-bootstrap --with-build-config=bootstrap-lto

 This patch record the global variables if WPA isn't enabled.  It
 works when GCC is configured with

 --enable-bootstrap --with-build-config=bootstrap-lto 
 --enable-languages=c,c++,fortran,java,lto,objc,obj-c++

 However, when go is added, I got

 lto1: internal compiler error: in add_AT_specification, at
 dwarf2out.c:3985
 0x629ad9 add_AT_specification
 /export/gnu/import/git/gcc/gcc/dwarf2out.c:3985
 0x64dabb gen_variable_die
 /export/gnu/import/git/gcc/gcc/dwarf2out.c:18327
 0x65336b gen_decl_die
 /export/gnu/import/git/gcc/gcc/dwarf2out.c:20033
 0x653fcd dwarf2out_decl(tree_node*)
 /export/gnu/import/git/gcc/gcc/dwarf2out.c:20348
 0x6535f9 dwarf2out_global_decl
 /export/gnu/import/git/gcc/gcc/dwarf2out.c:20083
 0x997703 emit_debug_global_declarations(tree_node**, int)
 /export/gnu/import/git/gcc/gcc/toplev.c:530
 0x521aaa lto_write_globals
 /export/gnu/import/git/gcc/gcc/lto/lto-lang.c:1067
 Please submit a full bug report,
 with preprocessed source if appropriate.
 Please include the complete backtrace with any bug report.
 See http://gcc.gnu.org/bugs.html for instructions.
 make[6]: *** [/tmp/cc3yYR7d.ltrans4.ltrans.o] Error 1
 lto-wrapper: make returned 2 exit status
 /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed
 collect2: error: ld returned 1 exit status
 make[5]: *** [go1] Error 1

 This is latent without my patch since no DWARF info on varaibles are
  generated.  OK to install?

 Thanks.


 H.J.
 ---
 2012-12-07  H.J. Lu  hongjiu...@intel.com

 PR lto/55466
 * lto-symtab.c (lto_symtab_merge_decls_1): Don't record
 the prevailing variable.
 * lto.c (lto_main): Record the global variables if WPA isn't
 enabled.

 diff --git a/gcc/lto-symtab.c b/gcc/lto-symtab.c
 index 0b0cdac..295fd37 100644
 --- a/gcc/lto-symtab.c
 +++ b/gcc/lto-symtab.c
 @@ -443,10 +443,6 @@ lto_symtab_merge_decls_1 (symtab_node first)

symtab_prevail_in_asm_name_hash (prevailing);

 -  /* Record the prevailing variable.  */
 -  if (TREE_CODE (prevailing-symbol.decl) == VAR_DECL)
 -vec_safe_push (lto_global_var_decls, prevailing-symbol.decl);
 -

 As this is not necessary, the push in lto.c:lto_register_var_decl_in_symtab
 for statics should not be necessary either (we even call
 rest_of_decl_compilation
 there).

 Ok with that push removed as well.

Done.

 Please make sure to file a bugreport for the go LTO bootstrap issue.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55640

-- 
H.J.


[PATCH] Fix PR55079

2012-12-10 Thread Richard Biener

This improves VRP so that two of the three (the remaining one invalid
IMHO) spurious array-bound warnings in PR55079 no longer appear.
With the patch we now properly handle

  MIN_EXPR [1, 6], VARYING

and register asserts for i_2 in

  i_2 = i_1 + 1;
  if (i_1 != 0)

which is a common pattern from tests of post-modify expressions.

For gcc.dg/tree-ssa/ssa-pre-1.c this is too fancy and thus I needed
to adjust the testcase to avoid VRP being too clever.

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

Richard.

2012-12-10  Richard Biener  rguent...@suse.de

PR tree-optimization/55079
* tree-vrp.c (extract_range_from_binary_expr_1): Handle MAX/MIN_EXPR
for more cases.
(register_edge_assert_for_2): Register asserts for post-in/decrement
tests.
(check_array_ref): Dump what expression we emit array bound
warnings for.
(search_for_addr_array): Likewise.

* gcc.dg/Warray-bounds-9.c: New testcase.
* gcc.dg/Warray-bounds-10.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-1.c: Adjust.

Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c  (revision 194358)
--- gcc/tree-vrp.c  (working copy)
*** extract_range_from_binary_expr_1 (value_
*** 2349,2354 
--- 2349,2356 
 code != EXACT_DIV_EXPR
 code != ROUND_DIV_EXPR
 code != TRUNC_MOD_EXPR
+code != MIN_EXPR
+code != MAX_EXPR
 (vr0.type == VR_VARYING
  || vr1.type == VR_VARYING
  || vr0.type != vr1.type
*** extract_range_from_binary_expr_1 (value_
*** 2602,2622 
else if (code == MIN_EXPR
   || code == MAX_EXPR)
  {
!   if (vr0.type == VR_ANTI_RANGE)
{
! /* For MIN_EXPR and MAX_EXPR with two VR_ANTI_RANGEs,
!the resulting VR_ANTI_RANGE is the same - intersection
!of the two ranges.  */
! min = vrp_int_const_binop (MAX_EXPR, vr0.min, vr1.min);
! max = vrp_int_const_binop (MIN_EXPR, vr0.max, vr1.max);
}
else
{
! /* For operations that make the resulting range directly
!proportional to the original ranges, apply the operation to
!the same end of each range.  */
! min = vrp_int_const_binop (code, vr0.min, vr1.min);
! max = vrp_int_const_binop (code, vr0.max, vr1.max);
}
  }
else if (code == MULT_EXPR)
--- 2604,2652 
else if (code == MIN_EXPR
   || code == MAX_EXPR)
  {
!   if (vr0.type == VR_RANGE
!  !symbolic_range_p (vr0))
{
! type = VR_RANGE;
! if (vr1.type == VR_RANGE
!  !symbolic_range_p (vr1))
!   {
! /* For operations that make the resulting range directly
!proportional to the original ranges, apply the operation to
!the same end of each range.  */
! min = vrp_int_const_binop (code, vr0.min, vr1.min);
! max = vrp_int_const_binop (code, vr0.max, vr1.max);
!   }
! else if (code == MIN_EXPR)
!   {
! min = vrp_val_min (expr_type);
! max = vr0.max;
!   }
! else if (code == MAX_EXPR)
!   {
! min = vr0.min;
! max = vrp_val_max (expr_type);
!   }
!   }
!   else if (vr1.type == VR_RANGE
!   !symbolic_range_p (vr1))
!   {
! type = VR_RANGE;
! if (code == MIN_EXPR)
!   {
! min = vrp_val_min (expr_type);
! max = vr1.max;
!   }
! else if (code == MAX_EXPR)
!   {
! min = vr1.min;
! max = vrp_val_max (expr_type);
!   }
}
else
{
! set_value_range_to_varying (vr);
! return;
}
  }
else if (code == MULT_EXPR)
*** register_edge_assert_for_2 (tree name, e
*** 4707,4712 
--- 4737,4781 
}
  }
  
+   /* In the case of post-in/decrement tests like if (i++) ... and uses
+  of the in/decremented value on the edge the extra name we want to
+  assert for is not on the def chain of the name compared.  Instead
+  it is in the set of use stmts.  */
+   if ((comp_code == NE_EXPR
+|| comp_code == EQ_EXPR)
+TREE_CODE (val) == INTEGER_CST)
+ {
+   imm_use_iterator ui;
+   gimple use_stmt;
+   FOR_EACH_IMM_USE_STMT (use_stmt, ui, name)
+   {
+ /* Cut off to use-stmts that are in the predecessor.  */
+ if (gimple_bb (use_stmt) != e-src)
+   continue;
+ 
+ if (!is_gimple_assign (use_stmt))
+   continue;
+ 
+ enum tree_code code = gimple_assign_rhs_code (use_stmt);
+ if (code != PLUS_EXPR
+  code != MINUS_EXPR)
+   continue;
+ 
+ tree cst = gimple_assign_rhs2 (use_stmt);
+ if (TREE_CODE (cst) != 

Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread David Edelsohn
On Mon, Dec 10, 2012 at 4:22 AM, Janus Weil ja...@gcc.gnu.org wrote:
 2012/12/10 David Edelsohn dje@gmail.com:
 There has been no progress on this bug for over two months.  I have
 opened PR fortran/55636.  This must be fixed before GCC 4.8 ships.

 Thanks for pinging, David. I almost forgot about it ...

 Here is a re-diffed version of my previous patch. I'd be grateful for
 comments. In particular: Does it fix all the problems on AIX? (For
 more open questions, see below.)

Janus,

Anything that changes the mangling of the symbols referenced in
fortran/trans-decl.c will fix the problem on AIX.

Thanks, David


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread David Edelsohn
On Mon, Dec 10, 2012 at 5:05 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
  For C and C++, identifiers beginning with underscore and upper case
  letter or with two underscores are reserve to the implementation.

 See the previous discussion in this thread ...

 That's true, but the implementation isn't just GCC, it is also C libraries
 which aren't provided by GCC.  Including a character (if possible) that
 will make it unaccessible from C/C++ is desirable.  And, not changing the
 names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
 in the debug info from time to time, so making them unnecessarily larger
 results in .debug_info size increases.

An earlier suggestion was _F. .  Maybe gfortran.h should follow the
same logic as gcc/defaults.h and gcc/cp/cp-tree.h:

#ifndef NO_DOT_IN_LABEL
_F.
#else
#ifndef NO_DOLLAR_IN_LABEL
_F$
#else
_F_
#endif
#endif

Thanks, David


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread Jakub Jelinek
On Mon, Dec 10, 2012 at 10:49:57AM -0500, David Edelsohn wrote:
 On Mon, Dec 10, 2012 at 5:05 AM, Jakub Jelinek ja...@redhat.com wrote:
  On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
   For C and C++, identifiers beginning with underscore and upper case
   letter or with two underscores are reserve to the implementation.
 
  See the previous discussion in this thread ...
 
  That's true, but the implementation isn't just GCC, it is also C libraries
  which aren't provided by GCC.  Including a character (if possible) that
  will make it unaccessible from C/C++ is desirable.  And, not changing the
  names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
  in the debug info from time to time, so making them unnecessarily larger
  results in .debug_info size increases.
 
 An earlier suggestion was _F. .  Maybe gfortran.h should follow the
 same logic as gcc/defaults.h and gcc/cp/cp-tree.h:
 
 #ifndef NO_DOT_IN_LABEL
 _F.
 #else
 #ifndef NO_DOLLAR_IN_LABEL
 _F$
 #else
 _F_
 #endif
 #endif

Sure, we my
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636
comment.

Jakub


[google/gcc-4_7] Backport r193747 to using working set for bb hotness (issue6907063)

2012-12-10 Thread Teresa Johnson
This is a backport of r193747 to use the working set from the profile summary
to determine the bb hot count threshold.

Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for google 4_7 branch?

Thanks,
Teresa

2012-12-10  Teresa Johnson  tejohn...@google.com

Backport r193747 from trunk:

2012-11-22  Teresa Johnson  tejohn...@google.com
Jan Hubicka  j...@suse.cz

* predict.c (maybe_hot_count_p): Use threshold from profiled working
set instead of hard limit.
(cgraph_maybe_hot_edge_p): Invoke maybe_hot_count_p() instead of
directly checking limit.
* params.def (HOT_BB_COUNT_FRACTION): Remove.
(HOT_BB_COUNT_WS_PERMILLE): New parameter.
* doc/invoke.texi (hot-bb-count-fraction): Remove.
(hot-bb-count-ws-permille): Document.


Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 194315)
+++ doc/invoke.texi (working copy)
@@ -9307,9 +9307,9 @@ ftree-vect-loop-version for more information.
 The maximum number of iterations of a loop the brute force algorithm
 for analysis of # of iterations of the loop tries to evaluate.
 
-@item hot-bb-count-fraction
-Select fraction of the maximal count of repetitions of basic block in program
-given basic block needs to have to be considered hot.
+@item hot-bb-count-ws-permille
+A basic block profile count is considered hot if it contributes to 
+the given permillage (i.e. 0...1000) of the entire profiled execution.
 
 @item hot-bb-frequency-fraction
 Select fraction of the entry block frequency of executions of basic block in
Index: predict.c
===
--- predict.c   (revision 194315)
+++ predict.c   (working copy)
@@ -137,13 +137,20 @@ maybe_hot_frequency_p (int freq)
 bool
 maybe_hot_count_p (gcov_type count)
 {
+  gcov_working_set_t *ws = NULL;
+  static gcov_type min_count = -1;
   if (!profile_info)
 return false;
   /* Code executed at most once is not hot.  */
   if (profile_info-runs = count)
 return false;
-  return (count
-  profile_info-sum_max / PARAM_VALUE (HOT_BB_COUNT_FRACTION));
+  if (min_count == -1)
+{
+  ws = find_working_set (PARAM_VALUE (HOT_BB_COUNT_WS_PERMILLE));
+  gcc_assert (ws);
+  min_count = ws-min_counter;
+}
+  return (count = min_count);
 }
 
 /* Return true in case BB can be CPU intensive and should be optimized
@@ -163,8 +170,7 @@ bool
 cgraph_maybe_hot_edge_p (struct cgraph_edge *edge)
 {
   if (profile_info  flag_branch_probabilities
-   (edge-count
- = profile_info-sum_max / PARAM_VALUE (HOT_BB_COUNT_FRACTION)))
+   !maybe_hot_count_p (edge-count))
 return false;
   if (edge-caller-frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED
   || edge-callee-frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED)
Index: params.def
===
--- params.def  (revision 194315)
+++ params.def  (working copy)
@@ -424,10 +424,11 @@ DEFPARAM(PARAM_SMS_LOOP_AVERAGE_COUNT_THRESHOLD,
 A threshold on the average loop count considered by the swing modulo 
scheduler,
 0, 0, 0)
 
-DEFPARAM(HOT_BB_COUNT_FRACTION,
-hot-bb-count-fraction,
-Select fraction of the maximal count of repetitions of basic block in 
program given basic block needs to have to be considered hot,
-6, 0, 0)
+DEFPARAM(HOT_BB_COUNT_WS_PERMILLE,
+hot-bb-count-ws-permille,
+ A basic block profile count is considered hot if it contributes to 
+ the given permillage of the entire profiled execution,
+999, 0, 1000)
 DEFPARAM(HOT_BB_FREQUENCY_FRACTION,
 hot-bb-frequency-fraction,
 Select fraction of the maximal frequency of executions of basic block 
in function given basic block needs to have to be considered hot,
@@ -451,7 +452,7 @@ DEFPARAM (PARAM_ALIGN_LOOP_ITERATIONS,
flatten the profile.
 
We need to cut the maximal predicted iterations to large enough iterations
-   so the loop appears important, but safely within HOT_BB_COUNT_FRACTION
+   so the loop appears important, but safely within maximum hotness
range.  */
 
 DEFPARAM(PARAM_MAX_PREDICTED_ITERATIONS,

--
This patch is available for review at http://codereview.appspot.com/6907063


Re: [Fortran, (RFC) patch] PR49110/51055 Assignment to alloc. deferred-length character vars

2012-12-10 Thread David Edelsohn
On Mon, Dec 10, 2012 at 10:54 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Mon, Dec 10, 2012 at 10:49:57AM -0500, David Edelsohn wrote:
 On Mon, Dec 10, 2012 at 5:05 AM, Jakub Jelinek ja...@redhat.com wrote:
  On Mon, Dec 10, 2012 at 10:56:58AM +0100, Janus Weil wrote:
   For C and C++, identifiers beginning with underscore and upper case
   letter or with two underscores are reserve to the implementation.
 
  See the previous discussion in this thread ...
 
  That's true, but the implementation isn't just GCC, it is also C libraries
  which aren't provided by GCC.  Including a character (if possible) that
  will make it unaccessible from C/C++ is desirable.  And, not changing the
  names of non-TREE_STATIC vars is also desirable, those I'm afraid show up
  in the debug info from time to time, so making them unnecessarily larger
  results in .debug_info size increases.

 An earlier suggestion was _F. .  Maybe gfortran.h should follow the
 same logic as gcc/defaults.h and gcc/cp/cp-tree.h:

 #ifndef NO_DOT_IN_LABEL
 _F.
 #else
 #ifndef NO_DOLLAR_IN_LABEL
 _F$
 #else
 _F_
 #endif
 #endif

 Sure, we my
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636
 comment.

Yes, I agree with the intention. The remaining question is if this
concept should be applied to all of the mangling with the new macro in
gfortran.h.

- David


Re: [AARCH64-4.7, PATCH, committed] Fix race in parallel build.

2012-12-10 Thread Richard Earnshaw

On 21/11/12 13:31, Marcus Shawcroft wrote:

I've just committed the attached back port of:

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01775.html

to the ARM/aarch64-4.7-branch.

/Marcus

2012-11-21  Marcus Shawcroft  marcus.shawcr...@arm.com

* Makefile.in (gengtype-lex.o): Add dependency on $(BCONFIG_H).


backport-aarch64-4.7-fix-parallel.patch


Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 193692)
+++ gcc/Makefile.in (revision 193693)
@@ -3888,7 +3888,7 @@
$(SYSTEM_H) coretypes.h $(GTM_H) errors.h $(READ_MD_H) gensupport.h
  build/gengenrtl.o : gengenrtl.c $(BCONFIG_H) $(SYSTEM_H) rtl.def
  gengtype-lex.o build/gengtype-lex.o : gengtype-lex.c gengtype.h $(SYSTEM_H)
-gengtype-lex.o: $(CONFIG_H)
+gengtype-lex.o: $(CONFIG_H) $(BCONFIG_H)
  build/gengtype-lex.o: $(BCONFIG_H)
  gengtype-parse.o build/gengtype-parse.o : gengtype-parse.c gengtype.h \
$(SYSTEM_H)



Is this also needed on the other release branches?

R.



Re: [PING][PATCH][RFC] Bug handling SUBREG (MEM) - MEM having side-effects?

2012-12-10 Thread Tejas Belagod

PING.

Tejas Belagod wrote:

Richard Sandiford wrote:

After the discussions Richard Earnshaw had on IRC with Andrew Pinski, it was
felt that it was best to fix the standard predicate
'general_operand' to not allow SUBREG (MEM) with side-effects as it has known
issues associated with it - particularly reload not being able to deal with such
cases. 'general_operand' currently outlaws cases like paradoxical SUBREG (MEM)
on targets with insn scheduling and SUBREG (MEM) with non-zero SUBREG_BYTE. This
is another case it should not allow. Here is a patch that tightens
general_operands to not allow SUBREG (MEM) with MEM having side-effects.

I would like to hear some thoughts on this.

LGTM.

It would be good to get rid of subreg mem operands altogether at some point,
but that's a little too drastic for stage 3.  This patch looks like a strict
improvement.



Thanks for looking at this. Is this OK for 4.7 as well?

Tejas Belagod
ARM.







Re: [patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

2012-12-10 Thread Steve Ellcey
On Mon, 2012-12-10 at 10:53 +, Richard Sandiford wrote:

 So please ignore that stupid suggestion.  The comments about the MIPS
 parts still stand of course.
 
 Richard

Here is a new patch.  I made the MIPS changes and I also changed some
code in dwarf2out.c.  I was making some calls to dbx_reg_number too
early in the last patch and getting aborts during testing due to that.
I also used a variable to avoid calling it twice in a row now.  This
version passed the GCC testsuite with no regressions.

Steve Ellcey
sell...@mips.com


2012-12-07  Steve Ellcey  sell...@mips.com

PR target/54061
rtl.h (IGNORED_DWARF_REGNUM): New.
* dwarf2out.c (reg_loc_descriptor): Check for IGNORED_DWARF_REGNUM.
(mem_loc_descriptor): Ditto.
* config/mips/mips.h (ALL_COP_REG_FIRST): New.
(ALL_COP_REG_LAST): New.
(ALL_COP_REG_NUM): Redefine using above macros.
* config/mips/mips.c (mips_option_override): Set mips_dbx_regno
coprocessor entries to IGNORED_DWARF_REGNUM.

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index b6a2290..820b228 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -16757,6 +16757,9 @@ mips_option_override (void)
   for (i = FP_REG_FIRST; i = FP_REG_LAST; i++)
 mips_dbx_regno[i] = i + start;
 
+  for (i = ALL_COP_REG_FIRST; i = ALL_COP_REG_LAST; i++)
+mips_dbx_regno[i] = IGNORED_DWARF_REGNUM;
+
   /* Accumulator debug registers use big-endian ordering.  */
   mips_dbx_regno[HI_REGNUM] = MD_DBX_FIRST + 0;
   mips_dbx_regno[LO_REGNUM] = MD_DBX_FIRST + 1;
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 308b59b..60b26cb 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1641,8 +1641,11 @@ struct mips_cpu_info {
 #define COP3_REG_FIRST 144
 #define COP3_REG_LAST 175
 #define COP3_REG_NUM (COP3_REG_LAST - COP3_REG_FIRST + 1)
-/* ALL_COP_REG_NUM assumes that COP0,2,and 3 are numbered consecutively.  */
-#define ALL_COP_REG_NUM (COP3_REG_LAST - COP0_REG_FIRST + 1)
+
+/* These definitions assume that COP0, 2 and 3 are numbered consecutively.  */
+#define ALL_COP_REG_FIRST COP0_REG_FIRST
+#define ALL_COP_REG_LAST COP3_REG_LAST
+#define ALL_COP_REG_NUM (ALL_COP_REG_LAST - ALL_COP_REG_FIRST + 1)
 
 #define DSP_ACC_REG_FIRST 176
 #define DSP_ACC_REG_LAST 181
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f0256ae..c92fa4b 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10499,7 +10499,12 @@ reg_loc_descriptor (rtx rtl, enum var_init_status 
initialized)
   if (hard_regno_nregs[REGNO (rtl)][GET_MODE (rtl)]  1 || regs)
 return multiple_reg_loc_descriptor (rtl, regs, initialized);
   else
-return one_reg_loc_descriptor (dbx_reg_number (rtl), initialized);
+{
+  unsigned int dbx_regnum = dbx_reg_number (rtl);
+  if (dbx_regnum == IGNORED_DWARF_REGNUM)
+   return 0;
+  return one_reg_loc_descriptor (dbx_regnum, initialized);
+}
 }
 
 /* Return a location descriptor that designates a machine register for
@@ -11926,6 +11931,7 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
  ))
{
  dw_die_ref type_die;
+ unsigned int dbx_regnum;
 
  if (dwarf_strict)
break;
@@ -11935,8 +11941,12 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
 GET_MODE_CLASS (mode) == MODE_INT);
  if (type_die == NULL)
break;
+
+ dbx_regnum = dbx_reg_number (rtl);
+ if (dbx_regnum == IGNORED_DWARF_REGNUM)
+   break;
  mem_loc_result = new_loc_descr (DW_OP_GNU_regval_type,
- dbx_reg_number (rtl), 0);
+ dbx_regnum, 0);
  mem_loc_result-dw_loc_oprnd2.val_class = dw_val_class_die_ref;
  mem_loc_result-dw_loc_oprnd2.v.val_die_ref.die = type_die;
  mem_loc_result-dw_loc_oprnd2.v.val_die_ref.external = 0;
@@ -12138,9 +12148,13 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mode,
op0 = mem_loc_descriptor (ENTRY_VALUE_EXP (rtl), mode,
  VOIDmode, VAR_INIT_STATUS_INITIALIZED);
  else
-   op0
- = one_reg_loc_descriptor (dbx_reg_number (ENTRY_VALUE_EXP (rtl)),
-   VAR_INIT_STATUS_INITIALIZED);
+   {
+  unsigned int dbx_regnum = dbx_reg_number (ENTRY_VALUE_EXP (rtl));
+ if (dbx_regnum == IGNORED_DWARF_REGNUM)
+   return NULL;
+ op0 = one_reg_loc_descriptor (dbx_regnum,
+   VAR_INIT_STATUS_INITIALIZED);
+   }
}
   else if (MEM_P (ENTRY_VALUE_EXP (rtl))
REG_P (XEXP (ENTRY_VALUE_EXP (rtl), 0)))
diff --git a/gcc/rtl.h b/gcc/rtl.h
index a0fb4f7..5b9ceb8 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -2439,6 +2439,9 @@ extern rtx gen_rtx_MEM (enum machine_mode, rtx);
 /* REGNUM never 

[patch, mips, testsuite] Fix scan on gcc.target/mips/ext-2.c

2012-12-10 Thread Steve Ellcey
In looking at the failure of gcc.target/mips/ext-2.c, it looks like the
GCC compiler is now figuring out that it can use a 32 bit ext instruction
instead of a 64 bit dext instruction and that this is why the test
fails.  Here is a patch to look for 'ext' or 'dext', OK to checkin?
It fixes the failure for me and I see no reason why GCC should not use
the ext instruction instead of dext in this case.

Steve Ellcey
sell...@mips.com


2012-12-10  Steve Ellcey  sell...@mips.com

* gcc.target/mips/ext-2.c: Scan for ext or dext.


diff --git a/gcc/testsuite/gcc.target/mips/ext-2.c 
b/gcc/testsuite/gcc.target/mips/ext-2.c
index 5d68bc5..6063d3b 100644
--- a/gcc/testsuite/gcc.target/mips/ext-2.c
+++ b/gcc/testsuite/gcc.target/mips/ext-2.c
@@ -4,7 +4,7 @@
 /* { dg-do compile } */
 /* { dg-options isa_rev=2 -mgp64 } */
 /* { dg-skip-if code quality test { *-*-* } { -O0 } {  } } */
-/* { dg-final { scan-assembler \tdext\t } } */
+/* { dg-final { scan-assembler \t(dext|ext)\t } } */
 /* { dg-final { scan-assembler-not \tand } } */
 /* { dg-final { scan-assembler-not \td?srl } } */
 


[patch, mips] Fix -mno-shared option (gcc.target/mips/pr35802.c)

2012-12-10 Thread Steve Ellcey

The test gcc.target/mips/pr35802.c is failing with the message:

xgcc: error: unrecognized command line option '-mdsp-mno-shared'

Obviously the -mdsp and -mno-shared flags got stuck together without
a space between them.  This patch fixes the failure.  Ok to checkin?
It was tested with no regressions.

2012-12-10  Steve Ellcey  sell...@mips.com

* config/mips/gnu-user.h (NO_SHARED_SPECS): Add space before option.


diff --git a/gcc/config/mips/gnu-user.h b/gcc/config/mips/gnu-user.h
index d35ddac..55ca662 100644
--- a/gcc/config/mips/gnu-user.h
+++ b/gcc/config/mips/gnu-user.h
@@ -97,7 +97,7 @@ along with GCC; see the file COPYING3.  If not see
 #ifdef HAVE_AS_NO_SHARED
 /* Default to -mno-shared for non-PIC.  */
 # define NO_SHARED_SPECS \
-  %{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;:-mno-shared}
+  %{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;: -mno-shared}
 #else
 # define NO_SHARED_SPECS 
 #endif


Re: application/xml mime-type in recent libstdc++ doc changes

2012-12-10 Thread Benjamin De Kosnik

  libstdc++-v3/doc/xsl/customization.xsl.in is marked as
  
svn:mime-type = application/xml
  
  at least on the 4.7 branch, having some unexpected outcome for svn
  diff. If this was unintended, could you change the svn:mime-type
  back to text?

This is unintentional, and frankly I don't know how the inital mime
type was created or how to fix it. Any pointers? Can you do it and tell
me how?

best,
benjamin


Re: [patch][c++] Stop in cp_write_global_declarations after writing a PCH

2012-12-10 Thread Steven Bosscher
On Fri, Dec 7, 2012 at 3:13 PM, Richard Biener wrote:
 On Fri, Dec 7, 2012 at 10:52 AM, Steven Bosscher wrote:
 Ping?

 Ok if C++ frontend maintainers don't complain over the weekend.

Committed now.
BTW I forgot to mention I also did a build+test with this patch and
with gcac checking enabled.

Ciao!
Steven


[patch, testsuite] Fix pr35634 tests when char is unsigned.

2012-12-10 Thread Steve Ellcey
The tests gcc.dg/torture/pr35634.c and g++.dg/torture/pr35634.C fail for
me on the mips-mti-elf target.  At first I thought it was because 'n'
was not initialized but then I realized it was because 'char' on this
target defaults to 'unsigned char', not 'signed char'.  Since I think
initializing 'n' is still a good idea I made that change as well as making
'c' an explicitly signed char.  This now passes on mips-mti-elf.

OK for checkin?

Steve Ellcey
sell...@mips.com


2012-12-10  Steve Ellcey  sell...@mips.com

* gcc.dg/torture/pr35634.c: Initialize n, make c signed.
* g++.dg/torgure/pr35634.C: Ditto.

diff --git a/gcc/testsuite/g++.dg/torture/pr35634.C 
b/gcc/testsuite/g++.dg/torture/pr35634.C
index 00848e3..1f03bb1 100644
--- a/gcc/testsuite/g++.dg/torture/pr35634.C
+++ b/gcc/testsuite/g++.dg/torture/pr35634.C
@@ -5,7 +5,7 @@ extern C void exit (int);
 
 void foo (int i)
 {
-static int n;
+static int n = 0;
 if (i  -128 || i  127)
 abort ();
 if (++n  1000)
@@ -14,6 +14,6 @@ void foo (int i)
 
 int main ()
 {
-char c;
+signed char c;
 for (c = 0; ; c++) foo (c);
 }
diff --git a/gcc/testsuite/gcc.dg/torture/pr35634.c 
b/gcc/testsuite/gcc.dg/torture/pr35634.c
index 32df7d4..f8876a4 100644
--- a/gcc/testsuite/gcc.dg/torture/pr35634.c
+++ b/gcc/testsuite/gcc.dg/torture/pr35634.c
@@ -5,7 +5,7 @@ void exit (int);
 
 void foo (int i)
 {
-static int n;
+static int n = 0;
 if (i  -128 || i  127)
 abort ();
 if (++n  1000)
@@ -14,6 +14,6 @@ void foo (int i)
 
 int main ()
 {
-char c;
+signed char c;
 for (c = 0; ; c++) foo (c);
 }


Re: [patch, testsuite] Fix pr35634 tests when char is unsigned.

2012-12-10 Thread Richard Biener
On Mon, Dec 10, 2012 at 7:32 PM, Steve Ellcey sell...@mips.com wrote:
 The tests gcc.dg/torture/pr35634.c and g++.dg/torture/pr35634.C fail for
 me on the mips-mti-elf target.  At first I thought it was because 'n'
 was not initialized but then I realized it was because 'char' on this
 target defaults to 'unsigned char', not 'signed char'.  Since I think
 initializing 'n' is still a good idea I made that change as well as making
 'c' an explicitly signed char.  This now passes on mips-mti-elf.

statics are zero-initialized according to C89.

 OK for checkin?

Ok minus the initialization.

Thanks,
Richard.

 Steve Ellcey
 sell...@mips.com


 2012-12-10  Steve Ellcey  sell...@mips.com

 * gcc.dg/torture/pr35634.c: Initialize n, make c signed.
 * g++.dg/torgure/pr35634.C: Ditto.

 diff --git a/gcc/testsuite/g++.dg/torture/pr35634.C 
 b/gcc/testsuite/g++.dg/torture/pr35634.C
 index 00848e3..1f03bb1 100644
 --- a/gcc/testsuite/g++.dg/torture/pr35634.C
 +++ b/gcc/testsuite/g++.dg/torture/pr35634.C
 @@ -5,7 +5,7 @@ extern C void exit (int);

  void foo (int i)
  {
 -static int n;
 +static int n = 0;
  if (i  -128 || i  127)
  abort ();
  if (++n  1000)
 @@ -14,6 +14,6 @@ void foo (int i)

  int main ()
  {
 -char c;
 +signed char c;
  for (c = 0; ; c++) foo (c);
  }
 diff --git a/gcc/testsuite/gcc.dg/torture/pr35634.c 
 b/gcc/testsuite/gcc.dg/torture/pr35634.c
 index 32df7d4..f8876a4 100644
 --- a/gcc/testsuite/gcc.dg/torture/pr35634.c
 +++ b/gcc/testsuite/gcc.dg/torture/pr35634.c
 @@ -5,7 +5,7 @@ void exit (int);

  void foo (int i)
  {
 -static int n;
 +static int n = 0;
  if (i  -128 || i  127)
  abort ();
  if (++n  1000)
 @@ -14,6 +14,6 @@ void foo (int i)

  int main ()
  {
 -char c;
 +signed char c;
  for (c = 0; ; c++) foo (c);
  }


Re: [patch] libgcc unwind-arm.h: mark arguments as unused

2012-12-10 Thread Ian Lance Taylor
On Sun, Dec 9, 2012 at 11:13 PM, Matthias Klose d...@ubuntu.com wrote:
 This was seen and fixed on trunk building libbacktrace on arm:
 http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00628.html

 I see this now cross building libgo targeting arm on the 4.7 branch. Ok to
 backport to the 4.7 branch?

It's fine with me.  You should technically get RM permission although
this seems safe enough.

Ian


Re: [patch, testsuite] Fix pr35634 tests when char is unsigned.

2012-12-10 Thread Steve Ellcey
On Mon, 2012-12-10 at 20:01 +0100, Richard Biener wrote:

 
 Ok minus the initialization.
 
 Thanks,
 Richard.

Actually, it looks like you already fixed this last week.  I am not
seeing it in my git tree, but it is in the FSF subversion and
git trees so I think I have a local problem updating my tree.

Steve Ellcey
sell...@mips.com



Re: [PATCH] Bugfix: Additional parameter for canonicalize comparison

2012-12-10 Thread Richard Henderson
On 12/10/2012 01:50 AM, Andreas Krebbel wrote:
 Ok. Here is an updated version trying to address the comments above.
 
 2012-12-10  Andreas Krebbel  andreas.kreb...@de.ibm.com
 
   * target.def: Define canonicalize_comparison hook.
   * targhooks.h (default_canonicalize_comparison): New prototype.
   * targhooks.c (default_canonicalize_comparison): New function.
   * doc/tm.texi: Add documentation for the new target hook.
   * doc/tm.texi.in: Likewise.
   * combine.c (try_combine): Adjust to use the target hook.
   * config/alpha/alpha.h (CANONICALIZE_COMPARISON): Remove macro
   definition.
   * config/alpha/alpha.c (alpha_canonicalize_comparison): New
   function.
   (TARGET_CANONICALIZE_COMPARISON): New macro definition.
   * config/arm/arm-protos.h (arm_canonicalize_comparison): Remove
   prototype.
   * config/arm/arm.c (arm_canonicalize_comparison): Add new
   parameter.
   (TARGET_CANONICALIZE_COMPARISON): New macro definition.
   * config/arm/arm.h (CANONICALIZE_COMPARISON): Remove macro
   definition.
   * config/s390/s390-protos.h (s390_canonicalize_comparison): Remove
   prototype.
   * config/s390/s390.c (s390_canonicalize_comparison): Add new
   parameter.
   (TARGET_CANONICALIZE_COMPARISON): New macro definition.
   * config/s390/s390.h (CANONICALIZE_COMPARISON): Remove macro
   definition.
   * config/sh/sh-protos.h (sh_canonicalize_comparison): Remove
   prototype.
   * config/sh/sh.c (sh_canonicalize_comparison): Add new prototype.  New
   function overloading the old one.
   (TARGET_CANONICALIZE_COMPARISON): New macro definition.
   * config/sh/sh.h (CANONICALIZE_COMPARISON): Remove macro
   definition.
   * config/spu/spu.c (spu_canonicalize_comparison): New function.
   (TARGET_CANONICALIZE_COMPARISON): New macro definition.
   * config/spu/spu.h (CANONICALIZE_COMPARISON): Remove macro
   definition.

Looks ok.  Although I thought Oleg was suggesting to not add a wrapper in sh,
but to adjust the users...

 + /* Convenience wrapper for the canonicalize_comparison target hook.
 +Targets hooks cannot use enum rtx_code.  */

Honestly, for 4.9 we should fix that.  Unlike machine_mode which really is
target-specific, rtx_code is not.  It's just not defined in the right place.


r~



Ping^2: Synopsys DesignWare ARC Port

2012-12-10 Thread Joern Rennecke

This patch set hasn't been reviewed for more than two weeks:


libgcc:

2012-10-09  Joern Rennecke  joern.renne...@embecosm.com

 * config.host (arc-*-elf*, arc*-*-linux-uclibc*): New configurations.
gcc:

2012-11-22  Joern Rennecke  joern.renne...@embecosm.com
 Brendan Kehoe  bren...@zen.org

 * config.gcc (arc-*-elf*, arc*-*-linux-uclibc*): New configurations.
 * doc/install.texi (--with-cpu): Mention ARC.
 (arc-*-elf32): New paragraph.
 (arc-linux-uclibc): Likewise.
 * doc/md.texi (Machine Constraints): Add ARC part.
 * doc/invoke.texi: (menu): Add ARC Options.
 (Machine Dependent Options) ARC Options: Add synopsis.
 (node ARC Options): Add.
 * doc/extend.texi (long_call / short_call attribute): Add ARC.

gcc/testsuite:

2012-11-22  Joern Rennecke  joern.renne...@embecosm.com

 * gcc.c-torture/execute/20101011-1.c [__arc__] (DO_TEST):  
Define as 0.

 * gcc.dg/torture/pr37868.c: Also skip for arc*-*-*.
 * gcc.dg/stack-usage-1.c [__arc__] (SIZE): Define.

libstdc++-v3:

2012-08-16  Joern Rennecke  joern.renne...@embecosm.com

 * acinclude.m4 (GLIBCXX_ENABLE_SJLJ_EXCEPTIONS): Also check for
 _Unwind_SjLj_Register when deciding if to set enable_sjlj_exceptions.
 * configure: Regenerate.

gcc:

2012-11-25  Saurabh Verma  saurabh.ve...@codito.com
 Ramana Radhakrishnan  ramana.radhakrish...@codito.com
 Joern Rennecke  joern.renne...@embecosm.com
 Muhammad Khurram Riaz khurram.r...@arc.com
 Brendan Kehoe  bren...@zen.org
 Michael Eager  ea...@eagercon.com

 * config/arc, common/config/arc: New directories.

gcc/testsuite:

2012-08-28  Joern Rennecke  joern.renne...@embecosm.com

 * gcc.target/arc: New directory.

libgcc:

2012-10-18  Joern Rennecke  joern.renne...@embecosm.com
 Brendan Kehoe  bren...@zen.org

 * libgcc/config/arc: New directory.

contents of config/arc:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02051.html
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02052.html
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02055.html

Plus the other stuff from here:

http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01891.html


Re: [patch, mips] Fix -mno-shared option (gcc.target/mips/pr35802.c)

2012-12-10 Thread Richard Sandiford
Steve Ellcey  sell...@mips.com writes:
 The test gcc.target/mips/pr35802.c is failing with the message:

   xgcc: error: unrecognized command line option '-mdsp-mno-shared'

 Obviously the -mdsp and -mno-shared flags got stuck together without
 a space between them.  This patch fixes the failure.  Ok to checkin?
 It was tested with no regressions.

Ugh.

 diff --git a/gcc/config/mips/gnu-user.h b/gcc/config/mips/gnu-user.h
 index d35ddac..55ca662 100644
 --- a/gcc/config/mips/gnu-user.h
 +++ b/gcc/config/mips/gnu-user.h
 @@ -97,7 +97,7 @@ along with GCC; see the file COPYING3.  If not see
  #ifdef HAVE_AS_NO_SHARED
  /* Default to -mno-shared for non-PIC.  */
  # define NO_SHARED_SPECS \
 -  %{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;:-mno-shared}
 +  %{mshared|mno-shared|fpic|fPIC|fpie|fPIE:;: -mno-shared}
  #else
  # define NO_SHARED_SPECS 
  #endif

MARCH_MTUNE_NATIVE_SPECS puts the space after the opening quote,
so we might as well do the same here for consistency.  OK with that
change, thanks.

Richard


Re: [PATCH] Bugfix: Additional parameter for canonicalize comparison

2012-12-10 Thread Oleg Endo
On Mon, 2012-12-10 at 11:22 -0800, Richard Henderson wrote:
 On 12/10/2012 01:50 AM, Andreas Krebbel wrote:
  Ok. Here is an updated version trying to address the comments above.
  
  2012-12-10  Andreas Krebbel  andreas.kreb...@de.ibm.com
  
  * target.def: Define canonicalize_comparison hook.
  * targhooks.h (default_canonicalize_comparison): New prototype.
  * targhooks.c (default_canonicalize_comparison): New function.
  * doc/tm.texi: Add documentation for the new target hook.
  * doc/tm.texi.in: Likewise.
  * combine.c (try_combine): Adjust to use the target hook.
  * config/alpha/alpha.h (CANONICALIZE_COMPARISON): Remove macro
  definition.
  * config/alpha/alpha.c (alpha_canonicalize_comparison): New
  function.
  (TARGET_CANONICALIZE_COMPARISON): New macro definition.
  * config/arm/arm-protos.h (arm_canonicalize_comparison): Remove
  prototype.
  * config/arm/arm.c (arm_canonicalize_comparison): Add new
  parameter.
  (TARGET_CANONICALIZE_COMPARISON): New macro definition.
  * config/arm/arm.h (CANONICALIZE_COMPARISON): Remove macro
  definition.
  * config/s390/s390-protos.h (s390_canonicalize_comparison): Remove
  prototype.
  * config/s390/s390.c (s390_canonicalize_comparison): Add new
  parameter.
  (TARGET_CANONICALIZE_COMPARISON): New macro definition.
  * config/s390/s390.h (CANONICALIZE_COMPARISON): Remove macro
  definition.
  * config/sh/sh-protos.h (sh_canonicalize_comparison): Remove
  prototype.
  * config/sh/sh.c (sh_canonicalize_comparison): Add new prototype.  New
  function overloading the old one.
  (TARGET_CANONICALIZE_COMPARISON): New macro definition.
  * config/sh/sh.h (CANONICALIZE_COMPARISON): Remove macro
  definition.
  * config/spu/spu.c (spu_canonicalize_comparison): New function.
  (TARGET_CANONICALIZE_COMPARISON): New macro definition.
  * config/spu/spu.h (CANONICALIZE_COMPARISON): Remove macro
  definition.
 
 Looks ok.  Although I thought Oleg was suggesting to not add a wrapper in sh,
 but to adjust the users...

No, I wasn't.  I was just mentioning the _1 thing.  But yes, you're
right.  The users should be fixed instead.  However  

  + /* Convenience wrapper for the canonicalize_comparison target hook.
  +Targets hooks cannot use enum rtx_code.  */
 
 Honestly, for 4.9 we should fix that.  Unlike machine_mode which really is
 target-specific, rtx_code is not.  It's just not defined in the right place.
 

... I can do that in the SH code during 4.9 after the issue above has
been resolved.

Cheers,
Oleg



Re: [patch, mips, testsuite] Fix scan on gcc.target/mips/ext-2.c

2012-12-10 Thread Richard Sandiford
Steve Ellcey  sell...@mips.com writes:
 In looking at the failure of gcc.target/mips/ext-2.c, it looks like the
 GCC compiler is now figuring out that it can use a 32 bit ext instruction
 instead of a 64 bit dext instruction and that this is why the test
 fails.  Here is a patch to look for 'ext' or 'dext', OK to checkin?
 It fixes the failure for me and I see no reason why GCC should not use
 the ext instruction instead of dext in this case.

Agreed, but it no longer matches the original intention of the test:

/* Turn the truncate,zero_extend,lshiftrt sequence before the or into a
   zero_extract.  The truncate is due to TARGET_PROMOTE_PROTOTYPES, the
   zero_extend to PROMOTE_MODE.  */

because we've lost the truncate.

I went for the patch below instead, after checking that the uncombined
sequence really was a truncate/zero_extend/lshiftft sequence.  Tested on
mips64-linux-gnu (where the test also failed for -mabi=n32 and -mabi=32,
but not for -mabi=64).  Applied.

Richard


gcc/testsuite/
* gcc.target/mips/ext-2.c: Require -mlong64.

Index: gcc/testsuite/gcc.target/mips/ext-2.c
===
--- gcc/testsuite/gcc.target/mips/ext-2.c   2012-08-27 17:31:22.0 
+0100
+++ gcc/testsuite/gcc.target/mips/ext-2.c   2012-12-10 19:50:25.159758211 
+
@@ -2,7 +2,7 @@
zero_extract.  The truncate is due to TARGET_PROMOTE_PROTOTYPES, the
zero_extend to PROMOTE_MODE.  */
 /* { dg-do compile } */
-/* { dg-options isa_rev=2 -mgp64 } */
+/* { dg-options isa_rev=2 -mgp64 -mlong64 } */
 /* { dg-skip-if code quality test { *-*-* } { -O0 } {  } } */
 /* { dg-final { scan-assembler \tdext\t } } */
 /* { dg-final { scan-assembler-not \tand } } */


[C++] Add missing dependency on $(PARAMS_H)

2012-12-10 Thread Eric Botcazou
When you add a new --param entry and rebuild an existing compiler, you get 
weird C++ regressions in the testsuite because of outdated object files.

Tested on x86_64-suse-linux, applied on the mainline as obvious.


2012-12-10  Eric Botcazou  ebotca...@adacore.com

* Make-lang.in (cp/typeck.o): Add dependency on $(PARAMS_H).
(cp/name-lookup.o): Likewise.


-- 
Eric BotcazouIndex: Make-lang.in
===
--- Make-lang.in	(revision 194328)
+++ Make-lang.in	(working copy)
@@ -288,7 +288,7 @@ cp/cp-objcp-common.o : cp/cp-objcp-commo
   $(CXX_PRETTY_PRINT_H) cp/cp-objcp-common.h gt-cp-cp-objcp-common.h
 cp/typeck2.o: cp/typeck2.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) \
   $(TM_P_H) $(DIAGNOSTIC_CORE_H) gt-cp-typeck2.h $(REAL_H) intl.h
-cp/typeck.o: cp/typeck.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) \
+cp/typeck.o: cp/typeck.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) $(PARAMS_H) \
   toplev.h $(DIAGNOSTIC_H) convert.h $(C_COMMON_H) $(TARGET_H) \
   c-family/c-objc.h
 cp/class.o: cp/class.c $(CXX_TREE_H) $(TM_H) $(FLAGS_H) toplev.h \
@@ -342,7 +342,7 @@ cp/cp-gimplify.o: cp/cp-gimplify.c $(CXX
 	$(TM_H) coretypes.h pointer-set.h tree-iterator.h $(SPLAY_TREE_H)
 
 cp/name-lookup.o: cp/name-lookup.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
-	$(TM_H) $(CXX_TREE_H) $(TIMEVAR_H) gt-cp-name-lookup.h \
+	$(TM_H) $(CXX_TREE_H) $(TIMEVAR_H) gt-cp-name-lookup.h $(PARAMS_H) \
 	$(DIAGNOSTIC_CORE_H) $(FLAGS_H) debug.h pointer-set.h
 
 cp/cxx-pretty-print.o: cp/cxx-pretty-print.c $(CXX_PRETTY_PRINT_H) \


Re: [patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

2012-12-10 Thread Cary Coutant
 2012-12-07  Steve Ellcey  sell...@mips.com

 PR target/54061
 rtl.h (IGNORED_DWARF_REGNUM): New.
 * dwarf2out.c (reg_loc_descriptor): Check for IGNORED_DWARF_REGNUM.
 (mem_loc_descriptor): Ditto.
 * config/mips/mips.h (ALL_COP_REG_FIRST): New.
 (ALL_COP_REG_LAST): New.
 (ALL_COP_REG_NUM): Redefine using above macros.
 * config/mips/mips.c (mips_option_override): Set mips_dbx_regno
 coprocessor entries to IGNORED_DWARF_REGNUM.

The dwarf2out.c parts are OK.

-cary


Re: [patch, mips, testsuite] Fix gcc.target/mips/octeon-bbit-2.c for -Os

2012-12-10 Thread Richard Sandiford
Sorry for the extra-long delay on this one.

Steve Ellcey  sell...@mips.com writes:
 The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization
 level does not do whichever optimization it is that results in a bbit instead
 of a bbit[01]l.  I would like to skip this test for -Os the way it already 
 gets
 skipped for -O0.

The point of the test is that BBIT[01]L doesn't exist; there aren't any
branch-likely variants of BBIT[01].  So we wanted to check that we could
still use branch-likely instructions for g(), but wouldn't ever generate
the invalid BBIT[01]L for the similarly-structured f().

The problem is that:

  int s = 0;
  for (; i  1; i++)
s += i;
  return s;

isn't a very direct way of encouraging branch-likely instructions,
because it requires the i  1 test to be duplicated.  As you say,
we legimately don't do that for -Os.  A sufficiently fancy gimple
optimiser could also figure out that the loop iterates at most once
and replace the loop with a non-iterating structure.

The patch below uses a form that doesn't require any code duplication
and which should be a bit more future-proof.  Tested on mips64-linux-gnu
and applied.

Richard


gcc/testsuite/
* gcc.target/mips/octeon-bbit-2.c: Restructure loops so that no
code duplication is required.  Allow BNE to appear.

Index: gcc/testsuite/gcc.target/mips/octeon-bbit-2.c
===
--- gcc/testsuite/gcc.target/mips/octeon-bbit-2.c   2012-08-27 
17:27:13.0 +0100
+++ gcc/testsuite/gcc.target/mips/octeon-bbit-2.c   2012-10-08 
21:23:53.416540290 +0100
@@ -4,22 +4,21 @@
 /* { dg-final { scan-assembler \tbbit\[01\]\t } } */
 /* { dg-final { scan-assembler-not \tbbit\[01\]l\t } } */
 /* { dg-final { scan-assembler \tbnel\t } } */
-/* { dg-final { scan-assembler-not \tbne\t } } */
 
 NOMIPS16 int
-f (int n, int i)
+f (int *a, int *b)
 {
-  int s = 0;
-  for (; i  1; i++)
-s += i;
-  return s;
+  do
+if (__builtin_expect (*a  1, 1))
+  *a = 0;
+  while (++a  b);
 }
 
 NOMIPS16 int
-g (int n, int i)
+g (int *a, int *b)
 {
-  int s = 0;
-  for (i = 0; i  n; i++)
-s += i;
-  return s;
+  do
+if (__builtin_expect (*a == 3, 1))
+  *a = 0;
+  while (++a  b);
 }


Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs

2012-12-10 Thread Xinliang David Li
I have not measured the CFI size impact -- but conceivably it should
be larger -- which is unfortunate.

David

On Mon, Dec 10, 2012 at 1:23 AM, Richard Biener
richard.guent...@gmail.com wrote:
 On Sun, Dec 9, 2012 at 2:50 PM, Uros Bizjak ubiz...@gmail.com wrote:
 Hello!

 I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
 SP adjustment instead of a sequence of pushes/pops. The preference to
 the MOVs are good for old CPU micro-architectures (before pentium-4,
 K10), because it breaks the data dependency.  In modern
 micro-architecture, push/pop is implemented using a mechanism called
 stack engine. The data dependency is removed by the hardware, and
 push/pop becomes very cheap (1 uOp, 1 cycle latency), and they are
 smaller. There is no longer the need to avoid using them.   This is
 also what ICC does.

 2012-12-08  Xinliang David Li  davi...@google.com
* config/i386/i386.c: Eanble push/pop in pro/epilogue for 
 moderen CPUs.

 s/moderen/modern

 OK for mainline SVN.

 It's also more costly for unwind info in the prologue/epilogue.  Thus, did you
 measure the effect on CFI size?

 Thanks,
 Richard.

 Thanks,
 Uros.


Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs

2012-12-10 Thread Mike Stump
On Dec 10, 2012, at 12:42 PM, Xinliang David Li davi...@google.com wrote:
 I have not measured the CFI size impact -- but conceivably it should
 be larger -- which is unfortunate.

Code speed and size are preferable to optimizing dwarf size…  :-)  I'd let 
dwarf 5 fix it!



Re: [asan] Handle noreturn calls with __asan_handle_no_return ()

2012-12-10 Thread Dodji Seketeli
Jakub Jelinek ja...@redhat.com writes:

 +++ gcc/asan.c2012-12-05 15:30:56.069890542 +0100
 @@ -1031,7 +1031,7 @@ instrument_builtin_call (gimple_stmt_ite
  {
gimple call = gsi_stmt (*iter);
  
 -  gcc_assert (is_gimple_builtin_call (call));
 +  gcc_checking_assert (is_gimple_builtin_call (call));

Why is this change necessary?

The patch looks OK to me otherwise.

-- 
Dodji


Re: [asan] Handle noreturn calls with __asan_handle_no_return ()

2012-12-10 Thread Jakub Jelinek
On Mon, Dec 10, 2012 at 10:44:49PM +0100, Dodji Seketeli wrote:
 Jakub Jelinek ja...@redhat.com writes:
 
  +++ gcc/asan.c  2012-12-05 15:30:56.069890542 +0100
  @@ -1031,7 +1031,7 @@ instrument_builtin_call (gimple_stmt_ite
   {
 gimple call = gsi_stmt (*iter);
   
  -  gcc_assert (is_gimple_builtin_call (call));
  +  gcc_checking_assert (is_gimple_builtin_call (call));
 
 Why is this change necessary?

It is not necessary, just it isn't as low cost as it would be good for
an assertion, it does:
  if (is_gimple_call (stmt)
   (callee = gimple_call_fndecl (stmt))
   is_builtin_fn (callee)
   DECL_BUILT_IN_CLASS (callee) == BUILT_IN_NORMAL)
return true;
and the caller calls that exact routine already:
  if (is_gimple_builtin_call (gsi_stmt (*iter)))
return instrument_builtin_call (iter);
and this is the second statement in instrument_builtin_call.

Jakub


Re: [PATCH] PR c++/53609 - Wrong argument deduction for pack expansion in argument pack

2012-12-10 Thread Jason Merrill

On 12/08/2012 05:12 PM, Dodji Seketeli wrote:

+  else if (arg_from_pack_level_to_prune || has_empty_arg)
+{
+  /* ... we just return a pack expansion which pattern is PATTERN
+into which ARGS has been substituted.  */
+  *instantiation_yields_no_list_p = true;
+}



Though I think it would still be appropriate to keep this 'if' just to
avoid going into the 'else' block for cases where we know that looping
over the parameter packs (and do the ARGUMENT_PACK_SELECT dance) is
unnecessary; all we want is to go straight to the point where we
substitute args into the pattern, build a pack expansion and return
it.  Or isn't what you meant?


I suppose we should keep this for has_empty_arg, but I'd like to do away 
with special handling of the arg_from_parm_pack case if possible, as 
it's a lot of extra complexity.



My understanding is that in practise, we never hit this point in the
previous code.  The reason why len would still be negative at this
point would be if we didn't find any (good) argument pack.  But in
that case, we would have considered that we have unsubstituted packs
and would have returned an unsubstituted pack expansion before we
reach this point.


I don't see that; in the old code, if there are unsubstituted packs we 
tsubst the args into the pattern.



+  /* We got some full packs, but we can't substitute them in until we
+have values for all the packs.  So remember these until then.  */


How can having this in gen_elem_of_pack_expansion_instantiation could 
work?  We don't want an expansion for each element of the packs that we 
have.


Jason



Re: [patch, mips, debug] Fix PR 54061, mips compiler aborts in testsuite

2012-12-10 Thread Richard Henderson
On 12/10/2012 08:50 AM, Steve Ellcey wrote:
 2012-12-07  Steve Ellcey  sell...@mips.com
 
   PR target/54061
   rtl.h (IGNORED_DWARF_REGNUM): New.
   * dwarf2out.c (reg_loc_descriptor): Check for IGNORED_DWARF_REGNUM.
   (mem_loc_descriptor): Ditto.
   * config/mips/mips.h (ALL_COP_REG_FIRST): New.
   (ALL_COP_REG_LAST): New.
   (ALL_COP_REG_NUM): Redefine using above macros.
   * config/mips/mips.c (mips_option_override): Set mips_dbx_regno
   coprocessor entries to IGNORED_DWARF_REGNUM.

Ok.


r~


Re: [PATCH] Bugfix: Additional parameter for canonicalize comparison

2012-12-10 Thread Kaz Kojima
Andreas Krebbel kreb...@linux.vnet.ibm.com wrote:
 Index: gcc/config/sh/sh.c
 ===
 *** gcc/config/sh/sh.c.orig
 --- gcc/config/sh/sh.c
[snop]
 ! static void
   sh_canonicalize_comparison (enum rtx_code cmp, rtx op0, rtx op1,
 ! enum machine_mode mode,
 ! bool op0_preserve_value ATTRIBUTE_UNUSED)
   {
 +   HOST_WIDE_INT val;
 + 

Please remove the last two lines which cause the warning:

gcc/config/sh/sh.c:1927:17: warning: unused variable 'val' [-Wunused-variable]

Regards,
kaz


Re: [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules

2012-12-10 Thread Janus Weil
Hi Tobias,

 I think the patch below is okay, especially in light of patch PR49110/51055
 which also contains a slight ABI breakage.

thanks, committed as r194375.


 Can you mention the potential ABI
 issue in the release notes (gfortran wiki).

Will do ...

Cheers,
Janus



 On 09.04.2012 18:31 Janus Weil wrote:

 Hi all,

 here is a simple patch for a problem recently reported by Andrew
 Benson: Procedure pointers inside a module don't receive the proper
 name mangling, which can lead to name collisions (as the test case
 demonstrates).

 The patch fixes this and regtests cleanly on x86_64-unknown-linux-gnu.
 I am aware that it will break the ABI, but only for programs involving
 procedure pointers (which still is a 'relatively' new feature,
 supported since gfortran 4.4). So, ok for trunk?

 Btw, speaking of ABI breaking: What are the chances of the array
 descriptor update and ABI cleanup happening for the 4.8 release? I
 know such an ABI breaking has been planned for some time, but I
 haven't followed the gfortran mailing list in detail during the last
 weeks and months, so I'm not sure what the current status is.

 Cheers,
 Janus



 2012-04-09  Janus Weil  ja...@gcc.gnu.org

 PR fortran/52909
 * trans-decl.c (get_proc_pointer_decl): Apply name mangling.


 2012-04-09  Janus Weil  ja...@gcc.gnu.org

 PR fortran/52909
 * gfortran.dg/proc_ptr_37.f90: New test case.




[cxx-conversion] Fix hash_table build problems with checking enabled.

2012-12-10 Thread Lawrence Crowl
Fix some hash_table build errors when configured with
--enable-checking=yes.

tree-browser.c
   * Remove stale declaration of removed TB_parent_eq.
   * Fix template parameter for base class to match value_type.

gimple.h
   * Use gimplify_hasher::hash rather than gimple_tree_hash in the
   assertion check.
   * Change return values to match return type. (I.e. no conversions.)

Tested on x86-64.

Committing to branch as obvious.


Index: gcc/tree-browser.c
===
--- gcc/tree-browser.c  (revision 194227)
+++ gcc/tree-browser.c  (working copy)
@@ -96,14 +96,13 @@ static tree TB_next_expr (tree);
 static tree TB_up_expr (tree);
 static tree TB_first_in_bind (tree);
 static tree TB_last_in_bind (tree);
-static int  TB_parent_eq (const void *, const void *);
 static tree TB_history_prev (void);

 /* FIXME: To be declared in a .h file.  */
 void browse_tree (tree);

 /* Hashtable helpers.  */
-struct tree_upper_hasher : typed_noop_remove VALUE
+struct tree_upper_hasher : typed_noop_remove tree_node
 {
   typedef tree_node value_type;
   typedef tree_node compare_type;
Index: gcc/gimple.h
===
--- gcc/gimple.h(revision 194227)
+++ gcc/gimple.h(working copy)
@@ -972,18 +972,18 @@ gimplify_hasher::equal (const value_type

   if (TREE_CODE (t2) != code
   || TREE_TYPE (t1) != TREE_TYPE (t2))
-return 0;
+return false;

   if (!operand_equal_p (t1, t2, 0))
-return 0;
+return false;

 #ifdef ENABLE_CHECKING
   /* Only allow them to compare equal if they also hash equal; otherwise
  results are nondeterminate, and we fail bootstrap comparison.  */
-  gcc_assert (gimple_tree_hash (p1) == gimple_tree_hash (p2));
+  gcc_assert (hash (p1) == hash (p2));
 #endif

-  return 1;
+  return true;
 }

 struct gimplify_ctx

-- 
Lawrence Crowl


[GOOGLE] disable streaming out TREE_BLOCK to cure lto-bootstrap

2012-12-10 Thread Dehao Chen
Hi,

The location_block patch has failed lto-bootstrap. This is fixed by a
bunch of fixes in trunk. But we would rather not spend too much effort
to back-port those fixes. So for now, we would disable streaming out
TREE_BLOCK as a workaround to solve to lto-bootstrap.

Bootstrapped and passed crosstool tests.

Okay for google-4_7?

Thanks,
Dehao

gcc/ChangeLog.google-4_7
2012-12-10  Dehao Chen  de...@google.com

* tree-streamer-out.c (write_ts_exp_tree_pointers): Disable
streaming out TREE_BLOCK.
Index: gcc/tree-streamer-out.c
===
--- gcc/tree-streamer-out.c (revision 194378)
+++ gcc/tree-streamer-out.c (working copy)
@@ -667,7 +667,7 @@ write_ts_exp_tree_pointers (struct output_block *o
   for (i = 0; i  TREE_OPERAND_LENGTH (expr); i++)
 stream_write_tree (ob, TREE_OPERAND (expr, i), ref_p);
   lto_output_location (ob, LOCATION_LOCUS (EXPR_LOCATION (expr)));
-  stream_write_tree (ob, TREE_BLOCK (expr), ref_p);
+  stream_write_tree (ob, NULL_TREE, ref_p);
 }


Re: [GOOGLE] disable streaming out TREE_BLOCK to cure lto-bootstrap

2012-12-10 Thread Xinliang David Li
ok.

David

On Mon, Dec 10, 2012 at 9:23 PM, Dehao Chen de...@google.com wrote:
 Hi,

 The location_block patch has failed lto-bootstrap. This is fixed by a
 bunch of fixes in trunk. But we would rather not spend too much effort
 to back-port those fixes. So for now, we would disable streaming out
 TREE_BLOCK as a workaround to solve to lto-bootstrap.

 Bootstrapped and passed crosstool tests.

 Okay for google-4_7?

 Thanks,
 Dehao

 gcc/ChangeLog.google-4_7
 2012-12-10  Dehao Chen  de...@google.com

 * tree-streamer-out.c (write_ts_exp_tree_pointers): Disable
 streaming out TREE_BLOCK.
 Index: gcc/tree-streamer-out.c
 ===
 --- gcc/tree-streamer-out.c (revision 194378)
 +++ gcc/tree-streamer-out.c (working copy)
 @@ -667,7 +667,7 @@ write_ts_exp_tree_pointers (struct output_block *o
for (i = 0; i  TREE_OPERAND_LENGTH (expr); i++)
  stream_write_tree (ob, TREE_OPERAND (expr, i), ref_p);
lto_output_location (ob, LOCATION_LOCUS (EXPR_LOCATION (expr)));
 -  stream_write_tree (ob, TREE_BLOCK (expr), ref_p);
 +  stream_write_tree (ob, NULL_TREE, ref_p);
  }


Re: [GOOGLE] disable streaming out TREE_BLOCK to cure lto-bootstrap

2012-12-10 Thread Andrew Pinski
On Mon, Dec 10, 2012 at 9:23 PM, Dehao Chen de...@google.com wrote:
 Hi,

 The location_block patch has failed lto-bootstrap. This is fixed by a
 bunch of fixes in trunk. But we would rather not spend too much effort
 to back-port those fixes. So for now, we would disable streaming out
 TREE_BLOCK as a workaround to solve to lto-bootstrap.

 Bootstrapped and passed crosstool tests.

 Okay for google-4_7?

Won't this break debugging information even more than it is already
broken with LTO?

Thanks,
Andrew Pinski



 Thanks,
 Dehao

 gcc/ChangeLog.google-4_7
 2012-12-10  Dehao Chen  de...@google.com

 * tree-streamer-out.c (write_ts_exp_tree_pointers): Disable
 streaming out TREE_BLOCK.
 Index: gcc/tree-streamer-out.c
 ===
 --- gcc/tree-streamer-out.c (revision 194378)
 +++ gcc/tree-streamer-out.c (working copy)
 @@ -667,7 +667,7 @@ write_ts_exp_tree_pointers (struct output_block *o
for (i = 0; i  TREE_OPERAND_LENGTH (expr); i++)
  stream_write_tree (ob, TREE_OPERAND (expr, i), ref_p);
lto_output_location (ob, LOCATION_LOCUS (EXPR_LOCATION (expr)));
 -  stream_write_tree (ob, TREE_BLOCK (expr), ref_p);
 +  stream_write_tree (ob, NULL_TREE, ref_p);
  }


Re: [GOOGLE] disable streaming out TREE_BLOCK to cure lto-bootstrap

2012-12-10 Thread Dehao Chen
On Mon, Dec 10, 2012 at 9:30 PM, Andrew Pinski pins...@gmail.com wrote:

 On Mon, Dec 10, 2012 at 9:23 PM, Dehao Chen de...@google.com wrote:
  Hi,
 
  The location_block patch has failed lto-bootstrap. This is fixed by a
  bunch of fixes in trunk. But we would rather not spend too much effort
  to back-port those fixes. So for now, we would disable streaming out
  TREE_BLOCK as a workaround to solve to lto-bootstrap.
 
  Bootstrapped and passed crosstool tests.
 
  Okay for google-4_7?

 Won't this break debugging information even more than it is already
 broken with LTO?

As you said, debug info in LTO is already broken (it can easily
overflow the 32bit integer space for location_t). And you are also
right that this patch will lose debug info (inline stack) for exprs in
google-4_7 branch. But as it just broke something that is already
broken, thus we think it is a reasonable workaround in order to make
lto actually work. When we upgrade to google-4_8, we will
automatically inherit from the trunk fixes.

Thanks,
Dehao


 Thanks,
 Andrew Pinski


 
  Thanks,
  Dehao
 
  gcc/ChangeLog.google-4_7
  2012-12-10  Dehao Chen  de...@google.com
 
  * tree-streamer-out.c (write_ts_exp_tree_pointers): Disable
  streaming out TREE_BLOCK.
  Index: gcc/tree-streamer-out.c
  ===
  --- gcc/tree-streamer-out.c (revision 194378)
  +++ gcc/tree-streamer-out.c (working copy)
  @@ -667,7 +667,7 @@ write_ts_exp_tree_pointers (struct output_block *o
 for (i = 0; i  TREE_OPERAND_LENGTH (expr); i++)
   stream_write_tree (ob, TREE_OPERAND (expr, i), ref_p);
 lto_output_location (ob, LOCATION_LOCUS (EXPR_LOCATION (expr)));
  -  stream_write_tree (ob, TREE_BLOCK (expr), ref_p);
  +  stream_write_tree (ob, NULL_TREE, ref_p);
   }


Re: application/xml mime-type in recent libstdc++ doc changes

2012-12-10 Thread Matthias Klose
Am 10.12.2012 18:52, schrieb Benjamin De Kosnik:
 
 libstdc++-v3/doc/xsl/customization.xsl.in is marked as

   svn:mime-type = application/xml

 at least on the 4.7 branch, having some unexpected outcome for svn
 diff. If this was unintended, could you change the svn:mime-type
 back to text?
 
 This is unintentional, and frankly I don't know how the inital mime
 type was created or how to fix it. Any pointers? Can you do it and tell
 me how?

I did a 'svn propset svn:mime-type text/xml customization.xsl.in', both on the
branch and the trunk. text/xml is the default mime-type for *.xsl files. The
file now appears in svn diff output.

  Matthias



mark expected failures for ppc64 (issue6932046)

2012-12-10 Thread Jing Yu
Add powerpc64-grtev3-linux-gnu.xfail to mark expected failures for
powerpc64 toolchain. For google/gcc_4-7 branch.

Tested:
  ./buildit --build_type=symlinks  --keep_work_dir --run_tests 
gcc-4.7.x-grtev3-powerpc64


2012-12-10  Jing Yu  jin...@google.com
* contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail: New


Index: contrib/ChangeLog.google-4_7
===
--- contrib/ChangeLog.google-4_7(revision 194383)
+++ contrib/ChangeLog.google-4_7(working copy)
@@ -1,3 +1,8 @@
+2012-12-10  Jing Yu  jin...@google.com
+
+   * contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail:
+   New.
+
 2012-11-05  Paul Pluzhnikov  ppluzhni...@google.com
 
* contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail:
Index: contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail
===
--- contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail   
(revision 0)
+++ contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail   
(revision 0)
@@ -0,0 +1,149 @@
+# Marked test failures for v16-powerpc64 toolchain built from
+# v16 release branch @64346, and v16 dev branch @64533.
+# *** gcc:
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O0 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O1 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O2 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O3 -fomit-frame-pointer 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O3 -g 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -Os 
+FAIL: gcc.c-torture/execute/20020226-1.c execution,  -O2 -flto 
-fno-use-linker-plugin -flto-partition=none 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O0 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O1 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O2 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O3 -fomit-frame-pointer 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O3 -g 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -Os 
+FAIL: gcc.c-torture/execute/20020508-1.c execution,  -O2 -flto 
-fno-use-linker-plugin -flto-partition=none 
+FAIL: gcc.dg/and-1.c scan-assembler-not nand
+FAIL: gcc.dg/cleanup-10.c execution test
+FAIL: gcc.dg/cleanup-11.c execution test
+FAIL: gcc.dg/cleanup-8.c execution test
+FAIL: gcc.dg/cleanup-9.c execution test
+FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 global deletions = (2|3)
+FAIL: gcc.dg/pr44194-1.c scan-rtl-dump-not final set \\(mem
+FAIL: gcc.dg/pr46728-6.c scan-assembler-not pow
+
+# These tests succeeded in v15-powerpc64. But they failed in v16-x86 too.
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 10)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 13)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 15)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 18)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 19)
+FAIL: gcc.dg/thread_annot_lock-24.c  (test for warnings, line 8)
+FAIL: gcc.dg/thread_annot_lock-24.c  (test for warnings, line 9)
+FAIL: gcc.dg/thread_annot_lock-24.c  (test for warnings, line 10)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 8)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 9)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 10)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 22)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 30)
+FAIL: gcc.dg/thread_annot_lock-42.c  (test for warnings, line 9)
+
+FAIL: gcc.dg/torture/pr53589.c  -O3 -g  (internal compiler error)
+FAIL: gcc.dg/torture/pr53589.c  -O3 -g  (test for excess errors)
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O0  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O0  -fpic  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O0  -fPIC  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O0  -pie -fpie  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O0  -pie -fPIE  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O1  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O1  -fpic  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O1  -fPIC  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O1  -pie -fpie  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O1  -pie -fPIE  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O2  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O2  -fpic  execution test
+flaky | FAIL: gcc.dg/torture/tls/tls-test.c  -O2  -fPIC  execution test
+flaky | FAIL: