Current trunk fails to build gmp

Since some time in November last year trunk fails to build gmp. Last successfull build was 30th of October last year. The issue seems to be a failing configure test. From config.log: Test compile: long long reliability test 1 configure:6585: /opt/devel/gnu/gcc/Linux/x86_64-pc-linux-gnu/Ubuntu_2

Re: A lot of additional testsuite failures when bootstrapping with "--with-arch=native --with-tune=native" on AMD Threadripper

Am 12.04.2023 um 12:57 schrieb Richard Biener: On Wed, Apr 12, 2023 at 11:03 AM Rainer Emrich wrote: I did some optimization testing by bootstrapping with "--with-arch=native --with-tune=native" on an AMD Threadripper system, that's "znver2". I'm not su

A lot of additional testsuite failures when bootstrapping with "--with-arch=native --with-tune=native" on AMD Threadripper

I did some optimization testing by bootstrapping with "--with-arch=native --with-tune=native" on an AMD Threadripper system, that's "znver2". I got a lot of additional testsuite failures especially in the jit testsuite. The log shows a lot of failures of the following form: libgccjit.so: error

Status of gcc 10.0.0 on x86_64-w64-mingw32

First status of gcc 10.0.0 on x86_64-w64-mingw32 for the new year. Test results: https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg00355.html Complete logs: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W?path=%2F10.0.0-rev.279895 signature.asc Description: OpenPGP digital signat

gcc-testres...@gcc.gn.org rejects E-Mails with 552 spam score exceeded threshold

Since today sometimes in the morning I'm not able to send test summaries to gcc-testres...@gcc.gnu.org anymore. gcc-testresu...@gcc.gnu.org: SMTP error from remote server for TEXT command, host: gcc.gnu.org (209.132.180.131) reason: 552 spam score exceeded threshold Does anybody else see Thiss is

svn unavailable since more than an hour

svn: E170013: Unable to connect to a repository at URL 'svn://gcc.gnu.org/svn/gcc/trunk' svn: E210002: Network connection closed unexpectedly signature.asc Description: OpenPGP digital signature

Status 7.4.1 on x86_64-w64-mingw32

Testresults can be found here: https://gcc.gnu.org/ml/gcc-testresults/2019-10/msg01742.html Complete bootstrapo and testsuite logs are here: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W?path=%2F7.4.1-rev.277503 signature.asc Description: OpenPGP digital signature

Successful build of gcc 9.2.0 on x86_64-w64-mingw32

Testresults can be seen here: https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg01595.html Complete logs of the testsuite run are available here: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W signature.asc Description: OpenPGP digital signature

Status of gcc 9.1.1 rev. 274208 on x86_64-w64-mingw32

Testresults can be seen here: https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg00909.html Complete logs of the testsuite run are available here: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W signature.asc Description: OpenPGP digital signature

Re: Status for 9.1.0 (GCC) on x86_64-w64-mingw32

Am 06.05.2019 um 16:36 schrieb Rainer Emrich: > Testsuite results here: > https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00743.html > > Complete bootstrap and testsuite logs here: > https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W > > At the moment ther

Status for 9.1.0 (GCC) on x86_64-w64-mingw32

Testsuite results here: https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00743.html Complete bootstrap and testsuite logs here: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W At the moment there's an issue in the d frontend testsuite. Linking of directory gdc.test "ln -s . gdc.te

Re: What's the status of of D on mingw?

Am 29.04.2019 um 09:59 schrieb Johannes Pfau: > Am 25.04.19 um 20:05 schrieb Rainer Emrich: >> Does anybody knows what's the plans for D on mingw. >> >> AFAIS the frontend builds and is enabled for mingw. But the D runtime is >> disabled for mingw and doesn'

What's the status of of D on mingw?

Does anybody knows what's the plans for D on mingw. AFAIS the frontend builds and is enabled for mingw. But the D runtime is disabled for mingw and doesn't build. A quick dive into the source showed that there is code for mingw target. But it looks like the wrong configuration is selected. Any i

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

