Re: About pkg() function and compiling options in mkoctfile

[José Luis García Pallero]

El sáb., 16 may. 2020 a las 15:24, Kai Torben Ohlhus
(<address@hidden>) escribió:
>
> On 5/16/20 9:29 PM, José Luis García Pallero wrote:
> > Hello:
> >
> > Some days ago I asked about the reason of the -fopenmp is present by
> > default in mkoctfile
> > (https://lists.gnu.org/archive/html/octave-maintainers/2020-05/msg00057.html)
> >
> > The reason of my question was that new versions of GCC handle better
> > than previous ones with some OpenMP directives. For example, now is
> > mandatory to declare explicitly all shared variables in the shared()
> > directive when the default(none) option is employed. Prior visions of
> > GCC does not require this for variables declared as const, but in the
> > standard was always mandatory (see
> > http://forum.openmp.org/forum/viewtopic.php?f=3&t=2104). So some code
> > must be changed in order to complain with the standard as newer GCC
> > versions complain. For example, the GCC provided with Debian stable
> > produces error when const variables are declared in shared() (see
> > https://sourceforge.net/p/octave/package-releases/417/#681d)
> >
> > Then, the fact that mkoctfile activates by default the OpenMP support
> > makes some cone not compilable in some systems. I can see that the
> > -pthread -fopenmp options for mkoctfile are stored in the globals
> > ALL_CFLAGS and ALL_CXXFLAGS, which also contain some information about
> > include folders
> >
> > But I think that ask the user to edit manually this variables in order
> > to install a package is not a good idea. So I propose to add an option
> > to the pkg() function in order to activate or deactivate the OpenMP
> > (and pthreads maybe) option. Or maybe more in general an option to
> > pass information and options from pkg() to mkoctfile. Or both things.
> >
> > I think that other discussion could be if mkocfile should activate by
> > default the OpenMP dupport
> >
> > Thanks
> >
>
>
> Thank you for providing more information.  You said: "So some code must
> be changed".  I still do not understand which code is affected?  Does
> this code contain "#pragma omp" sections that are beyond your control?

No, in this case I refer a code on the user side. In my case, for
example, a code in some packages of Octave Forge. When you use the
OpenMP option default(none) (I think it is a good practice in order to
remember which variables are exactly shared) the new versions of GCC
force to change the code if the OpenMP code section is inside a
function and calls to input scalar variables declared as const. With
older versions this values do not need to be put in the shared()
clause in order to complain with the default(none). But this code does
not compile with new GCC versions (GCC 9.3.0 provided with Debian Sid,
for example), as it follows more strictly the OpenMP standard. So when
you change the code, the new version with the shared() clause
populated with the scalar const variables does not compile with older
GCC versions (the one included in Debian stable, for example).

This is the reason of my suggestion about adding an option to the
pkg() function in order to select the activation or deactivation of
OpenMP in mkoctfile. Some as -omp or -noomp, for example. In this way,
the source code could be written using OpenMP complaint with the
latest GCC versions, and users of older versions desctivate the pkg
compiling with OpenMP and run in serial mode.

>
> In general it sounds like a great idea to change code to follow a
> standard, rather than relying on implementation defined behavior.  I do
> not see a reason to make Octave more complicated, rather than fixing
> code to conform to a standard upstream.
>
> Kai


--
*****************************************
José Luis García Pallero
address@hidden
(o<
/ / \
V_/_
Use Debian GNU/Linux and enjoy!
*****************************************