Snapshot gcc-4.4-20100309 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100309/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 9 Mar 2010, at 19:36, Rainer Orth wrote:
IainS writes:
.. I don't seem to get the bus errors on a 4CPU g5 or a Core 2
duo .. but
.. the 8-core machine is faster .. so ... race conditions are more
likely
to manifest there.
But race conditions don't manifest themselves in make SEGVs
On 9 Mar 2010, at 19:31, NightStrike wrote:
On Tue, Mar 9, 2010 at 2:27 PM, IainS > wrote:
I do build gmp/mpfr/mpc in-tree...
How? Last I tried, it didn't work, as mpc used the system gmp/mpfr,
not the just-built in-tree versions. Therefore, it's not really an
"in-tree" build, and you can't
IainS writes:
> .. I don't seem to get the bus errors on a 4CPU g5 or a Core 2 duo .. but
> .. the 8-core machine is faster .. so ... race conditions are more likely
> to manifest there.
But race conditions don't manifest themselves in make SEGVs ;-( I'm
regularly running make -k -j128 on a T
On Tue, Mar 9, 2010 at 2:27 PM, IainS wrote:
> I do build gmp/mpfr/mpc in-tree...
How? Last I tried, it didn't work, as mpc used the system gmp/mpfr,
not the just-built in-tree versions. Therefore, it's not really an
"in-tree" build, and you can't build on a system that doesn't already
have gmp
On 9 Mar 2010, at 19:13, Janis Johnson wrote:
To run all of the compiler tests in parallel you can do "make -jn -k
check-gcc" from the top level and let the existing build machinery
take care of running chunks of tests in parallel and putting the
results back together.
that's fine (I cou
On 09/03/2010 18:42, Basile Starynkevitch wrote:
> Dave Korn wrote:
>>
>> Yes, I think so; aggregation is the right word for it. Or maybe
>> scalarization. If you wrap all these chars in a struct, can SRA
>> handle it?
>
>
> I tried
> So it seems indeed that a structure can be cleared effici
ret
.cfi_endproc
.LFE0:
.size f, .-f
.ident "GCC: (GNU) 4.5.0 20100309 (experimental) [trunk
revision 157303]"
###
So it seems indeed that a structure can be cleared efficiently. However,
On 09/03/2010 17:42, Basile Starynkevitch wrote:
> I knew about vectorization (of which I am not an expert), and I didn't
> mention it, because in my view this is not exactly vectorization.
Agreed.
> And I don't want to use an array of bytes for that purpose. I want to have a
> rather large nu
char)(foo.bar * 0xff));
return 0;
}
monst...@yggdrasil /data/tmp $ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --enable-stage1-languages-c
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.4 20100309 (prerelease) (GCC)
monst...
On Fri, Feb 19, 2010 at 3:38 AM, Aldy Hernandez wrote:
> libitm.so won't build on ia32 because of an undefined reference to
> __sync_add_and_fetch_8.
>
> This is the build failure Pearly encountered here:
>
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01201.html
>
> What happens is that w
On Tue, Mar 09, 2010 at 05:25:35PM +0600, Alexey Salmin wrote:
> On Tue, Mar 9, 2010 at 3:58 PM, Basile Starynkevitch
> wrote:
> > Hello All,
> >
> > With a recently compiled gcc-trunk on x86-64/linux, I am compiling the
> > folllowing example:
> >
> > #
> >
> > /* file testmanych
On 02/19/2010 04:18 AM, Paolo Carlini wrote:
> On 02/19/2010 01:07 PM, Paolo Carlini wrote:
>> On 02/19/2010 12:38 PM, Aldy Hernandez wrote:
>>
>>> Since the TM library on ia32 is built with -m486, which doesn't
>>> have 64-bit atomic operations, should we...
>>>
>>> a) Build with -m586 and above
On 9 Mar 2010, at 12:46, Rainer Orth wrote:
IainS writes:
Instead, run make mail-report.log afterwards and check that.
...
suite in parallel, which isn't bad either.
As I wrote before, I'm going to use this on an (effectively) 64-core
machine and hope to achieve to use all cores in pa
"Amker.Cheng" writes:
> In gcc internal, section 16.19.8, there is a rule about
> "define_insn_reservation" like:
> "`condition` defines what RTL insns are described by this
> construction. You should re-
> member that you will be in trouble if `condition` for two or more
> different `define_in
On 3/9/2010 4:28 AM, IainS wrote:
It would be nice to allow the apparently independent targets [e.g.
gcc-c,fortran,c++ etc.] to be (explicitly) make-checked in parallel.
On certain targets, it has been necessary to do this explicitly for a
long time, submitting make check-gcc, make check-f
IainS writes:
> Am I trying something that is unsupported - or is this is a bug?
>
> ===
>
> "make -k -j8 check " is not particularly helpful (a) because it tests
> gmp/mpfr/mpc every time (b) any redirected output is hard to scan for
> problems.
What you're trying is far too complicated: just u
p), %rdx #, tmp68
> movq %rbp, %rcx # tmp60,
> movq %rbx, %rsi # tmp64,
> movl $40, %edi #,
> call g #
> movq 16(%rsp), %rbx #,
> movq 24(%rsp), %rbp #,
> movq 32(%rsp), %r12 #,
> ad
IainS writes:
>> Instead, run make mail-report.log afterwards and check that.
>
> Although, I note that contrib/test_summary only reports what gets into the
> *.sum files -- i.e. tests that complete or timeout.
> It doesn't log problems in the actual make process itself - to find those
> one stil
On 9 Mar 2010, at 12:10, Rainer Orth wrote:
IainS writes:
Am I trying something that is unsupported - or is this is a bug?
===
"make -k -j8 check " is not particularly helpful (a) because it tests
gmp/mpfr/mpc every time (b) any redirected output is hard to scan for
problems.
What you're
for the sake of keeping information segregated in log files (and
balancing out test times)
I tried the following (from within a regression testing script):
'make -k check-gcc-c RUNTESTFLAGS=$runTEST >${STATE}/$svnRevision-
check-c-log.txt 2>&1' &
(sleep 2) 'make -k check-gcc-c++ RUNTESTFLAGS=
IainS writes:
> on my mere 8 cores :-) I'm still getting sporadic Bus errors on:
>
> "make -k -j8 check RUNTESTFLAGS ... "
> [from the command line on a bootstrapped clean trunk @157307]
>
> so there's something else wrong somewhere...
Probably make gets SIGBUS, which obviously won't be in the
.size f, .-f
.ident "GCC: (GNU) 4.5.0 20100309 (experimental) [trunk revision
157303]"
#
With
gcc-trunk -S -O3 -fverbose-asm -march=core2 -mtune=core2 testmanychar.c
I am getting still
##
# options passed: testmanychar.c -march=core2
23 matches
Mail list logo
