Bruno Haible wrote:
I have access to such a machine now.
Excellent! Thanks.
- 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.
I suggest to add a similar #e
Hi Paul,
I spoke too soon when I wrote:
> 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.
Hi Paul,
> 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 co
Hi Paul,
> I'm inclined to guess that the 'aligned' attribute works on new-enough
> Itanium
> but not PA-RISC compilers.
>
> > 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 H
Bruno Haible wrote:
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 doe
Hi Paul,
> 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.
> What happens if you compile with 'cc
> +std=gnu'? or with 'cc +std=gcc', or 'cc -
On 03/17/2017 02:12 PM, Bruno Haible wrote:
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
Hi Paul,
> > 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 '
Bruno Haible wrote:
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 w
Hi Paul,
> Bruno Haible wrote:
> > 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 Em
Bruno Haible wrote:
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 comp
11 matches
Mail list logo