Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area

On 07/05/2011 01:54 AM, Alan Modra wrote: > Before that, fwprop never tries to work on hard registers. I question this claim. It seems to me that fwprop did look at paradoxical subregs of hard regs before my change. That wasn't part of the design anyway. The main purpose of fwprop's parad

Re: [PATCH] Fix bootstrap on OpenBSD, PR48851

On Mon, 4 Jul 2011, Mike Stump wrote: > On Jul 4, 2011, at 4:04 AM, Richard Guenther wrote: > > It happens that OpenBSD suffers from a bogus fixinclude that changes > > its perfectly valid NULL define from (void *)0 to 0. The fix itself > > appears to be very old and is completely bogus > > I do

Re: [PATCH] Fix tree_could_trap_p so that weak var accesses are considered trapping (PR tree-optimization/49618)

On Mon, Jul 4, 2011 at 8:09 PM, Jakub Jelinek wrote: > Hi! > > Before http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168951 > set_mem_attributes_minus_bitpos would set MEM_NOTRAP_P for decls > based on whether they are DECL_WEAK or not, but now it is set only > from !tree_could_trap_p. > > These

Re: [PATCH] Fix tree_could_trap_p so that weak var accesses are considered trapping (PR tree-optimization/49618)

On Tue, Jul 05, 2011 at 10:33:28AM +0200, Richard Guenther wrote: > On Mon, Jul 4, 2011 at 8:09 PM, Jakub Jelinek wrote: > > The second version is simplified one which always treats DECL_WEAK > > vars as maybe trapping.  Ok for 4.6? > > The trunk version is ok. For the 4.6 version, don't you nee

Re: [PATCH] Fix dead_debug_insert_before ICE (PR debug/49522)

> There are two kinds of changes we do on the debug insns without immediate > rescanning: > 1) reset the debug insn > 2) replace a reg use with DEBUG_EXPR of the same mode or >subreg of a larger DEBUG_EXPR with the same outer mode as the reg > > In the attached testcase on arm a debug insn is r

Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area

Paolo Bonzini writes: > On 07/05/2011 01:54 AM, Alan Modra wrote: >> > Before that, fwprop never tries to work on hard registers. >> >> I question this claim. It seems to me that fwprop did look at >> paradoxical subregs of hard regs before my change. > > That wasn't part of the design anyway.

Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area

On 07/05/2011 10:51 AM, Richard Sandiford wrote: > The patch is okay as far as I'm concerned, but I'm not a maintainer of > fwprop. You probably should be:-) I'd have no problem with that! Paolo

Re: [PATCH] Fix tree_could_trap_p so that weak var accesses are considered trapping (PR tree-optimization/49618)

On Tue, Jul 5, 2011 at 10:43 AM, Jakub Jelinek wrote: > On Tue, Jul 05, 2011 at 10:33:28AM +0200, Richard Guenther wrote: >> On Mon, Jul 4, 2011 at 8:09 PM, Jakub Jelinek wrote: >> > The second version is simplified one which always treats DECL_WEAK >> > vars as maybe trapping.  Ok for 4.6? >> >>

[testsuite]: Fix testcases that need int >= 32 bits.

There are still testcase that break on targets with int < 32 bits. CCed contributors. Johann * gcc.dg/pr44023.c: Add dg-require-effective-target int32plus * gcc.dg/pr43402.c: Ditto. Index: gcc.dg/pr43402.c === --- gc

Re: CFT: Move unwinder to toplevel libgcc

On Jul 4, 2011, at 8:09 PM, Rainer Orth wrote: > "Joseph S. Myers" writes: > >> On Mon, 20 Jun 2011, Rainer Orth wrote: >> >>> * Move all remaining unwinder-only macros to libgcc: UNW_IVMS_MODE, >>> MD_UNW_COMPATIBLE_PERSONALITY_P, MD_FROB_UPDATE_CONTEXT. >> >> I don't see any sign of macros

Re: [PATCH] Fix PR49518

On Tue, 5 Jul 2011, Ira Rosen wrote: > Richard Guenther wrote on 04/07/2011 03:30:59 PM: > > > > > > Richard Guenther wrote on 04/07/2011 02:38:50 PM: > > > > > > > Handling of negative steps broke one of the many asserts in > > > > the vectorizer. The following patch drops one that I can't > >

[testsuite]: Add require fopenmp as needed

