I have been using the following fixes for gcc -falign-foo for almost
a month with no problem.
%%%
Index: toplev.c
===================================================================
RCS file: /home/ncvs/src/contrib/gcc/toplev.c,v
retrieving revision 1.13
diff -u -2 -r1.13 toplev.c
--- toplev.c 9 May 2002 22:15:04 -0000 1.13
+++ toplev.c 12 May 2002 14:22:43 -0000
@@ -4747,5 +4747,5 @@
}
- if (optimize < 2 || optimize_size)
+ if (optimize_size)
{
align_loops = 1;
Index: config/i386/i386.h
===================================================================
RCS file: /home/ncvs/src/contrib/gcc/config/i386/i386.h,v
retrieving revision 1.9
diff -u -2 -r1.9 i386.h
--- config/i386/i386.h 30 May 2002 06:04:14 -0000 1.9
+++ config/i386/i386.h 1 Jun 2002 20:49:25 -0000
@@ -762,5 +778,5 @@
/* Allocation boundary for the code of a function. */
-#define FUNCTION_BOUNDARY 16
+#define FUNCTION_BOUNDARY 8
/* Alignment of field after `int : 0' in a structure. */
%%%
The patch to toplev.c fixes a plain bug. gcc -O0 and -O1 didn't do
the easy optimization of alignment for space. They attempted to do
the easy optimization of alignment for time, which should be to 1-byte
alignment on i386's. However, the second bug forces the alignment to
2 bytes for functions only. The alignment should be to the
target-dependent default. This is in struct processor_target_table[]
in config/i386/i386.c on i386's. The defaults are very target-dependent
and much larger than 1 or 2 (e.g., 64 for align-jumps on athlons!).
The patch in i386.h permits -falign-foo=1 to work. It is not quite
right, because a boundary of 2 bytes is apparently required for C++.
This shouldn't be a problem, since the boundary shouldn't be 1 unless
the user really wants that boundary and sets it using -falign-functions=1.
However, the following cases give the too-small boundary of 1 even when
-falign-functions is not used:
- without the first patch: both -Oo and -O1
- with the first patch: -Os only.
The thread about the PR (http://gcc.gnu.org/ml/gcc/2002-05/msg00989.html)
doesn't seem to lead anywhere.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
