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 <chr...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