There is a testcase that fails if no openmp is available. This patch fixed that. CCed contributor. Johann * gcc.dg/cpp/pragma-3.c: Add dg-require-effective-target fopenmp. Index: gcc.dg/cpp/pragma-3.c === --- gcc.dg/cpp/pr

Re: [PATCH] Fix PR49518

Richard Guenther wrote on 05/07/2011 12:35:24 PM: > > On Tue, 5 Jul 2011, Ira Rosen wrote: > > > Richard Guenther wrote on 04/07/2011 03:30:59 PM: > > > > > > > > Richard Guenther wrote on 04/07/2011 02:38:50 PM: > > > > > > > > > Handling of negative steps broke one of the many asserts in >

Re: PATCH] PR 49580

Zdenek Dvorak wrote on 30/06/2011 15:21:43: > From: Zdenek Dvorak > To: Razya Ladelsky/Haifa/IBM@IBMIL > Cc: gcc-patches@gcc.gnu.org, Richard Guenther > Date: 30/06/2011 15:21 > Subject: Re: PATCH] PR 49580 > > Hi, > > > This patch fixes the build failure of gcc spec2006 benchmark. > > The c

Re: PATCH] PR 49580

Hi, > I moved the adjustment of the loop's iterations from > gimple_duplicate_sese_tail > to tree-parloops.c, right before the call to gimple_duplicate_sese_tail. > I repeated the bootstrap, regression and spec runs - no new regressions. > > OK to commit? OK, Zdenek > Index: gcc/tree-parloops

Re: PATCH] PR 49580

Zdenek Dvorak wrote on 05/07/2011 13:37:41: > From: Zdenek Dvorak > To: Razya Ladelsky/Haifa/IBM@IBMIL > Cc: gcc-patches@gcc.gnu.org, Richard Guenther > Date: 05/07/2011 13:37 > Subject: Re: PATCH] PR 49580 > > Hi, > > > I moved the adjustment of the loop's iterations from > > gimple_duplic

Re: PATCH] PR 49580

On Tue, Jul 5, 2011 at 1:08 PM, Razya Ladelsky wrote: > Zdenek Dvorak wrote on 05/07/2011 13:37:41: > >> From: Zdenek Dvorak >> To: Razya Ladelsky/Haifa/IBM@IBMIL >> Cc: gcc-patches@gcc.gnu.org, Richard Guenther > >> Date: 05/07/2011 13:37 >> Subject: Re: PATCH] PR 49580 >> >> Hi, >> >> > I mov

[PATCH][C][C++] Move common tree node building to c_common_nodes_and_builtins

This consolidates build_common_tree_nodes and build_common_tree_nodes_2 at a single place in c_common_nodes_and_builtins for C family languages. It is a preparation for merging those two functions and moving them to be called from toplev.c as they are middle-end inits. Bootstrapped and tested on

[PATCH, go] Re: Should rename ELFOSABI_LINUX into ELFOSABI_GNU, and drop ELFOSABI_HURD

