All of lore.kernel.org
 help / color / mirror / Atom feed
* extra 'make check' failures on 32bit Linux
@ 2017-03-26 22:21 Ramsay Jones
  2017-03-26 23:56 ` Luc Van Oostenryck
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Ramsay Jones @ 2017-03-26 22:21 UTC (permalink / raw)
  To: Christopher Li, Luc Van Oostenryck; +Cc: Sparse Mailing-list

Hi Christopher, Luc,

On occasion I build sparse on 32-bit Linux and I have noticed, for some
weeks now, unexpected test failures. I have been meaning to take a look
at fixing these failures, but I just haven't had the time ... :(

So, as the next best thing, I thought I should at least let you know
about the failures, viz:

  $ make check
  Makefile:66: Your system does not have libxml, disabling c2xml
  Makefile:78: Your system does not have libgtk2, disabling test-inspect
  Makefile:98: Your system does not have llvm, disabling sparse-llvm
       TEST     abstract array declarator static (abstract-array-declarator-static.c)
       TEST     address_space attribute (address_space.c)
  ...
  
       TEST     bool-cast-explicit (bool-cast-explicit.c)
  error: Actual output contains some patterns which are not expected.
       TEST     bool-cast-implicit (bool-cast-implicit.c)
  error: Actual output contains some patterns which are not expected.
  ...
  
       TEST     call-inlined (call-inlined.c)
  error: actual output text does not match expected output text.
  error: see call-inlined.c.output.* for further investigation.
  --- call-inlined.c.output.expected	2017-03-26 18:26:03.358108923 +0100
  +++ call-inlined.c.output.got	2017-03-26 18:26:03.370120836 +0100
  @@ -15,14 +15,14 @@
   bas:
   .L6:
   	<entry-point>
  -	add.64      %r16 <- "abc", $1
  -	ret.64      %r16
  +	add.32      %r16 <- "abc", $1
  +	ret.32      %r16
   
   
   qus:
   .L9:
   	<entry-point>
  -	add.64      %r21 <- messg, $1
  -	ret.64      %r21
  +	add.32      %r21 <- messg, $1
  +	ret.32      %r21
   
   
       TEST     call-variadic (call-variadic.c)
  error: actual output text does not match expected output text.
  error: see call-variadic.c.output.* for further investigation.
  --- call-variadic.c.output.expected	2017-03-26 18:26:03.398148634 +0100
  +++ call-variadic.c.output.got	2017-03-26 18:26:03.402152605 +0100
  @@ -1,14 +1,14 @@
   foo:
   .L0:
   	<entry-point>
  -	push.64     "msg %c: %d %d/%ld %ld/%p %p\n"
  +	push.32     "msg %c: %d %d/%ld %ld/%p %p\n"
   	push.32     $120
   	push.32     %arg2
   	push.32     $7
  -	push.64     %arg3
  -	push.64     $0
  -	push.64     %arg4
  -	push.64     $0
  +	push.32     %arg3
  +	push.32     $0
  +	push.32     %arg4
  +	push.32     $0
   	call.32     %r5 <- print
   	ret.32      %r5
   
  ...
  
       TEST     division constants (div.c)
  error: actual error text does not match expected error text.
  error: see div.c.error.* for further investigation.
  --- div.c.error.expected	2017-03-26 18:26:04.142887258 +0100
  +++ div.c.error.got	2017-03-26 18:26:04.142887258 +0100
  @@ -2,8 +2,6 @@
   div.c:4:20: warning: division by zero
   div.c:5:22: warning: division by zero
   div.c:7:25: warning: constant integer operation overflow
  -div.c:8:27: warning: constant integer operation overflow
   div.c:9:34: warning: constant integer operation overflow
   div.c:11:25: warning: constant integer operation overflow
  -div.c:12:27: warning: constant integer operation overflow
   div.c:13:34: warning: constant integer operation overflow
  ...
  
       TEST     warn-unknown-attribute-yes (Wunknown-attribute-yes.c)
  Out of 210 tests, 196 passed, 14 failed (9 of them are known to fail)
  39 tests were disabled
  Makefile:213: recipe for target 'check' failed
  make: *** [check] Error 1
  
  $ cat validation/bool-cast-explicit.c.output.got
  fs32:
  .L0:
  	<entry-point>
  	setne.1     %r2 <- %arg1, $0
  	ret.1       %r2
  
  
  fu32:
  .L2:
  	<entry-point>
  	setne.1     %r5 <- %arg1, $0
  	ret.1       %r5
  
  
  fvdp:
  .L4:
  	<entry-point>
  	cast.32     %r8 <- (32) %arg1
  	setne.1     %r9 <- %r8, $0
  	ret.1       %r9
  
  
  fsip:
  .L6:
  	<entry-point>
  	cast.32     %r12 <- (32) %arg1
  	setne.1     %r13 <- %r12, $0
  	ret.1       %r13
  
  
  fdbl:
  .L8:
  	<entry-point>
  	set.64      %r16 <- 0.000000
  	setne.1     %r17 <- %arg1, %r16
  	ret.1       %r17
  
  
  ffun:
  .L10:
  	<entry-point>
  	cast.32     %r20 <- (32) ffun
  	setne.1     %r21 <- %r20, $0
  	ret.1       %r21
  
  
  fres:
  .L12:
  	<entry-point>
  	setne.1     %r24 <- %arg1, $0
  	ret.1       %r24
  
  
  $ 

Note that the output file for bool-cast-implicit.c is identical to the
above file for bool-cast-explicit.c, so I haven't included it here.

Again, I haven't had time to look properly, but it seems that some
expected output files assume a 64-bit platform and that long and pointers
are 64-bit rather than 32-bit. (or something like that :-) )

ATB,
Ramsay Jones


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: extra 'make check' failures on 32bit Linux
  2017-03-26 22:21 extra 'make check' failures on 32bit Linux Ramsay Jones
@ 2017-03-26 23:56 ` Luc Van Oostenryck
  2017-03-27  1:03 ` Luc Van Oostenryck
  2017-03-27  7:51 ` Christopher Li
  2 siblings, 0 replies; 8+ messages in thread
