libgomp platform customization

Sebastian Huber sebastian.huber@embedded-brains.de
Thu Jan 31 10:13:00 GMT 2019



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.



More information about the Gcc mailing list