Notes |
|
(0029749)
|
Brad King
|
2012-06-19 16:26
|
|
|
|
(0029750)
|
Daniel Richard G.
|
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
|
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.
|
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
|
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
|
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.
|
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
|
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.
|
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
|
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.
|
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
|
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.
|
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
|
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.
|
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
|
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
|
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
|
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.
|
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.
|
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
|
2012-06-21 08:32
(edited on: 2012-06-21 08:34) |
|
|
|
(0031458)
|
David Cole
|
2012-11-05 14:33
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|