On Mon, Jan 13, 2003 at 09:22:07AM -0800, Steve Fink wrote:
> On Jan-12, Nicholas Clark wrote:
> > IIRC Leo added an option to Configure.pl to turn on optimising.
> >
> > Prior to this, on IRC Dan said to me that we need to avoid the hack that perl5
> > found itself in, when it had to retro-fit the ability to change the compiler
> > flags per file.
> Would it be better to do it the other way around? We could put a
> marker at the end of each source file (mixed in with the emacs/vi flag
> section?) that specifies a set of compiler flags (or nothing at all if
> the default is ok.)
>
> If so, then I'd probably also use named sets ("big-jumptable-flags")
> or maybe even named modifiers ("default but violates-aliasing and
> trips-gcc2.95-O3-bug"). This would allow better descriptions of why
> the flags were being modified, and allow each compiler to deal with
> the situation differently (for "violates-aliasing", gcc would add
> -fno-strict-aliasing, lcc wouldn't do anything.)
I don't think that this will fly. The sort of flags we need to change are
things like this (Unicos):
if /etc/cpu -i | grep -q cfp
then
ccflags="$ccflags -h rounddiv"
fi
# Avoid an optimizer bug where a volatile variables
# isn't correctly saved and restored --Mark P. Lutz
pp_ctl_cflags='ccflags="$ccflags -h scalar0 -h vector0"'
# Otherwise the unpack %65c checksums will fail.
pp_pack_cflags='optimize="$ccflags -h scalar0 -h vector0"'
or this (Irix 6, based on a test of compiler version)
# workaround for an optimizer bug
# Made to work via UU/config.sh thing (or, rather, config.sh, since we're in
# a callback) from README.hints, plus further stuff; doesn't handle -g still,
# unfortunately - Allen
case "`$cc -version 2>&1`" in
*7.2.*)
test -z "$op_cflags" && echo "op_cflags=\"optimize=\\\"\$optimize -O1\\\"\"" >>
config.sh
test -z "$op_cflags" && op_cflags="optimize=\"\$optimize -O1\""
test -z "$opmini_cflags" && echo "opmini_cflags=\"optimize=\\\"\$optimize
-O1\\\"\"" >> config.sh
test -z "$opmini_cflags" && opmini_cflags="optimize=\"\$optimize -O1\""
;;
*7.3.1.*)
test -z "$op_cflags" && echo "op_cflags=\"optimize=\\\"\$optimize -O2\\\"\"" >>
config.sh
test -z "$op_cflags" && op_cflags="$op_cflags optimize=\"\$optimize -O2\""
test -z "$opmini_cflags" && echo "opmini_cflags=\"optimize=\\\"\$optimize
-O2\\\"\"" >> config.sh
test -z "$opmini_cflags" && opmini_cflags="optimize=\"\$optimize -O2\""
;;
esac
and other evil to work round compiler bugs found mainly by sweating blood.
(I don't know about the Irix bugs, but I do remember that working out
what the cause of Unicos bugs were wasn't fun. And I was mostly following
along at home by e-mail, not being able to offer Mark much more than
moral support. When unpack is going into an infinite loop on a Cray 6000 miles
away that you don't have any access to, there isn't much more you can do)
> I'm assuming the Configure system extracts the information from the
> source files and generates a makefile entry per source file with the
> appropriate compiler flags.
I'm also assuming a makefile entry for all source files with non-default
compiler flags, and a .c$(OBJ_EXT): rule for the default
So I'm thinking that we'll have a lot of per platform compiler specific
cruft that will need to be generalised programatically.
But more importantly we need a way for anyone to manually configure parrot
with wacky flags for a single file. Otherwise responses to perl6bug are going
to be along the lines of "edit the section in the source file, and add a new
(complex) rule that will trigger on your platform. Then reconfigure. Then
check the Makefile to see if that rule really did trigger".
Nicholas Clark
