Re: GCC trunk bootstrap failure on i686-w64-mingw32

在 2022-10-29 20:15, Eric Botcazou 写道: So what could be causing it? An oversight in https://gcc.gnu.org/pipermail/gcc-cvs/2022-August/370830.html has broken --disable-sjlj-exceptions. That's now fixed. Thank you. Rebuilding now. -- Best regards, LIU Hao OpenPGP_signature Description: Op

Re: GCC trunk bootstrap failure on i686-w64-mingw32

> So what could be causing it? An oversight in https://gcc.gnu.org/pipermail/gcc-cvs/2022-August/370830.html has broken --disable-sjlj-exceptions. That's now fixed. -- Eric Botcazou

GCC trunk bootstrap failure on i686-w64-mingw32

Greetings, Since at least a week ago, GCC trunk fails to bootstrap with a lot such errors during stage1: ``` D:\lh_mouse\GitHub\MINGW-packages\mingw-w64-gcc\src\build-MINGW32\i686-w64-mingw32\libstdc++-v3\src\c++11/../../../../../gcc/libstdc++-v3/src/c++11/functexcept.cc:74: undefined

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

On 6/16/21 1:32 PM, Uros Bizjak wrote: > On Wed, Jun 16, 2021 at 6:08 PM Liu Hao wrote: >> It looks like Uroš was on 00d07ec6e12, committed his changes mistakenly with >> `git commit --amend` >> (which changed the commit message but did not reset the author), then >> rebased the modified commit

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

On Wed, Jun 16, 2021 at 6:08 PM Liu Hao wrote: > > 在 2021-06-16 23:22, Jonathan Wakely via Gcc 写道: > >> Is there someone who an dig into the commit below > >> and try to find out how the author field was incorrectly set? > > > > That gets set when the local commit is done, before pushing it to the

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

在 2021-06-16 23:22, Jonathan Wakely via Gcc 写道: Is there someone who an dig into the commit below and try to find out how the author field was incorrectly set? That gets set when the local commit is done, before pushing it to the server. I don't think there's any way to find out how/why that ha

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

>Is there someone who an dig into the commit below >and try to find out how the author field was incorrectly set? That gets set when the local commit is done, before pushing it to the server. I don't think there's any way to find out how/why that happened after the fact. You did author the commit

GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

Hi all, I recently did a search on a git log of gcc trunk looking for a particular commit of mine, so was searching for my name, and I came across a commit from Uroš that lists me as the Author. I did not author that commit and talking with Uroš offline, he assures me that he didn't use --a

Re: is there a reason why "explicit specialization in non-namespace scope" is still an error in gcc-trunk?

On Wed, Sep 23, 2020 at 02:42:01PM +0200, Dennis Luehring wrote: > i've read that scoped template specalization is allowed in C++17 > > > clang supports it starting with release 7 > > MSVC supports it with VS2017(i don't know what revision) > > Intel does not like it Because CWG 727 isn't impl

when will "scoped template specalization" be available? gcc trunk seems not support it

i've read that scoped template specalization is allowed in C++17 - is it planned for the next gcc release? otherwise i will switch to an if constexpr solution - but would be still to have this feature checked compiler: gcc trunk (and latest intel) do not support it clang (starting with re

is there a reason why "explicit specialization in non-namespace scope" is still an error in gcc-trunk?

i've read that scoped template specalization is allowed in C++17 clang supports it starting with release 7 MSVC supports it with VS2017(i don't know what revision) Intel does not like it https://gcc.godbolt.org/z/1GET6v -- enumclass E{ A, B }; struct Ta{ int x; }; struct Tb{ float y; 

Re: Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation)

On 11/20/17, Eric Gallager wrote: > On 11/20/17, Yao Qi wrote: >> >> Hi, >> I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some >> -Werror=stringop-overflow= and -Werror=stringop-truncation warnings. >> Some of them are not necessary to me

Re: Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation)

On 17-11-20 09:33:46, Martin Sebor wrote: > On 11/20/2017 08:51 AM, Yao Qi wrote: > > > >Hi, > >I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some > >-Werror=stringop-overflow= and -Werror=stringop-truncation warnings. > >Some of them are not

Re: Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation)

On 11/20/2017 08:51 AM, Yao Qi wrote: Hi, I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some -Werror=stringop-overflow= and -Werror=stringop-truncation warnings. Some of them are not necessary to me, I have the attached patch for two of these but I have been waiting to

Re: Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation)

On 11/20/17, Yao Qi wrote: > > Hi, > I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some > -Werror=stringop-overflow= and -Werror=stringop-truncation warnings. > Some of them are not necessary to me, > > 1. ../../binutils-gdb/gdb/python/py-gdb-readline.

Fail to compile GDB with recent GCC trunk (-Werror=stringop-overflow=, -Werror=stringop-truncation)

Hi, I failed to compile GDB with GCC trunk (8.0.0 20171117) because of some -Werror=stringop-overflow= and -Werror=stringop-truncation warnings. Some of them are not necessary to me, 1. ../../binutils-gdb/gdb/python/py-gdb-readline.c:79:15: error: ‘char* strncpy(char*, const char*, size_t

Re: Fwd: Windows support dropped from gcc trunk

On Wed, Oct 14, 2015 at 11:48:27AM -0400, Tim Prince wrote: > > > > > I added gcc@gcc.gnu.org as this technically isn't a Fortran issue. > test suite reports hundred of new ICE instances, all referring to this > seh_unwind_emit function: > > /cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/gcc/testsuit

Re: Fwd: Windows support dropped from gcc trunk

ows 64-bit has been dropped >> from gcc trunk: >> winnt.c apparently has problems with seh, which prevent bootstrapping, >> and prevent the new gcc from building libraries. >> libgfortran build throws a fatal error on account of lack of support for >> __float128, even i

Re: Fwd: Windows support dropped from gcc trunk

On Wed, Oct 14, 2015 at 11:32:52AM -0400, Tim Prince wrote: > > Sorry if someone sees this multiple times; I think it may have been > stopped by ISP or text mode filtering: > > Since Sept. 26, the partial support for Windows 64-bit has been dropped > from gcc trunk: > w

Re: LTO IPA inline decisions in GCC trunk.

using GCC Linaro compiler (september) which is based on FSF 4.9 and > GCC trunk 30-sep-2014. > > With linaro compiler perf events show 5% less instruction counts compared > to the GCC trunk version I used. > > I looked at the generated code and seeing that IPA inlining have changed >

LTO IPA inline decisions in GCC trunk.

based on FSF 4.9 and GCC trunk 30-sep-2014. With linaro compiler perf events show 5% less instruction counts compared to the GCC trunk version I used. I looked at the generated code and seeing that IPA inlining have changed between linaro and trunk. Linaro compiler does not seem to inline a fun

Re: Failure bootstrapping GCC trunk on Cygwin

The following simple patch allow for the bootstrap to be completed: --- gcc-trunk-r199624/gcc/config/i386/winnt.c~ 2013-05-30 03:26:05.0 +0200 +++ gcc-trunk-r199624/gcc/config/i386/winnt.c 2013-06-04 19:24:49.140625000 +0200 @@ -480,7 +480,7 @@ flags |= SECTION_LINKONCE

Failure bootstrapping GCC trunk on Cygwin

For the sake of completeness... Bootstrapping trunk r199624 fails on Cygwin as follows: $ /work/gcc-trunk-r199624/configure --prefix=/usr/local/gfortran --program-suffix=-4.9 --enable-languages=c,c++,fortran --enable-checking=release --enable-threads=posix --enable-libgomp --enable

Re: Merging Cilk Plus into GCC Trunk

On 09/05/12 12:09, Iyer, Balaji V wrote: I can't speak for the rest of the community, but I think items 1-12 are useful for GCC (elemental functions, SIMD annotations, and array notations for C/C++), regardless of any language extensions. Perhaps you could provide examples on these as a start

Re: Merging Cilk Plus into GCC Trunk

On 09/05/2012 12:59 PM, Joseph S. Myers wrote: Regarding the patch ordering you list, note that earlier patches may not be reviewable without later ones (specifically, code changes can only be reviewed given documentation and testcases - in some cases documentation might be external, but it does

RE: Merging Cilk Plus into GCC Trunk

Jeff Law; r...@redhat.com >Subject: RE: Merging Cilk Plus into GCC Trunk > >On Wed, 5 Sep 2012, Iyer, Balaji V wrote: > >> If this is OK with everyone, I will start sending patches to >> gcc-patches mailing list soon. > >Regarding the patch ordering you list, note that ea

RE: Merging Cilk Plus into GCC Trunk

On Wed, 5 Sep 2012, Iyer, Balaji V wrote: > If this is OK with everyone, I will start sending patches to > gcc-patches mailing list soon. Regarding the patch ordering you list, note that earlier patches may not be reviewable without later ones (specifically, code changes can only be revi

RE: Merging Cilk Plus into GCC Trunk

lto:al...@redhat.com] >Sent: Tuesday, September 04, 2012 6:24 PM >To: Iyer, Balaji V >Cc: 'gcc@gcc.gnu.org'; Jeff Law; r...@redhat.com >Subject: Re: Merging Cilk Plus into GCC Trunk > >On 08/30/12 15:39, Iyer, Balaji V wrote: >> Hello Everyone, >> The Cilk-P

Re: Merging Cilk Plus into GCC Trunk

On 08/30/12 15:39, Iyer, Balaji V wrote: Hello Everyone, The Cilk-Plus branch is feature-complete. Programs using Cilk Plus constructs get great performance on vector and multicore hardware. Programs that don't use the new language features (enabled by a -fcilkplus flag) see no change.

Merging Cilk Plus into GCC Trunk

Hello Everyone, The Cilk-Plus branch is feature-complete. Programs using Cilk Plus constructs get great performance on vector and multicore hardware. Programs that don't use the new language features (enabled by a -fcilkplus flag) see no change. For details please see http://cilkplus.org

gcc trunk target libraries do not build on Darwin 12.1

I am having trouble building the trunk om Mac OS X 10.8.1 (Darwin 12.1.0). Configuring target libraries fails with the following error (e.g. libatomic): configure:3477: checking for C compiler default output file name configure:3499: /eng/upc/dev/nenad/gcc-trunk/bld/./gcc/xgcc -B/eng/upc/dev

Re: gcc trunk fails to build without isl/cloog

See . Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: gcc trunk fails to build without isl/cloog

On Aug 13, 2012, at 12:42 PM, H.J. Lu wrote: > On Mon, Aug 13, 2012 at 9:01 AM, wrote: >> The installation instructions seem to imply that GCC can be built without >> having ISL and/or CLOOG installed, and the configure script accepts >> --without-isl and --without-cloog. >> >> But I can't b

Re: gcc trunk fails to build without isl/cloog

On Mon, Aug 13, 2012 at 9:01 AM, wrote: > The installation instructions seem to imply that GCC can be built without > having ISL and/or CLOOG installed, and the configure script accepts > --without-isl and --without-cloog. > > But I can't build that. Reading the installation instructions makes

gcc trunk fails to build without isl/cloog

The installation instructions seem to imply that GCC can be built without having ISL and/or CLOOG installed, and the configure script accepts --without-isl and --without-cloog. But I can't build that. Reading the installation instructions makes me expect that such a configuration would skip th

GCC trunk [future 4.8] merged into MELT branch.

Hello all I just merged the trunk (future 4.8, svn rev 185094 into the MELT branch. This is the first merge of trunkk 4.8 into MELT. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bour

Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h

On 7 December 2011 20:14, Christian Joensson wrote: > I am trying to build gcc trunk on cygwin (with the snapshot of > 20111207) and get this: > > /usr/local/src/trunk/objdir.withada/./prev-gcc/g++ > -B/usr/local/src/trunk/objdir.withada/./prev-gcc/ > -B/usr/i686-pc-cygwin/bin

Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h

On 8 December 2011 01:09, Ian Lance Taylor wrote: > Jonathan Wakely writes: > >>> Should the Cygwin header use >>> extern "C++" on those declarations even though they're inside #ifdef >>> __cplusplus, or should adaint.c not #include things inside extern "C"? >> >> You could surround them in extern

Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h

Jonathan Wakely writes: >> Should the Cygwin header use >> extern "C++" on those declarations even though they're inside #ifdef >> __cplusplus, or should adaint.c not #include things inside extern "C"? > > You could surround them in extern "C++", linkage specifications nest. ...but I think it wo

Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h

On Wednesday, 7 December 2011, Dave Korn wrote: > On 07/12/2011 19:14, Christian Joensson wrote: >> I am trying to build gcc trunk on cygwin (with the snapshot of >> 20111207) and get this: > >> /usr/local/src/trunk/gcc/gcc/ada/adaint.c -o ada/adaint.o >> In fil

Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h

On 07/12/2011 19:14, Christian Joensson wrote: > I am trying to build gcc trunk on cygwin (with the snapshot of > 20111207) and get this: > /usr/local/src/trunk/gcc/gcc/ada/adaint.c -o ada/adaint.o > In file included from /usr/local/src/trunk/gcc/gcc/system.h:346:0, >

Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h

I am trying to build gcc trunk on cygwin (with the snapshot of 20111207) and get this: /usr/local/src/trunk/objdir.withada/./prev-gcc/g++ -B/usr/local/src/trunk/objdir.withada/./prev-gcc/ -B/usr/i686-pc-cygwin/bin/ -nostdinc++ -B/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3

Re: Issues with building gcc trunk with ada on cygwin

> I haven't tried it yet but the 'cygwin32' looks suspicsious to me, > i.e., the 32, to my understanding that '32' was removed years ago.. We should probably use the Windows-specific setting unconditionally. -- Eric Botcazou

Re: Issues with building gcc trunk with ada on cygwin

On 20 November 2011 12:06, Eric Botcazou wrote: >> Now, are there anyones here that recognise the issue and perhaps have >> an idea of how to address it? > > Take a look at gcc/ada/Makefile.in lines 279 and below: > > ifeq ($(strip $(filter-out cygwin32% mingw32% pe,$(osys))),) >  # On Windows nati

Re: Issues with building gcc trunk with ada on cygwin

> Now, are there anyones here that recognise the issue and perhaps have > an idea of how to address it? Take a look at gcc/ada/Makefile.in lines 279 and below: ifeq ($(strip $(filter-out cygwin32% mingw32% pe,$(osys))),) # On Windows native the tconfig.h files used by C runtime files needs to h

Issues with building gcc trunk with ada on cygwin

I have an issue with building gcc trunk, current and since quite a while. There seems to me to be quite some missing includes while building stage 3 compared with stage 2. For example, the adadecode.c comile in stage 2 for me looks like this: make[5]: Entering directory `/usr/local/src/trunk

Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"

