Discussion:
stdalign test with HP-UX cc
(too old to reply)
Bruno Haible
2017-03-15 21:03:46 UTC
Permalink
Raw Message
Hi Paul,

With cc on HP-UX 11.31, test-stdalign.c fails to compile:

cc -DHAVE_CONFIG_H -I. -I.. -DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I. -I.. -I./.. -I../gllib -I./../gllib -g -c -o test-stdalign.o test-stdalign.c
cc: "test-stdalign.c", line 65: error 1000: Unexpected symbol: "8".
cc: "test-stdalign.c", line 65: error 1000: Unexpected symbol: "8".
cc: "test-stdalign.c", line 66: error 1000: Unexpected symbol: "8".
cc: "test-stdalign.c", line 66: error 1000: Unexpected symbol: "8".
...

This is the info about the compiler:

$ cat > x.c
__STDC_VERSION__
__HP_cc
__HP_aCC

$ cc -E x.c
# 1 "x.c"
__STDC_VERSION__
111120
__HP_aCC

The number 111120 is larger than 061200 (octal!, = 25216), but it apparently
does not support the definition for _Alignas that you try use in stdalign.in.h
line 108.

Since I don't have access to a newer HP-UX cc compiler, I propose to just
disable this definition for HP-UX cc. This patch fixes the error.


2017-03-14 Bruno Haible <***@clisp.org>

stdalign: Make it work with HP-UX cc.
* lib/stdalign.in.h (_Alignas): Don't define for HP-UX cc.

diff --git a/lib/stdalign.in.h b/lib/stdalign.in.h
index c2b791e..f6f4190 100644
--- a/lib/stdalign.in.h
+++ b/lib/stdalign.in.h
@@ -103,7 +103,7 @@
# elif ((defined __APPLE__ && defined __MACH__ \
? 4 < __GNUC__ + (1 <= __GNUC_MINOR__) \
: __GNUC__) \
- || 061200 <= __HP_cc || 061200 <= __HP_aCC \
+ || 061200 <= __HP_aCC \
|| __ICC || 0x590 <= __SUNPRO_C || 0x0600 <= __xlC__)
# define _Alignas(a) __attribute__ ((__aligned__ (a)))
# elif 1300 <= _MSC_VER
Paul Eggert
2017-03-16 07:38:14 UTC
Permalink
Raw Message
Post by Bruno Haible
Since I don't have access to a newer HP-UX cc compiler, I propose to just
disable this definition for HP-UX cc. This patch fixes the error.
That sounds too drastic; I worry that it would break GNU Emacs, which relies on
having alignas.

Does Emacs 25.1 build with that compiler? If so, could you investigate why Enacs
works, whereas the stdalign test fails? Emacs 25.1 should be using
lib/stdalign.in.h. If it works for Emacs and fails for tests/test-stdalign.c,
then the latter is probably just too picky.

I don't have access to any HP-UX cc, unfortunately. MariaDB 10.1.22
include/my_compiler.h uses this test:

#elif defined(__HP_aCC) || defined(__HP_cc)
# if (__HP_aCC >= 60000) || (__HP_cc >= 60000)

and Qt 4, which I think worries only about C++, has the equivalent of:

#if __cplusplus >= 199707L && __HP_aCC-0 >= 061200

(though it uses '__attribute__((aligned(n))', not '__attribute__ ((__aligned__
(n)))'). I expect it's Qt that I got the "061200" from. At this point these
compiler-version numbers are so old it will be difficult to find out whether
they were really supposed to be octal or decimal, way back when.

Does it fix things to replace '__attribute__ ((__aligned__ (n)))' with
'__attribute__((aligned(n))' in lib/stdalign.in.h? If so, we could use that as a
workaround. This is a long-shot, admittedly.
Bruno Haible
2017-03-16 21:29:09 UTC
Permalink
Raw Message
Hi Paul,
Post by Paul Eggert
Post by Bruno Haible
Since I don't have access to a newer HP-UX cc compiler, I propose to just
disable this definition for HP-UX cc. This patch fixes the error.
That sounds too drastic; I worry that it would break GNU Emacs, which relies on
having alignas.
Does Emacs 25.1 build with that compiler?
No, Emacs 25.1 cannot be built with this compiler.