Hallo! On Thu, 30 Jun 2011 10:48:02 +0100, Nick Clifton wrote: > > 2011-06-19 Samuel Thibault > > > >* elf.c (_bfd_elf_set_osabi): Use ELFOSABI_GNU name instead > >of ELFOSABI_LINUX alias. > >* elf32-hppa.c (elf32_hppa_object_p): Likewise. > >* elf64-hppa.c (elf32_hppa_ob

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

Hallo! On Wed, 29 Jun 2011 10:40:10 +0200, Paolo Bonzini wrote: > On 06/21/2011 12:04 PM, Rainer Orth wrote: > > For md_unwind_header on the other hand, you'd have almost as many cases > > as in the general case. I fear it's hard to have the configuration > > split over too many places. So I'd

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

Hi Thomas, > Like this? > > > libgcc/ > config.host: Use i386/linux-unwind.h only for *-*-linux*. > > --- > libgcc/config.host | 10 -- > 1 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/libgcc/config.host b/libgcc/config.host > index 326ce91..1d5b887 100644

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

On 07/05/2011 01:52 PM, Rainer Orth wrote: Instead of nested cases, I'd rather use one i[34567]86-*-linux* case and another for the rest, duplicating extra_parts and tmake_file. Same for x86_64-*-linux* vs. the rest. But that's just me. I agree. Paolo

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

Hallo! On Tue, 05 Jul 2011 13:52:08 +0200, Rainer Orth wrote: > > Like this? [...] > > Instead of nested cases, I'd rather use one i[34567]86-*-linux* case and > another for the rest, duplicating extra_parts and tmake_file. Same for > x86_64-*-linux* vs. the rest. > > But that's just me. My

Re: [PATCH][C][C++] Move common tree node building to c_common_nodes_and_builtins

On Tue, 5 Jul 2011, Richard Guenther wrote: > This consolidates build_common_tree_nodes and build_common_tree_nodes_2 > at a single place in c_common_nodes_and_builtins for C family languages. > It is a preparation for merging those two functions and moving them > to be called from toplev.c as the

Re: [PATCH] Address lowering [1/3] Main patch

(Sorry for the late response; yesterday was a holiday here.) On Mon, 2011-07-04 at 16:21 +0200, Richard Guenther wrote: > On Thu, Jun 30, 2011 at 4:39 PM, William J. Schmidt > wrote: > > This is the first of three patches related to lowering addressing > > expressions to MEM_REFs and TARGET_MEM_R

PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

Ping. On Sat, Jun 25, 2011 at 9:20 AM, H.J. Lu wrote: > Hi, > > I was informed that MEM_REF only works in ptr_mode.  This patch changes > addr_for_mem_ref to use ptr_mode.  OK for trunk? > > Thanks. > > > H.J. > --- > 2011-06-25  H.J. Lu   > >        PR middle-end/47383 >        * tree-ssa-addre

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

On 07/05/2011 02:13 PM, Thomas Schwinge wrote: Hallo! On Tue, 05 Jul 2011 13:52:08 +0200, Rainer Orth wrote: Like this? [...] Instead of nested cases, I'd rather use one i[34567]86-*-linux* case and another for the rest, duplicating extra_parts and tmake_file. Same for x86_64-*-linux* vs.

Re: [PATCH] Address lowering [1/3] Main patch

On Mon, 2011-07-04 at 17:30 +0200, Michael Matz wrote: > Hi, > > On Mon, 4 Jul 2011, Richard Guenther wrote: > > > I still do not like the implementation of yet another CSE machinery > > given that we already have two. > > From reading it it really seems to be a normal block-local CSE, without

Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

On Tue, Jul 5, 2011 at 4:07 PM, H.J. Lu wrote: > Ping. That doesn't look correct without also ensuring we never create a TARGET_MEM_REF with a base that is not in the default address-space. In fact, with this patch the address-space argument to addr_for_mem_ref should go away or we need a hook th

Re: [PATCH] Address lowering [1/3] Main patch

Hi, On Tue, 5 Jul 2011, William J. Schmidt wrote: > Hm, I didn't think it was (currently) possible for a gimple statement to > have a mem-ref on both RHS and LHS. Is that incorrect? This is easily > changed if so, or if the possibility should be left open for the future. Think aggregate copi

Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

On Tue, Jul 5, 2011 at 7:15 AM, Richard Guenther wrote: > On Tue, Jul 5, 2011 at 4:07 PM, H.J. Lu wrote: >> Ping. > > That doesn't look correct without also ensuring we never create a > TARGET_MEM_REF with a base that is not in the default address-space. > In fact, with this patch the address-spa

PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

Ping. On Sat, Jun 11, 2011 at 8:58 AM, H.J. Lu wrote: > Hi, > > convert_memory_address_addr_space has a special PLUS/MULT case for > POINTERS_EXTEND_UNSIGNED < 0.  It turns out that it is also needed > for all Pmode != ptr_mode cases.  OK for trunk? > > Thanks. > > > H.J. > --- > 2011-06-11  H.J.

Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

On Tue, Jul 5, 2011 at 4:25 PM, H.J. Lu wrote: > On Tue, Jul 5, 2011 at 7:15 AM, Richard Guenther > wrote: >> On Tue, Jul 5, 2011 at 4:07 PM, H.J. Lu wrote: >>> Ping. >> >> That doesn't look correct without also ensuring we never create a >> TARGET_MEM_REF with a base that is not in the default

Re: [PATCH][C][C++] Move common tree node building to c_common_nodes_and_builtins

OK. Jason

PATCH [1/n] X32: Add initial -x32 support

Hi, I'd like to start submitting a series of patches to enable x32: https://sites.google.com/site/x32abi/ The GCC x32 branch is very stable. There are no unexpected failures in C, C++, Fortran and Objective C testsuites. SPEC CPU 2K/2006 compile and run correctly at -O2 and -O3. More than 90%

Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

On Tue, Jul 5, 2011 at 7:30 AM, Richard Guenther wrote: > On Tue, Jul 5, 2011 at 4:25 PM, H.J. Lu wrote: >> On Tue, Jul 5, 2011 at 7:15 AM, Richard Guenther >> wrote: >>> On Tue, Jul 5, 2011 at 4:07 PM, H.J. Lu wrote: Ping. >>> >>> That doesn't look correct without also ensuring we never c

Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

Richard Guenther wrote: > That doesn't look correct without also ensuring we never create a > TARGET_MEM_REF with a base that is not in the default address-space. > In fact, with this patch the address-space argument to addr_for_mem_ref > should go away or we need a hook that provides a non-promot

PING: PATCH [2/n]: Prepare x32: PR middle-end/47715: Convert pointer to TLS symbol if needed

PING. On Fri, Jul 1, 2011 at 9:37 AM, Richard Sandiford wrote: > "H.J. Lu" writes: >> On Wed, Jun 29, 2011 at 7:06 AM, H.J. Lu wrote: >>> On Wed, Jun 29, 2011 at 1:45 AM, Richard Sandiford >>> wrote: "H.J. Lu" writes: > @@ -706,7 +706,13 @@ precompute_register_parameters (int num_act

Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

On Tue, Jul 5, 2011 at 7:42 AM, Ulrich Weigand wrote: > Richard Guenther wrote: > >> That doesn't look correct without also ensuring we never create a >> TARGET_MEM_REF with a base that is not in the default address-space. >> In fact, with this patch the address-space argument to addr_for_mem_ref

RFA: Making attribute values avaliable for options

There is often an enum corresponding to a target.md attribute that you want as numeric values for an Enum option declaration. Alas, insn-attr.h is not included by options.c, and an attempt to include it with the HeaderInclude record is doomed because of all the headers that insn-attr.h requires t

C++ PATCH for c++/49598 (ICE with value capture of reference)

Need to convert_from_reference a decl that we're using as a normal expression, as in this case as an initializer. Tested x86_64-pc-linux-gnu, applying to trunk. commit b5c0742c0bfe7fe58dba443d47f880c26eea1b82 Author: Jason Merrill Date: Tue Jul 5 01:13:04 2011 -0400 PR c++/49598 *

[PATCH] Merge build_common_tree_nodes and build_common_tree_nodes_2

This merges the two common tree node creation functions now that all callers are sufficiently close to make frontend pieces obvious. Pending bootstrap and regtest on x86_64-unknown-linux-gnu, I will commit this tomorrow unless somebody objects by then. Richard. 2011-07-05 Richard Guenther

Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

H.J. Lu wrote: > > However, this still seems odd to me, as I had understood the address in > > a TARGET_MEM_REF needs to be an *address*, i.e. use address_mode. =A0If > > this is not true (has changed?) a lot of other places would need to > > change as well ... > > I was told that TARGET_MEM_REF

Re: PATCH [1/n] X32: Add initial -x32 support

On Tue, Jul 5, 2011 at 4:39 PM, H.J. Lu wrote: > I'd like to start submitting a series of patches to enable x32: > > https://sites.google.com/site/x32abi/ > > The GCC x32 branch is very stable. There are no unexpected failures in > C, C++, Fortran and Objective C testsuites.  SPEC CPU 2K/2006 com

Re: PING: PATCH [2/n]: Prepare x32: PR middle-end/47715: Convert pointer to TLS symbol if needed

On Tue, Jul 5, 2011 at 4:45 PM, H.J. Lu wrote: > PING. Ok. Thanks, Richard. > On Fri, Jul 1, 2011 at 9:37 AM, Richard Sandiford > wrote: >> "H.J. Lu" writes: >>> On Wed, Jun 29, 2011 at 7:06 AM, H.J. Lu wrote: On Wed, Jun 29, 2011 at 1:45 AM, Richard Sandiford wrote: > "H.J. L

Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

On Tue, Jul 5, 2011 at 4:56 PM, Ulrich Weigand wrote: > H.J. Lu wrote: > >> > However, this still seems odd to me, as I had understood the address in >> > a TARGET_MEM_REF needs to be an *address*, i.e. use address_mode. =A0If >> > this is not true (has changed?) a lot of other places would need t

Re: RFA: Making attribute values avaliable for options

On Tue, 5 Jul 2011, Joern Rennecke wrote: > This patch splits out a new generator genattr-enum from genattr, and it > generates insn-attr-enum.h, which just makes the enum declarations. > This new header file is then included by options.c and insn-attr.h . Is there a particular reason for making

Re: Ping: C-family stack check for threads

On 07/04/2011 03:25 PM, Thomas Klein wrote: > There is a emit_multi_reg_push but is there something like > emit_multi_reg_pop, too. There's a multi-reg push because that's one instruction. > Are the other operations (compare, branche, ..) still allowed? Of course. Everything is still allowed.

Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

Richard Guenther wrote: > On Tue, Jul 5, 2011 at 4:56 PM, Ulrich Weigand wrote: > > Can you elaborate? =A0We are talking about the mode returned from > > addr_for_mem_ref here. =A0I do now understand how this can be anything > > but an address mode: > > That is an address mode, but the intermedia

Re: RFA: Making attribute values avaliable for options

Quoting "Joseph S. Myers" : On Tue, 5 Jul 2011, Joern Rennecke wrote: This patch splits out a new generator genattr-enum from genattr, and it generates insn-attr-enum.h, which just makes the enum declarations. This new header file is then included by options.c and insn-attr.h . Is there a pa

Re: RFA: Making attribute values avaliable for options

On Tue, 5 Jul 2011, Joern Rennecke wrote: > > Like opts.c, options.c is a file > > shared by both the driver and the core compiler that can't include the > > full insn-attr.h for the same reason. > > Well, FWIW, at the moment, I can actually build both cc1 and xgcc when > I hand-edit options.c to

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

On Wed, Jun 1, 2011 at 7:49 PM, Ian Lance Taylor wrote: One problem remains in the libgo testsuite: certain tests have to be compiled with -mieee, otherwise FPE is generated for unordered values. Any suggestions, where -mieee should be placed? >>> >>> That's an interesting question

Re: [PATCH] Address lowering [1/3] Main patch

On Mon, 2011-07-04 at 17:30 +0200, Michael Matz wrote: > From reading it it really seems to be a normal block-local CSE, without > anything fancy. Hence, moving the pass just a little earlier (before > pass_vrp/pass_dominator) should already provide for all optimizations. If > not those shoul

Re: PING: PATCH [9/n]: Prepare x32: PR middle-end/47383: ivopts miscompiles Pmode != ptr_mode

On Tue, Jul 5, 2011 at 8:24 AM, Richard Guenther wrote: > On Tue, Jul 5, 2011 at 4:56 PM, Ulrich Weigand wrote: >> H.J. Lu wrote: >> >>> > However, this still seems odd to me, as I had understood the address in >>> > a TARGET_MEM_REF needs to be an *address*, i.e. use address_mode. =A0If >>> > th

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

On Jul 5, 2011, at 9:51 AM, Uros Bizjak wrote: > Attached patch also does the trick for me. > Please note that we set > -mieee flag to compile .go files from library and also we add this > flag to default testsuite compile flags. > Ick, I think this patch might be expedient, but, wrong. Ian wi

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

On Tue, Jul 5, 2011 at 7:17 PM, Mike Stump wrote: > On Jul 5, 2011, at 9:51 AM, Uros Bizjak wrote: >> Attached patch also does the trick for me. > >> Please note that we set >> -mieee flag to compile .go files from library and also we add this >> flag to default testsuite compile flags. > >> > Ic

Re: [testsuite]: Add require fopenmp as needed

On Jul 5, 2011, at 3:07 AM, Georg-Johann Lay wrote: > There is a testcase that fails if no openmp is available. > > This patch fixed that. > > CCed contributor. Not quite sure what this means. So, on patches you want approval on, the custom is to ask Ok? so that we can quickly tell which need

Re: PATCH [1/n] X32: Add initial -x32 support

On Tue, Jul 5, 2011 at 8:16 AM, Uros Bizjak wrote: > On Tue, Jul 5, 2011 at 4:39 PM, H.J. Lu wrote: > >> I'd like to start submitting a series of patches to enable x32: >> >> https://sites.google.com/site/x32abi/ >> >> The GCC x32 branch is very stable. There are no unexpected failures in >> C, C

Re: [testsuite]: Add require fopenmp as needed

Mike Stump wrote: > On Jul 5, 2011, at 3:07 AM, Georg-Johann Lay wrote: >> There is a testcase that fails if no openmp is available. >> >> This patch fixed that. >> >> CCed contributor. > > Not quite sure what this means. > > So, on patches you want approval on, the custom is to ask Ok? so > th

Re: [testsuite]: Fix testcases that need int >= 32 bits.

On Jul 5, 2011, at 2:02 AM, Georg-Johann Lay wrote: > There are still testcase that break on targets with int < 32 bits. [ Be sure to ask Ok? ] Ok.

Re: PATCH [1/n] X32: Add initial -x32 support

On Tue, Jul 5, 2011 at 7:54 PM, H.J. Lu wrote: >>> I'd like to start submitting a series of patches to enable x32: >>> >>> https://sites.google.com/site/x32abi/ >>> >>> The GCC x32 branch is very stable. There are no unexpected failures in >>> C, C++, Fortran and Objective C testsuites.  SPEC CPU

Re: [patch, fortran] Always return malloc(1) for empty arrays in the library

Hi Janne, Since size_t is unsigned, just test (size == 0). Otherwise Ok. Thanks for the patch. OK. Übertrage Daten ... Revision 175880 übertragen. Thanks for the review! Thomas

Re: PATCH [1/n] X32: Add initial -x32 support

On Tue, Jul 5, 2011 at 11:14 AM, Uros Bizjak wrote: > On Tue, Jul 5, 2011 at 7:54 PM, H.J. Lu wrote: > I'd like to start submitting a series of patches to enable x32: https://sites.google.com/site/x32abi/ The GCC x32 branch is very stable. There are no unexpected failures

Re: PATCH [1/n] X32: Add initial -x32 support

On Tue, 5 Jul 2011, H.J. Lu wrote: > > I really think that "!(m64|mx32)" is more descriptive and clear... > > I don't know if gcc spec supports it. I just followed mips backend. Indeed, I don't think any such grouping construct exists in specs. The .opt changes look fine to me. -- Joseph S.

Re: [2/11] Neater tests for signbits

On 07/01/2011 10:29 AM, Bernd Schmidt wrote: > * cse.c (find_comparison_args): Use val_mode_signbit_set_p. > * simplify-rtx.c (mode_signbit_p): Use GET_MODE_PRECISION. > (val_mode_signbit_p, val_mode_signbit_set_p): New functions. > (simplify_const_unary_operation, simplify_

Re: [3/11] Remove some dead code

On 07/01/2011 10:30 AM, Bernd Schmidt wrote: > * simplify-rtx.c (simplify_ternary_operation): Remove dead code. > > Index: baseline-trunk/gcc/simplify-rtx.c > === > --- baseline-trunk.orig/gcc/simplify-rtx.c > +++ baseline-trunk

Re: [4/11] Use precisions for TRULY_NOOP_TRUNCATION

On 07/01/2011 10:31 AM, Bernd Schmidt wrote: > * machmode.h (TRULY_NOOP_TRUNCATION_MODES_P): New macro. > * combine.c (make_extraction, gen_lowpart_or_truncate, > apply_distributive_law, simplify_comparison, > reg_truncated_to_mode, record_truncated_value): Use it. > *

Ping^2: TARGET_HAVE_NAMED_SECTIONS cleanup

Ping^2. The patch is still pending review. -- Joseph S. Myers jos...@codesourcery.com

Re: [5/11] Neater tests for paradoxical subregs

On 07/01/2011 10:33 AM, Bernd Schmidt wrote: > * emit-rtl.c (paradoxical_subreg_p): New function. > * rtl.h (paradoxical_subreg_p): Declare. > * combine.c (set_nonzero_bits_and_sign_copies, get_last_value, > apply_distributive_law, simplify_comparison, simplify_set): Use it.

Re: [6/11] Tests for HOST_WIDE_INT representability

On 07/01/2011 10:34 AM, Bernd Schmidt wrote: > * machmode.h (HWI_COMPUTABLE_MODE_P): New macro. > * combine.c (set_nonzero_bits_and_sign_copies): Use it. > (find_split-point, combine_simplify_rtx, simplify_if_then_else, > simplify_set, simplify_logical, expand_compound_opera

Re: [PATCH, go] Re: Should rename ELFOSABI_LINUX into ELFOSABI_GNU, and drop ELFOSABI_HURD

Thomas Schwinge writes: > The only ELFOSABI_* occurrences in GCC trunk are in libgo. > > Ian, what do you think about the following patch (untested -- what > testing does this need)? Is it even worth keeping the ELFOSABI_LINUX > alias? (It can never be returned via osabiStrings.) These files a

Re: Generic hwloop support library

Bernd Schmidt writes: >> Is there no possibility of running the optimisation in cfglayout mode >> instead? It seems from this and the forwarder block stuff above as >> though it might make things easier, but maybe not. > > I'm not sure what you mean here. This reordering isn't for the sake of > t

Re: PATCH [1/n] X32: Add initial -x32 support

On Tue, Jul 5, 2011 at 8:49 PM, H.J. Lu wrote: >>  #undef LINK_SPEC >>  #define LINK_SPEC "%{" SPEC_64 ":-m " GNU_USER_LINK_EMULATION64 "} \ >>                    %{" SPEC_32 ":-m " GNU_USER_LINK_EMULATION32 "} \ >> +                   %{" SPEC_X32 ":-m " GNU_USER_LINK_EMULATIONX32 "} \ >>   %{sh

Re: [PATCH] Fix dead_debug_insert_before ICE (PR debug/49522)

On Tue, Jul 05, 2011 at 10:35:11AM +0200, Eric Botcazou wrote: > > There are two kinds of changes we do on the debug insns without immediate > > rescanning: > > 1) reset the debug insn > > 2) replace a reg use with DEBUG_EXPR of the same mode or > >subreg of a larger DEBUG_EXPR with the same ou

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

Uros Bizjak writes: > What remains is a couple of unrelated failures in the testsuite: > > Epoll unexpected fd=0 > pollServer: unexpected wakeup for fd=0 mode=w > panic: test timed out > ../../../gcc-svn/trunk/libgo/testsuite/gotest: line 388: 7123 Aborted > ./a.out -test.short -

Re: [2/11] Neater tests for signbits

On 07/05/11 21:08, Richard Henderson wrote: > On 07/01/2011 10:29 AM, Bernd Schmidt wrote: >> * cse.c (find_comparison_args): Use val_mode_signbit_set_p. >> * simplify-rtx.c (mode_signbit_p): Use GET_MODE_PRECISION. >> (val_mode_signbit_p, val_mode_signbit_set_p): New functions. >>

Re: [PATCH 4/6] Fix computation of precision.

On Wed, Jun 29, 2011 at 10:35 AM, Sebastian Pop wrote: > 2011-06-29  Sebastian Pop   > >        * graphite-clast-to-gimple.c (precision_for_value): Removed. >        (precision_for_interval): Removed. >        (gcc_type_for_interval): Use mpz_sizeinbase. > --- This caused: http://gcc.gnu.org/bug

Re: [PATCH, go] Re: Should rename ELFOSABI_LINUX into ELFOSABI_GNU, and drop ELFOSABI_HURD

Hallo! On Tue, 05 Jul 2011 12:19:31 -0700, Ian Lance Taylor wrote: > Thomas Schwinge writes: > > > The only ELFOSABI_* occurrences in GCC trunk are in libgo. > > > > Ian, what do you think about the following patch (untested -- what > > testing does this need)? Is it even worth keeping the ELF

Re: [wwwdocs] Buildstat update for 4.6

On Mon, 4 Jul 2011, Tom G. Christensen wrote: > Latest results for 4.6.x You're amazing. Thanks a lot, Tom! Gerald

[pph] Do not clobber unemitted_tinfo_decls and keyed_classes (issue4636085)

This patch removes a FIXME in pph_read_file_contents. Instead of clobbering unemitted_tinfo_decls and keyed_classes, we should add to the existing ones. No new fixes, but this helps with the next patch. Tested on x86_64. Committed to branch. Diego. * pph-streamer-in.c (pph_read_fil

[pph] Stream and restore static_aggregates (issue4626096)

This patch is a partial fix for c1eabi1.cc. We were missing static initializers. There is another source of assembly difference in that file, so I still need to dig some more. This fixes x2nontrivinit.cc, however. I am still not happy with the way we add bindings and symbols to namespaces. We

C++ PATCH for c++/48157 (loss of explicit template args in member template signature)

We were accidentally discarding the args from a template-id when doing a partial instantiation of a qualified-id. Tested x86_64-pc-linux-gnu, applying to trunk. commit 50ab88c80a398570a84f65802c3e004e46f27eeb Author: Jason Merrill Date: Tue Jul 5 21:54:43 2011 -0400 PR c++/48157 *