* libgomp platform customization
@ 2019-01-30 14:46 Sebastian Huber
2019-01-31 9:29 ` Richard Biener
0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Huber @ 2019-01-30 14:46 UTC (permalink / raw)
To: GCC
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?
--
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@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libgomp platform customization
2019-01-30 14:46 libgomp platform customization Sebastian Huber
@ 2019-01-31 9:29 ` Richard Biener
2019-01-31 9:37 ` Sebastian Huber
0 siblings, 1 reply; 9+ messages in thread
From: Richard Biener @ 2019-01-31 9:29 UTC (permalink / raw)
To: Sebastian Huber; +Cc: GCC
On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
<sebastian.huber@embedded-brains.de> 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.huber@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libgomp platform customization
2019-01-31 9:29 ` Richard Biener
@ 2019-01-31 9:37 ` Sebastian Huber
2019-01-31 9:54 ` Richard Biener
2019-01-31 9:56 ` Jakub Jelinek
0 siblings, 2 replies; 9+ messages in thread
From: Sebastian Huber @ 2019-01-31 9:37 UTC (permalink / raw)
To: Richard Biener; +Cc: GCC
On 31/01/2019 10:29, Richard Biener wrote:
> On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
> <sebastian.huber@embedded-brains.de> 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.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libgomp platform customization
2019-01-31 9:37 ` Sebastian Huber
@ 2019-01-31 9:54 ` Richard Biener
2019-01-31 9:56 ` Jakub Jelinek
1 sibling, 0 replies; 9+ messages in thread
From: Richard Biener @ 2019-01-31 9:54 UTC (permalink / raw)
To: Sebastian Huber; +Cc: GCC
On Thu, Jan 31, 2019 at 10:37 AM Sebastian Huber
<sebastian.huber@embedded-brains.de> wrote:
>
> On 31/01/2019 10:29, Richard Biener wrote:
> > On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
> > <sebastian.huber@embedded-brains.de> 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.huber@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libgomp platform customization
2019-01-31 9:37 ` Sebastian Huber
2019-01-31 9:54 ` Richard Biener
@ 2019-01-31 9:56 ` Jakub Jelinek
2019-01-31 9:58 ` Sebastian Huber
1 sibling, 1 reply; 9+ messages in thread
From: Jakub Jelinek @ 2019-01-31 9:56 UTC (permalink / raw)
To: Sebastian Huber; +Cc: Richard Biener, GCC
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libgomp platform customization
2019-01-31 9:56 ` Jakub Jelinek
@ 2019-01-31 9:58 ` Sebastian Huber
2019-01-31 10:08 ` Jakub Jelinek
0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Huber @ 2019-01-31 9:58 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Richard Biener, GCC
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.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libgomp platform customization
2019-01-31 9:58 ` Sebastian Huber
@ 2019-01-31 10:08 ` Jakub Jelinek
2019-01-31 10:13 ` Sebastian Huber
0 siblings, 1 reply; 9+ messages in thread
From: Jakub Jelinek @ 2019-01-31 10:08 UTC (permalink / raw)
To: Sebastian Huber; +Cc: Richard Biener, GCC
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libgomp platform customization
2019-01-31 10:08 ` Jakub Jelinek
@ 2019-01-31 10:13 ` Sebastian Huber
2019-01-31 10:17 ` Jakub Jelinek
0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Huber @ 2019-01-31 10:13 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Richard Biener, GCC
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.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libgomp platform customization
2019-01-31 10:13 ` Sebastian Huber
@ 2019-01-31 10:17 ` Jakub Jelinek
0 siblings, 0 replies; 9+ messages in thread
From: Jakub Jelinek @ 2019-01-31 10:17 UTC (permalink / raw)
To: Sebastian Huber; +Cc: Richard Biener, GCC
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 <env.c>
Jakub
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-01-31 10:17 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-30 14:46 libgomp platform customization Sebastian Huber
2019-01-31 9:29 ` Richard Biener
2019-01-31 9:37 ` Sebastian Huber
2019-01-31 9:54 ` Richard Biener
2019-01-31 9:56 ` Jakub Jelinek
2019-01-31 9:58 ` Sebastian Huber
2019-01-31 10:08 ` Jakub Jelinek
2019-01-31 10:13 ` Sebastian Huber
2019-01-31 10:17 ` Jakub Jelinek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).