==== 1st attempt

$ CC="cc -Ae -D_XOPEN_SOURCE=500"
$ export CC
$ ./configure --prefix=$HOME/prefix-hpux113-cc --with-x-toolkit=no --with-xpm=no --with-jpeg=no --with-png=no --with-gif=no --with-tiff=no
$ gmake
...
CC strftime.o
cc: "time-internal.h", line 48: error 1681: Usage of `flexible array members' needs option `-AC99'
cc: "time-internal.h", line 48: error 1578: Size of struct or union member is unknown.

==== 2nd attempt

$ CC="cc -Ae -D_XOPEN_SOURCE=500 -AC99"
$ export CC
$ ./configure --prefix=$HOME/prefix-hpux113-cc --with-x-toolkit=no --with-xpm=no --with-jpeg=no --with-png=no --with-gif=no --with-tiff=no
$ gmake
...
CCLD ebrowse
cc: "ebrowse.c", line 281: error 1687: Illegal use of flexible array: structs with FAMs cannot be members of other structs.
cc: "ebrowse.c", line 281: error 1687: Illegal use of flexible array: structs with FAMs cannot be members of other structs.
cc: "ebrowse.c", line 281: error 1687: Illegal use of flexible array: structs with FAMs cannot be members of other structs.
cc: "ebrowse.c", line 281: error 1687: Illegal use of flexible array: structs with FAMs cannot be members of other structs.
cc: "ebrowse.c", line 281: error 1687: Illegal use of flexible array: structs with FAMs cannot be members of other structs.
cc: "ebrowse.c", line 281: error 1687: Illegal use of flexible array: structs with FAMs cannot be members of other structs.

Now, let's pick a source file that uses 'alignas':

$ cd src
$ gmake buffer.o
GEN lisp.mk
gmake -C ../lib-src make-docfile
gmake[1]: Entering directory `/home/haible/emacs-25.1/lib-src'
CCLD make-docfile
gmake[1]: Leaving directory `/home/haible/emacs-25.1/lib-src'
GEN globals.h
CC buffer.o
cc: "globals.h", line 1030: error 1000: Unexpected symbol: "8".
cc: "globals.h", line 1030: error 1670: Illegal attribute __aligned__ specified.
cc: "lisp.h", line 852: error 1669: Illegal version declaration for "XSYMBOL".
cc: "lisp.h", line 1454: warning 604: Pointers are not assignment-compatible.
cc: "lisp.h", line 1532: warning 604: Pointers are not assignment-compatible.
cc: "lisp.h", line 1688: warning 604: Pointers are not assignment-compatible.
cc: "lisp.h", line 3342: warning 604: Pointers are not assignment-compatible.
cc: "lisp.h", line 3342: warning 563: Argument #1 is not the correct type.
cc: "dispextern.h", line 2234: error 1687: Illegal use of flexible array: structs with FAMs cannot be members of other structs.
cc: "buffer.c", line 65: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 65: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 88: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 88: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 370: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 370: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 379: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 379: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 437: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 437: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 451: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 451: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 496: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 496: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 733: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 733: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 880: error 1669: Illegal version declaration for "delete_all_overlays".
cc: "buffer.c", line 912: error 1669: Illegal version declaration for "reset_buffer".
cc: "buffer.c", line 1042: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1042: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1097: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1097: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1106: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1106: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1114: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1114: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1125: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1125: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1238: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1238: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1271: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1271: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1281: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1281: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1303: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1303: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1325: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1325: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1375: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1375: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1386: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1386: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1401: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1401: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1467: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1467: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1556: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1556: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1582: error 1669: Illegal version declaration for "compact_buffer".
cc: "buffer.c", line 1615: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1615: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1936: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1936: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 1970: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 1970: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 2012: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 2012: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 2025: error 1669: Illegal version declaration for "set_buffer_internal_1".
cc: "buffer.c", line 2089: error 1669: Illegal version declaration for "set_buffer_temp".
cc: "buffer.c", line 2108: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 2108: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 2143: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 2143: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 2162: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 2162: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 2232: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 2232: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 2389: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 2389: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 2677: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 2677: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 3409: error 1669: Illegal version declaration for "recenter_overlay_lists".
cc: "buffer.c", line 3708: error 1669: Illegal version declaration for "fix_overlays_before".
cc: "buffer.c", line 3785: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 3785: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 3792: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 3792: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 3910: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 3910: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 4013: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 4013: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 4045: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 4045: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 4057: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 4057: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 4066: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 4066: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 4075: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 4075: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 4085: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 4085: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 4097: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 4097: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 4131: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 4131: error 1670: Illegal attribute __aligned__ specified.
cc: "buffer.c", line 4165: error 1000: Unexpected symbol: "8".
cc: panic 2161: Maximum allowed number of errors exceeded.
gmake: *** [buffer.o] Error 1
Post by Paul Eggert
Does it fix things to replace '__attribute__ ((__aligned__ (n)))' with
'__attribute__((aligned(n))' in lib/stdalign.in.h?
That's not a bad guess, based on [1] p. 150. But it fails in the same way:
...
cc: "buffer.c", line 65: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 65: error 1670: Illegal attribute aligned specified.
cc: "buffer.c", line 88: error 1000: Unexpected symbol: "8".
cc: "buffer.c", line 88: error 1670: Illegal attribute aligned specified.
...

