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

Hi Paul, On 2025-03-23 11:17:52 +0100, Paul Gevers wrote: > Hi Vincent, > > On Fri, 15 Dec 2023 04:53:51 +0100 Vincent Lefevre > wrote: > > On 2023-12-03 22:13:03 +0100, Vincent Lefevre wrote: > > > I've reported the following bug in the MPFR mailing-list. I thin

Bug#1078158: gcc-doc-defaults: switch to GCC 14

On 2024-08-07 15:13:52 +0200, Andreas Beckmann wrote: > gcc-doc-defaults started to FTBFS when the default compiler has been > switched to GCC 14. Please update the doc package to GCC 14, too. But gcc-14-doc is not available in Debian yet. -- Vincent Lefèvre - Web: 100

Bug#929777: Bug#1076503: Removed package(s) from unstable

On 2024-07-28 15:35:35 +, Debian FTP Masters wrote: > Version: 10.5.0-4+rm > > Dear submitter, > > as the package gcc-10 has just been removed from the Debian archive > unstable we hereby close the associated bug reports. We are sorry > that we couldn't deal with your issue properly. [...]

Bug#930430: Bug#1076502: Removed package(s) from unstable

Control: reopen -1 Control: reassign -1 libasan8 14.1.0-5 On 2024-07-28 15:27:28 +, Debian FTP Masters wrote: > Version: 9.5.0-6+rm > > Dear submitter, > > as the package gcc-9 has just been removed from the Debian archive > unstable we hereby close the associated bug reports. We are sorry

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

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_vaspr

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 i

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

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 th

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

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 mpf

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 mac

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 Comp

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) { i

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

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, ENS-Ly

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 segfaul

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 pat

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 /usr/lib/gcc/x8

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’: tst.c:3:3:

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, > >in c

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 by

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 li

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 de

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

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/ mpfr-(.+)

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 va

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 /var/lib/dpkg/info

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&arch=kfreebsd-i386&v

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 (libmpfr6_4.0.1

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: CR INRIA - computer a

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'), (500

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; > } &g

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 PATH=/usr/lib/gcc

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

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

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

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 t

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: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=8828

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 cha

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. > /usr/bin

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 versionin

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: Work: CR INRIA -

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 Lefèvre

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

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 po

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 / AriC project (LIP, EN

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 /usr/lib/x86_

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

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 th

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

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 provide

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 lib

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 reproducible

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, ENS-Lyon)

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 e

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 Al

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 "((!asan_init_is_

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 libr

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 / AriC project (LIP, ENS-L

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 \ --with-pkgversion='$(

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

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

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

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 1049

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 h

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 fun

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.

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

Control: found -1 20141118-1 This one is actually affected too (I didn't notice it before due to another bug). On 2014-12-11 00:32:37 +0100, Matthias Klose wrote: > Control: forwarded -1 https://gcc.gnu.org/PR64255 [...] > thanks for following upstream. Would it be possible to set the forwarded t

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

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 /usr/local/incl

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 prepr

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 - Web: 100% accessible validated (X)HTML -

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

retitle 681076 gcc-4.7: gcov can call format_gcov with top > bottom, which is unexpected and gives 99.99% tags 681076 upstream thanks On 2012-07-10 15:17:00 +0200, Vincent Lefevre wrote: > I have the following problem with gcov: > > ypig:/tmp/ompfr-gcov/src> gcov

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 executed:100

Bug#670164: ICE: Segmentation fault when compiling MPFR's set_f.c

tags 670164 fixed-upstream patch thanks I've attached the patch from upstream (only the fix, not the testcase). I've checked that it solves the problem. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - co

Bug#670264: gcc-snapshot: should be buildable with binutils-gold installed

Package: gcc-snapshot Version: 20120407-1 Severity: wishlist I can't build gcc-snapshot if binutils-gold is installed: ypig:...snapshot-20120407> dpkg-buildpackage -b -uc dpkg-buildpackage: source package gcc-snapshot dpkg-buildpackage: source version 20120407-1 dpkg-buildpackage: source changed

Bug#670164: ICE: Segmentation fault when compiling MPFR's set_f.c

tags 670164 upstream forwarded 670164 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52639 thanks Here's a simple testcase: // /usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.8.0/cc1 -fpreprocessed ice-setf.i -march=corei7 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm -mno-l

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

  1   2   >