The patch is "very simple". It gets rid of endless messages. However, I do not know the importance of restrict or __restrict__

The solution may be much different.

The AIX definition from /usr/include/standards.h

is

/*
 * Handle the use of the restrict keyword in non-C99 compilers
 */
#if ((__STDC_VERSION__ >= 199901L) || defined(__C99_RESTRICT))
#define __restrict__ restrict
#else
#define __restrict__
#endif

Note: there are several ways to resolve the issue of the occainsional C++ comments in C code. But experience shows that when C++ comments are being used
c89 is often not enough.

If PHP is meant to be strictly C89 code - I could change the CFLAG to get rid
of the messages - but just because gnu accepts both - with lots of help in zend.h it seems - does not make it better than one or the other.

If PHP is meant to be "c89" rather than "c99" (with extensions) then I need to try with different compiler flags - because langval c99ext is wrong

yes, I know I can add the flag -qcpluscmt instead - but I am told by people who "know" compilers that what we call c++ comments is officially an extension, not a core element.

Thank you for your consideration.

Maybe the code in zend.h is no longer needed. I have tried to find " restrict" or "__restrict" in the .c and .h files.

However, without something, the stderr is flooded with warnings.

To better see what the compiler does I combined -E and -qinfo=all and got this excerpt:

"/usr/include/standards.h", line 172.2: 1506-454 (I) if condition evaluates to 1.
"/usr/include/standards.h", line 173.9: 1506-441 (I) The macro definition will override the keyword "__restrict__".

#line 173
#define __restrict__ restrict

"/data/prj/php/src/php-5.4.45/Zend/zend.h", line 179.10: 1506-441 (I) The macro definition will override the keyword "__restrict__".
"/data/prj/php/src/php-5.4.45/Zend/zend.h", line 179.10: 1506-236 (W) Macro name __restrict__ has been redefined.
"/data/prj/php/src/php-5.4.45/Zend/zend.h", line 179.10: 1506-358 (I) "__restrict__" is defined on line 173 of /usr/include/standards.h.
"/data/prj/php/src/php-5.4.45/Zend/zend.h", line 180.2: 1506-460 (I) endif nesting level is 3.
"/data/prj/php/src/php-5.4.45/Zend/zend.h", line 181.9: 1506-441 (I) The macro definition will override the keyword "restrict".
"/data/prj/php/src/php-5.4.45/Zend/zend.h", line 183.2: 1506-460 (I) if nesting level is 3.

#line 174
# define ZEND_FASTCALL
#line 179
# define __restrict__

#define restrict __restrict__
#line 184
# define ZEND_ALLOCA_MAX_SIZE (32 * 1024)

Maybe after nearly 4 years someone can look at this!

This is still around - also in PHP-7.

Any comments. This creates a log of noise, perhaps for nothing.

"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 242.10: 1506-236 (W) Macro name __restrict__ has been redefined.
"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 242.10: 1506-358 (I) "__restrict__" is defined on line 173 of /usr/include/standards.h.

AIX defines as:
  +169  /*
  +170   * Handle the use of the restrict keyword in non-C99 compilers
  +171   */
  +172  #if ((__STDC_VERSION__ >= 199901L) || defined(__C99_RESTRICT))
  +173  #define __restrict__ restrict
  +174  #else
  +175  #define __restrict__
  +176  #endif
  +177

  +240  #if defined(__GNUC__) && ZEND_GCC_VERSION >= 3004
  +241  #else
  +242  # define __restrict__
  +243  #endif
  +244  #define restrict __restrict__
  +245

********

Using the command (note arguments -E and -qinfo=all):

nohup xlc -E -qinfo=all -Iext/date/lib -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 -DHAVE_TIMELIB_CONFIG_H=1 -Iext/date/ -I/data/prj/php/src/php-7.0.7/ext/date/
 -DPHP_ATOM_INC -I/data/prj/php/php-7.0.7/include -I/data/prj/php/php-7.0.7/main -I/data/prj/php/src/php-7.0.7 -I/data/prj/php/php-7.0.7/ext/date/lib -I
/data/prj/php/src/php-7.0.7/ext/date/lib -I/opt/include/libxml2 -I/data/prj/php/src/php-7.0.7/ext/sqlite3/libsqlite -I/data/prj/php/php-7.0.7/TSRM -I/da
ta/prj/php/php-7.0.7/Zend -I/data/prj/php/src/php-7.0.7/main -I/data/prj/php/src/php-7.0.7/Zend -I/data/prj/php/src/php-7.0.7/TSRM -I/data/prj/php/php-7
.0.7/    -I/usr/include -g   -c /data/prj/php/src/php-7.0.7/ext/date/lib/parse_tz.c -o ext/date/lib/parse_tz.lo > bug62346.i

Key lines in bug62346.i contain the following:


"/usr/include/standards.h", line 172.2: 1506-454 (I) if condition evaluates to 1.
"/usr/include/standards.h", line 173.9: 1506-441 (I) The macro definition will override the keyword "__restrict__".

#line 173
#define __restrict__ restrict

"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 240.2: 1506-460 (I) if nesting level is 7.
"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 240.13: 1506-455 (I) defined(__GNUC__) evaluates to 0.
"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 240.2: 1506-454 (I) if condition evaluates to 0.
"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 240.2: 1506-464 (I) Begin skipping tokens.
"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 241.2: 1506-460 (I) else nesting level is 7.
"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 241.2: 1506-456 (I) Stop skipping tokens.
"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 242.10: 1506-441 (I) The macro definition will override the keyword "__restrict__".
"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 242.10: 1506-236 (W) Macro name __restrict__ has been redefined.
"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 242.10: 1506-358 (I) "__restrict__" is defined on line 173 of /usr/include/standards.h.
"/data/prj/php/src/php-7.0.7/Zend/zend_portability.h", line 243.2: 1506-460 (I) endif nesting level is 7.


#line 242
# define __restrict__

#define restrict __restrict__

*******
I do not know what the keyword does 

but what (good) is the net result? after:

AIX:
#line 173
#define __restrict__ restrict
ZEND
#line 242
# define __restrict__

#define restrict __restrict__
*******
Confusing at the least - perhaps counter-productive...

p.s. subject line mentions zend.h, however the file is now, or also: zend_portability.h

Only mentions of __restrict__ in 7.4 are inside ffi, so this must've been fixed at some point in the meantime...