Re: latest gcc vs lib/timespec.h:85

2017-12-15 Thread Paul Eggert
On 12/14/2017 12:25 AM, Tim Rühsen wrote: Does it fix things to add -Wshorten-64-to-32 to build-aux/gcc-warning.spec and to build-aux/g++-warning.spec? > No, it doesn't change anything (I am not using manywarnings.m4). OK, in that case you should be able to fix the problem by specifying -Wno-

Re: latest gcc vs lib/timespec.h:85

2017-12-14 Thread Tim Rühsen
On 12/13/2017 10:55 PM, Paul Eggert wrote: > On 12/13/2017 01:32 AM, Tim Rühsen wrote: >> Now clang throws out an annoying warning about the return value of  > >> timespec_cmp(): > > In file included from wget.c:51: > > ../lib/timespec.h:94:20: warning: implicit conversion loses integer > > precis

Re: latest gcc vs lib/timespec.h:85

2017-12-13 Thread Paul Eggert
On 12/13/2017 01:32 AM, Tim Rühsen wrote: Now clang throws out an annoying warning about the return value of > timespec_cmp(): > > In file included from wget.c:51: > ../lib/timespec.h:94:20: warning: implicit conversion loses integer > precision: 'long' to 'int' [-Wshorten-64-to-32] > return a.

Re: latest gcc vs lib/timespec.h:85

2017-12-13 Thread Tim Rühsen
On 10/30/2017 12:43 AM, Jim Meyering wrote: > On Sun, Oct 29, 2017 at 4:27 PM, Paul Eggert wrote: >> Jim Meyering wrote: >>> >>> Here's a proposed patch: >> >> I prefer 'assume' to 'assure' here, since it's a low-level time-comparison >> primitive and lots of other code in the module already silen

Re: latest gcc vs lib/timespec.h:85

2017-10-29 Thread Jim Meyering
On Sun, Oct 29, 2017 at 4:27 PM, Paul Eggert wrote: > Jim Meyering wrote: >> >> Here's a proposed patch: > > I prefer 'assume' to 'assure' here, since it's a low-level time-comparison > primitive and lots of other code in the module already silently assumes that > the timestamps are valid. Also, w

Re: latest gcc vs lib/timespec.h:85

2017-10-29 Thread Paul Eggert
Jim Meyering wrote: Here's a proposed patch: I prefer 'assume' to 'assure' here, since it's a low-level time-comparison primitive and lots of other code in the module already silently assumes that the timestamps are valid. Also, while I was in the neighborhood I noticed that the cast is no l

Re: latest gcc vs lib/timespec.h:85

2017-10-29 Thread Jim Meyering
On Fri, Oct 27, 2017 at 9:33 PM, Jim Meyering wrote: > On Mon, Oct 2, 2017 at 6:31 PM, Paul Eggert wrote: >> On 10/02/2017 06:24 PM, Jim Meyering wrote: >>> >>> Given all of the comments on that function, I'd be tempted to suppress >>> this warning in that function. >> >> That would work. Another

Re: latest gcc vs lib/timespec.h:85

2017-10-27 Thread Jim Meyering
On Mon, Oct 2, 2017 at 6:31 PM, Paul Eggert wrote: > On 10/02/2017 06:24 PM, Jim Meyering wrote: >> >> Given all of the comments on that function, I'd be tempted to suppress >> this warning in that function. > > That would work. Another possibility would be to include verify.h and add > something

Re: latest gcc vs lib/timespec.h:85

2017-10-02 Thread Paul Eggert
On 10/02/2017 06:24 PM, Jim Meyering wrote: Given all of the comments on that function, I'd be tempted to suppress this warning in that function. That would work. Another possibility would be to include verify.h and add something like this to the start of timespec_cmp:   assume (-1 <= a.tv_n

latest gcc vs lib/timespec.h:85

2017-10-02 Thread Jim Meyering
Hi Paul, Mainly just a heads up, since this certainly isn't blocking me. When trying to build coreutils using gcc built from very recent (with some change committed since Sep 26), I see this new warning/error: In file included from src/system.h:140:0, from src/ls.c:84: src/ls.c: