Sebastian,
With the current r150790 gcc trunk, I am not seeing any
particular improvements in the polyhedron benchmarks with the
available graphite loop optimizations...
Date & Time : 15 Aug 2009 13:41:47
Test
Hi!
I'd appreciate some input on how to get the pipeline scheduler to
know about the bizarre MaverickCrunch timing characteristics.
Brief: Crunch is an asynchronous ARM coprocessor which has internal
operations from/to its own register set, transfers between its own
registers and the ARM integ
Oliver Kellogg wrote:
> On Fri, 2009-08-14 at 10:41 +0100, Andrew Haley wrote:
>>> I am stuck here, i.e. I don't know how to find the code
>>> that is
>>> at fault.
>>> Is there some way to trace a pointer entered in
>>> G.free_object_list
>>> back to its origin in the code?
>> The usual way to fin
{GC 17407k -> 17407k} {GC 17409k -> 17408k} {GC 17408k ->
17408k} {GC 17408k -> 17403k} {GC 17403k -> 17403k}Performing
interprocedural optimizations
{GC 17403k -> 17403k}
{GC 34561k -> +===GNAT BUG
DETECTED==+
| 4.5.0 20090815 (experim
>
> Yes. Although I'm streamlining things even more now. I've eliminated
> the "global" variables that store the excptr/filter, and instead each
> individual use location is asking for what it needs locally.
>
> Further, the actual landing pad itself is *not* generated in gimple.
> I had too ma
> On 08/10/2009 08:20 AM, Michael Matz wrote:
> >It's not that they _create_ side-effects, but they depend on some.
>
> Ah, fair enough. I hadn't actually thought that all through.
>
> >Btw, it's really wonderful that someone tackles EH-on-gimple ;-)
>
> I hadn't been planning on it, but my tra
On Sat, 2009-08-15 at 17:56 +0200, Ralf Wildenhues wrote:
> Which aclocal version do you have in PATH? Looks like 1.10 or newer,
> rather than 1.9.6.
Yes, that was probably it. Seems like Debian changed that behind my
back during a recent update...
Thanks!
Thomas
Hello Thomas,
* Thomas Koenig wrote on Sat, Aug 15, 2009 at 04:00:13PM CEST:
> Does this ring any bells? This is with a recent trunk.
>
> $ ../../gcc/trunk/configure --prefix=$HOME --enable-languages=c,fortran
> --enable-maintainer-mode && make && make install
>
> make[3]: Leaving directory `/v
Hi, folks,
Building with --enable-build-with-cxx fails to bootstrap as follows:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_alloc.o differs
x86_64-unknown-l
Does this ring any bells? This is with a recent trunk.
$ ../../gcc/trunk/configure --prefix=$HOME --enable-languages=c,fortran
--enable-maintainer-mode && make && make install
make[3]: Leaving directory `/var/work/gcc-bin/trunk/libdecnumber'
make[3]: Entering directory `/var/work/gcc-bin/trunk/g
I'd like to test lto on a project where objects first go through an
archive, and so wanted to follow
http://gcc.gnu.org/wiki/LinkTimeOptimization
using 'gcc -use-linker-plugin'
However, I can't get this to work.
gfortran -use-linker-plugin -flto main.f90 test.f90
/data03/vondele/binutils-2
On Sat, 2009-08-15 at 07:53 +0200, Ralf Wildenhues wrote:
> > > * Laurent GUERBY wrote on Fri, Aug 14, 2009 at 10:52:35PM CEST:
> > > > => gcc/testsuite/ada/acats/run_all.sh
> > >
> > > > 3/ Here is the point I find surprising: the "ps fauxww" run in the
> > > > second "if" show that even if the s
On Sat, 2009-08-15 at 01:37 +0100, Dave Korn wrote:
> Hmpf. That seems to rule out that theory. Gnatlink is still spawning the
> gcc driver to link, rather than the linker itself; maybe the driver's doing
> something wrong? Is collect-ld a shell script or an executable on your host?
It's a sc
13 matches
Mail list logo
