newlib header breaks restricted pointers in C++

newlib header breaks restricted pointers in C++

[Bruno De Fraine]

Hello,

As an extension, GCC and clang offer C99-style restricted pointers in C++ mode:
https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html

We notice that this extension is broken when including newlib headers: restricted pointers are treated as ordinary pointers.

We traced this to the following section of newlib/libc/include/sys/cdefs.h:

  /*
   * GCC 2.95 provides `__restrict' as an extension to C90 to support the
   * C99-specific `restrict' type qualifier.  We happen to use `__restrict' as
   * a way to define the `restrict' type qualifier without disturbing older
   * software that is unaware of C99 keywords.
   */
  #if !(__GNUC__ == 2 && __GNUC_MINOR__ == 95)
  #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901
  #define	__restrict
  #else
  #define	__restrict	restrict
  #endif
  #endif

While the GCC __restrict extension was indeed introduced in GCC 2.95, it is not limited to this version; the extension is also not limited to C90:
https://gcc.gnu.org/gcc-2.95/c++features.html

This is a suggestion how the logic in the header could be rewritten:

  /*
   * We use `__restrict' as a way to define the `restrict' type qualifier
   * without disturbing older software that is unaware of C99 keywords.
   * GCC also provides `__restrict' as an extension to support C99-style
   * restricted pointers in other language modes.
   */
  #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901
  #define	__restrict	restrict
  #elif !__GNUC_PREREQ__(2, 95)
  #define	__restrict
  #endif

Regards,
Bruno De Fraine

Re: newlib header breaks restricted pointers in C++

[Corinna Vinschen]

Hi Bruno,

On Jul 24 22:23, Bruno De Fraine wrote:
> Hello,
> 
> As an extension, GCC and clang offer C99-style restricted pointers in C++ mode:
> https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html
> 
> We notice that this extension is broken when including newlib headers: restricted pointers are treated as ordinary pointers.
> 
> We traced this to the following section of newlib/libc/include/sys/cdefs.h:
> 
>   /*
>    * GCC 2.95 provides `__restrict' as an extension to C90 to support the
>    * C99-specific `restrict' type qualifier.  We happen to use `__restrict' as
>    * a way to define the `restrict' type qualifier without disturbing older
>    * software that is unaware of C99 keywords.
>    */
>   #if !(__GNUC__ == 2 && __GNUC_MINOR__ == 95)
>   #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901
>   #define	__restrict
>   #else
>   #define	__restrict	restrict
>   #endif
>   #endif
> 
> While the GCC __restrict extension was indeed introduced in GCC 2.95, it is not limited to this version; the extension is also not limited to C90:
> https://gcc.gnu.org/gcc-2.95/c++features.html

Either way, the above has been taken from FreeBSD, and it is still,
as of today, the same expression as used in FreeBSDs sys/cdefs.h
file.

Seb, any input on this?


Corinna

Re: newlib header breaks restricted pointers in C++

[Sebastian Huber]

On 25.07.23 19:35, Corinna Vinschen wrote:
> Hi Bruno,
> 
> On Jul 24 22:23, Bruno De Fraine wrote:
>> Hello,
>>
>> As an extension, GCC and clang offer C99-style restricted pointers in C++ mode:
>> https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html
>>
>> We notice that this extension is broken when including newlib headers: restricted pointers are treated as ordinary pointers.
>>
>> We traced this to the following section of newlib/libc/include/sys/cdefs.h:
>>
>>    /*
>>     * GCC 2.95 provides `__restrict' as an extension to C90 to support the
>>     * C99-specific `restrict' type qualifier.  We happen to use `__restrict' as
>>     * a way to define the `restrict' type qualifier without disturbing older
>>     * software that is unaware of C99 keywords.
>>     */
>>    #if !(__GNUC__ == 2 && __GNUC_MINOR__ == 95)
>>    #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901
>>    #define	__restrict
>>    #else
>>    #define	__restrict	restrict
>>    #endif
>>    #endif
>>
>> While the GCC __restrict extension was indeed introduced in GCC 2.95, it is not limited to this version; the extension is also not limited to C90:
>> https://gcc.gnu.org/gcc-2.95/c++features.html
> Either way, the above has been taken from FreeBSD, and it is still,
> as of today, the same expression as used in FreeBSDs sys/cdefs.h
> file.
> 
> Seb, any input on this?

