View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013320CMakeCMakepublic2012-06-19 16:082012-11-05 14:33
ReporterDaniel Richard G. 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformPA-RISCOSHP-UXOS Version11.00
Product VersionCMake 2.8.8 
Target VersionFixed in Version 
Summary0013320: UINT32_C() et al. macro shenanigans break build on HP-UX
DescriptionBootstrapping CMake 2.8.8 on this HP-UX system fails with

[ 1%] Building C object Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_C.c.o
cd /tmp/cmake-build/Utilities/KWIML/test && /opt/tg/bin/tg-gcc -DKWIML_NAMESPACE=cmIML -DKWIML_LANGUAGE_C -DKWIML_LANGUAGE_CXX -pipe -W -Wall -Wcast-align -Wformat=2 -Wpointer-arith -Wundef -mpa-risc-2-0 -O3 -Wno-format -I/tmp/cmake-build/Utilities/KWIML/test -I/tmp/cmake-build/Utilities -o CMakeFiles/cmIML_test.dir/test_INT_C.c.o -c /home/src/cmake-2.8.8/Utilities/KWIML/test/test_INT_C.c
In file included from /home/src/cmake-2.8.8/Utilities/KWIML/test/test_INT_C.c:14:0:
/tmp/cmake-build/Utilities/KWIML/test/test_INT_format.h: In function 'test_INT_format':
/tmp/cmake-build/Utilities/KWIML/test/test_INT_format.h:195:1: error: pasting ")" and "l" does not give a valid preprocessing token
/tmp/cmake-build/Utilities/KWIML/test/test_INT_format.h:195:3: error: expected ',' or ';' before 'l'
gmake[2]: *** [Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/test_INT_C.c.o] Error 1
gmake[2]: Leaving directory `/tmp/cmake-build'
gmake[1]: *** [Utilities/KWIML/test/CMakeFiles/cmIML_test.dir/all] Error 2
gmake[1]: Leaving directory `/tmp/cmake-build'
gmake: *** [all] Error 2


The test_INT_format.h makes use of a symbol UINT32_C, and others like it. This is defined in inttypes.h:

    $ gnu-grep -R UINT32_C /usr/include
    /usr/include/inttypes.h:#define UINT32_C(__c) __CONCAT_U__(__c)
    /usr/include/inttypes.h:#define UINT32_C(__c) __CONCAT__(__CONCAT_U__(__c),l)
    /usr/include/inttypes.h:# define UINT32_MAX UINT32_C(4294967295)

From what I can tell, this macro is being expanded before being passed as an argument to TEST_C(). I'm not sure how to work around this.
TagsNo tags attached.
Attached Files? file icon inttypes.h [^] (13,265 bytes) 2012-06-20 11:39

- Relationships Relation Graph ] Dependency Graph ]
related to 0013321closedBrad King ABI.h doesn't know about older HP compilers 

-  Notes
(0029749)
Brad King (manager)
2012-06-19 16:26

This change fixed a similar problem on other platforms:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f94ae0ec [^]

but it is already in 2.8.8.

What are the definitions of __CONCAT_U__ and __CONCAT__ ?
(0029750)
Daniel Richard G. (reporter)
2012-06-19 16:46

Nuts, this issue also comes up in

[ 77%] Building C object Source/CMakeFiles/CMakeLib.dir/cm_sha2.c.o
cd /tmp/cmake-build/Source && /opt/tg/bin/tg-gcc -DCURL_STATICLIB -DLIBARCHIVE_STATIC -DCMAKE_BUILD_WITH_CMAKE -DCMAKE_USE_NINJA -pipe -W -Wall -Wcast-align -Wformat=2 -Wpointer-arith -Wundef -mpa-risc-2-0 -O3 -I/tmp/cmake-build/Utilities -I/home/src/cmake-2.8.8/Utilities -I/tmp/cmake-build/Source -I/home/src/cmake-2.8.8/Source -I/tmp/cmake-build/Utilities/cmcompress -I/home/src/cmake-2.8.8/Source/CTest -I/home/src/cmake-2.8.8/Source/CursesDialog/form -I/tmp/cmake-build/Source/CursesDialog/form -o CMakeFiles/CMakeLib.dir/cm_sha2.c.o -c /home/src/cmake-2.8.8/Source/cm_sha2.c
/home/src/cmake-2.8.8/Source/cm_sha2.c:241:1: error: pasting ")" and "l" does not give a valid preprocessing token
/home/src/cmake-2.8.8/Source/cm_sha2.c:241:2: error: expected '}' before 'l'
/home/src/cmake-2.8.8/Source/cm_sha2.c:242:1: error: pasting ")" and "l" does not give a valid preprocessing token
/home/src/cmake-2.8.8/Source/cm_sha2.c:243:1: error: pasting ")" and "l" does not give a valid preprocessing token
/home/src/cmake-2.8.8/Source/cm_sha2.c:244:1: error: pasting ")" and "l" does not give a valid preprocessing token
/home/src/cmake-2.8.8/Source/cm_sha2.c:245:1: error: pasting ")" and "l" does not give a valid preprocessing token
/home/src/cmake-2.8.8/Source/cm_sha2.c:250:1: error: pasting ")" and "l" does not give a valid preprocessing token
/home/src/cmake-2.8.8/Source/cm_sha2.c:250:2: error: expected '}' before 'l'
[further errors elided]


