[rtems-source-builder commit] rtems4.11: OpenMP support for ARM, PowerPC, SPARC

[Chris Johns]

On 20/07/2015 4:01 pm, Sebastian Huber wrote:
> 
> 
> On 19/07/15 01:57, Chris Johns wrote:
>> On 18/07/2015 11:38 pm, Sebastian Huber wrote:
>>> ----- Chris Johns <chrisj at rtems.org> schrieb:
>>>> On 18/07/2015 1:20 am, Joel Sherril wrote:
>>>>> diff --git a/rtems/config/4.11/rtems-arm.bset
>>>>> b/rtems/config/4.11/rtems-arm.bset
>>>>> index 1e06796..c0bd04a 100644
>>>>> --- a/rtems/config/4.11/rtems-arm.bset
>>>>> +++ b/rtems/config/4.11/rtems-arm.bset
>>>>> @@ -17,6 +17,11 @@
>>>>>   %define enable_obsolete 1
>>>>>     #
>>>>> +# Enable OpenMP support
>>>>> +#
>>>>> +%define with_libgomp
>>>>> +
>>>> I think this forces the option to be always on. Should a user be
>>>> able to
>>>> disable the option with --without-libgomp ?
>>> More options more problems.
>> The more defaults we turn on the more regression testing we need to do.
> 
> The libgomp test suite is part of the GCC test suite, so it makes no big
> difference to run it with libgomp enabled or not. It just takes a bit
> longer to execute and you need an SMP target to do the run-time tests.
> Since OpenMP makes only sense on SMP targets, this is not a real issue.
> 
>> The wiki page for OpenMP shows the test results status is unclear.
> 
> The problem was the OpenMP 3.1 Validation Suite itself. The libgomp
> support for RTEMS uses the POSIX configuration in GCC 4.9.3 which works
> really well in terms of correctness. In terms of performance there are
> severe problems, see https://devel.rtems.org/ticket/2274.
> 
> <http://web.cs.uh.edu/%7Eopenuh/download/>
>>
>> If we default to off and a user enables the feature that is different.
>> The need for regression testing and test results is not as critical.
>>
>>>   I don't think there are serious reasons to disable this option.  If
>>> you don't need OpenMP, then you waste a couple of minutes in tool
>>> build time and some megabytes of disk storage.
>> I am not concerned about the time to build or disk space. I am concerned
>> about a change so close to the release plus I have not seen any test
>> results. I know it is difficult to make available features while they
>> are being worked on however it is also reasonable for users to expect it
>> basically works when on by default so it is the default status that
>> concerns me and what it says.
> 
> The --enable-libgomp has absolutely no impact to your application if you
> don't enable OpenMP (-fopenmp).
> 

I am attempting to discuss the correctness of the tools being built and
how we manage this process as a project. It is not related to any
application I may build or the build time. We need to aim at limiting
what we release to what we can test.

I have seen no evidence this stuff works on all the architectures it is
enabled on so if I upgrade the tools and see it breaks a build can I
just default it to off until fixed or does the breakage block a tools
upgrade ?

>>
>> Are there test results that can be published for all the arch's enabled ?
>> How do we run the tests so we can regression test ?
>>
>> FWIW gcc testing and the gcc testsuite is a big item we need to address
>> in a formal way so the whole regression testing of tools from building
>> to test results is available to all users and not hidden away on
>> developer machines with custom scripts.
>>
>> Chris
> 
> Yes, regular and automated GCC tests are definitely something we need.
> We have the scripts available in the rtems-testing repository. 

They are to be obsoleted and that repo archived so please do not
encourage there use. The rtems-tools rtems-test command should be used
as it is to be supported on all hosts but it needs more work.

The rtems-testing scripts are specific to Linux, do not support gdb via
MI mode and the options and what happens is too variable.

> It just
> needs someone with enough time to polish the scripts and setup a machine
> which does regular test runs and publish the results.

We need to teach rtems-test how to run gcc tests.

Chris