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 <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.
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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
