sparse test failures on ppc32le (and other not so common archs)

Commit Message

Christopher Li Sept. 1, 2017, 12:47 a.m. UTC

On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
that works. So to address the Debian bug I can do:
>
>  - move sparse to /usr/lib
>  - teach cgcc about the move of sparse
>  - make /usr/bin/sparse call cgcc -no-compile "$@"

I don't like that. It means the user can't invoke sparse directly.

>
> or is it easier to teach sparse about the architecture stuff?

First of all. It is not very trivial to teach sparse about the architecture
stuff. To my mind, we need to move all the cgcc logic into sparse.

For this case, I think it is easier to teach the sparse validation
code to use cgcc on those back end testing. Most validation don't
need to include system header file at all so it does not have
this problem.

How about this patch?
I know my patch is white space damaged in email.
Git branch is at:
https://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git/log/?h=llvm-cgcc

Please let me know if that fix your problem. It pass check
on my local machine running x86_64. I don't have ppc64 to
test with.

Chris

--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Josh Triplett Sept. 1, 2017, 7:02 a.m. UTC | #1

On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
> that works. So to address the Debian bug I can do:
> >
> >  - move sparse to /usr/lib
> >  - teach cgcc about the move of sparse
> >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> 
> I don't like that. It means the user can't invoke sparse directly.
> 
> >
> > or is it easier to teach sparse about the architecture stuff?
> 
> First of all. It is not very trivial to teach sparse about the architecture
> stuff. To my mind, we need to move all the cgcc logic into sparse.

Related to that: while it would mean we couldn't necessarily just rely
entirely on GCC's definitions for a target platform, I think in an ideal
world we could have a sparse binary that understood *all* target
platforms at once, such that you could ask Sparse on x86_64 to "compile"
as though targeting any arbitrary architecture. That would also have the
major advantage of making it easy to run the Sparse testsuite for
*every* target architecture without needing compilers for every such
architecture.
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Uwe Kleine-König Sept. 1, 2017, 7:57 a.m. UTC | #2

On Fri, Sep 01, 2017 at 12:02:12AM -0700, Josh Triplett wrote:
> On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> > On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
> > that works. So to address the Debian bug I can do:
> > >
> > >  - move sparse to /usr/lib
> > >  - teach cgcc about the move of sparse
> > >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> > 
> > I don't like that. It means the user can't invoke sparse directly.
> > 
> > >
> > > or is it easier to teach sparse about the architecture stuff?
> > 
> > First of all. It is not very trivial to teach sparse about the architecture
> > stuff. To my mind, we need to move all the cgcc logic into sparse.
> 
> Related to that: while it would mean we couldn't necessarily just rely
> entirely on GCC's definitions for a target platform, I think in an ideal
> world we could have a sparse binary that understood *all* target
> platforms at once, such that you could ask Sparse on x86_64 to "compile"
> as though targeting any arbitrary architecture. That would also have the
> major advantage of making it easy to run the Sparse testsuite for
> *every* target architecture without needing compilers for every such
> architecture.

You'd need the target arch's system headers though. But still it would
be great. In a first attempt something like:

	#ifdef __powerpc__
		add_pre_buffer("#weak_define __powerpc__ " __powerpc__ "\n");
	#ifdef _CALL_ELF
		add_pre_buffer("#weak_define _CALL_ELF " _CALL_ELF "\n");
	#endif
	#endif

would be helpful already.

Best regards
Uwe

Christopher Li Sept. 1, 2017, noon UTC | #3

On Fri, Sep 1, 2017 at 3:02 AM, Josh Triplett <[e-mail]> wrote:
>> First of all. It is not very trivial to teach sparse about the architecture
>> stuff. To my mind, we need to move all the cgcc logic into sparse.
>
> Related to that: while it would mean we couldn't necessarily just rely
> entirely on GCC's definitions for a target platform, I think in an ideal
> world we could have a sparse binary that understood *all* target
> platforms at once, such that you could ask Sparse on x86_64 to "compile"

Yes, that is what I want to have. It is list as one of the project in
project idea document as well. I have  a related question. How do we
test the different architecture handling without actually run sparse
on different platform? I am thinking maybe using gcc cross platform
compiler and compare some macro against the sparse one.

> as though targeting any arbitrary architecture. That would also have the
> major advantage of making it easy to run the Sparse testsuite for
> *every* target architecture without needing compilers for every such
> architecture.

Another way to fix the test suite for now would be let testsuite
specify using cgcc instead of sparse directly, for the test source
that needs it. That will buy us some time. Fixing sparse properly
in the long term obvious would be better.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Josh Triplett Sept. 1, 2017, 10:55 p.m. UTC | #4

On Fri, Sep 01, 2017 at 09:57:09AM +0200, Uwe Kleine-König wrote:
> On Fri, Sep 01, 2017 at 12:02:12AM -0700, Josh Triplett wrote:
> > On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> > > On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
> > > that works. So to address the Debian bug I can do:
> > > >
> > > >  - move sparse to /usr/lib
> > > >  - teach cgcc about the move of sparse
> > > >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> > > 
> > > I don't like that. It means the user can't invoke sparse directly.
> > > 
> > > >
> > > > or is it easier to teach sparse about the architecture stuff?
> > > 
> > > First of all. It is not very trivial to teach sparse about the architecture
> > > stuff. To my mind, we need to move all the cgcc logic into sparse.
> > 
> > Related to that: while it would mean we couldn't necessarily just rely
> > entirely on GCC's definitions for a target platform, I think in an ideal
> > world we could have a sparse binary that understood *all* target
> > platforms at once, such that you could ask Sparse on x86_64 to "compile"
> > as though targeting any arbitrary architecture. That would also have the
> > major advantage of making it easy to run the Sparse testsuite for
> > *every* target architecture without needing compilers for every such
> > architecture.
> 
> You'd need the target arch's system headers though.

Only for building userspace code, not for building standalone/kernel
code, or the Sparse testsuite.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Luc Van Oostenryck Sept. 3, 2017, 9:14 p.m. UTC | #5

On Fri, Sep 1, 2017 at 9:02 AM, Josh Triplett <[e-mail]> wrote:
> On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
>> On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
>> that works. So to address the Debian bug I can do:
>> >
>> >  - move sparse to /usr/lib
>> >  - teach cgcc about the move of sparse
>> >  - make /usr/bin/sparse call cgcc -no-compile "$@"
>>
>> I don't like that. It means the user can't invoke sparse directly.
>>
>> >
>> > or is it easier to teach sparse about the architecture stuff?
>>
>> First of all. It is not very trivial to teach sparse about the architecture
>> stuff. To my mind, we need to move all the cgcc logic into sparse.
>
> Related to that: while it would mean we couldn't necessarily just rely
> entirely on GCC's definitions for a target platform, I think in an ideal
> world we could have a sparse binary that understood *all* target
> platforms at once, such that you could ask Sparse on x86_64 to "compile"
> as though targeting any arbitrary architecture. That would also have the
> major advantage of making it easy to run the Sparse testsuite for
> *every* target architecture without needing compilers for every such
> architecture.

I really think that the testsuite should not depend on system or library
header.