Den 11 november 2011 16:30 skrev Jason Merrill: > On 11/11/2011 07:02 AM, Christian Jönsson wrote: >> >> revision r181278 gives me a bootstrap/build error on cygwin for gcc >> trunk like this > > I've now conditioned those functions on the macro being defined.  

Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"

On 11/11/2011 07:02 AM, Christian Jönsson wrote: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk like this I've now conditioned those functions on the macro being defined. Does that fix it for you? Jason

Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"

> Just to make sure nobody is midled by th subject of your message: > your bootstrap problem obviously has nothing to do with the warning itself. > The latter has been discussed already on these mailing lists, is absolutely > bening. I have open pr51094 for this bootstrap failure. Note that it is

Re: revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"

Hi, > revision r181278 gives me a bootstrap/build error on cygwin for gcc > trunk like this Just to make sure nobody is midled by th subject of your message: your bootstrap problem obviously has nothing to do with the warning itself. The latter has been discussed already on these mailing

revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk: cc1: warning: unrecognized command line option "-Wno-narrowing"

revision r181278 gives me a bootstrap/build error on cygwin for gcc trunk like this gcc-4 -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic

Re: gcc-trunk build error in OpenBSD on stage3

niXman writes: >> Why is this failing on your system? > Up to now, I've been building GCC on a different machine (the OS > wasn't installed by me). Now, I have installed OpenBSD-5.0 on the VM. > > >> Look for uses of RPATH_ENVVAR in the top level Makefile. > This line from Makefile: > RPATH_ENVVA