Bruno

[1] http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=4268164&docLocale=en_US&docId=emr_na-c02652146
Paul Eggert
2017-03-17 08:59:16 UTC
Permalink
Raw Message
Post by Bruno Haible
Emacs 25.1 cannot be built with this compiler.
Thanks for looking into this. Ouch. It looks like HP-UX cc has serious bugs in
its implementation of C99 flexible array members. I added this issue to
emacs/etc/PROBLEMS, and am suggesting GCC instead of HP-UX cc for people who
want to build Emacs on HP-UX. See:

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a09473261c8b11243e68d84c5dc2448d65a67e77
Post by Bruno Haible
CCLD ebrowse
cc: "ebrowse.c", line 281: error 1687: Illegal use of flexible array: structs with FAMs cannot be members of other structs.
This suggests that the HP-UX cc flexible array member bug is as follows: if a
struct X contains a 'struct Y *' member where 'struct Y' has a flexible array
member, the compiler incorrectly rejects the definition of struct X. Does the
attached Gnulib patch suffice to detect the HP-UX cc bug? If so, this should fix
Emacs's problem with flexible array members on HP-UX cc. I installed this patch
into Gnulib since it shouldn't hurt even if it doesn't catch the HP-UX cc bug.


For the problem with __attribute__ ((__aligned__ (8))), does it suffice to put
the declaration after the identifier? E.g., does this compile:

int foo __attribute__ ((__aligned__ (8))) = 10;

whereas this does not compile?

int __attribute__ ((__aligned__ (8))) bar = 20;

If so, I think we can work around this problem in Emacs (even if we cannot solve
the problem in general for Gnulib stdalign), and something like the patch you
proposed should suffice for Gnulib (although we'd also need to fix
m4/stdalign.m4 to keep it in sync with lib/stdalign.in.h).

Also, in your build of Emacs 25.1, is the symbol HAVE_STRUCT_ATTRIBUTE_ALIGNED
defined in src/config.h?
Bruno Haible
2017-03-17 21:12:17 UTC
Permalink
Raw Message
Hi Paul,
Post by Paul Eggert
Post by Bruno Haible
CCLD ebrowse
cc: "ebrowse.c", line 281: error 1687: Illegal use of flexible array: structs with FAMs cannot be members of other structs.
This suggests that the HP-UX cc flexible array member bug is as follows: if a
struct X contains a 'struct Y *' member where 'struct Y' has a flexible array
member, the compiler incorrectly rejects the definition of struct X.
Confirmed:
$ cat foo.c
struct Y {
int a;
char b[];
};

struct X {
int b;
struct Y *p;
};