Otherwise, I'm not at all opposed to sparse being universal but I would like
to note that things can become very quickly very very messy.
For example, for the current problem here I understood that it was
at least partially based on the lack of a definition of _CALL_ELF
but do we need to define it to 1 or to 2, in other words, do we need
to support the ELFv1 ABI or the ELFv2? GCC has some flags for this
(-mabi=elfv[12]) but what default value do we want? ELFv1 is the default
for big-endian platform and ELFv2 for little-endian platform, so yes,
we need a flag for the endianness but which endianness we want as default?
And so on.

Things become even more fun when taking in account the difference
between GCC version. Do we want to be universal there too (and thus
have some flags for to specify which gcc's version we want to mimick)?
What about other compilers?


I think that part of the needed info can be auto-extracted from GCC
when doing a native build. Using some sort of spec file or a .sparserc
can help too.

I also note that currently, sparse is already largely universal *because*
it *doesn't* need those platform details (or only the very minimal: word size).

-- Luc Van Oostenryck
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Christopher Li Sept. 4, 2017, 6 p.m. UTC | #6

On Sun, Sep 3, 2017 at 5:14 PM, Luc Van Oostenryck
<[e-mail]> wrote:
>
> I really think that the testsuite should not depend on system or library
> header.

I think that is a good point. We can start cleaning up the system header
file dependency in the existing test suite. See how it goes.

>
> Otherwise, I'm not at all opposed to sparse being universal but I would like
> to note that things can become very quickly very very messy.
> For example, for the current problem here I understood that it was
> at least partially based on the lack of a definition of _CALL_ELF
> but do we need to define it to 1 or to 2, in other words, do we need
> to support the ELFv1 ABI or the ELFv2? GCC has some flags for this
> (-mabi=elfv[12]) but what default value do we want? ELFv1 is the default

I think we can just sparse default to as late as the latest release
version of gcc.

> for big-endian platform and ELFv2 for little-endian platform, so yes,
> we need a flag for the endianness but which endianness we want as default?

I am tempting to make the endianness the same as the host gcc by default.
Then it can be overwrite by architecture flags.

>
> Things become even more fun when taking in account the difference
> between GCC version. Do we want to be universal there too (and thus
> have some flags for to specify which gcc's version we want to mimick)?
> What about other compilers?

I purpose just sync to the latest gcc version (or a late enough version
we can agree on. e.g. the one that supported by kernel compile.) Sparse
current try to sync to the latest gcc attributes already.

> I think that part of the needed info can be auto-extracted from GCC
> when doing a native build. Using some sort of spec file or a .sparserc

Is there a way to do auto-extract? That would be a good starting point.

> I also note that currently, sparse is already largely universal *because*
> it *doesn't* need those platform details (or only the very minimal: word size).

Sparse is not universal, it just support a very small sub set of the C
source file that haven't expose to those platform detail macros. Adding
those architecture macro support will not make it any less universal.
Might slow things down, that is some thing we need to watch out for.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Uwe Kleine-König Sept. 6, 2017, 2:44 p.m. UTC | #7

[readding people to Cc assuming that's ok]

Hello Luc,

On Mon, Sep 04, 2017 at 10:36:47PM +0200, Luc Van Oostenryck wrote:
> On Mon, Sep 4, 2017 at 10:57 AM, Uwe Kleine-König <[e-mail]> wrote:
> > On 09/03/2017 11:14 PM, Luc Van Oostenryck wrote:
> >> On Fri, Sep 1, 2017 at 9:02 AM, Josh Triplett <[e-mail]> wrote:
> >>> Related to that: while it would mean we couldn't necessarily just rely
> >>> entirely on GCC's definitions for a target platform, I think in an ideal
> >>> world we could have a sparse binary that understood *all* target
> >>> platforms at once, such that you could ask Sparse on x86_64 to "compile"
> >>> as though targeting any arbitrary architecture. That would also have the
> >>> major advantage of making it easy to run the Sparse testsuite for
> >>> *every* target architecture without needing compilers for every such
> >>> architecture.
> >>
> >> I really think that the testsuite should not depend on system or library
> >> header.
> >
> > Assuming it's intended that sparse should be able to check userspace
> > programs, I don't agree here.
> 
> I understand this.
> I'll explain a bit better my point of view.
> First, I make a distinction between 'sparse core functionalities' and
> general usage.
> I was talking about this core usage and the testsuite is currently for this core
> usage too.

and while it's ok to test the core stuff and not wanting the system
includes to interfere, there should also be tests that check "ordinary"
userspace programs which naturally depend on the system headers.

> Asking for the testsuite to not depends on system or library header is exactly
> the same as GCC people asking bug reports to be done on pre-processed file
> (so that they focus on the core problem and not some problem with an header).
> This, of course, doesn't mean that GCC should only be used on standalone
> source files nor that GCC shouldn't be tested on real code, using
> system headers.
> It's just something different.
> 
> So to answer to your objection: yes, you're right but it should be done in some
> specific tests, not the core ones.

ah, we agree. Fine.

> Secondly, about "intended to check userspace programs":
> It's clear that sparse's main use is for the kernel, but it's also
> clear that it can
> and is used on other (userspace) projects.
> However, as you have seen yourself, you can't use sparse as is and expect
> to work on any environment, on any architecture. Even for the kernel it doesn't:
> each architecture has to specify a few flags (like -m32/-m64) and a few defines
> (-D__arm__, ...). For userspace, cgcc can do a part of this job for you.
> 
> Josh proposal to have what I called a 'universal' sparse, won't solve this,
> on the contrary.
> Compilers eschew part of this problem by having to configure the build
> 
> I'm all in favor to move cgcc logic to sparse and/or it's build system so that
> *for a native build* it can be used as-is in most cases.
> This would solve your problem, I think.
> 
> BTW, sorry I didn't follow last week but is your problem solved now?

No, it's not solved. But given that it is somehow known that sparse
(without cgcc) fails to work well on userspace stuff, I think the
following would be fine for the Debian side:

 a) let horst use cgcc instead of sparse
 b) downgrade bug to important or even normal pointing out that cgcc
    should be used for userspace programs

For sparse it would be cool to:

 c) drop the #weak_define of __amd64__ to make this "problem" more
    apparent. (Assuming this doesn't break e.g. a kernel build.)
 d) fix the test suite, at least mark the tests that are expected to
    fail on !x86 as such to make $(make check) succeed. (Otherwise I'd
    have to disable or ignore the testsuite which isn't that great.)
 
Best regards
Uwe

Christopher Li Sept. 6, 2017, 3:18 p.m. UTC | #8

On Wed, Sep 6, 2017 at 10:44 AM, Uwe Kleine-König <[e-mail]> wrote:
>
> and while it's ok to test the core stuff and not wanting the system
> includes to interfere, there should also be tests that check "ordinary"
> userspace programs which naturally depend on the system headers.
>

There is one. The "selfcheck" target was checking sparse on its own
source file. That will definitively use the system header file. However,
there are some warning trigger in the system header file can't be fixed
in the sparse source code. It need to change the system header to make
some warning go away, or disable that warning.

>
> No, it's not solved. But given that it is somehow known that sparse
> (without cgcc) fails to work well on userspace stuff, I think the
> following would be fine for the Debian side:
>
>  a) let horst use cgcc instead of sparse
>  b) downgrade bug to important or even normal pointing out that cgcc
>     should be used for userspace programs

