Bug#1065603: libdebuginfod1t64 dependency problem breaks the upgrade

[Vincent Lefevre]

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 libdebuginfod-common:
>  libdebuginfod1t64:amd64 depends on libdebuginfod-common (>= 0.190-1.1).
> 
> dpkg: error processing package libdebuginfod-common (--purge):
>  dependency problems - not removing
> (Reading database ... 655945 files and directories currently installed.)
> Errors were encountered while processing:
>  libdebuginfod-common

Well, the issue just seems to be a dpkg failure. "apt install -f"
shows nothing to fix.

So I'm wondering why dpkg wanted to remove libdebuginfod-common.

FYI, I did the upgrade via aptitude, and this package wasn't proposed
for removal. In /var/log/aptitude, after discarding the HOLD lines
(which correspond to no changes for these packages):

Aptitude 0.8.13: log report
Thu, Mar  7 2024 11:24:24 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 15 packages, and remove 6 packages.
5096 kB of disk space will be freed

[...]
[INSTALL, DEPENDENCIES] libasm1t64:amd64 0.190-1.1
[INSTALL, DEPENDENCIES] libdebuginfod1t64:amd64 0.190-1.1
[INSTALL, DEPENDENCIES] libdw1t64:amd64 0.190-1.1
[INSTALL, DEPENDENCIES] libelf1t64:amd64 0.190-1.1
[INSTALL, DEPENDENCIES] libglib2.0-0t64:amd64 2.78.4-3
[REMOVE, DEPENDENCIES] libasm1:amd64 0.190-1+b1
[REMOVE, DEPENDENCIES] libdebuginfod1:amd64 0.190-1+b1
[REMOVE, DEPENDENCIES] libdw1:amd64 0.190-1+b1
[REMOVE, DEPENDENCIES] libelf1:amd64 0.190-1+b1
[REMOVE, DEPENDENCIES] libglib2.0-0:amd64 2.78.4-1
[REMOVE, DEPENDENCIES] libglib2.0-0-dbgsym:amd64 2.78.4-1
[...]
[UPGRADE] elfutils:amd64 0.190-1+b1 -> 0.190-1.1
[UPGRADE] gir1.2-freedesktop:amd64 1.78.1-15 -> 1.78.1-16
[UPGRADE] gir1.2-freedesktop-dev:amd64 1.78.1-15 -> 1.78.1-16
[UPGRADE] gir1.2-girepository-2.0:amd64 1.78.1-15 -> 1.78.1-16
[UPGRADE] gir1.2-glib-2.0:amd64 1.78.1-15 -> 1.78.1-16
[UPGRADE] gir1.2-glib-2.0-dev:amd64 1.78.1-15 -> 1.78.1-16
[UPGRADE] libelf-dev:amd64 0.190-1+b1 -> 0.190-1.1
[UPGRADE] libglib2.0-bin:amd64 2.78.4-1 -> 2.78.4-3
[UPGRADE] libglib2.0-dev:amd64 2.78.4-1 -> 2.78.4-3
[UPGRADE] libglib2.0-dev-bin:amd64 2.78.4-1 -> 2.78.4-3


-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1065603: libdebuginfod1t64 dependency problem breaks the upgrade

[Vincent Lefevre]

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-common (--purge):
 dependency problems - not removing
(Reading database ... 655945 files and directories currently installed.)
Errors were encountered while processing:
 libdebuginfod-common

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libdebuginfod1t64 depends on:
ii  libc6 2.37-15.1
ii  libcurl3t64-gnutls [libcurl3-gnutls]  8.6.0-3.2
pn  libdebuginfod-common  
ii  libdw1t64 0.190-1.1
ii  libelf1t640.190-1.1

libdebuginfod1t64 recommends no packages.

libdebuginfod1t64 suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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

The gmp_vasprintf function is actually correct (but its documentation
is not; and it is gmp_sprintf that is incorrect, which is not a
problem for MPFR). I've fixed the remaining bugs in MPFR.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 issues on the MPFR side in master, but MPFR is still
affected by the bug on the GMP side (gmp_vasprintf):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057344

The vasprintf.c code (for the formatted output functions) does not
handle null characters correctly. These characters can occur by
using %c with the value 0.

This is shown by the check_null tsprintf.c test:

  
https://gitlab.inria.fr/mpfr/mpfr/-/commit/78e72e6538fabc1b720d97e862ec45354e5c9c3f

The possible consequences are:
  - possible memory corruption with custom memory allocators that
do not ignore the size parameter of the "free" function;
  - a part of the buffer fails to be overwritten (with possible
security issues if the buffer contains sensitive data that
were expected to be overwritten);
  - an assertion failure when GNU MPFR has been configured with
assertion checking (--enable-assert).

Note that some of these issues partly come from a bug in gmp_vasprintf
(such as the incorrect return value), which I've reported here:

  https://gmplib.org/list-archives/gmp-bugs/2023-December/005420.html

I think that I have fixed these issues on the MPFR side with

  
https://gitlab.inria.fr/mpfr/mpfr/-/commit/390e51ef8570da4e338e9806ecaf2d022210d951

but the first two consequences remain due to the gmp_vasprintf bug.

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-13-amd64 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmpfr6 depends on:
ii  libc6 2.36-9+deb12u3
ii  libgmp10  2:6.2.1+dfsg1-1.1

libmpfr6 recommends no packages.

libmpfr6 suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 that the info file may already be available
> in the source tree (this is always the case for tarballs), so that
> there could be some confusion. We're using
> 
> info_TEXINFOS = mpfr.texi
> 
> and the Makeinfo manual says:
> 
>It is worth noting that, contrary to what happens with the other
> formats, the generated ‘.info’ files are by default placed in ‘srcdir’
> rather than in the ‘builddir’.  This can be changed with the
> ‘info-in-builddir’ option.
> 
> So the question is whether we should use this option. Is it common
> among other software?

According to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034#65
we must not use info-in-builddir if we distribute info files
(in tarballs). Since distributing them is recommended (as not
everyone has the necessary tools to rebuild them), we will not
be able to use info-in-builddir.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 that the info file may already be available
in the source tree (this is always the case for tarballs), so that
there could be some confusion. We're using

info_TEXINFOS = mpfr.texi

and the Makeinfo manual says:

   It is worth noting that, contrary to what happens with the other
formats, the generated ‘.info’ files are by default placed in ‘srcdir’
rather than in the ‘builddir’.  This can be changed with the
‘info-in-builddir’ option.

So the question is whether we should use this option. Is it common
among other software?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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, produced by makeinfo version 6.8 from mpfr.texi.
+This is mpfr.info, produced by makeinfo version 7.0.3 from mpfr.texi.
 This manual documents how to install and use the Multiple Precision
 Floating-Point Reliable Library, version 4.2.0.

Apparently this is due to the fact that the upstream mpfr.info file
is rebuilt.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 mpfr_rec_sqrt function may yield a stack overflow due to many
  small allocations in the stack, based on alloca(). This occurs on
  cases that are very hard to round. In practice, to build such cases,
  the precision of the input needs to be large enough (e.g. around
  10 bits).
* MPFR can crash when a formatted output function is called with
  %.2147483648Rg in the format string (2147483648 = 2^31).

See attached files for simple testcases (but the patches provide
testcases for the testsuite).

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 
'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 
'testing'), (500, 'stable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmpfr6 depends on:
ii  libc6 2.36-9
ii  libgmp10  2:6.2.1+dfsg1-1.1

libmpfr6 recommends no packages.

libmpfr6 suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
#include 
#include 
#include 

int main (void)
{
  mpfr_exp_t emax_max;
  mpfr_t x;

  emax_max = mpfr_get_emax_max ();

  if (mpfr_set_emax (emax_max))
{
  fprintf (stderr, "ui_pow_ui-overflow error: mpfr_set_emax failed\n");
  return 1;
}

  mpfr_init2 (x, 8);

  /* The purpose of this test is more to check that mpfr_ui_pow_ui
 terminates (without taking much memory) rather than checking
 the value of x. On 2023-02-13, the +Inf case was not handled
 in the Ziv iteration, yielding an infinite loop, affecting
 mpfr_log10 in particular. See
   commit 90de094f0d9c309daca707aa227470d810866616
  */
  mpfr_ui_pow_ui (x, 5, ULONG_MAX, MPFR_RNDN);
  if (emax_max <= ULONG_MAX  /* true with default _MPFR_EXP_FORMAT */
  && ! mpfr_inf_p (x))
{
  fprintf (stderr, "ui_pow_ui-overflow error");
  printf ("ui_pow_ui-overflow: expected +Inf, got ");
  mpfr_dump (x);
  return 1;
}

  mpfr_clear (x);

  return 0;
}
#include 
#include 

int main (void)
{
  mpfr_t x, y;
  int inex;

  mpfr_init2 (x, 123456);
  mpfr_init2 (y, 4);
  mpfr_set_ui (y, 9, MPFR_RNDN);
  mpfr_ui_div (x, 1, y, MPFR_RNDN);
  inex = mpfr_rec_sqrt (y, x, MPFR_RNDN);
  /* Let's also check the result, though this is not the real purpose
 of this test (a stack overflow just makes the program crash).
 1/9 = 0.111000111000111000111000111000111000...E-3 and since the
 precision 123456 is divisible by 6, x > 1/9. Thus 1/sqrt(x) < 3. */
  if (mpfr_nan_p (y) || mpfr_cmp_ui (y, 3) != 0 || inex <= 0)
{
  printf ("mpfr_rec_sqrt error: expected 3 with inex > 0, got ");
  mpfr_out_str (stdout, 10, 0, y, MPFR_RNDN);
  printf (" with inex=%d\n", inex);
  return 1;
}
  mpfr_clear (x);
  mpfr_clear (y);

  return 0;
}
#include 
#include 

int main (void)
{
  mpfr_t x;
  char buf1[3] = "xxx", buf2[3] = "xxx";
  int r;

  mpfr_init2 (x, 128);
  mpfr_set_ui (x, 1, MPFR_RNDN);

  r = mpfr_snprintf (NULL, 0, "%.2147483648Rg\n", x);
  if (r != 2 && r >= 0)
return 1;

  r = mpfr_snprintf (buf1, sizeof(buf1), "%.2147483648Rg\n", x);
  if (r != 2 && r >= 0)
return 2;
  if (r >= 0 && (buf1[0] != '1' || buf1[1] != '\n' || buf1[2] != 0))
return 3;

  r = mpfr_sprintf (buf2, "%.2147483648Rg\n", x);
  if (r != 2 && r >= 0)
return 4;
  if (r >= 0 && (buf2[0] != '1' || buf2[1] != '\n' || buf2[2] != 0))
return 5;

  mpfr_clear (x);
  return 0;
}

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

[Vincent Lefevre]

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 << b;
  b -= n;
}
}

gcc-12 emits the following incorrect warning:

$ gcc-12 -fanalyzer -c warn-shiftcount.c
warn-shiftcount.c: In function ‘f’:
warn-shiftcount.c:8:22: warning: shift by count (‘64’) >= precision of type 
(‘6’) [-Wanalyzer-shift-count-overflow]
8 | p[i--] = 1UL << b;
  |  ^~~~
  ‘f’: events 1-5
