On 28/10/11 17:59, Richard Henderson wrote:
On 10/28/2011 06:49 AM, Peter Bigot wrote:
I'm inclined to follow sparc's lead, but is one or another of the choices
more likely to help combine/reload/etc do a better job?
I don't know.
In the case of RX, we don't model CC_REG until after reload, s
On 29/10/11 18:33, Peter Bigot wrote:
On Sat, Oct 29, 2011 at 10:58 AM, Richard Henderson wrote:
On 10/29/2011 05:41 AM, Peter Bigot wrote:
It seems cc0 should probably still be preferred for CISC-style
architectures like the MSP430. I'll give that approach a try.
I think that's somewhat un
[CCing David Miller, the SPARC binutils maintainer]
> I want to once again ask for write credentials so that
> I can submit patches for the sparc-leon architecture:
> The first patch is for the 'gcc' repository while the
> second patch is for the 'binutils' repository. They are both
> related so
On 31/10/11 05:36, Hans-Peter Nilsson wrote:
BTW, I
don't think it helps that someone decided the canonical form of
a parallel that includes a CC-setter must have the CC-setting
*first* (contrasting with the position of clobbers)...
How did you reach this conclusion?
--
PMatos
Hi all,
Could someone tell me whether the following sequence of DWARF information
is correct please, and if it is, how it should be interpreted? GCC emits
something like the following [1]:
.byte 0x75# DW_OP_breg5
.sleb128 0
.byte 0x93# DW_OP_piece
.uleb
On Mon, Oct 31, 2011 at 12:01:00PM -, Dan Towner wrote:
> Could someone tell me whether the following sequence of DWARF information
> is correct please, and if it is, how it should be interpreted? GCC emits
> something like the following [1]:
>
> .byte 0x75# DW_OP_breg5
>
Quoting Hans-Peter Nilsson :
I came to the somewhat the same conclusion for CRIS where all
insns set condition codes except move to memory and a "add
reg1,reg2" (no immediate operand) and to/from special registers:
there'll one clobbering and one CC_REG-setting pattern plus a
load of others (pee
Simon Wright writes:
> The Mercurial mirror at http://gcc.gnu.org/hg/gcc was last updated 11 months
> ago at SVN r166522.
>
> I think it can only cause confusion to have the mirror live but stale; ought
> it to be turned off?
Agreed. Besides, nowadays you don't need a mirror anymore. I'm hav
> It does not address other missing aspects of the c++ memory model. In
> particular, bitfields are still not compliant with not introducing new
> potential data races.
Can we treat this as a bugfix to be done during stage2? There is
already some support in mainline, but it performs lousy on an
> Then if I use the resultant compiler from a 4.6.1 build I get a massive
> increase in failures on both i386 and Sparc :
>
> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03286.html
This is unexpected, results are clean here:
http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg03536.html
> Als
Dennis Clarke writes:
> I'm not too sure how many things changed from 4.6.1 to 4.6.2 but I am
> seeing a really large increase in the number of "unexpected failures" on
> various tests.
>
> With 4.6.1 and Solaris I was able to get reasonable results :
>
> http://gcc.gnu.org/ml/gcc-testresults/201
Hello,
I'm looking for advice on how to debug and fix PR50906:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906
The basic summary is that GCC is generating bad unwinder information or
is incorrectly saving registers onto the stack on PowerPC e500v2. Any
ordinary function call+return works fin
On 31 October 2011 15:33, Rainer Orth wrote:
> As an asside, I'd suggest to considerably reduce your set of configure
> options: many of them are the default (like --without-gnu-ld
> --with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix,
> --enable-shared, --enable-multilib, --host=i386-p
> On 31 October 2011 15:33, Rainer Orth wrote:
>> As an asside, I'd suggest to considerably reduce your set of configure
>> options: many of them are the default (like --without-gnu-ld
>> --with-ld=/usr/ccs/bin/ld, --enable-nls, --enable-threads=posix,
>> --enable-shared, --enable-multilib, --host
Dennis Clarke writes:
>>> I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
>>> might be better to keep the default of pentiumpro instead.
>>
>> Solaris 8 won't run on anything less than pentium, I recently
>> convinced someone else to stop building GCC for i386 on Solaris:
On 31 October 2011 17:38, Rainer Orth wrote:
> Dennis Clarke writes:
>
I'm uncertain if Solaris 8/x86 still supports bare i386 machines, so it
might be better to keep the default of pentiumpro instead.
>>>
>>> Solaris 8 won't run on anything less than pentium, I recently
>>> convinced so
Aldy Hernandez writes:
> Can we treat this as a bugfix to be done during stage2? There is
> already some support in mainline, but it performs lousy on anything but
> the most simple of testccases. After much iterations with Richi, we
> couldn't come to an agreement on the remaining fixes. I wo
> These `I've used them for ever' options tend to do more harm than good,
> and confuse other users that check how your copy of gcc was built. This
> is especially bad for distributors like yourself, since the number of
> confused people is far larger than for some company-internal build ;-)
>
>
This is somewhat of a me-too message for the transactional-memory work.
We would also like it to be considered for merging with mainline
before the end of stage1.
We have a kept a wiki here:
http://gcc.gnu.org/wiki/TransactionalMemory
What it is
==
From the wiki...
Transactional me
On Mon, 31 Oct 2011, Paulo J. Matos wrote:
> On 31/10/11 05:36, Hans-Peter Nilsson wrote:
> > BTW, I
> > don't think it helps that someone decided the canonical form of
> > a parallel that includes a CC-setter must have the CC-setting
> > *first* (contrasting with the position of clobbers)...
>
> H
I've checked this in with some tweaks.
Jason
21 matches
Mail list logo