Anyway, those two macros are defined (in inttypes.h) as

    #define __CONCAT__(_A,_B) _A ## _B
    #define __CONCAT_U__(_A) _A ## u
(0029752)
Brad King (manager)
2012-06-19 17:15

Your grep output reports two UINT32_C definitions in inttypes.h. What are the preprocessor conditions that select one of them?
(0029753)
Daniel Richard G. (reporter)
2012-06-19 17:19

Seems to be a 32/64-bit thing:

    #ifdef __LP64__
    #define INT32_C(__c) (__c)
    #define UINT32_C(__c) __CONCAT_U__(__c)
    #else /* __LP64 */
    #define INT32_C(__c) __CONCAT__(__c,l)
    #define UINT32_C(__c) __CONCAT__(__CONCAT_U__(__c),l)
    #endif /* __LP64 */

(This HP-UX machine is strictly 32-bit.)
(0029754)
Brad King (manager)
2012-06-19 17:19

The platforms' concat macro definitions are wrong. They should be something like

#define __CONCAT__(_A,_B) __CONCAT_DELAY__(_A,_B)
#define __CONCAT_DELAY__(_A,_B) _A ## _B
#define __CONCAT_U__(_A) __CONCAT_DELAY_U__(_A)
#define __CONCAT_DELAY_U__(_A) _A ## u


The delay gives the preprocessor a chance to evaluate its arguments and concatenate their results.

Of course we can't change those so we have to work around them.
(0029755)
Brad King (manager)
2012-06-19 17:24

What preprocessor test can be used to identify this system?

We already have some tests like

 defined(__HP_cc) || defined(__HP_aCC)

but this is known to work on newer HP machines so we need a version test.
(0029756)
Daniel Richard G. (reporter)
2012-06-19 17:25

Indeed, my newer HP-UX system (B.11.23 on Itanium) has

    #ifdef __LP64__
    #define INT32_C(__c) (__c)
    #define UINT32_C(__c) __CONCAT_U__(__c)
    #else /* __LP64 */
    #define INT32_C(__c) __CONCAT__(__c,l)
    #define UINT32_C(__c) __CONCAT__(__c,ul)
    #endif /* __LP64 */

(The __CONCAT* macros are the same.)
(0029757)
Brad King (manager)
2012-06-19 17:28

Right, so on the old system the code

 #define UINT32_C(__c) __CONCAT__(__CONCAT_U__(__c),l)

tries to concatenate the literal tokens "__CONCAT_U__(__c)" and "l". That is why it complains about ")" and "l".
(0029758)
Daniel Richard G. (reporter)
2012-06-19 17:30

Good question. "cpp -dM" isn't showing anything particularly apropos:

    $ cpp -dM empty.h | grep -i hp
    #define __hppa 1
    #define __hpux 1
    #define __hp9000s700 1
    #define __hp9000s800 1
    #define __hp9000s800__ 1
    #define __hp9000s700__ 1
    #define __hppa__ 1
    #define __hpux__ 1
    #define _HPUX_SOURCE 1

Don't see much in the system headers, either...
(0029759)
Brad King (manager)
2012-06-19 17:34

Well, first try building with the patch below and adding "-DcmIML_INT_BROKEN_UINT32_C" to the flags.