|
|5 |   while (i >= 0 && b >= 0)
|  |  ~~~^
|  | |
|  | (1) following ‘true’ branch...
|6 | {
|7 |   if (b <= n)
|  |  ~   
|  |  |
|  |  (2) ...to here
|  |  (3) following ‘true’ branch (when ‘b <= n’)...
|8 | p[i--] = 1UL << b;
|  |   ~~~
|  || |
|  || (5) shift by count ‘64’ here
|  |(4) ...to here
|

Here, due to the "n = r % 64", one has n <= 63, so that "1UL << b"
can be executed only when b <= 63, and the shift is necessarily valid
(no overflow).

Note: gcc-11 is affected too, but not gcc-10.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-12 depends on:
ii  binutils   2.40-2
ii  cpp-12 12.2.0-14
ii  gcc-12-base12.2.0-14
ii  libc6  2.36-8
ii  libcc1-0   12.2.0-14
ii  libgcc-12-dev  12.2.0-14
ii  libgcc-s1  12.2.0-14
ii  libgmp10   2:6.2.1+dfsg1-1.1
ii  libisl23   0.25-1
ii  libmpc31.3.1-1
ii  libmpfr6   4.2.0-1
ii  libstdc++6 12.2.0-14
ii  libzstd1   1.5.4+dfsg2-3
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages gcc-12 recommends:
ii  libc6-dev  2.36-8

Versions of packages gcc-12 suggests:
ii  gcc-12-doc   12.2.0-1
ii  gcc-12-locales   12.2.0-14
ii  gcc-12-multilib  12.2.0-14

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1027284: mpfr_custom_get_kind broken in current 4.1.1

[Vincent Lefevre]

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 macro definition of
> mpfr_custom_get_kind that prevents building against CGAL.
> 
> Looks like the package needs to be refreshed with the updated upstream's
> version or apply the patch[0] independently.
> 
> [0] 
> https://github.com/BrianGladman/mpfr/commit/0ce17bae34a6c54de31b126f969d3ddd72c6bc37

There's no newer version for the 4.1 branch. So I suggest one of
these 3 possibilities:

1. Apply the patch available on https://www.mpfr.org/mpfr-4.1.1/#bugs

2. Apply the patch from the git commit 0ce17bae34a6c54de31b126f969d3ddd72c6bc37

3. Upgrade to 4.2.0-rc1 (this version is ABI and API compatible and
has the fix for this bug). I will do the release in a few days, as
everything seems fine (there's only a possible failure on m68k with
QEMU, but after investigation, this is due to a QEMU bug, and the
generated code should be correct; BTW, the 4.1.* versions also have
the concerned test).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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

Compare with gcc-12:

$ gcc-12
gcc-12: fatal error: no input files
compilation terminated.

And "gcc-snapshot -v" also fails with the same error (which may
trigger a failure in scripts that use this option).

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-snapshot depends on:
ii  amdgcn-tools13
ii  binutils2.38.50.20220629-2
ii  lib32z1 1:1.2.11.dfsg-4
ii  libc6   2.33-7
ii  libc6-dev   2.33-7
ii  libc6-dev-i386  2.33-7
ii  libc6-dev-x32   2.33-7
ii  libc6-i386  2.33-7
ii  libc6-x32   2.33-7
ii  libgc1  1:8.0.6-1.1
ii  libgmp102:6.2.1+dfsg1-1
ii  libisl230.24-2
ii  libmpc3 1.2.1-2
ii  libmpfr64.1.0-3
ii  libzstd11.5.2+dfsg-1
ii  nvptx-tools 0.20180301-1
ii  python3 3.10.4-1+b1
ii  zlib1g  1:1.2.11.dfsg-4

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.38.50.20220629-2

-- no debconf information

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

[Vincent Lefevre]

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

Bug#539912: reopen

[Vincent Lefevre]

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

[Vincent Lefevre]

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)
{
  if (b <= n)
p[i--] = 1UL << b;
  b -= n;
}
}

gives:

warn-shiftcount.c: In function ‘f’:
warn-shiftcount.c:8:22: warning: shift by count (‘64’) >= precision of type 
(‘6’) [-Wanalyzer-shift-count-overflow]
8 | p[i--] = 1UL << b;
  |  ^~~~
  ‘f’: events 1-5
|
|5 |   while (i >= 0 && b >= 0)
|  |  ~~~^
|  | |
|  | (1) following ‘true’ branch...
|6 | {
|7 |   if (b <= n)
|  |  ~   
|  |  |
|  |  (2) ...to here
|  |  (3) following ‘true’ branch (when ‘b <= n’)...
|8 | p[i--] = 1UL << b;
|  |   ~~~
|  || |
|  || (5) shift by count ‘64’ here
|  |(4) ...to here

This warning is incorrect, since 1UL << b is in the "if" branch,
where b <= n and n <= 63 (thus b <= 63).

No such issue with gcc-10 and before.

This makes testing of GNU MPFR fail (this testcase was derived from
GNU MPFR's random2.c).

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-11 depends on:
ii  binutils   2.37-4
ii  cpp-11 11.2.0-3
ii  gcc-11-base11.2.0-3
ii  libc6  2.31-17
ii  libcc1-0   11.2.0-3
ii  libgcc-11-dev  11.2.0-3
ii  libgcc-s1  11.2.0-3
ii  libgmp10   2:6.2.1+dfsg-1
ii  libisl23   0.23-1
ii  libmpc31.2.0-1
ii  libmpfr6   4.1.0-3
ii  libstdc++6 11.2.0-3
ii  libzstd1   1.4.8+dfsg-2.1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages gcc-11 recommends:
ii  libc6-dev  2.31-17

Versions of packages gcc-11 suggests:
pn  gcc-11-doc   
ii  gcc-11-locales   11.2.0-3
ii  gcc-11-multilib  11.2.0-3

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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

I've found the cause and proposed a patch, which has been committed
in master:

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=929f2cf4105ccf12d0684c6d5838f58f0ee5e7c7

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 non-zero exit status
> as usual.

gcc-10 now outputs an error message when running the program, e.g.

libgcov profiling error:dir/#home#vlefevre#tst.gcda:Error writing

but the exit status is still 0, which is an issue for scripts.

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

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#539912: now in gcc-10

[Vincent Lefevre]

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

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

[Vincent Lefevre]

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 segfault outright, but I think that's
> unrelated.)
> 
> One can build the program below with -lflint-arb to link:
> #include 
> #include 
> int main(void) {
> arb_t x;
> arb_init(x);
> if(arb_set_str(x, "0", WORD_MAX)) {
> exit(EXIT_FAILURE);
> } else {
> arb_printd(x, WORD_MAX);
> arb_clear(x);
> }
> }
> 
> and this causes
> ../../src/init2.c:52: MPFR assertion failed: ((p) >= 1 && (p) <= 
> ((mpfr_prec_t) mpfr_uprec_t) -1) >> 1) - 256)))
> Aborted

This is not a MPFR bug: a precision that is larger than MPFR_PREC_MAX
is provided. In the MPFR manual:

   The “precision” is the number of bits used to represent the
significand of a floating-point number; the corresponding C data type is
‘mpfr_prec_t’.  The precision can be any integer between ‘MPFR_PREC_MIN’
and ‘MPFR_PREC_MAX’.  In the current implementation, ‘MPFR_PREC_MIN’ is
equal to 1.

   Warning!  MPFR needs to increase the precision internally, in order
to provide accurate results (and in particular, correct rounding).  Do
not attempt to set the precision to any value near ‘MPFR_PREC_MAX’,
otherwise MPFR will abort due to an assertion failure.  However, in
practice, the real limitation will probably be the available memory on
your platform, and in case of lack of memory, the program may abort,
crash or have undefined behavior (depending on your C implementation).

> It seems this is related to the WORD_MAX limit in arb_printd(). Replacing
> it with WORD_MAX/8 one gets (in GMP)
> GNU MP: Cannot allocate memory (size=479903576292600072)
> Aborted

This time, I assume that the MPFR precision is less than MPFR_PREC_MAX,
but this is still much too large for the available memory.

This looks like a user-side error. I suppose that in arb, WORD_MAX
is a technical limitation (like MPFR_PREC_MAX in MPFR), but other
limitations may be reached in practice (on 64-bit machines, the
available memory should be the real limitation, though various
technical limitations may be reached before you get an error on
the available memory).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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
# 32 "" 2
# 1 "tst.c"
# 1 "/usr/include/limits.h" 1 3 4
[...]

There is no /usr/lib/gcc/x86_64-linux-gnu/9/include-fixed directory.

This could actually be a bug in libgcc-9-dev, as libgcc-8-dev
provides "/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed/limits.h".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 path in which to search for 
limits.h
  124 | # include_next 
  |  ^

or directly with "cpp-9 tst.c".

Since this issue does not occur with other GCC versions, I suppose
that this is a bug in cpp-9, not in libc6-dev.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cpp-9 depends on:
ii  gcc-9-base  9.3.0-1
ii  libc6   2.30-2
ii  libgmp102:6.2.0+dfsg-4
ii  libisl220.22.1-1
ii  libmpc3 1.1.0-1
ii  libmpfr64.0.2-1
ii  zlib1g  1:1.2.11.dfsg-2

cpp-9 recommends no packages.

Versions of packages cpp-9 suggests:
ii  gcc-9-locales  9.3.0-1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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/x86_64-linux-gnu/4.9/libgcc_s.so

which is a symbolic link to

  /lib/x86_64-linux-gnu/libgcc_s.so.1

but this file have moved to /lib.

The usual paths are searched too, so that alternatively, I think that
a libgcc_s.so -> libgcc_s.so.1 symbolic link in /lib could solve the
issue, if acceptable.

gcc-4.9 is rather old, but still useful for testing, and there was
no announce of any change.

In the mean time, a workaround is to add a symlink

/usr/local/lib/libgcc_s.so -> /lib/libgcc_s.so.1

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgcc1 depends on:
ii  gcc-10-base  10-20200204-1
ii  libc62.29-10
ii  libgcc-s110-20200204-1

libgcc1 recommends no packages.

libgcc1 suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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

Package: gcc-snapshot
Version: 1:20200124-1
Installed-Size: 3067842

So both the .deb size and the install size have almost tripled!

According to a diff, this is apparently due to some executables from
/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/10, which now have
debug info and are no longer stripped, making them 10 times as big.

With gcc-snapshot 1:20191130-1, I get:

-rwxr-xr-x 1 30M 2019-11-30 08:57:40 cc1*
-rwxr-xr-x 1 31M 2019-11-30 08:57:40 cc1obj*
-rwxr-xr-x 1 33M 2019-11-30 08:57:40 cc1plus*
-rwxr-xr-x 1 31M 2019-11-30 08:57:40 f951*
-rwxr-xr-x 1 31M 2019-11-30 08:57:40 go1*
-rwxr-xr-x 1 29M 2019-11-30 08:57:40 lto1*

cc1: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically 
linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=48082c3df2f3c926a3c027af59e2906f7c24225f, for GNU/Linux 3.2.0, 
stripped

With gcc-snapshot 1:20200124-1, I get:

-rwxr-xr-x 1 311M 2020-01-24 12:01:06 cc1*
-rwxr-xr-x 1 315M 2020-01-24 12:01:06 cc1obj*
-rwxr-xr-x 1 342M 2020-01-24 12:01:06 cc1plus*
-rwxr-xr-x 1 310M 2020-01-24 12:01:06 f951*
-rwxr-xr-x 1 335M 2020-01-24 12:01:06 go1*
-rwxr-xr-x 1 297M 2020-01-24 12:01:06 lto1*

cc1: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically 
linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=27e3f615a396668fe72d9e30bbaaf055ccf5660f, for GNU/Linux 3.2.0, 
with debug_info, not stripped

Since the Debian changelog just says

gcc-snapshot (1:20200124-1) unstable; urgency=medium

  * Snapshot, taken from the trunk (20200124).

 -- Matthias Klose   Fri, 24 Jan 2020 12:01:06 +0100

