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.  */

 /* 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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to