That seems to be the right thing to do for now. That is until
sparse are smarter on user space header regarding architecture stuff.

> For sparse it would be cool to:
>
>  c) drop the #weak_define of __amd64__ to make this "problem" more
>     apparent. (Assuming this doesn't break e.g. a kernel build.)

You mean remove define of "__x86_64__".

It will likely break some other stuff. For the record the "selfcheck" target
already using cgcc. We still need to fix the breakage.

Any suggestion how to test sparse running on other platform headfile
without have to get access to ppc64 for example? I think that is the biggest
obstacle right now. I can make some changes, but I don't have a good way
to test it other than x86 platform.

>  d) fix the test suite, at least mark the tests that are expected to
>     fail on !x86 as such to make $(make check) succeed. (Otherwise I'd
>     have to disable or ignore the testsuite which isn't that great.)

We can make the test-suite not depend on system header files.
That seems to be the right think to do. I also send out a patch
to let the llvm back end test-suite use cgcc last week. Removing
system header usage in test suite is better.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Uwe Kleine-König Sept. 6, 2017, 3:36 p.m. UTC | #9

Hello Christopher,

On Wed, Sep 06, 2017 at 11:18:04AM -0400, Christopher Li wrote:
> On Wed, Sep 6, 2017 at 10:44 AM, Uwe Kleine-König <[e-mail]> wrote:
> > and while it's ok to test the core stuff and not wanting the system
> > includes to interfere, there should also be tests that check "ordinary"
> > userspace programs which naturally depend on the system headers.
> 
> There is one. The "selfcheck" target was checking sparse on its own
> source file. That will definitively use the system header file. However,
> there are some warning trigger in the system header file can't be fixed
> in the sparse source code. It need to change the system header to make
> some warning go away, or disable that warning.
> 
> >
> > No, it's not solved. But given that it is somehow known that sparse
> > (without cgcc) fails to work well on userspace stuff, I think the
> > following would be fine for the Debian side:
> >
> >  a) let horst use cgcc instead of sparse
> >  b) downgrade bug to important (or even normal) pointing out that
> >     cgcc should be used for userspace programs
> 
> That seems to be the right thing to do for now. That is until
> sparse are smarter on user space header regarding architecture stuff.

ok, Antoine, can you talk to the horst people and ask them to switch to
cgcc then?

> > For sparse it would be cool to:
> >
> >  c) drop the #weak_define of __amd64__ to make this "problem" more
> >     apparent. (Assuming this doesn't break e.g. a kernel build.)
> 
> You mean remove define of "__x86_64__".

ack.

> It will likely break some other stuff. For the record the "selfcheck" target
> already using cgcc. We still need to fix the breakage.
> 
> Any suggestion how to test sparse running on other platform headfile
> without have to get access to ppc64 for example? I think that is the biggest
> obstacle right now. I can make some changes, but I don't have a good way
> to test it other than x86 platform.

There is https://dsa.debian.org/doc/guest-account/ which would give you
the possibility to access some Debian machines. Other than that I intend
to upload 0.5.1 to Debian soon and then can provide you links to build
failures in the build server farm :-) And if you have a patch, I can
volunteer to make the test monkey for you.