I suppose that this change can be a mistake.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-snapshot depends on:
ii  binutils2.33.90.20200122-2
ii  lib32z1 1:1.2.11.dfsg-1+b1
ii  libc6   2.29-9
ii  libc6-dev   2.29-9
ii  libc6-dev-i386  2.29-9
ii  libc6-dev-x32   2.29-9
ii  libc6-i386  2.29-9
ii  libc6-x32   2.29-9
ii  libgc1c21:7.6.4-0.4
ii  libgmp102:6.1.2+dfsg-4
ii  libisl220.22-2
ii  libmpc3 1.1.0-1
ii  libmpfr64.0.2-1
ii  libzstd11.4.4+dfsg-1
ii  python3 3.7.5-3
ii  zlib1g  1:1.2.11.dfsg-1+b1

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.33.90.20200122-2

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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: error: unknown type name ‘_Decimal64’
3 |   _Decimal64 x = 1;
  |   ^~

There is no such issue with gcc-snapshot (_Decimal64 is not a
forbidden extension):

$ gcc-snapshot -std=c11 tst.c -o tst
$ gcc-snapshot -std=c11 -pedantic tst.c -o tst
tst.c: In function 'main':
tst.c:3:3: warning: ISO C does not support decimal floating-point before C2X 
[-Wpedantic]
3 |   _Decimal64 x = 1;
  |   ^~

The GCC 9.2.0 manual does not mention a possible limitation.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-9 depends on:
ii  binutils  2.33.50.20200107-1
ii  cpp-9 9.2.1-22
ii  gcc-9-base9.2.1-22
ii  libc6 2.29-8
ii  libcc1-0  9.2.1-22
ii  libgcc-9-dev  9.2.1-22
ii  libgcc1   1:9.2.1-22
ii  libgmp10  2:6.1.2+dfsg-4
ii  libisl22  0.22-2
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.2-1
ii  libstdc++69.2.1-22
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages gcc-9 recommends:
ii  libc6-dev  2.29-8

Versions of packages gcc-9 suggests:
ii  gcc-9-doc   9.2.0-2
ii  gcc-9-locales   9.2.1-22
ii  gcc-9-multilib  9.2.1-22

-- no debconf information

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

[Vincent Lefevre]

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 case this matters). If the programs honors the system ABI, this
> >is allowed, and you'll effectively test the new libstdc++6.
> 
> No, if the rebuild rebuilds cppunittester or one of the
> exceptionprotectors or the smoketest so or similar we are at the
> same situation as with the autopkgtest (that's what it builds) and
> are not sure whether it's g++-9 or libstdc++6. Neither LO nor the
> test are an executable it's a executable with gazillions of .sos.

I meant running the generated program (smoketest) without rebuilding
it:

1. Build smoketest with the old g++-9 / libstdc++6.
2. Upgrade g++-9 / libstdc++6.
3. Run smoketest directly.

(I assume that the smoketest executable does not invoke g++-9 to
rebuild things on the fly.)

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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
> >>with an older gcc-9 version, upgrade libstdc++6, and run the test
> >>again (without rebuilding it), does it fail?
> >
> >This is impossible. This is a C++ unit test and the stuff assumes too
> >much of the build tree. You need to actually build the test libs etc to
> >run it. 
> >
> >That is why autopkgtest does only smoketest [...]
> 
> Well, thinking about it it might be possible. Build on testing,
> debian/tests/smoketest, dist-upgrade to did and rerun it and hope
> some makefile magic doesn't trigger some rebuild...

In case makefile magic triggers some rebuild, you can also run the
generated executable directly (with the right environment variables,
in case this matters). If the programs honors the system ABI, this
is allowed, and you'll effectively test the new libstdc++6.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 some new optimization or other change in the compiler.

That said, when seeing a new failure with a new GCC version for MPFR,
in (almost) all cases, this was due to a bug in GCC (after I spent
some time to build a simple testcase). But note that I also test MPFR
with sanitizer options, so that if there is some UB in MPFR, I would
probably notice it first.

I notice that this bug is assigned to libstdc++6. Do you think that
it is a library issue rather than a compiler issue? If you build LO
with an older gcc-9 version, upgrade libstdc++6, and run the test
again (without rebuilding it), does it fail?

If this is due to the compilation step, I would suggest to check LO
with sanitizer options. I also notice that the logs show the that
-fno-enforce-eh-specs option is used, which might also hide issues,
I suppose.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 list; you should 
either link runtime to your application or manually preload it with LD_PRELOAD.

Note also that this isn't even documented.

BTW, in my case (LD_PRELOAD=libgtk3-nocsd.so.0), libgtk3-nocsd.so.0
is completely unrelated to the program, thus this is a spurious
error.

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libasan5 depends on:
ii  gcc-8-base  8.3.0-7
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-7
ii  libstdc++6  8.3.0-7

libasan5 recommends no packages.

libasan5 suggests no packages.

-- no debconf information

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

[Vincent Lefevre]

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 detected. Well, "gcc -fprofile-use" outputs a warning,
but that's all.

Write failures should be detected, and when this happens,
the program should terminate with a non-zero exit status
as usual.

-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/64 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-6 depends on:
ii  binutils  2.28-5
ii  cpp-6 6.3.0-18+deb9u1
ii  gcc-6-base6.3.0-18+deb9u1
ii  libc6 2.24-11+deb9u4
ii  libcc1-0  6.3.0-18+deb9u1
ii  libgcc-6-dev  6.3.0-18+deb9u1
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgmp10  2:6.1.2+dfsg-1
ii  libisl15  0.18-1
ii  libmpc3   1.0.3-1+b2
ii  libmpfr4  3.1.5-1
ii  libstdc++66.3.0-18+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages gcc-6 recommends:
ii  libc6-dev  2.24-11+deb9u4

Versions of packages gcc-6 suggests:
pn  gcc-6-doc 
pn  gcc-6-locales 
ii  gcc-6-multilib6.3.0-18+deb9u1
pn  libasan3-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

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

[Vincent Lefevre]

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:
> > 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   --mode=link gcc  -O0 -march=native 
> -fsanitize=address -static-libasan   -version-info 6:0:0 
> -Wl,--disable-new-dtags -o libmpfr.la -rpath /usr/local/lib [.lo files]  -lgmp
> libtool: link: gcc -shared  -fPIC -DPIC  [.o files]  -lgmp  -O0 -march=native 
> -fsanitize=address -Wl,--disable-new-dtags   -Wl,-soname -Wl,libmpfr.so.6 -o 
> .libs/libmpfr.so.6.0.0
> 
> Why does libtool do that, while it preserves
> "-O0 -march=native -fsanitize=address"?

I can see that the libtool script contains:

  # Flags to be passed through unchanged, with rationale:
  # -64, -mips[0-9]  enable 64-bit mode for the SGI compiler
  # -r[0-9][0-9]*specify processor for the SGI compiler
  # -xarch=*, -xtarget=* enable 64-bit mode for the Sun compiler
  # +DA*, +DD*   enable 64-bit mode for the HP compiler
  # -q*  compiler args for the IBM compiler
  # -m*, -t[45]*, -txscale* architecture-specific flags for GCC
  # -F/path  path to uninstalled frameworks, gcc on darwin
  # -p, -pg, --coverage, -fprofile-*  profiling flags for GCC
  # -fstack-protector*   stack protector flags for GCC
  # @fileGCC response files
  # -tp=*Portland pgcc target processor selection
  # --sysroot=*  for sysroot support
  # -O*, -g*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time 
optimization
  # -specs=* GCC specs files
  # -stdlib=*select c++ std lib with clang
  # -fsanitize=* Clang/GCC memory and address sanitizer
  # -fuse-ld=*   Linker select flags for GCC
  -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
  -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| 
\
  -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| 
\
  -specs=*|-fsanitize=*|-fuse-ld=*)
func_quote_for_eval "$arg"
arg=$func_quote_for_eval_result
func_append compile_command " $arg"
func_append finalize_command " $arg"
func_append compiler_flags " $arg"
continue
;;

i.e. it misses the -static-libasan flag.

Reassigning to libtool.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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   --mode=link gcc  -O0 -march=native 
-fsanitize=address -static-libasan   -version-info 6:0:0 
-Wl,--disable-new-dtags -o libmpfr.la -rpath /usr/local/lib [.lo files]  -lgmp
libtool: link: gcc -shared  -fPIC -DPIC  [.o files]  -lgmp  -O0 -march=native 
-fsanitize=address -Wl,--disable-new-dtags   -Wl,-soname -Wl,libmpfr.so.6 -o 
.libs/libmpfr.so.6.0.0

Why does libtool do that, while it preserves
"-O0 -march=native -fsanitize=address"?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 been used, there is still a dynamic libasan,
as shown by ldd on a test program:

libasan.so.5 => /usr/lib/x86_64-linux-gnu/libasan.so.5 
(0x7fdcf052d000)

This may be the cause of the issue.

If there is a limitation (due to the use of other shared libraries?),
this should be mentioned in the gcc man page and manual.

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-8 depends on:
ii  binutils  2.31.1-16
ii  cpp-8 8.3.0-7
ii  gcc-8-base8.3.0-7
ii  libc6 2.28-9
ii  libcc1-0  8.3.0-7
ii  libgcc-8-dev  8.3.0-7
ii  libgcc1   1:8.3.0-7
ii  libgmp10  2:6.1.2+dfsg-4
ii  libisl19  0.20-2
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.2-1
ii  libstdc++68.3.0-7
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages gcc-8 recommends:
ii  libc6-dev  2.28-9

Versions of packages gcc-8 suggests:
pn  gcc-8-doc 
ii  gcc-8-locales 8.3.0-7
ii  gcc-8-multilib8.3.0-7
pn  libasan5-dbg  
pn  libatomic1-dbg
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan1-dbg 

-- no debconf information

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

[Vincent Lefevre]

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-(.+).tar.gz

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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

[Vincent Lefevre]

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 validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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/gcc-snapshot.prerm, which contains:

find /usr/lib/gcc-snapshot/share/python -name '*.py[co]' | xargs -r rm -f
find /usr/lib/gcc-snapshot/share/python -name __pycache__ -type d | xargs -r rm 
-rf

However, the python directory in the package contents is:

  /usr/lib/gcc-snapshot/share/gcc-9/python

This appears to be an inconsistency.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-snapshot depends on:
ii  binutils2.31.1-11
ii  libc6   2.28-4
ii  libc6-dev   2.28-4
ii  libc6-dev-i386  2.28-4
ii  libc6-dev-x32   2.28-4
ii  libc6-i386  2.28-4
ii  libc6-x32   2.28-4
ii  libgc1c21:7.6.4-0.4
ii  libgmp102:6.1.2+dfsg-4
ii  libisl190.20-2
ii  libmpc3 1.1.0-1
ii  libmpfr64.0.1-2
ii  python3 3.7.1-3
ii  zlib1g  1:1.2.11.dfsg-1

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.31.1-11

-- no debconf information

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

[Vincent Lefevre]

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


#include 
#include 
#include 

int main (void)
{
  volatile int i = INT_MIN;
  int j;

  j = abs (i);
  printf ("%d %d\n", j, j >= 0);
  return 0;
}


should output -2147483648 0 when compiled with the c99 utility. But:

zira:~> c99 -O2 -o tst tst.c
zira:~> ./tst
-2147483648 1

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc depends on:
ii  cpp4:7.3.0-3
ii  gcc-7  7.3.0-25

Versions of packages gcc recommends:
ii  libc6-dev [libc-dev]  2.27-4

Versions of packages gcc suggests:
ii  autoconf  2.69-11+local1
ii  automake  1:1.15.1-3.1
ii  bison 2:3.0.4.dfsg-1+b1
pn  flex  
ii  gcc-doc   5:7.2.0-2
ii  gcc-multilib  4:7.3.0-3
ii  gdb   7.12-6+b2
ii  libtool   2.4.6-2.1+local1
ii  make  4.2.1-1.1
ii  manpages-dev  4.16-1

