Re: [Cocci] Supporting Coccinelle software
On 20200214@12:52, Markus Elfring wrote: > > And because Coccinelle is free software, I could inspect > > Coccinelle and even adapt a few minimal things to my needs! > Would you like to share a bit more information about such adjustments? I cloned coccinelle's GIT repository, I suggested a patch, and the patch has been accepted. That is not possible with non-free software. ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] Thank you for Coccinelle!
Dear Coccinelle Developers, today being "I Love Free Software" / https://ilovefs.org I thank you for developing such a fantastic software like Coccinelle! I work in scientific / HPC computing and Coccinelle helped my work in achieving what was previously unachievable, or slow or extremely error-prone. And because Coccinelle is free software, I could inspect Coccinelle and even adapt a few minimal things to my needs! And you, fellow mailing list subscribers, how did Coccinelle improve your work ? And, dear Coccinelle devels, what we users can do to ensure good health to the Coccinelle project ? Long life to Coccinelle and its developers! Michele signature.asc Description: PGP signature ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] [PATCH] clarify misleading warning message
One may think that when warning that "should %s be a metavariable?" Coccinelle also treats a given symbol %s as a metavariable. Better state explicitly that this is not the case. --- parsing_cocci/check_meta.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/parsing_cocci/check_meta.ml b/parsing_cocci/check_meta.ml index e728d8f5..b857d3f6 100644 --- a/parsing_cocci/check_meta.ml +++ b/parsing_cocci/check_meta.ml @@ -84,7 +84,7 @@ let rec ident context old_metas table minus i = not err(* warn only once per id *) && not info.Ast0.isSymbolIdent then warning - (Printf.sprintf "line %d: should %s be a metavariable?" rl name) + (Printf.sprintf "line %d: should %s be a metavariable? treating it as symbol." rl name) | _ -> ()) | Ast0.MetaId(name,_,seedval,_) -> check_table table minus name; -- 2.20.1 ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] Munich, Germany, Oct. 8th: Intro to Semantic Patching with Coccinelle
Dear Kernel Hackers, Coccinelle is a tool routinely used to automatically upgrade Linux kernel drivers, or catch certain bugs in C programs, or to restructure C programs. So some of you may be interested in the following event I'm holding near Munich, Germany: *** "Introduction to Semantic Patching of C programs with Coccinelle" Tuesday, October 8, 2019, 10:00 - 17:00 Leibniz Supercomputing Centre (LRZ) of the Bavarian Academy of Sciences and Humanities, Garching near Munich, Boltzmannstr. 1 The maintenance of a large software project can be very demanding. External factors like evolving third-party software library APIs, or constantly changing hardware platforms might require significant code adaptions for the code to run efficiently, or to run at all. Failure in coping with this can lead to obsolescence, loss of performance, incompatibility, vendor lock-in, bugs. Have you ever wondered how to detect and manipulate specified classes of C code constructs, be it for code analysis, or better, to restructure an arbitrarily large codebase according to a specified, non-trivial `pattern', without writing a C compiler? In this training we introduce you to a tool to do exactly this: match and restructure C codebases in a programmatic, formal way. The training will also show how to analyze code looking for interesting patterns (e.g. bugs), integrate with your Python scripts to achieve the custom transformations you need, and leverage Coccinelle's limited C++ support. Special attention will be on performance-oriented transformations, of other interests of HPC practitioners. After this training, you shall be able to write your own code transformations, be it for a refactoring, performance improvement, paving the way to an experimental fork, or for debugging and further analysis. Teacher: Dr. Michele Martone (LRZ) Registration and further information https://www.lrz.de/services/compute/courses/2019-10-08_hspc1w19/ *** signature.asc Description: PGP signature ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] [PATCH] --c++ --test will assume .cpp extension, not .c
--c++ --test will assume .cpp extension, not .c Signed-off-by: Michele Martone --- diff --git a/testing.ml b/testing.ml index 258e6c6f..784040fe 100644 --- a/testing.ml +++ b/testing.ml @@ -97,7 +97,7 @@ let testone prefix x compare_with_expected = let x= if x =~ "\\(.*\\)_ver0$" then matched1 x else x in let base = if x =~ "\\(.*\\)_ver[0-9]+$" then matched1 x else x in - let cfile = prefix ^ x ^ ".c" in + let cfile = if !Flag.c_plus_plus then prefix ^ x ^ ".cpp" else prefix ^ x ^ ".c" in let cocci_file = prefix ^ base ^ ".cocci" in let expected_out = prefix ^ base ^ out_suffix in ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] [PATCH] a few typo fixes and formatting suggestions
A few typo fixes and formatting suggestions. For revision 75de16b.
Signed-off-by: Michele Martone
---
diff --git a/docs/manual/cocci_syntax.tex b/docs/manual/cocci_syntax.tex
index a2410a08..d0d27830 100644
--- a/docs/manual/cocci_syntax.tex
+++ b/docs/manual/cocci_syntax.tex
@@ -256,16 +256,16 @@ i.e., including as an element of another statement list.
\CASE{binary operator \NT{COMMA\_LIST}\mth{(}\T{binopdecl}\mth{)} ;}
\RULE{\rt{assignopdecl}}
- \CASE{\NT{id} \OPT{ = \NT{assignop\_contraint}}}
+ \CASE{\NT{id} \OPT{ = \NT{assignop\_constraint}}}
- \RULE{\rt{assignop\_contraint}}
+ \RULE{\rt{assignop\_constraint}}
\CASE{\mth{\{}\NT{COMMA\_LIST}\mth{(}\NT{assign\_op}\mth{)}\mth{\}}}
\CASE{\NT{assign\_op}}
\RULE{\rt{binopdecl}}
- \CASE{\NT{id} \OPT{ = \NT{binop\_contraint}}}
+ \CASE{\NT{id} \OPT{ = \NT{binop\_constraint}}}
- \RULE{\rt{binop\_contraint}}
+ \RULE{\rt{binop\_constraint}}
\CASE{\mth{\{}\NT{COMMA\_LIST}\mth{(}\NT{bin\_op}\mth{)}\mth{\}}}
\CASE{\NT{bin\_op}}
\end{grammar}
@@ -294,8 +294,8 @@ An {\bf identifier list} is only used for the parameter
list of a macro.
It is possible to specify its length.
It is possible to specify some information about the definition of a {\bf
- fresh identifier}. Examples are found in demos/plusplus1.cocci and
-demos/plusplus2.cocci %See the wiki.
+ fresh identifier}. Examples are found in {\tt demos/plusplus1.cocci} and
+{\tt demos/plusplus2.cocci} %See the wiki.
A {\bf symbol} declaration specifies that the provided identifiers should
be considered C identifiers when encountered in the body of the rule.
@@ -338,7 +338,7 @@ string contains format descriptors. Note that this makes
it impossible to
require \texttt{\ldots} to match exactly in a string, if the semantic patch
string contains format descriptors. If that is needed, some processing
with a scripting language would be required. And example for the use of
-string format metavariables is found in demos/format.cocci.
+string format metavariables is found in {\tt demos/format.cocci}.
Matching of various kinds of format strings within strings is supported.
With the {\tt -{}-ibm} option, matching of decimal format declarations is
@@ -431,7 +431,7 @@ metavariable must be used consistently. These
metavariables cannot be used
in all contexts; specifically, they cannot be used in context that would
make the parsing ambiguous. Some examples are the leftmost term of an
expression, such as the left-hand side of an assignment, or the type in a
-variable declaration. These restrictions may seems somewhat arbitrary from
+variable declaration. These restrictions may seem somewhat arbitrary from
the user's point of view. Thus, it is better to use metavariables with
metavariable types. If Coccinelle is given the argument {\tt
-parse\_cocci}, it will print information about the type that is inferred
@@ -482,7 +482,7 @@ lifting. The result of disjunction lifting can be observed
using {\tt
return or an assignment, or a loop header, if header, etc. The variable
being declared can also be referenced in the script code by its name. All
parameters, except position variables, have their string representation.
-An example is in demos/poscon.cocci.
+An example is in {\tt demos/poscon.cocci}.
Script constraints may be executed more than once for a given metavariable
binding. Executing the script constraint does not guarantee that the
@@ -588,7 +588,7 @@ Initialize and finalize rules do have access to virtual
metavariables,
using the usual syntax. As for other scripting language rules, the rule
is not run (and essentially does not exist) if some of the required virtual
metavariables are not bound. In ocaml, a warning is printed in this case.
-An example is found in demos/initvirt.cocci.
+An example is found in {\tt demos/initvirt.cocci}.
A script metavariable that does not specify an origin, using \texttt{<<},
is newly declared by the script. This metavariable should be assigned to a
@@ -629,7 +629,7 @@ the string actually represents the kind of term represented
by the
metavariable. Normally, a script rule is only applied if all of the
metavariables have values. If default values are provided, then the script
rule is only applied if all of the metavariables for which there are no
-default values have values. See demos/defaultscript.cocci for examples of
+default values have values. See {\tt demos/defaultscript.cocci} for examples
of
the use of this feature.
\section{Control Flow}
@@ -1737,7 +1737,7 @@ be matched against. The entire line is added, but it is
not parsed.
\section{Command-Line Semantic Match}
It is possible to specify a semantic match on the spatch command line,
-using the argument {\tt -sp}. In such a semantic match, any token
+using the argument {\tt --sp}. In such a semantic match, any token
beginning with a capital letter is assumed to be a metavariable of type
{\tt metavariable}. In thi
Re: [Cocci] coccinelle computes patch very slowly
On 20180626@17:40, Julia Lawall wrote: > On Tue, 26 Jun 2018, Michele Martone wrote: > > On 20180626@13:03, Julia Lawall wrote: > > > On Mon, 25 Jun 2018, Michele Martone wrote: > > > > Dear Coccinelle Team, > > > > > > > > While patching source files of a few thousand lines long, I > > > > noticed prohibitively long patch compute times (seemed hanged). > > > > > > > > This effectively prevented spatch from being usable. > > > > > > > > I attach a minimalistic program and patch replicating the problem. > > > > > > > > It seems like presence of uninitialized variables and/or > > > > a loops body might slow down spatch computation extremely. > > > > > > > > I will be grateful of any support! > > > > Hi Julia, > > > > > Loops can cause the matching process to become very expensive. > > > > With your suggeston below (thanks!) I was able to go around > > the problem (see comments) ! > > > > However, I hope that this behaviour is unintended. > > > > I mean: to practical means, loop presence, or a growing amount of > > uninitialized variables leading to supra-linear patch compute > > times is a game-stopper: it can IMHO severely scare users... > > I hope it is some algorithmic limitation that can be overcome.. > > It is an algorithmic limitation, but I don't think it can be overcome in > general. Coccinelle follows control-flow paths. When A ... B matches a > case where there is a loop between A and B, then there is an infinite loop > that blocks going from A to B. The solution is to use what is called weak > until (Coccinelle matching is based on computational tree logic). This > inlvoves negating everything and somehow reaching the fixed point in terms > of the code outside the loop, rather than the code inside the loop. This > easily explodes. A solution could be --no-loops, since you don't care > about situations that start at the end of a loop and jump around to the > top in your case. You can also use a timeout, to get an overall result > quickly at the risk of missing some results. You can also reduce the > problem by having one rule that matches a declaration, and another rule > that makes the transformation for each declared variable individually; > currently paths for different variables are interfering with each other > and further inflating the cost. You can also check whether there exists a > path from the declaration to a variable use, by putting exists in the > header, to be able to ignore variables that are simply never used. Hmmm I see, these are the innards... thanks! But .. for what C is concerned, the presence of a loop construct between a variable declaration and its use after the loop shall not be of any problem wrt type and visibility of that variable identifier. So in principle in the future one might think to follow this logic --- at least for C --- if desired --- no ? > > > I was about to propose various solutionsto get around the loop problem, > > > but I think you don't care. > > I do care --- I am open to further techniques --- they might very likel > > y come in handy soon ;-). > > So you may send them, please. > > > > > You just want to know the type of I. Hence: > > > > > > @@ > > > type T; > > > idexpression T I; > > > identifier f; > > > @@ > > > > > > I = > > > + (T) > > > f(...) > > > > Now the POC code gets patched in a fraction of a second. > > And a 1.2KLOC source with 17 occurrences of 'f' in just <1s. > > So my practical problem here is solved: thanks! > > > > I have an extra question. > > I observed that applying: > > spatch --sp-file <120 files totalling 140 KLOC> > > seems to take >4 minutes time and consuming > 5.5 GB of memory; > > I reran on each file separately, concatenating the patches. > > Then it finishes in ~40s, computing the same exact patch. > > > > Given such a simple patch, was this expected to be so ? > > When you put many files on the command line, it works on the all at once, > in order to be able to take into account references from oneto the other. > Since there are 120 of them, that will be a lot of live memory which will > stress the OCaml garbage collector. When you run on the files > individually the garbage collector is happy - the OCaml GC works well when > it only has to collect the minor heap. Ok, I see.. > Normally, when you have many files to work on, you give the name of the > enclosing directory and Coccinelle works on all
Re: [Cocci] coccinelle computes patch very slowly
On 20180626@13:03, Julia Lawall wrote: > On Mon, 25 Jun 2018, Michele Martone wrote: > > Dear Coccinelle Team, > > > > While patching source files of a few thousand lines long, I > > noticed prohibitively long patch compute times (seemed hanged). > > > > This effectively prevented spatch from being usable. > > > > I attach a minimalistic program and patch replicating the problem. > > > > It seems like presence of uninitialized variables and/or > > a loops body might slow down spatch computation extremely. > > > > I will be grateful of any support! Hi Julia, > Loops can cause the matching process to become very expensive. With your suggeston below (thanks!) I was able to go around the problem (see comments) ! However, I hope that this behaviour is unintended. I mean: to practical means, loop presence, or a growing amount of uninitialized variables leading to supra-linear patch compute times is a game-stopper: it can IMHO severely scare users... I hope it is some algorithmic limitation that can be overcome.. > I was about to propose various solutionsto get around the loop problem, > but I think you don't care. I do care --- I am open to further techniques --- they might very likel y come in handy soon ;-). So you may send them, please. > You just want to know the type of I. Hence: > > @@ > type T; > idexpression T I; > identifier f; > @@ > > I = > + (T) > f(...) Now the POC code gets patched in a fraction of a second. And a 1.2KLOC source with 17 occurrences of 'f' in just <1s. So my practical problem here is solved: thanks! I have an extra question. I observed that applying: spatch --sp-file <120 files totalling 140 KLOC> seems to take >4 minutes time and consuming > 5.5 GB of memory; I reran on each file separately, concatenating the patches. Then it finishes in ~40s, computing the same exact patch. Given such a simple patch, was this expected to be so ? Cheers, Michele ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] coccinelle computes patch very slowly
On 20180626@11:20, SF Markus Elfring wrote: > > While patching source files of a few thousand lines long, > > I noticed prohibitively long patch compute times (seemed hanged). > > Do you get nicer run time characteristics if you would refactor the SmPL > script > example like the following for the addition of a type cast? > > // A semantic patch introducing casting on function return: > @@ > identifier F, V; > type T; > @@ > T V; > ... > V = > +(T) > F(...); Hi Markus, using your patch (having F as any identifier, rather than a specific token) does not change anything time-wise, unfortunately :-( p.s.: My general problem actually was more complicated than this, in that the variables declarations can be anywhere, while this patch here requires declaration and F call to be in the same scope. Michele ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] coccinelle computes patch very slowly
Dear Coccinelle Team,
While patching source files of a few thousand lines long, I
noticed prohibitively long patch compute times (seemed hanged).
This effectively prevented spatch from being usable.
I attach a minimalistic program and patch replicating the problem.
It seems like presence of uninitialized variables and/or
a loops body might slow down spatch computation extremely.
I will be grateful of any support!
Michele
/*
// A semantic patch introducing casting on function return:
@@
type T;
identifier I;
symbol f;
@@
T I;
...
-I =
+I = (T)
f(...);
*/
// Unfortunately, the above semantic patch takes 44s to run `spatch --sp-file
` !
// By using initializing declarators, or deleting the loop, it takes a fraction
of a second.
// Tested with a coccinelle version 04d390a4414e626a0ca83f65f1ec08390c378cd1
(Sat May 26 07:43:36 2018 +0200).
// spatch version 1.0.6-00440-ga4532f08 compiled with OCaml version
4.08.0+dev0-2018-04-09
void * f(){return 0;}
void g(void)
{
int v1=0, v2=0;
int *a1, *a2;
int presence, of, these, slows, down, patch, computing, extremely, y1, y2,
y3, y4, y5;//each new uninitialized variable can cost seconds!
//int presence=0, of=0, these=0, slows=0, down=0, patch=0, computing=0,
extremely=0, y1=0, y2=0, y3=0, y4=0, y5=0;//inizialized ones are fine
//undefined_t status;// presence of this (if uncommented) slows down a lot
a1 = f();
for(v1 = 0; v1 < v2; v1++) { } // presence of this loop here, too! delete it
to have a huge speedup ?!
a2 = f();
}
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [cocci-bug] coccinelle 1.0.6: OpenMP #pragma directive leads to function ignore
On 20180502@15:16, Michele Martone wrote:
> On 20180430@09:44, Peter Senna Tschudin wrote:
> > ...
> Dear Peter, thanks for the apt-get based recipe,
> it worked for me on debian buster with ocaml-4.0.5.
>
> Dear Julia, thanks for the pragma patch which will
> enable coccinelle to support OpenMP-enabled listings
> too (I just tested it on the above setup) :-)
>
> Michele
Dear Julia,
I have another similar minimal test spatch case failing, attached.
It seems like using
#pragma omp parallel for private(I)
breaks the semantic patch, while having
#pragma omp parallel for
is still ok.
Please see attachment.
I'm using self-built ocaml (e407ecf11 2018-05-25)
and coccinelle (a4532f08 2018-05-17).
would be very useful to have full #pragma resilience!
Michele
// seems like this example breaks:
// spatch version 1.0.6-00440-ga4532f08 compiled with OCaml version
4.08.0+dev0-2018-04-09
// (a4532f08 2018-05-17)
/*
pragma_ignored_again.cocci:
@@
symbol A,I,J;
@@
-A[I]
+A[J]
*/
void f(void)
{
int*A=NULL,I=0;
// pragma presence breaks semantic patch (remote private(i) to 'fix' it)
// comment it to have A[I] -> A[J]
#pragma omp parallel for private(I)
A[I]++;
}
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [cocci-bug] coccinelle 1.0.6: OpenMP #pragma directive leads to function ignore
On 20180430@09:44, Peter Senna Tschudin wrote: > [...] > > > #!/bin/bash > > set -e > > set -x > > trap "read" EXIT # will block for input on error > > git clone https://github.com/coccinelle/coccinelle.git > > cd coccinelle > > ./autogen > > ./configure > > make # it stops here > > # make install > > > > and it reaches: > > > > ... > > OCAMLOPT enter.ml > > OCAMLCmain.mli > > OCAMLOPT main.ml > > OCAMLOPT -o spatch.opt > > /usr/lib64/ocaml/libbigarray.a(bigarray_stubs.o): In function > > `caml_ba_deserialize': > > /home/abuild/rpmbuild/BUILD/ocaml-4.03.0/otherlibs/bigarray/bigarray_stubs.c:979: > > undefined reference to `caml_umul_overflow' > > /home/abuild/rpmbuild/BUILD/ocaml-4.03.0/otherlibs/bigarray/bigarray_stubs.c:985: > > undefined reference to `caml_umul_overflow' > > collect2: error: ld returned 1 exit status > > File "caml_startup", line 1: > > Error: Error during linking > > Makefile:609: recipe for target 'spatch.opt' failed > > make: *** [spatch.opt] Error 2 > > rm parsing_cocci/lexer_cli.ml parsing_cocci/parser_cocci_menhir.ml.d > > parsing_cocci/parser_cocci_menhir.mli.d parsing_cocci/lexer_script.ml > > parsing_cocci/lexer_cocci.ml parsing_c/lexer_c.ml > > + read > > I usually ask the package manager to install build dependencies for me: > > Fedora: > $ sudo dnf builddep coccinelle > > Ubuntu/Debian: > $ sudo apt-get build-dep coccinelle > > [...] Dear Peter, thanks for the apt-get based recipe, it worked for me on debian buster with ocaml-4.0.5. Dear Julia, thanks for the pragma patch which will enable coccinelle to support OpenMP-enabled listings too (I just tested it on the above setup) :-) Michele ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [cocci-bug] coccinelle 1.0.6: OpenMP #pragma directive leads to function ignore
On 20180430@09:42, Julia Lawall wrote: > > > On Mon, 30 Apr 2018, Michele Martone wrote: > > > On 20180430@08:43, Julia Lawall wrote: > > > On Thu, 26 Apr 2018, Michele Martone wrote: > > > > > > > On 20180426@09:25, Julia Lawall wrote: > > > > > On Thu, 26 Apr 2018, Michele Martone wrote: > > > > > > > > > > > Dear Prof. Lawall and Coccinelle team, > > > > > > > > > > > > I'm an enthusiastical, however still beginner use of Coccinelle. > > > > > > > > > > > > While running spatch 1.0.6 on a long OpenMP-enabled listing, I > > > > > > noticed that the presence of the C line: > > > > > > #pragma omp parallel for reduction(+:I) private(I) > > > > > > seems to prevent restructuring of the function containing it. > > > > > > If I simplify the pragma to something like > > > > > > #pragma omp parallel > > > > > > the problem disappears. > > > > > > > > > > > > Is there anything I can do to restructure large codes containing > > > > > > many of such similar lines ? > > > > > > > > > > > > In the attachment you find a test case and the output I experience. > > > > > > > > > > Thanks for the report. We can try to make the parsing of #pragmas > > > > > more > > > > > flexible. > > > > > > > > > > julia > > > > > > > > Dear Julia, > > > > > > > > thanks for the quick response! > > > > > > > > I'll be waiting for Coccinelle-sided developments then. > > > > > > > > May I ask what would you recommend now to circumvent this ? > > > > > > > > From the SmPL v1.0.6 Grammar I am not aware of any way to > > > > e.g. ignore pragma lines as they were comments. > > > > > > > > So the best what comes to my mind is to: > > > > > > > > - comment #pragma lines > > > > - compute semantic patch > > > > - apply semantic patch > > > > - uncomment #pragma lines > > > > > > > > If there is any better solution, please let me know. > > > > > > The problem is now fixed in the github version of Coccinelle. > > > > > > julia > > > > That is good news -- thank you :-) > > > > Handling such pragma lines opens new ranges of use for Coccinelle! > > > > On my side, I just followed install.txt: > > > > #!/bin/bash > > set -e > > set -x > > trap "read" EXIT # will block for input on error > > git clone https://github.com/coccinelle/coccinelle.git > > cd coccinelle > > ./autogen > > ./configure > > make # it stops here > > # make install > > > > and it reaches: > > > > ... > > OCAMLOPT enter.ml > > OCAMLCmain.mli > > OCAMLOPT main.ml > > OCAMLOPT -o spatch.opt > > /usr/lib64/ocaml/libbigarray.a(bigarray_stubs.o): In function > > `caml_ba_deserialize': > > /home/abuild/rpmbuild/BUILD/ocaml-4.03.0/otherlibs/bigarray/bigarray_stubs.c:979: > > undefined reference to `caml_umul_overflow' > > /home/abuild/rpmbuild/BUILD/ocaml-4.03.0/otherlibs/bigarray/bigarray_stubs.c:985: > > undefined reference to `caml_umul_overflow' > > collect2: error: ld returned 1 exit status > > File "caml_startup", line 1: > > Error: Error during linking > > Makefile:609: recipe for target 'spatch.opt' failed > > make: *** [spatch.opt] Error 2 > > rm parsing_cocci/lexer_cli.ml parsing_cocci/parser_cocci_menhir.ml.d > > parsing_cocci/parser_cocci_menhir.mli.d parsing_cocci/lexer_script.ml > > parsing_cocci/lexer_cocci.ml parsing_c/lexer_c.ml > > + read > > > > It's my first experience building any ocaml-based software, so > > I would appreciate any hint how to proceed further, if possible. > > Oops, I'll forward this to my engineer, who knows about building issues. > I'm not sure if he will answer before Wednesday, due to the holiday. > What is your OS? $ cat /etc/os-release NAME="openSUSE Leap" VERSION="42.3" ID=opensuse ID_LIKE="suse" VERSION_ID="42.3" PRETTY_NAME="openSUSE Leap 42.3" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:leap:42.3" thanks! ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [cocci-bug] coccinelle 1.0.6: OpenMP #pragma directive leads to function ignore
On 20180430@08:43, Julia Lawall wrote: > On Thu, 26 Apr 2018, Michele Martone wrote: > > > On 20180426@09:25, Julia Lawall wrote: > > > On Thu, 26 Apr 2018, Michele Martone wrote: > > > > > > > Dear Prof. Lawall and Coccinelle team, > > > > > > > > I'm an enthusiastical, however still beginner use of Coccinelle. > > > > > > > > While running spatch 1.0.6 on a long OpenMP-enabled listing, I > > > > noticed that the presence of the C line: > > > > #pragma omp parallel for reduction(+:I) private(I) > > > > seems to prevent restructuring of the function containing it. > > > > If I simplify the pragma to something like > > > > #pragma omp parallel > > > > the problem disappears. > > > > > > > > Is there anything I can do to restructure large codes containing > > > > many of such similar lines ? > > > > > > > > In the attachment you find a test case and the output I experience. > > > > > > Thanks for the report. We can try to make the parsing of #pragmas more > > > flexible. > > > > > > julia > > > > Dear Julia, > > > > thanks for the quick response! > > > > I'll be waiting for Coccinelle-sided developments then. > > > > May I ask what would you recommend now to circumvent this ? > > > > From the SmPL v1.0.6 Grammar I am not aware of any way to > > e.g. ignore pragma lines as they were comments. > > > > So the best what comes to my mind is to: > > > > - comment #pragma lines > > - compute semantic patch > > - apply semantic patch > > - uncomment #pragma lines > > > > If there is any better solution, please let me know. > > The problem is now fixed in the github version of Coccinelle. > > julia That is good news -- thank you :-) Handling such pragma lines opens new ranges of use for Coccinelle! On my side, I just followed install.txt: #!/bin/bash set -e set -x trap "read" EXIT # will block for input on error git clone https://github.com/coccinelle/coccinelle.git cd coccinelle ./autogen ./configure make # it stops here # make install and it reaches: ... OCAMLOPT enter.ml OCAMLCmain.mli OCAMLOPT main.ml OCAMLOPT -o spatch.opt /usr/lib64/ocaml/libbigarray.a(bigarray_stubs.o): In function `caml_ba_deserialize': /home/abuild/rpmbuild/BUILD/ocaml-4.03.0/otherlibs/bigarray/bigarray_stubs.c:979: undefined reference to `caml_umul_overflow' /home/abuild/rpmbuild/BUILD/ocaml-4.03.0/otherlibs/bigarray/bigarray_stubs.c:985: undefined reference to `caml_umul_overflow' collect2: error: ld returned 1 exit status File "caml_startup", line 1: Error: Error during linking Makefile:609: recipe for target 'spatch.opt' failed make: *** [spatch.opt] Error 2 rm parsing_cocci/lexer_cli.ml parsing_cocci/parser_cocci_menhir.ml.d parsing_cocci/parser_cocci_menhir.mli.d parsing_cocci/lexer_script.ml parsing_cocci/lexer_cocci.ml parsing_c/lexer_c.ml + read It's my first experience building any ocaml-based software, so I would appreciate any hint how to proceed further, if possible. Michele ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [cocci-bug] coccinelle 1.0.6: OpenMP #pragma directive leads to function ignore
On 20180426@09:25, Julia Lawall wrote: > On Thu, 26 Apr 2018, Michele Martone wrote: > > > Dear Prof. Lawall and Coccinelle team, > > > > I'm an enthusiastical, however still beginner use of Coccinelle. > > > > While running spatch 1.0.6 on a long OpenMP-enabled listing, I > > noticed that the presence of the C line: > > #pragma omp parallel for reduction(+:I) private(I) > > seems to prevent restructuring of the function containing it. > > If I simplify the pragma to something like > > #pragma omp parallel > > the problem disappears. > > > > Is there anything I can do to restructure large codes containing > > many of such similar lines ? > > > > In the attachment you find a test case and the output I experience. > > Thanks for the report. We can try to make the parsing of #pragmas more > flexible. > > julia Dear Julia, thanks for the quick response! I'll be waiting for Coccinelle-sided developments then. May I ask what would you recommend now to circumvent this ? >From the SmPL v1.0.6 Grammar I am not aware of any way to e.g. ignore pragma lines as they were comments. So the best what comes to my mind is to: - comment #pragma lines - compute semantic patch - apply semantic patch - uncomment #pragma lines If there is any better solution, please let me know. Thanks, Michele ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
[Cocci] [cocci-bug] coccinelle 1.0.6: OpenMP #pragma directive leads to function ignore
Dear Prof. Lawall and Coccinelle team,
I'm an enthusiastical, however still beginner use of Coccinelle.
While running spatch 1.0.6 on a long OpenMP-enabled listing, I
noticed that the presence of the C line:
#pragma omp parallel for reduction(+:I) private(I)
seems to prevent restructuring of the function containing it.
If I simplify the pragma to something like
#pragma omp parallel
the problem disappears.
Is there anything I can do to restructure large codes containing
many of such similar lines ?
In the attachment you find a test case and the output I experience.
Best regards,
Michele
+ spatch --version
spatch version 1.0.6 compiled with OCaml version 4.05.0
Flags passed to the configure script: --host=i586-suse-linux-gnu
--build=i586-suse-linux-gnu --program-prefix= --disable-dependency-tracking
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include
--libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var
--sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
--disable-dependency-tracking
Python scripting support: yes
Syntax of regular expresssions: PCRE
+ sed -i 's/^...pragma/#pragma /g' pragma_ignored.c
+ cat pragma_ignored.c
void good(void)
{
A[I]; /* not ignored */
}
void bad(void)
{
A[I]; /* if pragma uncommented ignored by spatch 1.0.6 */
#pragma omp parallel for reduction(+:I) private(I)
}
+ spatch --sp-file pragma_ignored.cocci pragma_ignored.c
init_defs_builtins: /usr/lib/coccinelle/standard.h
HANDLING: pragma_ignored.c
diff =
--- pragma_ignored.c
+++ /tmp/di36pef/cocci-output-200330-4f22e8-pragma_ignored.c
@@ -1,6 +1,6 @@
void good(void)
{
- A[I]; /* not ignored */
+ A[J]; /* not ignored */
}
void bad(void)
{
+ sed -i 's/^.pragma /\/\/#pragma/g' pragma_ignored.c
+ cat pragma_ignored.c
void good(void)
{
A[I]; /* not ignored */
}
void bad(void)
{
A[I]; /* if pragma uncommented ignored by spatch 1.0.6 */
//#pragma omp parallel for reduction(+:I) private(I)
}
+ spatch --sp-file pragma_ignored.cocci pragma_ignored.c
init_defs_builtins: /usr/lib/coccinelle/standard.h
HANDLING: pragma_ignored.c
diff =
--- pragma_ignored.c
+++ /tmp/di36pef/cocci-output-200335-2965e3-pragma_ignored.c
@@ -1,9 +1,9 @@
void good(void)
{
- A[I]; /* not ignored */
+ A[J]; /* not ignored */
}
void bad(void)
{
- A[I]; /* if pragma uncommented ignored by spatch 1.0.6 */
+ A[J]; /* if pragma uncommented ignored by spatch 1.0.6 */
//#pragma omp parallel for reduction(+:I) private(I)
}
pragma_ignored.sh
Description: Bourne shell script
void good(void)
{
A[I]; /* not ignored */
}
void bad(void)
{
A[I]; /* if pragma uncommented ignored by spatch 1.0.6 */
//#pragma omp parallel for reduction(+:I) private(I)
}
// pragma_ignored.cocci
//
// $ spatch --version
// spatch version 1.0.6 compiled with OCaml version 4.05.0
// Flags passed to the configure script: --host=i586-suse-linux-gnu
--build=i586-suse-linux-gnu --program-prefix= --disable-dependency-tracking
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include
--libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var
--sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
--disable-dependency-tracking
// Python scripting support: yes
// Syntax of regular expresssions: PCRE
//
//
// $ spatch --sp-file pragma_ignored.cocci pragma_i
//
// @@ -1,9 +1,9 @@
// void good(void)
// {
// - A[I]; /* not ignored */
// + A[J]; /* not ignored */
// }
// void bad(void)
// {
// - A[I]; /* if pragma uncommented ignored by spatch 1.0.6 */
// + A[J]; /* if pragma uncommented ignored by spatch 1.0.6 */
// //#pragma omp parallel for reduction(+:I) private(I)
// }
//
@@
symbol A,I,J;
@@
-A[I]
+A[J]
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
