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

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

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

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

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

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

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

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

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

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

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

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

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#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#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#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#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#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#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#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#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#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#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#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#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#458072: cpp-4.1: segmentation fault in cc1 due to infinite loop in error() when using -ftrapv

Package: cpp-4.1 Version: 4.1.1-21 Severity: normal I get the following segmentation fault: courge:...re/mpfr-2.3.1-rc1> gcc -DWANT_ASSERT=2 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DMPFR_HAVE_FESE

Bug#458072: cpp-4.1: segmentation fault in cc1 due to infinite loop in error() when using -ftrapv

On 2007-12-28 14:26:04 +0100, Martin Michlmayr wrote: > * Vincent Lefevre <[EMAIL PROTECTED]> [2007-12-28 13:51]: > > courge:...re/mpfr-2.3.1-rc1> gcc -DWANT_ASSERT=2 -DHAVE_INTTYPES_H=1 > > -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STDARG=1 > > -DHAVE_S

Bug#458072: cpp-4.1: segmentation fault in cc1 due to infinite loop in error() when using -ftrapv

merge 458072 405065 thanks On 2007-12-28 19:01:15 +0100, Martin Michlmayr wrote: > I can reproduce the problem with 4.1.1-21 from stable but not with > 4.1.2-18 from testing/unstable. So I think this has been fixed > upstream (it might be PR30286 but I'm not sure). I simplified the code and coul

Bug#471818: gcj-4.3: dangling symlink /usr/share/man/man1/gc-analyze.1.gz

Package: gcj-4.3 Version: 4.3.0-1 Severity: minor /usr/share/man/man1/gc-analyze.1.gz is a dangling symlink: vin% ls -l /usr/share/man/man1/gc-analyze.1.gz lrwxrwxrwx 1 root root 19 2008-03-17 02:46:40 /usr/share/man/man1/gc-analyze.1.gz -> gc-analyze-4.3.1.gz vin% ls -lL /usr/share/man/man1/gc-

Bug#487076: gcc-4.3-doc: "info gcc" gives the manual of gcc 3.3 (gcc-3.3.info) instead of the current version

Package: gcc-4.3-doc Version: 4.3.0.nf1-1 Severity: normal When I type "info gcc", I get the manual of gcc 3.3: File: gcc-3.3.info, Node: Top, Next: G++ and GCC, Up: (DIR) whereas I expect to get the manual of gcc 4.3 (which is the version of /usr/bin/gcc, in fact 4.3.1 whereas the manual is

Bug#470318: i387 versus SSE versus MPFR (gcc "bug")

On 2008-04-17 14:02:17 +0400, Alexei Sheplyakov wrote: > I don't think it's a bug. Rather, it's a wrong expectation from the > user side. You are comparing results of FP calculation done on 3 > different platforms: ix87, sse2, and MPFR, and expect them to be the > same. I think your expectation is

Bug#524472: gcc-4.3: gcc 4.3.2 miscompiles GMP 4.3.0

Package: gcc-4.3 Version: 4.3.2-1.1 Severity: important Tags: lenny When I build GMP 4.3.0 with gcc 4.3.2, I get the following errors in "make check": rootrem.c:338: GNU MP assertion failed: bn >= qn /bin/sh: line 4: 2231 Aborted (core dumped) ${dir}$tst FAIL: reuse rootrem.c:338

Bug#524472: gcc-4.3: gcc 4.3.2 miscompiles GMP 4.3.0

retitle 524472 gcc-4.3: gcc 4.3.2 strict-aliasing bug / miscompiles GMP 4.3.0 thanks I've tracked down the bug and managed to write a simple testcase: /* With GCC 4.3.2 and -O2 option: output value is 1 instead of 0. * If -fno-strict-aliasing is added, this bug disappears. */ #include #includ

Bug#524472: gcc-4.3: gcc 4.3.2 miscompiles GMP 4.3.0

retitle 524472 [PR tree-optimization/36765] gcc-4.3: gcc 4.3.2 strict-aliasing bug / miscompiles GMP 4.3.0 thanks I've added the upstream bug reference to the title, in case someone else wonders... -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Bug#533124: c99-gcc -I breaks POSIX conformance

Package: gcc Version: 4:4.3.3-8 Severity: normal POSIX.1-2008 says[*]: -I directory Change the algorithm for searching for headers whose names are not absolute pathnames to look in the directory named by the directory pathname before looking in the usual places. Thus, headers whose

Bug#533124: c99-gcc -I breaks POSIX conformance

I've submitted a RFE on GCC here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442 -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUB

Bug#539912: gcc-4.3: POSIX requires that option -D have a lower precedence than -U

Package: gcc-4.3 Version: 4.3.3-15 Severity: normal Note: this is a bug concerning the c99 utility, but since c99 uses gcc, I report the bug against gcc. Also note that both gcc-4.4 and gcc-snapshot have the same problem. I've also reported the bug on GCC's bugzilla: http://gcc.gnu.org/bugzilla/sh

Bug#609217: gcc-4.4-doc: misleading __builtin_choose_expr documentation error

Package: gcc-4.4-doc Version: 4.4.4.nf1-1 Severity: normal The GCC 4.4 manual says: -- Built-in Function: TYPE __builtin_choose_expr (CONST_EXP, EXP1, EXP2) You can use the built-in function `__builtin_choose_expr' to evaluate code depending on the value of a constant express

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#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 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#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#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#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#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#547165: gcj-jre contains nothing (contrary to its description)

Package: gcj-jre Version: 4:4.3.3-9 Severity: grave Justification: renders package unusable The description says: Description: Java runtime environment using GIJ/classpath GIJ is a Java bytecode interpreter, not limited to interpreting bytecode. It includes a class loader which can dynamically

Bug#547170: java-gcj-compat-headless depends on a transitional package (gij)

Package: java-gcj-compat-headless Version: 1.0.80-5.1 Severity: wishlist java-gcj-compat-headless depends on gij: Depends: java-common (>= 0.25), gij (>= 4:4.3), fastjar, libgcj-bc (>= 4.3), libgcj9-jar (>= 4.3), libmx4j-java (>= 3.0.1), libgcj-common (>= 1:4.4.0-2) which is a transitional pack

Bug#547170: java-gcj-compat-headless depends on a transitional package (gij)

On 2009-09-17 15:04:53 +0200, Matthias Klose wrote: > tags 547170 + wontfix > thanks > > no, won't fix anything. java-gcj-compat is obsolete as well. Then why doesn't aptitude list them as obsolete? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

  1   2   >