-- no debconf information

Bug#897416: mpfr4: FTBFS on kfreebsd-amd64

[Vincent Lefevre]

[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=1523420566=0

> It should have been "yes", unless it is known that _Decimal64 does not
> work on FreeBSD. But the GCC manual does not mention OS related issues
> for _Decimal64:
> 
>   https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html

Well, I've looked at the test done by MPFR, and it is awkward:

  volatile _Decimal64 x = 1;
  union { double d; _Decimal64 d64; } y;
  if (x != x) return 83;
  y.d64 = 1234567890123456.0dd;
  return y.d == 0.14894469406741037E-123 ? 80 :
 y.d == 0.59075095508629822E-68  ? 81 : 82;

If there is any issue related to double (such as the use of
x87 extended precision), this may fail. Is this the reason
for kfreebsd-amd64?

I can see 3 solutions:

1. Still compare to double, but use the hex format for the double
values to avoid any inexact base 10 to base 2 conversion.

Note: IMHO, if _Decimal64 exists, one can safely assume that the
hex format is supported.

2. Use uint64_t instead of double. Similarly, IMHO, if _Decimal64
exists, uint64_t probably exists too.

3. Use an array of 8 unsigned char instead of double, and consider
the two possible cases of endianness that can occur nowadays.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#897416: mpfr4: FTBFS on kfreebsd-amd64

[Vincent Lefevre]

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-1_kfreebsd-amd64)
+++ dpkg-gensymbolst5OG2p   2018-04-04 16:57:36.0 +
@@ -189,7 +189,7 @@
  mpfr_get_d1@Base 3.1.3
  mpfr_get_d@Base 3.1.3
  mpfr_get_d_2exp@Base 3.1.3
- (arch=any-amd64 any-i386 powerpc ppc64 ppc64el s390x)mpfr_get_decimal64@Base 
4.0.0
+#MISSING: 4.0.1-1# (arch=any-amd64 any-i386 powerpc ppc64 ppc64el 
s390x)mpfr_get_decimal64@Base 4.0.0
  mpfr_get_default_prec@Base 3.1.3
  mpfr_get_default_rounding_mode@Base 3.1.3
  mpfr_get_emax@Base 3.1.3
@@ -442,7 +442,7 @@
  mpfr_set@Base 3.1.3
  mpfr_set_1_2@Base 4.0.0
  mpfr_set_d@Base 3.1.3
- (arch=any-amd64 any-i386 powerpc ppc64 ppc64el s390x)mpfr_set_decimal64@Base 
4.0.0
+#MISSING: 4.0.1-1# (arch=any-amd64 any-i386 powerpc ppc64 ppc64el 
s390x)mpfr_set_decimal64@Base 4.0.0
  mpfr_set_default_prec@Base 3.1.3
  mpfr_set_default_rounding_mode@Base 3.1.3
  mpfr_set_divby0@Base 3.1.3

and in the configure output:

checking if compiler knows _Decimal64... no

It should have been "yes", unless it is known that _Decimal64 does not
work on FreeBSD. But the GCC manual does not mention OS related issues
for _Decimal64:

  https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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_bug.cgi?id=84761#c9
> 
> Author: jakub
> Date: Mon Mar 19 20:47:29 2018
> New Revision: 258663
> 
> URL: https://gcc.gnu.org/viewcvs?rev=258663=gcc=rev
> Log:
>   PR sanitizer/84761
>   * sanitizer_common/sanitizer_linux_libcdep.cc (__GLIBC_PREREQ):
>   Define if not defined.
>   (DL_INTERNAL_FUNCTION): Don't define.
>   (InitTlsSize): For __i386__ if not compiled against glibc 2.27+
>   determine at runtime whether to use regparm(3), stdcall calling
>   convention for older glibcs or normal calling convention for
>   newer glibcs for call to _dl_get_tls_static_info.
> 
> Modified:
> trunk/libsanitizer/ChangeLog
> trunk/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc

I confirm that gcc-snapshot 1:20180320-1 in experimental fixes the
problem.

Thanks,

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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: https://gcc.gnu.org/viewcvs?rev=258663=gcc=rev
Log:
PR sanitizer/84761
* sanitizer_common/sanitizer_linux_libcdep.cc (__GLIBC_PREREQ):
Define if not defined.
(DL_INTERNAL_FUNCTION): Don't define.
(InitTlsSize): For __i386__ if not compiled against glibc 2.27+
determine at runtime whether to use regparm(3), stdcall calling
convention for older glibcs or normal calling convention for
newer glibcs for call to _dl_get_tls_static_info.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 (>= 2.27), thus has
presumely been built with glibc-2.27:

cventin:~> dpkg -s gcc-snapshot | grep Depends:
Depends: binutils (>= 2.30), libc6-dev-i386 (>= 2.11), libc6-dev-x32 (>= 2.11), 
libc6-dev (>= 2.13-5), lib32z1 (>= 1:1.1.4), libc6 (>= 2.27), libc6-i386 (>= 
2.27), libc6-x32 (>= 2.27), libgc1c2 (>= 1:7.2d), libgmp10 (>= 2:5.0.1~), 
libisl15 (>= 0.15), libmpc3, libmpfr6 (>= 3.1.3), zlib1g (>= 1:1.1.4), python

And I still get the same error:

cventin:~> gcc-snapshot -m32 -fsanitize=address tst.c -o tst
cventin:~> ./tst
AddressSanitizer:DEADLYSIGNAL
=
==8875==ERROR: AddressSanitizer: SEGV on unknown address 0xf7f29e70 (pc 
0xf7f29e84 bp 0xff97c77c sp 0xff97c73c T16777215)
==8875==The signal is caused by a WRITE memory access.
#0 0xf7f29e83 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x11e83)
#1 0xf7a43b19  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0x10cb19)
#2 0xf7a32787  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0xfb787)
#3 0xf7f2791a  (/lib/ld-linux.so.2+0xf91a)
#4 0xf7f18cb9  (/lib/ld-linux.so.2+0xcb9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e83) in 
_dl_get_tls_static_info
==8875==ABORTING

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 = dlsym(RTLD_NEXT, 
> "_dl_get_tls_static_info");
> 
> And on the glibc side:
> | $ readelf -s /lib/ld-linux.so.2  | grep _dl_get_tls_static_info
> |  4: 00011e7035 FUNCGLOBAL DEFAULT   12 
> _dl_get_tls_static_info@@GLIBC_PRIVATE
> 
> This has been discussed for example there:
> https://www.sourceware.org/ml/libc-alpha/2018-02/msg00611.html
> 
> The AddressSanitizer people should discuss for a public API so that it
> doesn't happen again. Otherwise it might break at every new glibc
> version.

FYI, I reported the bug upstream:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#892873: gcc-snapshot: unusual version number

[Vincent Lefevre]

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, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-snapshot depends on:
ii  binutils2.30-7
ii  lib32z1 1:1.2.8.dfsg-5
ii  libc6   2.27-2
ii  libc6-dev   2.27-2
ii  libc6-dev-i386  2.27-2
ii  libc6-dev-x32   2.27-2
ii  libc6-i386  2.27-2
ii  libc6-x32   2.27-2
ii  libgc1c21:7.4.2-8.1
ii  libgmp102:6.1.2+dfsg-3
ii  libisl150.18-1
ii  libmpc3 1.1.0-1
ii  libmpfr64.0.1-1
ii  python  2.7.14-4
ii  zlib1g  1:1.2.8.dfsg-5

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.30-7

-- no debconf information

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

[Vincent Lefevre]

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;
> }
> cventin:~> gcc-snapshot -m32 -fsanitize=address tst.c -o tst
> cventin:~> ./tst
> AddressSanitizer:DEADLYSIGNAL
> =
> ==25032==ERROR: AddressSanitizer: SEGV on unknown address 0xf7fa7e70 (pc 
> 0xf7fa7e84 bp 0xffbf40ac sp 0xffbf406c T16777215)
> ==25032==The signal is caused by a WRITE memory access.
> #0 0xf7fa7e83 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x11e83)
> #1 0xf7ac147d  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0x10e47d)
> #2 0xf7aafd27  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0xfcd27)
> #3 0xf7fa591a  (/lib/ld-linux.so.2+0xf91a)
> #4 0xf7f96cb9  (/lib/ld-linux.so.2+0xcb9)
> 
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e83) in 
> _dl_get_tls_static_info
> ==25032==ABORTING

libc6:i386 was actually the cause (gcc-snapshot had not changed).
Reverting to 2.26-6 makes the crash disappear.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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-snapshot/bin:$PATH
rpath=""
OLD_IFS="$IFS"
IFS=:
for i in $LD_RUN_PATH
do
  rpath="$rpath -Wl,-rpath -Wl,$i"
done
IFS="$OLD_IFS"
exec gcc -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib32 \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/libx32 $rpath "$@"

cventin:~> cat tst.c
int main (void)
{
  return 0;
}
cventin:~> gcc-snapshot -m32 -fsanitize=address tst.c -o tst
cventin:~> ./tst
AddressSanitizer:DEADLYSIGNAL
=
==25032==ERROR: AddressSanitizer: SEGV on unknown address 0xf7fa7e70 (pc 
0xf7fa7e84 bp 0xffbf40ac sp 0xffbf406c T16777215)
==25032==The signal is caused by a WRITE memory access.
#0 0xf7fa7e83 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x11e83)
#1 0xf7ac147d  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0x10e47d)
#2 0xf7aafd27  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0xfcd27)
#3 0xf7fa591a  (/lib/ld-linux.so.2+0xf91a)
#4 0xf7f96cb9  (/lib/ld-linux.so.2+0xcb9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e83) in 
_dl_get_tls_static_info
==25032==ABORTING

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-snapshot depends on:
ii  binutils2.30-5
ii  lib32z1 1:1.2.8.dfsg-5
ii  libc6   2.27-1
ii  libc6-dev   2.27-1
ii  libc6-dev-i386  2.27-1
ii  libc6-dev-x32   2.27-1
ii  libc6-i386  2.27-1
ii  libc6-x32   2.27-1
ii  libgc1c21:7.4.2-8.1
ii  libgmp102:6.1.2+dfsg-2
ii  libisl150.18-1
ii  libmpc3 1.1.0-1
ii  libmpfr64.0.1-1
ii  python  2.7.14-4
ii  zlib1g  1:1.2.8.dfsg-5

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.30-5

-- no debconf information

Bug#889723: libmpfr6: Obsolete README.Debian file

[Vincent Lefevre]

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.

which is no longer true.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmpfr6 depends on:
ii  libc6 2.26-6
ii  libgmp10  2:6.1.2+dfsg-2

libmpfr6 recommends no packages.

libmpfr6 suggests no packages.

-- no debconf information

Bug#889711: Error installing libmpfr-doc

[Vincent Lefevre]

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
> 
> When installing libmpfr-doc you get this error:

Only when the doc-base package is installed.

> Error in `/usr/share/doc-base/mpfr-manual', line 12: value of `Format' not
> specified.
> Note: `install-docs --verbose --check file_name' may give more details about
> the above error.
> 
> 
> When running as suggested "install-docs --verbose --check /usr/share/doc-
> base/mpfr-manual", this is the output:
> 
> Warning in `/usr/share/doc-base/mpfr-manual', line 10: unrecognised control
> field `#Format'.
> Warning in `/usr/share/doc-base/mpfr-manual', line 11: unrecognised control
> field `#Files'.
> Error in `/usr/share/doc-base/mpfr-manual', line 12: value of `Format' not
> specified.
> /usr/share/doc-base/mpfr-manual: 3 warnings or non-fatal errors found.

