compiling gcc as a part of toolchain (linux from scratch) gives me the
following error when compiling as user
but compiles fine when compiling as root:
--prefix=/tools \
--target=x86_64-lfs-linux-gnu \
--with-sysroot=/media/usbdisk \
--with-glib-version=2.25 \
--with-newlib \
--without-headers \
-
Snapshot gcc-7-20170629 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170629/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On June 29, 2017 8:27:18 PM GMT+02:00, Eric Botcazou
wrote:
>> OK to re-apply then on the branch(es) if it fixes the bootstrap
>issue.
>
>I was wrong, it's PR sanitizer/78532 + PR sanitizer/78992 instead...
>
>2016-11-30 Maxim Ostapenko
>
> PR sanitizer/78532
> * sanitizer_common/s
> OK to re-apply then on the branch(es) if it fixes the bootstrap issue.
I was wrong, it's PR sanitizer/78532 + PR sanitizer/78992 instead...
2016-11-30 Maxim Ostapenko
PR sanitizer/78532
* sanitizer_common/sanitizer_platform_limits_posix.h
(__sanitizer_sigaction): Adjust
On 06/28/2017 05:44 AM, Richard Biener wrote:
A release candidate for GCC 6.4 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/6.4.0-RC-20170628/
and shortly its mirrors. It has been generated from SVN revision 249715.
I have so far bootstrapped and tested the release candidate on
x86
Hi,
GCJ has been removed from GCC 7.1, so these broken links should also be removed
from the documentation page (https://gcc.gnu.org/onlinedocs/) and probably from
the scripts generating them:
"GCC 7.1 GCJ Manual (also in PDF or PostScript or an HTML tarball)"
Thanks,
Krisztian Paczari
On June 29, 2017 4:27:18 PM GMT+02:00, Eric Botcazou
wrote:
>> Iff 6.3.0 worked then it must be caused by
>>
>> r245546 | andreast | 2017-02-17 20:21:39 +0100 (Fri, 17 Feb 2017) | 9
>> lines
>>
>> 2017-02-17 Andreas Tobler
>>
>> Backported from mainline
>> 2017-02-16 Andreas Tobler
> Iff 6.3.0 worked then it must be caused by
>
> r245546 | andreast | 2017-02-17 20:21:39 +0100 (Fri, 17 Feb 2017) | 9
> lines
>
> 2017-02-17 Andreas Tobler
>
> Backported from mainline
> 2017-02-16 Andreas Tobler
>
> PR sanitizer/79562
> * sanitizer_common/sanitizer_platf
Hi Richard,
> Unless sparc-sun-solaris2.10 is also affected this won't block the
> release and I'm relying on you and the target maintainers to sort
> things out (confirming the above change is the culprit would be nice,
> even though it doesn't sound likely).
it's not: the Solaris (sparc and x86
On Thu, 29 Jun 2017, Anatoly Pugachev wrote:
> On Wed, Jun 28, 2017 at 1:44 PM, Richard Biener wrote:
> >
> > A release candidate for GCC 6.4 is available from
> >
> > ftp://gcc.gnu.org/pub/gcc/snapshots/6.4.0-RC-20170628/
> >
> > and shortly its mirrors. It has been generated from SVN revision
On Wed, Jun 28, 2017 at 1:44 PM, Richard Biener wrote:
>
> A release candidate for GCC 6.4 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/6.4.0-RC-20170628/
>
> and shortly its mirrors. It has been generated from SVN revision 249715.
>
> I have so far bootstrapped and tested the relea
> >
> >It then later decides to undo this and so generates a different order.
> >Question is, is this unexpected or should optimizations in expand be
> >checking for associativity?
>
> It's expected. Once fully in SSA the canonical operand order is lower SSA
> name versions first.
Ah, fair enoug
Andrew Pinski writes:
> Hi,
> I was looking into why we don't produce fmls with a scalar register
> as the last argument but I found a difference in how fnma4 is
> described in RTL which I think is causing the missed optimization.
> Look at the scalar version:
>
> (define_insn "fnma4"
> [(set
13 matches
Mail list logo