Am 16.04.2019 um 17:36 schrieb Jakub Jelinek: > On Tue, Apr 16, 2019 at 03:44:44PM +0200, Jakub Jelinek wrote: >> I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though, >> the *.log files are complete there. >> >> And I have no idea if it was introduced with your change or earlie

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

Am 16.04.2019 um 14:49 schrieb Christophe Lyon: > On Tue, 16 Apr 2019 at 14:34, Rainer Emrich > wrote: >> >> Am 16.04.2019 um 14:10 schrieb Christophe Lyon: >>> On Tue, 16 Apr 2019 at 13:04, Rainer Emrich >>> wrote: >>>> >>>> Am 16.04

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

Am 16.04.2019 um 14:10 schrieb Christophe Lyon: > On Tue, 16 Apr 2019 at 13:04, Rainer Emrich > wrote: >> >> Am 16.04.2019 um 11:59 schrieb Rainer Emrich: >>> Am 15.04.2019 um 20:12 schrieb Rainer Emrich: >>>> Am 15.04.2019 um 17:43 schrieb Rainer Emric

dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

Am 16.04.2019 um 11:59 schrieb Rainer Emrich: > Am 15.04.2019 um 20:12 schrieb Rainer Emrich: >> Am 15.04.2019 um 17:43 schrieb Rainer Emrich: >>> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: >>>> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: >

Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

Am 15.04.2019 um 20:12 schrieb Rainer Emrich: > Am 15.04.2019 um 17:43 schrieb Rainer Emrich: >> Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: >>> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: >>>> There seems to be a generic issue with the tests

Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

Am 15.04.2019 um 17:43 schrieb Rainer Emrich: > Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: >> On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: >>> There seems to be a generic issue with the tests in gcc/testsuite. The >>> log files do not contain the log

Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

Am 15.04.2019 um 17:38 schrieb Jakub Jelinek: > On Mon, Apr 15, 2019 at 05:30:14PM +0200, Rainer Emrich wrote: >> There seems to be a generic issue with the tests in gcc/testsuite. The >> log files do not contain the logs. > > Perhaps contrib/dg-extract-results* misbehaved? &

Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

Am 15.04.2019 um 17:22 schrieb Rainer Emrich: > Today I had the chance to bootstrap and runthe testsuite for trunk on > x86_64-w64-mingw32. Bootstrap is done with all supported languages > enabled including "D". > > Testsuite results can be found here: > https://gc

Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

Today I had the chance to bootstrap and runthe testsuite for trunk on x86_64-w64-mingw32. Bootstrap is done with all supported languages enabled including "D". Testsuite results can be found here: https://gcc.gnu.org/ml/gcc-testresults/2019-04/msg01795.html Complete logs here: https://cloud.emric

Status of all 3 aktiv bracnhes on x86_64-w64-mingw32.

Test results here: 7.4.1 revision 270001 https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg03790.html 8.3.1 revision 270001 https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg03824.html 9.0.1 revision 270001 https://gcc.gnu.org/ml/gcc-testresults/2019-03/msg03904.html Complete logs can be found

Results for 8.3.0 (GCC) testsuite on x86_64-w64-mingw32.

Test results here: https://gcc.gnu.org/ml/gcc-testresults/2019-02/msg03095.html Complete logs can be found here: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W signature.asc Description: OpenPGP digital signature

Status of 9.0.1 20190205 (experimental) [trunk revision 268546] (GCC) testsuite on x86_64-w64-mingw32

Am 17.01.2019 um 17:05 schrieb Rainer Emrich: > I will try to do a bootstrap and testsuite run again on the next weekend. Ok, it took a little longer. I've updated my msys2 installation and the mingw-w64 runtime. The test results are for a resent msys2 installation and mingw-w64 runtim

Status of 9.0.0 20190110 (experimental) [trunk revision 267818] (GCC) testsuite on x86_64-w64-mingw32

