ID:               39975
 Comment by:       wharmby at uk dot ibm dot com
 Reported By:      kprzemek at coig dot katowice dot pl
 Status:           Assigned
 Bug Type:         Compile Failure
 Operating System: IBM AIX 5.3
 PHP Version:      5.2.0
 Assigned To:      tony2001
 New Comment:

The IBM XL C service team have reviewed the PMR I raised and
whilst they agree it does highlight a gcc incompatibility 
the XL C compiler is adhering to the ISO standard as it 
stands. They have considered fixing this in currently 
supported version to improve the compatibility with gcc but 
cannot due to binary compatibility issues. I am in the  
process of getting the issue logged  so they can consider 
fixing it in a future version to improve gcc  compatibility.

However,  any fixed new version is in the future and the day
when all AIX users have this fixed version even further 
into the future so we either fix the PHP code to avoid the 
error messages or live with the error messages. The code generated by
the compiler appears OK but the documentation does say

  "Compilation continues and object code is generated. Error
   conditions exist that the compiler can correct, but the
   program might not run correctly."

which will leave the user with a slight uneasy feeling that 
the code may not work.

The fixes required to avoid the messages are trivial so we should
consider modifying the code unless anyone objects.


Previous Comments:
------------------------------------------------------------------------

[2007-01-17 09:45:44] wharmby at uk dot ibm dot com

PMR now raised to get XL C compiler fixed to avoid 
1506-159 error messages when bitfields defined on unsigned char type's.
PMR number is 40951,999,866

------------------------------------------------------------------------

[2007-01-11 12:33:18] wharmby at uk dot ibm dot com

Having acquired V5 documentation I can now confirm that 
-qlanglvl=extc89|extc99 is not supported under XL C V5 so cant use that
to avoid the errors reported above.

I am in the process of raising a PMR against the XL C compiler to get
the compiler fixed to avoid the error
message when bit fields defined on unsigned char types, e.g 

1506-159 (E) Bit-field type specified for how is not valid. Type
unsigned assumed.

Will post again when I have news on progress of PMR

------------------------------------------------------------------------

[2007-01-05 18:36:05] wharmby at uk dot ibm dot com

I have conducted a series of experiments today and results 
so far are listed below:

My environment:

 OS: AIX 5.2.0.0
 Compiler :  IBM(R) XL C Enterprise Edition V7.0
 PHP: PHP 5.2.1RC2-dev

With the following PHP configuration

    ./configure -enable-debug --enable-maintainer-zts  --disable-cgi
--enable-cli --with-libxml-dir=/u2/wharmby/freeware/xml2
--prefix=/u2/wharmby/php5

Ignoring the normal W(arning) messages the only compiler 
messages I get are E(rror) messages about badly defined 
bit-field's.  I get multiple instances of the following:

"/u2/wharmby/php5.2-200701040730/main/streams/php_stream_transport.h",
line 136.27: 1506-159 (E) Bit-field type specified for how is not
valid. Type unsigned assumed.

The offending code is as follows:

