This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]
sameeran joshi <gsocsameeran@gmail.com> writes:
> On 3/24/19, Andi Kleen <ak@linux.intel.com> 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
>> 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.
>> 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.
>>
>>>
>>>
>>> 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.
-Andi