Hello,
Michael Haardt schrieb:
>>B.11.23 ia64
>> C-ANSI-C C.06.00 HP C/ANSI C Compiler
>>A working solution here is setting CFLAGS to "-Ae -AOe +Onolimit".
> What does -AOe do? My compiler does not offer that.
It's an ipf-only option. From man cc:
-AOa
-AOe See corresponding -Aa or -Ae option. In addition,
allows the optimizer to aggressively exploit the
assumption that the source code conforms to the ANSI
programming language C or C++ standard. At present,
the effect is to make +Otype_safety=ansi the default.
As new independently-controllable optimizations are
developed that depend on the ANSI standards, the flags
that enable those optimizations may also become the
default under -AOa/-AOe.
> -Ae is default here,
> so I don't need to specify that. It is useful to enable -z, though,
> in order to catch null pointer references. How about that on Itanium?
Well, you may or may not add "-z". According to the manuals, there
is no difference between PA and ipf here.
> What happens with +O2 on Itanium?
That option is available, but "exim -bd" gets broken.
> I hope we can find a set of flags that allows building Exim for both
> architectures, old and new compiler. +O3 fails on the old compiler on
> HP-PA, so we had to go back to +O2 there, but I doubt you will notice
> the difference.
What version of cc does "+O3" fail with? I had three working test
compiles on PA-RISC using that option yesterday. I agree that
presumably an application like exim - where speed relies mainly on
i/o - will not substantially benefit from the differences between
two adjacent optimization levels, though.
[common compiler flags] As far as I can see, this will be quite
difficult to achieve. The compiler on ipf appears to be a completely
different product (different options, different behaviour, different
message numbering scheme,..).
Kind regards,
vt
P.S.:
+Otype_safety=[off|limited|ansi|strong]
Enable [disable] aliasing across types.
off The default. Specifies that aliasing
can occur freely across types. This is
a synonym to +Onoptrs_ansi and
+Onoptrs_strongly_typed options in
legacy cc.
limited
Code follows ANSI aliasing rules.
Unnamed objects should be treated as if
they had an unknown type.
ansi Code follows ANSI aliasing rules, and
unnamed objects should be treated the
same as named objects. This option is
synonym to +Optrs_ansi option in legacy
cc.
strong
Code follows ANSI aliasing rules, except
that accesses through lvalues of a
character type are not permitted to
touch objects of other types. This
assumes that field addresses are not
taken. This option is synonym to
+Optrs_strongly_typed option in legacy
cc.
P.P.S.: Maybe we should continue off-list? I don't want to annoy
anyone with more details on our platform-specific issues...
