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 powe
I have once again merged trunk to gccgo branch, this time merging
revision 183892.
Ian
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?
Than
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 wi
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 a
Thanks for the review. Committed to google-main.
--
Harshit
On Fri, Feb 3, 2012 at 4:33 PM, Xinliang David Li wrote:
> ok for google branches.
>
> David
>
> On Fri, Feb 3, 2012 at 3:20 PM, Harshit Chopra wrote:
>> Fixes the following tests by restricting them to 64-bit target environment.
>>
ok for google branches.
David
On Fri, Feb 3, 2012 at 3:20 PM, Harshit Chopra 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 crosstool-validate.py sc
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.
//
2012-02-0
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
Restrictin
> -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
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 +1,1
> Different patch attached?
Indeed, sorry. Here's the right one.
-benjamin2012-02-03 Benjamin Kosnik
PR libstdc++/51811
* include/bits/atomic_base.h (atomic<_Tp*>): Fix offsets.
* testsuite/29_atomics/atomic/operators/51811.cc: New.
* testsuite/29_atomics/atomic/operator
On Fri, Feb 03, 2012 at 11:52:44AM -0800, Benjamin Kosnik wrote:
>
> Fix-ups for atomic<_tp*> operators. Found some open issues with
> atomic that merit further study.
Different patch attached?
Jakub
Fix-ups for atomic<_tp*> operators. Found some open issues with
atomic that merit further study.
tested x86/linux
-benjamin2012-02-02 Benjamin Kosnik
PR libstdc++/52068
* src/c++11/Makefile.am (toolexeclib_LTLIBRARIES,
libc__11_la_SOURCES): Remove.
* src/c++11/Makefile.in
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 ac
On 12-02-03 11:36 , Quentin Neill wrote:
On Fri, Feb 3, 2012 at 12:58 PM, Diego Novillo mailto:dnovi...@google.com>> wrote:
On 12-02-03 09:33 , Kumar, Venkataramanan wrote:
Hi all,
I have inserted my name at correct order in the MAINTAINERS list.
Ok to commit ? ple
On 12-02-03 09:33 , Kumar, Venkataramanan wrote:
Hi all,
I have inserted my name at correct order in the MAINTAINERS list.
Ok to commit ? please see the patch below.
Yes. These obviously correct changes do not need further approval.
Simply post the patch to the list and commit it.
Diego.
Hi!
On some targets e.g. sms-7.c test fails, because fprintf is called
with %s format and NULL argument, GLIBC prints for that e.g.
SMS loop num: 1, file: (null), line: 0
but it isn't portable. print-rtl.c guards the locator printing with
/* Pretty-print insn locators. Ignore scopin
On Fri, 3 Feb 2012, Richard Sandiford wrote:
> > Not quite a large portion, just the function return stubs (which I reckon
> > there are exactly four) that process values in $v0/$v1 as if they were
> > arguments. This is of course a non-standard calling convention that
> > breaks the ABI and
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 +1
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
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 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 Fri, 2012-02-03 at 14:41 +0100, Richard Guenther wrote:
> On Fri, Feb 3, 2012 at 2:24 PM, William J. Schmidt
> 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
"Maciej W. Rozycki" 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 use
>> v0/v1 as
Chung-Lin Tang 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, although it's pro
On Fri, Feb 3, 2012 at 2:24 PM, William J. Schmidt
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 performance
> loss for 168.wupwise
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, w
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 writes:
> > >
> > > > Seriously - is there any real argument *against* just using the base
> > > > type as a hint for access size?
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, 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, 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 MI
(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 writes:
> >
> > > Seriously - is there any real argument
If we have something like
BIT_FIELD_REF = 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 this - I have no
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.
On Thu, Feb 2, 2012 at 8:00 PM, Patrick Marlier
wrote:
> On 02/02/2012 04:22 AM, Richard Guenther wrote:
>>
>> On Wed, Feb 1, 2012 at 10:19 PM, Patrick Marlier
>> wrote:
>>>
>>> On 02/01/2012 03:59 AM, Richard Guenther wrote:
The patch looks ok, but I'm not sure why you do not get
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
- http://
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
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/re
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 demanglin
On 02/02/2012 06:47 PM, Kai Tietz wrote:
> 2012-02-02 Kai Tietz
>
> PR libjava/48512
> * configure.ac (THREADSTARTFILESPEC): Don't add crtmet.o file for
> w64 windows targets.
> * configure: Regenerated.
>
> Tested for i686-w64-mingw32, and i686-pc-mingw32. Ok
On Fri, Feb 3, 2012 at 3:59 PM, Fu, Chao-Ying 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 th
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
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 late
44 matches
Mail list logo