There was a bug which prevented building libgfortran. Now after the issue is fixed, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331, I have posted new testresults. https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg01052.html Compared to rev. 265163 we have the following changes: acats tes

testsuite result updates for x86_64-w64-mingw32

There are new testsuite results for x86_64-w64-mingw32, for versions 6.4.1, 7.3.1, 8.2.1 and 9.0.0. https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02309.html https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02310.html https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02312.html https://gcc.gnu

Results for 9.0.0 20180928 (experimental) [trunk revision 264686] (GCC) testsuite on x86_64-w64-mingw32

As promised, results are available here: https://gcc.gnu.org/ml/gcc-testresults/2018-09/msg03636.html Complete build and test logs are available for download here: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W I keep the logs of some older revisions for comparison and added the lo

Test results update for gcc 9.0.0 on x86_64-w64-mingw32

https://gcc.gnu.org/ml/gcc-testresults/2018-09/msg01798.html Full build and testsuite logs here: https://cloud.emrich-ebersheim.de/index.php/s/pootRHorSgdtBkG If it's of any help I may try to do a bootstrap and testsuite run every 2 or 3 weeks. Rainer signature.asc Description: OpenPGP digita

Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32

Am 30.08.2018 um 14:38 schrieb Jonathan Wakely: > Thanks for these logs, they're very helpful. Trunk revision r263976 > fixes a number of the libstdc++ FAILs (compilation errors) and trunk > revision r263977 fixes a load more (linker errors). > > I'm about to fix one more FAIL, a recent regression

Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32

Am 22.08.2018 um 15:57 schrieb Rainer Emrich: > Am 22.08.2018 um 15:24 schrieb NightStrike: >> On Wed, Aug 22, 2018 at 3:29 AM, Rainer Emrich >> wrote: >>> Am 22.08.2018 um 04:03 schrieb NightStrike: >>>> On Tue, Aug 21, 2018 at 2:05 PM, Alexey Pavlov wrot

Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32

Am 22.08.2018 um 15:24 schrieb NightStrike: > On Wed, Aug 22, 2018 at 3:29 AM, Rainer Emrich > wrote: >> Am 22.08.2018 um 04:03 schrieb NightStrike: >>> On Tue, Aug 21, 2018 at 2:05 PM, Alexey Pavlov wrote: >>>> вт, 21 авг. 2018 г. в 20:46, NightStrike : >

Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32

Am 22.08.2018 um 04:03 schrieb NightStrike: > On Tue, Aug 21, 2018 at 2:05 PM, Alexey Pavlov wrote: >> вт, 21 авг. 2018 г. в 20:46, NightStrike : >>> On Tue, Aug 21, 2018 at 9:52 AM, Rainer Emrich >>> wrote: >>>> Bootstrap is done with msys2 on Windows 7. F

Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32

Bootstrap is done with msys2 on Windows 7. For the testsuite results see https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg02651.html signature.asc Description: OpenPGP digital signature

Successful bootsrap of gcc 8.1.0 on x86_64-w64-mingw32

Bootstrap is done with msys2 on Windows 7. For the testsuite results see https://gcc.gnu.org/ml/gcc-testresults/2018-05/msg00583.html signature.asc Description: OpenPGP digital signature

Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues

Am 08.02.2018 um 10:14 schrieb Rainer Emrich: > Am 08.02.2018 um 10:00 schrieb Rainer Emrich: >> Am 06.02.2018 um 19:18 schrieb Jonathan Wakely: >>> On 6 February 2018 at 18:03, Rainer Emrich wrote: >>> >>>> At least 20 of the acats tests catch all memory u

Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues

Am 08.02.2018 um 10:00 schrieb Rainer Emrich: > Am 06.02.2018 um 19:18 schrieb Jonathan Wakely: >> On 6 February 2018 at 18:03, Rainer Emrich wrote: >> >>> At least 20 of the acats tests catch all memory until the host memory is >>> exhausted. >>&

Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues

Am 06.02.2018 um 19:18 schrieb Jonathan Wakely: > On 6 February 2018 at 18:03, Rainer Emrich wrote: > >> At least 20 of the acats tests catch all memory until the host memory is >> exhausted. >> Same holds for the two libstdc++ tests >> 23_containers/unordered_set/r

Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues

Am 08.02.2018 um 00:01 schrieb Eric Botcazou: >> Indeed, this solves most of the new failures. Here is the acats test >> summary: >> === acats Summary === >> # of expected passes 2298 >> # of unexpected failures 22 >> *** FAILURES: c23003b c23003g c23003i c250002 c380004 cd

Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues

Am 06.02.2018 um 22:50 schrieb Eric Botcazou: >> Here's a short status report for trunk on x86_64-w64-mingw32 host. >> >> I know this is only a secondary platform, but there are some serius issues. >> >> Especially the ada part is in a bad shape compared to 7.3.0, see >> https://gcc.gnu.org/ml/gcc-

Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues

Am 06.02.2018 um 22:50 schrieb Eric Botcazou: >> Here's a short status report for trunk on x86_64-w64-mingw32 host. >> >> I know this is only a secondary platform, but there are some serius issues. >> >> Especially the ada part is in a bad shape compared to 7.3.0, see >> https://gcc.gnu.org/ml/gcc-

GCC 8.0.0 status on x86_64-w64-mingw32, some issues

Here's a short status report for trunk on x86_64-w64-mingw32 host. I know this is only a secondary platform, but there are some serius issues. Especially the ada part is in a bad shape compared to 7.3.0, see https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg00439.html and https://gcc.gnu.org/ml/g

ICE in stage 2 during libgcc configure on x86_64-w64-mingw32, rev. 257390

Today I get an ICE during configuration of libgcc in stage 2 on x86_64-w64-mingw32. That's rev. 257390. configure:3688: /opt/devel/SCRATCH/tmp.Sbg1TmFqa7/gcc-8.0.0/gcc-8.0.0/./gcc/xgcc -B/opt/devel/SCRATCH/tmp.Sbg1TmFqa7/gcc-8.0.0/gcc-8.0.0/./gcc/ -L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw

tcl errors during testsuite run

Recently I get a lot of tcl errors during the testsuite run. for example: ERROR: tcl error sourcing /opt/devel/gnu/src/gcc-mingw-w64/gcc-8.0.0/gcc/testsuite/gcc.dg/torture/tls/tls.exp. ERROR: torture-init: torture_without_loops is not empty as expected Does anybody else sees this too? I'm on x

Revision 243196 breaks bootstrap on x86_64-w64-mingw32 using --with-sysroot

Revision 243196 breaks native bootstrap on x86_64-w64-mingw32 using --with-sysroot to point gcc to the mingw-w64 runtime. This used to work since years until then. The bootstrap fails in stage 1 building libgcc due to not finding the runtime libraries. I opened PR 78880. signature.asc Descript

ld fails to build proper executables in several cases on x64_64-w64-mingw32

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I first discovered this by bootstrapping gcc and running the testsuite. I got around 1200 new failures for the same gcc revision using binutils-2.26 compared to using binutils-2.25.1, see https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg02756.html a

Re: Bootstrap broken on trunk, stage 2 gengtype: Internal error: abort in error_at_line, at gengtype.c:112

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 25.03.2015 18:30, schrieb Rainer Emrich: > Am 25.03.2015 17:22, schrieb Kai Tietz: >> Hmm, this seems to be something I haven't noticed until now. It might >> be new ... I see that cp-tree.h is part of gtfiles in config-lang.in

Re: Bootstrap broken on trunk, stage 2 gengtype: Internal error: abort in error_at_line, at gengtype.c:112

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 25.03.2015 17:22, schrieb Kai Tietz: > Hmm, this seems to be something I haven't noticed until now. It might be > new ... I see that cp-tree.h is part of gtfiles in config-lang.in. So the > warning about being not tagged for that language is weir

Re: GCC 5 Status Report (2015-03-20)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Short status for x86_64-w64-mingw32: There seems to be an issue with lto. Running the gcc and g++ tests I get a lot of ICEs I didn't got end of October last year. All like this: lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lt

Bootstrap broken on trunk, stage 2 gengtype: Internal error: abort in error_at_line, at gengtype.c:112

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is on x86_64-w64-mingw32. build/gengtype.exe \ -S ../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc -I gtyp-input.list -w tmp-gtype.state gtyp-input.list:101: file ../../../../../../../opt/devel/gnu/src/gc

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 11/04/2014 10:55 AM, schrieb Paolo Carlini: > .. thanks a lot Jon! (after all this parallel mode is still useful > for something ;) > > Paolo. Sorry for the terse message. I'm under heavy workload at the moment. But AFAIS now everything looks good

libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since the recent changes to the testsuites the folowing make targets in the libstdc++ testsuite directory don't work anymore: check-parallel check-performance check-performance-parallel Any comments? Cheers Rainer -BEGIN PGP SIGNATURE- Vers

Successfull bootstrap 4.9.1 (GCC) native x86_64-w64-mingw32

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 msys2 x86_64-w64-mingw32 setup on windows 7 system with an Intel(R) Xeon(R) E5 1660 v2 cpu, see http://sourceforge.net/p/mingw-w64/mailman/message/32493707/ mingw-w64 is trunk as of 21st of May. testsuite results see https://gcc.gnu.org/ml/gcc-testres

gcc-4.9.0 manual

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Not Found The requested URL /onlinedocs/gcc-4.9.0/libstdc++-api.pdf.gz was not found on this server. Apache Server at gcc.gnu.org Port 80 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://ww

Re: Copyright assignment forms

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Maxim, Am 07.01.2013 08:44, schrieb Maxim Kuvyrkov: > On 4/01/2013, at 12:54 AM, Rainer Emrich wrote: >> I like to contribute some patches to gcc. Therefor im asking kindly for >> the copyright assignment forms and advice. > >

Copyright assignment forms

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I like to contribute some patches to gcc. Therefor im asking kindly for the copyright assignment forms and advice. Cheers Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.