Re: gcc-trunk build error in OpenBSD on stage3

> Why is this failing on your system? Up to now, I've been building GCC on a different machine (the OS wasn't installed by me). Now, I have installed OpenBSD-5.0 on the VM. > Look for uses of RPATH_ENVVAR in the top level Makefile. This line from Makefile: RPATH_ENVVAR = LD_LIBRARY_PATH LD_LIBR

Re: gcc-trunk build error in OpenBSD on stage3

Diffs between stage2 and stage3. on configure libiberty for stage3 I see this warnings: configure:4962: checking for limits.hconfigure:4962: /home/root/gcc-build/build/gcc-trunk/./prev-gcc/xgcc-B/home/root/gcc-build/build/gcc-trunk/./prev-gcc/-B/usr/local/i686-pc-openbsd5.0/bin/-B/usr/local/i686

Re: gcc-trunk build error in OpenBSD on stage3

niXman writes: > in libiberty/config.h macro HAVE_LIMITS_H is undefined. Look in libiberty/config.log to see why HAVE_LIMITS_H is not defined. Also why HAVE_STDLIB_H is not defined. Ian

gcc-trunk build error in OpenBSD on stage3

Hi list. On build gcc-trunk in OpenBSD-5.0 on staget 3 I get the following errors: if [ x"-fpic" != x ]; then \ /home/root/gcc-build/build/gcc-trunk/./prev-gcc/xgcc -B/home/root/gcc-build/build/gcc-trunk/./prev-gcc/ -B/usr/local/i686-pc-openbsd5.0/bin/ -B/usr/local/i686-pc-openbsd5