From: Luc Van Oostenryck @ 2017-03-26 23:56 UTC (permalink / raw)
  To: Ramsay Jones; +Cc: Christopher Li, Sparse Mailing-list

On Sun, Mar 26, 2017 at 11:21:44PM +0100, Ramsay Jones wrote:
> Hi Christopher, Luc,
> 
> On occasion I build sparse on 32-bit Linux and I have noticed, for some
> weeks now, unexpected test failures. I have been meaning to take a look
> at fixing these failures, but I just haven't had the time ... :(
> 
> So, as the next best thing, I thought I should at least let you know
> about the failures, viz:
> 
> ...
> 
> Note that the output file for bool-cast-implicit.c is identical to the
> above file for bool-cast-explicit.c, so I haven't included it here.
> 
> Again, I haven't had time to look properly, but it seems that some
> expected output files assume a 64-bit platform and that long and pointers
> are 64-bit rather than 32-bit. (or something like that :-) )

You're absolutely right. My bad.
I'll update all that.

Thanks for letting know.

-- Luc

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: extra 'make check' failures on 32bit Linux
  2017-03-26 22:21 extra 'make check' failures on 32bit Linux Ramsay Jones
  2017-03-26 23:56 ` Luc Van Oostenryck
@ 2017-03-27  1:03 ` Luc Van Oostenryck
  2017-03-27 15:27   ` Ramsay Jones
  2017-03-27  7:51 ` Christopher Li
  2 siblings, 1 reply; 8+ messages in thread
From: Luc Van Oostenryck @ 2017-03-27  1:03 UTC (permalink / raw)
  To: Ramsay Jones; +Cc: Christopher Li, Sparse Mailing-list

On Sun, Mar 26, 2017 at 11:21:44PM +0100, Ramsay Jones wrote:
> Hi Christopher, Luc,
> 
> On occasion I build sparse on 32-bit Linux and I have noticed, for some
> weeks now, unexpected test failures. I have been meaning to take a look
> at fixing these failures, but I just haven't had the time ... :(

>   ...
>   
>        TEST     division constants (div.c)
>   error: actual error text does not match expected error text.
>   error: see div.c.error.* for further investigation.
>   --- div.c.error.expected	2017-03-26 18:26:04.142887258 +0100
>   +++ div.c.error.got	2017-03-26 18:26:04.142887258 +0100
>   @@ -2,8 +2,6 @@
>    div.c:4:20: warning: division by zero
>    div.c:5:22: warning: division by zero
>    div.c:7:25: warning: constant integer operation overflow
>   -div.c:8:27: warning: constant integer operation overflow
>    div.c:9:34: warning: constant integer operation overflow
>    div.c:11:25: warning: constant integer operation overflow
>   -div.c:12:27: warning: constant integer operation overflow
>    div.c:13:34: warning: constant integer operation overflow
>   ...

It's not very clear to me what is the cause of this error.
Have you only since some weeks (then I think it's since the
we define __SIZEOF_POINTER__) or is it older (then I think
it exists since quite a long time)?

-- Luc

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: extra 'make check' failures on 32bit Linux
  2017-03-26 22:21 extra 'make check' failures on 32bit Linux Ramsay Jones
  2017-03-26 23:56 ` Luc Van Oostenryck
  2017-03-27  1:03 ` Luc Van Oostenryck
@ 2017-03-27  7:51 ` Christopher Li
  2 siblings, 0 replies; 8+ messages in thread
From: Christopher Li @ 2017-03-27  7:51 UTC (permalink / raw)
  To: Ramsay Jones; +Cc: Luc Van Oostenryck, Sparse Mailing-list

On Sun, Mar 26, 2017 at 3:21 PM, Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
> Hi Christopher, Luc,
>
> On occasion I build sparse on 32-bit Linux and I have noticed, for some
> weeks now, unexpected test failures. I have been meaning to take a look
> at fixing these failures, but I just haven't had the time ... :(

Thanks for the report. I haven't test sparse on 32 bit platform.
It seems some byte code test case assuming the result from 64 bit platform.

Chris

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: extra 'make check' failures on 32bit Linux
  2017-03-27  1:03 ` Luc Van Oostenryck
@ 2017-03-27 15:27   ` Ramsay Jones
  2017-03-27 16:10     ` Luc Van Oostenryck
  0 siblings, 1 reply; 8+ messages in thread
From: Ramsay Jones @ 2017-03-27 15:27 UTC (permalink / raw)
  To: Luc Van Oostenryck; +Cc: Christopher Li, Sparse Mailing-list



On 27/03/17 02:03, Luc Van Oostenryck wrote:
> On Sun, Mar 26, 2017 at 11:21:44PM +0100, Ramsay Jones wrote:
>> Hi Christopher, Luc,
>>
>> On occasion I build sparse on 32-bit Linux and I have noticed, for some
>> weeks now, unexpected test failures. I have been meaning to take a look
>> at fixing these failures, but I just haven't had the time ... :(
> 
>>   ...
>>   
>>        TEST     division constants (div.c)
>>   error: actual error text does not match expected error text.
>>   error: see div.c.error.* for further investigation.
>>   --- div.c.error.expected	2017-03-26 18:26:04.142887258 +0100
>>   +++ div.c.error.got	2017-03-26 18:26:04.142887258 +0100
>>   @@ -2,8 +2,6 @@
>>    div.c:4:20: warning: division by zero
>>    div.c:5:22: warning: division by zero
>>    div.c:7:25: warning: constant integer operation overflow
>>   -div.c:8:27: warning: constant integer operation overflow
>>    div.c:9:34: warning: constant integer operation overflow
>>    div.c:11:25: warning: constant integer operation overflow
>>   -div.c:12:27: warning: constant integer operation overflow
>>    div.c:13:34: warning: constant integer operation overflow
>>   ...
> 
> It's not very clear to me what is the cause of this error.
> Have you only since some weeks (then I think it's since the
> we define __SIZEOF_POINTER__) or is it older (then I think
> it exists since quite a long time)?

I just did a git bisect, which shows:

...

$ git bisect good
8d688c9a6ee220ce00b30afd8bdffa34434c9950 is the first bad commit
commit 8d688c9a6ee220ce00b30afd8bdffa34434c9950
Author: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Date:   Tue Feb 7 21:04:24 2017 +0100

    define __LONG_MAX__ & __SIZEOF_POINTER__
    
    They're part of GCC's common predefined macros and some
    code & header files depends on them.
    
    Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
    Signed-off-by: Christopher Li <sparse@chrisli.org>