It seems that "#" is not recognized as a comment. Indeed, there is
no way to have comments in doc-base files:

  /usr/share/doc/doc-base/doc-base.txt.gz

Line 12 is an empty line. This error is probably due to the above
warnings. It may be a bug in doc-base, which should have ignored
sections with only "unrecognised control fields".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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. Shipping and ancient, pre-historic texinfo.tex
> is simply wrong.

Yes. To fix the automake issue, I would see 2 possibilities:

1. The simpler solution: patch texinfo.tex there directly, but this
can mean that it can be out-of-sync with texinfo.

2. The cleaner solution: provide a symlink to the texinfo.tex file
from texinfo (like what it does fto use config.guess and config.sub
from autotools-dev) and depend on texinfo. This would add a dependency
but I suspect that most software that uses GNU Automake also uses
Texinfo, so that in practice, this may not make a difference.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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).
> 
> 2. Patch the texinfo package using the texinfo.tex file from the
> GNU FTP site. After all, the error with @var in exponent is a bug
> in texinfo, which can affect developers of any software that would
> use a @var in exponent. The patch could probably be dropped when
> the next upstream texinfo is released.
> 
> But in case of (2), you need to make sure that this texinfo.tex
> file is taken into account, not the obsolete one from automake.

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
is used to build the software. Ideally, this should be done in
automake as this could affect other software (packaged or not).

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 the texinfo package does not support @var in exponent or
> > subscript as it yields a "\scriptfont 5 is undefined" error:
> 
> Indeed. That is fixed (partially) in the current SVN version, and an
> updated texinfo files can be downloaded from the fnu server.
> 
> If you think it is worth it, I can patch the texinfo package to update
> texinfo.tex
> -\def\texinfoversion{2017-08-23.19}
> +\def\texinfoversion{2018-01-09.11}

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

2. Patch the texinfo package using the texinfo.tex file from the
GNU FTP site. After all, the error with @var in exponent is a bug
in texinfo, which can affect developers of any software that would
use a @var in exponent. The patch could probably be dropped when
the next upstream texinfo is released.

But in case of (2), you need to make sure that this texinfo.tex
file is taken into account, not the obsolete one from automake.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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

  automake: "automake --add-missing" should not install an obsolete
  texinfo.tex file

(following a comment concerning the bug below).

> 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 the texinfo package does not support @var in exponent or
subscript as it yields a "\scriptfont 5 is undefined" error:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882842

and

  https://lists.nongnu.org/archive/html/bug-texinfo/2017-11/msg00019.html
  https://lists.nongnu.org/archive/html/bug-texinfo/2017-12/msg0.html
  https://lists.nongnu.org/archive/html/bug-texinfo/2018-01/msg9.html

> so maybe Vincent could provide a patch to update texinfo's version?

I'm not sure what is best. I wonder whether the same thing as
config.guess / config.sub should be done, for which automake just
provides symlinks to the up-to-date files from autotools-dev.

I'd say that /usr/share/automake-1.15/texinfo.tex should be a
symlink too.

For /usr/share/texmf/tex/texinfo/texinfo.tex, I don't know, since
there are also txi-??.tex files in "/usr/share/texmf/tex/texinfo",
which might be used for some projects that would provide non-English
documentation.

Either the texinfo.tex file should be provided by the texinfo package
(possibly patched, which would be the case now, but otherwise it seems
that in general, this file is up-to-date as upstream texinfo has quite
regular updates), in which case automake should depend on texinfo for
the symlink target, or it should be a separate package with the
/usr/share/texmf/tex/texinfo files, similar to autotools-dev.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 change since 4.0.0:

Index: doc/mpfr.texi
===
--- doc/mpfr.texi   (revision 12081)
+++ doc/mpfr.texi   (revision 12082)
@@ -123,8 +123,11 @@
 
 @c  Usage: @GMPabs{x}
 @c  Give either |x| in tex, or abs(x) in info or html.
+@c  The \ensuremath is needed because the OT1 encoding is used, where
+@c  the pipe character corresponds to a wide dash:
+@chttps://tex.stackexchange.com/a/1775/58921
 @tex
-\gdef\GMPabs#1{|#1|}
+\gdef\GMPabs#1{\ensuremath{|#1|}}
 @end tex
 @ifnottex
 @macro GMPabs {X}

The \ensuremath is necessary to avoid an incorrect PDF file.
For instance, see "It works with..." for mpfr_ai page 28 in
the current

  /usr/share/doc/libmpfr-doc/mpfr.pdf.gz

If I do a

  cp /usr/share/automake-1.15/texinfo.tex doc/

then I can reproduce the error. So, it seems to be a bug in
automake 1.15, solved by the newer texinfo.tex file provided
in the MPFR tarball.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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/make -C build pdf info html
> make[1]: Entering directory '/home/packages/gcc/mpfr/mpfr4-4.0.1~rc2/build'
> Making pdf in doc
> make[2]: Entering directory 
> '/home/packages/gcc/mpfr/mpfr4-4.0.1~rc2/build/doc'
> TEXINPUTS="../../doc:$TEXINPUTS" \
> MAKEINFO='/bin/bash /home/packages/gcc/mpfr/mpfr4-4.0.1~rc2/missing makeinfo
> --enable-encoding -I ../../doc' \
> texi2dvi --pdf --batch  --build-dir=mpfr.t2p -o mpfr.pdf  \
> ../../doc/mpfr.texi
> This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) 
> (preloaded
> format=pdfetex)
>  restricted \write18 enabled.
> entering extended mode
> 
> (../../../.././../../doc/mpfr.texi
> (/home/packages/gcc/mpfr/mpfr4-4.0.1~rc2/doc/texinfo.tex
> Loading texinfo [version 2013-02-01.11]: pdf, fonts, markup, glyphs,
   ^

This is strange. It should be:

Loading texinfo [version 2018-01-09.11]: pdf, fonts, markup, glyphs,

Don't the Debian tools corrupt the MPFR archive with an older texinfo
version?

FYI, the version used by MPFR 4 is the one from:

  https://ftp.gnu.org/gnu/texinfo/

i.e.

  https://ftp.gnu.org/gnu/texinfo/texinfo.tex
  https://ftp.gnu.org/gnu/texinfo/texinfo.tex.sig

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#888422: libmpfr6 should add Breaks: libmpfr4

[Vincent Lefevre]

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 to solve this issue?
> 
> Yes, versioning all symbols could solve this problem
> (assuming libraries like libmpc3 don't expose mpfr internals).

Note that MPFR internals (among what could be exposed, I think) have
not changed, so that I don't think this would even be a problem.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#888422: libmpfr6 should add Breaks: libmpfr4

[Vincent Lefevre]

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 - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#879864: gcc-5: version mismatch

[Vincent Lefevre]

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 policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-5 depends on:
ii  binutils  2.29.1-6
ii  cpp-5 5.5.0-2
ii  gcc-5-base5.5.0-2
ii  libc6 2.24-17
ii  libcc1-0  7.2.0-11
ii  libgcc-5-dev  5.5.0-2
ii  libgcc1   1:7.2.0-11
ii  libgmp10  2:6.1.2+dfsg-1.1
ii  libisl15  0.18-1
ii  libmpc3   1.0.3-2
ii  libmpfr4  3.1.6-1
ii  libstdc++67.2.0-11
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages gcc-5 recommends:
ii  libc6-dev  2.24-17

Versions of packages gcc-5 suggests:
ii  gcc-5-doc 5.3.0-2
ii  gcc-5-locales 5.5.0-2
ii  gcc-5-multilib5.5.0-2
pn  libasan2-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx0-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

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

[Vincent Lefevre]

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
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-7 depends on:
ii  binutils  2.29.1-6
ii  cpp-7 7.2.0-12
ii  gcc-7-base7.2.0-12
ii  libc6 2.24-17
ii  libcc1-0  7.2.0-12
ii  libgcc-7-dev  7.2.0-12
ii  libgcc1   1:7.2.0-12
ii  libgmp10  2:6.1.2+dfsg-1.1
ii  libisl15  0.18-1
ii  libmpc3   1.0.3-2
ii  libmpfr4  3.1.6-1
ii  libstdc++67.2.0-12
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages gcc-7 recommends:
ii  libc6-dev  2.24-17

Versions of packages gcc-7 suggests:
ii  gcc-7-doc 7.2.0-1
ii  gcc-7-locales 7.2.0-12
ii  gcc-7-multilib7.2.0-12
pn  libasan4-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

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

[Vincent Lefevre]

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

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

[Vincent Lefevre]

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_64-linux-gnu/libstdc++.so.6
[Current thread is 1 (Thread 0x7f81ed4c3700 (LWP 6832))]

I've attached the full backtrace.

I couldn't reproduce the crash.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libstdc++6 depends on:
ii  gcc-7-base  7.2.0-7
ii  libc6   2.24-17
ii  libgcc1 1:7.2.0-7

libstdc++6 recommends no packages.

libstdc++6 suggests no packages.

-- no debconf information

Thread 2 (Thread 0x7f820408da00 (LWP 6831)):
#0  0x7f81fd4a3c11 in _gdk_x11_gc_new (drawable=0x7f81e80ab970 
[GdkWindowImplX11], values=0x0, values_mask=(unknown: 0)) at 
./gdk/x11/gdkgc-x11.c:134
gc = 0x55b80c81c9a0 [GdkGCX11]
private = 0x55b80c81c9a0 [GdkGCX11]
xvalues = {function = 3, plane_mask = 140195920362240, foreground = 
140195920419104, background = 140720493280416, line_width = 47693680, 
line_style = 32642, cap_style = 209295136, join_style = 21944, fill_style = 
-401796096, fill_rule = 32641, arc_mode = 2, tile = 5, stipple = 
140196374776731, ts_x_origin = 187293072, ts_y_origin = 21944, font = 
3218813263216655616, subwindow_mode = 47659072, graphics_exposures = 32642, 
clip_x_origin = -531088128, clip_y_origin = 749438363, clip_mask = 
140195920525680, dash_offset = -45409469, dashes = -127 '\201'}
xvalues_mask = 3218813263216655616
__func__ = "_gdk_x11_gc_new"
#1  0x7f82030263f8 in wxGetPoolGC(GdkWindow*, wxPoolGCType) 
(window=0x7f81e807e900 [GdkWindow], type=type@entry=wxPEN_COLOUR) at 
../src/gtk/dcclient.cpp:197
i = 
pptr = 
__FUNCTION__ = "wxGetPoolGC"
#2  0x7f820302b741 in wxWindowDCImpl::SetUpDC(bool) 
(this=this@entry=0x55b80d48c200, isMemDC=isMemDC@entry=false) at 
../src/gtk/dcclient.cpp:394
__FUNCTION__ = "SetUpDC"
done = false
bg_col = 
#3  0x7f820302be32 in wxWindowDCImpl::wxWindowDCImpl(wxDC*, wxWindow*) 
(this=this@entry=0x55b80d48c200, owner=, 
window=window@entry=0x7f81e80d1400) at ../src/gtk/dcclient.cpp:319
widget = 0x7f81e8091920 [wxPizza]
#4  0x7f820302bff1 in wxClientDCImpl::wxClientDCImpl(wxDC*, wxWindow*) 
(this=0x55b80d48c200, owner=, win=0x7f81e80d1400) at 
../src/gtk/dcclient.cpp:2028
#5  0x7f82030daa75 in wxNativeDCFactory::CreateClientDC(wxClientDC*, 
wxWindow*) (this=, owner=0x7ffc0b03bd60, window=0x7f81e80d1400) 
at ../src/common/dcbase.cpp:142
impl = 
#6  0x7f82030dc6d0 in wxClientDC::wxClientDC(wxWindow*) 
(this=0x7ffc0b03bd60, win=0x7f81e80d1400) at ../src/common/dcbase.cpp:210
#7  0x55b80b022666 in  ()
#8  0x55b80b024170 in  ()
#9  0x55b80b004d52 in  ()
#10 0x55b80af5768d in  ()
#11 0x55b80af7e603 in  ()
#12 0x55b80af28899 in  ()
#13 0x55b80af2aa69 in  ()
#14 0x55b80af2abdd in  ()
#15 0x55b80af19a54 in  ()
#16 0x7f81ff6612e1 in __libc_start_main (main=0x55b80af19490, argc=2, 
argv=0x7ffc0b03c4c8, init=, fini=, 
rtld_fini=, stack_end=0x7ffc0b03c4b8) at ../csu/libc-start.c:291
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 8555933072301032110, 
94248945953888, 140720493282496, 0, 0, 2464814579908412078, 
2508275222473802414}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 
0x7ffc0b03c4e0, 0x7f82040db170}, data = {prev = 0x0, cleanup = 0x0, canceltype 
= 184796384}}}
not_first_call = 
#17 0x55b80af1ac8a in  ()