merged GCC trunk 176387 into MELT branch

Hello All I just merged trunk into the MELT branch. (you probably will need to rebuild the branch in a fresh build tree) Cheers -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, F

Re: internal compiler error in gcc trunk when using std::map

On 10 December 2010 00:40, Nathan Ridge wrote: > > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. This mailing list is not the right way to report bugs, you should have followed the instructions in the output you q

internal compiler error in gcc trunk when using std::map

Hello, I've just build the gcc trunk and tried to compile some code that compiled fine with gcc 4.5. It gave an internal compiler error. I've reduced it to the following minimal test case: #include #include int main() { std::map m; std::pair p; m.insert(p);

Re: GCC trunk revision 166285 passes SPEC CPU 2000/2006

On Fri, Nov 5, 2010 at 1:43 PM, H.J. Lu wrote: > FYI, GCC trunk revision 166285 passes SPEC CPU 2000/2006. > It is the first time in a month. Ship it! Richard.

GCC trunk revision 166285 passes SPEC CPU 2000/2006

FYI, GCC trunk revision 166285 passes SPEC CPU 2000/2006. It is the first time in a month. -- H.J.

Re: Waiting for stdin while compiling GCC-trunk

6:22 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Waiting for stdin while compiling GCC-trunk Hello all, When I try to compile GCC (trunk revision 161164). It seems that gcc is waiting for reading on stdin after libgcc2.c. This is what I get : make[2]: Nothing to b

