[Bug c/11942] New: restrict is broken in C99 mode?

[Bug c/11942] New: restrict is broken in C99 mode?

[debian-gcc at lists dot debian dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11942

           Summary: restrict is broken in C99 mode?
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: debian-gcc at lists dot debian dot org
                CC: gcc-bugs at gcc dot gnu dot org

[forwarded from http://bugs.debian.org/187091]

Bug submitter writes:

When I compile certain files (a testcase is attached), gcc fails to
compile with the following error:
broken-restrict.c:23: invalid use of `restrict'
I am sure this is a valid use of restrict because I have seen it used in
<http://www.opengroup.org/onlinepubs/007904975/functions/lio_listio.html>
(SUSv3), which is aligned with C99. In fact, that page says, in part:

	The restrict keyword is added to the lio_listio() prototype for
	alignment with the ISO/IEC 9899:1999 standard.

You can compile this with:
"gcc -std=c99 -c broken-restrict.c" and it will break or you can use
"gcc -DRESTRICT_IS_BROKEN -std=c99 -c broken-restrict.c" and it will
work.

I've pretty much narrowed it down to the restrict in the brackets (if
you put them on a new line, you will see that they are the cause of the
syntax error).

-----------
/* See
 * <http://www.opengroup.org/onlinepubs/007904975/functions/lio_listio.html>
 * for SUSv3's description of lio_listio().
 */

/* This is based on lio_listio(). */

struct foo
{
        char *x;
};

struct bar
{
        int *x;
};

int foo_lio_listio(int mode,
#ifdef RESTRICT_IS_BROKEN
                struct foo *const list[],
#else
                struct foo *__restrict__
                        const list[__restrict__],  /* line 23 */
#endif
                int nent,
#ifdef RESTRICT_IS_BROKEN
                struct bar *sig)
#else
                struct bar *__restrict__ sig)
#endif
{
        return 0;
}
------

[Bug c/11942] restrict is broken in C99 mode?

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11942


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-08-16 13:20:30
               date|                            |


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-16 13:20 -------
I can confirm this on the mainline (20030815).

[Bug c/11942] restrict is broken in C99 mode?

[dhazeghi at yahoo dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11942


dhazeghi at yahoo dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4                         |---


------- Additional Comments From dhazeghi at yahoo dot com  2003-08-22 23:53 -------
Not a regression (so not targetted for 3.4)

[Bug c/11942] restrict is broken in C99 mode?

[jsm28 at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11942


jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu dot org
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |3.4


------- Additional Comments From jsm28 at gcc dot gnu dot org  2003-10-24 08:54 -------
Fixed on mainline, probably by
<http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00693.html>.