$ cc -AC99 -c foo.c
cc: "foo.c", line 6: error 1687: Illegal use of flexible array: structs with FAMs cannot be members of other structs.
Post by Paul Eggert
Does the
attached Gnulib patch suffice to detect the HP-UX cc bug?
Yes. Output before your patch:
checking for flexible array member... yes
and after your patch:
checking for flexible array member... no
Post by Paul Eggert
For the problem with __attribute__ ((__aligned__ (8))), does it suffice to put
int foo __attribute__ ((__aligned__ (8))) = 10;
whereas this does not compile?
int __attribute__ ((__aligned__ (8))) bar = 20;
No, nothing like this works.

$ cat foo.c
int aa __attribute__ ((__aligned__ (8))) = 10;

int ab __attribute__ ((aligned (8))) = 10;

int __attribute__ ((__aligned__ (8))) ac = 10;

int __attribute__ ((aligned (8))) ad = 10;

__attribute__ ((__aligned__ (8))) int ae = 10;

__attribute__ ((aligned (8))) int af = 10;

$ cc -AC99 -c foo.c
cc: "foo.c", line 1: error 1000: Unexpected symbol: "8".
cc: "foo.c", line 1: error 1670: Illegal attribute __aligned__ specified.
cc: "foo.c", line 3: error 1000: Unexpected symbol: "8".
cc: "foo.c", line 3: error 1670: Illegal attribute aligned specified.
cc: "foo.c", line 5: error 1000: Unexpected symbol: "8".
cc: "foo.c", line 5: error 1670: Illegal attribute __aligned__ specified.
cc: "foo.c", line 7: error 1000: Unexpected symbol: "8".
cc: "foo.c", line 7: error 1670: Illegal attribute aligned specified.
cc: "foo.c", line 9: error 1000: Unexpected symbol: "8".
cc: "foo.c", line 9: error 1670: Illegal attribute __aligned__ specified.
cc: "foo.c", line 11: error 1000: Unexpected symbol: "8".
cc: "foo.c", line 11: error 1670: Illegal attribute aligned specified.
Post by Paul Eggert
Also, in your build of Emacs 25.1, is the symbol HAVE_STRUCT_ATTRIBUTE_ALIGNED
defined in src/config.h?
No, it's #undef'ed.
Post by Paul Eggert
(although we'd also need to fix m4/stdalign.m4 to keep it in sync with
lib/stdalign.in.h).
Good point. Here's a revised proposed patch.


2017-03-17 Bruno Haible <***@clisp.org>

stdalign: Make it work with HP-UX cc.
* lib/stdalign.in.h (_Alignas): Don't define for HP-UX cc.
* m4/stdalign.m4 (gl_STDALIGN_H): No need to enable the extra test
for HP-UX cc.

diff --git a/lib/stdalign.in.h b/lib/stdalign.in.h
index c2b791e..f6f4190 100644
--- a/lib/stdalign.in.h
+++ b/lib/stdalign.in.h
@@ -103,7 +103,7 @@
# elif ((defined __APPLE__ && defined __MACH__ \
? 4 < __GNUC__ + (1 <= __GNUC_MINOR__) \
: __GNUC__) \
- || 061200 <= __HP_cc || 061200 <= __HP_aCC \
+ || 061200 <= __HP_aCC \
|| __ICC || 0x590 <= __SUNPRO_C || 0x0600 <= __xlC__)
# define _Alignas(a) __attribute__ ((__aligned__ (a)))
# elif 1300 <= _MSC_VER
diff --git a/m4/stdalign.m4 b/m4/stdalign.m4
index 3a12658..5c15ef0 100644
--- a/m4/stdalign.m4
+++ b/m4/stdalign.m4
@@ -35,7 +35,7 @@ AC_DEFUN([gl_STDALIGN_H],
|| (defined __APPLE__ && defined __MACH__ \
? 4 < __GNUC__ + (1 <= __GNUC_MINOR__) \
: __GNUC__) \
- || __HP_cc || __HP_aCC || __IBMC__ || __IBMCPP__ \
+ || __HP_aCC || __IBMC__ || __IBMCPP__ \
|| __ICC || 0x5110 <= __SUNPRO_C \
|| 1300 <= _MSC_VER)
struct alignas_test { char c; char alignas (8) alignas_8; };
Paul Eggert
2017-03-17 22:10:21 UTC
Permalink
Raw Message
Post by Bruno Haible
No, nothing like this works.
$ cat foo.c
int aa __attribute__ ((__aligned__ (8))) = 10;
int ab __attribute__ ((aligned (8))) = 10;
That's strange, since Line 3 is taken almost verbatim from the HP-UX
manual you mentioned. I looked for other people who have run into the
problem, and found only this bug report dated 2007:

https://bugzilla.gnome.org/show_bug.cgi?id=468114

with no followup.

Looking through the HP-UX manuals, maybe the 'aligned' attribute is
supported only in GCC mode? What happens if you compile with 'cc
+std=gnu'? or with 'cc +std=gcc', or 'cc -Agnu', or 'cc -Agcc'? See
pages 13-14 of:

http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c04221956

The revised patch to the stdalign module looks good to me; thanks.
Bruno Haible
2017-03-17 22:28:18 UTC
Permalink
Raw Message
Hi Paul,
Post by Paul Eggert
That's strange, since Line 3 is taken almost verbatim from the HP-UX
manual you mentioned.
This manual is for a quite new HP cc on Itanium (IA-64) servers.
I'm talking about an older HP cc on hppa.
Post by Paul Eggert
What happens if you compile with 'cc
+std=gnu'? or with 'cc +std=gcc', or 'cc -Agnu', or 'cc -Agcc'? See
Doesn't help:

cc: warning 422: Unknown option "std=gnu" ignored.

cc: warning 422: Unknown option "std=gcc" ignored.

cc: error 1412: Unrecognized argument "gnu" to option -A.

cc: error 1412: Unrecognized argument "gcc" to option -A.
Post by Paul Eggert
The revised patch to the stdalign module looks good to me; thanks.
OK, I've pushed it.

Bruno
Paul Eggert
2017-03-19 06:29:48 UTC
Permalink
Raw Message
Post by Bruno Haible
This manual is for a quite new HP cc on Itanium (IA-64) servers.
I'm talking about an older HP cc on hppa.
2008 is "quite new"? Clocks must run slowly in the HP-UX world. :-)

I guess the 'aligned' attribute works with some HP-UX cc compilers but not
others. We know it does not work on your compiler (PA-RISC, __HP_cc==111120).
This circa 2013 email quoting Richard Lloyd:

https://lists.gnu.org/archive/html/bug-gnulib/2013-02/msg00095.html

suggests that he had PA-RISC version 111120 and Itanium version 62600 - the
former corresponding to the compiler you used, and the latter presumably
corresponding to the Itanium version A.06.20 listed in the manual you cited, the
manual that says "__attribute__ ((aligned (16)))" works.

I'm inclined to guess that the 'aligned' attribute works on new-enough Itanium
but not PA-RISC compilers. If my guess is right Emacs is in less trouble, since
PA-RISC is mostly obsolete but Itanium is still going. So, how about if we
assume that the "061200" applies to Itanium but not PA-RISC? That should fix
your problem, and we can find out later if the "061200" is right for Itanium, if
and when someone tries it out. Something like the attached, which I boldly
installed.
Bruno Haible
2017-03-19 10:50:35 UTC
Permalink
Raw Message
Hi Paul,
Post by Paul Eggert
I'm inclined to guess that the 'aligned' attribute works on new-enough Itanium
but not PA-RISC compilers.
Post by Bruno Haible
This manual is for a quite new HP cc on Itanium (IA-64) servers.
I'm talking about an older HP cc on hppa.
2008 is "quite new"? Clocks must run slowly in the HP-UX world. :-)
I guess the 'aligned' attribute works with some HP-UX cc compilers but not
others. We know it does not work on your compiler (PA-RISC, __HP_cc==111120).
https://lists.gnu.org/archive/html/bug-gnulib/2013-02/msg00095.html
suggests that he had PA-RISC version 111120 and Itanium version 62600 - the
former corresponding to the compiler you used, and the latter presumably
corresponding to the Itanium version A.06.20 listed in the manual you cited, the
manual that says "__attribute__ ((aligned (16)))" works.
I'm inclined to guess that the 'aligned' attribute works on new-enough Itanium
but not PA-RISC compilers. If my guess is right Emacs is in less trouble, since
PA-RISC is mostly obsolete but Itanium is still going. So, how about if we
assume that the "061200" applies to Itanium but not PA-RISC? That should fix
your problem, and we can find out later if the "061200" is right for Itanium, if
and when someone tries it out. Something like the attached, which I boldly
installed.
Bruno Haible
2017-03-19 11:02:34 UTC
Permalink
Raw Message
Hi Paul,
Post by Paul Eggert
I'm inclined to guess that the 'aligned' attribute works on new-enough Itanium
but not PA-RISC compilers.
Possibly. And I won't report a bug about this patch, because I don't have
access to a HP-UX IA64 machine.