I added a FreeBSD bug report:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272723

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: newlib header breaks restricted pointers in C++

[Corinna Vinschen]

On Jul 25 19:46, Sebastian Huber wrote:
> On 25.07.23 19:35, Corinna Vinschen wrote:
> > Hi Bruno,
> > 
> > On Jul 24 22:23, Bruno De Fraine wrote:
> > > Hello,
> > > 
> > > As an extension, GCC and clang offer C99-style restricted pointers in C++ mode:
> > > https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html
> > > 
> > > We notice that this extension is broken when including newlib headers: restricted pointers are treated as ordinary pointers.
> > > 
> > > We traced this to the following section of newlib/libc/include/sys/cdefs.h:
> > > 
> > >    /*
> > >     * GCC 2.95 provides `__restrict' as an extension to C90 to support the
> > >     * C99-specific `restrict' type qualifier.  We happen to use `__restrict' as
> > >     * a way to define the `restrict' type qualifier without disturbing older
> > >     * software that is unaware of C99 keywords.
> > >     */
> > >    #if !(__GNUC__ == 2 && __GNUC_MINOR__ == 95)
> > >    #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901
> > >    #define	__restrict
> > >    #else
> > >    #define	__restrict	restrict
> > >    #endif
> > >    #endif
> > > 
> > > While the GCC __restrict extension was indeed introduced in GCC 2.95, it is not limited to this version; the extension is also not limited to C90:
> > > https://gcc.gnu.org/gcc-2.95/c++features.html
> > Either way, the above has been taken from FreeBSD, and it is still,
> > as of today, the same expression as used in FreeBSDs sys/cdefs.h
> > file.
> > 
> > Seb, any input on this?
> 
> I added a FreeBSD bug report:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272723

Great, thanks!  Do we want to wait for a FreeBSD solution, or do
we want to change it now and, maybe, take the FreeBSD version later?

Does anybody want to provide a git compatible patch?


Thanks,
Corinna

Re: newlib header breaks restricted pointers in C++

[Steven J Abner]