Waiting for stdin while compiling GCC-trunk

Hello all, When I try to compile GCC (trunk revision 161164). It seems that gcc is waiting for reading on stdin after libgcc2.c. This is what I get : make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/export/is005060/jsalvucci/gcc-trunk-build/libcpp' make[2]

Re: RFC: merging GUPC into the GCC trunk?

On Wed, 7 Apr 2010, Gary Funck wrote: > What is the recommended process for having GUPC reviewed > (and hopefully, subsequently approved) for being merged > into the GCC mainline? Are there any fixes / enhancements you need in common GCC code? If so, submitting those first and separately might ma

Re: RFC: merging GUPC into the GCC trunk?

On Wed, Apr 7, 2010 at 11:05, Gary Funck wrote: > What is the recommended process for having GUPC reviewed > (and hopefully, subsequently approved) for being merged > into the GCC mainline? I would suggest splitting patches across reviewer domains. See previous merges from big branches for exam

RFC: merging GUPC into the GCC trunk?

Now that GCC 4.5 has been branched from the main line, it seems that this is an appropriate time to consider GUPC for inclusion into the GCC trunk. GUPC was recently checked in as a GCC branch: http://gcc.gnu.org/projects/gupc.html What is the recommended process for having GUPC reviewed (and

Re: rebuild test of Debian packages with GCC trunk 20100107

On Mon, Jan 11, 2010 at 7:15 PM, Matthias Klose wrote: > A rebuild test of the current Debian unstable distribution on > x86_64-linux-gnu was done, one rebuild test with the current gcc-4.4 from > the branch, and another one with GCC trunk 20100107. The latter did show > about 20

rebuild test of Debian packages with GCC trunk 20100107

