I've checked this in with some tweaks.
Jason
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
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
> 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 ;-)
>
>
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
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
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 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
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
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
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
> 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
> 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
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
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
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
>
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 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
[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 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
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
21 matches
Mail list logo