:100644 100644 38ff165b360525c2b83cd76d674593ee79cb9ffb 65887c40d3b5b020991be2372b0af5c1b7088776 M	lib.c
$ 

So, I looked in the debugger and 'bits_in_long' and 'bits_in_pointer'
are set correctly, but __LONG_MAX__ is being printed with an LL suffix,
so, this fixes it for me:

$ git diff
diff --git a/lib.c b/lib.c
index 272d2c8..502c264 100644
--- a/lib.c
+++ b/lib.c
@@ -834,7 +834,7 @@ static void predefined_macros(void)
        add_pre_buffer("#define __CHECKER__ 1\n");
 
        val = (1ULL << (bits_in_long-1)) - 1;
-       add_pre_buffer("#weak_define __LONG_MAX__ %#llxLL\n", val);
+       add_pre_buffer("#weak_define __LONG_MAX__ %#llxL\n", val);
        add_pre_buffer("#weak_define __SIZEOF_POINTER__ %d\n", bits_in_pointer/8);
 }
 
$ 

Not a proper fix, but ...

Ah, I've just noticed you have sent some patches. ;-)

I will take a look and let you know.

ATB,
Ramsay Jones



^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: extra 'make check' failures on 32bit Linux
  2017-03-27 15:27   ` Ramsay Jones
@ 2017-03-27 16:10     ` Luc Van Oostenryck
  2017-03-27 16:53       ` Ramsay Jones
  0 siblings, 1 reply; 8+ messages in thread
From: Luc Van Oostenryck @ 2017-03-27 16:10 UTC (permalink / raw)
  To: Ramsay Jones; +Cc: Christopher Li, Sparse Mailing-list

On Mon, Mar 27, 2017 at 5:27 PM, Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:

> So, I looked in the debugger and 'bits_in_long' and 'bits_in_pointer'
> are set correctly, but __LONG_MAX__ is being printed with an LL suffix,
> so, this fixes it for me:
>
> $ git diff
> diff --git a/lib.c b/lib.c
> index 272d2c8..502c264 100644
> --- a/lib.c
> +++ b/lib.c
> @@ -834,7 +834,7 @@ static void predefined_macros(void)
>         add_pre_buffer("#define __CHECKER__ 1\n");
>
>         val = (1ULL << (bits_in_long-1)) - 1;
> -       add_pre_buffer("#weak_define __LONG_MAX__ %#llxLL\n", val);
> +       add_pre_buffer("#weak_define __LONG_MAX__ %#llxL\n", val);
>         add_pre_buffer("#weak_define __SIZEOF_POINTER__ %d\n", bits_in_pointer/8);
>  }
>
> $
>
> Not a proper fix, but ...

Well, actually it is the proper fix as __LONG_MAX__ is supposed to be
a 'long' and not a 'long long'.

> Ah, I've just noticed you have sent some patches. ;-)
>
> I will take a look and let you know.

OK, thanks.
It should be OK as I new tested it on a 32bit machine but
another environment is always good for testing.

-- Luc

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: extra 'make check' failures on 32bit Linux
  2017-03-27 16:10     ` Luc Van Oostenryck
@ 2017-03-27 16:53       ` Ramsay Jones
  2017-03-27 17:15         ` Luc Van Oostenryck
  0 siblings, 1 reply; 8+ messages in thread
From: Ramsay Jones @ 2017-03-27 16:53 UTC (permalink / raw)
  To: Luc Van Oostenryck; +Cc: Christopher Li, Sparse Mailing-list



