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

[Sebastian Huber]

On 20/07/15 09:03, Chris Johns wrote:
> 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.

The libgomp is part of GCC just like libstdc++. If you test GCC with its 
test suite, then libgomp is also covered. I don't see why the enabling 
of libgomp makes anything worse.

>
> 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 ?

Which build should it break? I checked that I am able to build the tools 
with the RSB. It cannot break the RTEMS build, since we don't use 
-fopenmp here. If it really breaks anything, then I will fix it.

I tested the libgomp in the POSIX configuration and it worked really 
well except the performance issues. The operating system dependencies 
are quite limited, you just need POSIX threads, mutexes and semaphores.

>
>>> 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.

I don't encourage its use, my point is that we have all the ingredients 
that are necessary to do GCC testing with RTEMS. It just needs time to 
polish this stuff.

>
> 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.

Yes, and we should do regular GCC trunk testing. Currently its mere luck 
that if we catch errors like this for example:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.