[PATCH 0/4] chrisl master branch patches

[PATCH 0/4] chrisl master branch patches

[Ramsay Jones]

Hi Chris,

I noticed, this afternoon, that you have pushed new patches to your
public repo on kernel.org (including most of the patches from my
'misc sparse patches' series). After a quick test, I noticed a few
minor problems (see first two patches).

I don't know how you like to manage your public repo, but if you
don't mind re-winding your master branch, then you could squash
patch #1 into commit e23abfd and patch #2 into fe57afa.

The third patch is actually a re-send of one I sent separately
after the 10 patch series.

The final patch is a possible alternative to "[PATCH 04/10]
compile-i386.c: don't mix calls to write(2) with stdio", which
basically just removes the compile program. If you prefer
another solution, just let me know.

[Note: I have been living with the RFC patch #10 for quite a
while now with no problems. However, it was just a quick hack
to speed up cgcc/sparse on Cygwin and, on reflection, not a
good reason to introduce a sparse configuration file! Also, the
use of the perl language for the config file can be viewed as
a bit cute (too cute for some people). I will probably keep it
as a locally applied patch on cygwin (it is a noticeable speedup
on cygwin), but remove it on Linux.]

Ramsay Jones (4):
  test-suite: remove bashism to avoid test failures
  cgcc: avoid passing a sparse-only option to cc
  parse.c: remove duplicate 'may_alias' ignored_attributes
  compile: remove the unmaintained compile program

 .gitignore            |    1 -
 Makefile              |    4 +-
 cgcc                  |    4 +-
 compile-i386.c        | 2407 -------------------------------------------------
 compile.c             |   84 --
 compile.h             |   10 -
 parse.c               |    2 -
 validation/test-suite |    2 +-
 8 files changed, 4 insertions(+), 2510 deletions(-)
 delete mode 100644 compile-i386.c
 delete mode 100644 compile.c
 delete mode 100644 compile.h

-- 
2.1.0

Re: [PATCH 0/4] chrisl master branch patches

[Christopher Li]

On Sun, Oct 12, 2014 at 3:55 AM, Ramsay Jones
<ramsay@ramsay1.demon.co.uk> wrote:
> Hi Chris,
>
> I don't know how you like to manage your public repo, but if you
> don't mind re-winding your master branch, then you could squash
> patch #1 into commit e23abfd and patch #2 into fe57afa.

I should have try the review branch. Now it is push to master.
I can't rewind it.
>
> The final patch is a possible alternative to "[PATCH 04/10]
> compile-i386.c: don't mix calls to write(2) with stdio", which
> basically just removes the compile program. If you prefer
> another solution, just let me know.

I think I would just keep it as example of using the sparse
front end AST. For compiling, the sparse-llvm does a better job
there.

>
> [Note: I have been living with the RFC patch #10 for quite a
> while now with no problems. However, it was just a quick hack
> to speed up cgcc/sparse on Cygwin and, on reflection, not a
> good reason to introduce a sparse configuration file! Also, the
> use of the perl language for the config file can be viewed as
> a bit cute (too cute for some people). I will probably keep it
> as a locally applied patch on cygwin (it is a noticeable speedup
> on cygwin), but remove it on Linux.]

It seems scary the config file you can put any perl code there.
Any way, I think in the long term, it is better move cgcc stuff
into sparse. So sparse do not need to have a wrapper to setup
the compiling environment. To speed up things, it is best
to invoke sparse without a wrapper. That is how it is done in
the kernel checking.

Chris

Re: [PATCH 0/4] chrisl master branch patches

[Ramsay Jones]

On 12/10/14 10:22, Christopher Li wrote:
> On Sun, Oct 12, 2014 at 3:55 AM, Ramsay Jones
> <ramsay@ramsay1.demon.co.uk> wrote:

[snip]

>> The final patch is a possible alternative to "[PATCH 04/10]
>> compile-i386.c: don't mix calls to write(2) with stdio", which
>> basically just removes the compile program. If you prefer
>> another solution, just let me know.
> 
> I think I would just keep it as example of using the sparse
> front end AST. For compiling, the sparse-llvm does a better job
> there.
> 

OK, I will send an alternative patch separately (directly after this).

ATB,
Ramsay Jones