Thread 1 (Thread 0x7f81ed4c3700 (LWP 6832)):
#0  0x7f82004884f8 in vtable for __cxxabiv1::__si_class_type_info () at 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x7f8202fe47b2 in wxBitmap::HasPixmap() const 
(this=this@entry=0x7f81e8053270) at ../src/gtk/bitmap.cpp:1182
#2  0x7f8203029023 in wxWindowDCImpl::DoDrawBitmap(wxBitmap const&, int, 
int, bool) (this=0x7f81e80bae00, bitmap=..., x=, y=, useMask=) at ../src/gtk/dcclient.cpp:1159
__FUNCTION__ = "DoDrawBitmap"
w = 640
h = 384
xx = 0
yy = 0
ww = 640
hh = 384
clipRegion = 0x7f81e80b2b60
overlap = 
isScaled = false
hasAlpha = false
use_gc = 0x55b80c81cf40 [GdkGCX11]
mask = 0x0
mask_new = 0x0
pixmap = 0x0
pixmap_new = 0x0
pixbuf = 0x0
pixbuf_new = 0x0
#3  0x55b80b021a58 in  ()
#4  0x55b80b0225b9 in  ()
#5  

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

[Vincent Lefevre]

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 packages, for instance? In such a
> > case, libc6-dev-i386 would no longer need to recommend gcc-multilib.
> 
> First of all I believe moving this symlink to libc6-dev-i386 is the
> wrong thing to do, while libc6 needs this symlink you also need it for
> building packages with another libc.

I don't think this is a problem since, e.g. for amd64, the
gcc-X-multilib packages depend on libc6-dev-i386, so that
you'll get the symlink.

> In addition this also won't work for architectures with triarch support,
> as it would mean for example that both libc6-dev-i386 and libc6-dev-x32
> need to provide the symlink. This would make them not coinstallable
> anymore.

Do you mean that dpkg doesn't support coinstallation when the
symlink is the *same*?

For instance, with amd64, the symlink is:

  /usr/include/asm -> x86_64-linux-gnu/asm

thus both libc6-dev-i386:amd64 and libc6-dev-x32:amd64 would have
this same symlink.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 that, one currently has the following issue if one wants
to install a non-default multilib GCC version, e.g. gcc-6-multilib:

1. gcc-6-multilib (like the other gcc-X-multilib packages) depends on
   libc6-dev-i386.
2. libc6-dev-i386 recommends[*] gcc-multilib.
3. gcc-multilib depends on the default multilib GCC version, currently
   gcc-7-multilib.

[*] currently suggests, but this will be reverted to recommends
because the /usr/include/asm symbolic link is needed any
gcc-X-multilib compiler:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865429#20

So, installing gcc-6-multilib has the effect to install gcc-7-multilib,
while the user may just want version 6.

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 packages, for instance? In such a
case, libc6-dev-i386 would no longer need to recommend gcc-multilib.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-multilib depends on:
ii  cpp 4:7.1.0-2
ii  gcc 4:7.1.0-2
ii  gcc-7-multilib  7.1.0-13
ii  linux-libc-dev  4.11.11-1

gcc-multilib recommends no packages.

gcc-multilib suggests no packages.

-- no debconf information

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

[Vincent Lefevre]

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_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH
rpath=""
OLD_IFS="$IFS"
IFS=:
for i in $LD_RUN_PATH
do
  rpath="$rpath -Wl,-rpath -Wl,$i"
done
IFS="$OLD_IFS"
exec gcc -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib32 \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/libx32 $rpath "$@"

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 example? For instance, on amd64,
> the wrapper could be:
> 
> --- snip --
> #!/bin/sh
> LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
> PATH=/usr/lib/gcc-snapshot/bin:$PATH
> exec gcc -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib \
>  -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib32 \
>  -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/libx32 "$@"
> --- snip --

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.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 provided
/usr/lib/gcc-snapshot/lib/libasan.so.4), but this was not clear.
The /usr/share/doc/gcc-snapshot/README.Debian file first says:


To use this snapshot, you should set the following environment variables:

LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH


That way, things will work. But just after, it suggests an alternate
solution:


You might also like to use a shell script to wrap up this 
funcationality, e.g. 
 
place in /usr/local/bin/gcc-snapshot and chmod +x it 
 
--- snip --
#! /bin/sh
LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH
gcc "$@"
--- snip --

Make the same for g++, g77, gij, gcj, cpp, ...


This is the solution I'm currently using, but as you say, this may
not be sufficient. There should be some warning saying that under
some conditions, such as the use of the address sanitizer, the
LD_LIBRARY_PATH will also be needed for the generated binaries.
Or...

> 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 example? For instance, on amd64,
the wrapper could be:

--- snip --
#!/bin/sh
LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH
exec gcc -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib32 \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/libx32 "$@"
--- snip --

This seems to work (I've tested on amd64 with and without -m32).
Wouldn't this be a better solution?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 libasan4, which exists only in experimental,
while gcc-snapshot 20170505-1 is in unstable.

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-snapshot depends on:
ii  binutils2.28-4
ii  libc6   2.24-10
ii  libc6-dev   2.24-10
ii  libc6-dev-i386  2.24-10
ii  libc6-dev-x32   2.24-10
ii  libc6-i386  2.24-10
ii  libc6-x32   2.24-10
ii  libgc1c21:7.4.2-8
ii  libgmp102:6.1.2+dfsg-1
ii  libisl150.18-1
ii  libmpc3 1.0.3-1+b2
ii  libmpfr43.1.5-1
ii  python  2.7.13-2
ii  zlib1g  1:1.2.8.dfsg-5

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.28-4

-- no debconf information

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

[Vincent Lefevre]

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 with the MPFR code (get_d.c).

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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

[Vincent Lefevre]

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
environment variables for the "configure" script. The recommended
way[*] is to add a symlink to the plugin in /usr/lib/bfd-plugins,
but this is not something the end user can do, and only packages
should manage files under /usr/lib.

[*] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78795#c7

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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

All the tests fail with the error:

  Your application is linked against incompatible ASan runtimes.

There's no reason why the ASan runtimes should be incompatible.
"gcc-6 -fsanitize=address -static-libasan" has been used everywhere!

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libasan3 depends on:
ii  gcc-6-base  6.2.0-3
ii  libc6   2.24-2
ii  libgcc1 1:6.2.0-3
ii  libstdc++6  6.2.0-3

libasan3 recommends no packages.

libasan3 suggests no packages.

-- no debconf information

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

[Vincent Lefevre]

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_running && 
"ASan init calls itself!")) != (0)" (0x0, 0x0)


There's no such problem with gcc-4.9, gcc-5 and gcc-6.

Note: gcc-snapshot is the following script:

#!/bin/sh
LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH
exec gcc "$@"

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-snapshot depends on:
ii  binutils 2.27-8
ii  libasound2   1.1.2-1
ii  libatk1.0-0  2.21.90-2
ii  libc62.24-2
ii  libc6-dev2.24-2
ii  libc6-dev-i386   2.24-2
ii  libc6-dev-x322.24-2
ii  libc6-i386   2.24-2
ii  libc6-x322.24-2
ii  libcairo21.14.6-1+b1
ii  libecj-java  3.11.0-6
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.49.6-1
ii  libgmp10 2:6.1.1+dfsg-1
ii  libgtk2.0-0  2.24.30-4
ii  libice6  2:1.0.9-1+b1
ii  libisl15 0.17.1-1
ii  libmpc3  1.0.3-1
ii  libmpfr4 3.1.4-2
ii  libpango-1.0-0   1.40.2-1
ii  libpangocairo-1.0-0  1.40.2-1
ii  libpangoft2-1.0-01.40.2-1
ii  libsm6   2:1.2.2-1+b1
ii  libxrandr2   2:1.5.0-1
ii  libxrender1  1:0.9.9-2
ii  libxtst6 2:1.2.2-1+b1
ii  python   2.7.11-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.27-8

-- no debconf information

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

[Vincent Lefevre]

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 library list; you should 
either link runtime to your application or manually preload it with LD_PRELOAD.