[-- Attachment #1: Type: text/plain, Size: 2296 bytes --]

Curiosity killed the cat,
I might not understand, could you clarify. It mentions 'restrict is not 
a keyword in C++'.
So doesn't #if __cpplusplus need to define 'restrict'. Additionally, 
shouldn't the below mentioned
'#define'(s) include '__restrict__ ?

On Tue, Jul 25 2023 at 06:48:35 PM +0000, Corinna Vinschen 
<vinschen@redhat.com> wrote:
> On Jul 25 19:46, Sebastian Huber wrote:
>>  On 25.07.23 19:35, Corinna Vinschen wrote:
>>  > Hi Bruno,
>>  >
>>  > On Jul 24 22:23, Bruno De Fraine wrote:
>>  > > Hello,
>>  > >
>>  > > As an extension, GCC and clang offer C99-style restricted 
>> pointers in C++ mode:
>>  > > <https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html>
>>  > >
>>  > > We notice that this extension is broken when including newlib 
>> headers: restricted pointers are treated as ordinary pointers.
>>  > >
>>  > > We traced this to the following section of 
>> newlib/libc/include/sys/cdefs.h:
>>  > >
>>  > >    /*
>>  > >     * GCC 2.95 provides `__restrict' as an extension to C90 to 
>> support the
>>  > >     * C99-specific `restrict' type qualifier.  We happen to use 
>> `__restrict' as
>>  > >     * a way to define the `restrict' type qualifier without 
>> disturbing older
>>  > >     * software that is unaware of C99 keywords.
>>  > >     */
>>  > >    #if !(__GNUC__ == 2 && __GNUC_MINOR__ == 95)
>>  > >    #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901
>>  > >    #define	__restrict
>>  > >    #else
>>  > >    #define	__restrict	restrict
>>  > >    #endif
>>  > >    #endif
>>  > >
>>  > > While the GCC __restrict extension was indeed introduced in GCC 
>> 2.95, it is not limited to this version; the extension is also not 
>> limited to C90:
>>  > > <https://gcc.gnu.org/gcc-2.95/c++features.html>
>>  > Either way, the above has been taken from FreeBSD, and it is 
>> still,
>>  > as of today, the same expression as used in FreeBSDs sys/cdefs.h
>>  > file.
>>  >
>>  > Seb, any input on this?
>> 
>>  I added a FreeBSD bug report:
>> 
>>  <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272723>
> 
> Great, thanks!  Do we want to wait for a FreeBSD solution, or do
> we want to change it now and, maybe, take the FreeBSD version later?
> 
> Does anybody want to provide a git compatible patch?
> 
> 
> Thanks,
> Corinna
> 

Re: newlib header breaks restricted pointers in C++

[Corinna Vinschen]

On Jul 25 19:48, Steven J Abner wrote:
> Curiosity killed the cat,
> I might not understand, could you clarify. It mentions 'restrict is not a
> keyword in C++'.
> So doesn't #if __cpplusplus need to define 'restrict'. Additionally,
> shouldn't the below mentioned
> '#define'(s) include '__restrict__ ?

I don't think the header should really define "restrict" for C++,
it would clobber the namespace.

We have the following scenario:

- GCC defines __restrict (and __restrict__) for C and C++.

- Newlib overloads __restrict for all GCC versions != 2.95.

  - Either to nothing, if the app standard is < C99, or
  - to "restrict" if the app standard is >= C99.

The negated release check for version 2.95 exactly is certainly fishy.

Let's compare with the GLibc version:

  /* __restrict is known in EGCS 1.2 and above, and in clang.
     It works also in C++ mode (outside of arrays), but only when spelled
     as '__restrict', not 'restrict'.  */
  #if !(__GNUC_PREREQ (2,92) || __clang_major__ >= 3)
  # if defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L
  #  define __restrict    restrict
  # else
  #  define __restrict    /* Ignore */
  # endif
  #endif

So the expression is the same, just the version check makes more sense.

Shall we match our version expression to the GLibc expression?


Corinna

Re: newlib header breaks restricted pointers in C++

[Sebastian Huber]

On 27.07.23 11:00, Corinna Vinschen wrote:
> Let's compare with the GLibc version:
> 
>    /* __restrict is known in EGCS 1.2 and above, and in clang.
>       It works also in C++ mode (outside of arrays), but only when spelled
>       as '__restrict', not 'restrict'.  */
>    #if !(__GNUC_PREREQ (2,92) || __clang_major__ >= 3)
>    # if defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L
>    #  define __restrict    restrict
>    # else
>    #  define __restrict    /* Ignore */
>    # endif
>    #endif
> 
> So the expression is the same, just the version check makes more sense.
> 
> Shall we match our version expression to the GLibc expression?

Yes, this makes sense. However, do we care about GCC < 2.92 and clang < 3?

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: newlib header breaks restricted pointers in C++

[Joel Sherrill]

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]

On Fri, Jul 28, 2023 at 9:15 AM Sebastian Huber <
sebastian.huber@embedded-brains.de> wrote:

>
>
> On 27.07.23 11:00, Corinna Vinschen wrote:
> > Let's compare with the GLibc version:
> >
> >    /* __restrict is known in EGCS 1.2 and above, and in clang.
> >       It works also in C++ mode (outside of arrays), but only when
> spelled
> >       as '__restrict', not 'restrict'.  */
> >    #if !(__GNUC_PREREQ (2,92) || __clang_major__ >= 3)
> >    # if defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L
> >    #  define __restrict    restrict
> >    # else
> >    #  define __restrict    /* Ignore */
> >    # endif
> >    #endif
> >
> > So the expression is the same, just the version check makes more sense.
> >
> > Shall we match our version expression to the GLibc expression?
>
> Yes, this makes sense. However, do we care about GCC < 2.92 and clang < 3?
>

I recently tried to build a variety of old gcc and clang versions for some
experiments
and failed to go back that far building Linux compilers. I am sure there
are old toolchains
out there with gcc that old but they should stick with an older newlib.

GCC 2.95.3 was released on March 16, 2001. The base 2.95 release was in
July 1999.

This should be well before GCC supported C99.

I'd be prone to add #error if the version doesn't meet a floor version. But
that's just my
opinion.

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>