diff --git a/Utilities/KWIML/INT.h.in b/Utilities/KWIML/INT.h.in
index d40edcd..49e9904 100644
--- a/Utilities/KWIML/INT.h.in
+++ b/Utilities/KWIML/INT.h.in
@@ -534,7 +534,7 @@ An includer may test the following macros after inclusion:
 #else
 # define @KWIML@_INT_INT32_C(c) c
 #endif
-#if defined(UINT32_C)
+#if defined(UINT32_C) && !defined(@KWIML@_INT_BROKEN_UINT32_C)
 # define @KWIML@_INT_UINT32_C(c) UINT32_C(c)
 #else
 # define @KWIML@_INT_UINT32_C(c) c ## u
(0029761)
Daniel Richard G. (reporter)
2012-06-20 08:12

I tested with just "#if 0" there, but that was enough to allow the build to complete successfully, addressing the errors in both test_INT_format.h and cm_sha2.c. (So only UINT32_C() is broken; the other type-macros seem to be fine.)
(0029762)
Brad King (manager)
2012-06-20 08:23

Will something like this identify the broken case uniquely?

#if defined(__hpux) && !defined(__HP_cc) && !defined(__HP_aCC) \
 && defined(__CONCAT__) && defined(__CONCAT_U__) && !defined(__LP64__)
# define @KWIML@_INT_BROKEN_UINT32_C
#endif
(0029769)
Daniel Richard G. (reporter)
2012-06-20 11:42

I would drop the __HP_cc and __HP_aCC bits from that, as this is a system-header thing, not a compiler thing.

But I would add defined(__GNUC__), because the HP compiler/cpp can correctly process the broken __CONCAT* macros. I just double-checked this with a trivial program and -E: gcc bombs out, cc gives the right output.

I think it should be fine to presume UINT32_C() is broken without regard to the version of HP-UX, as it seems the type-suffix has always been "ul" in the non-64-bit case.

Oh, and for reference purposes, I've attached the inttypes.h header with the broken UINT32_C(). (The system is HP-UX B.11.00, according to uname(1).)
(0029771)
Brad King (manager)
2012-06-20 11:59

Okay, so you propose:
#if defined(__hpux) && !defined(__LP64__) && defined(__GNUC__) \
 && defined(__CONCAT__) && defined(__CONCAT_U__)
  /* Old HP defines UINT32_C in a way that breaks GNU.  */
# define @KWIML@_INT_BROKEN_UINT32_C
#endif


However, note that the line using @KWIML@_INT_BROKEN_UINT32_C, shown in 0013320:0029759, falls back to suffix "u", not "ul". With this workaround does the test still pass at runtime?
(0029772)
Daniel Richard G. (reporter)
2012-06-20 12:14

That conditional looks right to me.

But yes, "ul" for uint32_t isn't the norm. I don't suppose it would be kosher to just redefine UINT32_C() in that specific case? Or maybe define XXX_INT_UINT32_C() for HP, and enclose the standard definition in an "#ifndef XXX_INT_UINT32_C"?

As for the runtime test, this is what I get from the earlier "#if 0" build:

    $ ./cmIML_test | grep -v ', PASSED$'
    C cmIML_INT_SCNi8: expected [-85], got [0], FAILED
    C cmIML_INT_SCNd8: expected [-85], got [0], FAILED
    C cmIML_INT_SCNo8: expected [253], got [0], FAILED
    C cmIML_INT_SCNu8: expected [171], got [0], FAILED
    C cmIML_INT_SCNx8: expected [ab], got [0], FAILED
    C cmIML_INT_SCNx8: expected [AB], got [0], FAILED
    C++ cmIML_INT_SCNi8: expected [-85], got [0], FAILED
    C++ cmIML_INT_SCNd8: expected [-85], got [0], FAILED
    C++ cmIML_INT_SCNo8: expected [253], got [0], FAILED
    C++ cmIML_INT_SCNu8: expected [171], got [0], FAILED
    C++ cmIML_INT_SCNx8: expected [ab], got [0], FAILED
    C++ cmIML_INT_SCNx8: expected [AB], got [0], FAILED

(New bug report?)
(0029773)
Brad King (manager)
2012-06-20 13:00

Re 0013320:0029772: It looks like the test for UINT32_C passes with suffix "u" anyway.