Something should be done. This was very confusing at first, because
the problem first came here when I ran a configure script which was
working a few days ago (after investigation, it is now clear that
the reason was that it wasn't under a X11 session a few days ago),
and just saw:

checking whether we are cross compiling... configure: error: in 
`/home/vlefevre/tmp/mpfr-old':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

I could see the error message, but the reason wasn't clear yet
(I initially thought of a regression after a recent upgrade).

So, I think that if possible, having LD_PRELOAD already set shouldn't
affect ASan. Shouldn't -static-libasan be the default, for instance?

If this is not possible, various things should be clarified:

1. The error message should be more informative, e.g. when LD_PRELOAD
is set, say that LD_PRELOAD is set but ASan runtime does not appear
in LD_PRELOAD or does not come first.

2. The gcc(1) man page does not mention LD_PRELOAD at all. Ditto for
the GCC manual.

3. How to find the right ASan runtime *automatically* should also be
documented.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libasan3 depends on:
ii  gcc-6-base  6.2.0-3
ii  libc6   2.24-2
ii  libgcc1 1:6.2.0-3
ii  libstdc++6  6.2.0-3

libasan3 recommends no packages.

libasan3 suggests no packages.

-- no debconf information

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

[Vincent Lefevre]

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

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

[Vincent Lefevre]

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='$(distribution)$(if 
$(with_linaro_branch),/Linaro)$(if $(with_ibm_branch),/IBM)___$(DEB_VERSION)' \
--with-bugurl='file:///usr/share/doc/$(subst 
gcj,gcc,$(PKGSOURCE))/README.Bugs'

So, I suppose that the cause was that $(distribution) was unset.
If I understand correctly, this comes from debian/rules.defs,
which has:

distribution:= $(shell lsb_release -is)

In the logs[*], I can see multiple errors:

Traceback (most recent call last):
  File "/usr/bin/lsb_release", line 25, in 
import lsb_release
ImportError: No module named 'lsb_release'

Shouldn't the build tools check for errors?

[*] 
https://buildd.debian.org/status/fetch.php?pkg=gcc-6=amd64=6.1.1-6=1465527737

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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.

The first line of the output should have been:

gcc-6 (Debian 6.1.1-6) 6.1.1 20160609

There was no such problem with gcc-6 6.1.1-5.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-6 depends on:
ii  binutils  2.26-11
ii  cpp-6 6.1.1-6
ii  gcc-6-base6.1.1-6
ii  libc6 2.22-11
ii  libcc1-0  6.1.1-6
ii  libgcc-6-dev  6.1.1-6
ii  libgcc1   1:6.1.1-6
ii  libgmp10  2:6.1.0+dfsg-2
ii  libisl15  0.17.1-1
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.4-2
ii  libstdc++66.1.1-6
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gcc-6 recommends:
ii  libc6-dev  2.22-11

Versions of packages gcc-6 suggests:
ii  gcc-6-doc 6.1.0-1
ii  gcc-6-locales 6.1.1-6
ii  gcc-6-multilib6.1.1-6
pn  libasan3-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

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

[Vincent Lefevre]

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:

get_d.c: In function 'mpfr_get_d':
get_d.c:115:24: error: array subscript is above array bounds 
[-Werror=array-bounds]
 d = (d + tp[i]) / MP_BASE_AS_DOUBLE;
  ~~^~~

There was no such problem with

gcc (Debian 20160508-1) 7.0.0 20160508 (experimental) [trunk revision 236009]

so that's a recent regression.

I've also reported the bug upstream.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-snapshot depends on:
ii  binutils 2.26-10
ii  libasound2   1.1.0-1
ii  libatk1.0-0  2.20.0-1
ii  libc62.22-10
ii  libc6-dev2.22-10
ii  libc6-dev-i386   2.22-10
ii  libc6-dev-x322.22-10
ii  libc6-i386   2.22-10
ii  libc6-x322.22-10
ii  libcairo21.14.6-1+b1
ii  libecj-java  3.10.1-2
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgmp10 2:6.1.0+dfsg-2
ii  libgtk2.0-0  2.24.30-2
ii  libice6  2:1.0.9-1+b1
ii  libisl15 0.17.1-1
ii  libmpc3  1.0.3-1
ii  libmpfr4 3.1.4-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpangoft2-1.0-01.40.1-1
ii  libsm6   2:1.2.2-1+b1
ii  libxrandr2   2:1.5.0-1
ii  libxrender1  1:0.9.9-2
ii  libxtst6 2:1.2.2-1+b1
ii  python   2.7.11-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.26-10

-- no debconf information

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

[Vincent Lefevre]

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, neither __linux
nor __linux__ is mentioned in the GCC manual (at least for the recent
versions), so that I assume that the developers should not rely on it.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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
/usr/bin/gij-5 - priority 105
[...]

105 for the latest version is too low. I suppose that it should be
1050 and the problem is due to out-of-date code in debian/rules.defs,
which assumes that BASE_VERSION has 2 components:

  java_priority = 10$(subst .,,$(BASE_VERSION))

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gcj-5-jre-headless depends on:
ii  gcc-5-base 5.2.1-22
ii  gcj-5-jre-lib  5.2.1-22
ii  libc6  2.19-22
ii  libgcc11:5.2.1-22
ii  libgcj16   5.2.1-22
ii  zlib1g 1:1.2.8.dfsg-2+b1

gcj-5-jre-headless recommends no packages.

Versions of packages gcj-5-jre-headless suggests:
ii  fastjar   2:0.98-6
pn  gcj-5-jdk 
ii  libgcj16-awt  5.2.1-22

-- no debconf information

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

[Vincent Lefevre]

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 claim that we still support GMP 4.1.x, which is true, but this bug
makes the MPFR build fail with a misleading error message in configure
(we also suggest in the error message to look at config.log, where one
can find a bit more about the real reason of the failure, but this
doesn't give an idea of what is wrong exactly). I have improved the
gmp.h testing in the MPFR configure so that one gets a more meaningful
error if gmp.h isn't usable at all (+ mentioning this incompatibility
between GMP 4.1.x and GCC 5, in the MPFR 3.1 branch).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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. This comes from
gmp.h (GMP 4.1). So, that's actually a bug in GMP, which uses this
semantics unconditionally with all GCC versions. Fortunately,
GMP 4.1 is very old and this has been improved in later GMP
versions.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Vincent Lefevre]

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 function `fn1':
ct.i:(.text+0xa): undefined reference to `fn2'
collect2: error: ld returned 1 exit status

No such problem with gcc-4.9, gcc-4.8 and gcc-4.7.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gcc-5 depends on:
ii  binutils  2.25.1-1
ii  cpp-5 5.2.1-15
ii  gcc-5-base5.2.1-15
ii  libc6 2.19-19
ii  libcc1-0  5.2.1-15
ii  libgcc-5-dev  5.2.1-15
ii  libgcc1   1:5.2.1-15
ii  libgmp10  2:6.0.0+dfsg-7
ii  libisl13  0.14-2
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.3-1
ii  libstdc++65.2.1-15
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gcc-5 recommends:
ii  libc6-dev  2.19-19

Versions of packages gcc-5 suggests:
pn  gcc-5-doc none
ii  gcc-5-locales 5.2.1-15
ii  gcc-5-multilib5.2.1-15
pn  libasan2-dbg  none
ii  libatomic1-dbg5.2.1-15
ii  libcilkrts5-dbg   5.2.1-15
ii  libgcc1-dbg   1:5.2.1-15
ii  libgomp1-dbg  5.2.1-15
ii  libitm1-dbg   5.2.1-15
ii  liblsan0-dbg  5.2.1-15
pn  libmpx0-dbg   none
ii  libquadmath0-dbg  5.2.1-15
ii  libtsan0-dbg  5.2.1-15
ii  libubsan0-dbg 5.2.1-15

-- no debconf information

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

[Vincent Lefevre]

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:
  
  /usr/local/include/x86_64-linux-gnu
  /usr/local/include
  [...]
  /usr/include/x86_64-linux-gnu
  /usr/include
  
  and when adding the -m32 option:
  
  /usr/local/include/i386-linux-gnu
  /usr/local/include
  [...]
  /usr/include/i386-linux-gnu
  /usr/include
  
  But if I use CPATH=/home/vlefevre/include, I just get:
  
  /home/vlefevre/include
  
  Adding the other directory to $CPATH is not a good solution because
  one doesn't always know the ABI (whether -m32 is present or not) in
  advance, i.e. one doesn't know in advance which directory to add.
 
 the preprocessor doesn't know anything about /home/vlefevre/include.
 what should it append?

It should follow the same convention as the system directories.
For instance, if I use CPATH=/home/vlefevre/include then it should
add:

  /home/vlefevre/include/x86_64-linux-gnu
  /home/vlefevre/include

for x86_64 compilation, and

  /home/vlefevre/include/i386-linux-gnu
  /home/vlefevre/include

for i386 compilation (i.e. with -m32).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150503232619.gc13...@xvii.vinc17.org

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

[Vincent Lefevre]

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:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gcc-snapshot depends on:
ii  binutils 2.24.90.20141209-1
ii  libasound2   1.0.28-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-13
ii  libc6-dev2.19-13
ii  libc6-dev-i386   2.19-13
ii  libc6-dev-x322.19-13
ii  libc6-i386   2.19-13
ii  libc6-x322.19-13
ii  libcairo21.14.0-2.1
ii  libecj-java  3.10.1-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-2
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.42.1-1
ii  libgmp10 2:6.0.0+dfsg-6
ii  libgtk2.0-0  2.24.25-1
ii  libice6  2:1.0.9-1+b1
ii  libisl10 0.12.2-2
ii  libmpc3  1.0.2-1
ii  libmpfr4 3.1.2-1+b2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libsm6   2:1.2.2-1+b1
ii  libxrandr2   2:1.4.2-1+b1
ii  libxrender1  1:0.9.8-1+b1
ii  libxtst6 2:1.2.2-1+b1
ii  python   2.7.8-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.24.90.20141209-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141210190903.ga26...@ypig.lip.ens-lyon.fr

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

[Vincent Lefevre]

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/include
[...]
/usr/include/x86_64-linux-gnu
/usr/include

and when adding the -m32 option:

/usr/local/include/i386-linux-gnu
/usr/local/include
[...]
/usr/include/i386-linux-gnu
/usr/include

But if I use CPATH=/home/vlefevre/include, I just get:

/home/vlefevre/include

Adding the other directory to $CPATH is not a good solution because
one doesn't always know the ABI (whether -m32 is present or not) in
advance, i.e. one doesn't know in advance which directory to add.

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cpp-4.9 depends on:
ii  gcc-4.9-base   4.9.2-5
ii  libc6  2.19-13
ii  libcloog-isl4  0.18.2-1
ii  libgmp10   2:6.0.0+dfsg-6
ii  libisl10   0.12.2-2
ii  libmpc31.0.2-1
ii  libmpfr4   3.1.2-1+b1
ii  zlib1g 1:1.2.8.dfsg-2+b1

cpp-4.9 recommends no packages.

Versions of packages cpp-4.9 suggests:
ii  gcc-4.9-locales  4.9.2-5

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141209140311.ga32...@ypig.lip.ens-lyon.fr

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

[Vincent Lefevre]

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 preprocessed source if appropriate.
See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions.

with:

void foo (void);

void tst (void)
{
  int px, py, e;
  for (py = 3; py = 136; py++)
for (px = 32; px = 160; px += 32)
  for (e = py - 2; e = 0; e--)
foo ();
}

This was found when compiling GNU MPFR (tests/tget_f.c).

This is a regression. There is no such problem with 20141016-1.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gcc-snapshot depends on:
ii  binutils 2.24.90.2014-2
ii  libasound2   1.0.28-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-13
ii  libc6-dev2.19-13
ii  libc6-dev-i386   2.19-13
ii  libc6-dev-x322.19-13
ii  libc6-i386   2.19-13
ii  libc6-x322.19-13
ii  libcairo21.14.0-2.1
ii  libecj-java  3.10.1-1
ii  libfontconfig1   2.11.0-6.2
ii  libfreetype6 2.5.2-2
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.42.1-1
ii  libgmp10 2:6.0.0+dfsg-6
ii  libgtk2.0-0  2.24.25-1
ii  libice6  2:1.0.9-1
ii  libisl10 0.12.2-2
ii  libmpc3  1.0.2-1
ii  libmpfr4 3.1.2-1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libsm6   2:1.2.2-1
ii  libxrandr2   2:1.4.2-1+b1
ii  libxrender1  1:0.9.8-1+b1
ii  libxtst6 2:1.2.2-1+b1
ii  python   2.7.8-2
ii  zlib1g   1:1.2.8.dfsg-2

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
ii  binutils [binutils-gold]  2.24.90.2014-2

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141121112853.ga21...@ypig.lip.ens-lyon.fr

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

[Vincent Lefevre]

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 - 20121116-1  ( devel 
 )
 Broken gcc-snapshot:amd64 Depends on libc6-dev-x32 [ amd64 ]  none  ( none 
 ) (= 2.11)
  Try to Re-Instate (1) gcc-snapshot:amd64
 Done
 Done
 The following packages have been kept back:
   gcc-snapshot
 The following packages will be upgraded:
 […]

gcc-snapshot/20121116-1 wasn't installable either for me, but there is
no longer such a dependency (ditto for the libc6 version):

ypig:~ dpkg -s gcc-snapshot
Package: gcc-snapshot
Status: install ok installed
Priority: extra
Section: devel
Installed-Size: 428470
Maintainer: Debian GCC Maintainers debian-gcc@lists.debian.org
Architecture: amd64
Version: 20121120-1
Provides: c++-compiler, c++abi2-dev
Depends: binutils (= 2.22), libc6-dev-i386 (= 2.11), libc6-dev (= 2.13-5), 
libasound2 (= 1.0.16), libatk1.0-0 (= 1.12.4), libc6 (= 2.11), libc6-i386 
(= 2.10), libcairo2 (= 1.2.4), libcloog-isl3, libfontconfig1 (= 2.9.0), 
libfreetype6 (= 2.2.1), libgdk-pixbuf2.0-0 (= 2.22.0), libglib2.0-0 (= 
2.24.0), libgmp10, libgtk2.0-0 (= 2.24.0), libice6 (= 1:1.0.0), libisl10, 
libmpc2, libmpfr4 (= 3.1.0), libpango1.0-0 (= 1.14.0), libsm6, libxrandr2 (= 
4.3), libxrender1, libxtst6, zlib1g (= 1:1.1.4), libecj-java (= 3.5.1), python
Suggests: binutils-gold (= 2.22)
Description: A SNAPSHOT of the GNU Compiler Collection
[...]

I suppose that the problem has been fixed (though the changelog
doesn't say anything about that).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121121112310.ga20...@ypig.lip.ens-lyon.fr

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

[Vincent Lefevre]

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 validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121004113621.ga7...@xvii.vinc17.org

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

[Vincent Lefevre]

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.00% of 31

Function 'mpfr_round_raw_4'
Lines executed:95.00% of 60

Function 'mpfr_round_raw_2'
Lines executed:99.99% of 9

Function 'mpfr_round_raw'
Lines executed:100.00% of 7

File 'round_prec.c'
Lines executed:100.00% of 79
Creating 'round_prec.c.gcov'

File 'round_raw_generic.c'
Lines executed:97.37% of 76
Creating 'round_raw_generic.c.gcov'

File '/usr/include/gmp-x86_64.h'
No executable lines
Removing 'gmp-x86_64.h.gcov'

See the result for Function 'mpfr_round_raw_2': 99.99% of 9.
This is not possible! Either all the lines are executed, in which
case one should get 100%, or at most 8 lines of 9 are executed,
in which case one should get 88.89% at most.

This is reproducible on a Debian/unstable amd64 machine with MPFR
trunk r8346 by running the tools/coverage script.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gcc-4.7 depends on:
ii  binutils  2.22-7+local1
ii  cpp-4.7   4.7.1-4
ii  gcc-4.7-base  4.7.1-4
ii  libc6 2.13-34
ii  libgcc1   1:4.7.1-4
ii  libgmp10  2:5.0.5+dfsg-2
ii  libgomp1  4.7.1-4
ii  libitm1   4.7.1-4
ii  libmpc2   0.9-4
ii  libmpfr4  3.1.0-5
ii  libquadmath0  4.7.1-4
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages gcc-4.7 recommends:
ii  libc6-dev  2.13-34

Versions of packages gcc-4.7 suggests:
pn  binutils-goldnone
pn  gcc-4.7-doc  none
ii  gcc-4.7-locales  4.7.1-4
ii  gcc-4.7-multilib 4.7.1-4
ii  libgcc1-dbg  1:4.7.1-4
ii  libgomp1-dbg 4.7.1-4
ii  libitm1-dbg  4.7.1-4
pn  libmudflap0-4.7-dev  none
ii  libmudflap0-dbg  4.7.1-4
ii  libquadmath0-dbg 4.7.1-4

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120710131700.ga9...@ypig.lip.ens-lyon.fr

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

[Vincent Lefevre]

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. According to the README.Debian
file, the wrapper is just what we need.

  The snapshot package is meant to get early feedback about the
 development version of GCC, either for a rebuild test, or to easily
 test for compiler errors on porter boxes. It's not a package meant
 for regular development. I really prefer to have users either set
 environment variables or create the wrapper scripts on their own.

The package description doesn't say that it isn't for regular
development.

BTW, is there any reason why gcc-snapshot needs the library path
to be changed explicitly (to run the compiler) while this is not
needed for gcc-4.4, gcc-4.5, etc.?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111231192441.gj5...@xvii.vinc17.org

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

[Vincent Lefevre]

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 those libraries' behavior involves
 modifying the library path at runtime.

OK, I thought that the static version was used in such a case, but
I've now seen that the gcc doc (under -static-libgcc) says that it
is not always possible (in particular for C++ and Java).

Alternatively, couldn't /usr/lib/gcc-snapshot/lib be added to the
run path instead of having to use LD_LIBRARY_PATH? For instance,
having

  export LD_RUN_PATH=/usr/lib/gcc-snapshot/lib

in the gcc-snapshot wrapper seems to work (I've done tests with mksh).

Without this run path setting:

$ ldd mksh
linux-vdso.so.1 =  (0x7fff829ff000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f159516a000)
libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f1594f54000)
/lib64/ld-linux-x86-64.so.2 (0x7f159550d000)

With this setting:

$ ldd mksh
linux-vdso.so.1 =  (0x7fff69fff000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f85a6818000)
libgcc_s.so.1 = /usr/lib/gcc-snapshot/lib/libgcc_s.so.1 
(0x7f85a6603000)
/lib64/ld-linux-x86-64.so.2 (0x7f85a6bbb000)

without modifying LD_LIBRARY_PATH.

 From time to time the ABI can be bumped, which means the dependencies
 of generated executables need not always be satisfied by the ordinary
 copies of those libraries in /lib.

I also suppose that there may be incompatilibities if the software
compiled with gcc-snapshot is linked against libraries compiled with
normal GCC versions (if they both use libgcc).

  The README.Debian file
  doesn't say anything like that. According to the README.Debian
  file, the wrapper is just what we need.
 
 Good catch, thanks.  Can you suggest an improved wording?

Let's first see what you think about the run path...

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111231214308.gk5...@xvii.vinc17.org

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

[Vincent Lefevre]

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 the same as the package. At least after
  having tested my stuff with gcc-4.2 in the past, I didn't even
  suspect gcc-snapshot could be any different until ./configure
  failed :p
 
 I suspect it's to save people from the pain of using the snapshot to
 build Debian packages on autobuilders when wanting to use a new
 feature or after running into a bug with one of the released gcc
 versions.

I use gcc-snapshot as a simple end user of GCC, in order to do some
portability tests of my programs (not directly related to Debian)
with the latest GCC features, in particular. So, providing
/usr/bin/gcc-snapshot would be natural.

Do you mean that you don't want gcc-snapshot to be in /usr/bin
because this would yield problems on autobuilders? But wouldn't
be the autobuilders' fault?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111230215536.gf5...@xvii.vinc17.org

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

[Vincent Lefevre]

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
 at README.Debian and not to do that.

OK. Couldn't the wrapper detect that it is being used by a packager
(e.g. because some environment variable is set by the build process)
and output an error in such a case?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111231003435.gg5...@xvii.vinc17.org

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

[Vincent Lefevre]

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 -std=gnu99'

I got:

../../mpfr-3.1.0/tests/trint.c: In function 'main':
../../mpfr-3.1.0/tests/trint.c:247:10: internal compiler error: in decide_alg, 
at config/i386/i386.c:22094
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions.
[...]
Preprocessed source stored into /tmp/ccMzeiyD.out file, please attach this to 
your bugreport.
make[2]: *** [trint.o] Error 1
make[2]: *** Waiting for unfinished jobs

I've attached the preprocessed source, compressed.

BTW, this is strange that config/i386/i386.c is mentioned because
this is an x86_64 machine.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gcc-snapshot depends on:
ii  binutils2.22-1  
ii  libasound2  1.0.24.1-4  
ii  libatk1.0-0 2.2.0-2 
ii  libc6   2.13-21 
ii  libc6-dev   2.13-21 
ii  libc6-dev-i386  2.13-21 
ii  libc6-i386  2.13-21 
ii  libcairo2   1.10.2-6.1  
ii  libcloog-ppl0   0.15.9-3
ii  libecj-java 3.5.1-3 
ii  libfontconfig1  2.8.0-3 
ii  libfreetype62.4.8-1 
ii  libgdk-pixbuf2.0-0  2.24.0-1
ii  libglib2.0-02.30.2-4
ii  libgmp102:5.0.2+dfsg-2  
ii  libgmpxx4ldbl   2:5.0.2+dfsg-2  
ii  libgtk2.0-0 2.24.8-2
ii  libice6 2:1.0.7-2   
ii  libmpc2 0.9-4   
ii  libmpfr43.1.0-3 
ii  libpango1.0-0   1.29.4-2
ii  libppl-c4   0.11.2-6
ii  libppl9 0.11.2-6
ii  libsm6  2:1.2.0-2   
ii  libxrandr2  2:1.3.2-2   
ii  libxrender1 1:0.9.6-2   
ii  libxtst62:1.2.0-4   
ii  python  2.7.2-9 
ii  zlib1g  1:1.2.3.4.dfsg-3

gcc-snapshot recommends no packages.

Versions of packages gcc-snapshot suggests:
pn  binutils-gold  none

-- no debconf information


ccMzeiyD.out.bz2
Description: Binary data

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

[Vincent Lefevre]

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 libgcj12 all
have the same source gcj-4.6, thus gcj-4.6-jre-lib depends on future
versions of the same source.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages gcj-4.6-jre-lib depends on:
ii  gcj-4.6-base  4.6.0-3The GNU Compiler Collection (gcj b
ii  libgcj12  4.6.0-3Java runtime library for use with 

gcj-4.6-jre-lib recommends no packages.

gcj-4.6-jre-lib suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110612030202.ga2...@ypig.lip.ens-lyon.fr

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

[Vincent Lefevre]

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 on the
latest version. I might have copy-pasted the wrong line. :(
I'll have to check again. Sorry.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110524120111.gu1...@prunille.vinc17.org

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

[Vincent Lefevre]

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): undefined reference to `_q_add'
collect2: ld returned 1 exit status

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110524145956.gv1...@prunille.vinc17.org

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

[Vincent Lefevre]

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 vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110525014414.gw1...@prunille.vinc17.org

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

[Vincent Lefevre]

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 exit status
zsh: exit 1 gcc-4.4 tst.c -o tst -mabi=ieeelongdouble

tst.c is:

int main (void)
{
  volatile long double x = 1, y;
  y = x + x;
  return 0;
}

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (500, 'oldstable'), (200, 
'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.26-1-powerpc
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-4.6 depends on:
ii  binutils   2.21.0.20110327-3 The GNU assembler, linker and bina
ii  cpp-4.64.6.0-2   The GNU C preprocessor
ii  gcc-4.6-base   4.6.0-2   The GNU Compiler Collection (base 
ii  libc6  2.11.2-7  Embedded GNU C Library: Shared lib
ii  libcloog-ppl0  0.15.9-3  the Chunky Loop Generator (runtime
ii  libgcc11:4.6.0-2 GCC support library
ii  libgmp10   2:5.0.1+dfsg-7Multiprecision arithmetic library
ii  libgmpxx4ldbl  2:5.0.1+dfsg-7Multiprecision arithmetic library 
ii  libgomp1   4.6.0-2   GCC OpenMP (GOMP) support library
ii  libmpc20.9-3 multiple precision complex floatin
ii  libmpfr4   3.0.0-9   multiple precision floating-point 
ii  libppl-c4  0.11.2-3  Parma Polyhedra Library (C interfa
ii  libppl90.11.2-3  Parma Polyhedra Library (runtime l
ii  zlib1g 1:1.2.3.4.dfsg-3  compression library - runtime

Versions of packages gcc-4.6 recommends:
ii  libc6-dev 2.11.2-7   Embedded GNU C Library: Developmen

Versions of packages gcc-4.6 suggests:
pn  binutils-gold none (no description available)
pn  gcc-4.6-doc   none (no description available)
pn  gcc-4.6-locales   none (no description available)
pn  gcc-4.6-multilib  none (no description available)
pn  libgcc1-dbg   none (no description available)
pn  libgomp1-dbg  none (no description available)
pn  libmudflap0-4.6-dev   none (no description available)
pn  libmudflap0-dbg   none (no description available)
pn  libquadmath-dbg   none (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110516020321.ga25...@ay.vinc17.org