Re: Transactional memory test case reduction failure
running commands :
chmod u+x
bash check.sh
echo $?
It's still giving output as 1,I included the -squiggle option still,it
dosen't work for me? any Ideas?
#!/bin/bash
CC="-I/home/swamimauli/upload/csmith/runtime/"
OPTS="-Wall"
TEST="bug.c"
gcc ${CC} ${OPTS} ${TEST} 2>&1 | grep 'internal compiler error:in
expand_expr_addr_expr_1, at expr.c:7862'
if ! test $? = 0; then
exit 1
fi
exit 0
Thanks.
Sameeran Joshi
On 8/27/18, Peter Bergner wrote:
> On 8/27/18 10:35 AM, Shubham Narlawar wrote:
>> Here is the file. I am getting some error in sending .sh file, so I send
>> it
>> as below.
>>
>> #!/bin/bash
>> gcc -fgnu-tm testcase.c > out.txt 2>&1 &&\
>> if
>> grep 'internal compiler error' out.txt
>> then
>> exit 0
>> else
>> exit 1
>> fi
>
> When I use creduce, I never write my output to an actual file, but
> just pipe it directly into grep. My creduce.sh scripts usually look
> like the following which have worked for me in the past.
>
> Peter
>
>
> #!/bin/bash
>
> CC="/home/bergner/gcc/build/gcc-fsf-6-pr78543-debug/gcc/xgcc
> -B/home/bergner/gcc/build/gcc-fsf-6-pr78543-debug/gcc"
> OPTS="-O3 -S"
> TEST=pr78543-2.i
>
> ${CC} ${OPTS} ${TEST} 2>&1 | grep 'internal compiler error: in push_reload,
> at reload.c:1349'
> if ! test $? = 0; then
> exit 1
> fi
> exit 0
>
>
Re: Transactional memory test case reduction failure
On 8/27/18, Peter Bergner wrote:
> On 8/27/18 11:42 AM, sameeran joshi wrote:
>> It's still giving output as 1,I included the -squiggle option still,it
>> dosen't work for me? any Ideas?
>>
>> #!/bin/bash
>>
>> CC="-I/home/swamimauli/upload/csmith/runtime/"
>> OPTS="-Wall"
>> TEST="bug.c"
>> gcc ${CC} ${OPTS} ${TEST} 2>&1 | grep 'internal compiler error:in
>> expand_expr_addr_expr_1, at expr.c:7862'
>> if ! test $? = 0; then
>> exit 1
>> fi
>> exit 0
>
> Well what does:
>
> linux% gcc -I/home/swamimauli/upload/csmith/runtime/ -Wall bug.c
running above command on terminal,gives many warnings and asks for the
-fgnu-tm option.
bug.c:1091:2: error: ‘__transaction_relaxed ’ without transactional
memory support enabled
__transaction_relaxed {
>
> return?
>
> And also, what does:
>
> linux% gcc -I/home/swamimauli/upload/csmith/runtime/ -Wall bug.c 2>&1 |
> grep 'internal compiler error: in expand_expr_addr_expr_1, at expr.c:7862'
> linux% echo $?
returns 1
>
> return?
>
> Peter
>
>
Re: Transactional memory test case reduction failure
On 8/27/18, Peter Bergner wrote:
> On 8/27/18 12:13 PM, sameeran joshi wrote:
>> On 8/27/18, Peter Bergner wrote:
>>> Well what does:
>>>
>>> linux% gcc -I/home/swamimauli/upload/csmith/runtime/ -Wall bug.c
>>
>> running above command on terminal,gives many warnings and asks for the
>> -fgnu-tm option.
>>
this shows me ICE if I include -fgnu-tm flag.
>> bug.c:1091:2: error: ‘__transaction_relaxed ’ without transactional
>> memory support enabled
>> __transaction_relaxed {
>
> Well there's your problem then, meaning your compile command doesn't
> result in the "internal compiler error: " message you're expecting
> to see.
>
> Peter
>
>
Re: Transactional memory test case reduction failure
Thank you people for your help and investing time. I have successfully reduces file and filed bug. Thanks, Sameeran Joshi On 8/27/18, Peter Bergner wrote: > On 8/27/18 1:20 PM, sameeran joshi wrote: >> On 8/27/18, Peter Bergner wrote: >>> On 8/27/18 12:13 PM, sameeran joshi wrote: >>>> On 8/27/18, Peter Bergner wrote: >>>>> Well what does: >>>>> >>>>> linux% gcc -I/home/swamimauli/upload/csmith/runtime/ -Wall bug.c >>>> >>>> running above command on terminal,gives many warnings and asks for the >>>> -fgnu-tm option. >>>> >> >> this shows me ICE if I include -fgnu-tm flag. > > Then you need to add -fgnu-tm to your compile options in your > creduce script. Otherwise, how can creduce reduce your test > case down to a minimal, but still ICEing test case, if you > don't tell it how to make it ICE? > > Peter > > >
Source code coverage of gcc
Hi, I have a random C program as a test case, for which I need to do source code coverage on gcc. I have used the gcov tool and further the lcov tool. The percentage of source code coverage which I get after using gcov, Is that the final % which I need to do gcc source code coverage? What does it mean to build gcc with -pg option, how does that help in source code coverage? Thanks, Sameeran Joshi
Re: Testing compiler reliability using Csmith
Hi, we had reported 1 issue (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87118) Using the extended csmith for gcc c language extensions. We are currently working on adding more extensions to it and fuzzing in background. Thanks, Sameeran joshi On Fri 7 Dec, 2018, 9:07 PM Jeff Law, wrote: > On 12/6/18 5:02 PM, Andi Kleen wrote: > > Radu Ometita writes: > > > >> Hello everyone! > >> > >> We are working on writing a paper about testing the reliability of C > compilers by using Csmith (a random C99 program generator). > >> > >> A previous testing effort, using Csmith, found 79 GCC bugs, and 25 of > >> those have been marked by developers as P1 > >> (https://www.flux.utah.edu/download?uid=114 > >> <https://www.flux.utah.edu/download?uid=114>): . However, after this > >> paper was published we are unaware of any further testing using > >> Csmith, and we would like to ask you, if you are aware of any such > >> efforts or further results. > > > > Sameeran has been doing some additional testing with modified csmith. > > > > There's currently no systematic effort to run csmith regularly > > to find regressions. > That's my understanding as well. > > I also got the impression that they'd already hit a significant > inflection point with csmith as the bugs it was finding were ultimately > duplicates of issues it'd already found. csmith was going to need some > significant development to find new ways to stress compilers. > > I have a lot of respect for John's work. It's too bad I don't see him > more often. He's only 15 minutes up the road working with my old group > at the U. > > jeff >
[GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
Hi,I am an undergraduate student currently in final year of computer science and engineering degree course from Pune University, India. I and Shubham have been working on Last year's GSoC project idea : Implement a fuzzer leveraging GCC extensions. Fuzzers like csmith are fairly good at finding compiler bugs. But they only generate standard C, but no extensions. GCC has many extensions, which are not covered. It would be good to extend a fuzzer like csmith to fuzz extensions like OpenMP, attributes, vector extensions, etc. Then run the fuzzer and report compiler bugs. since June 2018 under the guidance of mentor Andi Kleen. I worked on generating GCC C language extensions here is the link (coverage reports,implemented extension's list,bugs found,test cases, and usage are in README file on github) github Link: https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions We choose this as our university project as well, and are still fuzzing the extensions on compiler farm. Based on the previous work I would like to propose the following idea for GSoC 2019: Extending Csmith for OpenMP extensions. I would implement following constructs of OpenMP 1.PARALLEL CONSTRUCT 2.WORKSHARING CONSTRUCTS - 2.1 sections 2.2 single 2.3 loop constructs 2.4 master construct 3.TEAMS CONSTRUCT 4.TASKING CONSTRUCT - 4.1 task 4.2 taskloop 4.3 taskloop simd 4.4 taskyield 5.SYNCHRONIZATION CONSTRUCTS - 5.1 critical 5.2 atomic 5.3 barrier 5.4 taskwait 5.5 taskgroup 6.DATA SHARING ATTRIBUTES - 6.1 private 6.2 public 6.3 firstprivate 6.4 lastprivate Also, I would like to work on the target constrains if time permits. The main challenge what I think would be to ensure that there aren't any data races and data conflicts so that the parallelized program is not undefined. Usage for the GCC community : 1. It might have slight large increments in code coverage and trigger a lot of unique code . I have watched A "Hands-on" Introduction to OpenMP | Tim Mattson, Intel all 4 parts https://www.youtube.com/watch?v=pRtTIW9-Nr0 I have started reading the specification of latest 5.0 standard. Please suggest if this could be an interesting idea for upcoming GSoC ? Thanks, Sameeran Joshi
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
else{//not a structured block
+ b->IsStructured = false;
+ }
+ }
+ else{//a parent block
+if (b->check_structured_block_conditions() ){ // if
true
+//logic of struc block
+ //wait the internal blocks remain to check
+ //1.get internal blocks
+ vector internal_blks;
+ for (size_t i =0 ; i< b->stms.size() ; i++)
+ b->stms[i]->get_blocks(internal_blks);
+
+ bool internal_block_fails=false;
+ for (size_t k = 0; k < internal_blks.size();
k++){
+ if(!internal_blks[k]->IsStructured){
+ internal_block_fails = true;
+ break;
+ }
+ }
+ (internal_block_fails == true) ?
(b->IsStructured = false ) :
(b->IsStructured = true);
+}
+else{//not a structured block
+b->IsStructured = false;
+}
+
+ }
+ }
curr_func->stack.pop_back();
return NULL;
@@ -248,7 +290,49 @@ Block::make_random(CGContext &cg_context, bool looping)
}
return b;
}
+//need to call after DFA analysis,else some statements removed
+//we check for for and if statements ( as have blocks to these statements )
+//if above statements not present it's a leaf node else a parent one
+
+void Block::set_leaf_or_nonleaf_block(Block *b){
+ b->leaf_block = true;//assume block is leaf,rule out later
+ for (int i =0 ; istms.size() ; i++){
+ if ( (b->stms[i]->eType == eFor) || (b->stms[i]->eType ==
eIfElse)
){ //if a for/ if statement.do we need to check any more?
+ b->leaf_block = false;
+ }
+ }
+}
+//checks whether block is a leaf
+bool Block::is_leaf_block(){
+ if (this->leaf_block)
+ return true;
+ else
+ return false;
+}
+bool Block::check_structured_block_conditions(){
+ //write here
+ size_t i ;
+ for (i = 0 ; i < this->stms.size(); i++){
+ if (this->stms[i]->eType == eReturn)
+ return false;
+ if (this->stms[i]->eType == eBreak)
+ return false;
+ if (this->stms[i]->eType == eGoto)
+ return false;
+ //continue is alowed,right?
+ //1.if no return
+ //2.no break
+ //3. no statement goto
+ //if no label present-hard
+ }
+ return true;//still need more detailed analysis
+}
+bool Block::is_structured_block(){
+ if (this->IsStructured)
+ return true;
+ else
+ return false;
+}
/*
*
*/
@@ -296,7 +380,7 @@ Block::~Block(void)
local_vars.clear();
macro_tmp_vars.clear();
}
-
+//new temp variable created and stored in macro_tmp_vars(mentioned below)
std::string
Block::create_new_tmp_var(enum eSimpleType type) const
@@ -368,6 +452,17 @@ Block::Output(std::ostream &out, FactMgr* fm, int
indent) const
//blockid
std::ostringstream ss;
ss << "block id: " << stm_id;
+ if (IsStructured){
+ outputln(out);
+ output_tab(out, indent);
+ output_comment_line (out , "structured");
+ }
+ else{
+ outputln(out);
+ output_tab(out, indent);
+ output_comment_line (out , "un structured");
+ }
+ output_tab(out, indent);
output_comment_line(out, ss.str());
if(CGOptions::stmt_expr()){
diff --git a/src/Block.h b/src/Block.h
index 23c939f..79f95a6 100644
--- a/src/Block.h
+++ b/src/Block.h
@@ -132,6 +132,14 @@ public:
bool func_start_stmt_expr = false;
+//data variables
+ bool leaf_block ;//is it good if not initialized in constructor?
+ bool IsStructured ;
+//member functions
+ void set_leaf_or_nonleaf_block(Block *b);
+ bool is_leaf_block();
+ bool check_structured_block_conditions();
+ bool is_structured_block();
private:
bool depth_protect;
On 2/18/19, Martin Jambor wrote:
> Hello Sameeran,
>
> On Sun, Feb 10 2019, sameeran joshi wrote:
>> Hi,I am an undergraduate student currently in final year of computer
>> science and engineering degree course from Pune University, India. I
>> and Shubham have been working on Last year's GSoC project idea :
>>
>> Implement a fuzzer leveraging GCC exten
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
On 3/24/19, Andi Kleen wrote:
> On Sat, Mar 23, 2019 at 11:49:11PM +0530, sameeran joshi wrote:
>> 1) check_structured_block_conditions()
>> checks for the conditions related to a structured block
>> 1.no returns in block
>
> returns should be allowed inside statement expressions.
If I am correct, we would create a new branch "COMPsmith"(C OpenMP
smith)(name will this work?) from the master of Csmith and work on
it, statement expression are in the "gcc c extensions" branch I guess
which would be a separate branch.
So it shouldn't allow return as well, right?
>
>> 2.no gotos
>> 3.no breaks
>> and accordingly labels the blocks as structured block, for example
>> for (){
>> //unstructured
>> //block 1
>> if(){
>> //unstructured
>> //block 2
>> if(){
>> //block 3
>> //structured
>> 1.no gotos
>> 2.no breaks
>> 3.no return
>> 4.Do I need to check continue as well?
>
> Yes check for continue too.
referring this: http://forum.openmp.org/forum/viewtopic.php?f=3&t=458
continue can be used but with some restriction as:
"innermost associated loop may be curtailed by a continue statement "
Can you please elaborate this with some simple example?
IIUC , we can use continue for innermost loop blocks and their sibling
nodes, but not the parent blocks.
>
>> This applies mostly when the break,goto,return statements have some
>> probability of generation.
>> Another workaround I think(which would increase the generation of more
>> OpenMP constructs)is to make probabilities of above statements to '0'
>
> Sure, of course only within the structured expressions.
>
>> For the following code:
>> struct S1 {
>> int f0;
>> };
>> global variable:
>> static struct S1 g_371 = {0x54L};
>>
>> void main ( ){
>> #pragma omp parallel for
>> for (g_371.f0 = (-3); (g_371.f0 >= (-27)) ; g_371.f0 =
>> safe_sub_func_int32_t_s_s(g_371.f0, 2))
>> {/* block id: 1 */
>> structured block
>> }
>> }
>> I have following 3 questions in regards to usage of openmp.
>>
>> 0.Can't I use a '(test)' a 'bracket' for a 'test' expression?
>> error:invalid controlling predicate
>> If I try removing the brackets the program works fine.
>
>
> You mean it errors for
> for (g_371.f0 = (-3); (g_371.f0 >= (-27)) ; g_371.f0 =
> safe_sub_func_int32_t_s_s(g_371.f0, 2))
>
> and works for
>
> for (g_371.f0 = (-3); g_371.f0 >= (-27) ; g_371.f0 =
> safe_sub_func_int32_t_s_s(g_371.f0, 2))
>
> ?
yes
>
> If yes that would seem like a gcc bug. I would file in bugzilla with a
> simple test case.
>
Did you file it? can you please send me the bug id?
>
>>
>>
>> 1.Can I use a struct field variable for initialization?:
>>
>> Whereas the 5.0 specification states:
>> var operator lb
>> var := variable of signed or unsigned type | variable of pointer type
>> which obeys the specification rules.
>>
>> error:expected iteration declaration/initialization before 'g_371'
>
> Ok I guess it's not supported, so you can't.
Any specific reason for not supporting struct variables as
initialization, as the spec. doesn't impose any restrictions.
>
>>
>>
>> 2.Consider a case where I need to increment the variable:
>>
>> Considering the grammar of Csmith, in increment expression I need to
>> use function safe_sub_func_int32_t_s_s(g_371.f0, 2)
>> the function decrements the variable(same as g_371.f0 = g_371.f0-1 )
>> but it does some checks for the bounds, which are essential for
>> checking the undefined conditions.
>
> Maybe could make the index only unsigned, then ++ would work.
> We definitely need increment expressions to be useful.
>
> And perhaps have an command line option to allow unchecked signed increment
> for this.
>>
>> What do you think about adding command lines so as to disable
>> generation of such increment expressions so it follows spec 5.0
>
> We need them, otherwise too much useful OpenMP won't be generated.
I was thinking about say, --no-func-as-incr will not generate safe_*
functions in increment expressions of for statement, but rather
generate simple and valid increment statements.
I am working on proposal currently and the timeline, will try sending
in couple of days.
>
> -Andi
>
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
On 3/26/19, Jakub Jelinek wrote:
> On Mon, Mar 25, 2019 at 05:41:26PM -0700, Andi Kleen wrote:
>> sameeran joshi writes:
>>
>> > On 3/24/19, Andi Kleen wrote:
>> >> On Sat, Mar 23, 2019 at 11:49:11PM +0530, sameeran joshi wrote:
>> >>> 1) check_structured_block_conditions()
>> >>> checks for the conditions related to a structured block
>> >>> 1.no returns in block
>> >>
>> >> returns should be allowed inside statement expressions.
>> > If I am correct, we would create a new branch "COMPsmith"(C OpenMP
>> > smith)(name will this work?) from the master of Csmith and work on
>> > it, statement expression are in the "gcc c extensions" branch I guess
>> > which would be a separate branch.
>> >
>> > So it shouldn't allow return as well, right?
>>
>> Yes
>
> Yeah, break, return, throw that isn't caught within the body again and not
> rethrown are not valid, similarly say longjmp out of it, goto too.
> exit, abort are ok (the block is then single entry, no exit rather than
> single entry, single exit, but that is fine).
>
>> >> Yes check for continue too.
>> > referring this: http://forum.openmp.org/forum/viewtopic.php?f=3&t=458
>> > continue can be used but with some restriction as:
>> >
>> > "innermost associated loop may be curtailed by a continue statement "
>>
>> Ah you're right. Better don't do continue then.
>
> Why? continue is just fine if it is in the body of the innermost loop.
> In OpenMP 4.5 the loops if collapsed had to be closely nested with no code
> at all in between (which is what GCC 9 still implements), so the only way
> to add invalid continue is to add it into statement expressions in the b,
> lb
> and incr expressions.
>
>> >> If yes that would seem like a gcc bug. I would file in bugzilla with a
>> >> simple test case.
>> >>
>> > Did you file it? can you please send me the bug id?
>>
>> I didn't. Can you show some simple example that errors first?
>>
>> Perhaps Jakub or some other OpenMP expert can also chime in.
>
> I'd need to see an example of what you are talking about.
int i;
#pragma omp parallel for
for (i = (0) ; (i< (20)) ; i++) {
printf ("\ntest expression fails due to brackets");
printf ("\n i< (20) works ");
printf ("\n (i< (20)) fails ");
}
commands: ~$ gcc fail_for.c -Wall -Wextra -fopenmp
fail_for.c: In function ‘main’:
fail_for.c:5:17: error: invalid controlling predicate
for (i = (0) ; (i< (20)) ; i++) {
^
swamimauli@swamimauli:~$ gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
>
>> >>> 1.Can I use a struct field variable for initialization?:
>> >>>
>> >>> Whereas the 5.0 specification states:
>> >>> var operator lb
>> >>> var := variable of signed or unsigned type | variable of pointer type
>> >>> which obeys the specification rules.
>> >>>
>> >>> error:expected iteration declaration/initialization before 'g_371'
>> >>
>> >> Ok I guess it's not supported, so you can't.
>> > Any specific reason for not supporting struct variables as
>> > initialization, as the spec. doesn't impose any restriction
>>
>> Yes it seems like a gcc restriction. I would file a bug (feature
>> request) that one. It's good, these are the kind of things
>> the OpenMP fuzzing project should be finding.
>
> I can raise it on omp-lang, but I'm 100% sure the intent is to have only
> iterators which actually can be privatized, so:
> struct S { int s; void foo (); };
>
> void
> S::foo ()
> {
> #pragma omp for
> for (s = 0; s < 24; s++)
> ;
> }
>
> is fine (as one can in methods use non-static data members in private (s),
> but your example with obj.field iterator is rejected by all the compilers
> I've tried (gcc, icc, clang), so I guess we are just missing a restriction
> in the canonical loop form that
> \it{var} may not be part of another variable (as an array or structure
> element).
> for C and for C++ the with the exception for methods.
> Or say that var must be a base language identifier.
>
struct s{
int f0;
};
void main (){
int i;
struct s var1 ;
#pragma omp parallel for
for (var1.f0 = 0 ; var1.f0< (20); var1.f0++) {
}
}
swamimauli@swamimauli:~$ gcc fail_struct.c -Wall -Wextra -fopenmp
fail_struct.c: In function ‘main’:
fail_struct.c:9:14: error: expected iteration declaration or
initialization before ‘var1’
for (var1.f0 = 0 ; var1.f0< (20); var1.f0++) {
^~~~
Thanks,
Sameeran Joshi
> Jakub
>
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
On 3/26/19, Andi Kleen wrote: >> That is a correct diagnostics. >> >> See Canonical loop form. >> >> test-exprOne of the following: >> var relational-op b >> b relational-op var >> >> ( var relational-op b ) >> is neither of those. > > Still seems strange to fail for some meaningless brackets. > > But ok. > > -Andi >
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
HI, Discussing the project with Andi, I have drafted a proposal, please review and suggest necessary changes. If some OpenMP experts from GCC have some ideas or changes please suggest. https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing Thanks, Sameeran Joshi.
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
On 4/3/19, Martin Jambor wrote: > Hello Joshi, > > On Mon, Apr 01 2019, sameeran joshi wrote: >> HI, >> Discussing the project with Andi, I have drafted a proposal, please >> review and suggest >> necessary changes. >> If some OpenMP experts from GCC have some ideas or changes please >> suggest. >> >> https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing > > I will leave most of the evaluation on Andi (and assume he likes the > proposal, by the way). However, I have read the proposal, I like it and > I consider it very useful but also possibly quite ambitious. But we can > adjust expectations as we go forward. > > Please consider fixing some of the formatting in the document, > especially of the code snippets, sometimes they are a bit difficult to Thanks for pointing it, I have indented them. > read without any indentation. That may be also the reason why I don't > quite understand what is the relationship of omp tasks and loops or > uninitialized local arrays. I have removed the location to insert for OMP tasks at 'uninitialized local array initialization'. Only kept it for as it was getting more complex. 1. while loops 2. nested for loops If you could suggest which constructs do you feel more ambitious?, so I could work on it to modify them. > > But apart from that it is nice, thanks for applying, Thanks, Sameeran Joshi > > Martin >
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
On 4/4/19, Martin Jambor wrote:
> Hi,
>
> On Wed, Apr 03 2019, sameeran joshi wrote:
>> On 4/3/19, Martin Jambor wrote:
>>> Hello Joshi,
>>>
>>> On Mon, Apr 01 2019, sameeran joshi wrote:
>>>> HI,
>>>> Discussing the project with Andi, I have drafted a proposal, please
>>>> review and suggest
>>>> necessary changes.
>>>> If some OpenMP experts from GCC have some ideas or changes please
>>>> suggest.
>>>>
>>>> https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing
>>>
>>> I will leave most of the evaluation on Andi (and assume he likes the
>>> proposal, by the way). However, I have read the proposal, I like it and
>>> I consider it very useful but also possibly quite ambitious. But we can
>>> adjust expectations as we go forward.
>>>
>>> Please consider fixing some of the formatting in the document,
>>> especially of the code snippets, sometimes they are a bit difficult to
>>
>> Thanks for pointing it, I have indented them.
>
> Great, it indeed is now much better.
>
>>
>>> read without any indentation. That may be also the reason why I don't
>>> quite understand what is the relationship of omp tasks and loops or
>>> uninitialized local arrays.
>>
>> I have removed the location to insert for OMP tasks at 'uninitialized
>> local array initialization'.
>> Only kept it for as it was getting more complex.
>>
>> 1. while loops
>> 2. nested for loops
>
> OK.
>
>>
>> If you could suggest which constructs do you feel more ambitious?, so
>
> The one thing I am quite intrigued by is how exactly you will detect
> data races,
There could be 2 approaches to it:
1. Not changing the current generation grammar :
How?
//This is done after statement is generated and after fact analysis of
statement is done, inside Statement::make_random()
//whenever statement is generated, can set flag to indicate a data race in it.
check_and set_data_race_in_statement(){
1.retrieve write vars from current statement (Effect.h)
2.loop through all write vars and check is_shared(write_var)
if true
its a data race
set some flag to indicate
}
This labels each statement with a flag to indicate data race in the
statement, now after generation of a particular block, looping through
the statements and checking whether they have a data race,
if YES:(possible solutions )
1.Neglect the block for parallel region ( may not be
efficient as may neglect most of the blocks)
2. May be apply some synchronization constructs to the block.
if NO race:
good to go with the block to be parallel.
Andi suggested "that will be hard after the fact", But I found Csmith
doing some Fact analysis (DFA analysis) in it's code base.
Which I didn't explore during the previous project.
Will need some help to investigate about Fact Analysis (Fact*.h) which Csmith
already implements, also they maintain the current generation context
(CG_Context.h). As I think would solve most of the problems?
2. Decide before you generate the block that is parallel( a block
would be explicitly selected as a parallel block (based on
probability) ) and then avoid generating any data races. (Andi
suggested )
So, how do you avoid them?
e.g.
LHS OP EXPRESSION
Whenever a LHS variable is selected, care needs to be taken
it's not a shared variable.This avoids the data races during
generation itself.
But this approach restricts the generation grammar, so only
writes to local variables from that block will be present in the
block . Will this work?
The above function could now become something like
Statement::check_and_avoid_data_races_in_statement()
---
> but I assume a conservative but useful approach will not be
> too difficult to devise.
I feel the most time consuming and challenging part would be adding
the first extension, i.e the ' #pragma omp parallel' pragma.
Do you have more suggestions ?
>
>> I could work on it to modify them.
>
> Don't worry about the remark too much. The proposal looks solid.
>
> Martin
>
Thanks,
Sameeran Joshi
Fuzzer extension for gcc
Hi all,I have been figuring out to work on some project,so while searching I found fuzzer implementation project quite interesting,so please can I get some information and links about the extension of fuzzer project for gcc . Can anyone help me please.
Transactional memory test case reduction failure
Hi, I have found an ICE in the transaction memory extension while compiling a program with gcc,but unfortunately for filing a bug in the gcc bugzilla I am unable to reduce the buggy file with creduce . I have included the command line option -fgnu-tm while compiling it. Does creduce support transactional memory for reduction? In the interestingness test script,it always returns 1, also following message is displayed C-Reduce cannot run because the interestingness test does not return zero. Please ensure that it does so not only in the directory where you are invoking C-Reduce, but also in an arbitrary temporary directory containing only the files that are being reduced. In other words, running these commands: DIR=`mktemp -d` cp /home/swamimauli/upload/csmith/runtime/del/testcase.c $DIR cd $DIR /home/swamimauli/upload/csmith/runtime/del/check.sh echo $? should result in "0" being echoed to the terminal. See "creduce --help" for more information. Thanks, Sameeran Joshi