But my previous report about a portability problem arose because code was
committed to gnulib without ever having been tested on the relevant platforms.
Now again, you introduce such code.

I would find it better to have it tested on actual HP-UX IA64 machines.
Here are two possible ideas:
- Ask on the platform-testers mailing list for someone willing to test
it for us. (For example, without the help of Daniel Richard G we would
not be able to able to do anything for z/OS.)
- Try to get shell access to such a machine. For example from the people
at http://hpux.connect.org.uk/, or from some of the people mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 .

Bruno
Bruno Haible
2017-03-19 12:34:36 UTC
Permalink
Raw Message
Hi Paul,
Post by Bruno Haible
I won't report a bug about this patch, because I don't have
access to a HP-UX IA64 machine.
I have access to such a machine now.


1) About the version numbers:

$ cc -V
cc: HP C/aC++ B3910B A.06.27.03 [Nov 30 2012]

$ aCC -V
aCC: HP C/aC++ B3910B A.06.27.03 [Nov 30 2012]

$ cat ver.c
__HP_cc
__HP_aCC

$ cc -E ver.c
#line 1 "ver.c"
62703
__HP_aCC

$ aCC -E ver.c
#line 1 "ver.c"
__HP_cc
62703

So, as you can see:
- The version numeber does not include a leading 0. The person who introduced
that 0 was probably not aware of the syntax of octal numbers in C.
- Version numbers in HP-UX hppa cc and in HP-UX ia64 cc are unrelated. The ones
in HP-UX hppa cc have a major number of 11 although it's much older. So,
it's good to keep the '__ia64' in the condition in stdalign.in.h.


2) About the attribute aligned syntax:

$ cat foo.c
int aa __attribute__ ((__aligned__ (8))) = 10;

int ab __attribute__ ((aligned (8))) = 10;

int __attribute__ ((__aligned__ (8))) ac = 10;

int __attribute__ ((aligned (8))) ad = 10;

__attribute__ ((__aligned__ (8))) int ae = 10;

__attribute__ ((aligned (8))) int af = 10;

$ cc -Ae -c foo.c
$ cc -AC99 -c foo.c

So, the compiler does understand the syntax, as promised in the documentation.


3) The test-stdalign test now compiles, but it fails:

$ ./test-stdalign
../../gltests/test-stdalign.c:88: assertion '(uintptr_t) &(static_char_alignas) % TEST_ALIGNMENT == 0' failed
zsh: abort (core dumped) ./test-stdalign

In the test we already have a bold

#if defined __SUNPRO_C
/* Avoid a test failure due to Sun Studio Developer Bug Report #2125432. */
fputs ("Skipping test: known Sun C compiler bug\n", stderr);
return 77;
#else

I suggest to add a similar #elif for HP-UX ia64 cc.


Bruno
Paul Eggert
2017-03-19 16:35:58 UTC
Permalink
Raw Message
Post by Bruno Haible
I have access to such a machine now.
Excellent! Thanks.
Post by Bruno Haible
- The version numeber does not include a leading 0.
Yes, that seems to be the practice now. Perhaps older versions had a leading 0
before they discovered that meant it was octal.
Post by Bruno Haible
I suggest to add a similar #elif for HP-UX ia64 cc.
Thanks, I installed the attached.

Loading...