Re: [Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32

Am 19.07.2012 18:12, schrieb redi at gcc dot gnu.org: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 > > --- Comment #5 from Jonathan Wakely 2012-07-19 > 16:12:18 UTC --- > Does changing the definition of POINTER_HASH to use intptr_t instead of long > work? > This works for ggc-common.c. I

bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Affected versions are 4.7.x and 4.8.0. PR 53912 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 shows the failures in stage 2 for gcc-4.8.0. Most are of the form "error: cast from 'void*' to 'long int' loses precision" or similar. AFAIK a switch to

Re: sync top level configure to binutils

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.07.2012 17:30, schrieb Joseph S. Myers: > On Mon, 16 Jul 2012, Rainer Emrich wrote: > >> binutils head top level configure still requires ppl. Now as the changes >> for ppl, isl and cloog are in, I think it's time t

sync top level configure to binutils

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 binutils head top level configure still requires ppl. Now as the changes for ppl, isl and cloog are in, I think it's time to sync to binutils. Any comments? Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG wit

Re: GNU MPC 1.0 release candidate

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Enge inria.fr> writes: > We are pleased to announce the immediate availability of the first release > candidate for GNU MPC 1.0 at > http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz sha1sum > 9acc8a54ba4ecd0ccf172c0d07fcc21822

Re: libstdc++-6.dll doesn't export functions -- gcc-4.6.1 and host=i686-pc-mingw32

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 20.07.2011 17:25, schrieb Jonathan Wakely: > This should go to the libstdc++ list or even better to bugzilla, thanks > > > > On 20/07/2011, Rainer Emrich wrote: > Hi, > > there is a big issue in the gcc-4.6 series. &g

libstdc++-6.dll doesn't export functions -- gcc-4.6.1 and host=i686-pc-mingw32

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, there is a big issue in the gcc-4.6 series. On mingw libstdc++-6.dll exports only: atomic_flag_clear_explicit atomic_flag_test_and_set_explicit The gcc-4.5 series is fine. Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Com

GCC online documentation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 "GCC 4.6.1 Standard C++ Library Manual" and "GCC 4.6.1 Standard C++ Library Reference Manual" missing. http://gcc.gnu.org/onlinedocs/gcc-4.6.1/libstdc++/manual/spine.html Not Found The requested URL /onlinedocs/gcc-4.6.1/libstdc++/manual/spine.html

Re: GCC 4.4.4 Release Candidate available from gcc.gnu.org

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 26.04.2010 20:03, schrieb Jakub Jelinek: > On Mon, Apr 26, 2010 at 07:59:46PM +0200, Rainer Emrich wrote: >> I get an ICE in dbxout.c building a cross compiler from i686-pc-mingw32 to >> i686-w64-mingw32. >> >> i68

Re: GCC 4.4.4 Release Candidate available from gcc.gnu.org

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I get an ICE in dbxout.c building a cross compiler from i686-pc-mingw32 to i686-w64-mingw32. i686-pc-mingw32-gcc -c -g -O2 -D__USE_MINGW_ACCESS -DIN_GCC - -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes - -Wmissing-prototype

suggestion for ppl and cloog-ppl configure enhancement

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 IMHO it would be a godd idea to add the following two configure options to ppl configure: --with-gmp-include=DIR GMP include directory --with-gmp-lib=DIR GMP lib directory On 64-bit Linux systems you have the libraries in lib64 instead of li

strange dependency_libs in libstdc++.la on *-*-mingw32

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 in libstdc++.la: for i686-pc-mingw32: dependency_libs=' - -L/home/rainer/software/build/i686-pc/i686-pc/i686-pc/gcc-4.5.0/gcc-4.5.0/i686-pc-mingw32/libstdc++-v3/src - -L/home/rainer/software/build/i686-pc/i686-pc/i686-pc/gcc-4.5.0/gcc-4.5.0/i686-pc-mi

trunk with shared libstdc++ on x86_64-w64-mingw32 fails to build libgmpxx

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 undefined reference to `std::string::reserve(unsigned long long)' Link of libgmpxx fails: /bin/sh ./libtool --mode=link g++ -O2 -pedantic -m64 -mtune=k8 -o libgmpxx.la - -rpath /home/rainer/tmp/install/lib -no-undefined -Wl,--export-all-symbols -

Re: issue building ppl with trunk

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rainer Emrich schrieb: > Jason Merrill schrieb: >> On 12/01/2009 09:02 AM, Rainer Emrich wrote: >>> C:/MinGW/i686-pc/i686-pc/i686-pc/gcc-4.5.0/mingw/lib/libppl.a(Polyhedron_widenings.o):Polyhedron_w

Re: issue building ppl with trunk

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Merrill schrieb: > On 12/01/2009 09:02 AM, Rainer Emrich wrote: >> C:/MinGW/i686-pc/i686-pc/i686-pc/gcc-4.5.0/mingw/lib/libppl.a(Polyhedron_widenings.o):Polyhedron_widenings.

Re: issue building ppl with trunk

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Merrill schrieb: > On 12/01/2009 09:02 AM, Rainer Emrich wrote: >> C:/MinGW/i686-pc/i686-pc/i686-pc/gcc-4.5.0/mingw/lib/libppl.a(Polyhedron_widenings.o):Polyhedron_widenings.

issue building ppl with trunk

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since beginning of November trunk fails to build ppl properly at least on *-*-mingw32 targets. ppl itself builds, but building cloog-ppl or bootstrapping gcc fails: C:/MinGW/i686-pc/i686-pc/i686-pc/gcc-4.5.0/mingw/lib/libppl.a(Polyhedron_widenings.o):

Re: with rev. 154329 ppl doesn't build anymore

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rainer Emrich schrieb: > Rainer Emrich schrieb: >> This is with gcc-trunk rev. 154329 >> build=x86_64-w64-mingw32 >> ppl-0.10.2 > >> Used to work until yesterday, now: > >> /bin/sh ../libtool --tag=CXX --mod

Re: with rev. 154329 ppl doesn't build anymore

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rainer Emrich schrieb: > This is with gcc-trunk rev. 154329 > build=x86_64-w64-mingw32 > ppl-0.10.2 > > Used to work until yesterday, now: > > /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. > -I../..

with rev. 154329 ppl doesn't build anymore

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is with gcc-trunk rev. 154329 build=x86_64-w64-mingw32 ppl-0.10.2 Used to work until yesterday, now: /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. - -I../../ppl-0.10.2/src -I.. -I.. -I../../ppl-0.10.2/src - -I/mingw/x86_

Re: libtool update?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues schrieb: > Hello Rainer, > > * Rainer Emrich wrote on Tue, Aug 18, 2009 at 04:08:38PM CEST: >> Are there any plans to update libtool? > > If anybody updates libtool before the Autoconf + Automake update, > I

native x86_64-w64-mingw32 fails to boostrap

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 cause are the generated scripts as and collect-ld in the gcc diretory. After building the stage 1 compiler the configuration of libgcc fails. configure:3019: /home/rainer/tmp/build/./gcc/xgcc - -B/home/rainer/tmp/build/./gcc/ - -L/home/rainer/tmp/inst

cross build x86_64-unknown-linux-gnu to i686-pc-cygwin fails in libstdc++-v3

in libstdc++-v3: configure:57398: error: No support for this host/target combination. Used to work for the gcc-4.4.x series. Any ideas? Rainer

Re: building LTO plugin fails for x86_64-unknown -linux-gnu

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Guenther schrieb: > On Sun, Oct 11, 2009 at 6:21 PM, Richard Guenther > wrote: >> On Sun, Oct 11, 2009 at 6:04 PM, Rainer Emrich >> wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>&

building LTO plugin fails for x86_64-unknown -linux-gnu

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 libtool: link: gcc -shared .libs/lto-plugin.o - -L/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/install/lib64 - -lelf - -L/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.5.0/gcc-4.5.0/libiberty/pic - -

libgcj still doesn't build for i686-pc-mingw32

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 gnu/java/security/jce/prng/natVMSecureRandom.cc: In static member function »static jint gnu::java::security::jce::prng::VMSecureRandom::natGenerateSeed(JArray<__java_byte>*, jint, jint)«: gnu/java/security/jce/prng/natVMSecureRandom.cc:29:15: Fehler: e

libtool update?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Are there any plans to update libtool? There is at least one issue which is solved upstream, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40972 Cheers, Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with

Re: cloog static build

e or directory Cheers, Rainer > > Thanks, > Sebastian Pop > -- > AMD - GNU Tools > > > > On Tue, Aug 11, 2009 at 07:10, Rainer Emrich > wrote: > Sebastian Pop schrieb: >>>> On Mon, Aug 10, 2009 at 04:22, Rainer Emrich >>>> wrote: >>&

Re: cloog static build

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Pop schrieb: > On Mon, Aug 10, 2009 at 04:22, Rainer Emrich > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I build my gcc windows versions (*-pc-cygwin, *-pc-mingw32, *-w64-mingw32) >

cloog static build

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I build my gcc windows versions (*-pc-cygwin, *-pc-mingw32, *-w64-mingw32) using static build libraries gmp, mpfr, mpc, ppl and cloog. Configuration and building of gcc is really easy using the --with-host-libstdcxx configure switch. That's not true fo

trunk bootstrap failure in libgfortran for i686-pc-cygwin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 if /bin/sh ./libtool --tag=CC --mode=compile /home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/./gcc/xgcc - -B/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/./gcc/ - -B/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/bin/ - -

Re: default library search path for native *-w64-mingw32 builds is broken somehow

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rainer Emrich schrieb: > Rainer Emrich schrieb: >> Kai Tietz schrieb: >>> 2009/7/20 Kai Tietz : >>>> 2009/7/20 Rainer Emrich : > >>> For the native compiler I get: >>> $ x86_64-w64-mingw32-gcc -prin

default library search path for native *-w64-mingw32 builds is broken somehow

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I try to build native i686-w64-mingw32 and x86_64-w64-mingw32 configurations. I have working cross configurations for both and the on stage builds succeed without issues. But the built compilers have broken default library search pathes. For the x86_

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 - --

--with-host-libstdcxx doesn't work as expected

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At least on cygwin --with-host-libstdcxx doesn't work as expected. ../gcc/configure --with-host-libstdcxx=-lstdc++ gives POSTSTAGE1_LIBS = in the top Makefile. ../gcc/configure --with-boot-libs=-lstdc++ gives POSTSTAGE1_LIBS = -lstdc++ in the top Mak

Failure building trunk on cygwin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's the same as described in the following thread http://gcc.gnu.org/ml/gcc/2009-06/msg00594.html I used binutils-cvs and gcc-trunk as of today and gcc-4.4.1 with binutils-cvs as of today as bootstrap compiler. Rainer -BEGIN PGP SIGNATURE-

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: Call for testers: MPC-0.6 released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Built with disable-shared: - - i686-pc-mingw32 gcc-4.4.0 gmp-4.2.4 mpfr-2.4.1 ok - - i686-pc-cygwin gcc-4.4.0 gmp-4.2.4 mpfr-2.4.1 ok Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enig

Successfull build of gcc-4.4.0 [gcc-4_4-branch revision 145224] for target i686-pc-mingw32 (cross build from i686-pc-cygwin)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.4.0 20090329 (prerelease) [gcc-4_4-branch revision 145224] (GCC) Platform: i686-pc-mingw32 configure flags: - --prefix=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/i686-pc-mingw32/mingw - --with-sysroot=/opt/devel/gnu/cross-gcc/gcc-4.4.

Successfull build of gcc-4.4.0 [gcc-4_4-branch revision 145224] for target x86_64-pc-mingw32 (cross build from i686-pc-cygwin)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.4.0 20090329 (prerelease) [gcc-4_4-branch revision 145224] (GCC) Platform: x86_64-pc-mingw32 configure flags: - --prefix=/opt/devel/gnu/cross-gcc/gcc-4.4.0/mingw/x86_64-pc-mingw32/mingw - --with-sysroot=/opt/devel/gnu/cross-gcc/gcc

Re: Successfull build of gcc-4.4.0 [trunk revision 145008] on i686-pc-cygwin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Botcazou schrieb: >> For the acats tests most of the FAIL cases ar of the form: >> violation of restriction "NO_IMPLICIT_DYNAMIC_CODE" at system.ads:44 > > This very likely means that the compiler is misconfigured. Try to replace > "cygwin32" wi

Re: Successfull build of gcc-4.4.0 [trunk revision 145008] on i686-pc-cygwin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Botcazou schrieb: >> For the acats tests most of the FAIL cases ar of the form: >> violation of restriction "NO_IMPLICIT_DYNAMIC_CODE" at system.ads:44 > > This very likely means that the compiler is misconfigured. Try to replace > "cygwin32" wi

Successfull build of gcc-4.4.0 [trunk revision 145008] on i686-pc-cygwin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.4.0 20090323 (experimental) [trunk revision 145008] (GCC) Platform: i686-pc-cygwin configure flags: --prefix=/opt/devel/gnu/gcc/gcc-4.4.0/i686-pc-cygwin - --with-gmp=/opt/devel/gnu/gcc/gcc-4.4.0/i686-pc-cygwin - --with-mpfr=/opt/dev

Re: trouble building cross compiler: host x86_64-unknown-linux-gnu -> target hppa64-hp-hpux11.00

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kai Ruottu schrieb: > Rainer Emrich wrote: >>> Maybe putting only >>> the bare 'milli.a' there, assuming a '-L/usr/lib/pa20_64' in the >>> native case and a '-L$sysroot/usr/lib/pa20_64' i

  1   2   >