typedef struct _php_stream_xport_param {
    enum {
          STREAM_XPORT_OP_BIND, STREAM_XPORT_OP_CONNECT,
          STREAM_XPORT_OP_LISTEN, STREAM_XPORT_OP_ACCEPT,
          STREAM_XPORT_OP_CONNECT_ASYNC,
          STREAM_XPORT_OP_GET_NAME,
          STREAM_XPORT_OP_GET_PEER_NAME,
          STREAM_XPORT_OP_RECV,
          STREAM_XPORT_OP_SEND,
          STREAM_XPORT_OP_SHUTDOWN
    } op;
    unsigned int want_addr:1;
    unsigned int want_textaddr:1;
    unsigned int want_errortext:1;
    stream_shutdown_t how:3; <<< THIS IS LINE FLAGGED

e.t.c

stream_shutdown_t  is defined as follows:

typedef enum {
    STREAM_SHUT_RD,
    STREAM_SHUT_WR,
    STREAM_SHUT_RDWR
} stream_shutdown_t;

This is a variation of the bitfield problem reported above
when compiling hash_tiger.c. The complete list of messages for this
with xlc V7 are:

cc -Iext/hash/ -I/u2/wharmby/php5.2-200701040730/ext/hash/
-DPHP_ATOM_INC
-I/u2/wharmby/php5.2-200701040730/include
-I/u2/wharmby/php5.2-200701040730/main
-I/u2/wharmby/php5.2-200701040730
-I/u2/wharmby/freeware/xml2/include/libxml2
-I/u2/wharmby/php5.2-200701040730/ext/date/lib
-I/u2/wharmby/php5.2-200701040730/TSRM
-I/u2/wharmby/php5.2-200701040730/Zend -D_THREAD_SAFE -I/usr/include
-g
-DZTS -c /u2/wharmby/php5.2-200701040730/ext/hash/hash_tiger.c -o
ext/hash/hash_tiger.o
"/u2/wharmby/php5.2-200701040730/main/streams/php_stream_transport.h",
line
136.27: 1506-159 (E) Bit-field type specified for how is not valid.
Type unsigned assumed.
"/u2/wharmby/php5.2-200701040730/ext/hash/php_hash_tiger.h", line 28.9:
1506-159 (E) Bit-field type specified for passes is not valid. Type
unsigned assumed.
"/u2/wharmby/php5.2-200701040730/ext/hash/php_hash_tiger.h", a line
29.9: 1506-159 (E) Bit-field type specified for length is not valid.
Type unsigned assumed.

The "E" messages allow the build to complete OK and runs its
basic regression tests but I have not run sufficient test 
to verify that the complier has generated valid code. However,
regardless of whether the code generated is sound given that the same
code compiles clean under gcc I will approach the compiler team to see
if we can get the compiler
fixed to accept bit-fields of "unsigned char".

Other than that everything compiles OK, The problems regarding the
spurious ";" after ZEND_ARG_INFO(), trailing "," in a enum e.t.c are
fixed with xlc v7 when compiling with default complier options.

However, the default value for the langlvl compiler option with V7 when
invoking compiler as cc is "extended". I have 
experimented a little by modifying the "-qlanglvl" compiler 
option The xlc manual lists amongst others the following:

"stdc89" Compilation conforms to the ANSI C89 standard, also known as
ISO C90.

"stdc99" Compilation conforms to the ISO C99 standard.

"extc89" Compilation conforms to the ANSI C89 standard, and 
accepts implementation-specific language extensions.

"extc99" Compilation conforms to the ISO C99 standard, and 
accepts implementation-specific language extensions.

If I set langlvl to either stdc89 or stdc99 then I get ALL 
the messages as reported in the defect 39975 and the compilation is
aborted e.g 

"/u2/wharmby/php5.2-200701040730/main/streams/php_stream_filter_api.h",
line 65.21: 1506-275 (S) Unexpected text ',' encountered.
"/u2/wharmby/php5.2-200701040730/main/streams/php_stream_transport.h",
line 136.27: 1506-009 (S) Bit-field how must be of type signed int,
unsigned int or int.

With either extc89 or extc99 I just get the "E" messages 
listed above and the build completes OK.

What is not clear to me at the moment is whether or not the code
compiles OK with the V7 compiler because of fixes in the newer versions
of compiler or whether its just a change in default "lnaglvl". As I dont
have the V5 complier or its documentation to check I have contacted
someone in the
complier team for clarification.

I will report back further next week when I have more information.

In the meantime you could try specifying the extra CFLAG of

     -qlanglvl=extc89|extc99
 
to see if 
  (a) its accepted by V5, and 
  (b) whether it reduces the number of compile failures

------------------------------------------------------------------------

[2007-01-03 16:58:44] wharmby at uk dot ibm dot com

A couple of comments on this bug: 

1) VisualAge C++ Professional Version 5.0 for AIX went out
of support on December 31, 2003. The supported versions of
the IBM compilers are 6.0, 7.0, or 8.0.  However, you should check that
you have the latest Version 5.0 PTF installed just in case this problem
is resolved at that level. It can be found here:  

http://www.ibm.com/support/docview.wss?rs=0&uid=swg21156462

2) With each new version of the compiler changes have been made to
enhance the portability from GNU C/C++ to the AIX compiler. This
webpage describes such features in the latest Version 8.0 compilers:

http://www.ibm.com/software/awdtools/xlcpp/features/#GNU

I currently do not have access to a AIX system with the 
latest complier but I will look into getting access to one to to check
whether or not the issues you highlight are fixed or not in a newer
version of the AIX compiler.

------------------------------------------------------------------------

[2006-12-29 19:24:43] orchard at engr dot wisc dot edu

I had to fix the following error to get the Sun C compiler to compile
the program (I changed the comment to standard C syntax):

[eceserv1] 203% diff spl_iterators.c.orig spl_iterators.c
1484c1484
<               return;// NULL
---
>               return;/* // NULL */

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/39975

-- 
Edit this bug report at http://bugs.php.net/?id=39975&edit=1

Reply via email to