A rebuild test of the current Debian unstable distribution on x86_64-linux-gnu was done, one rebuild test with the current gcc-4.4 from the branch, and another one with GCC trunk 20100107. The latter did show about 200 additional build failures, which are listed in [1] (minus some already known

Re: Building gold from binutils-2.20 alongside gcc trunk errors out:

Richard Guenther wrote: On Sun, Oct 25, 2009 at 7:42 PM, Toon Moene wrote: /usr/snp/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/bin/ld: error: /scratch/hirlam/hl_home/EXP/lib/src/linuxgfortran/lib/port.a: multiple definition of casihl_ /usr/snp/lib/gcc/x86_64-

Re: Building gold from binutils-2.20 alongside gcc trunk errors out:

On Sun, Oct 25, 2009 at 7:42 PM, Toon Moene wrote: > Toon Moene wrote: >> >> As follows: >> >> g++ -DHAVE_CONFIG_H -I. -I../../gcc/gold  -I../../gcc/gold >> -I../../gcc/gold/../include -I../../gcc/gold/../elfcpp >> -DLOCALEDIR="\"/usr/snp/share/locale\"" -DBINDIR="\"/usr/snp/bin\"" >> -DTOOLBINDIR

Re: Building gold from binutils-2.20 alongside gcc trunk errors out:

Toon Moene wrote: As follows: g++ -DHAVE_CONFIG_H -I. -I../../gcc/gold -I../../gcc/gold -I../../gcc/gold/../include -I../../gcc/gold/../elfcpp -DLOCALEDIR="\"/usr/snp/share/locale\"" -DBINDIR="\"/usr/snp/bin\"" -DTOOLBINDIR="\"/usr/snp/x86_64-unknown-linux-gnu/bin\"" -W -Wall -Werror -D_L

Building gold from binutils-2.20 alongside gcc trunk errors out:

As follows: g++ -DHAVE_CONFIG_H -I. -I../../gcc/gold -I../../gcc/gold -I../../gcc/gold/../include -I../../gcc/gold/../elfcpp -DLOCALEDIR="\"/usr/snp/share/locale\"" -DBINDIR="\"/usr/snp/bin\"" -DTOOLBINDIR="\"/usr/snp/x86_64-unknown-linux-gnu/bin\"" -W -Wall -Werror -D_LARGEFILE_SOURCE -D_

Re: Incorporation of Objective-C 2.0 changes into GCC trunk

What is the process for getting a blob of code assigned to the FSF that is not just being committed into the tree? Creating a branch on gcc.gnu.org and committing it there should be enough. Paolo

Re: Incorporation of Objective-C 2.0 changes into GCC trunk

On Jul 22, 2009, at 2:58 AM, Paolo Bonzini wrote: On 07/22/2009 10:57 AM, Richard Guenther wrote: On Tue, Jul 21, 2009 at 11:14 PM, Paolo Bonzini wrote: Gregory Casamento wrote: As far as I'm aware apple has an assignment for changes to gcc, so it should be possible to pull them in. You'r

Re: Incorporation of Objective-C 2.0 changes into GCC trunk

Gregory Casamento wrote: > If not, I would like to know what the GNUstep project can do to help > make this happen. Persuade Apple to de-embargo their engineers from showing their faces in public round here?(*) At least from the outside, it appears that Apple(**) is simply not interested in

Re: Incorporation of Objective-C 2.0 changes into GCC trunk

On 07/22/2009 10:57 AM, Richard Guenther wrote: On Tue, Jul 21, 2009 at 11:14 PM, Paolo Bonzini wrote: Gregory Casamento wrote: As far as I'm aware apple has an assignment for changes to gcc, so it should be possible to pull them in. You're not forced to assign changes that you do not want to

Re: Incorporation of Objective-C 2.0 changes into GCC trunk

On Tue, Jul 21, 2009 at 11:14 PM, Paolo Bonzini wrote: > Gregory Casamento wrote: >> As far as I'm aware apple has an assignment for changes to gcc, so it >> should be possible to pull them in. > > You're not forced to assign changes that you do not want to assign. I don't understand. Yes you are

Re: Incorporation of Objective-C 2.0 changes into GCC trunk

Gregory Casamento wrote: > As far as I'm aware apple has an assignment for changes to gcc, so it > should be possible to pull them in. You're not forced to assign changes that you do not want to assign. Paolo

Re: Incorporation of Objective-C 2.0 changes into GCC trunk

As far as I'm aware apple has an assignment for changes to gcc, so it should be possible to pull them in. On Tuesday, July 21, 2009, wrote: > Op 21 jul. 2009 21:50 schreef Paolo Bonzini : >> Gregory Casamento wrote: >> >> > Hey guys I'm wondering if there's a timeline for incorporating the >

Re: Incorporation of Objective-C 2.0 changes into GCC trunk

Gregory Casamento wrote: > All, > > Hey guys I'm wondering if there's a timeline for incorporating the > Objective-C 2.0 changes from Apple into the trunk of GCC. > > If not, I would like to know what the GNUstep project can do to help > make this happen. No. But you just have to take patch

Incorporation of Objective-C 2.0 changes into GCC trunk

All, Hey guys I'm wondering if there's a timeline for incorporating the Objective-C 2.0 changes from Apple into the trunk of GCC. If not, I would like to know what the GNUstep project can do to help make this happen. Thanks very much. :) Sincerely, GC -- Gregory Casamento Open Logic Corpora

Re: gcc-trunk bootstrap failure in libjava on i686-pc-cygwin

Rainer Emrich wrote: > shows link failure "undefined reference to `_dlmmap'" and "undefined reference > to `_dlmunmap'" Sorry, I got distracted from this one for a bit. I'm working on a fix. cheers, DaveK

gcc-trunk bootstrap failure in libjava on i686-pc-cygwin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 gcc-trunk revision 149297 configured with ../../../../src/gcc-4.5.0/configure - --prefix=/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin - --with-gmp=/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin - --with-mpfr=/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin

gcc trunk miscompiles binutils

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 seen on i686-pc-cygwin and x86_64-unknown-linux-gnu at least since revision 148309 and binutils HEAD from 6th of June. Affected is the assembler. Here a part of the testsuite gas.sum on i686-pc-cygwin: Running /home/rainer/software/src/binutils-cvs-

Re: [gcc trunk on cygwin] ../../gcc/gcc/config/i386/msformat-c.c:[39,40,41,42,43,44,58,75,87,110,128,145] error: enum conversion in initialization is invalid in C++

2009/5/5 Dave Korn : > Christian Joensson wrote: > >> ../../gcc/gcc/config/i386/msformat-c.c:39: error: enum conversion in >> initialization is invalid in C++ > >> Any hints on what's going on and how to cure the issue? > >  Yep: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00125.html (and thread).

Re: [gcc trunk on cygwin] ../../gcc/gcc/config/i386/msformat-c.c:[39,40,41,42,43,44,58,75,87,110,128,145] error: enum conversion in initialization is invalid in C++

Christian Joensson wrote: > ../../gcc/gcc/config/i386/msformat-c.c:39: error: enum conversion in > initialization is invalid in C++ > Any hints on what's going on and how to cure the issue? Yep: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00125.html (and thread). cheers, DaveK

[gcc trunk on cygwin] ../../gcc/gcc/config/i386/msformat-c.c:[39,40,41,42,43,44,58,75,87,110,128,145] error: enum conversion in initialization is invalid in C++

This is on Windows XP Pro/SP3 cygwin Intel Core2 Duo t9...@2.80ghz system with packages: binutils 20080624-2 2.18.50.20080625 bison2.3-1 2.3 cloog-ppl0.15.3-1 cygwin 1.7.0-46 dejagnu 20021217-2 1.4.2.x expect

Re: update_version_svn (was: Minimum required GNAT version for bootstrap of GNAT on gcc trunk)

On Sat, 4 Apr 2009, Gerald Pfeifer wrote: > 2009-04-04 Gerald Pfeifer > > * update_web_docs_svn: Run this script under plain /bin/sh > as opposed to /bin/sh -x. I think this is OK. -x was probably more useful before the script used set -e to exit on errors. -- Joseph S. Myers

Re: Minimum required GNAT version for bootstrap of GNAT on gcc trunk

To add to this data: on i686-mingw the system gcc-3.4.5-20060117-3 is able to bootstrap SVN 4.4 with --enable-languages=c,ada the resulting compiler is able to compile simple Ada programs and ACATS is currently running (I can't test C because I don't have dejagnu - advice welcomed). Current trunk

Re: update_version_svn (was: Minimum required GNAT version for bootstrap of GNAT on gcc trunk)

On Sat, Apr 4, 2009 at 2:57 PM, Gerald Pfeifer wrote: > On Tue, 24 Feb 2009, Joseph S. Myers wrote: >> build.html was missing group write permission: >> >> -rw-r--r--   1 gerald   gcc 18920 Mar 30  2008 build.html >> >> This probably meant that the nightly onlinedocs update would fail to >> update

update_version_svn (was: Minimum required GNAT version for bootstrap of GNAT on gcc trunk)

On Tue, 24 Feb 2009, Joseph S. Myers wrote: > build.html was missing group write permission: > > -rw-r--r-- 1 gerald gcc 18920 Mar 30 2008 build.html > > This probably meant that the nightly onlinedocs update would fail to > update it. I've now moved and copied the file so it now has group

Re: Problem with a cross-compiler based on gcc-trunk

First thing would be to try and figure out why the insn isn't being > recognized. This is rather odd unless your patch has affected the movsi > definition in the .md file. Does the error go away if you make sure there > is > no dllimport/export attribute? > > cheers,

Re: Problem with a cross-compiler based on gcc-trunk

Vincent R. wrote: > vinc...@vincent-pc:~/projects$ arm-mingw32ce-gcc -std=gnu99 -save-temps > -I/home/vincent/local/wince/include -DNDEBUG -O3 -c cegcc-errno-bug.c > -DDLL_EXPORT -DPIC -o libeet_la-eet_lib.o > cegcc-errno-bug.c: In function 'eet_close': > cegcc-errno-bug.c:134: error: unrecogniza

Problem with a cross-compiler based on gcc-trunk

Hi, I am testing a cross-compiler targetting arm-wince-pe and based on gcc-trunk revision r144975 and when compiling a project I get the following error : vinc...@vincent-pc:~/projects$ arm-mingw32ce-gcc -std=gnu99 -save-temps -I/home/vincent/local/wince/include -DNDEBUG -O3 -c cegcc-errno-bug.c

Re: Minimum required GNAT version for bootstrap of GNAT on gcc trunk

Laurent GUERBY wrote: > > On i686-linux for c,ada: > > 3.4.4 bootstraped 4.3.2 fine (your configuration) > 3.4.0 bootstraped 4.3.1 fine > 3.4.0 bootstraped trunk 143919 fine > > I'm not going to test more, a priori what the documentation > currently says for Ada is correct at least for i686-lin

Re: Minimum required GNAT version for bootstrap of GNAT on gcc trunk

On Thu, 2009-03-05 at 18:24 +0100, Laurent GUERBY wrote: > On Tue, 2009-02-24 at 20:40 +0100, Laurent GUERBY wrote: > > On Tue, 2009-02-24 at 19:36 +, Dave Korn wrote: > > > Laurent GUERBY wrote: > > > > On Tue, 2009-02-24 at 18:59 +, Dave Korn wrote: > > > >> Laurent GUERBY wrote: > > > >>

Re: Minimum required GNAT version for bootstrap of GNAT on gcc trunk

On Tue, 2009-02-24 at 20:40 +0100, Laurent GUERBY wrote: > On Tue, 2009-02-24 at 19:36 +, Dave Korn wrote: > > Laurent GUERBY wrote: > > > On Tue, 2009-02-24 at 18:59 +, Dave Korn wrote: > > >> Laurent GUERBY wrote: > > >> > > >>> I'm not sure 3.4 will work for trunk > > >> I was just en

Re: Minimum required GNAT version for bootstrap of GNAT on gcc trunk

I managed to build it with my own compiled version of GCC-4.3 under Ubuntu. The stock 4.1 compilers failed on a -f flag IIRC, can't remember what it was exactly though. Luke.

Re: Minimum required GNAT version for bootstrap of GNAT on gcc trunk

On Tue, 24 Feb 2009, Laurent GUERBY wrote: > On Tue, 2009-02-24 at 23:32 +0100, Gerald Pfeifer wrote: > > On Tue, 24 Feb 2009, Laurent GUERBY wrote: > > >> At http://gcc.gnu.org/install/build.html , I see: > > > I believe this one is for released compilers, not SVN trunk. > > > > Actually, http:/

Re: Minimum required GNAT version for bootstrap of GNAT on gcc trunk

On Tue, Feb 24, 2009 at 02:54:54PM -0800, Laurent GUERBY wrote: > In trunk install.texi: > > "In order to build GNAT, the Ada compiler, you need a working GNAT > compiler (GCC version 3.4 or later)." > > On the web: > > "In order to build GNAT, the Ada compiler, you need a working GNAT > compile

  1   2   3   >