On 27/03/17 17:10, Luc Van Oostenryck wrote:
> On Mon, Mar 27, 2017 at 5:27 PM, Ramsay Jones
> <ramsay@ramsayjones.plus.com> wrote:
> 
>> So, I looked in the debugger and 'bits_in_long' and 'bits_in_pointer'
>> are set correctly, but __LONG_MAX__ is being printed with an LL suffix,
>> so, this fixes it for me:
>>
>> $ git diff
>> diff --git a/lib.c b/lib.c
>> index 272d2c8..502c264 100644
>> --- a/lib.c
>> +++ b/lib.c
>> @@ -834,7 +834,7 @@ static void predefined_macros(void)
>>         add_pre_buffer("#define __CHECKER__ 1\n");
>>
>>         val = (1ULL << (bits_in_long-1)) - 1;
>> -       add_pre_buffer("#weak_define __LONG_MAX__ %#llxLL\n", val);
>> +       add_pre_buffer("#weak_define __LONG_MAX__ %#llxL\n", val);
>>         add_pre_buffer("#weak_define __SIZEOF_POINTER__ %d\n", bits_in_pointer/8);
>>  }
>>
>> $
>>
>> Not a proper fix, but ...
> 
> Well, actually it is the proper fix as __LONG_MAX__ is supposed to be
> a 'long' and not a 'long long'.
> 
>> Ah, I've just noticed you have sent some patches. ;-)
>>
>> I will take a look and let you know.
> 
> OK, thanks.
> It should be OK as I new tested it on a 32bit machine but
> another environment is always good for testing.

OK, so I tested the 5 patch series + the v2 patch that you sent
out on Linux 64bit, Linux 32bit and cygwin 64bit.

I applied the patches on top of the current 'sparse-next' branch:

  $ git branch -v
    chrisl-master   ce18a90 sparse: update __builtin_object_size() prototype
    master          fbbfc73 simplify float-to-float casts that doesn't change size
    mingw           9e96dd5 test-suite: Add -b option to ignore CR at eol on MinGW
    sparse-next     f7817f0 llvm: cleanup of output_[ptr]cast()
  * sparse-next-tmp df7cd04 fix expansion of integers to floats

  $ git log --oneline sparse-next..
  df7cd04 fix expansion of integers to floats
  83de8c4 do not depends on limits.h to test __CHAR_BIT__
  ac9f7b4 fix test validation/div.c
  153d5cf predefine __SIZEOF_INT__ & friends
  a3a916c predefine __INT_MAX__ and friends
  26a0a0a fix test for cast to bool on 32bit machines
  $ 

On Linux 64bit, I get:

  $ make check
  ...
  Out of 214 tests, 205 passed, 9 failed (9 of them are known to fail)
  39 tests were disabled
  $ 

On Linux 32bit, I get:

  $ make check
  ...
       TEST     call-inlined (call-inlined.c)
  error: actual output text does not match expected output text.
  error: see call-inlined.c.output.* for further investigation.
  --- call-inlined.c.output.expected	2017-03-27 16:57:23.438683323 +0100
  +++ call-inlined.c.output.got	2017-03-27 16:57:23.442685323 +0100
  @@ -15,14 +15,14 @@
   bas:
   .L6:
   	<entry-point>
  -	add.64      %r16 <- "abc", $1
  -	ret.64      %r16
  +	add.32      %r16 <- "abc", $1
  +	ret.32      %r16
 
 
   qus:
   .L9:
   	<entry-point>
  -	add.64      %r21 <- messg, $1
  -	ret.64      %r21
  +	add.32      %r21 <- messg, $1
  +	ret.32      %r21
 
 
       TEST     call-variadic (call-variadic.c)
  error: actual output text does not match expected output text.
  error: see call-variadic.c.output.* for further investigation.
  --- call-variadic.c.output.expected	2017-03-27 16:57:23.482705323 +0100
  +++ call-variadic.c.output.got	2017-03-27 16:57:23.486707323 +0100
  @@ -1,14 +1,14 @@
   foo:
   .L0:
   	<entry-point>
  -	push.64     "msg %c: %d %d/%ld %ld/%p %p\n"
  +	push.32     "msg %c: %d %d/%ld %ld/%p %p\n"
   	push.32     $120
   	push.32     %arg2
   	push.32     $7
  -	push.64     %arg3
  -	push.64     $0
  -	push.64     %arg4
  -	push.64     $0
  +	push.32     %arg3
  +	push.32     $0
  +	push.32     %arg4
  +	push.32     $0
   	call.32     %r5 <- print
   	ret.32      %r5
 
  ...
  Out of 214 tests, 203 passed, 11 failed (9 of them are known to fail)
  39 tests were disabled
  Makefile:213: recipe for target 'check' failed
  make: *** [check] Error 1
  $ 

