On Sun, Sep 09, 2018 at 06:11:16PM +0100, Ramsay Jones wrote: > Hi Luc, > > As you may remember, I occasionally build sparse on 32bit Linux. Yes, I know, and I should do this myself more often ... > This build > failed recently and I have been trying, without success, to find time to look > into the reasons for the failure. Today I had a _very_ quick look and used > git bisect to at least pin down the commits which introduced the three new > test failures. Unfortunately, I don't have time to look at this further at > the moment, so I thought I should let you know what I have found so far. Thanks. > The first bisect run netted two new failures: ... > TEST init-local (mem2reg/init-local.c) > error: test 'mem2reg/init-local.c' failed > error: Pattern 'load\.' unexpectedly present This one is not an error (the IR is valid and matches the semantic of original code) but is somehow a problem. It's related to what can be promoted to register. Here, in ssa.c:is_promotable(), a struct that is longer than a long (maximal size of an integer register) is ignored for SSA conversion because the double is 64bit while long is only 32. Clearly the double could be promoted too but once floats mix with integers, several problems occurs and it's why I restricted things like this. I'll look at this but I know it is a bit delicate, even fragile. > TEST cse-size (optim/cse-size.c) > error: test 'optim/cse-size.c' failed > error: Pattern 'phi\.' expected 2 times but got 1 times This one is a non-issue. The test make only sense when long > int. Adding a -m64 will fix the failing test (or, I can do what I have done in some other tests, using short & int instead of int & long). > The second bisect run netted the final new failure: ... > TEST Waddress-space-strict (Waddress-space-strict.c) > error: actual error text does not match expected error text. > error: see Waddress-space-strict.c.error.* for further investigation. > --- Waddress-space-strict.c.error.expected 2018-09-08 21:14:27.297819515 +0100 > +++ Waddress-space-strict.c.error.got 2018-09-08 21:14:27.289819441 +0100 > @@ -8,7 +8,7 @@ > Waddress-space-strict.c:30:10: warning: cast removes address space of expression > Waddress-space-strict.c:31:10: warning: cast removes address space of expression > Waddress-space-strict.c:32:10: warning: cast removes address space of expression > -Waddress-space-strict.c:9:18: warning: non size-preserving integer to pointer cast > -Waddress-space-strict.c:10:25: warning: non size-preserving integer to pointer cast > -Waddress-space-strict.c:21:15: warning: non size-preserving pointer to integer cast > -Waddress-space-strict.c:28:15: warning: non size-preserving pointer to integer cast > +Waddress-space-strict.c:15:18: warning: non size-preserving integer to pointer cast > +Waddress-space-strict.c:16:25: warning: non size-preserving integer to pointer cast > +Waddress-space-strict.c:23:17: warning: non size-preserving pointer to integer cast > +Waddress-space-strict.c:30:17: warning: non size-preserving pointer to integer cast > > Just looking at the output of the third failure above, it seems clear that > this is caused by the test expectation that a pointer is 64-bit. Or more exactly, that long == pointer and int < pointer. > I suspect, > but haven't tried, adding '-m64' to the command line would fix that test. It's the correct thing to do. > (But that begs the question about checking 32-bit pointers). Well, there is no problems with 32-bit pointers. The test here doesn't check anything really specific to pointers and their size. It only tests the address-spaces and for doing this makes some assumption about the relative sizes of integers and pointers. In truth, this test tests too much (and should use intptr). Thanks for testing this. -- Luc