> >  d) fix the test suite, at least mark the tests that are expected to
> >     fail on !x86 as such to make $(make check) succeed. (Otherwise I'd
> >     have to disable or ignore the testsuite which isn't that great.)
> 
> We can make the test-suite not depend on system header files.
> That seems to be the right think to do. I also send out a patch
> to let the llvm back end test-suite use cgcc last week. Removing
> system header usage in test suite is better.

Testing that patch is on my todo list.

Best regards
Uwe

Uwe Kleine-König Sept. 9, 2017, 9:02 p.m. UTC | #10

On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
> that works. So to address the Debian bug I can do:
> >
> >  - move sparse to /usr/lib
> >  - teach cgcc about the move of sparse
> >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> 
> I don't like that. It means the user can't invoke sparse directly.
> 
> >
> > or is it easier to teach sparse about the architecture stuff?
> 
> First of all. It is not very trivial to teach sparse about the architecture
> stuff. To my mind, we need to move all the cgcc logic into sparse.
> 
> For this case, I think it is easier to teach the sparse validation
> code to use cgcc on those back end testing. Most validation don't
> need to include system header file at all so it does not have
> this problem.
> 
> How about this patch?
> I know my patch is white space damaged in email.
> Git branch is at:
> https://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git/log/?h=llvm-cgcc
> 
> Please let me know if that fix your problem. It pass check
> on my local machine running x86_64. I don't have ppc64 to
> test with.
> 
> Chris
> 
> diff --git a/sparsec b/sparsec
> index 9dc96c9..2990d26 100755
> --- a/sparsec
> +++ b/sparsec
> @@ -32,7 +32,8 @@ done
>  TMPLLVM=`mktemp -t tmp.XXXXXX`".llvm"
>  TMPFILE=`mktemp -t tmp.XXXXXX`".o"
> 
> -$DIRNAME/sparse-llvm $SPARSEOPTS > $TMPLLVM
> +env CHECK=$DIRNAME/sparse-llvm $DIRNAME/cgcc -no-compile \
> +       $SPARSEOPTS > $TMPLLVM
> 
>  LLC=`"${LLVM_CONFIG:-llvm-config}" --bindir`/llc
> 
> diff --git a/sparsei b/sparsei
> index 3431a9f..3abd00f 100755
> --- a/sparsei
> +++ b/sparsei
> @@ -10,4 +10,4 @@ if [ $# -eq 0 ]; then
>    exit 1
>  fi
> 
> -$DIRNAME/sparse-llvm $@ | $LLI
> +env CHECK=$DIRNAME/sparse-llvm $DIRNAME/cgcc -no-compile $@ | $LLI

I tried this on ppc64le and it fixes 2 tests, so were at

	Out of 287 tests, 273 passed, 14 failed (10 of them are known to fail)

The repaired tests are:

	backend/hello.c
	backend/sum.c

unexpected failures are:

	backend/arithmetic-ops.c
	backend/cmp-ops.c
	backend/int-cond.c
	backend/logical-ops.c

These are not about missing preprocessor tokens as there are no system
includes used, but the error there is

	Error: unrecognized opcode: `...`

. I didn't look into what the problem is there, but attached the test
log.

I did a build test on a few other Debian machines, arm64 was fine, mips
and mipx64el had 15 failures, ppc64 (i.e. big endian) had 12. I didn't
look in more detail and suggest to tackle one after the other :-)

Best regards
Uwe
I: Started sh -c make && make check
O: make: Nothing to be done for 'all'.
O:      TEST    Woverride-init-def (Woverride-init-def.c)
O:      TEST    Woverride-init-no (Woverride-init-no.c)
O:      TEST    Woverride-init-yes (Woverride-init-yes.c)
O:      TEST    warn-unknown-attribute (Wunknown-attribute-def.c)
O:      TEST    warn-unknown-attribute-no (Wunknown-attribute-no.c)
O:      TEST    warn-unknown-attribute-yes (Wunknown-attribute-yes.c)
O:      TEST    __func__ (__func__.c)
O:      TEST    abstract array declarator static (abstract-array-declarator-static.c)
O:      TEST    address_space attribute (address_space.c)
O:      TEST    alias distinct symbols (alias-distinct.c)
O:      TEST    alias symbol/pointer (alias-mixed.c)
O:      TEST    alias same symbols (alias-same.c)
O:      TEST    attribute __alloc_align__ (alloc-align.c)
O:      TEST    alternate keywords (alternate-keywords.c)
O:      TEST    test anonymous union initializer (anon-union.c)
O:      TEST    Asm with goto labels. (asm-empty-clobber.c)
O:      TEST    Asm with goto labels. (asm-goto-lables.c)
O:      TEST    asm-toplevel.c (asm-toplevel.c)
O:      TEST    inline attributes (attr-inline.c)
O:      TEST    attribute no_sanitize_address (attr-no_sanitize_address.c)
O:      TEST    attribute noclone (attr-noclone.c)
O:      TEST    optimize attributes (attr-optimize.c)
O:      TEST    attribute warning (attr-warning.c)
O:      TEST    attribute assume_aligned (attr_aligned.c)
O:      TEST    attribute after ( in direct-declarator (attr_in_parameter.c)
O:      TEST    attribute vector_size (attr_vector_size.c)
O:      TEST    Arithmetic operator code generation (backend/arithmetic-ops.c)
O: error: actual error text does not match expected error text.
O: error: see backend/arithmetic-ops.c.error.* for further investigation.
O: --- backend/arithmetic-ops.c.error.expected	2017-09-09 20:44:47.964306005 +0000
O: +++ backend/arithmetic-ops.c.error.got	2017-09-09 20:44:47.960305943 +0000
O: @@ -0,0 +1,10 @@
O: +{standard input}: Assembler messages:
O: +{standard input}:38: Error: unrecognized opcode: `xsaddsp'
O: +{standard input}:52: Error: unrecognized opcode: `xsadddp'
O: +{standard input}:94: Error: unrecognized opcode: `xssubsp'
O: +{standard input}:108: Error: unrecognized opcode: `xssubdp'
O: +{standard input}:150: Error: unrecognized opcode: `xsmulsp'
O: +{standard input}:164: Error: unrecognized opcode: `xsmuldp'
O: +{standard input}:206: Error: unrecognized opcode: `xsdivsp'
O: +{standard input}:220: Error: unrecognized opcode: `xsdivdp'
O: +mv: cannot stat '/tmp/tmp.8axUUC.o': No such file or directory
O:      TEST    Array code generation (backend/array.c)
O:      TEST    Bitwise operator code generation (backend/bitwise-ops.c)
O:      TEST    Boolean type code generation (backend/bool-test.c)
O:      TEST    Cast code generation (backend/cast.c)
O:      TEST    Comparison operator code generation (backend/cmp-ops.c)
O: error: actual error text does not match expected error text.
O: error: see backend/cmp-ops.c.error.* for further investigation.
O: --- backend/cmp-ops.c.error.expected	2017-09-09 20:44:48.320311523 +0000
O: +++ backend/cmp-ops.c.error.got	2017-09-09 20:44:48.316311461 +0000
O: @@ -0,0 +1,18 @@
O: +{standard input}: Assembler messages:
O: +{standard input}:13: Error: unrecognized opcode: `isel'
O: +{standard input}:29: Error: unrecognized opcode: `isel'
O: +{standard input}:46: Error: unrecognized opcode: `isel'
O: +{standard input}:63: Error: unrecognized opcode: `isel'
O: +{standard input}:79: Error: unrecognized opcode: `isel'
O: +{standard input}:95: Error: unrecognized opcode: `isel'
O: +{standard input}:112: Error: unrecognized opcode: `isel'
O: +{standard input}:129: Error: unrecognized opcode: `isel'
O: +{standard input}:145: Error: unrecognized opcode: `isel'
O: +{standard input}:161: Error: unrecognized opcode: `isel'
O: +{standard input}:178: Error: unrecognized opcode: `isel'
O: +{standard input}:194: Error: unrecognized opcode: `isel'
O: +{standard input}:211: Error: unrecognized opcode: `isel'
O: +{standard input}:228: Error: unrecognized opcode: `isel'
O: +{standard input}:245: Error: unrecognized opcode: `isel'
O: +{standard input}:262: Error: unrecognized opcode: `isel'
O: +mv: cannot stat '/tmp/tmp.DoTA0H.o': No such file or directory
O:      TEST    Extern symbol code generation (backend/extern.c)
O:      TEST    Function pointer code generation (backend/function-ptr.c)
O:      TEST    'hello, world' code generation (backend/hello.c)
O:      TEST    Non-bool condition values in branch/select (backend/int-cond.c)
O: error: actual error text does not match expected error text.
O: error: see backend/int-cond.c.error.* for further investigation.
O: --- backend/int-cond.c.error.expected	2017-09-09 20:44:48.572315429 +0000
O: +++ backend/int-cond.c.error.got	2017-09-09 20:44:48.568315367 +0000
O: @@ -0,0 +1,4 @@
O: +{standard input}: Assembler messages:
O: +{standard input}:11: Error: unrecognized opcode: `isel'
O: +{standard input}:26: Error: unrecognized opcode: `isel'
O: +mv: cannot stat '/tmp/tmp.ytNQ13.o': No such file or directory
O:      TEST    Type of loaded objects (backend/load-type.c)
O:      TEST    Logical operator code generation (backend/logical-ops.c)
O: error: actual error text does not match expected error text.
O: error: see backend/logical-ops.c.error.* for further investigation.
O: --- backend/logical-ops.c.error.expected	2017-09-09 20:44:48.696317351 +0000
O: +++ backend/logical-ops.c.error.got	2017-09-09 20:44:48.692317289 +0000
O: @@ -0,0 +1,4 @@
O: +{standard input}: Assembler messages:
O: +{standard input}:14: Error: unrecognized opcode: `isel'
O: +{standard input}:32: Error: unrecognized opcode: `isel'
O: +mv: cannot stat '/tmp/tmp.onWlTP.o': No such file or directory
O:      TEST    Loops (backend/loop.c)
O:      TEST    Loops with unused counter (backend/loop2.c)
O:      TEST    Pointer cast code generation (backend/ptrcast.c)
O:      TEST    Type of stored objects (backend/store-type.c)
O:      TEST    struct access code generation (backend/struct-access.c)
O:      TEST    Struct code generation (backend/struct.c)
O:      TEST    sum from 1 to n (backend/sum.c)
O:      TEST    Union code generation (backend/union.c)
O:      TEST    void return type code generation (backend/void-return-type.c)
O:      TEST    Bad array designated initializer (bad-array-designated-initializer.c)
O:      TEST    bad assignment (bad-assignment.c)
O:      TEST    Bad cast syntax (bad-cast.c)
O:      TEST    Bad ternary syntax (bad-ternary-cond.c)
O:      TEST    Bad typeof syntax segfault (bad-typeof.c)
O:      TEST    enum not in scope (badtype1.c)
O: info: test 'badtype1.c' is known to fail
O:      TEST    missing type (badtype2.c)
O:      TEST    missing type in argument list (badtype3.c)
O:      TEST    switch(bad_type) {...} segfault (badtype4.c)
O:      TEST    badtype5.c (badtype5.c)
O:      TEST    binary constant (binary-constant.c)
O:      TEST    bitfield size (bitfield-size.c)
O:      TEST    bitfield to integer promotion (bitfields.c)
O:      TEST    conversions to bitwise types (bitwise-cast.c)
O:      TEST    sizeof(bool array) (bool-array.c)
O:      TEST    bool-cast-bad.c (bool-cast-bad.c)
O:      TEST    bool-cast-explicit (bool-cast-explicit.c)
O:      TEST    bool-cast-implicit (bool-cast-implicit.c)
O:      TEST    bool-cast-restricted.c (bool-cast-restricted.c)
O:      TEST    constant folding in bswap builtins (bswap-constant-folding.c)
O:      TEST    inlining switch statement (bug_inline_switch.c)
O:      TEST    builtin-args-checking (builtin-args-checking.c)
O:      TEST    builtin-bswap-constant (builtin-bswap-constant.c)
O:      TEST    builtin-bswap (builtin-bswap-variable.c)
O:      TEST    __builtin_atomic (builtin_atomic.c)
O:      TEST    __builtin_bswap (builtin_bswap.c)
O:      TEST    __builtin INFINITY / nan() (builtin_inf.c)
O:      TEST    __builtin_safe (builtin_safe1.c)
O:      TEST    __builtin_unreachable() (builtin_unreachable.c)
O:      TEST    __builtin_va_arg_pack() (builtin_va_arg_pack.c)
O:      TEST    c11-alignas (c11-alignas.c)
O:      TEST    c11-alignof (c11-alignof.c)
O:      TEST    c11-noreturn (c11-noreturn.c)
O:      TEST    c11-stdc-version (c11-stdc-version.c)
O:      TEST    c11-thread-local (c11-thread-local.c)
O:      TEST    C99 for-loop declarations (c99-for-loop-decl.c)
O:      TEST    C99 for loop variable declaration (c99-for-loop.c)
O:      TEST    Calling convention attributes (calling-convention-attributes.c)
O:      TEST    cast-constant-to-float (cast-constant-to-float.c)
O:      TEST    cast-constants.c (cast-constants.c)
O:      TEST    cast-kinds (cast-kinds.c)
O:      TEST    Segfault in check_byte_count after syntax error (check_byte_count-ice.c)
O:      TEST    choose expr builtin (choose_expr.c)
O:      TEST    Comma and array decay (comma.c)
O:      TEST    Compare null pointer constant to int (compare-null-to-int.c)
O:      TEST    compound-assign-type (compound-assign-type.c)
O:      TEST    cond-address-array.c (cond-address-array.c)
O:      TEST    cond-address-function (cond-address-function.c)
O:      TEST    cond-address.c (cond-address.c)
O:      TEST    cond-err-expand.c (cond-err-expand.c)
O:      TEST    Two-argument conditional expression types (cond_expr.c)
O:      TEST    type of conditional expression (cond_expr2.c)
O:      TEST    result type of relational and logical operators (cond_expr3.c)
O:      TEST    conditional-type (conditional-type.c)
O:      TEST    address of static object's member constness verification. (constexpr-addr-of-static-member.c)
O:      TEST    address of static object constness verification. (constexpr-addr-of-static.c)
O:      TEST    Expression constness propagation in binops and alike (constexpr-binop.c)
O:      TEST    Expression constness propagation in casts (constexpr-cast.c)
O:      TEST    compound literal address constness verification (constexpr-compound-literal.c)
O:      TEST    Expression constness propagation in conditional expressions (constexpr-conditional.c)
O:      TEST    static storage object initializer constness verification. (constexpr-init.c)
O:      TEST    label reference constness verification. (constexpr-labelref.c)
O:      TEST    __builtin_offsetof() constness verification. (constexpr-offsetof.c)
O:      TEST    pointer arithmetic constness verification. (constexpr-pointer-arith.c)
O:      TEST    integer literal cast to pointer type constness verification. (constexpr-pointer-cast.c)
O:      TEST    Expression constness propagation in preops (constexpr-preop.c)
O:      TEST    constness of pure/const builtins (constexpr-pure-builtin.c)
O:      TEST    string literal constness verification. (constexpr-string.c)
O:      TEST    __builtin_types_compatible_p() constness verification. (constexpr-types-compatible-p.c)
O:      TEST    Check -Wcontext (context.c)
O:      TEST    crash add-doms (crash-add-doms.c)
O:      TEST    crash bb_target (crash-bb_target.c)
O:      TEST    crash ep->active (crash-ep-active.c)
O:      TEST    crash ptrlist (crash-ptrlist.c)
O:      TEST    crash rewrite_branch (crash-rewrite-branch.c)
O:      TEST    crazy02-not-so.c (crazy02-not-so.c)
O:      TEST    crazy03.c (crazy03.c)
O:      TEST    declaration after statement (ANSI) (declaration-after-statement-ansi.c)
O:      TEST    declaration after statement (C89) (declaration-after-statement-c89.c)
O:      TEST    declaration after statement (C99) (declaration-after-statement-c99.c)
O:      TEST    declaration after statement (default) (declaration-after-statement-default.c)
O:      TEST    finding definitions (definitions.c)
O:      TEST    designated_init attribute (designated-init.c)
O:      TEST    discarded-label-statement (discarded-label-statement.c)
O:      TEST    division constants (div.c)
O:      TEST    Double semicolon in struct (double-semicolon.c)
O:      TEST    Dubious bitwise operation on !x (dubious-bitwise-with-not.c)
O:      TEST    endian-big.c (endian-big.c)
O:      TEST    endian-little.c (endian-little.c)
O:      TEST    enum-mismatch (enum-mismatch.c)
O:      TEST    enumeration constants' scope [6.2.1p7] (enum_scope.c)
O:      TEST    Character escape sequences (escapes.c)
O:      TEST    duplicate extern array (extern-array.c)
O:      TEST    extern inline function (extern-inline.c)
O:      TEST    field overlap (field-overlap.c)
O:      TEST    field-override (field-override.c)
O:      TEST    Forced function argument type. (fored_arg.c)
O:      TEST    foul bitwise (foul-bitwise.c)
O:      TEST    fp-vs-ptrcast (fp-vs-ptrcast.c)
O:      TEST    Function pointer inheritance (function-pointer-inheritance.c)
O:      TEST    function-redecl (function-redecl.c)
O:      TEST    goto labels (goto-label.c)
O:      TEST    identifier-list parsing (identifier_list.c)
O:      TEST    implicit-ret-type.c (implicit-ret-type.c)
O:      TEST    implicit-type.c (implicit-type.c)
O:      TEST    internal infinite loop (0) (infinite-loop0.c)
O:      TEST    infinite loop 02 (infinite-loop02.c)
O:      TEST    infinite loop 03 (infinite-loop03.c)
O:      TEST    char array initializers (init-char-array.c)
O:      TEST    parenthesized string initializer (init-char-array1.c)
O:      TEST    -Winit-cstring option (init_cstring.c)
O:      TEST    Initializer entry defined twice (initializer-entry-defined-twice.c)
O:      TEST    inline compound literals (inline_compound_literals.c)
O:      TEST    int128 (int128.c)
O:      TEST    Integer promotions (integer-promotions.c)
O:      TEST    integer constant & conditional expression (ioc-typecheck.c)
O: info: test 'ioc-typecheck.c' is known to fail
O:      TEST    kill-casts (kill-casts.c)
O:      TEST    kill-computedgoto (kill-computedgoto.c)
O:      TEST    kill-cse (kill-cse.c)
O:      TEST    kill insert-branch (kill-insert-branch.c)
O:      TEST    kill-load (kill-load.c)
O:      TEST    kill-phi-node (kill-phi-node.c)
O:      TEST    kill-phi-ttsbb (kill-phi-ttsbb.c)
O:      TEST    kill-phi-ttsbb2 (kill-phi-ttsbb2.c)
O:      TEST    kill-phisrc (kill-phisrc.c)
O:      TEST    kill-pure-call (kill-pure-call.c)
O:      TEST    kill-replaced-insn (kill-replaced-insn.c)
O:      TEST    kill-rewritten-load (kill-rewritten-load.c)
O:      TEST    kill-select (kill-select.c)
O:      TEST    kill-slice (kill-slice.c)
O:      TEST    kill-store (kill-store.c)
O:      TEST    kill-unreachable-phi (kill-unreachable-phi.c)
O:      TEST    Label followed by __asm__ (label-asm.c)
O:      TEST    Label attribute (label-attr.c)
O:      TEST    label-expr (label-expr.c)
O:      TEST    __label__ scope (label-scope.c)
O:      TEST    bitfield initializer mask (linear/bitfield-init-mask.c)
O:      TEST    bitfield implicit init zero (linear/bitfield-init-zero.c)
O:      TEST    missing instruction's size (linear/missing-insn-size.c)
O:      TEST    struct implicit init zero not needed (linear/struct-init-full.c)
O: info: test 'linear/struct-init-full.c' is known to fail
O:      TEST    struct implicit init zero needed (linear/struct-init-partial.c)
O:      TEST    Local label (local-label.c)
O:      TEST    Logical and/or (logical.c)
O:      TEST    loop-linearization (loop-linearization.c)
O:      TEST    Expansion of typeof when dealing with member of struct (member_of_typeof.c)
O:      TEST    memops-volatile (memops-volatile.c)
O:      TEST    handling of identifier-less declarations (missing-ident.c)
O:      TEST    typedefs with many declarators (multi_typedef.c)
O:      TEST    nested declarator vs. parameters (nested-declarator.c)
O:      TEST    more on handling of ( in direct-declarator (nested-declarator2.c)
O:      TEST    nocast.c (nocast.c)
O:      TEST    noderef attribute (noderef.c)
O:      TEST    Using plain integer as NULL pointer (non-pointer-null.c)
O:      TEST    Old initializer with -Wno-old-initializer (old-initializer-nowarn.c)
O:      TEST    Old initializer (old-initializer.c)
O:      TEST    double-unop (optim/binops-same-args.c)
O:      TEST    bool-context (optim/bool-context.c)
O:      TEST    bool-same-args (optim/bool-same-args.c)
O:      TEST    bool-simplify (optim/bool-simplify.c)
O:      TEST    cse-commutativity (optim/cse-commutativity.c)
O:      TEST    cse-dual-compare (optim/cse-dual-compare.c)
O: info: test 'optim/cse-dual-compare.c' is known to fail
O:      TEST    double-unop (optim/double-unop.c)
O:      TEST    fpcast-nop (optim/fpcast-nop.c)
O:      TEST    muldiv-by-one (optim/muldiv-by-one.c)
O:      TEST    muldiv-by-zero (optim/muldiv-by-zero.c)
O:      TEST    muldiv-minus-one (optim/muldiv-minus-one.c)
O:      TEST    optim/setcc-setcc (optim/setcc-setcc.c)
O:      TEST    optim/setcc-seteq (optim/setcc-seteq.c)
O:      TEST    optim/setcc-setne (optim/setcc-setne.c)
O:      TEST    Ignore VOID in if-convert (optim/void-if-convert.c)
O:      TEST    There is no scope boundary between global and file scope (outer-scope.c)
O:      TEST    #pragma once (pragma-once.c)
O:      TEST    __COUNTER__ #1 (preprocessor/counter1.c)
O:      TEST    __COUNTER__ #2 (preprocessor/counter2.c)
O:      TEST    __COUNTER__ #3 (preprocessor/counter3.c)
O:      TEST    dump-macros with empty file (preprocessor/dump-macros-empty.c)
O:      TEST    dump-macros with multiple files (preprocessor/dump-macros-multi.c)
O:      TEST    dump-macros (preprocessor/dump-macros.c)
O:      TEST    early-escape (preprocessor/early-escape.c)
O:      TEST    predefined __<type>_BIT__ (preprocessor/predef-char-bit.c)
O:      TEST    predefined __<type>_MAX__ (preprocessor/predef-max.c)
O:      TEST    predefined __SIZEOF_<type>__ (preprocessor/predef-sizeof.c)
O:      TEST    Preprocessor #1 (preprocessor/preprocessor1.c)
O:      TEST    Preprocessor #10 (preprocessor/preprocessor10.c)
O:      TEST    Preprocessor #11 (preprocessor/preprocessor11.c)
O:      TEST    Preprocessor #12 (preprocessor/preprocessor12.c)
O:      TEST    Preprocessor #13 (preprocessor/preprocessor13.c)
O:      TEST    Preprocessor #14 (preprocessor/preprocessor14.c)
O:      TEST    Preprocessor #15 (preprocessor/preprocessor15.c)
O:      TEST    Preprocessor #16 (preprocessor/preprocessor16.c)
O:      TEST    Preprocessor #17 (preprocessor/preprocessor17.c)
O:      TEST    Preprocessor #18 (preprocessor/preprocessor18.c)
O:      TEST    Preprocessor #19 (preprocessor/preprocessor19.c)
O:      TEST    Preprocessor #2 (preprocessor/preprocessor2.c)
O:      TEST    Preprocessor #20 (preprocessor/preprocessor20.c)
O:      TEST    Preprocessor #21 (preprocessor/preprocessor21.c)
O:      TEST    Preprocessor #22 (preprocessor/preprocessor22.c)
O:      TEST    Preprocessor #23 (preprocessor/preprocessor23.c)
O:      TEST    Preprocessor #3 (preprocessor/preprocessor3.c)
O:      TEST    Preprocessor #4 (preprocessor/preprocessor4.c)
O:      TEST    Preprocessor #5 (preprocessor/preprocessor5.c)
O:      TEST    Preprocessor #6 (preprocessor/preprocessor6.c)
O:      TEST    Preprocessor #7 (preprocessor/preprocessor7.c)
O:      TEST    Preprocessor #8 (preprocessor/preprocessor8.c)
O:      TEST    Preprocessor #9 (preprocessor/preprocessor9.c)
O:      TEST    Preprocessor #14 (preprocessor/stringify.c)
O:      TEST    wide char token-pasting (preprocessor/wide.c)
O:      TEST    Compile skip function prototype (prototype.c)
O:      TEST    ptr-inherit.c (ptr-inherit.c)
O:      TEST    Pure function attribute (pure-function.c)
O:      TEST    const et.al. are reserved identifiers (reserved.c)
O:      TEST    restrict array attribute (restrict-array.c)
O:      TEST    typeof with bitwise types (restricted-typeof.c)
O:      TEST    sizeof(_Bool) is valid (sizeof-bool.c)
O:      TEST    Handling of sizeof compound-literal . member (sizeof-compound-postfix.c)
O:      TEST    valid specifier combinations (specifiers1.c)
O:      TEST    invalid specifier combinations (specifiers2.c)
O:      TEST    static forward declaration (static-forward-decl.c)
O:      TEST    static assertion (static_assert.c)
O:      TEST    Address space of a struct member (struct-as.c)
O:      TEST    struct attribute placement (struct-attribute-placement.c)
O:      TEST    struct namespaces #1 (struct-ns1.c)
O:      TEST    struct not in scope (struct-ns2.c)
O: info: test 'struct-ns2.c' is known to fail
O:      TEST    struct size (struct-size1.c)
O:      TEST    tautological-compare (tautological-compare.c)
O:      TEST    binary operations (test-be.c)
O:      TEST    selfcheck1 (testsuite-selfcheck1.c)
O:      TEST    selfcheck2 (testsuite-selfcheck2.c)
O: info: test 'testsuite-selfcheck2.c' is known to fail
O:      TEST    selfcheck3 (testsuite-selfcheck3.c)
O: info: test 'testsuite-selfcheck3.c' is known to fail
O:      TEST    Transparent union attribute. (transparent-union.c)
O:      TEST    "char []" to "char *" demotion (type1.c)
O:      TEST    typedef shadowing (typedef_shadow.c)
O:      TEST    typeof-addresspace.c (typeof-addresspace.c)
O: info: test 'typeof-addresspace.c' is known to fail
O:      TEST    Rusty Russell's typeof attribute casting. (typeof-attribute.c)
O:      TEST    typeof-mods (typeof-mods.c)
O:      TEST    typeof-noderef (typeof-noderef.c)
O: info: test 'typeof-noderef.c' is known to fail
O:      TEST    typeof-safe (typeof-safe.c)
O: info: test 'typeof-safe.c' is known to fail
O:      TEST    -Wtypesign (typesign.c)
O:      TEST    Varargs bogus warning regression test #1 (varargs1.c)
O:      TEST    wide character constants (wide.c)
E: make: *** [check] Error 1
O: Out of 287 tests, 273 passed, 14 failed (10 of them are known to fail)
O: Makefile:232: recipe for target 'check' failed
I: Finished with exitcode 2

Luc Van Oostenryck Sept. 10, 2017, 1:22 a.m. UTC | #11

On Sat, Sep 9, 2017 at 11:02 PM, Uwe Kleine-König <[e-mail]> wrote:
>
> I tried this on ppc64le and it fixes 2 tests, so were at
>
>         Out of 287 tests, 273 passed, 14 failed (10 of them are known to fail)
>
> The repaired tests are:
>
>         backend/hello.c
>         backend/sum.c
>
> unexpected failures are:
>
>         backend/arithmetic-ops.c
>         backend/cmp-ops.c
>         backend/int-cond.c
>         backend/logical-ops.c
>
> These are not about missing preprocessor tokens as there are no system
> includes used, but the error there is
>
>         Error: unrecognized opcode: `...`
>
> . I didn't look into what the problem is there, but attached the test
> log.

It clearly looks as the code generated by LLVM  (the machine code/assembly
not LLVM's bytecode) is not understood by the assembler (or at least some
instructions). Probably a mismatch with the architecture version or something
like that.

> I did a build test on a few other Debian machines, arm64 was fine, mips
> and mipx64el had 15 failures, ppc64 (i.e. big endian) had 12. I didn't
> look in more detail and suggest to tackle one after the other :-)

I fully test on x86, x86-64, arm & ARM64 (with LLVM 3.9 or 4.0).
I also test on ppc64 but not the LLVM part because the machines I have
access to have not LLVM installed and I never bothered to install it myself.

Would it be possible to have access to a machine with the architectures
you care about?

Meanwhile, is it possible to have the build logs but with 'make V=1 ...' ?
It would also be useful to have:
- the output of 'uname -a'
- the details about the version of LLVM you're using

On the other hand, you/us should disable the sparse-llvm part since:
- it's something that is bundled and build by default but absolutely not
  needed (or even useful) to use sparse.
- it hasn't been written for anything else than x86/x86-64 (no 'layout'
  for anything else than those architectures.

Best regards,
-- Luc Van Ooostenryck
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Uwe Kleine-König Sept. 10, 2017, 8:43 a.m. UTC | #12

On 09/10/2017 03:22 AM, Luc Van Oostenryck wrote:
> On Sat, Sep 9, 2017 at 11:02 PM, Uwe Kleine-König <[e-mail]> wrote:
>>
>> I tried this on ppc64le and it fixes 2 tests, so were at
>>
>>         Out of 287 tests, 273 passed, 14 failed (10 of them are known to fail)
>>
>> The repaired tests are:
>>
>>         backend/hello.c
>>         backend/sum.c
>>
>> unexpected failures are:
>>
>>         backend/arithmetic-ops.c
>>         backend/cmp-ops.c
>>         backend/int-cond.c
>>         backend/logical-ops.c
>>
>> These are not about missing preprocessor tokens as there are no system
>> includes used, but the error there is
>>
>>         Error: unrecognized opcode: `...`
>>
>> . I didn't look into what the problem is there, but attached the test
>> log.
> 
> It clearly looks as the code generated by LLVM  (the machine code/assembly
> not LLVM's bytecode) is not understood by the assembler (or at least some
> instructions). Probably a mismatch with the architecture version or something
> like that.
> 
>> I did a build test on a few other Debian machines, arm64 was fine, mips
>> and mipx64el had 15 failures, ppc64 (i.e. big endian) had 12. I didn't
>> look in more detail and suggest to tackle one after the other :-)
> 
> I fully test on x86, x86-64, arm & ARM64 (with LLVM 3.9 or 4.0).
> I also test on ppc64 but not the LLVM part because the machines I have
> access to have not LLVM installed and I never bothered to install it myself.
> 
> Would it be possible to have access to a machine with the architectures
> you care about?

Debian provides access to porter boxes for such problems. See
https://dsa.debian.org/doc/guest-account/.

> Meanwhile, is it possible to have the build logs but with 'make V=1 ...' ?
> It would also be useful to have:
> - the output of 'uname -a'
> - the details about the version of LLVM you're using

Sure, can do. Attached is a build from the ppc64el machine with Chris'
patch applied. Tell me if it contains everything you need.

> On the other hand, you/us should disable the sparse-llvm part since:
> - it's something that is bundled and build by default but absolutely not
>   needed (or even useful) to use sparse.
> - it hasn't been written for anything else than x86/x86-64 (no 'layout'
>   for anything else than those architectures.

With your patch applied I get (independent of having Chris' patch
applied or not):

	Out of 265 tests, 255 passed, 10 failed (10 of them are known to fail)

Best regards
Uwe

Luc Van Oostenryck Sept. 10, 2017, 9:39 a.m. UTC | #13

On Sun, Sep 10, 2017 at 10:43 AM, Uwe Kleine-König
<[e-mail]> wrote:
> On 09/10/2017 03:22 AM, Luc Van Oostenryck wrote:
>>
>> I fully test on x86, x86-64, arm & ARM64 (with LLVM 3.9 or 4.0).
>> I also test on ppc64 but not the LLVM part because the machines I have
>> access to have not LLVM installed and I never bothered to install it myself.
>>
>> Would it be possible to have access to a machine with the architectures
>> you care about?
>
> Debian provides access to porter boxes for such problems. See
> https://dsa.debian.org/doc/guest-account/.

OK.
I'll first try to install LLVM on what I have already access, it
should be faster.

>> Meanwhile, is it possible to have the build logs but with 'make V=1 ...' ?
>> It would also be useful to have:
>> - the output of 'uname -a'
>> - the details about the version of LLVM you're using
>
> Sure, can do. Attached is a build from the ppc64el machine with Chris'
> patch applied. Tell me if it contains everything you need.

Yes, enough to investigate the problem. Thanks.

>> On the other hand, you/us should disable the sparse-llvm part since:
>> - it's something that is bundled and build by default but absolutely not
>>   needed (or even useful) to use sparse.
>> - it hasn't been written for anything else than x86/x86-64 (no 'layout'
>>   for anything else than those architectures.
>
> With your patch applied I get (independent of having Chris' patch
> applied or not):
>
>         Out of 265 tests, 255 passed, 10 failed (10 of them are known to fail)

Perfect.
With this, you should be unblocked.

@Chris,
can you apply the patch, please?


Best regards,
-- Luc Van Oostenryck
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Luc Van Oostenryck Sept. 10, 2017, 12:29 p.m. UTC | #14

On Sun, Sep 10, 2017 at 10:43 AM, Uwe Kleine-König
<[e-mail]> wrote:
>
>> Meanwhile, is it possible to have the build logs but with 'make V=1 ...' ?
>> It would also be useful to have:
>> - the output of 'uname -a'
>> - the details about the version of LLVM you're using
>
> Sure, can do. Attached is a build from the ppc64el machine with Chris'
> patch applied. Tell me if it contains everything you need.

I've taken a look at it what happens.
The problem is easy to identify and very annoying to solve:
in sparsec (a wrapper for sparse-llvm + llc + as [+ ld]) there
is a discrepancy between the defaults for llc and as.
'llc' seems to default to the sub-architecture of the build machine
(possibly including the most modern features) while 'as' defaults
to the minimal features for the build machine architecture.

The problem can be solved (on the machine I have access to) by either:
- using the option "-mgeneric" for llc
- using the option "-mpower8" for as

Something smarter would be better.

-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Christopher Li Sept. 12, 2017, 5:59 a.m. UTC | #15

On Wed, Sep 6, 2017 at 11:36 AM, Uwe Kleine-König <[e-mail]> wrote:
> There is https://dsa.debian.org/doc/guest-account/ which would give you
> the possibility to access some Debian machines. Other than that I intend

Sorry for the delay. Thanks for the pointer of the guest account.

> to upload 0.5.1 to Debian soon and then can provide you links to build
> failures in the build server farm :-) And if you have a patch, I can
> volunteer to make the test monkey for you.