And on cygwin 64bit, I get:

  $ tail test-out-tmp
       TEST     Varargs bogus warning regression test #1 (varargs1.c)
       TEST     wide character constants (wide.c)
       TEST     Woverride-init-def (Woverride-init-def.c)
       TEST     Woverride-init-no (Woverride-init-no.c)
       TEST     Woverride-init-yes (Woverride-init-yes.c)
       TEST     warn-unknown-attribute (Wunknown-attribute-def.c)
       TEST     warn-unknown-attribute-no (Wunknown-attribute-no.c)
       TEST     warn-unknown-attribute-yes (Wunknown-attribute-yes.c)
  Out of 253 tests, 235 passed, 18 failed (9 of them are known to fail)
  make: *** [Makefile:213: check] Error 1
  $ 

Note that the 9 unexpected failures on cygwin are due to the same
'llvm tool problems' that we discussed before. ie the new tests added
in these patches all pass.

Hope that helps.

ATB,
Ramsay Jones


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: extra 'make check' failures on 32bit Linux
  2017-03-27 16:53       ` Ramsay Jones
@ 2017-03-27 17:15         ` Luc Van Oostenryck
  0 siblings, 0 replies; 8+ messages in thread
From: Luc Van Oostenryck @ 2017-03-27 17:15 UTC (permalink / raw)
  To: Ramsay Jones; +Cc: Christopher Li, Sparse Mailing-list

On Mon, Mar 27, 2017 at 05:53:17PM +0100, Ramsay Jones wrote:
> 
> > OK, thanks.
> > It should be OK as I new tested it on a 32bit machine but
> > another environment is always good for testing.
> 
> OK, so I tested the 5 patch series + the v2 patch that you sent
> out on Linux 64bit, Linux 32bit and cygwin 64bit.
> 
> I applied the patches on top of the current 'sparse-next' branch:
> 
>   $ git branch -v
>     chrisl-master   ce18a90 sparse: update __builtin_object_size() prototype
>     master          fbbfc73 simplify float-to-float casts that doesn't change size
>     mingw           9e96dd5 test-suite: Add -b option to ignore CR at eol on MinGW
>     sparse-next     f7817f0 llvm: cleanup of output_[ptr]cast()
>   * sparse-next-tmp df7cd04 fix expansion of integers to floats
> 
>   $ git log --oneline sparse-next..
>   df7cd04 fix expansion of integers to floats
>   83de8c4 do not depends on limits.h to test __CHAR_BIT__
>   ac9f7b4 fix test validation/div.c
>   153d5cf predefine __SIZEOF_INT__ & friends
>   a3a916c predefine __INT_MAX__ and friends
>   26a0a0a fix test for cast to bool on 32bit machines
>   $ 
> 
> On Linux 64bit, I get:
> 
>   $ make check
>   ...
>   Out of 214 tests, 205 passed, 9 failed (9 of them are known to fail)
>   39 tests were disabled
>   $ 
> 
> On Linux 32bit, I get:
> 
>   $ make check
>   ...
>        TEST     call-inlined (call-inlined.c)
>   error: actual output text does not match expected output text.
>   error: see call-inlined.c.output.* for further investigation.
>   --- call-inlined.c.output.expected	2017-03-27 16:57:23.438683323 +0100
>   +++ call-inlined.c.output.got	2017-03-27 16:57:23.442685323 +0100

Yes, this is expected. Sorry, I should have told earlier.
Those were part of another serie that I didn't yes sent an updated
version. The 5 patches series only covered what's already in master,
not sparse-next.

I'll sent an updated version for what's in sparse-next a bit later.

-- Luc

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-03-27 17:25 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-26 22:21 extra 'make check' failures on 32bit Linux Ramsay Jones
2017-03-26 23:56 ` Luc Van Oostenryck
2017-03-27  1:03 ` Luc Van Oostenryck
2017-03-27 15:27   ` Ramsay Jones
2017-03-27 16:10     ` Luc Van Oostenryck
2017-03-27 16:53       ` Ramsay Jones
2017-03-27 17:15         ` Luc Van Oostenryck
2017-03-27  7:51 ` Christopher Li

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.