Bug#147241: g++: internal compiler error on s390
Package: g++ Version: 2:2.95.4-14 (or what s390 used, see below) Severity: normal My QuantLib package doesn't build on s390. Buildd shows the following towards the end of the log: make[3]: Entering directory `/build/buildd/quantlib-0.3.0/Examples/Swap' source='swapvaluation.cpp' object='swapvaluation.o' libtool=no \ depfile='.deps/swapvaluation.Po' tmpdepfile='.deps/swapvaluation.TPo' \ depmode=gcc /bin/sh ../../config/depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../ql -I../.. -I../..-O2 -D_REENTRANT -c -o swapvaluation.o `test -f swapvaluation.cpp || echo './'`swapvaluation.cpp g++: Internal compiler error: program cc1plus got fatal signal 9 make[3]: *** [swapvaluation.o] Error 1 make[3]: Leaving directory `/build/buildd/quantlib-0.3.0/Examples/Swap' This is pretty much the most ram-consuming c++ code I have seen, it might simply have been short of further memory resources. Let me know if I can help with further infos. Dirk -- System Information Debian Release: 3.0 Kernel Version: Linux sonny 2.2.20ext3 #1 Sat Dec 8 23:52:06 CST 2001 i586 unknown Versions of the packages g++ depends on: ii cpp2.95.4-14 The GNU C preprocessor. ii g++-2.95 2.95.4-7 The GNU C++ compiler. ii gcc-2.95 2.95.4-7 The GNU C compiler. -- Good judgement comes from experience; experience comes from bad judgement. -- Fred Brooks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#175478: g77-3.2: Internal error encountered compiling octave 2.1
Package: g77-3.2 Version: +N/A; reported 2003-01-05 Severity: important This applies to g77-3.2 on m68k as detailed below in an email I first sent to the m68k build crew, and John Eaton, Octave's author. Let me know if you need more help. John does provide some more detail below, and the buildd logs have more as well. Dirk On Sun, Jan 05, 2003 at 02:49:39PM -0600, John W. Eaton wrote: > On 5-Jan-2003, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: > > | > | >From the build log, and note that I already switch debugging and > optimisation > | off on m68k: > | > | /usr/bin/g77-3.2 -c -fPIC -O0 -g0 zbknu.f -o pic/zbknu.o > | zbknu.f: In subroutine `zbknu': > | zbknu.f:567: Internal compiler error in instantiate_virtual_regs_1, at > function.c:3980 > | Please submit a full bug report, > | with preprocessed source if appropriate. > | See http://www.gnu.org/software/gcc/bugs.html> for instructions. > | > | Please see full details at > | > | > http://buildd.debian.org/fetch.php?&pkg=octave2.1&ver=2.1.43-2&arch=m68k&stamp=1041790412&file=log&as=raw > | > | Let me know if you want me to report this as a g77-3.2 bug. Octave 2.1 now > | requires gcc 3.2. > > I'd say yes, you should report it as a bug unless we can verify that > it doesn't happen with the latest g77/gcc sources. > > I don't see anything particularly special about amos/zbknu.f, but it > is a relatively large subroutine with a lot of local variables. So > given that and the error message above, it looks like we've triggered > a register allocation bug. The file function.c is part of the gcc > backend, I think. It is in the gcc subdirectory of the gcc sources, > not the fortran front end directory. > > jwe -- Prediction is very difficult, especially about the future. -- Niels Bohr
Bug#175478: g77-3.2: Internal error encountered compiling octave 2.1
Here are further details on the "g77-3.2 dies on m68k" bug, as suggested by John and Rick. Dirk Script started on Sun Jan 5 22:35:20 2003 [EMAIL PROTECTED]:~$ cd octave2.1-2.1.43/libcruft/amos/ [EMAIL PROTECTED]:~/octave2.1-2.1.43/libcruft/amos$ gcc-3.2 -v Reading specs from /usr/lib/gcc-lib/m68k-linux/3.2.2/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,pascal,objc --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc m68k-linux Thread model: posix gcc version 3.2.2 20021231 (Debian prerelease) [EMAIL PROTECTED]:~/octave2.1-2.1.43/libcruft/amos$ /usr/bin/g77-3.2 -c -fPIC -O0 -g0 zbknu.f zbknu.f: In subroutine `zbknu': zbknu.f:567: Internal compiler error in instantiate_virtual_regs_1, at function.c:3980 Please submit a full bug report, with preprocessed source if appropriate. See http://www.gnu.org/software/gcc/bugs.html> for instructions. [EMAIL PROTECTED]:~/octave2.1-2.1.43/libcruft/amos$ cat zbknu.f SUBROUTINE ZBKNU(ZR, ZI, FNU, KODE, N, YR, YI, NZ, TOL, ELIM, * ALIM) C***BEGIN PROLOGUE ZBKNU C***REFER TO ZBESI,ZBESK,ZAIRY,ZBESH C C ZBKNU COMPUTES THE K BESSEL FUNCTION IN THE RIGHT HALF Z PLANE. C C***ROUTINES CALLED DGAMLN,I1MACH,D1MACH,ZKSCL,ZSHCH,ZUCHK,XZABS,ZDIV, CXZEXP,XZLOG,ZMLT,XZSQRT C***END PROLOGUE ZBKNU C DOUBLE PRECISION AA, AK, ALIM, ASCLE, A1, A2, BB, BK, BRY, CAZ, * CBI, CBR, CC, CCHI, CCHR, CKI, CKR, COEFI, COEFR, CONEI, CONER, * CRSCR, CSCLR, CSHI, CSHR, CSI, CSR, CSRR, CSSR, CTWOR, * CZEROI, CZEROR, CZI, CZR, DNU, DNU2, DPI, ELIM, ETEST, FC, FHS, * FI, FK, FKS, FMUI, FMUR, FNU, FPI, FR, G1, G2, HPI, PI, PR, PTI, * PTR, P1I, P1R, P2I, P2M, P2R, QI, QR, RAK, RCAZ, RTHPI, RZI, * RZR, R1, S, SMUI, SMUR, SPI, STI, STR, S1I, S1R, S2I, S2R, TM, * TOL, TTH, T1, T2, YI, YR, ZI, ZR, DGAMLN, D1MACH, XZABS, ELM, * CELMR, ZDR, ZDI, AS, ALAS, HELIM, CYR, CYI INTEGER I, IFLAG, INU, K, KFLAG, KK, KMAX, KODE, KODED, N, NZ, * IDUM, I1MACH, J, IC, INUB, NW DIMENSION YR(N), YI(N), CC(8), CSSR(3), CSRR(3), BRY(3), CYR(2), * CYI(2) C COMPLEX Z,Y,A,B,RZ,SMU,FU,FMU,F,FLRZ,CZ,S1,S2,CSH,CCH C COMPLEX CK,P,Q,COEF,P1,P2,CBK,PT,CZERO,CONE,CTWO,ST,EZ,CS,DK C DATA KMAX / 30 / DATA CZEROR,CZEROI,CONER,CONEI,CTWOR,R1/ 1 0.0D0 , 0.0D0 , 1.0D0 , 0.0D0 , 2.0D0 , 2.0D0 / DATA DPI, RTHPI, SPI ,HPI, FPI, TTH / 1 3.14159265358979324D0, 1.25331413731550025D0, 2 1.90985931710274403D0, 1.57079632679489662D0, 3 1.8976331517738D0, 6.6D-01/ DATA CC(1), CC(2), CC(3), CC(4), CC(5), CC(6), CC(7), CC(8)/ 1 5.77215664901532861D-01,-4.20026350340952355D-02, 2-4.2197734443367D-02, 7.21894324666309954D-03, 3-2.15241674114950973D-04,-2.01348547807882387D-05, 4 1.13302723198169588D-06, 6.11609510448141582D-09/ C CAZ = XZABS(ZR,ZI) CSCLR = 1.0D0/TOL CRSCR = TOL CSSR(1) = CSCLR CSSR(2) = 1.0D0 CSSR(3) = CRSCR CSRR(1) = CRSCR CSRR(2) = 1.0D0 CSRR(3) = CSCLR BRY(1) = 1.0D+3*D1MACH(1)/TOL BRY(2) = 1.0D0/BRY(1) BRY(3) = D1MACH(2) NZ = 0 IFLAG = 0 KODED = KODE RCAZ = 1.0D0/CAZ STR = ZR*RCAZ STI = -ZI*RCAZ RZR = (STR+STR)*RCAZ RZI = (STI+STI)*RCAZ INU = INT(SNGL(FNU+0.5D0)) DNU = FNU - DBLE(FLOAT(INU)) IF (DABS(DNU).EQ.0.5D0) GO TO 110 DNU2 = 0.0D0 IF (DABS(DNU).GT.TOL) DNU2 = DNU*DNU IF (CAZ.GT.R1) GO TO 110 C--- C SERIES FOR CABS(Z).LE.R1 C--- FC = 1.0D0 CALL XZLOG(RZR, RZI, SMUR, SMUI, IDUM) FMUR = SMUR*DNU FMUI = SMUI*DNU CALL ZSHCH(FMUR, FMUI, CSHR, CSHI, CCHR, CCHI) IF (DNU.EQ.0.0D0) GO TO 10 FC = DNU*DPI FC = FC/DSIN(FC) SMUR = CSHR/DNU SMUI = CSHI/DNU 10 CONTINUE A2 = 1.0D0 + DNU C--- C GAM(1-Z)*GAM(1+Z)=PI*Z/SIN(PI*Z), T1=1/GAM(1-DNU), T2=1/GAM(1+DNU) C--- T2 = DEXP(-DGAMLN(A2,IDUM)) T1 = 1.0D0/(T2*FC) IF (DABS(DNU).GT.0.1D0) GO TO 40 C--- C SERIES FOR F0 TO RESOLVE INDETERMINACY FOR SMALL ABS(DNU) C--- AK = 1.0D0 S = CC(1) DO 20 K=2,8 AK = AK*DNU2 TM = CC(K)*AK S = S + TM IF (DABS(TM).LT.TOL) GO TO 30 20 CONTINUE 30
Bug#175478: g77-3.2: Internal error encountered compiling octave 2.1
> Dirk Eddelbuettel writes: > > > > Package: g77-3.2 > > Version: +N/A; reported 2003-01-05 > > Severity: important > > > > This applies to g77-3.2 on m68k as detailed below in an email I first sent > > to the m68k build crew, and John Eaton, Octave's author. > > > > Let me know if you need more help. John does provide some more detail below, > > and the buildd logs have more as well. > > please could you check, if the file changed from the last time you This particular Fortran file has not changed in years (decades?) but ... > built with a different (which?) compiler version? ... have a look at the buildd.debian.org logs. There are two issues for m68k -- I recently switched back from f2c to g77; m68k was the only one using f2c This switch was probably made around November. -- Octave itself changed some C++ structures and now requires g++ 3.2 or better. This only affected the releases of the last few days (2.1.42 onwards). So looking at http://buildd.debian.org/build.php?arch=m68k&pkg=octave2.1 you see that 2.1.40 built fine on m68k using the default (2.95) g++. Does that help? Tschuess, Dirk -- According to the latest figures, 43% of all signatures are totally worthless.
g77-3.2 on m68k blows up on Fortran file in Octave 2.1
Folks, Did we already report this one upstream? Note the -O0 -g0, not sure what else I can try, other than to shoot all the four remaining linux-on-m68k users left on the planet. Just kidding. Dirk Details taken from http://buildd.debian.org/fetch.php?&pkg=octave2.1&ver=2.1.45-1&arch=m68k&stamp=1045717125&file=log&as=raw : /usr/bin/g77-3.2 -c -fPIC -O0 -g0 zbknu.f -o pic/zbknu.o zbknu.f: In subroutine `zbknu': zbknu.f:567: Internal compiler error in instantiate_virtual_regs_1, at function.c:3980 Please submit a full bug report, with preprocessed source if appropriate. See http://www.gnu.org/software/gcc/bugs.html> for instructions. make[4]: *** [pic/zbknu.o] Error 1 make[4]: Leaving directory `/build/buildd/octave2.1-2.1.45/libcruft/amos' make[3]: *** [amos] Error 2 make[3]: Leaving directory `/build/buildd/octave2.1-2.1.45/libcruft' make[2]: *** [libcruft] Error 2 make[2]: Leaving directory `/build/buildd/octave2.1-2.1.45' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/octave2.1-2.1.45' make: *** [make-stamp] Error 2 ** Build finished at 20030219-2055 FAILED [dpkg-buildpackage died] -- Prediction is very difficult, especially about the future. -- Niels Bohr
Re: g77-3.2 on m68k blows up on Fortran file in Octave 2.1
> Dirk Eddelbuettel writes: > > > > Folks, > > > > Did we already report this one upstream? > > see #175478, submitted by someone called Edd ... ;-) Ah, yes, amnesia hitting me squarely on the forehead. Thanks for the cluebat, > > Note the -O0 -g0, not sure what > > else I can try, other than to shoot all the four remaining linux-on-m68k > > users left on the planet. Just kidding. > > you forgot to add the five autobuilders :) > > currently building 3.3 for m68k-linux on crest. Roman Zippel posted > test results one week ago, so it should build. when it's finished, > please try building the gcc-snapshot package. Err, you mean, try building octave2.1 using the gcc-snapshot? The offending file is small, could you guys try to fetch it and try just that? No need to blow three, four hours of the not exactly abundant m68k autobuilder cycles on all the rest of octave. Dirk -- According to the latest figures, 43% of all signatures are totally worthless.
Bug#175478: Follow-up to bug report
As per follow-up email, the bug still haunts us ... /usr/bin/g77-3.2 -c -fPIC -O0 -g0 zbknu.f -o pic/zbknu.o zbknu.f: In subroutine `zbknu': zbknu.f:567: Internal compiler error in instantiate_virtual_regs_1, at function.c:3980 Please submit a full bug report, with preprocessed source if appropriate. See http://www.gnu.org/software/gcc/bugs.html> for instructions. make[4]: *** [pic/zbknu.o] Error 1 make[4]: Leaving directory `/build/buildd/octave2.1-2.1.45/libcruft/amos' make[3]: *** [amos] Error 2 make[3]: Leaving directory `/build/buildd/octave2.1-2.1.45/libcruft' make[2]: *** [libcruft] Error 2 make[2]: Leaving directory `/build/buildd/octave2.1-2.1.45' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/octave2.1-2.1.45' make: *** [make-stamp] Error 2 ** Build finished at 20030219-2055 FAILED [dpkg-buildpackage died] -- ... and I'm attaching the fortran file in question to this email. Dirk zbknu.f Description: Binary data -- Prediction is very difficult, especially about the future. -- Niels Bohr
Bug#448149: quantlib-swig - FTBFS: g++: Internal error: Killed (program cc1plus)
On 26 October 2007 at 17:44, Martin Michlmayr wrote: | * Bastian Blank <[EMAIL PROTECTED]> [2007-10-26 17:07]: | > Nack. quantlib-swig feeds insane large input and fails. | | Does that s390 buildd only have 256 MB of RAM or so? Good point. I've seen the g++ process approach one gb on my x86 when building this. Also note that I have no sway in upstream's choice of one large file. Also of note is that powerpc fails with ICE whereas it managed to build the previous Debian upload 0.8-2 mips and mipsel fail with relocation errors, I would need help with that from toolchain exports. arm fails as it times out after 500 minutes. The others (alpha, amd63, hppa, ia64, i386, sparc) all succeed. Dirk -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#448149: quantlib-swig - FTBFS: g++: Internal error: Killed (program cc1plus)
On 26 October 2007 at 20:02, Martin Michlmayr wrote: | * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2007-10-26 11:30]: | > Also of note is that powerpc fails with ICE whereas it managed to build the | > previous Debian upload 0.8-2 | | voltaire only has 320 MB RAM, so I guess it's simply running out of | memory too. Ack. I am already switching to -O0 -g0 for a few arches, and I now added s390. Do you recommend I do the same for powerpc? | > mips and mipsel fail with relocation errors, I would need help with | > that from toolchain exports. | | I thought this error shouldn't happen anymore. CCing Thiemo. Thanks!! Dirk -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#448149: quantlib-swig - FTBFS: g++: Internal error: Killed (program cc1plus)
Using -O0 and -g0 avoided the ICE on s390 as seen at http://buildd.debian.org/build.php?&pkg=quantlib-swig&ver=0.8.0-4&arch=s390&file=log I'll leave it to the g++ maintainers to see if they want to close this, or look at it further. It may really just be a resource exhaustion on the host machine. Dirk -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#448149: quantlib-swig - FTBFS: g++: Internal error: Killed (program cc1plus)
On 27 October 2007 at 15:55, Matthias Klose wrote: | Dirk Eddelbuettel writes: | > | > On 26 October 2007 at 20:02, Martin Michlmayr wrote: | > | * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2007-10-26 11:30]: | > | > Also of note is that powerpc fails with ICE whereas it managed to build the | > | > previous Debian upload 0.8-2 | > | | > | voltaire only has 320 MB RAM, so I guess it's simply running out of | > | memory too. | > | > Ack. I am already switching to -O0 -g0 for a few arches, and I now added | > s390. Do you recommend I do the same for powerpc? | | the correct fix is to make the code chunks which swig generates, smaller. I'll let upstream know (CC'ed, hi Luigi :). I don't have the swig-foo to do that myself. Anybody inside Debian I could bug for help? Dirk -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#448149: quantlib-swig - FTBFS: g++: Internal error: Killed (program cc1plus)
On 27 October 2007 at 17:12, Luigi Ballabio wrote: | | On Oct 27, 2007, at 4:36 PM, Dirk Eddelbuettel wrote: | > | | > | the correct fix is to make the code chunks which swig generates, | > smaller. | > | > I'll let upstream know (CC'ed, hi Luigi :). | | Hi, Dirk. | There's someone working on that. I don't have an estimate for when | it's done, though. It will be for next release anyway Excellent news. | ---I don't think we'll backport the thing. No worries. We have the 0.8.* release mostly under control, and this sounds like the right thing going forward towards 1.0. Cheers, Dirk -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
Package: g++-4.1 Version: 4.1.1-5 Severity: important The g++ version that recently entered testing exhibits the same problem I had been reported to the hppa maintainers -- and which Randolph report upstream at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28620 . I understand that it is fixed in unstable, but as the toolchain is frozen (or being frozen) I just want to make sure everyone is on the same page: the current 'testing' version of g++ will not cut it for release. The code below is from the current sources my rquantlib package which I intend to send to unstable later today. It does build on unstable but fails on testing showing that testing isn't quite there at the moment. Hope this helps, Dirk * Installing *source* package 'RQuantLib' ... checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking whether we are using the GNU C++ compiler... (cached) yes checking whether g++ accepts -g... (cached) yes checking for quantlib-config... yes Building libRcpp.a in RcppSrc... g++ -I/usr/share/R/include -I/usr/share/R/include -DUSING_QUANTLIB -I/usr/include -fpic -g -O2 -c Rcpp.cpp -o Rcpp.o ar crs libRcpp.a Rcpp.o checking for Boost development files... yes checking Boost version... yes configure: creating ./config.status config.status: creating src/Makevars Completed configuration and ready to build. ** libs g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB -I/usr/include -I../RcppSrc -fpic -g -O2 -c barrier_binary.cpp -o barrier_binary.o g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB -I/usr/include -I../RcppSrc -fpic -g -O2 -c bermudan.cpp -o bermudan.o g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB -I/usr/include -I../RcppSrc -fpic -g -O2 -c curves.cpp -o curves.o g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB -I/usr/include -I../RcppSrc -fpic -g -O2 -c discount.cpp -o discount.o g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB -I/usr/include -I../RcppSrc -fpic -g -O2 -c implieds.cpp -o implieds.o g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB -I/usr/include -I../RcppSrc -fpic -g -O2 -c utils.cpp -o utils.o g++ -I/usr/share/R/include -I/usr/share/R/include-g -O2 -DUSING_QUANTLIB -I/usr/include -I../RcppSrc -fpic -g -O2 -c vanilla.cpp -o vanilla.o g++ -shared -o RQuantLib.so barrier_binary.o bermudan.o curves.o discount.o implieds.o utils.o vanilla.o -L../RcppSrc -lRcpp -L/usr/lib -lQuantLib-0.3.13 -L/usr/lib/R/lib -lR bermudan.o:(.data+0x0): multiple definition of `_ZN8QuantLib8McPricerIT_T0_E10minSample_E' barrier_binary.o:(.data+0x0): first defined here bermudan.o:(.data+0x4): multiple definition of `_ZN8QuantLib12McSimulationIT_T0_E10minSample_E' barrier_binary.o:(.data+0x4): first defined here curves.o:(.data+0x0): multiple definition of `_ZN8QuantLib8McPricerIT_T0_E10minSample_E' barrier_binary.o:(.data+0x0): first defined here curves.o:(.data+0x4): multiple definition of `_ZN8QuantLib12McSimulationIT_T0_E10minSample_E' barrier_binary.o:(.data+0x4): first defined here discount.o:(.data+0x0): multiple definition of `_ZN8QuantLib8McPricerIT_T0_E10minSample_E' barrier_binary.o:(.data+0x0): first defined here discount.o:(.data+0x4): multiple definition of `_ZN8QuantLib12McSimulationIT_T0_E10minSample_E' barrier_binary.o:(.data+0x4): first defined here implieds.o:(.data+0x0): multiple definition of `_ZN8QuantLib8McPricerIT_T0_E10minSample_E' barrier_binary.o:(.data+0x0): first defined here implieds.o:(.data+0x4): multiple definition of `_ZN8QuantLib12McSimulationIT_T0_E10minSample_E' barrier_binary.o:(.data+0x4): first defined here utils.o:(.data+0x0): multiple definition of `_ZN8QuantLib8McPricerIT_T0_E10minSample_E' barrier_binary.o:(.data+0x0): first defined here utils.o:(.data+0x4): multiple definition of `_ZN8QuantLib12McSimulationIT_T0_E10minSample_E' barrier_binary.o:(.data+0x4): first defined here vanilla.o:(.data+0x0): multiple definition of `_ZN8QuantLib8McPricerIT_T0_E10minSample_E' barrier_binary.o:(.data+0x0): first defined here vanilla.o:(.data+0x4): multiple definition of `_ZN8QuantLib12McSimulationIT_T0_E10minSample_E' barrier_binary.o:(.data+0x4): first defined here ../RcppSrc/libRcpp.a(Rcpp.o):(.data+0x0): multiple definition of `_ZN8QuantLib8McPricerIT_T0_E10minSample_E' barrier_binary.o:(.data+0x0): first defined here ../RcppSrc/libRcpp.a(Rcpp.o):(.data+0x4): multiple definition of `_ZN8QuantLib12McSimulationIT_T0_E10minSample_E' barrier_binary.o:(.data+0x4): first defined here collect2: ld returned 1 exit status
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
(With the 14hr mail outage on master.debian.org, this is the first message I am seeing in this thread after I filed my bug report. So forgive me if I say something redundant...). On 17 August 2006 at 12:00, Martin Michlmayr wrote: | * John Schmidt <[EMAIL PROTECTED]> [2006-08-16 18:32]: | > I have a big c++ application that creates quite a few shared libraries and it | > takes on the order of 10 minutes for the creation of one of my libraries (not | > all of them) with g++-4.1, whereas with g++-4.0, the same library only takes | > at most 30 seconds. This is with a debug build and no optimization. | | Do you have a small testcase? This is comparable to my experience with RQuantLib. My last build took 17 minutes wall time in the (unoptimised) pbuilder, so call it a minute for setting up and closing the pbuilder. Now, RQuantLib is just five small C++ files ... but it links against the huge-ish QuantLib. This used to take maybe minutes, but right now takes forever. The link step alone is eight minutes (!!) on an aging dual AMD 1.8 MHz --- but with ample 2 GB of RAM. So it's not that I starve g++ and ld of memory ... Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
On 18 August 2006 at 00:58, Martin Michlmayr wrote: | * John Schmidt <[EMAIL PROTECTED]> [2006-08-17 13:46]: | > Is there a way for me to instrument my code/system, etc to indicate | > where the big time sink is? | | I'm not sure but I'll try to investigate. I didn't make that as clear as I wanted to in my last email -- but you could just compare the package build of RQuantLib on stable (where it should be few minutes) to testing (where it will be at least twice that). Not that much code in Quantlib or RQuantLib and you should get a quick feeling for how much g++ changed. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
On 19 August 2006 at 15:03, Matthias Klose wrote: | Dirk Eddelbuettel writes: | > | > On 18 August 2006 at 00:58, Martin Michlmayr wrote: | > | * John Schmidt <[EMAIL PROTECTED]> [2006-08-17 13:46]: | > | > Is there a way for me to instrument my code/system, etc to indicate | > | > where the big time sink is? | > | | > | I'm not sure but I'll try to investigate. | > | > I didn't make that as clear as I wanted to in my last email -- but you could | > just compare the package build of RQuantLib on stable (where it should be few | > minutes) to testing (where it will be at least twice that). Not that much | > code in Quantlib or RQuantLib and you should get a quick feeling for how much | > g++ changed. | | please identify the files, which take longer to build; it's known that | 4.x is slower in some cases. As I wrote in previous messages, the worst offender is the linking stage which takes several times as long as usual. On my dual Athlon (1.5 Ghz each, 2gb ram total) the linking of the rather small rquantlib.so takes over eight minutes which is totally ridiculous. It used to be one, at the most two, minutes. Thanks, Dirk (on vacation) -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
On 22 August 2006 at 07:29, Dirk Eddelbuettel wrote: | | On 19 August 2006 at 15:03, Matthias Klose wrote: | | Dirk Eddelbuettel writes: | | > | | > On 18 August 2006 at 00:58, Martin Michlmayr wrote: | | > | * John Schmidt <[EMAIL PROTECTED]> [2006-08-17 13:46]: | | > | > Is there a way for me to instrument my code/system, etc to indicate | | > | > where the big time sink is? | | > | | | > | I'm not sure but I'll try to investigate. | | > | | > I didn't make that as clear as I wanted to in my last email -- but you could | | > just compare the package build of RQuantLib on stable (where it should be few | | > minutes) to testing (where it will be at least twice that). Not that much | | > code in Quantlib or RQuantLib and you should get a quick feeling for how much | | > g++ changed. | | | | please identify the files, which take longer to build; it's known that | | 4.x is slower in some cases. | | | As I wrote in previous messages, the worst offender is the linking stage | which takes several times as long as usual. On my dual Athlon (1.5 Ghz each, | 2gb ram total) the linking of the rather small rquantlib.so takes over eight | minutes which is totally ridiculous. It used to be one, at the most two, | minutes. I never heard any follow-up. Is there any? While it is nice that 4.1.1-11 is now in testing it is not so nice that 4.1.1-11 exhibits the slow builds John and I have been experiencing -- on different code bases, no less. Is that the status quo or can we expect improvements at some point? Thanks, Dirk | | Thanks, | | Dirk (on vacation) | | -- | Hell, there are no rules here - we're trying to accomplish something. | -- Thomas A. Edison -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
On 3 September 2006 at 14:40, Martin Michlmayr wrote: | * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-09-03 06:47]: | > I never heard any follow-up. Is there any? While it is nice that 4.1.1-11 is | > now in testing it is not so nice that 4.1.1-11 exhibits the slow builds John | > and I have been experiencing -- on different code bases, no less. | | I briefly looked at it, didn't see anything obvious and then ran out | of time. I also don't really have the right expertise for this. | | > Is that the status quo or can we expect improvements at some point? | | For 4.1 probably not; it'd be possible for 4.2 but you'd need to come | up with some kind of (small) testcase. As John and I stated, 'small' is hard to define in the context of large-ish C++ applications / libraries. The C++ source of RQuantLib are small (around 60kb) and I could probably trim that further for an example ... but it would still need QuantLib itself which is rather larger. Would that be helpful or not? I have no clue what parts of QuantLib itself cause the compiler and linker to go gaga. You'd need a real C++ export to figure that out. I am CCing one -- who is also a key developer of QuantLib. Hth, Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
On 3 September 2006 at 16:27, Martin Michlmayr wrote: | * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-09-03 09:16]: | > | up with some kind of (small) testcase. | > | > As John and I stated, 'small' is hard to define in the context of large-ish | > C++ applications / libraries. The C++ source of RQuantLib are small (around | > 60kb) and I could probably trim that further for an example ... but it would | > still need QuantLib itself which is rather larger. Would that be helpful or | > not? | | s/small/self-contained/ then. Do you have some example where the | linking process of some c++ files takes ages, without linking them | against some external library? That would make things much easier | imho. I agree. But as I am unsure excactly what part in the area of templates and static initialization (or some variant thereof) causes this, I have to defer to Luigi. But yes, a smaller self-contained testcase would obviously help our case. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
One interesting little illustration is provided by the CRAN timing summaries. The master site of CRAN (the CTAN / CPAN equivalent for R) is hosted on Debian testing. Compile/build/test times are shown at http://cran.r-project.org/src/contrib/checkTimings.html and RQuantLib is the 2nd most time-consuming packages -- right after RGtk2 which happens to be around thirty (!!) times larger when we compare the orig.tar.gz [ flawed, as we know that RGtk2 also has a lot of documentation ] but still. [EMAIL PROTECTED]:/var/local/cache/pbuilder/result> ls -lh rgtk2_2.8.5.orig.tar.gz \ rquantlib_0.2.4.orig.tar.gz -rw-r--r-- 1 edd edd 1.8M Jun 22 19:39 rgtk2_2.8.5.orig.tar.gz -rw-r--r-- 1 edd edd 64K Aug 14 22:39 rquantlib_0.2.4.orig.tar.gz Still compile/link with g++-4.1 sucks really big time for certain projects. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
On 5 September 2006 at 18:41, Luigi Ballabio wrote: | | On Sep 3, 2006, at 5:57 PM, Dirk Eddelbuettel wrote: | > | s/small/self-contained/ then. Do you have some example where the | > | linking process of some c++ files takes ages, without linking them | > | against some external library? That would make things much easier | > | imho. | > | > I agree. But as I am unsure excactly what part in the area of | > templates and | > static initialization (or some variant thereof) causes this, I have to | > defer | > to Luigi. | > | > But yes, a smaller self-contained testcase would obviously help our | > case. | | Dirk, | I'm a bit out of context here. Are we talking about link times, or | about the link error in Etch? Link times. [ The 'link error in Etch' was something we first saw on hppa, and later noticed as a general problem -- but which is fixed in recent g++ versions. ] Are you aware of anything we could turn in as a self-contained example? Without an example, the g++ authors will have a hard time tuning this. As I say it, build time for QL are way up relative to g++ 4.0; linking alone for the small-ish RQuantLib is now over 8 minutes. John seconded this observation based on a different code base he is working on. Do you still have a Debian box you use for development? Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
On 26 September 2006 at 11:34, John Schmidt wrote: | To follow-up on my experiences with g++-4.1 code and extremely slow link | times, I did a chroot and pulled in old versions of g++-4.1 and binutils from | snapshot.debian.net to build my big c++ application. | | Here is a table with the following results: | | Dateg++-4.1 binutils Status | 4-30-06 4.1.0-1+b1 2.16.1cvs20060413-1 fast link | 5-30-06 4.1.0-4 2.16.1cvs20060413-1 fast link | 5-30-06 4.1.0-4 2.17-1 slow link | 6-30-06 4.1.1-5 2.16.1cvs20060413-1 fast link | 6-30-06 4.1.1-5 2.17-1 slow link | | The date column is for the day used to pull in g++-4.1 and binutils with the | the version shown in the other columns. The fast link represents something | on the order of several seconds, whereas slow link represents on the order of | 15 minutes. | | It is clear that the problem with slow linking comes from binutils version | 2.17-1 (and greater) and not g++-4.1. There is a current binutils bug | report -- bug 3111 that seems to correlate with my experiences and Dirk's. | | I will follow-up with binutils folks on this problem. | | Dirk -- could you try and see if downgrading binutils to something less than | 2.17-1 restores saner link times? Nice work, and I can surely try this. Now, I don't see a recent non-2.17 version of binutils anywhere in .deb form for i386. Before I go off an rebuild, could you place your version somewhere where I can fetch it from? Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
On 26 September 2006 at 20:10, Martin Michlmayr wrote: | * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-09-26 13:07]: | > Nice work, and I can surely try this. Now, I don't see a recent non-2.17 | > version of binutils anywhere in .deb form for i386. Before I go off an | > rebuild, could you place your version somewhere where I can fetch it from? | | http://snapshot.debian.net/ Yes, but it only has sources -- or do I misread the webpage? [ Checks himself. ] Yes I do. Never mind. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
Hi Martin, On 19 April 2007 at 16:51, Martin Michlmayr wrote: | * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-08-15 17:29]: | > Package: g++-4.1 | > Version: 4.1.1-5 | > | > I understand that it is fixed in unstable, but as the toolchain is | > frozen (or being frozen) I just want to make sure everyone is on the | > same page: the current 'testing' version of g++ will not cut it for | > release. | | This bug was fixed in 4.1.1-9 afaik, and etch shipped with 4.1.1-21. No beans. I was just discussing with Kurt Hornik, one of the R Core developers, and CRAN maintainers, why building of my RQuantLib / r-cran-quantlib takes so long. The issue is not solved as far as I can tell. The linking of complicated / templated C++ code can still take aaggee --- around 20 minutes on recent hardware, around 28 minutes on my somewhat dated by largeish memory server. I wouldn't close the bug. But I have too little time for follow-ups to reopen it, I simply CC the BTS here. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing
On 19 April 2007 at 20:12, Martin Michlmayr wrote: | Dirk, | | * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2007-04-19 20:44]: | > No beans. I was just discussing with Kurt Hornik, one of the R Core | > developers, and CRAN maintainers, why building of my RQuantLib / | > r-cran-quantlib takes so long. The issue is not solved as far as I can | > tell. The linking of complicated / templated C++ code can still take | > aaggee --- around 20 minutes on recent hardware, around 28 | > minutes on my somewhat dated by largeish memory server. | | I was talking about the original bug you reported - the multiple | definitions on hppa. My bad. | As to the slow linking, I'm afraid there's little that can be done | with a reasonable small testcase. (without ?) I will get back to you if I can come up with one but I am unsure if I can... Thanks, Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
arm: ICE building quantlib
I put up a new revision quantlib_0.8.1-2 which builds better on some arches (mips, mipsel) but dies on arm with make[4]: Entering directory `/build/buildd/quantlib-0.8.1/ql' /bin/sh ../libtool --tag=CXX --mode=link g++ -O0 -g0 -D_REENTRANT -fpermissive -o libQuantLib.la -rpath /build/buildd/quantlib-0.8.1/debian/libquantlib-0.8.1/usr/lib -release 0.8.1 currency.lo discretizedasset.lo errors.lo exchangerate.lo exercise.lo index.lo interestrate.lo money.lo prices.lo stochasticprocess.lo swaptionvolstructure.lo timegrid.lo voltermstructure.lo cashflows/libCashFlows.la currencies/libCurrencies.la indexes/libIndexes.la instruments/libInstruments.la legacy/libLegacy.la math/libMath.la methods/libMethods.la models/libModels.la pricingengines/libPricingEngines.la processes/libProcesses.la quotes/libQuotes.la termstructures/libTermStructures.la time/libTime.la utilities/libUtilities.la g++ -shared -nostdlib /usr/lib/gcc/arm-linux-gnu/4.1.3/../../../crti.o /usr/lib/gcc/arm-linux-gnu/4.1.3/crtbeginS.o .libs/currency.o .libs/discretizedasset.o .libs/errors.o .libs/exchangerate.o .libs/exercise.o .libs/index.o .libs/interestrate.o .libs/money.o .libs/prices.o .libs/stochasticprocess.o .libs/swaptionvolstructure.o .libs/timegrid.o .libs/voltermstructure.o -Wl,--whole-archive cashflows/.libs/libCashFlows.a currencies/.libs/libCurrencies.a indexes/.libs/libIndexes.a instruments/.libs/libInstruments.a legacy/.libs/libLegacy.a math/.libs/libMath.a methods/.libs/libMethods.a models/.libs/libModels.a pricingengines/.libs/libPricingEngines.a processes/.libs/libProcesses.a quotes/.libs/libQuotes.a termstructures/.libs/libTermStructures.a time/.libs/libTime.a utilities/.libs/libUtilities.a -Wl,--no-whole-archive -L/usr/lib/gcc/arm-linux-gnu/4.1.3 -L/usr/lib/gcc/arm-linux-gnu/4.1.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/arm-linux-gnu/4.1.3/crtendS.o /usr/lib/gcc/arm-linux-gnu/4.1.3/../../../crtn.o -Wl,-soname -Wl,libQuantLib-0.8.1.so -o .libs/libQuantLib-0.8.1.so -L/usr/lib/gcc/arm-linux-gnu/4.1.3 -L/usr/lib/gcc/arm-linux-gnu/4.1.3/../../.. -lstdc++ -lm -lc -lgcc_s collect2: ld terminated with signal 11 [Segmentation fault] Shouldn't that have been g++ 4.2 anyway? Full log at http://buildd.debian.org/fetch.cgi?&pkg=quantlib&ver=0.8.1-2&arch=arm&stamp=1184754190&file=log Help would be appreciated. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison
Re: arm: ICE building quantlib
On Wed, Jul 18, 2007 at 04:22:03PM +0200, Matthias Klose wrote: > Dirk Eddelbuettel writes: > > Shouldn't that have been g++ 4.2 anyway? > > why? I thought it was the default in unstable. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: arm: ICE building quantlib
On 18 July 2007 at 18:24, Aurelien Jarno wrote: | Dirk Eddelbuettel a écrit : | > I put up a new revision quantlib_0.8.1-2 which builds better on some arches | > (mips, mipsel) but dies on arm with | > | > make[4]: Entering directory `/build/buildd/quantlib-0.8.1/ql' | > /bin/sh ../libtool --tag=CXX --mode=link g++ -O0 -g0 -D_REENTRANT -fpermissive -o libQuantLib.la -rpath /build/buildd/quantlib-0.8.1/debian/libquantlib-0.8.1/usr/lib -release 0.8.1 currency.lo discretizedasset.lo errors.lo exchangerate.lo exercise.lo index.lo interestrate.lo money.lo prices.lo stochasticprocess.lo swaptionvolstructure.lo timegrid.lo voltermstructure.lo cashflows/libCashFlows.la currencies/libCurrencies.la indexes/libIndexes.la instruments/libInstruments.la legacy/libLegacy.la math/libMath.la methods/libMethods.la models/libModels.la pricingengines/libPricingEngines.la processes/libProcesses.la quotes/libQuotes.la termstructures/libTermStructures.la time/libTime.la utilities/libUtilities.la | > g++ -shared -nostdlib /usr/lib/gcc/arm-linux-gnu/4.1.3/../../../crti.o /usr/lib/gcc/arm-linux-gnu/4.1.3/crtbeginS.o .libs/currency.o .libs/discretizedasset.o .libs/errors.o .libs/exchangerate.o .libs/exercise.o .libs/index.o .libs/interestrate.o .libs/money.o .libs/prices.o .libs/stochasticprocess.o .libs/swaptionvolstructure.o .libs/timegrid.o .libs/voltermstructure.o -Wl,--whole-archive cashflows/.libs/libCashFlows.a currencies/.libs/libCurrencies.a indexes/.libs/libIndexes.a instruments/.libs/libInstruments.a legacy/.libs/libLegacy.a math/.libs/libMath.a methods/.libs/libMethods.a models/.libs/libModels.a pricingengines/.libs/libPricingEngines.a processes/.libs/libProcesses.a quotes/.libs/libQuotes.a termstructures/.libs/libTermStructures.a time/.libs/libTime.a utilities/.libs/libUtilities.a -Wl,--no-whole-archive -L/usr/lib/gcc/arm-linux-gnu/4.1.3 -L/usr/lib/gcc/arm-linux-gnu/4.1.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/arm-linux-gnu/4.1.3/crtendS.o /usr/lib/g | cc/arm-linux-gnu/4.1.3/../../../crtn.o -Wl,-soname -Wl,libQuantLib-0.8.1.so -o .libs/libQuantLib-0.8.1.so -L/usr/lib/gcc/arm-linux-gnu/4.1.3 -L/usr/lib/gcc/arm-linux-gnu/4.1.3/../../.. -lstdc++ -lm -lc -lgcc_s | > collect2: ld terminated with signal 11 [Segmentation fault] | > | > Shouldn't that have been g++ 4.2 anyway? | > | > Full log at | > http://buildd.debian.org/fetch.cgi?&pkg=quantlib&ver=0.8.1-2&arch=arm&stamp=1184754190&file=log | > | | That's most probably a lack of memory on the build daemon. | | I will try to build it on a machine with more ram. That would be super! Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison
Bug#442036: gcc-4.2: ICE on Alpha with new GSL sources
Package: gcc-4.2 Severity: important Version: 4:4.2.1-6 The new gsl sources (1.90.90-1) failed on Alpha with the following error: /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I..-mieee -mfp-rounding-mode=d -Wall -pipe -fexceptions -D_REENTRANT -g -O3 -mieee -c -o minmax.lo minmax.c gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -mieee -mfp-rounding-mode=d -Wall -pipe -fexceptions -D_REENTRANT -g -O3 -mieee -c minmax.c -fPIC -DPIC -o .libs/minmax.o minmax_source.c: In function 'gsl_vector_long_double_max': minmax_source.c:43: internal compiler error: in iv_analyze_expr, at loop-iv.c:911 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . make[3]: *** [minmax.lo] Error 1 make[3]: Leaving directory `/build/buildd/gsl-1.9.90/vector' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/gsl-1.9.90' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/gsl-1.9.90' make: *** [build-stamp] Error 2 * It seems to gave built everywhere else, see http://buildd.debian.org/build.php?pkg=gsl Dirk -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442036: gcc-4.2: ICE on Alpha with new GSL sources
On Wed, Sep 12, 2007 at 08:04:22PM +0200, Matthias Klose wrote: > Dirk Eddelbuettel writes: > > Please submit a full bug report, > > with preprocessed source if appropriate. > > please do so, does it build with gcc-snapshot? Don't know as I don't have access to Alpha. D. -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442036: gcc-4.2: ICE on Alpha with new GSL sources
On 12 September 2007 at 21:00, Falk Hueffner wrote:
| Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
|
| > /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H
| > -I. -I.. -I.. -I..-mieee -mfp-rounding-mode=d -Wall -pipe -fexceptions
| > -D_REENTRANT -g -O3 -mieee -c -o minmax.lo minmax.c
| > gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -mieee -mfp-rounding-mode=d -Wall
| > -pipe -fexceptions -D_REENTRANT -g -O3 -mieee -c minmax.c -fPIC -DPIC -o
| > .libs/minmax.o
| > minmax_source.c: In function 'gsl_vector_long_double_max':
| > minmax_source.c:43: internal compiler error: in iv_analyze_expr, at
| > loop-iv.c:911
| > Please submit a full bug report,
|
| I can reproduce this with 4.2.1-5 and 4.3.0 20070829. Test case:
|
| long double f(long double *data, long n) {
| long double max = 0;
| long i;
| for (i = 0; i < n; i++) {
| if (data[i])
| max = 1;
| }
| return max;
| }
|
| fails at -O3, OK at -O2.
Many thanks, Falk. I'll prepare 1.9.90-2 where Alpha gets -O2. BTW do we
still need this special case for Alpha:
# edd 29 Sep 2005 alpha needs -mieee with gcc 4.0
ifeq ($(arch),alpha)
CFLAGS += -mieee
endif
Dirk
--
Three out of two people have difficulties with fractions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#94137: gcc -mieee-with-inexact on ev67 gives wrong results
reassign 94137 gcc thanks Ok, this one might be easy to close for the gcc folks as it appears to fixed in newer versions; I am reassigned mostly for record keeping purposes. Thanks, Dirk "Andras" == Major A writes: Andras> SUMMARY Andras> Andras> Thanks all for the debugging info. The problem seems to be gcc Andras> version 2.95.2. The problem doesn't appear with 2.95.3 and 2.96 on Andras> similar hardware. Only ev6 and ev67 seem to be affected. Andras> Andras> This all has had very little testing, so I could be totally wrong. Andras> Andras> Andras Andras> Andras> === Andras> Major Andras e-mail: [EMAIL PROTECTED] www: Andras> http://andras.webhop.org/ Andras> === Andras> Andras> -- According to the latest figures, 43% of all statistics are totally worthless.
Bug#135943: Processed: Re: Bug#135943: r-recommended_1.4.1-1 fails to autobuild on m68k
On Wed, Feb 27, 2002 at 07:35:32AM +0100, Matthias Klose wrote: > Debian Bug Tracking System writes: > > Processing commands for [EMAIL PROTECTED]: > > > > > reassign 135943 gcc > > Bug#135943: r-recommended_1.4.1-1 fails to autobuild on m68k > > Bug reassigned from package `r-recommended' to `gcc'. > > > > > retitle 135943 gcc on m68k has internal error in coxfit2.c in survival in > > > r-recommended > > If live is so short, why the hell does noone of you attach the > preprocessed source to the report, when reassigning the report to > gcc You are no Debian newbies. Just wondering ... Because a) theu are fully documented in a known place and b) I actually did include the pertinent error messages. > and recheck with gcc-3.0 ... That is a good one. I would need help from a m68k maintainer willing to try this. Dirk -- Good judgement comes from experience; experience comes from bad judgement. -- Fred Brooks
Bug#135943: r-recommended_1.4.1-1 fails to autobuild on m68k
On Wed, Feb 27, 2002 at 12:29:15PM +, Phil Blundell wrote:
> On Wed, 2002-02-27 at 02:40, Dirk Eddelbuettel wrote:
> > gcc -I/usr/lib/R/include -fPIC -g -O2 -c coxfit2.c -o coxfit2.o
> > coxfit2.c: In function `coxfit2':
> > coxfit2.c:352: Internal compiler error:
> > coxfit2.c:352: internal error--unrecognizable insn:
> > (insn 2883 243 245 (set (reg:DF 16 %fp0)
> > (const_double:DF (mem/u:DF (symbol_ref/u:SI ("*.LC0")) 0) 0 [0x0] 0
> > [0x0] 0 [0x0])) -1 (nil)
> > (nil))
>
> This is almost certainly the same as #129573, for what that's worth.
Very interesting. Did your last patch fix the problem, and is the -fPIC
option is useable?
Dirk
--
Good judgement comes from experience; experience comes from bad judgement.
-- Fred Brooks
Bug#135943: r-recommended_1.4.1-1 fails to autobuild on m68k
On Wed, Feb 27, 2002 at 04:16:36PM +, Phil Blundell wrote:
> On Wed, 2002-02-27 at 13:03, Dirk Eddelbuettel wrote:
> > On Wed, Feb 27, 2002 at 12:29:15PM +, Phil Blundell wrote:
> > > On Wed, 2002-02-27 at 02:40, Dirk Eddelbuettel wrote:
> > > > gcc -I/usr/lib/R/include -fPIC -g -O2 -c coxfit2.c -o coxfit2.o
> > > > coxfit2.c: In function `coxfit2':
> > > > coxfit2.c:352: Internal compiler error:
> > > > coxfit2.c:352: internal error--unrecognizable insn:
> > > > (insn 2883 243 245 (set (reg:DF 16 %fp0)
> > > > (const_double:DF (mem/u:DF (symbol_ref/u:SI ("*.LC0")) 0) 0
> > > > [0x0] 0 [0x0] 0 [0x0])) -1 (nil)
> > > > (nil))
> > >
> > > This is almost certainly the same as #129573, for what that's worth.
> >
> > Very interesting. Did your last patch fix the problem, and is the -fPIC
> > option is useable?
>
> I don't know. I was too lazy to test it myself and my m68k knowledge is
> a bit sketchy. I'm certainly happy to work with the m68k folks to solve
> this problem if somebody from that camp is prepared to try these things
> out.
I am twisting Chris Steigies arm (the body part, not the arch :) to help me
given that Rick is too busy to do anything but bug filing.
Dirk
--
Good judgement comes from experience; experience comes from bad judgement.
-- Fred Brooks
Bug#144584: g++-3.0: on ia64, internal compiler error with octave code
Package: g++-3.0
Version: 1:3.0.4-7
Severity: important
The following bug report owes a lot to John Eaton's work. I reported a
problem with the octave2.1 package on the ia64 platform to him, the upstream
authors. Bdale kindly provided an account on ia64 for John.
There appear to (still) be some issues with g++-3.0 on ia64. Under some
optimisation switches, the executable is built, but segfaults. Under others,
g++-3.-0 dies.
The latter problem is detailed here. I quote from an email by John to
me. Note that the code in question is really part of GNU Octave, a program we
have successfully built hundreds of times on different platforms.
-
From: "John W. Eaton" <[EMAIL PROTECTED]>
Date: Wed, 24 Apr 2002 13:03:07 -0500
To: Dirk Eddelbuettel <[EMAIL PROTECTED]>
Subject: internal compiler error on ia64
OK, let's start with this one.
Here is the source file (pared down and simplified from what we really
have in lo-mappers.cc):
#include
extern std::complex acosh (const std::complex& x);
std::complex
acos (const std::complex& x)
{
return (std::real (x)) ? acosh (x) : acosh (x);
}
Here is the compile command and result:
g++-3.0 -v -save-temps -c -g foo-3.cc -o foo-3.o
Reading specs from /usr/lib/gcc-lib/ia64-linux/3.0.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,proto,objc --prefix=/usr
--infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as
--with-gnu-ld --with-system-zlib --enable-long-long --enable-nls
--without-included-gettext --disable-checking --enable-threads=posix
--enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc ia64-linux
Thread model: posix
gcc version 3.0.4
/usr/lib/gcc-lib/ia64-linux/3.0.4/cpp0 -lang-c++ -D__GNUG__=3
-D__GXX_DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -v -D__GNUC__=3
-D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=4 -D__ia64 -D__ia64__ -D__linux
-D__linux__ -D_LONGLONG -Dlinux -Dunix -D__LP64__ -D__ELF__ -D__ia64 -D__ia64__
-D__linux -D__linux__ -D_LONGLONG -D__linux__ -D__unix__ -D__LP64__ -D__ELF__
-D__linux -D__unix -Asystem=linux -Acpu=ia64 -Amachine=ia64 -D__NO_INLINE__
-D__STDC_HOSTED__=1 -D_GNU_SOURCE -D__LONG_MAX__=9223372036854775807L foo-3.cc
foo-3.ii
GNU CPP version 3.0.4 (cpplib) (IA-64) Linux
#include "..." search starts here:
#include <...> search starts here:
/usr/include/g++-v3
/usr/include/g++-v3/ia64-linux
/usr/include/g++-v3/backward
/usr/local/include
/usr/lib/gcc-lib/ia64-linux/3.0.4/include
/usr/ia64-linux/include
/usr/include
End of search list.
/usr/lib/gcc-lib/ia64-linux/3.0.4/cc1plus -fpreprocessed foo-3.ii -quiet
-dumpbase foo-3.cc -g -version -o foo-3.s
GNU CPP version 3.0.4 (cpplib) (IA-64) Linux
GNU C++ version 3.0.4 (ia64-linux)
compiled by GNU C version 3.0.4.
foo-3.cc: In function `std::complex acos(const
std::complex&)':
foo-3.cc:8: Internal compiler error in change_address, at emit-rtl.c:1624
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
-
I have not included the complete source file, which can be downloaded from
http://www.che.wisc.edu/~jwe/foo-3.ii
Dirk
--
Good judgement comes from experience; experience comes from bad judgement.
-- Fred Brooks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#144584: g++-3.0: on ia64, internal compiler error with octave code
> > There appear to (still) be some issues with g++-3.0 on ia64. Under some > > optimisation switches, the executable is built, but segfaults. Under others, > > g++-3.-0 dies. > > fwiw with gcc version 3.1 20020331 (prerelease) the problem appears to > be fixed. I think this might be the same/related to pr/5363, but not > sure. Is that one available somewhere on an ia64 box, preferably one accessible to John? > there are a couple of fixes that might be related to this in cvs > unfortunately with the pending woody release we probably won't get this > in till woody+1... Such is life. More important to get it fixed in the first place. Thanks for heads-up. Dirk -- According to the latest figures, 43% of all signatures are totally worthless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gcc internal compiler error on mips with octave-forge
See http://buildd.debian.org/fetch.php?&pkg=octave-forge&ver=2004.01.18-1&arch=mips&stamp=1074506653&file=log&as=raw for more details, the pertinent part is mkoctfile -DHAVE_OCTAVE_21 -v lp.cc /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.52 -I/usr/include/octave-2.1.52/octave -O2 -DHAVE_OCTAVE_21 lp.cc -o lp.o lp.cc: In function ctave_value_list Flp(const octave_value_list&, int)': lp.cc:640: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [lp.oct] Error 1 make[3]: Leaving directory build/buildd/octave-forge-2004.01.18/main/optim' make[2]: *** [optim/] Error 2 make[2]: Leaving directory build/buildd/octave-forge-2004.01.18/main' make[1]: *** [main/] Error 2 make[1]: Leaving directory build/buildd/octave-forge-2004.01.18' make: *** [build-stamp] Error 2 ** Build finished at 20040119-1059 FAILED [dpkg-buildpackage died] Purging chroot-unstable/build/buildd/octave-forge-2004.01.18 mkoctfile is just a wrapper used by Octave. Cou someone with acces to a mips box please try if it builds with -O1 or -O0 ? It builds on a bunch of ther architectures just fine. Thanks, Dirk -- The relationship between the computed price and reality is as yet unknown. -- From the pac(8) manual page
Re: gcc internal compiler error on mips with octave-forge
On Tue, Jan 20, 2004 at 07:16:54PM +, Martin Michlmayr wrote: > * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2004-01-20 11:06]: > > mkoctfile -DHAVE_OCTAVE_21 -v lp.cc > > /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.52 > > -I/usr/include/octave-2.1.52/octave -O2 -DHAVE_OCTAVE_21 lp.cc -o lp.o > > lp.cc: In function ctave_value_list Flp(const octave_value_list&, int)': > > lp.cc:640: internal compiler error: Segmentation fault > > It seems to build here with the same toolchain used in the failed Interesting. I also note that it used to build before (but IIRC some changes were applied more recently to this particular file, though I may confuse this with another file in octave-forge). If it builds, could you possibly upload the resulting .deb to ftp-master.d.o? > build. I'd just give the mips buildd a chance to take a look and > possibly try another build. Could do too, though that will happen with the next upload anyway. This 2004.01.18-1 upload is a bit of a test for upstream; if it works there will be a new version anyway (and we may refrain from re-uploading it if there are in fact no changes at all). Dirk > 152:[EMAIL PROTECTED]: ..orge-2004.01.18/main/optim] make ^^ Cool hostname for someone with, if memory serves, an undergrad in psychology :) Dirk > mkoctfile -DHAVE_OCTAVE_21 -v lp.cc > /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.52 > -I/usr/include/octave-2.1.52/octave -O2 -DHAVE_OCTAVE_21 lp.cc -o lp.o > /tmp/ccOcRNbv.s: Assembler messages: > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /tmp/ccOcRNbv.s:43994: Warning: AT used after ".set noat" or macro used after > ".set nomacro" > /usr/bin/g++ -shared -o lp.oct lp.o > mkoctfile -DHAVE_OCTAVE_21 -v leval.cc > /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.52 > -I/usr/include/octave-2.1.52/octave -O2 -DHAVE_OCTAVE_21 leval.cc -o leval.o > /usr/bin/g++ -shared -o leval.oct leval.o > 153:[EMAIL PROTECTED]: ..orge-2004.01.18/main/optim] > > ii binutils 2.14.90.0.7-3 The GNU assembler, linker > and binary utilities > ii libc6-dev 2.3.2.ds1-10 GNU C Library: Development > Libraries and Header Files > ii gcc-3.33.3.3-0pre1The GNU C compiler > ii g++-3.33.3.3-0pre1The GNU C++ compiler > ii libstdc++5 3.3.3-0pre1The GNU Standard C++ > Library v3 > ii libstdc++5-3.3-dev 3.3.3-0pre1The GNU Standard C++ > Library v3 (development files) > > -- > Martin Michlmayr > [EMAIL PROTECTED] > -- The relationship between the computed price and reality is as yet unknown. -- From the pac(8) manual page
Bug#255100: quantlib FTBFS on amd64: files not found.
On Sat, Jun 19, 2004 at 03:56:22PM +0200, Kurt Roeckx wrote: > On Sat, Jun 19, 2004 at 08:48:37AM -0500, Dirk Eddelbuettel wrote: > > > > arch := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) > > Shouldn't you be using the DEB_BUILD_GNU_TYPE instead? (It > returns the same in this cause, but in case of cross compiles?) Maybe. I tend to copy what works in one debian/rules across my other ones. I guess cross-compilation has not been an issue yet. Maybe I get bitten by that one day... Dirk -- FEATURE: VW Beetle license plate in California
