Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 11.03.2017 um 00:33 schrieb Junio C Hamano: > René Scharfe writes: > >> @ depends on r @ >> expression E; >> @@ >> - *& >>E > > I guess my source of the confusion is that the tool that understands > the semantics of the C language still needs to be

Re: [PATCH v1] Travis: also test on 32-bit Linux

René Scharfe writes: > @ depends on r @ > expression E; > @@ > - *& > E I guess my source of the confusion is that the tool that understands the semantics of the C language still needs to be told about that. I was hoping that something that

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 10.03.2017 um 21:13 schrieb Junio C Hamano: René Scharfe writes: I think this misses the other two cases: (*dst, src) and (*dst, *src). ... and that's why I left them out. You can't get dst vs. *dst wrong with structs (at least not without the compiler complaining); only

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Fri, Mar 10, 2017 at 12:13:11PM -0800, Junio C Hamano wrote: > René Scharfe writes: > > >> I think this misses the other two cases: (*dst, src) and (*dst, *src). > > > > ... and that's why I left them out. You can't get dst vs. *dst wrong > > with structs (at least not without

Re: [PATCH v1] Travis: also test on 32-bit Linux

René Scharfe writes: >> I think this misses the other two cases: (*dst, src) and (*dst, *src). > > ... and that's why I left them out. You can't get dst vs. *dst wrong > with structs (at least not without the compiler complaining); only > safe transformations are included in this

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 10.03.2017 um 18:57 schrieb Jeff King: On Fri, Mar 10, 2017 at 05:20:13PM +0100, René Scharfe wrote: I think this misses the other two cases: (*dst, src) and (*dst, *src). ... and that's why I left them out. You can't get dst vs. *dst wrong with structs (at least not without the compiler

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Fri, Mar 10, 2017 at 05:20:13PM +0100, René Scharfe wrote: > > I think this misses the other two cases: (*dst, src) and (*dst, *src). > > ... and that's why I left them out. You can't get dst vs. *dst wrong with > structs (at least not without the compiler complaining); only safe >

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 10.03.2017 um 09:18 schrieb Jeff King: On Fri, Mar 10, 2017 at 01:14:16AM +0100, René Scharfe wrote: 2. Ones which just copy a single object, like: memcpy(, , sizeof(dst)); Perhaps we should be using struct assignment like: dst = src; here. It's safer and it

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Fri, Mar 10, 2017 at 01:14:16AM +0100, René Scharfe wrote: > > 2. Ones which just copy a single object, like: > > > >memcpy(, , sizeof(dst)); > > > > Perhaps we should be using struct assignment like: > > > >dst = src; > > > > here. It's safer and it should give

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Fri, Mar 10, 2017 at 01:14:45AM +0100, René Scharfe wrote: > > 3. There were a number of alloc-and-copy instances. The copy part is > > the same as (2) above, but you have to repeat the size, which is > > potentially error-prone. I wonder if we would want something like: > > > >

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 05.03.2017 um 12:36 schrieb Jeff King: > I grepped for 'memcpy.*sizeof' and found one other case that's not a > bug, but is questionable. > > Of the "good" cases, I think most of them could be converted into > something more obviously-correct, which would make auditing easier. The > three main

Re: [PATCH v1] Travis: also test on 32-bit Linux

Am 05.03.2017 um 12:36 schrieb Jeff King: I grepped for 'memcpy.*sizeof' and found one other case that's not a bug, but is questionable. Of the "good" cases, I think most of them could be converted into something more obviously-correct, which would make auditing easier. The three main cases I

Re: [PATCH v1] Travis: also test on 32-bit Linux

On 05/03/17 17:38, Lars Schneider wrote: >> On 02 Mar 2017, at 16:17, Ramsay Jones wrote: >> On 02/03/17 11:24, Johannes Schindelin wrote: >>> On Thu, 2 Mar 2017, Lars Schneider wrote: >>> >> [snip] One thing that still bugs me: In the Linux32 environment prove

Re: [PATCH v1] Travis: also test on 32-bit Linux

> On 02 Mar 2017, at 16:17, Ramsay Jones wrote: > > > > On 02/03/17 11:24, Johannes Schindelin wrote: >> Hi Lars, >> >> On Thu, 2 Mar 2017, Lars Schneider wrote: >> > [snip] >>> One thing that still bugs me: In the Linux32 environment prove adds the >>> CPU

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Sun, Mar 05, 2017 at 06:36:19AM -0500, Jeff King wrote: > I grepped for 'memcpy.*sizeof' and found one other case that's not a > bug, but is questionable. And here's the fix for that case. It can be applied separately from the other patch if need be. -- >8 -- Subject: [PATCH] ewah: fix

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Sat, Mar 04, 2017 at 09:08:40PM +0100, Vegard Nossum wrote: > > At a glance, looks like range_set_copy() is using > > sizeof(struct range_set) == 12, but > > range_set_init/range_set_grow/ALLOC_GROW/REALLOC_ARRAY is using > > sizeof(rs->range) == 8. > > Attached patch seems to fix it --

Re: [PATCH v1] Travis: also test on 32-bit Linux

On 04/03/2017 20:49, Vegard Nossum wrote: On 04/03/2017 19:08, Vegard Nossum wrote: On 04/03/2017 18:23, Lars Schneider wrote: Did Travis find our first 32bit bug? I briefly looked into it and the following new topic on pu seems to cause the issue:

Re: [PATCH v1] Travis: also test on 32-bit Linux

On 04/03/2017 19:08, Vegard Nossum wrote: On 04/03/2017 18:23, Lars Schneider wrote: Did Travis find our first 32bit bug? I briefly looked into it and the following new topic on pu seems to cause the issue: http://public-inbox.org/git/20170302172902.16850-1-allan.x.xav...@oracle.com/

Re: [PATCH v1] Travis: also test on 32-bit Linux

On 04/03/2017 18:23, Lars Schneider wrote: Did Travis find our first 32bit bug? I briefly looked into it and the following new topic on pu seems to cause the issue: http://public-inbox.org/git/20170302172902.16850-1-allan.x.xav...@oracle.com/

Re: [PATCH v1] Travis: also test on 32-bit Linux

> On 04 Mar 2017, at 05:11, Junio C Hamano wrote: > > On Fri, Mar 3, 2017 at 4:03 PM, Junio C Hamano wrote: >> >> I only recently started looking at Travis logs, so I cannot tell if >> it is just a usual flake (e.g. some builds a few days ago seems to >>

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Fri, Mar 3, 2017 at 4:03 PM, Junio C Hamano wrote: > > I only recently started looking at Travis logs, so I cannot tell if > it is just a usual flake (e.g. some builds a few days ago seems to > have failed due to not being able to check out the tree being > tested, which I

Re: [PATCH v1] Travis: also test on 32-bit Linux

Junio C Hamano writes: > I see he did v2 which you Acked in a different thread. Will replace > what's been on 'pu' and running with Travis the past few days with > it. Let's wait for one or more Travis cycles and then merge it to > 'next'.

Re: [PATCH v1] Travis: also test on 32-bit Linux

Johannes Schindelin writes: > On Thu, 2 Mar 2017, Junio C Hamano wrote: > >> Another question is which v3 people mean in the discussion, when you >> and Dscho work on improvements at the same time and each post the >> "next" version marked as "v3", and they comment on

Re: [PATCH v1] Travis: also test on 32-bit Linux

Hi Junio, On Thu, 2 Mar 2017, Junio C Hamano wrote: > Another question is which v3 people mean in the discussion, when you > and Dscho work on improvements at the same time and each post the > "next" version marked as "v3", and they comment on one of them? But then, Lars & I communicate in a

Re: [PATCH v1] Travis: also test on 32-bit Linux

Lars Schneider writes: >> On 02 Mar 2017, at 12:24, Johannes Schindelin >> wrote: >> >> Hi Lars, >> >> On Thu, 2 Mar 2017, Lars Schneider wrote: >> >>> The patch looks good to me in general but I want to propose the following >>>

Re: [PATCH v1] Travis: also test on 32-bit Linux

On Thu, Mar 2, 2017 at 3:22 PM, Johannes Schindelin wrote: > >> >> +set -e >> > >> > Is this really necessary? I really like to avoid `set -e`, in >> > particular when we do pretty much everything in && chains anyway. >> >> Agreed, not really necessary here as we just

Re: [PATCH v1] Travis: also test on 32-bit Linux

On 02/03/17 11:24, Johannes Schindelin wrote: > Hi Lars, > > On Thu, 2 Mar 2017, Lars Schneider wrote: > [snip] >> One thing that still bugs me: In the Linux32 environment prove adds the >> CPU times to every test run: ( 0.02 usr 0.00 sys + 0.00 cusr 0.00 >> csys ... Has anyone an idea why

Re: [PATCH v1] Travis: also test on 32-bit Linux

Hi Lars, On Thu, 2 Mar 2017, Lars Schneider wrote: > > On 02 Mar 2017, at 12:24, Johannes Schindelin > > wrote: > > > > On Thu, 2 Mar 2017, Lars Schneider wrote: > > > >> The patch looks good to me in general but I want to propose the > >> following changes: > >

Re: [PATCH v1] Travis: also test on 32-bit Linux

> On 02 Mar 2017, at 12:24, Johannes Schindelin > wrote: > > Hi Lars, > > On Thu, 2 Mar 2017, Lars Schneider wrote: > >> The patch looks good to me in general but I want to propose the following >> changes: > > I know you are using your script to generate this

Re: [PATCH v1] Travis: also test on 32-bit Linux

Hi Lars, On Thu, 2 Mar 2017, Lars Schneider wrote: > The patch looks good to me in general but I want to propose the following > changes: I know you are using your script to generate this mail, but I would have liked to see v2 in the subject ;-) > (1) Move all the docker magic into a dedicated