On Sat, Feb 11, 2012 at 1:26 AM, Richard Henderson wrote:
> On 02/09/2012 03:47 PM, Uros Bizjak wrote:
>> 2012-02-10 Uros Bizjak
>>
>> * compare-elim.c (find_comparisons_in_bb): Eliminate only compares
>> having mode compatible with the mode of previous compare. Substitute
>>
On Tue, Feb 7, 2012 at 5:37 PM, Uros Bizjak wrote:
>> Attached patch declares CCZmode compatible with CCGOC, CCGO and CCNO modes.
>
> Actually, CCZ mode is not compatible with CCNO mode, since the later
> only declares that overflow flag is not set. CCGOC and CCGO declare
> garbage in overflow (a
On 02/08/2012 03:01 AM, Jakub Jelinek wrote:
On Tue, Feb 07, 2012 at 11:41:03PM -1000, Jason Merrill wrote:
Hmm, I wrote up something quite similar on the plane. One
difference is that mine synchronizes .rpo files that start with some
variants chosen and others not. Does this make sense to you
On Sat, Feb 11, 2012 at 9:41 AM, Uros Bizjak wrote:
>>> Attached patch declares CCZmode compatible with CCGOC, CCGO and CCNO modes.
>>
>> Actually, CCZ mode is not compatible with CCNO mode, since the later
>> only declares that overflow flag is not set. CCGOC and CCGO declare
>> garbage in overf
This patch fixes PR rtl-optimization/52175, which is another case of
dbr_schedule mishandling the result of shrink-wrapping. There is code
to allow:
add rN,rN,CONST
to be put into a delay slot by adding a compensating:
add rN,rN,-CONST
to the opposite thread. (Which ha
On Sat, 11 Feb 2012, Richard Henderson wrote:
> On 02/04/2012 02:06 AM, Richard Sandiford wrote:
> >> > Actually I had that idea of a link-once function too, but it turned out
> >> > quite complicated to do without rewriting some generic parts of GCC as
> >> > it
> >> > is currently not prepar
> is having Address be an integer useful any more? Nowadays it should be
> possible to declare Address to be an access type with no associated storage
> pool. Even nicer might be to have it be turned into void* when lowering to
> GCC types. After all, Address is really used much like void*; see h
The minimum stack frame size is 176 in 64-bit mode, not 128.
Tested on SPARC/Solaris, applied on the mainline.
2012-02-11 Eric Botcazou
* src/sparc/v9.S (STACKFRAME): Bump to 176.
--
Eric Botcazou
Index: src/sparc/v9.S
==
Hi!
In July Richard changed reduce_bit_field BIT_NOT_EXPR expansion from
NOT unop to XOR with all the bits in the bitfield's precision set.
Unfortunately that is correct for unsigned bitfields only, for signed
bitfields, where op0 is already sign-extended to its mode before this,
expanding this as
On 11 February 2012 00:56, Richard Henderson wrote:
>
> Ok?
OK, thanks.
On Feb 11, 2012, at 05:37, Eric Botcazou wrote:
> The polymorphism pointer/address indeed proves to be problematic in certain
> circumstances (e.g. it breaks on m68k, see PR ada/48835). My understanding
> is
> that using pointers in Ada is heavyweight, hence the choice of an integer for
> Sys
On Nov 4, 2011, at 8:23 PM, Quentin Neill wrote:
> My scenario about "ANY test results changed" is what I added with -strict.
> This patch concatenates the common .sum files before comparing.
So, how exactly does this work for you:
+ ( for fname in `cat $lst5`; do cat $1/$fname; done ) >$su
Hi,
this completes the half-implemented linking scheme of libitm and makes it mimic
that of libgomp entirely. We need the -pthread thing on Solaris 8.
Tested on SPARC/Solaris 8 & 9 and i586/Linux, OK for the mainline?
2012-02-11 Eric Botcazou
* gcc.c (LINK_COMMAND_SPEC): Deal with
Index: compare_tests
===
--- compare_tests (revision 184129)
+++ compare_tests (working copy)
@@ -83,11 +83,14 @@ if [ -d "$1" -a -d "$2" ] ; then
exit $exit_status
fi
cmnsums=`cat $lst5 | wc
> Probably for Convention C, we should convert Address to *void.
>
> So, for
>
>function Alloc (Size : size_t) return System.Address;
>pragma Export (C, Alloc, "__gnat_malloc");
>
> we probably should do this replacement and add the necessary
> type conversions. That would seem to be how
On Sat, Feb 11, 2012 at 1:26 AM, Richard Henderson wrote:
> On 02/09/2012 03:47 PM, Uros Bizjak wrote:
>> 2012-02-10 Uros Bizjak
>>
>> * compare-elim.c (find_comparisons_in_bb): Eliminate only compares
>> having mode compatible with the mode of previous compare. Substitute
>>
errors)
WARNING: libitm.c/txrelease.c compilation failed to produce executable
Running
/sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120211/libitm/testsuite/libitm.c++/c++.exp
...
FAIL: libitm.c++/dropref.C (test for excess errors)
WARNING: libitm.c++/dropref.C compilation failed to produce executabl
> This change causes massive failures at -m32/-m64 on x86_64-apple-darwin11
> in the libitm testsuite...
How did you test it?
--
Eric Botcazou
LL; }
+void _ZdaPvRKSt9nothrow_t (void * a UNUSED, c_nothrow_p b UNUSED) { return; }
+
#endif
built as...
Using built-in specs.
COLLECT_GCC=gcc-fsf-4.7
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.3.0/4.7.0/lto-wrapper
Target: x86_64-apple-darwin11.3.0
Configured with: ../gcc
On Sat, Feb 11, 2012 at 06:54:05PM +0100, Eric Botcazou wrote:
> > This change causes massive failures at -m32/-m64 on x86_64-apple-darwin11
> > in the libitm testsuite...
>
> How did you test it?
>
> --
> Eric Botcazou
Eric,
FYI, if I restore -litm to the linkage of the failing tests, they
> Applied to gcc trunk (r184130) along with the proposed fix for
> Bug libitm/52042...
OK, I missed the hardcoded(!) spec in config/darwin.h for libgomp, so I guess
we need the same thing for libitm. Revised patch attached.
* config/darwin.h (LINK_COMMAND_SPEC_A): Deal with -fgnu-t
>FYI, if I restore -litm to the linkage of the failing tests, they
> compile and run fine. I don't understand why we think -litm can be dropped
> from linking the tests in the libitm testsuite.
Because -fgnu-tm will automatically add it on the link line, like for -fopenmp.
--
Eric Botcazou
Hi Eric,
On 11 Feb 2012, at 14:14, Eric Botcazou wrote:
Hi,
this completes the half-implemented linking scheme of libitm and
makes it mimic
that of libgomp entirely. We need the -pthread thing on Solaris 8.
Tested on SPARC/Solaris 8 & 9 and i586/Linux, OK for the mainline?
2012-02-11 E
On Sat, Feb 11, 2012 at 07:11:11PM +0100, Eric Botcazou wrote:
> > Applied to gcc trunk (r184130) along with the proposed fix for
> > Bug libitm/52042...
>
> OK, I missed the hardcoded(!) spec in config/darwin.h for libgomp, so I guess
> we need the same thing for libitm. Revised patch attac
>I missed the regeneration of libitm/configure the first time. The
> p2.diff with the regenerated libitm/configure passes make check in libitm
> now on x86_64-apple-darwin11...
Great, thanks for the testing.
--
Eric Botcazou
> Date: Sun, 5 Feb 2012 00:30:53 +0100 (CET)
> From: Gerald Pfeifer
>
> Is this patch upstream on the OpenBSD side? How and where have
> you tested it?
Not sure what you mean by "upstream" in this conext. We curently ship
GCC 4.2.1 as our system compiler, which is different enough from the
cu
El 6 de febrer de 2012 19:31, Mike Stump ha escrit:
>>> Looks obvious to me as well. I'd say let's put it in...
>>
>> Is this patch approved, then?
>
> I've not seen anyone approve it yet. I'm not a maintainer for that area, so,
> I cannot.
Who can approve it? Looking at the maintainers file
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.7-b20120128.de.po', h
On 02/11/2012 07:09 AM, Uros Bizjak wrote:
> On Sat, Feb 11, 2012 at 1:26 AM, Richard Henderson wrote:
>> On 02/09/2012 03:47 PM, Uros Bizjak wrote:
>>> 2012-02-10 Uros Bizjak
>>>
>>> * compare-elim.c (find_comparisons_in_bb): Eliminate only compares
>>> having mode compatible with
On Tue, 7 Feb 2012, Joern Rennecke wrote:
> Tested by building 'info' for epiphany-elf, and by bootstrapping
> x86_64-unknown-linux-gnu .
Jörn, you are listed as epihphany maintainer, so you don't needs
to RFA patches like this.
That said...
Index: doc/extend.texi
===
Given that both Mike and me considered this patch on the obvious
side, I now committed the following variation thereof on trunk.
(Note the line break and comment change. 5! = 120 did not seem
like a useful version number. ;-)
Gerald
Index: ginclude/stddef.h
=
On Sun, 5 Feb 2012, Joseph S. Myers wrote:
>> It has been brought to my attention that we have been missing
>> a prominent member of the Steering Committee on our web page.
> Should the list distinguish which members are or are not GNU maintainers
> of GCC? fencepost:/gd/gnuorg/maintainers lists
Based by a request by all three release managers the steering
committee aggreed to remove ia64-unknown-linux-gnu as a secondary
platform for GCC 4.7 and I applied the patch below to update our
documentation accordingly.
Gerald
Index: criteria.html
=
commit cbd38ef0c58ac4a365913d2bb2a2e0c062516dbb
Author: Ollie Wild
Date: Sat Feb 11 22:05:52 2012 -0600
Update known failures to reflect current reality.
diff --git a/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
b/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
This patch to the sync/atomic package disables a couple of tests on
systems with an inappropriate pointer size. The 32-bit test was
clobbering 4 bytes on the heap. The 64-bit test only worked on
little-endian systems. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to m
The nilptr.go test fails on 64-bit SPARC Solaris systems, because the
linker puts the array in a place where the test can not work correctly.
I disabled it on all SPARC Solaris systems. I changed to disabling to
not run the test, rather than to xfail it. For this test, an XPASS is
not useful info
This patch to libgo defines some more __sync functions that may be
missing on some systems. PR 52084 reports that these are missing on
PowerPC GNU/Linux.
I'll convert these to the new __atomic functions in gcc 4.8 when the
atomic library is available.
Bootstrapped and ran Go testsuite on x86_64-
37 matches
Mail list logo
