Liu [pro...@gmail.com] wrote:
OK, I get.
But, sorry, my mips64dspr2 patch has be done...
Should I summit it?
I just wonder what version of the MIPS64 DSP/DSPr2 spec that you implemented.
Do you have a target CPU that has these MIPS64 DSP/DSPr2 instructions? My
concern is that the latest
Hi,
It seems loop-iv.c happily creates shared RTL in lots of places,
loop-unroll.c solves that by unsharing everything it adds, this is
an attempt to do the same in unswitching to unshare everything iv_analyze
came up with.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
On Fri, Feb 3, 2012 at 3:59 PM, Fu, Chao-Ying f...@mips.com wrote:
Liu [pro...@gmail.com] wrote:
OK, I get.
But, sorry, my mips64dspr2 patch has be done...
Should I summit it?
I just wonder what version of the MIPS64 DSP/DSPr2 spec that you
implemented. Do you have a target CPU that has
On 02/02/2012 06:47 PM, Kai Tietz wrote:
2012-02-02 Kai Tietz kti...@redhat.com
PR libjava/48512
* configure.ac (THREADSTARTFILESPEC): Don't add crtmet.o file for
w64 windows targets.
* configure: Regenerated.
Tested for i686-w64-mingw32, and
On Thu, Feb 02, 2012 at 09:10:50PM -0700, Sandra Loosemore wrote:
--- gcc/testsuite/g++.dg/torture/pr51910.C(revision 0)
+++ gcc/testsuite/g++.dg/torture/pr51910.C(revision 0)
@@ -0,0 +1,19 @@
+// PR c++/51910
+// Check that -frepo works in the presence of linker symbol demangling.
On Thu, 2 Feb 2012, Jakub Jelinek wrote:
Hi!
It seems loop-iv.c happily creates shared RTL in lots of places,
loop-unroll.c solves that by unsharing everything it adds, this is
an attempt to do the same in unswitching to unshare everything iv_analyze
came up with.
Bootstrapped/regtested
Hi Richard,
Sorry for the delay to respond, and thanks for revising and committing
the changes to trunk. The revised changes look much cleaner :)
About the other concerns:
(2) is interesting if there is also a way to build those MIPS16 libraries
out of the box. I'd like such a mechanism to
Hi!
I'd like to ping 3 patches:
- http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01335.html
PR debug/51950
-gdwarf-4 -fdebug-types-section cloning bug
- http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00034.html
PR middle-end/52074
fix EXPAND_NORMAL expansion with -fsection-anchors
-
On Thu, Feb 2, 2012 at 8:00 PM, Patrick Marlier
patrick.marl...@gmail.com wrote:
On 02/02/2012 04:22 AM, Richard Guenther wrote:
On Wed, Feb 1, 2012 at 10:19 PM, Patrick Marlier
patrick.marl...@gmail.com wrote:
On 02/01/2012 03:59 AM, Richard Guenther wrote:
The patch looks ok, but I'm
On 02/03/2012 11:13 AM, Jakub Jelinek wrote:
- http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01492.html
update libstdc++ baseline_symbols.txt for several targets
This is Ok (sorry for not telling you explicitly earlier)
Thanks,
Paolo.
If we have something like
BIT_FIELD_REF a.D.1707, 1, 0 = D.1722_3;
where a.D.1707 is of integer type then SRA will happily create
an SSA name replacement for a.D1707 resulting in invalid GIMPLE
IL with partial updates to SSA names (and crash later in the
verifiers).
The following patch cures
(Somehow my reply was private to Aldy ... forwarding to gcc-patches
now, given that it contains a patch and we changed topics)
On Fri, 3 Feb 2012, Richard Guenther wrote:
On Thu, 2 Feb 2012, Aldy Hernandez wrote:
Linus Torvalds torva...@linux-foundation.org writes:
Seriously - is
On Fri, 3 Feb 2012, Chung-Lin Tang wrote:
On the issue of hiding stuff in mips16.S, it may be suitable to raise
this issue here: there is a problem when MIPS16 hard-float calls go
through PLTs, because the hard-float stub functions in mips16.S use
v0/v1 as scratch registers, the same as
On Fri, Feb 03, 2012 at 09:17:23AM +0100, Zdenek Dvorak wrote:
It seems loop-iv.c happily creates shared RTL in lots of places,
loop-unroll.c solves that by unsharing everything it adds, this is
an attempt to do the same in unswitching to unshare everything iv_analyze
came up with.
On Fri, Feb 03, 2012 at 10:27:17AM +0100, Jakub Jelinek wrote:
Anyway, here is the tweaking all the symbols that demangle the same
equally patch (untested so far) as an alternative. On the example it
Now bootstrapped/regtested on x86_64-linux and i686-linux.
Jakub
On Fri, 3 Feb 2012, Richard Guenther wrote:
On Fri, 3 Feb 2012, Richard Guenther wrote:
On Thu, 2 Feb 2012, Aldy Hernandez wrote:
Linus Torvalds torva...@linux-foundation.org writes:
Seriously - is there any real argument *against* just using the base
type as a hint for
This fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50969 by slightly
raising the cost of vector permutes on powerpc64 VSX targets (and
ensuring those costs are correctly used). This reverses the performance
loss for 168.wupwise, and gives a slight boost to 433.milc as well.
In the long run,
On Fri, Feb 3, 2012 at 2:24 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
This fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50969 by slightly
raising the cost of vector permutes on powerpc64 VSX targets (and
ensuring those costs are correctly used). This reverses the
Chung-Lin Tang clt...@codesourcery.com writes:
(2) is interesting if there is also a way to build those MIPS16 libraries
out of the box. I'd like such a mechanism to be added at the same time,
so that the new support is easy to test. This is still a 4.7 candidate
if it can be done in time,
Maciej W. Rozycki ma...@codesourcery.com writes:
On Fri, 3 Feb 2012, Chung-Lin Tang wrote:
On the issue of hiding stuff in mips16.S, it may be suitable to raise
this issue here: there is a problem when MIPS16 hard-float calls go
through PLTs, because the hard-float stub functions in mips16.S
On Fri, 2012-02-03 at 14:41 +0100, Richard Guenther wrote:
On Fri, Feb 3, 2012 at 2:24 PM, William J. Schmidt
wschm...@linux.vnet.ibm.com wrote:
This fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50969 by slightly
raising the cost of vector permutes on powerpc64 VSX targets (and
Hi all,
Just adding my name under Write After Approval list.
Please see the patch below.
Index: ChangeLog
===
--- ChangeLog (revision 183872)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2012-02-03 Venkataramanan Kumar
On 02/03/2012 11:44 AM, Kumar, Venkataramanan wrote:
Index: MAINTAINERS
===
--- MAINTAINERS (revision 183872)
+++ MAINTAINERS (working copy)
@@ -538,6 +538,7 @@
Jon zieglerj...@apple.com
Roman zippelzip...@linux-m68k.org
Josef
Hi Patrick,
Thank you for pointing that. I will fix it.
Regards,
Venkat.
-Original Message-
From: Patrick Marlier [mailto:patrick.marl...@gmail.com]
Sent: Friday, February 03, 2012 10:20 PM
To: Kumar, Venkataramanan
Cc: gcc-patches@gcc.gnu.org
Subject: Re: MAINTAINERS (Write
Hi all,
I have inserted my name at correct order in the MAINTAINERS list.
Ok to commit ? please see the patch below.
Regards,
Venkat.
Index: ChangeLog
===
--- ChangeLog (revision 183873)
+++ ChangeLog (working copy)
@@ -1,5
This patch removes the define_constants from avr.md:
SREG_ADDR, SP_ADDR, RAMPZ_ADDR.
The constants were not used in md directly and didn't take care of afr_offset
between RAM and I/O address.
The replacement is a new structure avr_addr that holds RAM addresses of
respective SFRs and takes into
Fix-ups for atomic_tp* operators. Found some open issues with
atomicvoid* that merit further study.
tested x86/linux
-benjamin2012-02-02 Benjamin Kosnik b...@redhat.com
PR libstdc++/52068
* src/c++11/Makefile.am (toolexeclib_LTLIBRARIES,
libc__11_la_SOURCES): Remove.
*
On Fri, Feb 03, 2012 at 11:52:44AM -0800, Benjamin Kosnik wrote:
Fix-ups for atomic_tp* operators. Found some open issues with
atomicvoid* that merit further study.
Different patch attached?
Jakub
Different patch attached?
Indeed, sorry. Here's the right one.
-benjamin2012-02-03 Benjamin Kosnik b...@redhat.com
PR libstdc++/51811
* include/bits/atomic_base.h (atomic_Tp*): Fix offsets.
* testsuite/29_atomics/atomic/operators/51811.cc: New.
*
I'm just going to check in this PR's derived test case, since it seems
like something we should be tracking.
tested x86/linux
-benjamindiff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 656cc96..187ee49 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,5
-Original Message-
From: Georg-Johann Lay [mailto:a...@gjlay.de]
Sent: Friday, February 03, 2012 12:47 PM
To: gcc-patches@gcc.gnu.org
Cc: Denis Chertykov; Weddington, Eric
Subject: [Patch,AVR]: Clean up hard-coded SFR addresses
This patch removes the define_constants from
Fixes the following tests by restricting them to 64-bit target environment.
Tested: Using 'make -k check-gcc RUNTESTFLAGS=i386.exp=patch*
--target_board=unix\{-m32,,-m64\}' and crosstool-validate.py script.
Patch to be applied to google/main branch.
2012-02-03 Harshit Chopra
Hi,
when Dodji added the new warning something went wrong with the
description in c.opt, which seems truncated. I'm proposing the below,
very close to the text in invoke.texi besides the plural form, which
seems more consistent. Is it Ok with you?
Thanks,
Paolo.
//
ok for google branches.
David
On Fri, Feb 3, 2012 at 3:20 PM, Harshit Chopra hars...@google.com wrote:
Fixes the following tests by restricting them to 64-bit target environment.
Tested: Using 'make -k check-gcc RUNTESTFLAGS=i386.exp=patch*
--target_board=unix\{-m32,,-m64\}' and
Thanks for the review. Committed to google-main.
--
Harshit
On Fri, Feb 3, 2012 at 4:33 PM, Xinliang David Li davi...@google.com wrote:
ok for google branches.
David
On Fri, Feb 3, 2012 at 3:20 PM, Harshit Chopra hars...@google.com wrote:
Fixes the following tests by restricting them to
This patch removes the define_constants from avr.md:
SREG_ADDR, SP_ADDR, RAMPZ_ADDR.
The constants were not used in md directly and didn't take care of
afr_offset between RAM and I/O address.
The replacement is a new structure avr_addr that holds RAM addresses
of respective SFRs and takes into
This patch does two related things. First, it fixes the hash code in
the type descript for a named type so that it matches the hash code the
compiler will use internally. Second, it fixes the hash code in the new
type structure created by reflect.PtrTo to match the hash code which the
compiler
Hi,
Here is the patch fixing pr51867 by removing the redundant check on
DECL_ASSEMBLER_NAME_SET_P.
I also changed '-O0' to '-O1' in signbit-2.c and added a new test.
The new test case won't bite if target cpu does not support hardware sqrtf
instruction.
Tested on arm-eabi and x86, Is it OK?
I have once again merged trunk to gccgo branch, this time merging
revision 183892.
Ian
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01835.html changed the
code I'm tweaking here to use DFmode subregs when loading a TFmode
constant into regs for e500. This just extends that change to all
rs6000 targets, the simplest fix I found for PR52107, a problem I
discovered when looking at
40 matches
Mail list logo
