From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54406 invoked by alias); 31 Jan 2019 09:29:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 54111 invoked by uid 89); 31 Jan 2019 09:29:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=4.1 required=5.0 tests=BAYES_00,FOREIGN_BODY,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=geschftliche, gesch=c3=a4ftliche, Fax, Phone?= X-HELO: mail-lf1-f50.google.com Received: from mail-lf1-f50.google.com (HELO mail-lf1-f50.google.com) (209.85.167.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 31 Jan 2019 09:29:55 +0000 Received: by mail-lf1-f50.google.com with SMTP id z13so1747175lfe.11 for ; Thu, 31 Jan 2019 01:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TmBeACbotNAlzyuWscLh2lMMfcR7yR7Hkokn95hYt0Y=; b=qAamVrXd5/Itbv2AteinmdrVl+/79zu4SzyiPp1pdXQrSt/NEf8sCQCGesjCHQ8IDH J3z+aIOLrV5t3e9D+U6U7JiZzNujYoE+uEDILFT3q/BxCFsmK+8My8WPpZLwva/SNfRK VFiPKpD0dR6g+/kq4daMHBC2eE9aP8U/ovOYWs8nupQmdEjIVB+Zmk/B+ed7ZrWZk+hf 9JwX+L/m7bj4w8P+uh0c2dnDovBtChYjwNw8K/WOlaFShEIRgqurqZAZ0KdCZGBU/cbG l68Djxcjy/Bo1Oi/7DSA1iOYrtqmdozn8ayyt4obgYcqu+glRxYfCkuJ9rVf9BEyASE0 odlQ== MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 31 Jan 2019 09:29:00 -0000 Message-ID: Subject: Re: libgomp platform customization To: Sebastian Huber Cc: GCC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00256.txt.bz2 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 =3D 0; > stride =3D 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 =3D 0; > *value =3D strtol (s, &end, 10); > if (errno !=3D 0) > return NULL; > > return end; > } > > Then use: > > env =3D gomp_strtol (env, &stride); > if (env =3D=3D 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=C3=A4ftliche Mitteilung im Sinne des EHUG. >