Re: libgomp platform customization
On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
wrote:
>
> Hello,
>
> we would like to use libgomp in a quite constraint environment. In this
> environment using for example the C locale support, errno, malloc(),
> realloc(), free(), and abort() are problematic. One option would be to
> introduce a new header file "config/*/platform.h" which is included in
> libgomp.h right after the #include "config.h". A platform could then do
> something like this:
>
> #define malloc(size) platform_malloc(size)
> ...
>
> In env.c there are some uses of strto*() like this:
>
>errno = 0;
>stride = strtol (env, &env, 10);
>if (errno)
> return false;
>
> I would like to introduce a new header file "strto.h" which defines
> something like this:
>
> static inline char *
> gomp_strtol (char *s, long *value)
> {
>char *end;
>
>errno = 0;
>*value = strtol (s, &end, 10);
>if (errno != 0)
> return NULL;
>
>return end;
> }
>
> Then use:
>
>env = gomp_strtol (env, &stride);
>if (env == NULL)
> return false;
>
> A platform could then provide its own "config/*/strto.h" with an
> alternative implementation.
>
> Would this be acceptable after the GCC 9 release?
I guess you could look at what nvptx and HSA (and GCN on some branch)
do here?
Richard.
> --
> 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.
>
Re: Small typo on site
On Wed, Jan 30, 2019 at 5:19 PM wrote: > > hi, > on site: > https://www.gnu.org/software/gcc/bugs/#dontwant > in section > Reporting Bugs > Summarized bug reporting instructions > What we do not want > in 3 point you have > > An attached archive (tar, zip, shar, whatever) containing all (or some :-) > of the above. > > (or some :-) should be replace to (or some :-) ) Fixed. > ~wytrzeszcz > > Ps. thank for all you did already >
Re: libgomp platform customization
On 31/01/2019 10:29, Richard Biener wrote:
On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
wrote:
Hello,
we would like to use libgomp in a quite constraint environment. In this
environment using for example the C locale support, errno, malloc(),
realloc(), free(), and abort() are problematic. One option would be to
introduce a new header file "config/*/platform.h" which is included in
libgomp.h right after the #include "config.h". A platform could then do
something like this:
#define malloc(size) platform_malloc(size)
...
In env.c there are some uses of strto*() like this:
errno = 0;
stride = strtol (env, &env, 10);
if (errno)
return false;
I would like to introduce a new header file "strto.h" which defines
something like this:
static inline char *
gomp_strtol (char *s, long *value)
{
char *end;
errno = 0;
*value = strtol (s, &end, 10);
if (errno != 0)
return NULL;
return end;
}
Then use:
env = gomp_strtol (env, &stride);
if (env == NULL)
return false;
A platform could then provide its own "config/*/strto.h" with an
alternative implementation.
Would this be acceptable after the GCC 9 release?
I guess you could look at what nvptx and HSA (and GCN on some branch)
do here?
My problem is that our real-time operating system (RTEMS) is somewhere
in between a full blown Linux and the offload hardware. I would like to
get rid of stuff which depends on the Newlib struct _reent since this
pulls in a lot of dependencies. The heavy weight functions are just used
for the initialization (env.c) and error reporting. Containing the heap
allocation functions helps to control the memory used by OpenMP
computations.
--
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.
Re: libgomp platform customization
On Thu, Jan 31, 2019 at 10:37 AM Sebastian Huber
wrote:
>
> On 31/01/2019 10:29, Richard Biener wrote:
> > On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
> > wrote:
> >> Hello,
> >>
> >> we would like to use libgomp in a quite constraint environment. In this
> >> environment using for example the C locale support, errno, malloc(),
> >> realloc(), free(), and abort() are problematic. One option would be to
> >> introduce a new header file "config/*/platform.h" which is included in
> >> libgomp.h right after the #include "config.h". A platform could then do
> >> something like this:
> >>
> >> #define malloc(size) platform_malloc(size)
> >> ...
> >>
> >> In env.c there are some uses of strto*() like this:
> >>
> >> errno = 0;
> >> stride = strtol (env, &env, 10);
> >> if (errno)
> >> return false;
> >>
> >> I would like to introduce a new header file "strto.h" which defines
> >> something like this:
> >>
> >> static inline char *
> >> gomp_strtol (char *s, long *value)
> >> {
> >> char *end;
> >>
> >> errno = 0;
> >> *value = strtol (s, &end, 10);
> >> if (errno != 0)
> >> return NULL;
> >>
> >> return end;
> >> }
> >>
> >> Then use:
> >>
> >> env = gomp_strtol (env, &stride);
> >> if (env == NULL)
> >> return false;
> >>
> >> A platform could then provide its own "config/*/strto.h" with an
> >> alternative implementation.
> >>
> >> Would this be acceptable after the GCC 9 release?
> > I guess you could look at what nvptx and HSA (and GCN on some branch)
> > do here?
>
> My problem is that our real-time operating system (RTEMS) is somewhere
> in between a full blown Linux and the offload hardware. I would like to
> get rid of stuff which depends on the Newlib struct _reent since this
> pulls in a lot of dependencies. The heavy weight functions are just used
> for the initialization (env.c) and error reporting. Containing the heap
> allocation functions helps to control the memory used by OpenMP
> computations.
I suppose supplying a RTEMS specific noop-stub would work here
and that's close enough to what the offload stuff does. But I'm not
very familiar with this so sorry if misleading you.
Richard.
> --
> 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.
>
Re: libgomp platform customization
On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote: > My problem is that our real-time operating system (RTEMS) is somewhere in > between a full blown Linux and the offload hardware. I would like to get rid > of stuff which depends on the Newlib struct _reent since this pulls in a lot > of dependencies. The heavy weight functions are just used for the > initialization (env.c) and error reporting. Containing the heap allocation > functions helps to control the memory used by OpenMP computations. Heap allocations are everywhere in libgomp, not just in initialization, for parallel, offloading, tasking, worksharing constructs, ... You won't get far without that. Jakub
Re: libgomp platform customization
On 31/01/2019 10:56, Jakub Jelinek wrote: On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote: My problem is that our real-time operating system (RTEMS) is somewhere in between a full blown Linux and the offload hardware. I would like to get rid of stuff which depends on the Newlib struct _reent since this pulls in a lot of dependencies. The heavy weight functions are just used for the initialization (env.c) and error reporting. Containing the heap allocation functions helps to control the memory used by OpenMP computations. Heap allocations are everywhere in libgomp, not just in initialization, for parallel, offloading, tasking, worksharing constructs, ... You won't get far without that. I would like to use a specialized heap for OpenMP and not the general purpose malloc(), etc. -- 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.
Re: libgomp platform customization
On Thu, Jan 31, 2019 at 10:58:27AM +0100, Sebastian Huber wrote: > On 31/01/2019 10:56, Jakub Jelinek wrote: > > On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote: > > > My problem is that our real-time operating system (RTEMS) is somewhere in > > > between a full blown Linux and the offload hardware. I would like to get > > > rid > > > of stuff which depends on the Newlib struct _reent since this pulls in a > > > lot > > > of dependencies. The heavy weight functions are just used for the > > > initialization (env.c) and error reporting. Containing the heap allocation > > > functions helps to control the memory used by OpenMP computations. > > Heap allocations are everywhere in libgomp, not just in initialization, > > for parallel, offloading, tasking, worksharing constructs, ... > > You won't get far without that. > > I would like to use a specialized heap for OpenMP and not the general > purpose malloc(), etc. I'd prefer not to clobber the generic code with that though. So, if you in some config/rtems/ header or overriding *.c file #undef strtoul #define strtoul(p, e, b) rtems_strtoul (p, e, b) and similarly for malloc, free, calloc, I won't object, but I'm against introducing gomp_strtoul, etc. (we do already have gomp_malloc, but expect free to be usable against that). Jakub
Re: libgomp platform customization
On 31/01/2019 11:07, Jakub Jelinek wrote: On Thu, Jan 31, 2019 at 10:58:27AM +0100, Sebastian Huber wrote: On 31/01/2019 10:56, Jakub Jelinek wrote: On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote: My problem is that our real-time operating system (RTEMS) is somewhere in between a full blown Linux and the offload hardware. I would like to get rid of stuff which depends on the Newlib struct _reent since this pulls in a lot of dependencies. The heavy weight functions are just used for the initialization (env.c) and error reporting. Containing the heap allocation functions helps to control the memory used by OpenMP computations. Heap allocations are everywhere in libgomp, not just in initialization, for parallel, offloading, tasking, worksharing constructs, ... You won't get far without that. I would like to use a specialized heap for OpenMP and not the general purpose malloc(), etc. I'd prefer not to clobber the generic code with that though. So, if you in some config/rtems/ header or overriding *.c file #undef strtoul #define strtoul(p, e, b) rtems_strtoul (p, e, b) and similarly for malloc, free, calloc, I won't object, but I'm against introducing gomp_strtoul, etc. (we do already have gomp_malloc, but expect free to be usable against that). The strtoul() is used in combination with errno, so using a macro is not enough. I really would like to be able to use env.c in general, since the standard configuration via environment variables is fine. -- 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.
Re: libgomp platform customization
On Thu, Jan 31, 2019 at 11:13:44AM +0100, Sebastian Huber wrote: > On 31/01/2019 11:07, Jakub Jelinek wrote: > > On Thu, Jan 31, 2019 at 10:58:27AM +0100, Sebastian Huber wrote: > > > On 31/01/2019 10:56, Jakub Jelinek wrote: > > > > On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote: > > > > > My problem is that our real-time operating system (RTEMS) is > > > > > somewhere in > > > > > between a full blown Linux and the offload hardware. I would like to > > > > > get rid > > > > > of stuff which depends on the Newlib struct _reent since this pulls > > > > > in a lot > > > > > of dependencies. The heavy weight functions are just used for the > > > > > initialization (env.c) and error reporting. Containing the heap > > > > > allocation > > > > > functions helps to control the memory used by OpenMP computations. > > > > Heap allocations are everywhere in libgomp, not just in initialization, > > > > for parallel, offloading, tasking, worksharing constructs, ... > > > > You won't get far without that. > > > I would like to use a specialized heap for OpenMP and not the general > > > purpose malloc(), etc. > > I'd prefer not to clobber the generic code with that though. > > So, if you in some config/rtems/ header or overriding *.c file > > #undef strtoul > > #define strtoul(p, e, b) rtems_strtoul (p, e, b) > > and similarly for malloc, free, calloc, I won't object, but I'm against > > introducing gomp_strtoul, etc. (we do already have gomp_malloc, but expect > > free to be usable against that). > > The strtoul() is used in combination with errno, so using a macro is not > enough. I really would like to be able to use env.c in general, since the > standard configuration via environment variables is fine. You can #undef errno #define errno whatever too. And that can be done just in config/rtems/env.c, which will do that stuff and then #include_next Jakub
gcc-7-20190131 is now available
Snapshot gcc-7-20190131 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190131/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 268432 You'll find: gcc-7-20190131.tar.xzComplete GCC SHA256=1453bc8adf80be98c28e5215dacb148610c1e2a421552427d7cd341699bccebb SHA1=3ba59666436ef3c3d4fdf0443502d08a3b4e3bcf Diffs from 7-20190124 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Announce: GNU MPFR 4.0.2 is released
GNU MPFR 4.0.2 ("dinde aux marrons", patch level 2), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:
https://www.mpfr.org/mpfr-4.0.2/
from InriaForge:
https://gforge.inria.fr/projects/mpfr/
and from the GNU FTP site:
https://ftp.gnu.org/gnu/mpfr/
Thanks very much to those who sent us bug reports and/or tested the
release candidate.
The SHA1 digests:
d6a313a3b1ceb9ff3be71cd18e45468837b7fd53 mpfr-4.0.2.tar.bz2
ade94aa28e181540763d6698c6c9fae795be8b75 mpfr-4.0.2.tar.gz
52c1f2a4c9a202f46cf3275a8d46b562aa584208 mpfr-4.0.2.tar.xz
194ea07b9df25203ae20b2be40c66ee70744edc6 mpfr-4.0.2.zip
The SHA256 digests:
c05e3f02d09e0e9019384cdd58e0f19c64e6db1fd6f5ecf77b4b1c61ca253acc
mpfr-4.0.2.tar.bz2
ae26cace63a498f07047a784cd3b0e4d010b44d2b193bab82af693de57a19a78
mpfr-4.0.2.tar.gz
1d3be708604eae0e42d578ba93b390c2a145f17743a744d8f3f8c2ad5855a38a
mpfr-4.0.2.tar.xz
c956921dcf0df8d3bd84a3552ded6dc115a7d6e5224ad2982905c5e777db818d mpfr-4.0.2.zip
The signatures:
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.tar.xz.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.tar.bz2.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.tar.gz.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.zip.asc
Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:
gpg --recv-keys 980C197698C3739D
or by downloading it from .
The key fingerprint is:
07F3 DBBE CC1A 3960 5078 094D 980C 1976 98C3 739D
The signatures can be verified with: gpg --verify
You should check that the key fingerprint matches.
Changes from version 4.0.1 to version 4.0.2:
- Corrected minimal GMP version in the INSTALL file and the MPFR manual.
- Option -pedantic is now always removed from __GMP_CFLAGS (see INSTALL).
- Shared caches: cleanup; really detect lock failures (abort in this case).
- Improved MPFR manual. In particular, corrected/completed the
mpfr_get_str description in order to follow the historical behavior
and GMP's mpf_get_str function.
- Bug fixes (see ChangeLog file).
You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 4.0.2 web page.
Regards,
--
Vincent Lefèvre - Web:
