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 outer mode
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.
On Wed, Jun 29, 2011 at 10:35 AM, Sebastian Pop seb...@gmail.com wrote:
2011-06-29 Sebastian Pop sebastian@amd.com
* graphite-clast-to-gimple.c (precision_for_value): Removed.
(precision_for_interval): Removed.
(gcc_type_for_interval): Use mpz_sizeinbase.
---
This
Hallo!
On Tue, 05 Jul 2011 12:19:31 -0700, Ian Lance Taylor i...@google.com wrote:
Thomas Schwinge tho...@schwinge.name 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
On Mon, 4 Jul 2011, Tom G. Christensen wrote:
Latest results for 4.6.x
You're amazing. Thanks a lot, Tom!
Gerald
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
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 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 ja...@redhat.com
Date: Tue Jul 5 21:54:43 2011 -0400
PR
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
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 don't
On Mon, Jul 4, 2011 at 8:09 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
Before http://gcc.gnu.org/viewcvs?root=gccview=revrev=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.
On Tue, Jul 05, 2011 at 10:33:28AM +0200, Richard Guenther wrote:
On Mon, Jul 4, 2011 at 8:09 PM, Jakub Jelinek ja...@redhat.com 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,
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 reset,
Paolo Bonzini bonz...@gnu.org 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
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
On Tue, Jul 5, 2011 at 10:43 AM, Jakub Jelinek ja...@redhat.com 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 ja...@redhat.com wrote:
The second version is simplified one which always treats DECL_WEAK
vars as maybe
On Jul 4, 2011, at 8:09 PM, Rainer Orth wrote:
Joseph S. Myers jos...@codesourcery.com 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
On Tue, 5 Jul 2011, Ira Rosen wrote:
Richard Guenther rguent...@suse.de wrote on 04/07/2011 03:30:59 PM:
Richard Guenther rguent...@suse.de 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
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
===
---
Richard Guenther rguent...@suse.de wrote on 05/07/2011 12:35:24 PM:
On Tue, 5 Jul 2011, Ira Rosen wrote:
Richard Guenther rguent...@suse.de wrote on 04/07/2011 03:30:59 PM:
Richard Guenther rguent...@suse.de wrote on 04/07/2011 02:38:50
PM:
Handling of negative steps broke
Zdenek Dvorak rakd...@kam.mff.cuni.cz wrote on 30/06/2011 15:21:43:
From: Zdenek Dvorak rakd...@kam.mff.cuni.cz
To: Razya Ladelsky/Haifa/IBM@IBMIL
Cc: gcc-patches@gcc.gnu.org, Richard Guenther
richard.guent...@gmail.com
Date: 30/06/2011 15:21
Subject: Re: PATCH] PR 49580
Hi,
This
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.c
Zdenek Dvorak rakd...@kam.mff.cuni.cz wrote on 05/07/2011 13:37:41:
From: Zdenek Dvorak rakd...@kam.mff.cuni.cz
To: Razya Ladelsky/Haifa/IBM@IBMIL
Cc: gcc-patches@gcc.gnu.org, Richard Guenther
richard.guent...@gmail.com
Date: 05/07/2011 13:37
Subject: Re: PATCH] PR 49580
Hi,
I moved
On Tue, Jul 5, 2011 at 1:08 PM, Razya Ladelsky ra...@il.ibm.com wrote:
Zdenek Dvorak rakd...@kam.mff.cuni.cz wrote on 05/07/2011 13:37:41:
From: Zdenek Dvorak rakd...@kam.mff.cuni.cz
To: Razya Ladelsky/Haifa/IBM@IBMIL
Cc: gcc-patches@gcc.gnu.org, Richard Guenther
richard.guent...@gmail.com
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
Hallo!
On Thu, 30 Jun 2011 10:48:02 +0100, Nick Clifton ni...@redhat.com wrote:
2011-06-19 Samuel Thibault samuel.thiba...@gnu.org
* elf.c (_bfd_elf_set_osabi): Use ELFOSABI_GNU name instead
of ELFOSABI_LINUX alias.
* elf32-hppa.c (elf32_hppa_object_p): Likewise.
*
Hallo!
On Wed, 29 Jun 2011 10:40:10 +0200, Paolo Bonzini bonz...@gnu.org 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.
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
---
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
Hallo!
On Tue, 05 Jul 2011 13:52:08 +0200, Rainer Orth r...@cebitec.uni-bielefeld.de
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.
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 they
(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
wschm...@linux.vnet.ibm.com wrote:
This is the first of three patches related to lowering addressing
expressions to
Ping.
On Sat, Jun 25, 2011 at 9:20 AM, H.J. Lu hongjiu...@intel.com 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 hongjiu...@intel.com
PR
On 07/05/2011 02:13 PM, Thomas Schwinge wrote:
Hallo!
On Tue, 05 Jul 2011 13:52:08 +0200, Rainer Orthr...@cebitec.uni-bielefeld.de
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.
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
anything
On Tue, Jul 5, 2011 at 4:07 PM, H.J. Lu hjl.to...@gmail.com 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
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
On Tue, Jul 5, 2011 at 7:15 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Jul 5, 2011 at 4:07 PM, H.J. Lu hjl.to...@gmail.com 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.
Ping.
On Sat, Jun 11, 2011 at 8:58 AM, H.J. Lu hongjiu...@intel.com 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.
---
On Tue, Jul 5, 2011 at 4:25 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Jul 5, 2011 at 7:15 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Jul 5, 2011 at 4:07 PM, H.J. Lu hjl.to...@gmail.com wrote:
Ping.
That doesn't look correct without also ensuring we never create a
OK.
Jason
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
On Tue, Jul 5, 2011 at 7:30 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Jul 5, 2011 at 4:25 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Jul 5, 2011 at 7:15 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Jul 5, 2011 at 4:07 PM, H.J. Lu hjl.to...@gmail.com
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-promoted
PING.
On Fri, Jul 1, 2011 at 9:37 AM, Richard Sandiford
richard.sandif...@linaro.org wrote:
H.J. Lu hjl.to...@gmail.com writes:
On Wed, Jun 29, 2011 at 7:06 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Jun 29, 2011 at 1:45 AM, Richard Sandiford
richard.sandif...@linaro.org wrote:
H.J. Lu
On Tue, Jul 5, 2011 at 7:42 AM, Ulrich Weigand uweig...@de.ibm.com 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
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
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
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 needs
On Tue, Jul 5, 2011 at 4:39 PM, H.J. Lu hongjiu...@intel.com 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
On Tue, Jul 5, 2011 at 4:45 PM, H.J. Lu hjl.to...@gmail.com wrote:
PING.
Ok.
Thanks,
Richard.
On Fri, Jul 1, 2011 at 9:37 AM, Richard Sandiford
richard.sandif...@linaro.org wrote:
H.J. Lu hjl.to...@gmail.com writes:
On Wed, Jun 29, 2011 at 7:06 AM, H.J. Lu hjl.to...@gmail.com wrote:
On
On Tue, Jul 5, 2011 at 4:56 PM, Ulrich Weigand uweig...@de.ibm.com 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
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
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.
Richard Guenther wrote:
On Tue, Jul 5, 2011 at 4:56 PM, Ulrich Weigand uweig...@de.ibm.com 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
Quoting Joseph S. Myers jos...@codesourcery.com:
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
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 include
On Wed, Jun 1, 2011 at 7:49 PM, Ian Lance Taylor i...@google.com 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.
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 should
On Tue, Jul 5, 2011 at 8:24 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Jul 5, 2011 at 4:56 PM, Ulrich Weigand uweig...@de.ibm.com 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.
On Jul 5, 2011, at 9:51 AM, Uros Bizjak ubiz...@gmail.com 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,
On Tue, Jul 5, 2011 at 7:17 PM, Mike Stump mikest...@comcast.net wrote:
On Jul 5, 2011, at 9:51 AM, Uros Bizjak ubiz...@gmail.com 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
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
On Tue, Jul 5, 2011 at 8:16 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Jul 5, 2011 at 4:39 PM, H.J. Lu hongjiu...@intel.com 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
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
that we can
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.
On Tue, Jul 5, 2011 at 7:54 PM, H.J. Lu hjl.to...@gmail.com 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
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
On Tue, Jul 5, 2011 at 11:14 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Jul 5, 2011 at 7:54 PM, H.J. Lu hjl.to...@gmail.com 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
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,
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
+++
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. The patch
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01642.html is still pending
review.
--
Joseph S. Myers
jos...@codesourcery.com
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.
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,
Thomas Schwinge tho...@schwinge.name 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
On Tue, Jul 5, 2011 at 8:49 PM, H.J. Lu hjl.to...@gmail.com 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 } \
77 matches
Mail list logo
