On Tue, Sep 24, 2019 at 10:16:27PM +, Steve Ellcey wrote:
> A recent g++ change (I haven't tracked down exactly which one, but in
> the last day or two) seems to have broken my boost build. It is dying
> with lots of errors like:
>
> ./boost/intrusive/list.hpp:1448:7: required from here
> .
A recent g++ change (I haven't tracked down exactly which one, but in
the last day or two) seems to have broken my boost build. It is dying
with lots of errors like:
./boost/intrusive/list.hpp:1448:7: required from here
./boost/intrusive/detail/list_iterator.hpp:93:41: error: call of
overloaded
On 8 June 2018 at 16:11, Joseph Myers wrote:
> On Fri, 8 Jun 2018, Jonathan Wakely wrote:
>
>> > The root cause is PR66203 which I reported quite some time ago, which
>> > points to a newlib problem: on aarch64 there is no default rom
>> > monitor, one has to explicitly use a --specs flag for the l
On Fri, 8 Jun 2018, Jonathan Wakely wrote:
> > The root cause is PR66203 which I reported quite some time ago, which
> > points to a newlib problem: on aarch64 there is no default rom
> > monitor, one has to explicitly use a --specs flag for the link to
> > succeed.
>
> I have no idea why this ca
On 8 June 2018 at 16:41, Jonathan Wakely wrote:
> On 8 June 2018 at 14:22, Christophe Lyon wrote:
>> Hi,
>>
>> As I reported in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
>> GCC for aarch64*-none-elf fails when configuring libstdc++ since
>> r261034 (a week ago).
>
> S
On 8 June 2018 at 14:22, Christophe Lyon wrote:
> Hi,
>
> As I reported in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
> GCC for aarch64*-none-elf fails when configuring libstdc++ since
> r261034 (a week ago).
Sorry for not trying to fix it, I'm travelling and not been a
Hi,
As I reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
GCC for aarch64*-none-elf fails when configuring libstdc++ since
r261034 (a week ago).
The root cause is PR66203 which I reported quite some time ago, which
points to a newlib problem: on aarch64 there is no
On Nov 22, 2013, at 10:13 AM, Jakub Jelinek wrote:
>> This is exactly the patch referenced in the pointer to the upstream repo.
>> Arno, does this fix the build for you?
>>
>> Ok?
>
> Yes
Committed revision 205285.
On Fri, Nov 22, 2013 at 07:21:07PM +0100, Arnaud Charlet wrote:
> > This is exactly the patch referenced in the pointer to the upstream repo.
> > Arno, does this fix the build for you?
>
> Well now I encounter:
>
> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: In
> f
> This is exactly the patch referenced in the pointer to the upstream repo.
> Arno, does this fix the build for you?
Well now I encounter:
/users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: In
function '__sanitizer::uptr __sanitizer::internal_filesize(__sanitizer::fd_t)':
On Fri, Nov 22, 2013 at 10:11:18AM -0800, Mike Stump wrote:
> On Nov 22, 2013, at 4:31 AM, Konstantin Serebryany
> wrote:
> > These CFI directives were completely removed in upstream at
> > http://llvm.org/viewvc/llvm-project?rev=192196&view=rev
> > Strangely, this did not get into the last merge
On Nov 22, 2013, at 4:31 AM, Konstantin Serebryany
wrote:
> These CFI directives were completely removed in upstream at
> http://llvm.org/viewvc/llvm-project?rev=192196&view=rev
> Strangely, this did not get into the last merge...
>
> Anyway, these cfi_* will (should, at least) disappear with th
On Fri, Nov 22, 2013 at 7:00 PM, FX wrote:
>> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:
>> Assembler messages:
>> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:821:
>> Error: .cfi_endproc without corresponding .cfi_startproc
>> :21485:
> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:
> Assembler messages:
> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:821:
> Error: .cfi_endproc without corresponding .cfi_startproc
> :21485: Error: open CFI at the end of file; missing .cfi
On Fri, 2013-11-22 at 12:30 +0100, Richard Biener wrote:
> On Fri, Nov 22, 2013 at 1:57 AM, Jonathan Wakely
> wrote:
> > Yes, it only seems to be a problem with SUSE kernels:
> > http://gcc.gnu.org/ml/gcc/2013-11/msg00090.html
>
> As my bugreport is being ignored it would help if one ouf our
> p
Hi,
On Fri, Nov 22, 2013 at 04:36:47PM +0400, Konstantin Serebryany wrote:
> On Fri, Nov 22, 2013 at 4:35 PM, Martin Jambor wrote:
> > On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote:
> >> > As my bugreport is being ignored it would help if one ouf our
> >>
> >> Sorry. Which
On Fri, Nov 22, 2013 at 1:36 PM, Konstantin Serebryany
wrote:
> On Fri, Nov 22, 2013 at 4:35 PM, Martin Jambor wrote:
>> On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote:
>>> > As my bugreport is being ignored it would help if one ouf our
>>>
>>> Sorry. Which one?
>>
>> I bel
On Fri, Nov 22, 2013 at 4:35 PM, Martin Jambor wrote:
> On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote:
>> > As my bugreport is being ignored it would help if one ouf our
>>
>> Sorry. Which one?
>
> I believe richi meant
> https://bugzilla.novell.com/show_bug.cgi?id=849180
On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote:
> > As my bugreport is being ignored it would help if one ouf our
>
> Sorry. Which one?
I believe richi meant
https://bugzilla.novell.com/show_bug.cgi?id=849180
Martin
>
> > partners (hint! hint!) would raise this issue via
On Fri, Nov 22, 2013 at 4:31 PM, Konstantin Serebryany
wrote:
> On Fri, Nov 22, 2013 at 3:56 PM, Jakub Jelinek wrote:
>> On Fri, Nov 22, 2013 at 12:47:17PM +0100, Arnaud Charlet wrote:
>>> > >>> Looks like another issue for the libsanitizer maintainers.
>>> > >>
>>> > >> I've been doing bootstrap
On Fri, Nov 22, 2013 at 3:56 PM, Jakub Jelinek wrote:
> On Fri, Nov 22, 2013 at 12:47:17PM +0100, Arnaud Charlet wrote:
>> > >>> Looks like another issue for the libsanitizer maintainers.
>> > >>
>> > >> I've been doing bootstraps, but didn't see this because the
>> > >> kernel header linux/vt.h u
> As my bugreport is being ignored it would help if one ouf our
Sorry. Which one?
> partners (hint! hint!) would raise this issue via the appropriate
> channel ;)
>
> Richard.
On Fri, Nov 22, 2013 at 12:47:17PM +0100, Arnaud Charlet wrote:
> > >>> Looks like another issue for the libsanitizer maintainers.
> > >>
> > >> I've been doing bootstraps, but didn't see this because the
> > >> kernel header linux/vt.h use on the RHEL6 system I was doing
> > >> builds on has that
> > Would appreciate a fix/work around!
>
> Configure with --disable-libsanitizer.
Will do, thanks.
> Would appreciate a fix/work around!
Configure with --disable-libsanitizer.
--
Eric Botcazou
> >>> Looks like another issue for the libsanitizer maintainers.
> >>
> >> I've been doing bootstraps, but didn't see this because the
> >> kernel header linux/vt.h use on the RHEL6 system I was doing
> >> builds on has that field renamed. Looking at our SLES11
> >> devel system I do see the probl
On Fri, Nov 22, 2013 at 1:57 AM, Jonathan Wakely wrote:
> On 21 November 2013 21:17, Peter Bergner wrote:
>> On Thu, 2013-11-21 at 16:03 -0500, David Edelsohn wrote:
>>> Looks like another issue for the libsanitizer maintainers.
>>
>> I've been doing bootstraps, but didn't see this because the
>>
> > Committed that way. Thanks! Ok for 4.7 branch as well?
>
> yes, it is. Thanks,
Done!
On Thu, May 10, 2012 at 3:33 PM, DJ Delorie wrote:
>
>> style nits: It should be size_t(__len - __pos), and not
>> (size_t)(__len - __pos). Same for the other hunk. Patch OK with
>> those changes.
>
> Committed that way. Thanks! Ok for 4.7 branch as well?
yes, it is. Thanks,
-- Gaby
> style nits: It should be size_t(__len - __pos), and not
> (size_t)(__len - __pos). Same for the other hunk. Patch OK with
> those changes.
Committed that way. Thanks! Ok for 4.7 branch as well?
* include/bits/random.tcc (seed_seq::generate): Cast max()
operands to size_t to
On Wed, 9 May 2012, Gabriel Dos Reis wrote:
On Wed, May 9, 2012 at 3:41 AM, Marc Glisse wrote:
necessary because of platforms where size_t is unsigned short (I didn't know
those existed...)
Well, I suspect AVR might be such platform but I do not seem to have an
ABI document for AVR yet... (h
On Wed, May 9, 2012 at 3:41 AM, Marc Glisse wrote:
> On Wed, 9 May 2012, Richard Guenther wrote:
>
>> On Wed, May 9, 2012 at 1:24 AM, Gabriel Dos Reis
>> wrote:
>>>
>>> On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
I assume this is a size_t vs int type problem, but the diagnos
On Wed, May 9, 2012 at 3:27 AM, Richard Guenther
wrote:
> On Wed, May 9, 2012 at 1:24 AM, Gabriel Dos Reis
> wrote:
>> On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
>>>
>>> I assume this is a size_t vs int type problem, but the diagnostic
>>> points to the function declaration, not to an act
On Wed, 9 May 2012, Richard Guenther wrote:
On Wed, May 9, 2012 at 1:24 AM, Gabriel Dos Reis
wrote:
On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
I assume this is a size_t vs int type problem, but the diagnostic
points to the function declaration, not to an actual binary
expression, and
On Wed, May 9, 2012 at 1:24 AM, Gabriel Dos Reis
wrote:
> On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
>>
>> I assume this is a size_t vs int type problem, but the diagnostic
>> points to the function declaration, not to an actual binary
>> expression, and I can't figure out what it's compla
On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
>
> I assume this is a size_t vs int type problem, but the diagnostic
> points to the function declaration, not to an actual binary
> expression, and I can't figure out what it's complaining about:
My mailer uses proportional fonts so I can't make
I assume this is a size_t vs int type problem, but the diagnostic
points to the function declaration, not to an actual binary
expression, and I can't figure out what it's complaining about:
/greed/dj/m32c/gcc/h8300-elf/./gcc/xgcc -shared-libgcc
-B/greed/dj/m32c/gcc/h8300-elf/./gcc -nostdinc++
-
> Jan Hubicka wrote:
> > I am testing patch for that still.
> > The current version is (updated per Joseph's comment about COMDAT making
> > sence
> > on !PUBLIC functions).
> >
> Thanks Honza, I just built successfully r154128
Note that there are still testsuite regressions found by the sanit
Jan Hubicka wrote:
> I am testing patch for that still.
> The current version is (updated per Joseph's comment about COMDAT making sence
> on !PUBLIC functions).
>
Thanks Honza, I just built successfully r154128
Paolo.*
*
On Thu, 12 Nov 2009, Paolo Carlini wrote:
> the build is currently, ie 154122, broken in libstdc++-v3:
>
> ./src/system_error.cc:95:1: internal compiler error:
> Segmentation fault
>
> Version 154120 works fine for me.
FWIW, seen for cris-elf too. (Worked: r154119, failed from: r154122.)
> Hi,
>
> the build is currently, ie 154122, broken in libstdc++-v3:
>
> ./src/system_error.cc:95:1: internal compiler error:
> Segmentation fault
>
> Version 154120 works fine for me.
I am testing patch for that still.
The current version is (updated per Joseph's comment about COMDAT ma
Hi,
the build is currently, ie 154122, broken in libstdc++-v3:
./src/system_error.cc:95:1: internal compiler error:
Segmentation fault
Version 154120 works fine for me.
Paolo.
Paolo,
Mike Stump's view was that darwin1 and darwin2 should be
ignored since they can't build FSF gcc for other reasons.
The idea was to fix these cases for the foreseeable future
by using darwin[921]* as the match. I also tested the patch
with a build of i686-apple-darwin9 and the results are
>Mike Stump's recommendation on this issue is to use the match
> darwin[912]* to make sure that this is captured for darwin9 through
> darwin29. The idea is to not match darwin3 through darwin8. This usage
> is present in several places...
>
> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg0033
On Thu, Apr 09, 2009 at 11:35:36AM +0200, Paolo Bonzini wrote:
> Jack Howarth wrote:
> >I see one place where breakage may have occured...
> >
> > http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/configure.ac?r1=144881&r2=144887
> >
> > --- trunk/configure.ac 2009/03/16 13:23:13 14
Jack Howarth wrote:
>I see one place where breakage may have occured...
>
> http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/configure.ac?r1=144881&r2=144887
>
> --- trunk/configure.ac2009/03/16 13:23:13 144881
> +++ trunk/configure.ac2009/03/16 17:02:02 144887
> @@
I see one place where breakage may have occured...
http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/configure.ac?r1=144881&r2=144887
--- trunk/configure.ac 2009/03/16 13:23:13 144881
+++ trunk/configure.ac 2009/03/16 17:02:02 144887
@@ -446,11 +446,11 @@
*-*-chorusos)
nocon
Unfortunately this hasn't been tested for awhile, but it appears
that the x86_64-apple-darwin target no longer can build java. I am
seeing...
checking build system type... x86_64-apple-darwin10
checking host system type... x86_64-apple-darwin10
checking target system type... x86_64-apple-darwi
On Tue, May 20, 2008 at 4:52 PM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
>> Does anybody else see build failure on 4_3 branch? My build from a
>> clean dir (./configure --with-mpfr=/usr/local) dies with
> It works for me. Maybe you have a too high -j and some dependencies
> are missing? W
On Tue, May 20, 2008 at 3:57 PM, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> Hello!
>
> Does anybody else see build failure on 4_3 branch? My build from a
> clean dir (./configure --with-mpfr=/usr/local) dies with
>
> gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall
> -Wwrite-strings -Wstri
Hello!
Does anybody else see build failure on 4_3 branch? My build from a
clean dir (./configure --with-mpfr=/usr/local) dies with
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pe
On Mar 6, 2007, at 11:14 AM, Matthias Klose wrote:
Mike Stump schrieb:
I have a feeling sed -i isn't our friend.
fixed.
I can confirm that this fixed my build. I'm expected the regression
tester to follow shortly.
Thanks.
Mike Stump schrieb:
It appears that one of these:
+ '[' -s .bad_compare ']'
+ exit 1
I have a feeling sed -i isn't our friend.
fixed.
Matthias
2007-03-06 Matthias Klose <[EMAIL PROTECTED]>
* doc/Makefile.am(gkeytool.pod): Don't use sed -i.
* doc/Makefile.in: Regenerate.
It appears that one of these:
r122580 | doko | 2007-03-05 15:23:18 -0800 (Mon, 05 Mar 2007) | 6 lines
2007-03-02 Mario Torre <[EMAIL PROTECTED]>
PR classpath/31017:
committed for Petteri R<83>ty
<[EMAIL P
Geoff,
If the autoconf patch isn't going in to gcc trunk, would someone
at Apple please nudge the folks who maintain www.opensource.apple.com
to post the Xcode Tools 2.4 source code release? Either than or post
a new cctools based off the same to the gcc ftp site. We really need
to be able to cr
On 10/09/2006, at 6:48 AM, Jack Howarth wrote:
Eric,
You definitely want the autoconf patch added
in otherwise builds of libgfortran will crash
when older cctools are used (like Xcode 2.3).
Typically what we do is just say that GCC requires a later version of
cctools.
smime.p7s
Descr
Eric,
You definitely want the autoconf patch added
in otherwise builds of libgfortran will crash
when older cctools are used (like Xcode 2.3).
I'll try a build of current gcc trunk with
your new darwin.c correction but without
the autoconf patch to see if all the literal16
support exists in Xco
Shantonu Sen wrote:
That's not correct. The linker support only exists in ld64 for Xcode
2.4. It fails like this for ld(32). 32-bit Darwin targets shouldn't be
using this assembly feature...
Right, I knew that. Looks like I have a typo though. Bah.
I'll fix it shortly. Though nothing wrong
That's not correct. The linker support only exists in ld64 for Xcode
2.4. It fails like this for ld(32). 32-bit Darwin targets shouldn't be
using this assembly feature...
Shantonu
On Sep 9, 2006, at 12:16 PM, Eric Christopher wrote:
Using the cctools from Xcode 2.4, the failure changes an
Jack Howarth wrote:
Eric,
One last question. Is it correct to assume that when
the newer cctools with the literal16 support becomes
available, things like 'integer(16)' will become available
in gfortran for darwin?
Seems reasonable to expect that it could be made to happen.
-eric
Eric,
One last question. Is it correct to assume that when
the newer cctools with the literal16 support becomes
available, things like 'integer(16)' will become available
in gfortran for darwin?
Jack
Using the cctools from Xcode 2.4, the failure changes and moves to the linkage
of libgfortran itself...
ld: .libs/maxloc0_4_r16.o unknown flags (type) of section 2
(__TEXT,__literal16) in load command 0
ld: .libs/maxloc0_8_r16.o unknown flags (type) of section 2
(__TEXT,__literal16) in load c
My original attempt to build gcc trunk yesterday used the
cctools from Xcode 2.3 and produced the failure...
/bin/sh ./libtool --mode=compile /sw/src/fink.build/gcc4-4.1.999-20060908/darwin
_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gc
c/ -B/sw/lib/gcc4/powerp
Okay. The problem with the libgfortran build failing is
unrelated to the remaining sections of the TImode patch.
I see the same failure with an unpatched version of current
gcc trunk. Time to file a PR.
Jack
ps I am currently building (for the last couple of days)
with --disable-boo
I should add that the last good build I have is from last
night at revision r116774.
Jack
To correct the typo in the last message, I am now rebuilding
without the reduced TImode patch to confirm it is not at fault.
As I said, since the build craps out in the 32-bit sections, I
doubt it is the source of the libgfortran build failure.
Jack
I don't know if this is related to Eric's checkins tonight
but I can no longer build libgfortran on Darwin PPC. The build fails
at...
/bin/sh ./libtool --mode=compile /sw/src/fink.build/gcc4-4.1.999-20060908/darwin
_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./g
This patch broke building GCC because Makefile indention was done with
spaces instead of a TAB.
Obvious fix commited, r115313. That will teach me how to think "oh
well that's a tiny patch I sent a month ago, I'll just copy it from
the mail archives instead of locating it on my disk".
Sorry.
--
Will fix right now.
2006/7/10, Jan-Benedict Glaw <[EMAIL PROTECTED]>:
On Mon, 2006-07-10 17:58:19 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: lauras
> Date: Mon Jul 10 17:58:18 2006
> New Revision: 115310
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115310
> Log:
>
On Mon, 2006-07-10 17:58:19 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: lauras
> Date: Mon Jul 10 17:58:18 2006
> New Revision: 115310
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115310
> Log:
> fixincludes:
> 2006-07-10 Laurynas Biveinis <[EMAIL PROTECTED]>
>
>
Hi!
Building for VAX is broken again (this is already the cross-compiler
building a vax-hosted gcc):
:
:
vax-linux-uclibc-gcc -c -static -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-s
> I didn't even have an old bootstrap of the trunk for HP-UX; I tried to do
> one and it died with
>
> ./xgcc -B./ -B/u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/bin/ -isystem
> /u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/include -isystem
> /u/jbuck/cvs.hp/trunk/hppa2.0w-hp-hpux11.00/sys-include
I wrote:
> >I'll check HP-UX/HPPA and let you know; since I didn't have a recent
> >bootstrap of the trunk it will take a bit.
On Mon, Apr 04, 2005 at 03:45:26PM -0700, Geoffrey Keating wrote:
> Even a relatively old bootstrap will do, assembler/linker
> nondeterminism is what I'm really concern
73 matches
Mail list logo
