* 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).