BTW, if I want to get a PPC64 machine for Linux testing purpose, is the
used apple G5 a good place to start?

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Uwe Kleine-König Sept. 12, 2017, 6:27 a.m. UTC | #16

On Tue, Sep 12, 2017 at 01:59:47AM -0400, Christopher Li wrote:
> On Wed, Sep 6, 2017 at 11:36 AM, Uwe Kleine-König <[e-mail]> wrote:
> > There is https://dsa.debian.org/doc/guest-account/ which would give you
> > the possibility to access some Debian machines. Other than that I intend
> 
> Sorry for the delay. Thanks for the pointer of the guest account.

Tell me if you want to do that. And plan for a delay because there is
some "paper work" to be done before; mainly by other people, so it might
(or might not) take a moment.

> > to upload 0.5.1 to Debian soon and then can provide you links to build
> > failures in the build server farm :-) And if you have a patch, I can
> > volunteer to make the test monkey for you.
> 
> BTW, if I want to get a PPC64 machine for Linux testing purpose, is the
> used apple G5 a good place to start?

Honestly I don't know. https://wiki.debian.org/ppc64el tells

	Debian/ppc64el requires, at minimum, a POWER8 processor machine.
	Although Debian was initially bootstrapped on a POWER7 set of
	servers. this class of server is not supported anymore, and you
	are not able to run Debian/ppc64el on a POWER7 processor without
	hitting an illegal instruction fault.