RE: newlib header breaks restricted pointers in C++

[Bruno De Fraine]

Hello,

> -----Original Message-----
> From: Corinna Vinschen <vinschen@redhat.com>
> Sent: Tuesday, July 25, 2023 8:49 PM
> To: Sebastian Huber <sebastian.huber@embedded-brains.de>
> Cc: Bruno De Fraine <brunodf@synopsys.com>; newlib@sourceware.org
> Subject: Re: newlib header breaks restricted pointers in C++
> 
> On Jul 25 19:46, Sebastian Huber wrote:
> > On 25.07.23 19:35, Corinna Vinschen wrote:
> > > Hi Bruno,
> > >
> > > On Jul 24 22:23, Bruno De Fraine wrote:
> > > > Hello,
> > > >
> > > > As an extension, GCC and clang offer C99-style restricted pointers
> in C++ mode:
> > > > https://urldefense.com/v3/__https://gcc.gnu.org/onlinedocs/gcc/Res
> > > > tricted-Pointers.html__;!!A4F2R9G_pg!aU9wM3m354sF_hiGWy_vrFoJdVs4p
> > > > pL6L-vjcfOx3UOouh-kGDoXHt-F7WiaJmKbZ19ePhSowFxGrkp2kulDyOU$
> > > >
> > > > We notice that this extension is broken when including newlib
> headers: restricted pointers are treated as ordinary pointers.
> > > >
> > > > We traced this to the following section of
> newlib/libc/include/sys/cdefs.h:
> > > >
> > > >    /*
> > > >     * GCC 2.95 provides `__restrict' as an extension to C90 to
> support the
> > > >     * C99-specific `restrict' type qualifier.  We happen to use
> `__restrict' as
> > > >     * a way to define the `restrict' type qualifier without
> disturbing older
> > > >     * software that is unaware of C99 keywords.
> > > >     */
> > > >    #if !(__GNUC__ == 2 && __GNUC_MINOR__ == 95)
> > > >    #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901
> > > >    #define	__restrict
> > > >    #else
> > > >    #define	__restrict	restrict
> > > >    #endif
> > > >    #endif
> > > >
> > > > While the GCC __restrict extension was indeed introduced in GCC
> 2.95, it is not limited to this version; the extension is also not
> limited to C90:
> > > > https://urldefense.com/v3/__https://gcc.gnu.org/gcc-2.95/c**Afeatu
> > > > res.html__;Kys!!A4F2R9G_pg!aU9wM3m354sF_hiGWy_vrFoJdVs4ppL6L-vjcfO
> > > > x3UOouh-kGDoXHt-F7WiaJmKbZ19ePhSowFxGrkp2WBPU9ls$
> > > Either way, the above has been taken from FreeBSD, and it is still,
> > > as of today, the same expression as used in FreeBSDs sys/cdefs.h
> > > file.
> > >
> > > Seb, any input on this?
> >
> > I added a FreeBSD bug report:
> >
> > https://urldefense.com/v3/__https://bugs.freebsd.org/bugzilla/show_bug
> > .cgi?id=272723__;!!A4F2R9G_pg!aU9wM3m354sF_hiGWy_vrFoJdVs4ppL6L-vjcfOx
> > 3UOouh-kGDoXHt-F7WiaJmKbZ19ePhSowFxGrkp2HFg2w9c$
> 
> Great, thanks!  Do we want to wait for a FreeBSD solution, or do we want
> to change it now and, maybe, take the FreeBSD version later?
> 
> Does anybody want to provide a git compatible patch?

If the outcome is to fix this ahead of FreeBSD, I can send a git compatible patch, using the logic either from my suggestion or from Glibc (see elsewhere in this thread).
The differences between both are little:
- With gcc >= 2.95 and C99 (or newer) mode, you can choose whether to map to "restrict" or "__restrict" (this seems purely stylistic).
- It is possible to also check for clang since it supports the "__restrict" extension as well. But clang will define __GNUC__ macros to claim it is compatible with gcc 4.2.1 anyway. (AFAIK it has always done this, with that specific version, but more recently you can control this with the -fgnuc-version command-line option.)

Best regards,
Bruno De Fraine