> $ egrep "mpfr\.h" log/cfg/cfg.gcc-11.1.0.log
> checking for the correct version of mpfr.h... buggy but acceptable
>
> It appears "gcc-11.1.0/contrib/download_prerequisites"
> specifies "mpfr-3.1.4.tar.bz2" whereas top level 'configure'
> has "MPFR_VERSION_NUM(3,1,6)".
>
> Is there a reason
> My builds for the last couple of days have all been failing in stage 2
> like so:
>
> /home/arth/src/gcc/gcc/config/i386/i386.c: In function ‘rtx_def*
> ix86_expand_bui
> ltin(tree, rtx, rtx, machine_mode, int)’:
> /home/arth/src/gcc/gcc/config/i386/i386.c:38407:18: error: ‘fcn’ may be used
> u
Andrew Pinski writes:
> On Fri, Apr 1, 2011 at 8:57 PM, Alex wrote:
>> If I understood correct, gcc could replace insns 5, 7, 8 and 9 by the insn
>> defined as "*and_2", but it seems "combine" did not tried that.
>
> Yes you missed that combine in GCC only acts on 3 insns at a time.
> Though th
[EMAIL PROTECTED] writes:
> Over the previous years, I had downloaded and used both a really archaic
> gcc-1.09 DLX backend as well as the one you refer too. They are both in a sad
> state of affairs, but the gcc-2.7.2.1 (AFAICR) was usable.
>
Offtopic: if you still have such an old gcc-1.09 (?)
Toon Moene <[EMAIL PROTECTED]> writes:
> L.S.,
>
> Recently, I've begun to bootstrap with make BOOT_CFLAGS="flags",
> basically to get the run time libraries (libgfortran, libgomp)
> compiled with -mcpu=native -mtune=native (the speed of the compiler
> doesn't interest me that much).
>
> However,
Andreas Jaeger <[EMAIL PROTECTED]> writes:
> bootstrap with current svn head fails for me on Linux/x86-64:
...
> cc1: warnings being treated as errors
> /cvs/gcc-svn/trunk/gcc/treelang/treetree.c:1191: error:
> ‘treelang_expand_function’ defined but not used
> make[3]: *** [treelang/treetree.o] E
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
[...]
> My personal preference would be to acknowledge that for our users
> there is no significant difference between GPLv2 and GPLv3. And we
> should acknowledge that people backporting patches from later releases
> are already going to have to relic
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> It was a patch to enable more optimization. Reverting it should be as safe
> or unsafe as exchanging forwprop and dce passes. And I have no idea
> as how to quantify safeness of either ;)
>
> I'd say we better analyze what goes wrong (as the probl
"Vladimir N. Makarov" <[EMAIL PROTECTED]> writes:
> I run SPEC2000 several times per week and always look at 3 runs (to be
> sure that is nothing wrong happened) but I never saw such big
> "confidence" intervals (as I understand that is difference between max
> and min of 3 runs divided by the sco
I have compared 4.1.2 release (r121943) with three revisions of 4.2 on spec2k
on an 2GHz AMD Athlon64 box (in 64bit mode), detailed results are below.
In short, current 4.2 performs just as good as 4.1 on this target
with the exception of huge 80% win on 178.galgel. All other difference
lies almos
Steven Bosscher <[EMAIL PROTECTED]> writes:
> Hello,
>
...[snip]
> So I'm looking for help here: Who can help me find a test case to trigger
> a verify_flow_info ICE in GCC with the above patch applied? Can people
> try this patch on their favorite target, and see if they can trigger a
> test sui
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Gerald Pfeifer <[EMAIL PROTECTED]> writes:
>
> | On Sun, 28 Jan 2007, Joe Buck wrote:
> | > It's probably time to turn off 4.0 snapshots; the last ones will
> | > probably be Gaby's prerelease snapshots, and the release should come
> | > soon.
> |
>
12 matches
Mail list logo