As for the SCN*8 trouble, let's keep all these related problems for the platform in this issue entry. Several platforms lack support for SCN*8 so we just need to add the condition for this one.
(0029776)
Brad King (manager)
2012-06-20 13:27

Try this patch for the SCN*8 trouble. Please confirm that the problem is for both the HP and GNU compilers.

diff --git a/Utilities/KWIML/INT.h.in b/Utilities/KWIML/INT.h.in
index d40edcd..0251f02 100644
--- a/Utilities/KWIML/INT.h.in
+++ b/Utilities/KWIML/INT.h.in
@@ -259,8 +259,6 @@ An includer may test the following macros after inclusion:
 # endif
 #elif defined(__SUNPRO_C) || defined(__SUNPRO_CC)
 # define @KWIML@_INT__NO_SCN8
-#elif defined(__HP_cc) || defined(__HP_aCC)
-# define @KWIML@_INT__NO_SCN8
 #elif defined(__BORLANDC__)
 # define @KWIML@_INT__NO_SCN8
 # define @KWIML@_INT__NO_SCN64
@@ -268,6 +266,8 @@ An includer may test the following macros after inclusion:
 # define @KWIML@_INT__NO_SCN8
 #elif defined(__WATCOMC__)
 # define @KWIML@_INT__NO_SCN8
+# elif defined(__hpux) /* HP runtime lacks support (any compiler) */
+# define @KWIML@_INT__NO_SCN8
 #endif
 
 /* 8-bit d, i */
(0029777)
Brad King (manager)
2012-06-20 13:52

Here is a full patch to try for the UINT32_C problem:

diff --git a/Utilities/KWIML/INT.h.in b/Utilities/KWIML/INT.h.in
index d40edcd..dc34fec 100644
--- a/Utilities/KWIML/INT.h.in
+++ b/Utilities/KWIML/INT.h.in
@@ -91,10 +91,11 @@ An includer may test the following macros after inclusion:
     Some compilers define integer format macros incorrectly for their
     own formatted print/scan implementations.
 
-  @KWIML@_INT_BROKEN_INT64_C  = macro INT64_C is incorrect if defined
-  @KWIML@_INT_BROKEN_UINT64_C = macro UINT64_C is incorrect if defined
+  @KWIML@_INT_BROKEN_INT#_C  = macro INT#_C is incorrect if defined
+  @KWIML@_INT_BROKEN_UINT#_C = macro UINT#_C is incorrect if defined
     Some compilers define integer constant macros incorrectly and
-    cannot handle literals as large as the integer type.
+    cannot handle literals as large as the integer type or even
+    produce bad preprocessor syntax.
 
   @KWIML@_INT_BROKEN_INT8_T   = type 'int8_t' is available but incorrect
     Some compilers have a flag to make 'char' (un)signed but do not account
@@ -341,12 +342,12 @@ An includer may test the following macros after inclusion:
 #endif
 
 /* 8-bit constants */
-#if defined(INT8_C)
+#if defined(INT8_C) && !defined(@KWIML@_INT_BROKEN_INT8_C)
 # define @KWIML@_INT_INT8_C(c) INT8_C(c)
 #else
 # define @KWIML@_INT_INT8_C(c) c
 #endif
-#if defined(UINT8_C)
+#if defined(UINT8_C) && !defined(@KWIML@_INT_BROKEN_UINT8_C)
 # define @KWIML@_INT_UINT8_C(c) UINT8_C(c)
 #else
 # define @KWIML@_INT_UINT8_C(c) c ## u
@@ -435,12 +436,12 @@ An includer may test the following macros after inclusion:
 #endif
 
 /* 16-bit constants */
-#if defined(INT16_C)
+#if defined(INT16_C) && !defined(@KWIML@_INT_BROKEN_INT16_C)
 # define @KWIML@_INT_INT16_C(c) INT16_C(c)
 #else
 # define @KWIML@_INT_INT16_C(c) c
 #endif
-#if defined(UINT16_C)
+#if defined(UINT16_C) && !defined(@KWIML@_INT_BROKEN_UINT16_C)
 # define @KWIML@_INT_UINT16_C(c) UINT16_C(c)
 #else
 # define @KWIML@_INT_UINT16_C(c) c ## u
@@ -528,13 +529,19 @@ An includer may test the following macros after inclusion:
 # define @KWIML@_INT_PRIX32 "X"
 #endif
 
