Bug#1065603: libdebuginfod1t64 dependency problem breaks the upgrade

Control: retitle -1 libdebuginfod1t64 dependency problem makes dpkg fail with attempt of removal of libdebuginfod-common On 2024-03-07 11:28:21 +0100, Vincent Lefevre wrote: > When I wanted to upgrade, this ended up with > > dpkg: dependency problems prevent removal of libdebuginf

Bug#1065603: libdebuginfod1t64 dependency problem breaks the upgrade

Package: libdebuginfod1t64 Version: 0.190-1.1 Severity: serious When I wanted to upgrade, this ended up with dpkg: dependency problems prevent removal of libdebuginfod-common: libdebuginfod1t64:amd64 depends on libdebuginfod-common (>= 0.190-1.1). dpkg: error processing package

Bug#1057355: libmpfr6: major formatted output function bugs with %c and the value 0

Control: tags -1 fixed-upstream On 2023-12-03 22:13:03 +0100, Vincent Lefevre wrote: > I've reported the following bug in the MPFR mailing-list. I think > I've fixed the issues on the MPFR side in master, but MPFR is still > affected by the bug on the GMP side (gmp_vasprintf): >

Bug#1057355: libmpfr6: major formatted output function bugs with %c and the value 0

Package: libmpfr6 Version: 4.2.0-1 Severity: grave Tags: security upstream Justification: user security hole Forwarded: https://sympa.inria.fr/sympa/arc/mpfr/2023-12/msg0.html X-Debbugs-Cc: Debian Security Team I've reported the following bug in the MPFR mailing-list. I think I've fixed the

Bug#1046055: mpfr4: Fails to build source after successful build

On 2023-08-28 11:51:17 +0200, Vincent Lefevre wrote: > On 2023-08-28 11:15:15 +0200, Matthias Klose wrote: > > the package is built in a separate build dir. shouldn't the upstream > > makefile also build the info file in the build tree? > > I'm not sure. The issue is t

Bug#1046055: mpfr4: Fails to build source after successful build

On 2023-08-28 11:15:15 +0200, Matthias Klose wrote: > > Apparently this is due to the fact that the upstream mpfr.info file > > is rebuilt. > > the package is built in a separate build dir. shouldn't the upstream > makefile also build the info file in the build tree? I'm not sure. The issue is

Bug#1046055: mpfr4: Fails to build source after successful build

On 2023-08-13 21:21:00 +0200, Lucas Nussbaum wrote: > > dpkg-source: error: aborting due to unexpected upstream changes, see > > /tmp/mpfr4_4.2.0-1.diff.v1TRvW The diff contains the following: --- mpfr4-4.2.0.orig/doc/mpfr.info +++ mpfr4-4.2.0/doc/mpfr.info @@ -1,4 +1,4 @@ -This is mpfr.info,

Bug#1036606: libmpfr6: multiple bugs in GNU MPFR 4.2.0, patches available

Package: libmpfr6 Version: 4.2.0-1 Severity: important Tags: upstream There are multiple bugs, more or less important, in GNU MPFR 4.2.0. Patches are available at https://www.mpfr.org/mpfr-4.2.0/#bugs In particular: * For the mpfr_ui_pow_ui function, infinite loop in case of overflow. * The

Bug#1032130: gcc-12: incorrect -Wanalyzer-shift-count-overflow warning

Package: gcc-12 Version: 12.2.0-14 Severity: normal Tags: upstream Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447 On the following program void f (unsigned long *p, int r, int i) { int b = 64, n = r % 64; while (i >= 0 && b >= 0) { if (b <= n) p[i--] = 1UL

Bug#1027284: mpfr_custom_get_kind broken in current 4.1.1

Control: tags -1 upstream fixed-upstream On 2022-12-29 19:22:12 +0100, Yuri D'Elia wrote: > According to https://github.com/CGAL/cgal/issues/7064 mpfr 4.1.1 was > updated after-the-fact without a version bump. I'm wondering what you mean by "version bump". > mpfr 4.1.1 in debian has a broken

Bug#1014150: gcc-snapshot: unexpected failures with no arguments or with -v

Package: gcc-snapshot Version: 1:20220630-1 Severity: normal "gcc-snapshot" without any argument fails in a strange way: $ gcc-snapshot /usr/bin/ld: /usr/lib/x86_64-linux-gnu/crt1.o: in function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status

Bug#539912: now, gcc-11

Control: reassign -1 gcc-11 11.2.0-13 since the gcc package now depends on gcc-11 and the bug is still present. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP,

Bug#539912: reopen

Control: reopen -1 Reopen bug closed by a spammer. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#993021: gcc-11: incorrect -Wanalyzer-shift-count-overflow warning

Package: gcc-11 Version: 11.2.0-3 Severity: important Tags: upstream Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98447 Compiling the following code with "gcc-11 -fanalyzer -c" void f (unsigned long *p, int r, int i) { int b = 64, n = r % 64; while (i >= 0 && b >= 0) {

Bug#929777: gcc-6: output errors to .gcda file are not checked

Control: retitle -1 gcc: some errors in output to .gcda file are not checked Control: tags -1 fixed-upstream On 2021-08-04 12:33:38 +0200, Vincent Lefevre wrote: > I've just reported the bug upstream (and with a GCC 12 snapshot > I built a few days ago, I don't even get an error message).

Bug#929777: gcc-6: output errors to .gcda file are not checked

Control: reassign -1 gcc-10 10.2.1-6 Control: tags -1 upstream Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101773 On 2019-05-31 01:19:47 +0200, Vincent Lefevre wrote: > Write failures should be detected, and when this happens, > the program should terminate with a no

Bug#539912: now in gcc-10

Control: reopen -1 Control: reassign -1 gcc-10 10.2.1-6 Still occurs there, which is now the default gcc. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP,

Bug#973443: src/init2.c:52: MPFR assertion failure

On 2020-10-30 13:34:31 -0400, John Scott wrote: > I was fooling around with Arb and it seems that this program causes > an assertion failure in MPFR, although ASan and UBSan don't point to > any misusage by Arb. (Curiously if you change the numerical string > from "0" to "0.5" then Arb does

Bug#953806: cpp-9: no include path in which to search for limits.h

Compare: cventin:~> cpp-8 tst.c # 1 "tst.c" # 1 "" # 1 "" # 31 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 32 "" 2 # 1 "tst.c" # 1 "/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h" 1 3 4 [...] cventin:~> cpp-9 tst.c # 1 "tst.c" # 1 "" # 1 "" # 31 "" # 1 "/usr/include/stdc-predef.h" 1 3 4

Bug#953806: cpp-9: no include path in which to search for limits.h

Package: cpp-9 Version: 9.3.0-1 Severity: grave Justification: renders package unusable The compilation of a simple program like #include int main (void) { return 0; } now fails: cventin:~> gcc-9 tst.c -o tst In file included from tst.c:1: /usr/include/limits.h:124:26: error: no include

Bug#951086: libgcc1: /lib/x86_64-linux-gnu/libgcc_s.so.1 is missing

Package: libgcc1 Version: 1:10-20200204-1 Severity: important After a recent upgrade, I get the following error: zira:~> gcc-4.9 tst.c -o tst /usr/bin/ld: cannot find -lgcc_s collect2: error: ld returned 1 exit status It tries to open libgcc_s.so, which was previously found at

Bug#949945: gcc-snapshot: some executables have debug info, making the package 3 times as big as previously

Package: gcc-snapshot Version: 1:20200124-1 Severity: normal One has: -rw-r--r-- 1 198M 2019-11-30 15:28:32 gcc-snapshot_1%3a20191130-1_amd64.deb -rw-r--r-- 1 567M 2020-01-24 23:43:53 gcc-snapshot_1%3a20200124-1_amd64.deb and Package: gcc-snapshot Version: 1:20191130-1 Installed-Size: 1066234

Bug#948490: gcc-9: -std=c11 prevents the use of decimal FP

Control: tags -1 upstream Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93410 On 2020-01-23 14:04:59 +0100, Matthias Klose wrote: > please could you recheck with trunk, This is still OK with the trunk (e9ee848dcdc). > and report that upstream? Done. -- Vincent Lefèvre -

Bug#948490: gcc-9: -std=c11 prevents the use of decimal FP

Package: gcc-9 Version: 9.2.1-22 Severity: normal The -std=c11 option (or other versions of the C standard) prevents the use of decimal FP: $ cat tst.c int main (void) { _Decimal64 x = 1; return x != 1; } $ gcc-9 tst.c -o tst $ gcc-9 -std=c11 tst.c -o tst tst.c: In function ‘main’:

Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

On 2019-10-29 13:09:46 +0100, rene.engelh...@mailbox.org wrote: > Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre : > >In case makefile magic triggers some rebuild, you can also run the > >generated executable directly (with the right environment variables, > >

Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

On 2019-10-29 11:52:55 +0100, rene.engelh...@mailbox.org wrote: > Hi again, > > Am 29. Oktober 2019 11:26:41 MEZ schrieb rene.engelh...@mailbox.org: > >Hi, > > > >Am 29. Oktober 2019 10:59:07 MEZ schrieb Vincent Lefevre > >: > >> If you build LO > >

Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

On 2019-10-28 23:34:11 +0100, Rene Engelhard wrote: > You like to make other people bad where this is not the case. In this > case this is not a LO bug since the exact same LO version worked until > said gcc upload. If the LO code has some undefined behavior, it could also be a LO bug triggered

Bug#930430: libasan5: AddressSanitizer breaks when LD_PRELOAD is defined

Package: libasan5 Version: 8.3.0-7 Severity: normal When LD_PRELOAD is defined (which can be a consequence of gtk3-nocsd being installed and the user being in an X11 session), I get: zira:~> gcc -fsanitize=address t.c zira:~> ./a.out ==11059==ASan runtime does not come first in initial library

Bug#929777: gcc-6: output errors to .gcda file are not checked

Package: gcc-6 Version: 6.3.0-18+deb9u1 Severity: normal When executing a program compiled with profile generation (-fprofile-generate), the obtained .gcda file is sometimes empty (apparently due to write errors). The problem is that the program terminates successfully, so that the issue is not

Bug#928254: gcc-8: -static-libasan does not work with GNU MPFR

Control: reassign -1 libtool 2.4.6-10 Control: retitle -1 libtool: "Flags to be passed through unchanged" should include -static-libasan Control: severity -1 normal On 2019-05-02 10:10:33 +0200, Vincent Lefevre wrote: > On 2019-05-01 20:54:05 +0200, Matthias Klose wrote: > &g

Bug#928254: gcc-8: -static-libasan does not work with GNU MPFR

On 2019-05-01 20:54:05 +0200, Matthias Klose wrote: > the linker never sees your CFLAGS. At least -static-libasan needs to > be added to LDFLAGS. Indeed, I can see -static-libasan in the "libtool --mode=link" line, but libtool drops this option in the gcc call: /bin/sh ../libtool --tag=CC

Bug#928254: gcc-8: -static-libasan does not work with GNU MPFR

Package: gcc-8 Version: 8.3.0-7 Severity: minor When I build and check GNU MPFR with: ./configure CFLAGS="-fsanitize=address -static-libasan" make make check I get lots of failure with the error: Your application is linked against incompatible ASan runtimes. Though -static-libasan has

Bug#922278: mpfr4: please update the www.mpfr.org URLs to use https

Source: mpfr4 Version: 4.0.2-1 Severity: normal The www.mpfr.org URLs under the debian directory should be updated to use https: debian/control:Homepage: http://www.mpfr.org/ debian/copyright:MPFR was downloaded from http://www.mpfr.org/. debian/watch:http://www.mpfr.org/mpfr-current/

Bug#539912: reassign to gcc-8, which is now the default compiler

Control: reopen -1 Control: reassign -1 gcc-8 8.2.0-17 Control: retitle -1 gcc-8: for c99, POSIX requires that option -D have a lower precedence than -U as this is now the default compiler, and the bug still occurs with it. -- Vincent Lefèvre - Web: 100% accessible

Bug#918226: gcc-snapshot.prerm yields error messages - incorrect paths?

Package: gcc-snapshot Version: 1:20190102-1 Severity: normal I can see the following error messages on upgrade or removal: find: ‘/usr/lib/gcc-snapshot/share/python’: No such file or directory find: ‘/usr/lib/gcc-snapshot/share/python’: No such file or directory They come from

Bug#903771: c99: buggy POSIX abs(INT_MIN)

Package: gcc Version: 4:7.3.0-3 Severity: normal In the new POSIX abs() specification: If the result cannot be represented, the result shall be {INT_MIN}. instead of being undefined behavior. See: http://austingroupbugs.net/view.php?id=1108#c4041 Thus the following program

Bug#897416: mpfr4: FTBFS on kfreebsd-amd64

[Cc mpfr list] On 2018-05-02 13:45:30 +0200, Vincent Lefevre wrote: > and in the configure output: > > checking if compiler knows _Decimal64... no Note that it is "yes" for kfreebsd-i386: https://buildd.debian.org/status/fetch.php?pkg=mpfr4=kfreebsd-i386=4.0.1-1=152342

Bug#897416: mpfr4: FTBFS on kfreebsd-amd64

On 2018-05-02 11:38:14 +0200, Svante Signell wrote: > mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the debian/libmpfr6.symbols > file. Attached is a file with the symbols generated from the build: > libmpfr6.symbols.kfreebsd-amd64. This is due to: --- debian/libmpfr6.symbols

Bug#892096: gcc-snapshot: AddressSanitizer uses glibc internal functions

On 2018-03-20 01:06:50 +0100, Vincent Lefevre wrote: > Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761 > Control: tags -1 fixed-upstream > > in the sense that this will be OK at least up to glibc 2.27. > > See https://gcc.gnu.org/bugzilla/show_b

Bug#892096: gcc-snapshot: AddressSanitizer uses glibc internal functions

Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761 Control: tags -1 fixed-upstream in the sense that this will be OK at least up to glibc 2.27. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761#c9 Author: jakub Date: Mon Mar 19 20:47:29 2018 New Revision: 258663 URL:

Bug#892096: gcc-snapshot: AddressSanitizer uses glibc internal functions

Control: reopen -1 On 2018-03-14 10:27:35 +0100, Vincent Lefevre wrote: > On 2018-03-14 09:20:17 +0100, Matthias Klose wrote: > > now built using glibc-2.27. > > Which version? FYI, I still obtain a crash with 201803012-1. Reopening since 201803012-1 depends on libc6 (>

Bug#892096: gcc-snapshot: AddressSanitizer uses glibc internal functions

On 2018-03-14 09:20:17 +0100, Matthias Klose wrote: > now built using glibc-2.27. Which version? FYI, I still obtain a crash with 201803012-1. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work:

Bug#892096: libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer

On 2018-03-05 20:46:32 +0100, Aurelien Jarno wrote: > The AddressSanitizer is using glibc internal functions though dlsym(), > and such functions have the right to change in new major versions: > > From libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc: > | void *get_tls_static_info_ptr =

Bug#892873: gcc-snapshot: unusual version number

Package: gcc-snapshot Version: 201803012-1 Severity: normal The version number is 201803012-1 instead of the expected 20180312-1. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'),

Bug#892096: libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer

Control: reassign -1 libc6 2.27-1 Control: retitle -1 libc6:i386 yields invalid writes, triggered by GCC's AddressSanitizer Control: severity -1 serious On 2018-03-05 14:10:56 +0100, Vincent Lefevre wrote: > cventin:~> cat tst.c > int main (void) > { > return 0; > } > cv

Bug#892096: gcc-snapshot: AddressSanitizer /usr/lib/gcc-snapshot/lib32/libasan.so.5 is broken: SEGV

Package: gcc-snapshot Version: 20180216-1 Severity: important On a program that does nothing, the AddressSanitizer segfaults with the 32-bit ABI. This is a regression. I have the following gcc-snapshot script: #!/bin/sh LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH

Bug#889723: libmpfr6: Obsolete README.Debian file

Package: libmpfr6 Version: 4.0.1~rc2-1 Severity: minor /usr/share/doc/libmpfr6/README.Debian contains: | MPFR Documentation | -- | | The documentation of MPFR is licensed under the GFDL which is | considered non-free by the debian project, and has been removed from | this

Bug#889711: Error installing libmpfr-doc

Control: tags -1 - upstream Not an upstream bug. Upstream does not provide the /usr/share/doc-base/mpfr-manual file, which seems to be generated by Debian tools. On 2018-02-06 09:25:26 +0100, cruncher wrote: > Package: libmpfr-doc > Version: 4.0.1~rc2-1 > Severity: normal > Tags: upstream > >

Bug#889631: Bug#889647: mpfr 4.0 branch fails to build with texinfo.tex from automake

On 2018-02-05 23:34:18 +0900, Norbert Preining wrote: > > In case this was not clear, I meant that in addition to the texinfo > > correction, something else needs to be done in another package, > > either in automake or in mpfr4, to that the right texinfo.tex file > > automake is the culprit.

Bug#889631: Bug#889647: mpfr 4.0 branch fails to build with texinfo.tex from automake

On 2018-02-05 15:23:08 +0100, Vincent Lefevre wrote: > I think that there are 2 possible solutions: > > 1. Make sure that the texinfo.tex provided in the tarball is used > (I wonder why it gets replaced, this should be unnecessary, just > like things such as autoreconf). > >

Bug#889631: Bug#889647: mpfr 4.0 branch fails to build with texinfo.tex from automake

On 2018-02-05 22:42:55 +0900, Norbert Preining wrote: > Hi Vincent, > > I cannot add much to your email, all correct. > > > > I assume texinfo's version of texinfo.tex is too old as well for the > > > mpfr4 build, > > > > Probably, but maybe for a different reason. The current version > > from

Bug#889631: mpfr 4.0 branch fails to build with texinfo.tex from automake

On 2018-02-05 10:49:18 +0100, Matthias Klose wrote: > I see that the texinfo.tex version in automake is from 2013, and is > definitely too old for the mpfr4 build. Could that copy be kept in > sync with texinfo? I reported in November 2017:

Bug#889631: mpfr 4.0 branch fails to build with recent tex

On 2018-02-05 08:45:00 +0100, Matthias Klose wrote: [...] > Chapter 4 [5] [6] [7] [8] [9] [10] Chapter 5 [11] [12] [13] [14] [15] [16] > ../../../.././../../doc/mpfr.texi:1577: Undefined control sequence. > \GMPabs #1->\ensuremath > {|#1|} FYI, I had to do the following

Bug#889631: mpfr 4.0 branch fails to build with recent tex

On 2018-02-05 08:45:00 +0100, Matthias Klose wrote: > Trying to build the 4.0.0 release candidate 2 in Debian unstable, > the package fails to build the documentation: > > texlive is version 2017.20180110-1. If I try to build the PDF manually (make pdf), I can't reproduce the problem. >

Bug#888422: libmpfr6 should add Breaks: libmpfr4

On 2018-01-25 20:32:45 +0200, Adrian Bunk wrote: > On Thu, Jan 25, 2018 at 02:15:15PM +0100, Vincent Lefevre wrote: > > On 2018-01-25 14:11:49 +0200, Adrian Bunk wrote: > > > Mixing libmpfr4 and libmpfr6 doesn't work well: > > > > Wasn't symbol versioning supposed

Bug#888422: libmpfr6 should add Breaks: libmpfr4

On 2018-01-25 14:11:49 +0200, Adrian Bunk wrote: > Mixing libmpfr4 and libmpfr6 doesn't work well: Wasn't symbol versioning supposed to solve this issue? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Bug#888253: mpfr4: Please reduce optimization level on powerpcspe

On 2018-01-24 11:38:35 +0100, John Paul Adrian Glaubitz wrote: > Source: mpfr4 > Version: 3.1.6-1 ^^^ I suppose that this should be 4.0.0-5. [...] > The mpfr4 build for the 4.x versions is currently choking on gcc ICEs [1]: -- Vincent

Bug#877233: libstdc++6: gnuplot crashed in libstdc++.so.6 (SIGSEGV)

On 2017-10-27 00:00:06 +0200, Matthias Klose wrote: > closing this issue. Apparently it us unreproducible, also by upstream. Please > feel free to reopen and adding instructions for a reproducer. I still couldn't reproduce the bug. No issues detected by valgrind. -- Vincent Lefèvre

Bug#879864: gcc-5: version mismatch

Package: gcc-5 Version: 5.5.0-2 Severity: normal zira:~> gcc-5 --version gcc-5 (Debian 5.5.0-2) 5.4.1 20171010 [...] The package version is 5.5.0-2, but the displayed version is 5.4.1. This is not consistent. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT

Bug#879823: gcc-7: mismatch version given by "gcc-7 --version"

Package: gcc-7 Version: 7.2.0-12 Severity: normal cventin:~> gcc-7 --version gcc-7 (Debian 7.2.0-12) 7.2.1 20171025 [...] The package version is 7.2.0-12, but the displayed version is 7.2.1. This is not consistent. -- System Information: Debian Release: buster/sid APT prefers unstable-debug

Bug#877233: libstdc++6: gnuplot crashed in libstdc++.so.6 (SIGSEGV)

Note: Under about the same conditions, I did not get any crash in the past months. So this issue might be new. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic /

Bug#877233: libstdc++6: gnuplot crashed in libstdc++.so.6 (SIGSEGV)

Package: libstdc++6 Version: 7.2.0-7 Severity: important gnuplot crashed in libstdc++.so.6: Core was generated by `/usr/bin/gnuplot -persist'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f82004884f8 in vtable for __cxxabiv1::__si_class_type_info () from

Bug#872054: gcc-multilib: installation of gcc-X-multilib should not yield the installation of the default gcc

On 2017-08-14 18:21:07 +0200, Aurelien Jarno wrote: > On 2017-08-13 23:00, Vincent Lefevre wrote: > > Something needs to be done to avoid that. Shouldn't the > > /usr/include/asm symbolic link be provided either by libc6-dev-i386 > > or by the individual gcc-X-multilib p

Bug#872054: gcc-multilib: installation of gcc-X-multilib should not yield the installation of the default gcc

Package: gcc-multilib Version: 4:7.1.0-2 Severity: wishlist gcc-multilib currently provides two independent features: 1. the /usr/include/asm symbolic link (which has nothing to do with a specific GCC version); 2. depends on the default GCC version (currently via gcc-7-multilib). Because on

Bug#862176: gcc-snapshot: needs packages from experimental, with -fsanitize=address

On 2017-05-10 03:26:14 +0200, Vincent Lefevre wrote: > Forget that. This breaks the use of LD_RUN_PATH. :( Or the contents > of LD_RUN_PATH should be added as rpath arguments by the wrapper. In case this can be useful: #!/bin/sh LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PAT

Bug#862176: gcc-snapshot: needs packages from experimental, with -fsanitize=address

On 2017-05-10 01:31:02 +0200, Vincent Lefevre wrote: > > closing this issue, there is no "propoer" solution. > > I'm just thinking... Couldn't the use of a run path for > /usr/lib/gcc-snapshot/lib be a proper solution? i.e. give > a better wrapper as an exa

Bug#862176: gcc-snapshot: needs packages from experimental, with -fsanitize=address

Control: reopen -1 Control: severity -1 minor Control: retitle -1 gcc-snapshot: README.Debian is inaccurate concerning LD_LIBRARY_PATH On 2017-05-10 00:00:10 +0200, Matthias Klose wrote: > set LD_LIBRARY_PATH for running your binaries. OK, I now understand (I didn't see that gcc-snapshot

Bug#862176: gcc-snapshot: needs packages from experimental, with -fsanitize=address

Package: gcc-snapshot Version: 20170505-1 Severity: important If I compile a program with gcc-snapshot -fsanitize=address I get when running it: ./a.out: error while loading shared libraries: libasan.so.4: cannot open shared object file: No such file or directory libasan.so.4 is part of

Bug#826555: gcc-snapshot regression: -Warray-bounds false positive with -O2

Control: tags -1 - fixed-upstream On 2017-01-17 12:06:17 +0100, Vincent Lefevre wrote: > Control: tags -1 fixed-upstream > > See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433#c10 Well, I can no longer reproduce the warning with the simple test case, but this is still rep

Bug#826555: gcc-snapshot regression: -Warray-bounds false positive with -O2

Control: tags -1 fixed-upstream See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433#c10 -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP,

symlink to liblto_plugin.so

Hi Debian GCC Maintainers, Shouldn't there be a symlink to liblto_plugin.so in /usr/lib/bfd-plugins? When one builds some software (in particular, libraries) with LTO (-flto), then the end user should expect that the LTO plugin be used automatically, without needing to specify AR, NM and RANLIB

Bug#836864: libasan3: -fsanitize=address -static-libasan doesn't always work

Package: libasan3 Version: 6.2.0-3 Severity: normal While -fsanitize=address -static-libasan works on a simple .c file, it no longer works in a more complex case. To reproduce, build MPFR (e.g. 3.1.4) with: ./configure CC=gcc-6 CFLAGS="-fsanitize=address -static-libasan" make make check

Bug#836855: gcc-snapshot: -fsanitize=address -static-libasan doesn't work

Package: gcc-snapshot Version: 20160508-1 Severity: normal cventin:~> cat t.c int main (void) { return 0; } cventin:~> gcc-snapshot -fsanitize=address -static-libasan t.c cventin:~> ./a.out ==27754==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asan_rtl.cc:405

Bug#836848: libasan3: AddressSanitizer breaks when LD_PRELOAD is defined

Package: libasan3 Version: 6.2.0-3 Severity: normal When LD_PRELOAD is defined (which can be a consequence of gtk3-nocsd being installed and the user being in an X11 session), I get: cventin:~> gcc -fsanitize=address t.c cventin:~> ./a.out ==22051==ASan runtime does not come first in initial

Bug#539912: reassign to gcc-6, which is now the default compiler

Control: reassign -1 gcc-6 6.1.1-11 as this is now the default compiler, and the bug still occurs with it. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic /

Bug#827173: gcc-6: missing "Debian" in "gcc-6 --version" output

On 2016-06-13 14:43:06 +0200, Matthias Klose wrote: > from the logs: > > > Configured with: -v > > --with-pkgversion=' 6.1.1-6' > > Don't know what happened. A new build has the distro name again. I can see in the debian/rules2 file of 6.1.1-6: CONFARGS = -v \

Bug#827173: gcc-6: missing "Debian" in "gcc-6 --version" output

Package: gcc-6 Version: 6.1.1-6 Severity: minor $ gcc-6 --version gcc-6 ( 6.1.1-6) 6.1.1 20160609 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR

Bug#826555: gcc-snapshot regression: -Warray-bounds false positive with -O2

Package: gcc-snapshot Version: 20160603-1 Severity: important Tags: upstream Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433 When compiling GNU MPFR 3.1.4 with CFLAGS="-O2 -Werror=array-bounds" and gcc (Debian 20160603-1) 7.0.0 20160603 (experimental) [trunk revision 237077] I

Bug#345587: cpp-4.0: x86/powerpc inconsistency for the __linux macro

Control: tags -1 + wontfix On 2016-01-25 17:10:59 +0100, Matthias Klose wrote: > Control: tags -1 + wontfix Retagging wontfix (FYI, "Control:" pseudo-headers do not work with -done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746206). I don't know the reason of this wontfix, but anyway,

Bug#803055: gcj-5-jre-headless: update-alternatives priority is too low: 105 instead of 1050

Package: gcj-5-jre-headless Version: 5.2.1-22 Severity: normal One has the following update-alternatives priorities: xvii:~> update-alternatives --display java [...] /usr/bin/gij-4.6 - priority 1046 /usr/bin/gij-4.7 - priority 1047 /usr/bin/gij-4.8 - priority 1048 /usr/bin/gij-4.9 - priority

Bug#796076: gcc-5: undefined reference errors with extern __inline__ (regression)

On 2015-08-20 13:19:23 +0200, Matthias Klose wrote: see https://gcc.gnu.org/gcc-5/porting_to.html __attribute__ ((gnu_inline)) should be your fix. Yes, this has been fixed in GMP 4.2, but the (very old) GMP 4.1 branch will never be fixed. This is a bit annoying, as for MPFR up to 3.1.x, we

Bug#796076: gcc-5: undefined reference errors with extern __inline__ (regression)

On 2015-08-19 17:36:47 +0200, Matthias Klose wrote: On 08/19/2015 10:48 AM, Vincent Lefevre wrote: extern __inline__ fn1() { fn2(); } main() {} not a bug. if you want to keep gnu89 inline semantics, build using -fgnu89-inline. Well, I haven't chosen the gnu89 inline semantics

Bug#796076: gcc-5: undefined reference errors with extern __inline__ (regression)

Package: gcc-5 Version: 5.2.1-15 Severity: important On the following C code obtained with creduce (on a code obtained when I wanted to test MPFR 3.1.3 against GMP 4.1.4): extern __inline__ fn1() { fn2(); } main() {} I get the following error with gcc-5: $ gcc-5 -w ct.i /tmp/ccFWIDKK.o: In

Bug#772642: cpp-4.9: please support multiarch for the user search paths (CPATH, etc.)

On 2015-05-03 18:33:12 +0200, Matthias Klose wrote: On 12/09/2014 03:03 PM, Vincent Lefevre wrote: cpp currently supports multiarch search paths for /usr/local and /usr, but not for directories supplied via environment variables like $CPATH and $C_INCLUDE_PATH. For instance, cpp -v gives

Bug#772746: gcc-snapshot: generates wrong code with -O2 - major regression

Package: gcc-snapshot Version: 20141209-1 Severity: grave Tags: upstream Justification: renders package unusable Generates wrong code with -O2 (e.g. for GNU MPFR). Bug reported several times upstream, including mine: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64255 -- System Information:

Bug#772642: cpp-4.9: please support multiarch for the user search paths (CPATH, etc.)

Package: cpp-4.9 Version: 4.9.2-5 Severity: wishlist cpp currently supports multiarch search paths for /usr/local and /usr, but not for directories supplied via environment variables like $CPATH and $C_INCLUDE_PATH. For instance, cpp -v gives: /usr/local/include/x86_64-linux-gnu

Bug#770450: gcc-snapshot: ICE with -O2 -fsanitize=undefined

Package: gcc-snapshot Version: 20141118-1 Severity: important Tags: upstream Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64016 $ gcc-snapshot -O2 -fsanitize=undefined -c gcc-ice.c gcc: internal compiler error: Segmentation fault (program cc1) Please submit a full bug report, with

Bug#693632: gcc-snapshot: depends on libc6-dev-x32 which is not in Debian

On 2012-11-18 19:59:39 +, Thorsten Glaser wrote: tg@zigo:~ $ sudo apt-get --purge dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Starting Starting 2 Investigating (0) gcc-snapshot [ amd64 ] 20121106-1 -

Bug#684082: gcc-doc: update to gcc 4.7

On 2012-08-06 21:32:53 +0200, Andrew Shadura wrote: Please package gcc-4.7-doc and update gcc-doc to point to it. Now that gcc-4.7-doc is available, the only thing to do is to update gcc-doc to point to it. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible

Bug#681076: gcc-4.7: gcov -f rounding problem

Package: gcc-4.7 Version: 4.7.1-4 Severity: minor I have the following problem with gcov: ypig:/tmp/ompfr-gcov/src gcov -f round_prec.c Function 'mpfr_can_round_raw' Lines executed:100.00% of 44 Function 'mpfr_can_round' Lines executed:100.00% of 4 Function 'mpfr_prec_round' Lines

Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

On 2011-12-31 17:04:19 +0100, Matthias Klose wrote: A wrapper will never remind you using the new library paths at runtime. At runtime? Do you mean that one needs to change the library path also for running the generated executable? The README.Debian file doesn't say anything like that.

Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

On 2011-12-31 14:00:04 -0600, Jonathan Nieder wrote: Vincent Lefevre wrote: At runtime? Do you mean that one needs to change the library path also for running the generated executable? Yes, gcc-snapshot includes a snapshot of libgcc (and libstdc++, libgcj, libobjc, etc). So checking

Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

On 2011-12-30 13:08:24 -0600, Jonathan Nieder wrote: Adam Borowski wrote: I see no reason why it couldn't simply be shipped in the package outright. It's not like it invades anyone's namespace, etc. It would be also consistent with all other gcc packages, all having the executable named

Bug#431014: Why won't you ship /usr/bin/gcc-snapshot?

On 2011-12-30 17:15:00 -0600, Jonathan Nieder wrote: No, I mean that packagers can but should not use Build-Depends: gcc-snapshot CC = gcc-snapshot Don't do that, then. you might say. But not providing a /usr/bin/gcc-snapshot wrapper provides people with a reminder to look

Bug#650277: ICE when building MPFR: in decide_alg, at config/i386/i386.c:22094

Package: gcc-snapshot Version: 2014-1 Severity: normal When building the future MPFR 3.1.0-p4 (but the patch level shouldn't matter here) with ../mpfr-3.1.0/configure --with-gmp=/usr/local/gmp-debug --enable-assert=full --enable-logging CC=gcc-snapshot CFLAGS='-Wall -O3 -march=native

Bug#630187: gcj-4.6-jre-lib: wrong dependencies

Package: gcj-4.6-jre-lib Version: 4.6.0-4 Severity: grave Justification: renders package unusable gcj-4.6-jre-lib 4.6.0-4 is not installable because it has the following dependencies: Depends: gcj-4.6-base (= 4.6.0-12), libgcj12 (= 4.6.0-12) The problem is that gcj-4.6-jre-lib, gcj-4.6-base and

Bug#626869: gcc-4.6: undefined reference to `_q_add' with -mabi=ieeelongdouble

On 2011-05-24 10:15:56 +0200, Matthias Klose wrote: On 05/16/2011 04:03 AM, Vincent Lefevre wrote: Package: gcc-4.6 Version: 4.6.0-2 ay:~ gcc-4.4 tst.c -o tst -mabi=ieeelongdouble reporting for 4.6 and testing with 4.4? IIRC I tested the different versions and did the report

Bug#626869: gcc-4.6: undefined reference to `_q_add' with -mabi=ieeelongdouble

Now with the latest gcc-4.6: ay:~ gcc-4.6 --version gcc-4.6 (Debian 4.6.0-7) 4.6.1 20110507 (prerelease) [...] ay:~ gcc-4.6 tst.c -o tst -mabi=ieeelongdouble cc1: warning: using IEEE extended precision long double [enabled by default] /tmp/cczFMB6p.o: In function `main': tst.c:(.text+0x84):

Bug#626869: gcc-4.6: undefined reference to `_q_add' with -mabi=ieeelongdouble

On 2011-05-24 17:35:24 +0200, Matthias Klose wrote: did that work in any earlier version? I could try only with gcc 4.4, 4.5 and 4.6, and none of them work. I don't know what to think about: https://www-304.ibm.com/support/docview.wss?rs=2030uid=swg21245006 -- Vincent Lefèvre

Bug#626869: gcc-4.6: undefined reference to `_q_add' with -mabi=ieeelongdouble

Package: gcc-4.6 Version: 4.6.0-2 Severity: normal I get the following error: ay:~ gcc-4.4 tst.c -o tst -mabi=ieeelongdouble cc1: warning: Using IEEE extended precision long double /tmp/cceTQS0o.o: In function `main': tst.c:(.text+0x84): undefined reference to `_q_add' collect2: ld returned 1

  1   2   >