Hm https://en.wikipedia.org/wiki/POWER8 tells:

	Systems based on POWER8 became available from IBM in June
	2014. Systems and POWER8 processor designs made by other
	OpenPOWER members was available in early 2015.

So I think this rules out a G5.

https://wiki.debian.org/ppc64el/Installation mentions you can run this
under qemu however.

Best regards
Uwe

Christopher Li Sept. 12, 2017, 6:36 a.m. UTC | #17

On Tue, Sep 12, 2017 at 2:27 AM, Uwe Kleine-König <[e-mail]> wrote:
>> BTW, if I want to get a PPC64 machine for Linux testing purpose, is the
>> used apple G5 a good place to start?
>
> Honestly I don't know. https://wiki.debian.org/ppc64el tells
>
>         Debian/ppc64el requires, at minimum, a POWER8 processor machine.
>         Although Debian was initially bootstrapped on a POWER7 set of
>         servers. this class of server is not supported anymore, and you
>         are not able to run Debian/ppc64el on a POWER7 processor without
>         hitting an illegal instruction fault.
>
> Hm https://en.wikipedia.org/wiki/POWER8 tells:
>
>         Systems based on POWER8 became available from IBM in June
>         2014. Systems and POWER8 processor designs made by other
>         OpenPOWER members was available in early 2015.
>
> So I think this rules out a G5.

Thanks for the tip. I am glad I asked before I pull the trigger.

> https://wiki.debian.org/ppc64el/Installation mentions you can run this
> under qemu however.

Good idea. I will give that a try too.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/sparsec b/sparsec
index 9dc96c9..2990d26 100755
--- a/sparsec
+++ b/sparsec
@@ -32,7 +32,8 @@  done
 TMPLLVM=`mktemp -t tmp.XXXXXX`".llvm"
 TMPFILE=`mktemp -t tmp.XXXXXX`".o"

-$DIRNAME/sparse-llvm $SPARSEOPTS > $TMPLLVM
+env CHECK=$DIRNAME/sparse-llvm $DIRNAME/cgcc -no-compile \
+       $SPARSEOPTS > $TMPLLVM

 LLC=`"${LLVM_CONFIG:-llvm-config}" --bindir`/llc

diff --git a/sparsei b/sparsei
index 3431a9f..3abd00f 100755
--- a/sparsei
+++ b/sparsei
@@ -10,4 +10,4 @@  if [ $# -eq 0 ]; then
   exit 1
 fi

-$DIRNAME/sparse-llvm $@ | $LLI
+env CHECK=$DIRNAME/sparse-llvm $DIRNAME/cgcc -no-compile $@ | $LLI