+#if defined(__hpux) && defined(__GNUC__) && !defined(__LP64__) \
+ && defined(__CONCAT__) && defined(__CONCAT_U__)
+  /* Some HPs define UINT32_C incorrectly and break GNU.  */
+# define @KWIML@_INT_BROKEN_UINT32_C
+#endif
+
 /* 32-bit constants */
-#if defined(INT32_C)
+#if defined(INT32_C) && !defined(@KWIML@_INT_BROKEN_INT32_C)
 # define @KWIML@_INT_INT32_C(c) INT32_C(c)
 #else
 # define @KWIML@_INT_INT32_C(c) c
 #endif
-#if defined(UINT32_C)
+#if defined(UINT32_C) && !defined(@KWIML@_INT_BROKEN_UINT32_C)
 # define @KWIML@_INT_UINT32_C(c) UINT32_C(c)
 #else
 # define @KWIML@_INT_UINT32_C(c) c ## u
(0029785)
Daniel Richard G. (reporter)
2012-06-20 16:14
edited on: 2012-06-21 08:00

I see the same SCN*8 failures for both cc- and gcc-built cmIML_test programs, prior to patching.

I will report back on test builds with gcc and cc using 2.8.8 plus the patches in 0013320:0029776 , 0013320:0029777 , and 0013321:0029774 . (The cc build, however, won't get very far due to bug 13332.)

(0029791)
Daniel Richard G. (reporter)
2012-06-21 01:04

The gcc build completes successfully; the cc build stopped at the expected point.

Both successfully built cmIML_test, and both binaries no longer produce any FAILED lines.
(0029795)
Brad King (manager)
2012-06-21 08:32
edited on: 2012-06-21 08:34

Applied UINT32_C fix and SCN*8 fix:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec1d3524 [^]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=539064d4 [^]

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=64d0e156 [^]

(0031458)
David Cole (manager)
2012-11-05 14:33

Closing resolved issues that have not been updated in more than 4 months.

- Issue History
Date Modified Username Field Change
2012-06-19 16:08 Daniel Richard G. New Issue
2012-06-19 16:26 Brad King Note Added: 0029749
2012-06-19 16:46 Daniel Richard G. Note Added: 0029750
2012-06-19 17:15 Brad King Note Added: 0029752
2012-06-19 17:19 Daniel Richard G. Note Added: 0029753
2012-06-19 17:19 Brad King Note Added: 0029754
2012-06-19 17:24 Brad King Note Added: 0029755
2012-06-19 17:25 Daniel Richard G. Note Added: 0029756
2012-06-19 17:28 Brad King Note Added: 0029757
2012-06-19 17:30 Daniel Richard G. Note Added: 0029758
2012-06-19 17:34 Brad King Note Added: 0029759
2012-06-20 08:12 Daniel Richard G. Note Added: 0029761
2012-06-20 08:20 Brad King Relationship added related to 0013321
2012-06-20 08:23 Brad King Note Added: 0029762
2012-06-20 11:39 Daniel Richard G. File Added: inttypes.h
2012-06-20 11:42 Daniel Richard G. Note Added: 0029769
2012-06-20 11:59 Brad King Note Added: 0029771
2012-06-20 12:14 Daniel Richard G. Note Added: 0029772
2012-06-20 13:00 Brad King Note Added: 0029773
2012-06-20 13:27 Brad King Note Added: 0029776
2012-06-20 13:52 Brad King Note Added: 0029777
2012-06-20 16:14 Daniel Richard G. Note Added: 0029785
2012-06-20 16:17 Daniel Richard G. Note Edited: 0029785 View Revisions
2012-06-20 16:18 Daniel Richard G. Note Edited: 0029785 View Revisions
2012-06-21 01:04 Daniel Richard G. Note Added: 0029791
2012-06-21 08:00 Brad King Note Edited: 0029785 View Revisions
2012-06-21 08:32 Brad King Note Added: 0029795
2012-06-21 08:32 Brad King Assigned To => Brad King
2012-06-21 08:32 Brad King Status new => resolved
2012-06-21 08:32 Brad King Resolution open => fixed
2012-06-21 08:34 Brad King Note Edited: 0029795 View Revisions
2012-11-05 14:33 David Cole Note Added: 0031458
2012-11-05 14:33 David Cole Status resolved => closed


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker