* Re: GCC 3.3, GCC 3.4
@ 2003-02-02 6:17 Brad Lucier
0 siblings, 0 replies; 115+ messages in thread
From: Brad Lucier @ 2003-02-02 6:17 UTC (permalink / raw)
To: matz; +Cc: Brad Lucier, gcc
Michael:
I, and I presume many other people, have a great deal of interest in
the new register allocator, both for its promise and for the evidence
so far of its capabilities.
My understanding from previous messages on this list is that the new ra
would be included in 3.3 but not supported; support would begin in 3.4.
(By support, I mean that if someone finds bugs in it then the intention
is that those bugs will be fixed.)
David Edelsohn indicated that other people are prepared to help with
the new ra. I hope that some way will be found to organize the work
so that the new ra will be ready for 3.4.
Brad
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-04 20:47 ` Matt Austern
@ 2003-02-06 19:26 ` Tim Josling
0 siblings, 0 replies; 115+ messages in thread
From: Tim Josling @ 2003-02-06 19:26 UTC (permalink / raw)
Cc: gcc
[-- Attachment #1: Type: text/plain, Size: 4478 bytes --]
> > Matt Austern at Apple did similar experiment by using ggc placeholder.
> > (same interface as ggc, no collection, allocate memory using mmap in
> > chunks and
> > satisfy memory allocation requests from these chunks etc..).
> >
> > He got around ~12% speedup for sample c++ source.
> >
> > -Devang
> > (also from Geoff Keating in another email)
> > To be precise, Matt found that the speedup of using the ggc
> > placeholder was about equivalent to the speedup of using ggc-page but
> > disabling garbage collection. This contradicts the results that Tim
> > Josling got above.
> >
> > --
> > - Geoffrey Keating
> > Matt,
> >
> > Any chance I could get a copy of your c++ source and/or your minimal
> > non-gc
> > implementation so I can see what is under the discrepancy?
>
> My placeholder "collector" is attached...
> > Also did you keep your actual numbers, and what was your machine
> > configuration.
>
> I tested running cc1plus only, on a preprocessed source file. I don't
> think I can include that source file, I'm afraid, because it's
> proprietary
> Apple code. I was running the tests on a PPC running OS X
> 10.2.2.
>
> Numbers:
> TOT 2.6s real, 2.3s user, 0.3s sys
> TOT with placeholder gc 2.3s real, 2.0s user, 0.3s sys
>
> The numbers changed a bit depending on how large the chunks were
> that I allocated with ggc-placeholder.c. I can probably find some more
> detailed numbers if I try.
>
> And I have to say, these results surprised me. I expected to see bigger
> gains, because of improved locality.
>
> --Matt
Matt,
Thanks.
Tests
-----
I reran the tests with four scenarios:
1. Standard ggc-page.c
2. Stndard ggc-page.c but ggc_collect just returns immediately.
3. Matt's placeholder routine (mmap/alignment)
4. My placeholder routine (xmalloc/no alignment)
Numbers
=======
User CPU time in seconds
------------------------
gcc bootstrap on Pentium III, 1ghz, 256 mb ram, compaq Armada E500.
Configured languages, c c++ TL CB, c TL CB, Extra when c++
configured
TL = treelang, CB = COBOL
1. ggc-page.c, 2815.28, 1998.96, 816.32
2. ggc-page.c (no collect), 2642.98, 1894.14, 748.84
3. placeholder (matt), 2527.46, 1841.54, 685.92
4. placeholder (tim), 2527.41, 1835.33, 692.08
Cost of ggc-alloc %, 4.57, 2.86, 9.17
Cost of collects % , 6.12, 5.24, 8.27
Cost of GC (alloc+collect)%, 11.39, 8.55, 19.01
(this table best viewed in a fixed width font)
The elapsed times were in line with the CPU times and the system CPU time did
not vary much.
Placeholder routine
===================
I attached my version of the placeholder routine (new version, last year's one
is offsite). It is about the same speed as Matt's routine within 0.3%. I just
copied it over ggc-page.c rather than change the make files (having first
saved a copy of ggc-page.c).
There does not seem to be any difference between the placeholder routines that
would explain the discrepancy.
Analysis
========
The results for the gcc build were different from the results I have from last
year. Last year, running the ggc_collect sped the build up. Now it slows it
down further, by around 5%.
\x13
> > Geoff Keating...
> > To be precise, Matt found that the speedup of using the ggc
> > placeholder was about equivalent to the speedup of using ggc-page but
> > disabling garbage collection. This contradicts the results that Tim
> > Josling got above.
> Matt Austern...
> Yes. That's why I haven't been pushing to have a mode in which
> gc is entirely removed: my measurements suggest that the most
> important way in which gc introduces overhead is the most obvious
> one: the collection phase itself takes time.
Geoff is saying and you agree that the CPU for placeholder ~= CPU for
gcc_page_no_collect i.e. the main gain is from not collecting.
However according to my numbers for gcc bootstrap, the placeholder is
significantly faster than ggc_page_no_collect.
I am trying to get some numbers for some C++ programs.
It would be useful to know how much CPU\x18 Matt's C++ pgm takes with
ggc-page-no-collect i.e. no collection, but with things laid out for ggc-page.
Above we only have the numbers for standard GC and for the placeholder.
Tim Josling
[-- Attachment #2: ggc-tim.c --]
[-- Type: text, Size: 3983 bytes --]
#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "tm.h"
#include "tree.h"
#include "rtl.h"
#include "tm_p.h"
#include "toplev.h"
#include "varray.h"
#include "flags.h"
#include "ggc.h"
#include "timevar.h"
#include "params.h"
#ifdef ENABLE_VALGRIND_CHECKING
#include <valgrind.h>
#else
/* Avoid #ifdef:s when we can help it. */
#define VALGRIND_DISCARD(x)
#endif
#include <assert.h>
#include <sys/mman.h>
/* Alloc SIZE bytes of GC'able memory. */
#define K 1024
#define M (K * K)
static const size_t chunksize = (1 * M); /* 1MB */
static char* chunk_begin = 0;
static size_t chunk_remaining = 0;
static void get_chunk(size_t min);
static void get_chunk(size_t min)
{
size_t actual;
actual = (chunksize > min)? chunksize : min;
chunk_begin = xmalloc (actual);
chunk_remaining = actual;
}
void *
ggc_alloc (size_t size)
{
char* user_area;
size_t* size_area;
size_t actual;
actual = size + sizeof (size_t);
if (actual > chunk_remaining)
get_chunk(actual);
user_area = chunk_begin + sizeof (size_t);
size_area = (size_t*) (chunk_begin);
*size_area = size;
chunk_begin += actual;
chunk_remaining -= actual;
return user_area;
}
int
ggc_set_mark (const void *p ATTRIBUTE_UNUSED)
{
abort ();
return 0;
}
/* Return 1 if P has been marked, zero otherwise. */
int
ggc_marked_p (const void *p ATTRIBUTE_UNUSED)
{
return 1;
}
/* Return the size of the gc-able object P. */
size_t
ggc_get_size (const void *p)
{
return *((int*) ((char*) p - sizeof(size_t)));
}
/* A placeholder collection routine */
void
ggc_collect ()
{
}
/* Called once to initialize the garbage collector. */
void
init_ggc ()
{
}
/* Start a new GGC context. Memory allocated in previous contexts
will not be collected while the new context is active. */
void
ggc_push_context ()
{
}
/* Finish a GC context. Any uncollected memory in the new context
will be merged with the old context. */
void
ggc_pop_context ()
{
}
/* Report on GC memory usage. */
void
ggc_print_statistics ()
{
fprintf(stderr, "Statistics? What statistics?\n");
}
\f
struct ggc_pch_data *
init_ggc_pch ()
{
sorry ("Generating PCH files is not supported when using ggc-placeholder.c");
return NULL;
}
void
ggc_pch_count_object (d, x, size)
struct ggc_pch_data *d ATTRIBUTE_UNUSED;
void *x ATTRIBUTE_UNUSED;
size_t size ATTRIBUTE_UNUSED;
{
}
size_t
ggc_pch_total_size (d)
struct ggc_pch_data *d ATTRIBUTE_UNUSED;
{
return 0;
}
void
ggc_pch_this_base (d, base)
struct ggc_pch_data *d ATTRIBUTE_UNUSED;
void *base ATTRIBUTE_UNUSED;
{
}
char *
ggc_pch_alloc_object (d, x, size)
struct ggc_pch_data *d ATTRIBUTE_UNUSED;
void *x ATTRIBUTE_UNUSED;
size_t size ATTRIBUTE_UNUSED;
{
return NULL;
}
void
ggc_pch_prepare_write (d, f)
struct ggc_pch_data * d ATTRIBUTE_UNUSED;
FILE * f ATTRIBUTE_UNUSED;
{
}
void
ggc_pch_write_object (d, f, x, newx, size)
struct ggc_pch_data * d ATTRIBUTE_UNUSED;
FILE *f ATTRIBUTE_UNUSED;
void *x ATTRIBUTE_UNUSED;
void *newx ATTRIBUTE_UNUSED;
size_t size ATTRIBUTE_UNUSED;
{
}
void
ggc_pch_finish (d, f)
struct ggc_pch_data * d ATTRIBUTE_UNUSED;
FILE *f ATTRIBUTE_UNUSED;
{
}
void
ggc_pch_read (f, addr)
FILE *f ATTRIBUTE_UNUSED;
void *addr ATTRIBUTE_UNUSED;
{
/* This should be impossible, since we won't generate any valid PCH
files for this configuration. */
abort ();
}
/* Dummy stuff for pfe */
void pfe_freeze_thaw_ggc(void* p) ;
void check_struct_page_entry(int n) ;
void check_struct_page_group(int n) ;
void check_struct_page_table_chain(int n) ;
void check_struct_globals(int n) ;
void pfe_freeze_thaw_ggc(void* p ATTRIBUTE_UNUSED) { }
void check_struct_page_entry(int n ATTRIBUTE_UNUSED) { }
void check_struct_page_group(int n ATTRIBUTE_UNUSED) { }
void check_struct_page_table_chain(int n ATTRIBUTE_UNUSED) { }
void check_struct_globals(int n ATTRIBUTE_UNUSED) { }
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-04 20:17 ` Tim Josling
@ 2003-02-04 20:47 ` Matt Austern
2003-02-06 19:26 ` Tim Josling
0 siblings, 1 reply; 115+ messages in thread
From: Matt Austern @ 2003-02-04 20:47 UTC (permalink / raw)
To: Tim Josling; +Cc: Devang Patel, gcc, To, be, precise, geoffk
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
On Tuesday, February 4, 2003, at 12:11 PM, Tim Josling wrote:
> Matt,
>
> Any chance I could get a copy of your c++ source and/or your minimal
> non-gc
> implementation so I can see what is under the discrepancy?
My placeholder "collector" is attached. Note that you can't use
it with PCH; doing a PCH experiment might be interesting too,
but it would be harder. I also made the obvious changes in the
configure script and makefile to accept --with-gc=placeholder.
As you can see, I'm doing things in the maximally simpleminded
way.
[-- Attachment #2: ggc-placeholder.c --]
[-- Type: text/plain, Size: 4236 bytes --]
#include "config.h"
#include "system.h"
#include "rtl.h"
#include "tree.h"
#include "tm_p.h"
#include "flags.h"
#include "varray.h"
#include "ggc.h"
#include "toplev.h"
#include "params.h"
#include <unistd.h>
#include <assert.h>
#include <sys/mman.h>
/* Alloc SIZE bytes of GC'able memory. */
static const int chunksize = 0x100000; /* 1MB */
static char* chunk_begin = 0;
static int chunk_remaining = 0;
static void get_chunk()
{
char* pref = 0;
if (chunk_begin)
pref = chunk_begin + chunk_remaining;
chunk_begin = mmap(pref, chunksize, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANON, -1, 0);
chunk_remaining = chunksize;
if (!chunk_begin || chunk_begin == (char*) MAP_FAILED)
{
fprintf(stderr, "Placeholder mmap failed\n");
abort();
}
int adj = (unsigned long) chunk_begin & 3;
if (adj != 0)
{
chunk_begin += 4 - adj;
chunk_remaining -= 4 - adj;
}
}
void *
ggc_alloc (size)
size_t size;
{
int adj, adj2;
/* request should fit on a 4-byte boundary */
adj = size & 3;
if (adj)
size += 4 - adj;
adj2 = ((unsigned long) chunk_begin & 8) == 4 ? 4 : 8;
if (size + adj2 > chunk_remaining)
{
assert(size + 16 < chunksize);
get_chunk();
adj2 = ((unsigned long) chunk_begin & 8) == 4 ? 4 : 8;
}
char* p = chunk_begin;
chunk_begin += size + adj2;
chunk_remaining -= size + adj2;
char* user_area = p + adj2;
int* size_area = (int*) (user_area - 4);
*size_area = size;
return user_area;
}
int
ggc_set_mark (p)
const void *p;
{
}
/* Return 1 if P has been marked, zero otherwise. */
int
ggc_marked_p (p)
const void *p;
{
return 1;
}
/* Return the size of the gc-able object P. */
size_t
ggc_get_size (p)
const void *p;
{
int* size_area = (int*) ((char*) p - 4);
return *size_area;
}
/* A placeholder collection routine */
void
ggc_collect ()
{
}
/* Called once to initialize the garbage collector. */
void
init_ggc ()
{
}
/* Start a new GGC context. Memory allocated in previous contexts
will not be collected while the new context is active. */
void
ggc_push_context ()
{
}
/* Finish a GC context. Any uncollected memory in the new context
will be merged with the old context. */
void
ggc_pop_context ()
{
}
/* Report on GC memory usage. */
void
ggc_print_statistics ()
{
fprintf(stderr, "Statistics? What statistics?\n");
}
\f
struct ggc_pch_data *
init_ggc_pch ()
{
sorry ("Generating PCH files is not supported when using ggc-placeholder.c");
return NULL;
}
void
ggc_pch_count_object (d, x, size)
struct ggc_pch_data *d ATTRIBUTE_UNUSED;
void *x ATTRIBUTE_UNUSED;
size_t size ATTRIBUTE_UNUSED;
{
}
size_t
ggc_pch_total_size (d)
struct ggc_pch_data *d ATTRIBUTE_UNUSED;
{
return 0;
}
void
ggc_pch_this_base (d, base)
struct ggc_pch_data *d ATTRIBUTE_UNUSED;
void *base ATTRIBUTE_UNUSED;
{
}
char *
ggc_pch_alloc_object (d, x, size)
struct ggc_pch_data *d ATTRIBUTE_UNUSED;
void *x ATTRIBUTE_UNUSED;
size_t size ATTRIBUTE_UNUSED;
{
return NULL;
}
void
ggc_pch_prepare_write (d, f)
struct ggc_pch_data * d ATTRIBUTE_UNUSED;
FILE * f ATTRIBUTE_UNUSED;
{
}
void
ggc_pch_write_object (d, f, x, newx, size)
struct ggc_pch_data * d ATTRIBUTE_UNUSED;
FILE *f ATTRIBUTE_UNUSED;
void *x ATTRIBUTE_UNUSED;
void *newx ATTRIBUTE_UNUSED;
size_t size ATTRIBUTE_UNUSED;
{
}
void
ggc_pch_finish (d, f)
struct ggc_pch_data * d ATTRIBUTE_UNUSED;
FILE *f ATTRIBUTE_UNUSED;
{
}
void
ggc_pch_read (f, addr)
FILE *f ATTRIBUTE_UNUSED;
void *addr ATTRIBUTE_UNUSED;
{
/* This should be impossible, since we won't generate any valid PCH
files for this configuration. */
abort ();
}
/* Dummy stuff for pfe */
void pfe_freeze_thaw_ggc(void* p) { }
void check_struct_page_entry(int n) { }
void check_struct_page_group(int n) { }
void check_struct_page_table_chain(int n) { }
void check_struct_globals(int n) { }
[-- Attachment #3: Makefile.in --]
[-- Type: application/octet-stream, Size: 167852 bytes --]
# Makefile for GNU C compiler.
# Copyright (C) 1987, 1988, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997
# 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
#This file is part of GCC.
#GCC is free software; you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation; either version 2, or (at your option)
#any later version.
#GCC is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#GNU General Public License for more details.
#You should have received a copy of the GNU General Public License
#along with GCC; see the file COPYING. If not, write to
#the Free Software Foundation, 59 Temple Place - Suite 330,
#Boston MA 02111-1307, USA.
# The targets for external use include:
# all, doc, proto, install, install-cross, install-cross-rest,
# uninstall, TAGS, mostlyclean, clean, distclean, maintainer-clean,
# stage1, stage2, stage3, stage4.
# This is the default target.
all:
# Suppress smart makes who think they know how to automake Yacc files
.y.c:
# Directory where sources are, from where we are.
srcdir = @srcdir@
VPATH = @srcdir@
# Pointer to the GCC Project website
website=http://gcc.gnu.org
# These directories contain files that are provided as part of a FSF tarball,
# but not provided in CVS. Some GCC integrators like to use the CVS sources
# but keep them read-only during a build, and so change these variables
# from these defaults.
# BEGIN APPLE LOCAL parsedir
parsedir = .
docobjdir = .
# END APPLE LOCAL parsedir
# Variables that exist for you to override.
# See below for how to change them for certain systems.
# List of language subdirectories.
# This is overridden by configure.
SUBDIRS =@subdirs@
# Selection of languages to be made.
# This is overridden by configure.
CONFIG_LANGUAGES = @all_languages@
LANGUAGES = c gcov$(exeext) $(CONFIG_LANGUAGES)
# Selection of languages to be made during stage1 build.
# This is overridden by configure.
BOOT_LANGUAGES = c @all_boot_languages@
# Various ways of specifying flags for compilations:
# CFLAGS is for the user to override to, e.g., do a cross build with -O2.
# For recursive bootstrap builds CFLAGS is used to pass in STAGE1_CFLAGS
# or BOOT_CFLAGS
# STAGE1_CFLAGS is set by configure on some targets or passed from toplevel
# and sets the CFLAGS passed to stage1 of a bootstrap compilation.
# BOOT_CFLAGS is the value of CFLAGS to pass to the stage2, stage3 and stage4
# bootstrap compilations.
# XCFLAGS is used for most compilations but not when using the GCC just built.
# TCFLAGS is used for compilations with the GCC just built.
XCFLAGS =
TCFLAGS =
CFLAGS = -g
STAGE1_CFLAGS = -g @stage1_cflags@
BOOT_CFLAGS = -g -O2
# Flags to determine code coverage. When coverage is disabled, this will
# contain the optimization flags, as you normally want code coverage
# without optimization. The -dumpbase $@ makes sure that the auxilary
# files end up near the object files.
COVERAGE_FLAGS = @coverage_flags@
coverageexts = .{da,bb,bbg}
# The warning flags are separate from BOOT_CFLAGS because people tend to
# override optimization flags and we'd like them to still have warnings
# turned on. These flags are also used to pass other stage dependent
# flags from configure. The user is free to explicitly turn these flags
# off if they wish.
# LOOSE_WARN are the warning flags to use when compiling something
# which is only compiled with gcc, such as libgcc and the frontends
# other than C.
# STRICT_WARN and STRICT2_WARN are the additional warning flags to
# apply to the back end and the C front end, which may be compiled
# with other compilers. This is partially controlled by configure in
# stage1, as not all versions of gcc understand -Wno-long-long.
LOOSE_WARN = -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
STRICT_WARN = -Wtraditional @strict1_warn@
STRICT2_WARN = -Wtraditional -pedantic -Wno-long-long
# This is set by --enable-checking. The idea is to catch forgotten
# "extern" tags in header files.
NOCOMMON_FLAG = @nocommon_flag@
# These are set by --enable-checking=valgrind.
RUN_GEN = @valgrind_command@
VALGRIND_DRIVER_DEFINES = @valgrind_path_defines@
# This is how we control whether or not the additional warnings are applied.
.-warn = $(STRICT_WARN)
GCC_WARN_CFLAGS = $(LOOSE_WARN) $($(@D)-warn) $(NOCOMMON_FLAG)
# All warnings have to be shut off in stage1 if the compiler used then
# isn't gcc; configure determines that. WARN_CFLAGS will be either
# $(GCC_WARN_CFLAGS), or nothing.
WARN_CFLAGS = @warn_cflags@
# These exists to be overridden by the x-* and t-* files, respectively.
# APPLE LOCAL cpp-precomp
X_CFLAGS = -no-cpp-precomp
T_CFLAGS =
X_CPPFLAGS =
T_CPPFLAGS =
ADAC = @ADAC@
AWK = @AWK@
CC = @CC@
BISON = @BISON@
BISONFLAGS =
FLEX = @FLEX@
FLEXFLAGS =
AR = ar
AR_FLAGS = rc
DLLTOOL = dlltool
RANLIB = @RANLIB@
SHELL = @SHELL@
# pwd command to use. Allow user to override default by setting PWDCMD in
# the environment to account for automounters. The make variable must not
# be called PWDCMD, otherwise the value set here is passed to make
# subprocesses and overrides the setting from the user's environment.
PWD = $${PWDCMD-pwd}
# on sysV, define this as cp.
INSTALL = @INSTALL@
# Some systems may be missing symbolic links, regular links, or both.
# Allow configure to check this and use "ln -s", "ln", or "cp" as appropriate.
LN=@LN@
LN_S=@LN_S@
# These permit overriding just for certain files.
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_SCRIPT = @INSTALL@
MAKEINFO = @MAKEINFO@
MAKEINFOFLAGS =
TEXI2DVI = texi2dvi
TEXI2POD = perl $(srcdir)/../contrib/texi2pod.pl
POD2MAN = pod2man --center="GNU" --release="gcc-$(version)"
# For GNUmake: let us decide what gets passed to recursive makes.
MAKEOVERRIDES =
@SET_MAKE@
# Some compilers can't handle cc -c blah.c -o foo/blah.o.
# In stage2 and beyond, we force this to "-o $@" since we know we're using gcc.
OUTPUT_OPTION = @OUTPUT_OPTION@
# Some versions of `touch' (such as the version on Solaris 2.8)
# do not correctly set the timestamp due to buggy versions of `utime'
# in the kernel. So, we use `echo' instead.
STAMP = echo timestamp >
# This is where we get zlib from. zlibdir is -L../zlib and zlibinc is
# -I../zlib, unless we were configured with --with-system-zlib, in which
# case both are empty.
ZLIB = @zlibdir@ -lz
ZLIBINC = @zlibinc@
# Substitution type for target's getgroups 2nd arg.
TARGET_GETGROUPS_T = @TARGET_GETGROUPS_T@
# Target to use when installing include directory. Either
# install-headers-tar, install-headers-cpio or install-headers-cp.
INSTALL_HEADERS_DIR = @build_install_headers_dir@
# Header files that are made available under the same name
# to programs compiled with GCC.
USER_H = $(srcdir)/ginclude/float.h \
$(srcdir)/ginclude/iso646.h \
$(srcdir)/ginclude/stdarg.h \
$(srcdir)/ginclude/stdbool.h \
$(srcdir)/ginclude/stddef.h \
$(srcdir)/ginclude/varargs.h \
$(EXTRA_HEADERS)
# The GCC to use for compiling libgcc.a and crt*.o.
# Usually the one we just built.
# Don't use this as a dependency--use $(GCC_PASSES) or $(GCC_PARTS).
GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include
# This is used instead of ALL_CFLAGS when compiling with GCC_FOR_TARGET.
# It omits XCFLAGS, and specifies -B./.
# It also specifies -isystem ./include to find, e.g., stddef.h.
GCC_CFLAGS=$(INTERNAL_CFLAGS) $(X_CFLAGS) $(T_CFLAGS) $(LOOSE_WARN) -isystem ./include $(TCFLAGS)
# Sed command to transform gcc to installed name. Overwritten by configure.
program_transform_name = @program_transform_name@
program_transform_cross_name = s,^,$(target_alias)-,
build_canonical = @build_canonical@
host_canonical = @host_canonical@
# Tools to use when building a cross-compiler.
# These are used because `configure' appends `cross-make'
# to the makefile when making a cross-compiler.
# Use the tools from the build tree, if they are available.
# objdir is set by configure.
objdir = @objdir@
AR_FOR_TARGET = ` \
if [ -f $(objdir)/../binutils/ar ] ; then \
echo $(objdir)/../binutils/ar ; \
else \
if [ "$(host_canonical)" = "$(target)" ] ; then \
echo ar; \
else \
t='$(program_transform_cross_name)'; echo ar | sed -e $$t ; \
fi; \
fi`
AR_FLAGS_FOR_TARGET =
AR_CREATE_FOR_TARGET = $(AR_FOR_TARGET) $(AR_FLAGS_FOR_TARGET) rc
AR_EXTRACT_FOR_TARGET = $(AR_FOR_TARGET) $(AR_FLAGS_FOR_TARGET) x
RANLIB_FOR_TARGET = ` \
if [ -f $(objdir)/../binutils/ranlib ] ; then \
echo $(objdir)/../binutils/ranlib ; \
else \
if [ "$(host_canonical)" = "$(target)" ] ; then \
echo $(RANLIB); \
else \
t='$(program_transform_cross_name)'; echo ranlib | sed -e $$t ; \
fi; \
fi`
NM_FOR_TARGET = ` \
if [ -f ./nm ] ; then \
echo ./nm ; \
elif [ -f $(objdir)/../binutils/nm-new ] ; then \
echo $(objdir)/../binutils/nm-new ; \
else \
if [ "$(host_canonical)" = "$(target)" ] ; then \
echo nm; \
else \
t='$(program_transform_cross_name)'; echo nm | sed -e $$t ; \
fi; \
fi`
# Where to find some libiberty headers.
HASHTAB_H = $(srcdir)/../include/hashtab.h
OBSTACK_H = $(srcdir)/../include/obstack.h
SPLAY_TREE_H= $(srcdir)/../include/splay-tree.h
FIBHEAP_H = $(srcdir)/../include/fibheap.h
# Default native SYSTEM_HEADER_DIR, to be overridden by targets.
NATIVE_SYSTEM_HEADER_DIR = /usr/include
# Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
CROSS_SYSTEM_HEADER_DIR = $(build_tooldir)/sys-include
# autoconf sets SYSTEM_HEADER_DIR to one of the above.
SYSTEM_HEADER_DIR = @SYSTEM_HEADER_DIR@
# Control whether to run fixproto and fixincludes.
STMP_FIXPROTO = @STMP_FIXPROTO@
STMP_FIXINC = @STMP_FIXINC@
# Test to see whether <limits.h> exists in the system header files.
LIMITS_H_TEST = [ -f $(SYSTEM_HEADER_DIR)/limits.h ]
target=@target@
target_alias=@target_alias@
xmake_file=@dep_host_xmake_file@
tmake_file=@dep_tmake_file@
out_file=$(srcdir)/config/@out_file@
out_object_file=@out_object_file@
md_file=$(srcdir)/config/@md_file@
tm_defines=@tm_defines@
tm_p_file_list=@tm_p_file_list@
tm_p_file=@tm_p_file@
build_xm_file_list=@build_xm_file_list@
build_xm_file=@build_xm_file@
build_xm_defines=@build_xm_defines@
host_xm_file_list=@host_xm_file_list@
host_xm_file=@host_xm_file@
host_xm_defines=@host_xm_defines@
xm_file=@xm_file@
xm_defines=@xm_defines@
lang_specs_files=@lang_specs_files@
lang_options_files=@lang_options_files@
lang_tree_files=@lang_tree_files@
target_cpu_default=@target_cpu_default@
GCC_THREAD_FILE=@thread_file@
OBJC_BOEHM_GC=@objc_boehm_gc@
GTHREAD_FLAGS=@gthread_flags@
# Be prepared for gcc2 merges.
gcc_version=@gcc_version@
gcc_version_trigger=@gcc_version_trigger@
version=$(gcc_version)
mainversion=`grep version_string $(srcdir)/version.c | sed -e 's/.*\"\([0-9]*\.[0-9]*\).*/\1/'`
# Common prefix for installation directories.
# NOTE: This directory must exist when you start installation.
prefix = @prefix@
# Directory in which to put localized header files. On the systems with
# gcc as the native cc, `local_prefix' may not be `prefix' which is
# `/usr'.
# NOTE: local_prefix *should not* default from prefix.
local_prefix = @local_prefix@
# Directory in which to put host dependent programs and libraries
exec_prefix = @exec_prefix@
# Directory in which to put the executable for the command `gcc'
bindir = @bindir@
# Directory in which to put the directories used by the compiler.
libdir = @libdir@
# Directory in which the compiler finds executables, libraries, etc.
libsubdir = $(libdir)/gcc-lib/$(target_alias)/$(version)
# Used to produce a relative $(gcc_tooldir) in gcc.o
unlibsubdir = ../../..
# Directory in which to find other cross-compilation tools and headers.
dollar = @dollar@
# Used in install-cross.
gcc_tooldir = @gcc_tooldir@
# Used to install the shared libgcc.
slibdir = @slibdir@
# Since gcc_tooldir does not exist at build-time, use -B$(build_tooldir)/bin/
build_tooldir = $(exec_prefix)/$(target_alias)
# Directory in which the compiler finds target-independent g++ includes.
gcc_gxx_include_dir = @gcc_gxx_include_dir@
# Directory to search for site-specific includes.
local_includedir = $(local_prefix)/include
includedir = $(prefix)/include
# where the info files go
infodir = @infodir@
# Where cpp should go besides $prefix/bin if necessary
cpp_install_dir = @cpp_install_dir@
# where the locale files go
datadir = @datadir@
localedir = $(datadir)/locale
# Extension (if any) to put in installed man-page filename.
man1ext = .1
man7ext = .7
objext = .o
exeext = @host_exeext@
build_exeext = @build_exeext@
# Directory in which to put man pages.
mandir = @mandir@
man1dir = $(mandir)/man1
man7dir = $(mandir)/man7
# Dir for temp files.
tmpdir = /tmp
# Top build directory, relative to here.
top_builddir = .
# Whether we were configured with NLS.
USE_NLS = @USE_NLS@
# Internationalization library.
INTLLIBS = @INTLLIBS@
INTLDEPS = @INTLDEPS@
# Character encoding conversion library.
LIBICONV = @LIBICONV@
# List of internationalization subdirectories.
INTL_SUBDIRS = intl
# The GC method to be used on this system.
GGC=@GGC@.o
# If a supplementary library is being used for the GC.
GGC_LIB=
# libgcc.a may be built directly or via stmp-multilib,
# and installed likewise. Overridden by t-fragment.
LIBGCC = libgcc.a
INSTALL_LIBGCC = install-libgcc
# Options to use when compiling libgcc2.a.
#
LIBGCC2_DEBUG_CFLAGS = -g
# APPLE LOCAL control opt level. ilr
LIBGCC2_CFLAGS = $(LIBGCC2_OPT) $(LIBGCC2_INCLUDES) $(GCC_CFLAGS) $(TARGET_LIBGCC2_CFLAGS) $(LIBGCC2_DEBUG_CFLAGS) $(GTHREAD_FLAGS) -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED @inhibit_libc@
# Additional options to use when compiling libgcc2.a.
# Some targets override this to -isystem include
LIBGCC2_INCLUDES =
# APPLE LOCAL control opt level. ilr
LIBGCC2_OPT = -O2
# Additional target-dependent options for compiling libgcc2.a.
TARGET_LIBGCC2_CFLAGS =
# Options to use when compiling crtbegin/end.
CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \
-finhibit-size-directive -fno-inline-functions -fno-exceptions \
-fno-zero-initialized-in-bss
# Additional sources to handle exceptions; overridden on ia64.
LIB2ADDEH = $(srcdir)/unwind-dw2.c $(srcdir)/unwind-dw2-fde.c \
$(srcdir)/unwind-sjlj.c
LIB2ADDEHDEP = unwind.inc unwind-dw2-fde.h
# nm flags to list global symbols in libgcc object files.
SHLIB_NM_FLAGS = -pg
# List of extra executables that should be compiled for this target machine
# that are used for compiling from source code to object code.
# The rules for compiling them should be in the t-* file for the machine.
EXTRA_PASSES =@extra_passes@
# Like EXTRA_PASSES, but these are used when linking.
EXTRA_PROGRAMS = @extra_programs@
# List of extra object files that should be compiled for this target machine.
# The rules for compiling them should be in the t-* file for the machine.
EXTRA_PARTS = @extra_parts@
# List of extra object files that should be compiled and linked with
# compiler proper (cc1, cc1obj, cc1plus).
EXTRA_OBJS = @extra_objs@
# List of extra object files that should be compiled and linked with
# the gcc driver.
EXTRA_GCC_OBJS =@host_extra_gcc_objs@
# List of additional header files to install.
# Often this is edited directly by `configure'.
EXTRA_HEADERS =@extra_headers_list@
# It is convenient for configure to add the assignment at the beginning,
# so don't override it here.
# APPLE LOCAL: darwin native
# The above comment doesn't make any sense, and the next line means that
# use_collect2=no in config.gcc has no effect. -sts 1/2001
#USE_COLLECT2 = collect2$(exeext)
# List of extra C and assembler files to add to static and shared libgcc2.
# Assembler files should have names ending in `.asm'.
LIB2FUNCS_EXTRA =
# List of extra C and assembler files to add to static libgcc2.
# Assembler files should have names ending in `.asm'.
LIB2FUNCS_STATIC_EXTRA =
# Program to convert libraries.
LIBCONVERT =
# Control whether header files are installed.
INSTALL_HEADERS=install-headers install-mkheaders
# Control whether Info documentation is built and installed.
BUILD_INFO = @BUILD_INFO@
# Control whether manpages generated by texi2pod.pl can be rebuilt.
GENERATED_MANPAGES = @GENERATED_MANPAGES@
# Additional directories of header files to run fixincludes on.
# These should be directories searched automatically by default
# just as /usr/include is.
# *Do not* use this for directories that happen to contain
# header files, but are not searched automatically by default.
# On most systems, this is empty.
OTHER_FIXINCLUDES_DIRS=
# A list of all the language-specific executables.
# This is overridden by configure.
COMPILERS = cc1$(exeext) @all_compilers@
# List of things which should already be built whenever we try to use xgcc
# to compile anything (without linking).
GCC_PASSES=xgcc$(exeext) cc1$(exeext) specs $(EXTRA_PASSES)
# List of things which should already be built whenever we try to use xgcc
# to link anything.
GCC_PARTS=$(GCC_PASSES) $(LIBGCC) $(EXTRA_PROGRAMS) $(USE_COLLECT2) $(EXTRA_PARTS)
# Directory to link to, when using the target `maketest'.
DIR = ../gcc
# Flags to use when cross-building GCC.
# Prefix to apply to names of object files when using them
# to run on the machine we are compiling on.
BUILD_PREFIX = @BUILD_PREFIX@
# Prefix to apply to names of object files when compiling them
# to run on the machine we are compiling on.
# The default for this variable is chosen to keep these rules
# out of the way of the other rules for compiling the same source files.
BUILD_PREFIX_1 = @BUILD_PREFIX_1@
# Native compiler for the build machine and its switches.
HOST_CC = @HOST_CC@
HOST_CFLAGS= @HOST_CFLAGS@ -DGENERATOR_FILE
# Native linker and preprocessor flags. For x-fragment overrides.
HOST_LDFLAGS=$(LDFLAGS)
HOST_CPPFLAGS=$(ALL_CPPFLAGS)
# Actual name to use when installing a native compiler.
GCC_INSTALL_NAME = `echo gcc|sed '$(program_transform_name)'`
GCC_TARGET_INSTALL_NAME = $(target_alias)-`echo gcc|sed '$(program_transform_name)'`
CPP_INSTALL_NAME = `echo cpp|sed '$(program_transform_name)'`
PROTOIZE_INSTALL_NAME = `echo protoize|sed '$(program_transform_name)'`
UNPROTOIZE_INSTALL_NAME = `echo unprotoize|sed '$(program_transform_name)'`
GCOV_INSTALL_NAME = `echo gcov|sed '$(program_transform_name)'`
GCCBUG_INSTALL_NAME = `echo gccbug|sed '$(program_transform_name)'`
# Actual name to use when installing a cross-compiler.
GCC_CROSS_NAME = `echo gcc|sed '$(program_transform_cross_name)'`
CPP_CROSS_NAME = `echo cpp|sed '$(program_transform_cross_name)'`
PROTOIZE_CROSS_NAME = `echo protoize|sed '$(program_transform_cross_name)'`
UNPROTOIZE_CROSS_NAME = `echo unprotoize|sed '$(program_transform_cross_name)'`
# APPLE LOCAL begin PFE
PFE_MEM_OBJS = pfe/pfe-mem.o
PFE_MEM_H = $(PFE_DIR)/pfe-mem.h
PFE_OBJS = pfe/pfe.o pfe/pfe-header.o pfe/freeze-thaw.o pfe/pfedbg.o \
$(PFE_MEM_OBJS)
PFE_C_AND_OBJC_OBJS = pfe/c-common-freeze-thaw.o pfe/c-freeze-thaw.o
PFE_STUB_OBJS = pfe/stub-pfe.o
BUILD_PFE_STUB_OBJS = pfe/$(BUILD_PREFIX_1)stub-pfe.o
PFE_DIR = $(srcdir)/pfe
PFE_H = $(PFE_DIR)/pfe.h
PFE_HEADER_H = $(PFE_DIR)/pfe-header.h $(TREE_H) $(C_COMMON_H) function.h \
$(CPPLIB_H) hashtable.h cpphash.h $(RTL_BASE_H)
C_FREEZE_THAW_H = $(PFE_DIR)/c-freeze-thaw.h
ALL_PFE_OBJS = pfe/*$(objext)
PFE_INTERNAL_CFLAGS =
# APPLE LOCAL end PFE
# APPLE LOCAL begin order files ilr
# When configure --enable-build_gcc is specified then we know that the
# makefile was created as a result of using build_gcc. For such builds
# we want to use the order files in the order-files directory. The
# makefile will test ORDER_FILES. If it is not null then the appropriate
# order file is added to the cc1* link.
#ORDER_FILES = @enable_build_gcc@
### ORDER FILES ARE CURRENTLY DISABLED. TO ENABLE THEM REMOVE THE LINE ###
### BELOW AND UNCOMMENT THE LINE ABOVE. ###
ORDER_FILES =
ifeq ($(ORDER_FILES),yes)
CC1_ORDER_FLAGS = `if [ -f $(srcdir)/../order-files/cc1.order ]; then \
echo -sectorder __TEXT __text $(srcdir)/../order-files/cc1.order -e start ; fi`
else
CC1_ORDER_FLAGS =
endif
# APPLE LOCAL end order files ilr
# Set by autoconf to "all.internal" for a native build, or
# "all.cross" to build a cross compiler.
ALL = @ALL@
# Setup the testing framework, if you have one
EXPECT = `if [ -f $${rootme}/../expect/expect ] ; then \
echo $${rootme}/../expect/expect ; \
else echo expect ; fi`
RUNTEST = `if [ -f $${srcdir}/../dejagnu/runtest ] ; then \
echo $${srcdir}/../dejagnu/runtest ; \
else echo runtest; fi`
RUNTESTFLAGS =
# Extra symbols for fixproto to define when parsing headers.
FIXPROTO_DEFINES =
# Extra flags to use when compiling crt{begin,end}.o.
CRTSTUFF_T_CFLAGS =
# Extra flags to use when compiling [m]crt0.o.
CRT0STUFF_T_CFLAGS =
# "t" or nothing, for building multilibbed versions of, say, crtbegin.o.
T =
# Should T contain a `=', libgcc.mk will make T_TARGET, setting
# $(T_TARGET) to the name of the actual target filename.
T_TARGET =
T_TARGET : $(T_TARGET)
# End of variables for you to override.
# Definition of `all' is here so that new rules inserted by sed
# do not specify the default target.
# The real definition is under `all.internal' (for native compilers)
# or `all.cross' (for cross compilers).
all: all.indirect
# This tells GNU Make version 3 not to put all variables in the environment.
.NOEXPORT:
# GCONFIG_H lists the config files that the generator files depend on, while
# CONFIG_H lists the ones ordinary gcc files depend on, which includes
# several files generated by those generators.
GCONFIG_H = config.h $(host_xm_file_list)
HCONFIG_H = hconfig.h $(build_xm_file_list)
CONFIG_H = $(GCONFIG_H) insn-constants.h insn-flags.h
TCONFIG_H = tconfig.h $(xm_file_list)
TARGET_H = target.h
HOOKS_H = hooks.h
LANGHOOKS_DEF_H = langhooks-def.h $(HOOKS_H)
TARGET_DEF_H = target-def.h $(HOOKS_H)
TM_P_H = tm_p.h $(tm_p_file_list) tm-preds.h
MACHMODE_H = machmode.h machmode.def @extra_modes_file@
RTL_BASE_H = rtl.h rtl.def $(MACHMODE_H)
RTL_H = $(RTL_BASE_H) genrtl.h
PARAMS_H = params.h params.def
TREE_H = tree.h tree.def $(MACHMODE_H) tree-check.h version.h builtins.def \
location.h
BASIC_BLOCK_H = basic-block.h bitmap.h sbitmap.h varray.h
DEMANGLE_H = $(srcdir)/../include/demangle.h
RECOG_H = recog.h
EXPR_H = expr.h
OPTABS_H = optabs.h insn-codes.h
REGS_H = regs.h varray.h $(MACHMODE_H)
INTEGRATE_H = integrate.h varray.h
LOOP_H = loop.h varray.h bitmap.h
GCC_H = gcc.h version.h
# APPLE LOCAL PFE
GGC_H = ggc.h gtype-desc.h $(PFE_H)
TIMEVAR_H = timevar.h timevar.def
INSN_ATTR_H = insn-attr.h $(srcdir)/insn-addr.h $(srcdir)/varray.h
C_COMMON_H = c-common.h $(SPLAY_TREE_H) $(CPPLIB_H)
C_TREE_H = c-tree.h $(C_COMMON_H)
SYSTEM_H = system.h hwint.h $(srcdir)/../include/libiberty.h
PREDICT_H = predict.h predict.def
CPPLIB_H = cpplib.h line-map.h
# sed inserts variable overrides after the following line.
####target overrides
@target_overrides@
####host overrides
@host_overrides@
#\f
# Now figure out from those variables how to compile and link.
all.indirect: $(ALL)
# IN_GCC distinguishes between code compiled into GCC itself and other
# programs built during a bootstrap.
# autoconf inserts -DCROSS_COMPILE if we are building a cross compiler.
# APPLE LOCAL PFE
INTERNAL_CFLAGS = $(PFE_INTERNAL_CFLAGS) -DIN_GCC @CROSS@
# This is the variable actually used when we compile.
# If you change this line, you probably also need to change the definition
# of HOST_CFLAGS in build-make to match.
ALL_CFLAGS = $(X_CFLAGS) $(T_CFLAGS) \
$(CFLAGS) $(INTERNAL_CFLAGS) $(COVERAGE_FLAGS) $(WARN_CFLAGS) $(XCFLAGS) @DEFS@
# Likewise.
ALL_CPPFLAGS = $(CPPFLAGS) $(X_CPPFLAGS) $(T_CPPFLAGS)
# Build and host support libraries. FORBUILD is either
# .. or ../$(build_alias) depending on whether host != build.
LIBIBERTY = ../libiberty/libiberty.a
BUILD_LIBIBERTY = @FORBUILD@/libiberty/libiberty.a
# Dependencies on the intl and portability libraries.
LIBDEPS= $(INTLDEPS) $(LIBIBERTY)
# Likewise, for use in the tools that must run on this machine
# even if we are cross-building GCC.
HOST_LIBDEPS= $(BUILD_LIBIBERTY)
# How to link with both our special library facilities
# and the system's installed libraries.
LIBS = $(INTLLIBS) @LIBS@ $(LIBIBERTY)
# Any system libraries needed just for GNAT.
SYSLIBS = @GNAT_LIBEXC@
# Likewise, for use in the tools that must run on this machine
# even if we are cross-building GCC.
HOST_LIBS = $(BUILD_LIBIBERTY)
# APPLE LOCAL PFE
HOST_RTL = $(BUILD_PREFIX)rtl.o read-rtl.o $(BUILD_PREFIX)bitmap.o \
$(BUILD_PFE_STUB_OBJS) \
$(BUILD_PREFIX)ggc-none.o
HOST_SUPPORT = gensupport.o insn-conditions.o
HOST_EARLY_SUPPORT = gensupport.o dummy-conditions.o
HOST_PRINT = print-rtl1.o
HOST_ERRORS = $(BUILD_PREFIX)errors.o
HOST_VARRAY = $(BUILD_PREFIX)varray.o
# Specify the directories to be searched for header files.
# Both . and srcdir are used, in that order,
# so that *config.h will be found in the compilation
# subdirectory rather than in the source directory.
# -I$(@D) and -I$(srcdir)/$(@D) cause the subdirectory of the file
# currently being compiled, in both source trees, to be examined as well.
INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
-I$(srcdir)/config -I$(srcdir)/../include -I$(srcdir)/../more-hdrs
# Always use -I$(srcdir)/config when compiling.
.c.o:
$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
# This tells GNU make version 3 not to export all the variables
# defined in this file into the environment.
.NOEXPORT:
#\f
# Support for additional languages (other than c and objc).
# ??? objc can be supported this way too (leave for later).
# These next lines are overridden by configure.
LANG_MAKEFILES = @all_lang_makefiles@
LANG_STAGESTUFF = @all_stagestuff@
# Flags to pass to recursive makes.
# CC is set by configure. Hosts without symlinks need special handling
# because we need CC="stage1/xgcc -Bstage1/" to work in the language
# subdirectories.
# ??? The choices here will need some experimenting with.
ORDINARY_FLAGS_TO_PASS = \
"AR_FLAGS_FOR_TARGET=$(AR_FLAGS_FOR_TARGET)" \
"AR_CREATE_FOR_TARGET=$(AR_CREATE_FOR_TARGET)" \
"AR_EXTRACT_FOR_TARGET=$(AR_EXTRACT_FOR_TARGET)" \
"AR_FOR_TARGET=$(AR_FOR_TARGET)" \
"BISON=$(BISON)" \
"BISONFLAGS=$(BISONFLAGS)" \
"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
"GCC_FOR_TARGET=$(GCC_FOR_TARGET)" \
"LDFLAGS=$(LDFLAGS)" \
"FLEX=$(FLEX)" \
"FLEXFLAGS=$(FLEXFLAGS)" \
"LN=$(LN)" \
"LN_S=$(LN_S)" \
"MAKEINFO=$(MAKEINFO)" \
"MAKEINFOFLAGS=$(MAKEINFOFLAGS)" \
"MAKEOVERRIDES=" \
"RANLIB_FOR_TARGET=$(RANLIB_FOR_TARGET)" \
"SHELL=$(SHELL)" \
"exeext=$(exeext)" \
"build_exeext=$(build_exeext)" \
"objext=$(objext)" \
"exec_prefix=$(exec_prefix)" \
"prefix=$(prefix)" \
"local_prefix=$(local_prefix)" \
"gxx_include_dir=$(gcc_gxx_include_dir)" \
"build_tooldir=$(build_tooldir)" \
"gcc_tooldir=$(gcc_tooldir)" \
"bindir=$(bindir)" \
"libsubdir=$(libsubdir)" \
"datadir=$(datadir)" \
"localedir=$(localedir)"
FLAGS_TO_PASS = $(ORDINARY_FLAGS_TO_PASS) "CC=@cc_set_by_configure@" \
"STAGE_PREFIX=@stage_prefix_set_by_configure@"
PREPEND_DOTDOT_TO_RELATIVE_PATHS = sed \
-e 's|^ *[^ /][^ /]*/|%&|' \
-e 's| -B| -B%|g' \
-e 's|% *[^- /]|%&|g' \
-e 's|%% *|../|g' \
-e 's|%||g'
SUBDIR_FLAGS_TO_PASS = $(ORDINARY_FLAGS_TO_PASS) \
"CC=`echo @quoted_cc_set_by_configure@ | $(PREPEND_DOTDOT_TO_RELATIVE_PATHS)`" \
"STAGE_PREFIX=`echo @quoted_stage_prefix_set_by_configure@ | $(PREPEND_DOTDOT_TO_RELATIVE_PATHS)`"
#\f
# Lists of files for various purposes.
# Target specific, C specific object file
C_TARGET_OBJS=@c_target_objs@
# Target specific, C++ specific object file
CXX_TARGET_OBJS=@cxx_target_objs@
# Language-specific object files for C and Objective C.
# APPLE LOCAL debugging
# APPLE LOCAL PFE
# APPLE LOCAL indexing
C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o \
$(PFE_C_AND_OBJC_OBJS) $(PFE_OBJS) \
genindex.o \
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \
c-objc-common.o c-dump.o c-pch.o libcpp.a $(C_TARGET_OBJS)
# Language-specific object files for C.
# APPLE LOCAL debugging
# APPLE LOCAL Objective-C++
C_OBJS = c-parse.o c-lang.o c-pretty-print.o $(C_AND_OBJC_OBJS) \
c-idebug.o stub-objc.o c-dmp-tree.o
# Language-independent object files.
# APPLE LOCAL new tree dump
OBJS = alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o \
dmp-tree.o \
cfg.o cfganal.o cfgbuild.o cfgcleanup.o cfglayout.o cfgloop.o \
cfgrtl.o combine.o conflict.o convert.o cse.o cselib.o dbxout.o \
debug.o df.o diagnostic.o doloop.o dominance.o \
dwarf2asm.o dwarf2out.o dwarfout.o emit-rtl.o except.o explow.o \
expmed.o expr.o final.o flow.o fold-const.o function.o gcse.o \
genrtl.o ggc-common.o global.o graph.o gtype-desc.o \
haifa-sched.o hashtable.o hooks.o ifcvt.o insn-attrtab.o insn-emit.o \
insn-extract.o insn-opinit.o insn-output.o insn-peep.o insn-recog.o \
integrate.o intl.o jump.o langhooks.o lcm.o lists.o local-alloc.o \
loop.o mbchar.o optabs.o params.o predict.o print-rtl.o print-tree.o \
profile.o ra.o ra-build.o ra-colorize.o ra-debug.o ra-rewrite.o \
real.o recog.o reg-stack.o regclass.o regmove.o regrename.o \
reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o rtl-error.o \
sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o \
sibcall.o simplify-rtx.o ssa.o ssa-ccp.o ssa-dce.o stmt.o \
stor-layout.o stringpool.o timevar.o toplev.o tracer.o tree.o tree-dump.o \
tree-inline.o unroll.o varasm.o varray.o version.o vmsdbgout.o xcoffout.o \
et-forest.o $(GGC) $(out_object_file) $(EXTRA_OBJS)
BACKEND = main.o libbackend.a
# Files to be copied away after each stage in building.
# APPLE LOCAL PFE
STAGESTUFF = *$(objext) insn-flags.h insn-config.h insn-codes.h \
$(ALL_PFE_OBJS) \
insn-output.c insn-recog.c insn-emit.c insn-extract.c insn-peep.c \
insn-attr.h insn-attrtab.c insn-opinit.c insn-constants.h tm-preds.h \
tree-check.h insn-conditions.c \
s-flags s-config s-codes s-mlib s-genrtl s-gtype gtyp-gen.h \
s-output s-recog s-emit s-extract s-peep s-check s-conditions \
s-attr s-attrtab s-opinit s-preds s-constants s-crt0 \
genemit$(build_exeext) genoutput$(build_exeext) genrecog$(build_exeext) \
genextract$(build_exeext) genflags$(build_exeext) gencodes$(build_exeext) \
genconfig$(build_exeext) genpeep$(build_exeext) genattrtab$(build_exeext) \
genattr$(build_exeext) genopinit$(build_exeext) gengenrtl$(build_exeext) \
gencheck$(build_exeext) genpreds$(build_exeext) genconstants$(build_exeext) \
gengtype$(build_exeext) genconditions$(build_exeext) \
genrtl.c genrtl.h gt-*.h gtype-*.h gtype-desc.c \
xgcc$(exeext) cpp$(exeext) cc1$(exeext) $(EXTRA_PASSES) \
$(EXTRA_PARTS) $(EXTRA_PROGRAMS) gcc-cross$(exeext) cc1obj$(exeext) \
protoize$(exeext) unprotoize$(exeext) \
specs collect2$(exeext) $(USE_COLLECT2) \
gcov$(exeext) *.[0-9][0-9].* *.[si] libcpp.a libbackend.a libgcc.mk \
$(LANG_STAGESTUFF)
# Library members defined in libgcc2.c.
# Variable length limited to 255 charactes when passed to a shell script.
LIB2FUNCS_1 = _muldi3 _negdi2 _lshrdi3 _ashldi3 _ashrdi3 _ffsdi2 _clz \
_cmpdi2 _ucmpdi2 _floatdidf _floatdisf _fixunsdfsi _fixunssfsi \
_fixunsdfdi _fixdfdi _fixunssfdi _fixsfdi _fixxfdi _fixunsxfdi
LIB2FUNCS_2 = _floatdixf _fixunsxfsi _fixtfdi _fixunstfdi _floatditf \
_clear_cache _trampoline __main _exit _absvsi2 _absvdi2 _addvsi3 \
_addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors
# Defined in libgcc2.c, included only in the static library.
LIB2FUNCS_ST = _eprintf _bb __gcc_bcmp
FPBIT_FUNCS = _pack_sf _unpack_sf _addsub_sf _mul_sf _div_sf \
_fpcmp_parts_sf _compare_sf _eq_sf _ne_sf _gt_sf _ge_sf \
_lt_sf _le_sf _unord_sf _si_to_sf _sf_to_si _negate_sf _make_sf \
_sf_to_df _thenan_sf _sf_to_usi _usi_to_sf
DPBIT_FUNCS = _pack_df _unpack_df _addsub_df _mul_df _div_df \
_fpcmp_parts_df _compare_df _eq_df _ne_df _gt_df _ge_df \
_lt_df _le_df _unord_df _si_to_df _df_to_si _negate_df _make_df \
_df_to_sf _thenan_df _df_to_usi _usi_to_df
# These might cause a divide overflow trap and so are compiled with
# unwinder info.
LIB2_DIVMOD_FUNCS = _divdi3 _moddi3 _udivdi3 _umoddi3 _udiv_w_sdiv _udivmoddi4
# The only suffixes we want for implicit rules are .c and .o, so clear
# the list and add them. This speeds up GNU Make, and allows -r to work.
# For i18n support, we also need .gmo, .po, .pox.
# This must come before the language makefile fragments to allow them to
# add suffixes and rules of their own.
.SUFFIXES:
.SUFFIXES: .c .o .po .pox .gmo
#\f
# Language makefile fragments.
# The following targets define the interface between us and the languages.
#
# all.cross, start.encap, rest.encap,
# info, dvi,
# install-normal, install-common, install-info, install-man,
# uninstall,
# mostlyclean, clean, distclean, extraclean, maintainer-clean,
# stage1, stage2, stage3, stage4
#
# Each language is linked in with a series of hooks (since we can't use `::'
# targets). The name of each hooked is "lang.${target_name}" (eg: lang.info).
# Configure computes and adds these here.
####language hooks
@language_hooks@
# sed inserts language fragments after the following line.
####language fragments
@language_fragments@
# End of language makefile fragments.
#\f
Makefile: $(srcdir)/Makefile.in config.status $(srcdir)/version.c \
$(xmake_file) $(tmake_file) $(LANG_MAKEFILES)
$(SHELL) $(srcdir)/configure.frag $(srcdir) "$(SUBDIRS)" \
"$(xmake_file)" "$(tmake_file)"
cp config.status config.run
LANGUAGES="$(CONFIG_LANGUAGES)" $(SHELL) config.run
rm -f config.run
config.h: cs-config.h ; @true
hconfig.h: cs-hconfig.h ; @true
tconfig.h: cs-tconfig.h ; @true
tm_p.h: cs-tm_p.h ; @true
cs-config.h: Makefile
TM_DEFINES="$(tm_defines)" \
HEADERS="$(host_xm_file)" XM_DEFINES="$(host_xm_defines)" \
TARGET_CPU_DEFAULT="$(target_cpu_default)" \
$(SHELL) $(srcdir)/mkconfig.sh config.h
cs-hconfig.h: Makefile
TM_DEFINES="$(tm_defines)" \
HEADERS="$(build_xm_file)" XM_DEFINES="$(build_xm_defines)" \
TARGET_CPU_DEFAULT="$(target_cpu_default)" \
$(SHELL) $(srcdir)/mkconfig.sh hconfig.h
cs-tconfig.h: Makefile
TM_DEFINES="$(tm_defines)" \
HEADERS="$(xm_file)" XM_DEFINES="$(xm_defines)" \
TARGET_CPU_DEFAULT="" \
$(SHELL) $(srcdir)/mkconfig.sh tconfig.h
cs-tm_p.h: Makefile
TM_DEFINES="" \
HEADERS="$(tm_p_file)" XM_DEFINES="" TARGET_CPU_DEFAULT="" \
$(SHELL) $(srcdir)/mkconfig.sh tm_p.h
# Don't automatically run autoconf, since configure.in might be accidentally
# newer than configure. Also, this writes into the source directory which
# might be on a read-only file system. If configured for maintainer mode
# then do allow autoconf to be run.
$(srcdir)/configure: @MAINT@ $(srcdir)/configure.in
(cd $(srcdir) && autoconf)
gccbug: $(srcdir)/gccbug.in
CONFIG_FILES=gccbug CONFIG_HEADERS= ./config.status
mklibgcc: $(srcdir)/mklibgcc.in
CONFIG_FILES=mklibgcc CONFIG_HEADERS= ./config.status
mkheaders: $(srcdir)/mkheaders.in
CONFIG_FILES=mkheaders CONFIG_HEADERS= ./config.status
# cstamp-h.in controls rebuilding of config.in.
# It is named cstamp-h.in and not stamp-h.in so the mostlyclean rule doesn't
# delete it. A stamp file is needed as autoheader won't update the file if
# nothing has changed.
# It remains in the source directory and is part of the distribution.
# This follows what is done in shellutils, fileutils, etc.
# "echo timestamp" is used instead of touch to be consistent with other
# packages that use autoconf (??? perhaps also to avoid problems with patch?).
# ??? Newer versions have a maintainer mode that may be useful here.
# Don't run autoheader automatically either.
# Only run it if maintainer mode is enabled.
@MAINT@ $(srcdir)/config.in: $(srcdir)/cstamp-h.in
@MAINT@ $(srcdir)/cstamp-h.in: $(srcdir)/configure.in $(srcdir)/acconfig.h
@MAINT@ (cd $(srcdir) && autoheader)
@MAINT@ @rm -f $(srcdir)/cstamp-h.in
@MAINT@ echo timestamp > $(srcdir)/cstamp-h.in
auto-host.h: cstamp-h ; @true
cstamp-h: config.in config.status
CONFIG_HEADERS=auto-host.h:config.in LANGUAGES="$(CONFIG_LANGUAGES)" $(SHELL) config.status
# Really, really stupid make features, such as SUN's KEEP_STATE, may force
# a target to build even if it is up-to-date. So we must verify that
# config.status does not exist before failing.
config.status: $(srcdir)/configure $(srcdir)/config.gcc version.c
@if [ ! -f config.status ] ; then \
echo You must configure gcc. Look at http://gcc.gnu.org/install/ for details.; \
false; \
else \
LANGUAGES="$(CONFIG_LANGUAGES)" $(SHELL) config.status --recheck; \
fi
all.internal: start.encap rest.encap doc
# This is what to compile if making a cross-compiler.
all.cross: native gcc-cross cpp$(exeext) specs \
$(LIBGCC) $(EXTRA_PARTS) lang.all.cross doc
# This is what must be made before installing GCC and converting libraries.
start.encap: native xgcc$(exeext) cpp$(exeext) specs \
xlimits.h lang.start.encap
# These can't be made until after GCC can run.
rest.encap: $(STMP_FIXPROTO) $(LIBGCC) $(EXTRA_PARTS) lang.rest.encap
# This is what is made with the host's compiler
# whether making a cross compiler or not.
native: config.status auto-host.h intl.all build-@POSUB@ $(LANGUAGES) \
$(EXTRA_PASSES) $(EXTRA_PROGRAMS) $(USE_COLLECT2)
# Define the names for selecting languages in LANGUAGES.
C c: cc1$(exeext)
PROTO: proto
# Tell GNU make these are phony targets.
.PHONY: C c PROTO proto
# On the target machine, finish building a cross compiler.
# This does the things that can't be done on the host machine.
rest.cross: $(LIBGCC) specs
# Recompile all the language-independent object files.
# This is used only if the user explicitly asks for it.
compilations: $(BACKEND)
# Like libcpp.a, this archive is strictly for the host.
libbackend.a: $(OBJS)
-rm -rf libbackend.a
$(AR) $(AR_FLAGS) libbackend.a $(OBJS)
-$(RANLIB) libbackend.a
# We call this executable `xgcc' rather than `gcc'
# to avoid confusion if the current directory is in the path
# and CC is `gcc'. It is renamed to `gcc' when it is installed.
xgcc$(exeext): gcc.o gccspec.o version.o intl.o prefix.o \
version.o $(LIBDEPS) $(EXTRA_GCC_OBJS)
$(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ gcc.o gccspec.o intl.o \
prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS)
# cpp is to cpp0 as gcc is to cc1.
# The only difference from xgcc is that it's linked with cppspec.o
# instead of gccspec.o.
cpp$(exeext): gcc.o cppspec.o version.o intl.o prefix.o \
version.o $(LIBDEPS) $(EXTRA_GCC_OBJS)
$(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ gcc.o cppspec.o intl.o \
prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS)
# Dump a specs file to make -B./ read these specs over installed ones.
specs: xgcc$(exeext)
$(GCC_FOR_TARGET) -dumpspecs > tmp-specs
mv tmp-specs specs
# We do want to create an executable named `xgcc', so we can use it to
# compile libgcc2.a.
# Also create gcc-cross, so that install-common will install properly.
gcc-cross: xgcc$(exeext)
cp xgcc$(exeext) gcc-cross$(exeext)
# APPLE LOCAL order files ilr
cc1$(exeext): $(C_OBJS) $(BACKEND) $(LIBDEPS)
$(CC) $(ALL_CFLAGS) $(LDFLAGS) -o cc1$(exeext) \
$(C_OBJS) $(BACKEND) $(LIBS) $(CC1_ORDER_FLAGS)
# Build the version of limits.h that we will install.
xlimits.h: glimits.h limitx.h limity.h
if $(LIMITS_H_TEST) ; then \
cat $(srcdir)/limitx.h $(srcdir)/glimits.h $(srcdir)/limity.h > tmp-xlimits.h; \
else \
cat $(srcdir)/glimits.h > tmp-xlimits.h; \
fi
mv tmp-xlimits.h xlimits.h
#\f
# Build libgcc.a.
LIB2ADD = $(LIB2FUNCS_EXTRA)
LIB2ADD_ST = $(LIB2FUNCS_STATIC_EXTRA)
# /* APPLE LOCAL begin libcc_kext */
LIBK_FUNCS = $(LIBKFUNCS_DARWIN)
LIBK_SUPCXX_FUNCS = $(LIBK_SUPCXX_DARWIN)
libgcc.mk: config.status Makefile mklibgcc $(LIB2ADD) $(LIB2ADD_ST) xgcc$(exeext) specs
objext='$(objext)' \
LIB1ASMFUNCS='$(LIB1ASMFUNCS)' \
LIB2FUNCS_1='$(LIB2FUNCS_1)' \
LIB2FUNCS_2='$(LIB2FUNCS_2)' \
LIB2FUNCS_ST='$(LIB2FUNCS_ST)' \
LIB2ADD='$(LIB2ADD)' \
LIB2ADD_ST='$(LIB2ADD_ST)' \
LIB2ADDEH='$(LIB2ADDEH)' \
LIB2ADDEHDEP='$(LIB2ADDEHDEP)' \
LIBKFUNCS='$(LIBK_FUNCS)' \
LIBKSUPCXXFUNCS='$(LIBK_SUPCXX_FUNCS)' \
FPBIT='$(FPBIT)' \
FPBIT_FUNCS='$(FPBIT_FUNCS)' \
LIB2_DIVMOD_FUNCS='$(LIB2_DIVMOD_FUNCS)' \
DPBIT='$(DPBIT)' \
DPBIT_FUNCS='$(DPBIT_FUNCS)' \
MULTILIBS=`$(GCC_FOR_TARGET) --print-multi-lib` \
EXTRA_MULTILIB_PARTS='$(EXTRA_MULTILIB_PARTS)' \
SHLIB_LINK='$(SHLIB_LINK)' \
SHLIB_INSTALL='$(SHLIB_INSTALL)' \
SHLIB_EXT='$(SHLIB_EXT)' \
SHLIB_MULTILIB='$(SHLIB_MULTILIB)' \
SHLIB_MKMAP='$(SHLIB_MKMAP)' \
SHLIB_MKMAP_OPTS='$(SHLIB_MKMAP_OPTS)' \
SHLIB_MAPFILES='$(SHLIB_MAPFILES)' \
SHLIB_NM_FLAGS='$(SHLIB_NM_FLAGS)' \
MULTILIB_OSDIRNAMES='$(MULTILIB_OSDIRNAMES)' \
mkinstalldirs='$(SHELL) $(srcdir)/mkinstalldirs' \
$(SHELL) mklibgcc > tmp-libgcc.mk
mv tmp-libgcc.mk libgcc.mk
# /* APPLE LOCAL end libcc_kext */
# All the things that might cause us to want to recompile bits of libgcc.
LIBGCC_DEPS = $(GCC_PASSES) $(LANGUAGES) stmp-int-hdrs $(STMP_FIXPROTO) \
libgcc.mk $(srcdir)/libgcc2.c $(TCONFIG_H) \
$(MACHMODE_H) longlong.h gbl-ctors.h config.status stmp-int-hdrs \
tsystem.h $(FPBIT) $(DPBIT) $(LIB2ADD) $(LIB2ADD_ST) $(LIB2ADDEH) \
$(LIB2ADDEHDEP) $(EXTRA_PARTS) $(srcdir)/config/$(LIB1ASMSRC)
libgcc.a: $(LIBGCC_DEPS)
$(MAKE) GCC_FOR_TARGET="$(GCC_FOR_TARGET)" \
BUILD_PREFIX="$(BUILD_PREFIX)" BUILD_PREFIX_1="$(BUILD_PREFIX_1)" \
AR_FOR_TARGET="$(AR_FOR_TARGET)" \
AR_CREATE_FOR_TARGET="$(AR_CREATE_FOR_TARGET)" \
AR_FLAGS_FOR_TARGET="$(AR_FLAGS_FOR_TARGET)" \
CFLAGS="$(CFLAGS) $(WARN_CFLAGS)" \
RANLIB_FOR_TARGET="$(RANLIB_FOR_TARGET)" \
NM_FOR_TARGET="$(NM_FOR_TARGET)" AWK="$(AWK)" \
LIBGCC2_CFLAGS="$(LIBGCC2_CFLAGS)" \
INCLUDES="$(INCLUDES)" \
CONFIG_H="$(TCONFIG_H)" MACHMODE_H="$(MACHMODE_H)" \
LIB1ASMSRC='$(LIB1ASMSRC)' \
MAKEOVERRIDES= \
-f libgcc.mk all
# /* APPLE LOCAL begin libcc_kext */
LIBCC_KEXT_DEPS = $(GCC_PASSES) $(LANGUAGES) stmp-int-hdrs $(STMP_FIXPROTO) \
libgcc.mk $(srcdir)/libgcc2.c $(FPBIT) $(DPBIT) $(TCONFIG_H) \
$(MACHMODE_H) longlong.h config.status stmp-int-hdrs \
tsystem.h $(srcdir)/config/$(LIB1ASMSRC)
# same invocation as libgcc.a above
libcc_kext.a: $(LIBCC_KEXT_DEPS)
$(MAKE) GCC_FOR_TARGET="$(GCC_FOR_TARGET)" \
HOST_PREFIX="$(HOST_PREFIX)" HOST_PREFIX_1="$(HOST_PREFIX_1)" \
AR_FOR_TARGET="$(AR_FOR_TARGET)" \
AR_CREATE_FOR_TARGET="$(AR_CREATE_FOR_TARGET)" \
AR_FLAGS_FOR_TARGET="$(AR_FLAGS_FOR_TARGET)" \
CFLAGS="$(CFLAGS) $(WARN_CFLAGS)" \
RANLIB_FOR_TARGET="$(RANLIB_FOR_TARGET)" \
NM_FOR_TARGET="$(NM_FOR_TARGET)" AWK="$(AWK)" \
LIBGCC2_CFLAGS="$(LIBGCC2_CFLAGS)" \
INCLUDES="$(INCLUDES)" \
CONFIG_H="$(TCONFIG_H)" MACHMODE_H="$(MACHMODE_H)" \
LIB1ASMSRC='$(LIB1ASMSRC)' \
MAKEOVERRIDES= \
-f libgcc.mk libcc_kext.a
# /* APPLE LOCAL end libcc_kext */
# Use the genmultilib shell script to generate the information the gcc
# driver program needs to select the library directory based on the
# switches.
multilib.h: s-mlib; @true
s-mlib: $(srcdir)/genmultilib Makefile
if test @enable_multilib@ = yes \
|| test -n "$(MULTILIB_OSDIRNAMES)"; then \
$(SHELL) $(srcdir)/genmultilib \
"$(MULTILIB_OPTIONS)" \
"$(MULTILIB_DIRNAMES)" \
"$(MULTILIB_MATCHES)" \
"$(MULTILIB_EXCEPTIONS)" \
"$(MULTILIB_EXTRA_OPTS)" \
"$(MULTILIB_EXCLUSIONS)" \
"$(MULTILIB_OSDIRNAMES)" \
"@enable_multilib@" \
> tmp-mlib.h; \
else \
$(SHELL) $(srcdir)/genmultilib '' '' '' '' '' '' '' no \
> tmp-mlib.h; \
fi
$(SHELL) $(srcdir)/move-if-change tmp-mlib.h multilib.h
$(STAMP) s-mlib
# Build multiple copies of libgcc.a, one for each target switch.
stmp-multilib: $(LIBGCC_DEPS)
$(MAKE) GCC_FOR_TARGET="$(GCC_FOR_TARGET)" \
BUILD_PREFIX="$(BUILD_PREFIX)" BUILD_PREFIX_1="$(BUILD_PREFIX_1)" \
AR_FOR_TARGET="$(AR_FOR_TARGET)" \
AR_CREATE_FOR_TARGET="$(AR_CREATE_FOR_TARGET)" \
AR_FLAGS_FOR_TARGET="$(AR_FLAGS_FOR_TARGET)" \
CFLAGS="$(CFLAGS) $(WARN_CFLAGS)" \
RANLIB_FOR_TARGET="$(RANLIB_FOR_TARGET)" \
NM_FOR_TARGET="$(NM_FOR_TARGET)" AWK="$(AWK)" \
LIBGCC2_CFLAGS="$(LIBGCC2_CFLAGS)" \
INCLUDES="$(INCLUDES)" \
CONFIG_H="$(CONFIG_H)" MACHMODE_H="$(MACHMODE_H)" \
LIB1ASMSRC='$(LIB1ASMSRC)' \
MAKEOVERRIDES= \
-f libgcc.mk all
$(STAMP) stmp-multilib
# Compile two additional files that are linked with every program
# linked using GCC on systems using COFF or ELF, for the sake of C++
# constructors.
$(T)crtbegin.o: crtstuff.c $(GCC_PASSES) $(TCONFIG_H) auto-host.h \
gbl-ctors.h stmp-int-hdrs tsystem.h
$(GCC_FOR_TARGET) $(CRTSTUFF_CFLAGS) $(CRTSTUFF_T_CFLAGS) \
@inhibit_libc@ -c $(srcdir)/crtstuff.c -DCRT_BEGIN \
-o $(T)crtbegin$(objext)
$(T)crtend.o: crtstuff.c $(GCC_PASSES) $(TCONFIG_H) auto-host.h \
gbl-ctors.h stmp-int-hdrs tsystem.h
$(GCC_FOR_TARGET) $(CRTSTUFF_CFLAGS) $(CRTSTUFF_T_CFLAGS) \
@inhibit_libc@ -c $(srcdir)/crtstuff.c -DCRT_END \
-o $(T)crtend$(objext)
# These are versions of crtbegin and crtend for shared libraries.
$(T)crtbeginS.o: crtstuff.c $(GCC_PASSES) $(TCONFIG_H) auto-host.h \
gbl-ctors.h stmp-int-hdrs tsystem.h
$(GCC_FOR_TARGET) $(CRTSTUFF_CFLAGS) $(CRTSTUFF_T_CFLAGS_S) \
@inhibit_libc@ -c $(srcdir)/crtstuff.c -DCRT_BEGIN -DCRTSTUFFS_O \
-o $(T)crtbeginS$(objext)
$(T)crtendS.o: crtstuff.c $(GCC_PASSES) $(TCONFIG_H) auto-host.h \
gbl-ctors.h stmp-int-hdrs tsystem.h
$(GCC_FOR_TARGET) $(CRTSTUFF_CFLAGS) $(CRTSTUFF_T_CFLAGS_S) \
@inhibit_libc@ -c $(srcdir)/crtstuff.c -DCRT_END -DCRTSTUFFS_O \
-o $(T)crtendS$(objext)
# This is a version of crtbegin for -static links.
$(T)crtbeginT.o: crtstuff.c $(GCC_PASSES) $(TCONFIG_H) auto-host.h \
gbl-ctors.h stmp-int-hdrs tsystem.h
$(GCC_FOR_TARGET) $(CRTSTUFF_CFLAGS) $(CRTSTUFF_T_CFLAGS) \
@inhibit_libc@ -c $(srcdir)/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O \
-o $(T)crtbeginT$(objext)
# Compile the start modules crt0.o and mcrt0.o that are linked with
# every program
crt0.o: s-crt0 ; @true
mcrt0.o: s-crt0; @true
s-crt0: $(CRT0_S) $(MCRT0_S) $(GCC_PASSES) $(CONFIG_H)
$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(CRT0STUFF_T_CFLAGS) \
-o crt0.o -c $(CRT0_S)
$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(CRT0STUFF_T_CFLAGS) \
-o mcrt0.o -c $(MCRT0_S)
$(STAMP) s-crt0
#\f
# Compiling object files from source files.
# Note that dependencies on obstack.h are not written
# because that file is not part of GCC.
# C language specific files.
c-errors.o: c-errors.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(C_TREE_H) flags.h \
diagnostic.h $(TM_P_H)
c-parse.o : $(parsedir)/c-parse.c $(CONFIG_H) $(TREE_H) $(GGC_H) intl.h \
$(C_TREE_H) input.h flags.h $(SYSTEM_H) toplev.h output.h $(CPPLIB_H) \
varray.h gt-c-parse.h
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-c $(parsedir)/c-parse.c $(OUTPUT_OPTION)
# APPLE LOCAL Objective-C++
c-parse.o : langhooks.h
$(parsedir)/c-parse.c: $(parsedir)/c-parse.y
cd $(parsedir) && \
if $(BISON) $(BISONFLAGS) -o c-p$$$$.c c-parse.y; then \
test -f c-p$$$$.output && mv -f c-p$$$$.output c-parse.output ; \
mv -f c-p$$$$.c c-parse.c ; \
else \
rm -f c-p$$$$.* ; \
false ; \
fi
$(parsedir)/c-parse.y: c-parse.in
echo '/*WARNING: This file is automatically generated!*/' >tmp-c-parse.y
sed -e "/^ifobjc$$/,/^end ifobjc$$/d" \
-e "/^ifc$$/d" -e "/^end ifc$$/d" \
$(srcdir)/c-parse.in >>tmp-c-parse.y
$(SHELL) $(srcdir)/move-if-change tmp-c-parse.y $(parsedir)/c-parse.y
c-decl.o : c-decl.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(RTL_H) $(C_TREE_H) \
$(GGC_H) $(TARGET_H) flags.h function.h output.h $(EXPR_H) \
debug.h toplev.h intl.h $(TM_P_H) tree-inline.h $(TIMEVAR_H) c-pragma.h \
gt-c-decl.h
c-typeck.o : c-typeck.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(C_TREE_H) \
$(TARGET_H) flags.h intl.h output.h $(EXPR_H) $(RTL_H) toplev.h $(TM_P_H)
c-lang.o : c-lang.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(C_TREE_H) \
$(GGC_H) langhooks.h $(LANGHOOKS_DEF_H) c-common.h gtype-c.h
# APPLE LOCAL Objective-C++
stub-objc.o : stub-objc.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H)
c-lex.o : c-lex.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(RTL_H) \
debug.h $(C_TREE_H) c-common.h real.h \
c-pragma.h input.h intl.h flags.h toplev.h output.h \
mbchar.h $(CPPLIB_H) $(EXPR_H) $(TM_P_H)
c-objc-common.o : c-objc-common.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) \
$(C_TREE_H) $(RTL_H) insn-config.h integrate.h $(EXPR_H) $(C_TREE_H) \
flags.h toplev.h tree-inline.h diagnostic.h integrate.h $(VARRAY_H) \
langhooks.h $(GGC_H) gt-c-objc-common.h $(TARGET_H)
c-aux-info.o : c-aux-info.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(C_TREE_H) \
flags.h toplev.h
c-convert.o : c-convert.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) flags.h toplev.h \
$(C_COMMON_H)
c-pragma.o: c-pragma.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) function.h \
c-pragma.h toplev.h output.h $(GGC_H) $(TM_P_H) $(C_COMMON_H) gt-c-pragma.h
mbchar.o: mbchar.c $(CONFIG_H) $(SYSTEM_H) mbchar.h
graph.o: graph.c $(CONFIG_H) $(SYSTEM_H) toplev.h flags.h output.h $(RTL_H) \
function.h hard-reg-set.h $(BASIC_BLOCK_H) graph.h
sbitmap.o: sbitmap.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h hard-reg-set.h \
$(BASIC_BLOCK_H)
COLLECT2_OBJS = collect2.o tlink.o intl.o version.o
COLLECT2_LIBS = @COLLECT2_LIBS@
collect2$(exeext): $(COLLECT2_OBJS) $(LIBDEPS)
# Don't try modifying collect2 (aka ld) in place--it might be linking this.
$(CC) $(ALL_CFLAGS) $(LDFLAGS) -o T$@ \
$(COLLECT2_OBJS) $(LIBS) $(COLLECT2_LIBS)
mv -f T$@ $@
collect2.o : collect2.c $(CONFIG_H) $(SYSTEM_H) gstab.h intl.h \
$(OBSTACK_H) $(DEMANGLE_H) collect2.h version.h
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-DTARGET_MACHINE=\"$(target_alias)\" \
-c $(srcdir)/collect2.c $(OUTPUT_OPTION)
tlink.o: tlink.c $(DEMANGLE_H) $(HASHTAB_H) $(CONFIG_H) $(SYSTEM_H) \
$(OBSTACK_H) collect2.h intl.h
# A file used by all variants of C.
c-common.o : c-common.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(OBSTACK_H) \
$(C_COMMON_H) flags.h toplev.h output.h c-pragma.h $(RTL_H) $(GGC_H) \
$(EXPR_H) $(TM_P_H) builtin-types.def builtin-attrs.def $(TARGET_H) \
diagnostic.h except.h gt-c-common.h real.h langhooks.h varray.h
c-pretty-print.o : c-pretty-print.c c-pretty-print.h pretty-print.h \
$(C_COMMON_H) $(CONFIG_H) $(SYSTEM_H) real.h
c-opts.o : c-opts.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(C_COMMON_H) \
c-pragma.h flags.h toplev.h langhooks.h tree-inline.h diagnostic.h \
intl.h
# A file used by all variants of C and some other languages.
attribs.o : attribs.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) flags.h \
toplev.h output.h c-pragma.h $(RTL_H) $(GGC_H) $(EXPR_H) $(TM_P_H) \
builtin-types.def $(TARGET_H) langhooks.h
c-format.o : c-format.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) langhooks.h \
$(C_COMMON_H) flags.h toplev.h intl.h diagnostic.h
c-semantics.o : c-semantics.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(C_TREE_H) \
flags.h toplev.h output.h c-pragma.h $(RTL_H) $(GGC_H) \
$(EXPR_H) $(PREDICT_H)
c-dump.o : c-dump.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(C_TREE_H) tree-dump.h
c-pch.o : c-pch.c $(CONFIG_H) $(SYSTEM_H) $(CPPLIB_H) $(TREE_H) c-common.h \
output.h toplev.h c-pragma.h $(GGC_H) debug.h
# Language-independent files.
DRIVER_DEFINES = \
-DSTANDARD_STARTFILE_PREFIX=\"$(unlibsubdir)/\" \
-DSTANDARD_EXEC_PREFIX=\"$(libdir)/gcc-lib/\" \
-DDEFAULT_TARGET_VERSION=\"$(version)\" \
-DDEFAULT_TARGET_MACHINE=\"$(target_alias)\" \
-DSTANDARD_BINDIR_PREFIX=\"$(bindir)/\" \
-DTOOLDIR_BASE_PREFIX=\"$(unlibsubdir)/../\" \
$(VALGRIND_DRIVER_DEFINES) \
`test "X$${SHLIB_LINK}" = "X" || test "@enable_shared@" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` \
`test "X$${SHLIB_MULTILIB}" = "X" || echo "-DNO_SHARED_LIBGCC_MULTILIB"`
# APPLE LOCAL cpp-precomp
gcc.o: gcc.c $(CONFIG_H) $(SYSTEM_H) intl.h multilib.h cppdefault.h \
Makefile $(lang_specs_files) specs.h prefix.h $(GCC_H)
(SHLIB_LINK='$(SHLIB_LINK)' \
SHLIB_MULTILIB='$(SHLIB_MULTILIB)'; \
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
$(DRIVER_DEFINES) \
-c $(srcdir)/gcc.c $(OUTPUT_OPTION))
gccspec.o: gccspec.c $(CONFIG_H) $(SYSTEM_H) $(GCC_H)
(SHLIB_LINK='$(SHLIB_LINK)' \
SHLIB_MULTILIB='$(SHLIB_MULTILIB)'; \
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
$(DRIVER_DEFINES) \
-c $(srcdir)/gccspec.c $(OUTPUT_OPTION))
cppspec.o: cppspec.c $(CONFIG_H) $(SYSTEM_H) $(GCC_H)
tree-check.h: s-check ; @true
s-check : gencheck$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./gencheck$(build_exeext) > tmp-check.h
$(SHELL) $(srcdir)/move-if-change tmp-check.h tree-check.h
$(STAMP) s-check
gencheck$(build_exeext) : gencheck.o $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
gencheck.o $(HOST_LIBS)
gencheck.o : gencheck.c gencheck.h tree.def $(HCONFIG_H) $(SYSTEM_H) \
$(lang_tree_files)
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) \
$(srcdir)/gencheck.c $(OUTPUT_OPTION)
gencheck.h : s-gencheck ; @true
s-gencheck : Makefile
ltf="$(lang_tree_files)"; for f in $$ltf; do \
echo "#include \"$$f\""; \
done | sed 's|$(srcdir)/||' > tmp-gencheck.h
$(SHELL) $(srcdir)/move-if-change tmp-gencheck.h gencheck.h
$(STAMP) s-gencheck
options.h : s-options ; @true
s-options : Makefile
lof="$(lang_options_files)"; for f in $$lof; do \
echo "#include \"$$f\""; \
done | sed 's|$(srcdir)/||' > tmp-options.h
$(SHELL) $(srcdir)/move-if-change tmp-options.h options.h
$(STAMP) s-options
specs.h : s-specs ; @true
s-specs : Makefile
lsf="$(lang_specs_files)"; for f in $$lsf; do \
echo "#include \"$$f\""; \
done | sed 's|$(srcdir)/||' > tmp-specs.h
$(SHELL) $(srcdir)/move-if-change tmp-specs.h specs.h
$(STAMP) s-specs
dumpvers: dumpvers.c
version.o: version.c version.h
gtype-desc.o: gtype-desc.c $(CONFIG_H) $(SYSTEM_H) varray.h $(HASHTAB_H) \
$(TREE_H) $(RTL_H) function.h insn-config.h $(EXPR_H) $(OPTABS_H) \
libfuncs.h debug.h $(GGC_H) bitmap.h $(BASIC_BLOCK_H) hard-reg-set.h \
ssa.h cselib.h insn-addr.h
ggc-common.o: ggc-common.c $(CONFIG_H) $(SYSTEM_H) $(GGC_H) $(HASHTAB_H) \
toplev.h
ggc-simple.o: ggc-simple.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
$(GGC_H) varray.h $(TIMEVAR_H) $(TM_P_H) $(PARAMS_H)
ggc-placeholder.o: ggc-placeholder.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
$(GGC_H) varray.h $(TIMEVAR_H) $(TM_P_H) $(PARAMS_H)
ggc-page.o: ggc-page.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
toplev.h $(GGC_H) varray.h $(TIMEVAR_H) $(TM_P_H) $(PARAMS_H)
stringpool.o: stringpool.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(OBSTACK_H) \
$(GGC_H) gt-stringpool.h
hashtable.o: hashtable.c hashtable.h $(CONFIG_H) $(SYSTEM_H) $(OBSTACK_H)
line-map.o: line-map.c line-map.h intl.h $(CONFIG_H) $(SYSTEM_H)
ggc-none.o: ggc-none.c $(GCONFIG_H) $(SYSTEM_H) $(GGC_H)
$(CC) -c $(ALL_CFLAGS) -DGENERATOR_FILE $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
prefix.o: prefix.c $(CONFIG_H) $(SYSTEM_H) Makefile prefix.h
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-DPREFIX=\"$(prefix)\" \
-c $(srcdir)/prefix.c $(OUTPUT_OPTION)
convert.o: convert.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) flags.h convert.h \
toplev.h langhooks.h
langhooks.o : langhooks.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) toplev.h \
tree-inline.h $(RTL_H) insn-config.h integrate.h langhooks.h \
$(LANGHOOKS_DEF_H) flags.h
tree.o : tree.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) flags.h function.h toplev.h \
$(GGC_H) $(HASHTAB_H) $(TARGET_H) output.h $(TM_P_H) langhooks.h \
real.h gt-tree.h
tree-dump.o: tree-dump.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(C_TREE_H) \
flags.h langhooks.h toplev.h output.h c-pragma.h $(RTL_H) $(GGC_H) \
$(EXPR_H) $(SPLAY_TREE_H) tree-dump.h
tree-inline.o : tree-inline.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(RTL_H) \
expr.h flags.h params.h input.h insn-config.h $(INTEGRATE_H) \
$(VARRAY_H) $(HASHTAB_H) $(SPLAY_TREE_H) toplev.h langhooks.h \
$(C_COMMON_H) tree-inline.h
print-tree.o : print-tree.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(GGC_H) \
langhooks.h real.h
stor-layout.o : stor-layout.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) flags.h \
function.h $(EXPR_H) $(RTL_H) toplev.h $(GGC_H) $(TM_P_H) $(TARGET_H) \
langhooks.h
fold-const.o : fold-const.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) flags.h real.h \
toplev.h $(HASHTAB_H) $(EXPR_H) $(RTL_H) $(GGC_H) $(TM_P_H) langhooks.h
diagnostic.o : diagnostic.c diagnostic.h real.h diagnostic.def \
$(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(TM_P_H) flags.h $(GGC_H) \
input.h toplev.h intl.h langhooks.h $(LANGHOOKS_DEF_H)
toplev.o : toplev.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(RTL_H) function.h \
flags.h xcoffout.h input.h $(INSN_ATTR_H) output.h diagnostic.h \
debug.h insn-config.h intl.h $(RECOG_H) Makefile toplev.h \
dwarf2out.h sdbout.h dbxout.h $(EXPR_H) hard-reg-set.h $(BASIC_BLOCK_H) \
graph.h $(LOOP_H) except.h $(REGS_H) $(TIMEVAR_H) $(lang_options_files) \
ssa.h $(PARAMS_H) $(TM_P_H) reload.h dwarf2asm.h $(TARGET_H) \
langhooks.h insn-flags.h options.h cfglayout.h real.h
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-DTARGET_NAME=\"$(target_alias)\" \
-c $(srcdir)/toplev.c $(OUTPUT_OPTION)
main.o : main.c $(CONFIG_H) $(SYSTEM_H) toplev.h
rtl-error.o: rtl-error.c system.h $(RTL_H) $(INSN_ATTR_H) insn-config.h \
input.h toplev.h intl.h diagnostic.h $(CONFIG_H)
rtl.o : rtl.c $(GCONFIG_H) $(SYSTEM_H) $(RTL_H) real.h $(GGC_H) errors.h
$(CC) -c $(ALL_CFLAGS) -DGENERATOR_FILE $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
print-rtl.o : print-rtl.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) \
hard-reg-set.h $(BASIC_BLOCK_H) real.h
rtlanal.o : rtlanal.c $(CONFIG_H) $(SYSTEM_H) toplev.h $(RTL_H) \
hard-reg-set.h $(TM_P_H) insn-config.h $(RECOG_H) real.h flags.h
errors.o : errors.c $(GCONFIG_H) $(SYSTEM_H) errors.h
$(CC) -c $(ALL_CFLAGS) -DGENERATOR_FILE $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
varasm.o : varasm.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(RTL_H) flags.h \
function.h $(EXPR_H) hard-reg-set.h $(REGS_H) \
output.h c-pragma.h toplev.h xcoffout.h debug.h $(GGC_H) $(TM_P_H) \
$(HASHTAB_H) $(TARGET_H) langhooks.h gt-varasm.h real.h
function.o : function.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
function.h $(EXPR_H) libfuncs.h $(REGS_H) hard-reg-set.h \
insn-config.h $(RECOG_H) output.h toplev.h except.h $(HASHTAB_H) $(GGC_H) \
$(TM_P_H) langhooks.h gt-function.h
stmt.o : stmt.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h function.h \
insn-config.h hard-reg-set.h $(EXPR_H) libfuncs.h except.h \
$(LOOP_H) $(RECOG_H) toplev.h output.h varray.h $(GGC_H) $(TM_P_H) \
langhooks.h $(PREDICT_H) gt-stmt.h
except.o : except.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
except.h function.h $(EXPR_H) libfuncs.h integrate.h langhooks.h \
insn-config.h hard-reg-set.h $(BASIC_BLOCK_H) output.h \
dwarf2asm.h dwarf2out.h toplev.h $(HASHTAB_H) intl.h $(GGC_H) \
gt-except.h
expr.o : expr.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h function.h \
$(REGS_H) $(EXPR_H) $(OPTABS_H) libfuncs.h insn-attr.h insn-config.h \
$(RECOG_H) output.h typeclass.h hard-reg-set.h toplev.h hard-reg-set.h \
except.h reload.h $(GGC_H) langhooks.h intl.h $(TM_P_H) real.h
builtins.o : builtins.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
$(TARGET_H) function.h $(REGS_H) $(EXPR_H) $(OPTABS_H) insn-config.h \
$(RECOG_H) output.h typeclass.h hard-reg-set.h toplev.h hard-reg-set.h \
except.h $(TM_P_H) $(PREDICT_H) libfuncs.h real.h langhooks.h
calls.o : calls.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
$(EXPR_H) langhooks.h $(TARGET_H) \
libfuncs.h $(REGS_H) toplev.h output.h function.h $(TIMEVAR_H) $(TM_P_H)
expmed.o : expmed.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
insn-config.h $(EXPR_H) $(OPTABS_H) $(RECOG_H) real.h \
toplev.h $(TM_P_H) langhooks.h
explow.o : explow.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
hard-reg-set.h insn-config.h $(EXPR_H) $(OPTABS_H) $(RECOG_H) \
toplev.h function.h ggc.h $(TM_P_H) gt-explow.h
optabs.o : optabs.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
insn-config.h $(EXPR_H) $(OPTABS_H) libfuncs.h $(RECOG_H) reload.h \
toplev.h $(GGC_H) real.h $(TM_P_H) except.h gt-optabs.h
dbxout.o : dbxout.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(RTL_H) flags.h \
$(REGS_H) debug.h $(TM_P_H) $(TARGET_H) function.h langhooks.h \
insn-config.h reload.h gstab.h xcoffout.h output.h dbxout.h toplev.h \
$(GGC_H) gt-dbxout.h
debug.o : debug.c debug.h $(CONFIG_H) $(SYSTEM_H)
sdbout.o : sdbout.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(RTL_H) flags.h \
function.h $(EXPR_H) output.h hard-reg-set.h $(REGS_H) real.h \
insn-config.h xcoffout.h c-pragma.h ggc.h \
sdbout.h toplev.h $(TM_P_H) except.h debug.h langhooks.h gt-sdbout.h
dwarfout.o : dwarfout.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(RTL_H) dwarf.h \
flags.h insn-config.h reload.h output.h toplev.h $(TM_P_H) \
debug.h langhooks.h
dwarf2out.o : dwarf2out.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(RTL_H) dwarf2.h \
debug.h flags.h insn-config.h reload.h output.h diagnostic.h real.h \
hard-reg-set.h $(REGS_H) $(EXPR_H) libfuncs.h toplev.h dwarf2out.h \
varray.h $(GGC_H) except.h dwarf2asm.h $(TM_P_H) langhooks.h $(HASHTAB_H) \
gt-dwarf2out.h
dwarf2asm.o : dwarf2asm.c $(CONFIG_H) $(SYSTEM_H) flags.h $(RTL_H) $(TREE_H) \
output.h dwarf2asm.h $(TM_P_H) $(GGC_H) gt-dwarf2asm.h
vmsdbgout.o : vmsdbgout.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(RTL_H) flags.h \
output.h vmsdbg.h debug.h langhooks.h function.h
xcoffout.o : xcoffout.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(RTL_H) xcoffout.h \
flags.h toplev.h output.h dbxout.h $(GGC_H) $(TARGET_H)
emit-rtl.o : emit-rtl.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
function.h $(REGS_H) insn-config.h $(RECOG_H) real.h $(GGC_H) \
$(EXPR_H) $(srcdir)/../include/obstack.h hard-reg-set.h bitmap.h toplev.h \
$(HASHTAB_H) $(TM_P_H) debug.h langhooks.h
real.o : real.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) toplev.h $(TM_P_H)
integrate.o : integrate.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
debug.h $(INTEGRATE_H) insn-config.h $(EXPR_H) real.h $(REGS_H) \
intl.h function.h output.h $(RECOG_H) except.h toplev.h $(LOOP_H) \
$(PARAMS_H) $(TM_P_H) $(TARGET_H) langhooks.h gt-integrate.h
jump.o : jump.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h hard-reg-set.h $(REGS_H) \
insn-config.h $(RECOG_H) $(EXPR_H) real.h except.h function.h \
toplev.h $(INSN_ATTR_H) $(TM_P_H) reload.h $(PREDICT_H)
simplify-rtx.o : simplify-rtx.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(REGS_H) \
hard-reg-set.h flags.h real.h insn-config.h $(RECOG_H) $(EXPR_H) toplev.h \
output.h function.h $(GGC_H) $(OBSTACK_H) $(TM_P_H) $(TREE_H)
cselib.o : cselib.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(REGS_H) \
hard-reg-set.h flags.h real.h insn-config.h $(RECOG_H) $(EXPR_H) toplev.h \
output.h function.h cselib.h $(GGC_H) $(TM_P_H) gt-cselib.h
cse.o : cse.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(REGS_H) hard-reg-set.h flags.h \
real.h insn-config.h $(RECOG_H) $(EXPR_H) toplev.h output.h function.h \
$(BASIC_BLOCK_H) $(GGC_H) $(TM_P_H) $(TIMEVAR_H)
gcse.o : gcse.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(REGS_H) hard-reg-set.h \
flags.h real.h insn-config.h ggc.h $(RECOG_H) $(EXPR_H) $(BASIC_BLOCK_H) \
function.h output.h toplev.h $(TM_P_H) $(PARAMS_H) except.h gt-gcse.h
sibcall.o : sibcall.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(REGS_H) function.h \
hard-reg-set.h flags.h insn-config.h $(RECOG_H) $(BASIC_BLOCK_H)
resource.o : resource.c $(CONFIG_H) $(RTL_H) hard-reg-set.h $(SYSTEM_H) \
$(BASIC_BLOCK_H) $(REGS_H) flags.h output.h resource.h function.h toplev.h \
$(INSN_ATTR_H) except.h $(PARAMS_H) $(TM_P_H)
lcm.o : lcm.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(REGS_H) hard-reg-set.h flags.h \
real.h insn-config.h $(INSN_ATTR_H) $(RECOG_H) $(EXPR_H) $(BASIC_BLOCK_H) \
$(TM_P_H) df.h
ssa.o : ssa.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(REGS_H) varray.h $(EXPR_H) \
hard-reg-set.h flags.h function.h real.h insn-config.h $(RECOG_H) \
$(BASIC_BLOCK_H) output.h ssa.h
ssa-dce.o : ssa-dce.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) hard-reg-set.h \
$(BASIC_BLOCK_H) ssa.h insn-config.h $(RECOG_H) output.h
ssa-ccp.o : ssa-ccp.c $(CONFIG_H) system.h $(RTL_H) hard-reg-set.h \
$(BASIC_BLOCK_H) ssa.h insn-config.h $(RECOG_H) output.h \
errors.h $(GGC_H) df.h function.h
df.o : df.c $(CONFIG_H) system.h $(RTL_H) insn-config.h $(RECOG_H) \
function.h $(REGS_H) $(OBSTACK_H) hard-reg-set.h $(BASIC_BLOCK_H) df.h \
$(FIBHEAP_H)
conflict.o : conflict.c $(CONFIG_H) $(SYSTEM_H) $(OBSTACK_H) $(HASHTAB_H) \
$(RTL_H) hard-reg-set.h $(BASIC_BLOCK_H)
profile.o : profile.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
insn-config.h output.h $(REGS_H) $(EXPR_H) function.h \
gcov-io.h toplev.h $(GGC_H) hard-reg-set.h $(BASIC_BLOCK_H) $(TARGET_H) \
langhooks.h profile.h libfuncs.h gt-profile.h
loop.o : loop.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h $(LOOP_H) \
insn-config.h $(REGS_H) hard-reg-set.h $(RECOG_H) $(EXPR_H) \
real.h $(PREDICT_H) $(BASIC_BLOCK_H) function.h \
toplev.h varray.h except.h cselib.h $(OPTABS_H) $(TM_P_H)
doloop.o : doloop.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h $(LOOP_H) \
$(EXPR_H) hard-reg-set.h $(BASIC_BLOCK_H) $(TM_P_H) toplev.h
unroll.o : unroll.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) insn-config.h function.h \
$(INTEGRATE_H) $(REGS_H) $(RECOG_H) flags.h $(EXPR_H) $(LOOP_H) toplev.h \
hard-reg-set.h varray.h $(BASIC_BLOCK_H) $(TM_P_H) $(PREDICT_H) $(PARAMS_H)
flow.o : flow.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h insn-config.h \
$(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h output.h toplev.h $(RECOG_H) \
function.h except.h $(EXPR_H) ssa.h $(GGC_H) $(TM_P_H)
cfg.o : cfg.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h insn-config.h \
$(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h output.h toplev.h $(RECOG_H) \
function.h except.h $(GGC_H) $(TM_P_H)
cfgrtl.o : cfgrtl.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h insn-config.h \
$(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h output.h toplev.h $(RECOG_H) \
function.h except.h $(GGC_H) $(TM_P_H) insn-config.h
cfganal.o : cfganal.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(BASIC_BLOCK_H) \
hard-reg-set.h insn-config.h $(RECOG_H) $(GGC_H) $(TM_P_H)
cfgbuild.o : cfgbuild.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h insn-config.h \
$(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h output.h toplev.h $(RECOG_H) \
function.h except.h $(GGC_H)
cfgcleanup.o : cfgcleanup.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TIMEVAR_H)\
$(BASIC_BLOCK_H) hard-reg-set.h output.h flags.h $(RECOG_H) toplev.h \
$(GGC_H) insn-config.h cselib.h $(TARGET_H) $(TM_P_H)
cfgloop.o : cfgloop.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) \
$(BASIC_BLOCK_H) hard-reg-set.h
dominance.o : dominance.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) hard-reg-set.h \
$(BASIC_BLOCK_H) et-forest.h
et-forest.o : et-forest.c $(CONFIG_H) $(SYSTEM_H) et-forest.h
combine.o : combine.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h function.h \
insn-config.h $(INSN_ATTR_H) $(REGS_H) $(EXPR_H) \
$(BASIC_BLOCK_H) $(RECOG_H) real.h hard-reg-set.h toplev.h $(TM_P_H)
regclass.o : regclass.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) hard-reg-set.h flags.h \
$(BASIC_BLOCK_H) $(REGS_H) insn-config.h $(RECOG_H) reload.h real.h \
toplev.h function.h output.h $(GGC_H) $(TM_P_H) $(EXPR_H)
local-alloc.o : local-alloc.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h \
$(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h insn-config.h $(RECOG_H) \
output.h function.h $(INSN_ATTR_H) toplev.h except.h $(TM_P_H)
bitmap.o : bitmap.c $(GCONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h \
$(BASIC_BLOCK_H) $(REGS_H) $(GGC_H)
$(CC) -c $(ALL_CFLAGS) -DGENERATOR_FILE $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
global.o : global.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h reload.h function.h \
$(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h insn-config.h output.h toplev.h \
$(TM_P_H)
varray.o : varray.c $(CONFIG_H) $(SYSTEM_H) varray.h $(GGC_H) errors.h
ra.o : ra.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TM_P_H) insn-config.h \
$(RECOG_H) integrate.h function.h $(REGS_H) $(OBSTACK_H) hard-reg-set.h \
$(BASIC_BLOCK_H) df.h expr.h output.h toplev.h flags.h reload.h ra.h
ra-build.o : ra-build.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TM_P_H) \
insn-config.h $(RECOG_H) function.h $(REGS_H) hard-reg-set.h \
$(BASIC_BLOCK_H) df.h output.h ggc.h ra.h gt-ra-build.h reload.h
ra-colorize.o : ra-colorize.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TM_P_H) \
function.h $(REGS_H) hard-reg-set.h $(BASIC_BLOCK_H) df.h output.h ra.h
ra-debug.o : ra-debug.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) insn-config.h \
$(RECOG_H) function.h hard-reg-set.h $(BASIC_BLOCK_H) df.h output.h ra.h \
$(TM_P_H)
ra-rewrite.o : ra-rewrite.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TM_P_H) \
function.h $(REGS_H) hard-reg-set.h $(BASIC_BLOCK_H) df.h expr.h \
output.h except.h ra.h reload.h insn-config.h
reload.o : reload.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h output.h \
$(EXPR_H) $(OPTABS_H) reload.h $(RECOG_H) hard-reg-set.h insn-config.h \
$(REGS_H) function.h real.h toplev.h $(TM_P_H)
reload1.o : reload1.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) real.h flags.h \
$(EXPR_H) $(OPTABS_H) reload.h $(REGS_H) hard-reg-set.h insn-config.h \
$(BASIC_BLOCK_H) $(RECOG_H) output.h function.h toplev.h cselib.h $(TM_P_H) \
except.h $(TREE_H)
caller-save.o : caller-save.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h \
$(REGS_H) hard-reg-set.h insn-config.h $(BASIC_BLOCK_H) function.h \
$(RECOG_H) reload.h $(EXPR_H) toplev.h $(TM_P_H)
reorg.o : reorg.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) conditions.h hard-reg-set.h \
$(BASIC_BLOCK_H) $(REGS_H) insn-config.h $(INSN_ATTR_H) except.h \
$(RECOG_H) function.h flags.h output.h $(EXPR_H) toplev.h $(PARAMS_H) $(TM_P_H)
alias.o : alias.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) flags.h hard-reg-set.h \
$(BASIC_BLOCK_H) $(REGS_H) toplev.h output.h $(EXPR_H) \
$(GGC_H) function.h cselib.h $(TREE_H) $(TM_P_H) langhooks.h $(TARGET_H) \
gt-alias.h
regmove.o : regmove.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) insn-config.h \
$(RECOG_H) output.h $(REGS_H) hard-reg-set.h flags.h function.h \
$(EXPR_H) $(BASIC_BLOCK_H) toplev.h $(TM_P_H) except.h reload.h
haifa-sched.o : haifa-sched.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) sched-int.h \
$(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h flags.h insn-config.h function.h \
$(INSN_ATTR_H) toplev.h $(RECOG_H) except.h $(TM_P_H) $(TARGET_H)
sched-deps.o : sched-deps.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) sched-int.h \
$(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h flags.h insn-config.h function.h \
$(INSN_ATTR_H) toplev.h $(RECOG_H) except.h cselib.h $(PARAMS_H) $(TM_P_H)
sched-rgn.o : sched-rgn.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) sched-int.h \
$(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h flags.h insn-config.h function.h \
$(INSN_ATTR_H) toplev.h $(RECOG_H) except.h $(TM_P_H) $(TARGET_H)
sched-ebb.o : sched-ebb.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) sched-int.h \
$(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h flags.h insn-config.h function.h \
$(INSN_ATTR_H) toplev.h $(RECOG_H) except.h $(TM_P_H)
sched-vis.o : sched-vis.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) sched-int.h \
hard-reg-set.h $(BASIC_BLOCK_H) $(INSN_ATTR_H) $(REGS_H) $(TM_P_H) \
$(TARGET_H) real.h
final.o : final.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h intl.h \
$(REGS_H) $(RECOG_H) conditions.h insn-config.h $(INSN_ATTR_H) function.h \
real.h output.h hard-reg-set.h except.h debug.h xcoffout.h profile.h \
toplev.h reload.h dwarf2out.h $(BASIC_BLOCK_H) $(TM_P_H) $(TARGET_H) $(EXPR_H)
recog.o : recog.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) function.h $(BASIC_BLOCK_H) \
$(REGS_H) $(RECOG_H) $(EXPR_H) hard-reg-set.h flags.h insn-config.h \
$(INSN_ATTR_H) real.h toplev.h output.h reload.h $(TM_P_H)
reg-stack.o : reg-stack.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) $(RECOG_H) \
$(REGS_H) hard-reg-set.h flags.h insn-config.h toplev.h reload.h \
varray.h function.h $(TM_P_H) $(GGC_H) gt-reg-stack.h
predict.o: predict.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) flags.h \
insn-config.h $(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h output.h toplev.h \
$(RECOG_H) function.h except.h $(EXPR_H) $(TM_P_H) $(PREDICT_H) real.h \
$(PARAMS_H) $(TARGET_H)
lists.o: lists.c $(CONFIG_H) $(SYSTEM_H) toplev.h $(RTL_H) $(GGC_H)
bb-reorder.o : bb-reorder.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) \
flags.h $(BASIC_BLOCK_H) hard-reg-set.h output.h cfglayout.h $(TARGET_H)
tracer.o : tracer.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) \
$(BASIC_BLOCK_H) hard-reg-set.h output.h cfglayout.h flags.h \
$(PARAMS_H) profile.h
cfglayout.o : cfglayout.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(TREE_H) \
insn-config.h $(BASIC_BLOCK_H) hard-reg-set.h output.h function.h \
cfglayout.h
timevar.o : timevar.c $(CONFIG_H) $(SYSTEM_H) $(TIMEVAR_H) flags.h intl.h
regrename.o : regrename.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) insn-config.h \
$(BASIC_BLOCK_H) $(REGS_H) hard-reg-set.h output.h $(RECOG_H) function.h \
resource.h $(OBSTACK_H) flags.h $(TM_P_H)
ifcvt.o : ifcvt.c $(CONFIG_H) $(SYSTEM_H) $(RTL_H) $(REGS_H) toplev.h \
flags.h insn-config.h function.h $(RECOG_H) $(BASIC_BLOCK_H) $(EXPR_H) \
output.h except.h $(TM_P_H) real.h
params.o : params.c $(CONFIG_H) $(SYSTEM_H) $(PARAMS_H) toplev.h
hooks.o: hooks.c $(CONFIG_H) $(SYSTEM_H) $(HOOKS_H)
# APPLE LOCAL debugging
# Suppress all warnings explicitly for the idebug builds since there can be
# many when, and if, -traditional-cpp is used.
c-idebug.o : c-idebug.c $(CONFIG_H) $(TREE_H) $(C_TREE_H) $(RTL_H) flags.h idebug.c
$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -w $(srcdir)/c-idebug.c -o c-idebug.o
# APPLE LOCAL begin new tree dump
dmp-tree.o : dmp-tree.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(GGC_H) $(C_COMMON_H) \
langhooks.h dmp-tree.h
c-dmp-tree.o : c-dmp-tree.c $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(GGC_H) \
$(C_TREE_H) dmp-tree.h
# Additional dependencies for existing rules for new tree dump
c-decl.o : dmp-tree.h
tree.o : dmp-tree.h
# APPLE LOCAL end new tree dump
# APPLE LOCAL begin PFE
# Additional dependencies for existing rules for PFE.
c-decl.o : $(PFE_H) $(PFE_HEADER_H)
c-lang.o : $(PFE_H) $(C_FREEZE_THAW_H)
c-lex.o : $(PFE_H)
cppfiles.o : $(PFE_H) $(PFE_HEADER_H)
cppinit.o : $(PFE_H) $(PFE_HEADER_H)
cpplex.o : $(PFE_H)
cpplib.o : $(PFE_H) $(PFE_HEADER_H)
cppmacro.o : $(PFE_H)
cppmain.o : $(PFE_H)
dbxout.o : $(PFE_H) $(PFE_HEADER_H)
diagnostic.o : $(PFE_H)
emit-rtl.o : $(PFE_H) $(PFE_HEADER_H)
except.o : $(PFE_H) $(PFE_HEADER_H)
expr.o : $(PFE_H)
function.o : $(PFE_H) $(PFE_HEADER_H) $(TM_P_H)
genrtl.o : $(PFE_H)
ggc-page.o : $(PFE_H) $(PFE_HEADER_H)
hashtable.o : $(PFE_H)
integrate.o : $(PFE_H) $(PFE_HEADER_H)
rtl.o : $(PFE_H)
stringpool.o : $(PFE_H)
toplev.o : $(PFE_H) $(PFE_HEADER_H)
tree.o : $(PFE_H)
varasm.o : $(PFE_H) $(PFE_HEADER_H)
varray.o : $(PFE_H)
# Use default build rule whenever possible. However, several pfe
# files have explicit build rules...
# stub-pfe.o Stub for various compiler build tools which is
# includes config.h but doesn't need insn-codes.h
# and insn-flags.h included by config.h. Defining
# GENERATOR_FILE explicitly suppresses these includes.
pfe/pfe.o: $(PFE_DIR)/pfe.c $(PFE_H) $(PFE_MEM_H) \
$(GCONFIG_H) $(SYSTEM_H) $(PFE_HEADER_H) $(TIMEVAR_H) $(TM_P_H) \
$(MACHMODE_H) langhooks.h $(TREE_H) $(CONFIG_H)
$(CC) -c -no-cpp-precomp $(INTERNAL_CFLAGS) $(CFLAGS) -DHAVE_CONFIG_H \
$(ALL_CPPFLAGS) -DGENERATOR_FILE \
$(INCLUDES) \
$(PFE_DIR)/pfe.c -o pfe/pfe.o
pfe/pfe-mem.o: $(PFE_DIR)/pfe-mem.c \
$(PFE_DIR)/pfe-mem.h \
$(GCONFIG_H) $(SYSTEM_H)
$(CC) -c -no-cpp-precomp $(INTERNAL_CFLAGS) $(CFLAGS) -DHAVE_CONFIG_H \
$(ALL_CPPFLAGS) -DGENERATOR_FILE \
$(INCLUDES) \
$(PFE_DIR)/pfe-mem.c -o pfe/pfe-mem.o
pfe/stub-pfe.o: $(PFE_DIR)/stub-pfe.c $(PFE_H) $(PFE_HEADER_H) $(GCONFIG_H) $(SYSTEM_H)
$(CC) -c -no-cpp-precomp $(INTERNAL_CFLAGS) $(CFLAGS) -DHAVE_CONFIG_H \
$(ALL_CPPFLAGS) -DGENERATOR_FILE $(INCLUDES) \
$(PFE_DIR)/stub-pfe.c -o pfe/stub-pfe.o
# Use this version when compiling into host-only tools like genflags.
pfe/$(BUILD_PREFIX_1)stub-pfe.o: $(PFE_DIR)/stub-pfe.c $(PFE_H) $(PFE_HEADER_H) $(HCONFIG_H) $(SYSTEM_H)
rm -f pfe/$(BUILD_PREFIX)stub-pfe.c
sed -e 's/config[.]h/hconfig.h/' $(PFE_DIR)/stub-pfe.c > pfe/$(BUILD_PREFIX)stub-pfe.c
$(HOST_CC) -c -no-cpp-precomp $(HOST_CFLAGS) -DHAVE_CONFIG_H \
$(ALL_CPPFLAGS) -DGENERATOR_FILE $(INCLUDES) \
pfe/$(BUILD_PREFIX)stub-pfe.c -o pfe/$(BUILD_PREFIX_1)stub-pfe.o
pfe/pfe-header.o: $(PFE_DIR)/pfe-header.c $(PFE_H) \
$(GCONFIG_H) $(SYSTEM_H) $(TM_P_H) $(PFE_HEADER_H) toplev.h langhooks.h \
$(TREE_H) $(RTL_H) varray.h $(CPPLIB_H) $(PFE_DIR)/structs-to-check.def $(CONFIG_H)
pfe/freeze-thaw.o: $(PFE_DIR)/freeze-thaw.c $(PFE_H) \
$(GCONFIG_H) $(SYSTEM_H) $(C_TREE_H) $(RTL_H) hard-reg-set.h langhooks.h \
$(BASIC_BLOCK_H) $(CONFIG_H)
pfe/c-freeze-thaw.o: $(PFE_DIR)/c-freeze-thaw.c $(PFE_H) $(PFE_HEADER_H) \
$(GCONFIG_H) $(SYSTEM_H) $(C_FREEZE_THAW_H) \
$(PFE_DIR)/structs-to-check.def $(TREE_H) $(CONFIG_H)
pfe/c-common-freeze-thaw.o: $(PFE_DIR)/c-common-freeze-thaw.c $(PFE_H) \
$(GCONFIG_H) $(SYSTEM_H) $(TREE_H) $(CONFIG_H)
pfe/pfedbg.o: $(PFE_DIR)/pfedbg.c toplev.h intl.h $(PFE_H) \
$(GCONFIG_H) $(SYSTEM_H) $(TREE_H) $(CONFIG_H)
# APPLE LOCAL end PFE
# APPLE LOCAL indexing
c-decl.o : genindex.h
cppfiles.o : genindex.h
toplev.o : genindex.h
cppmacro.o : genindex.h
genindex.o : config.h $(SYSTEM_H) genindex.h $(TREE_H) $(CONFIG_H)
stub-genindex.o : config.h $(SYSTEM_H) genindex.h $(TREE_H) $(CONFIG_H)
$(out_object_file): $(out_file) $(CONFIG_H) $(TREE_H) $(GGC_H) \
$(RTL_H) $(REGS_H) hard-reg-set.h real.h insn-config.h conditions.h \
output.h $(INSN_ATTR_H) $(SYSTEM_H) toplev.h $(TARGET_H) libfuncs.h \
$(TARGET_DEF_H) function.h sched-int.h $(TM_P_H) $(EXPR_H) $(OPTABS_H) \
langhooks.h
$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
$(out_file) $(OUTPUT_OPTION)
# Build auxiliary files that support ecoff format.
mips-tfile: mips-tfile.o version.o $(LIBDEPS)
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ mips-tfile.o version.o $(LIBS)
mips-tfile.o : mips-tfile.c $(CONFIG_H) $(RTL_H) $(SYSTEM_H) version.h
mips-tdump: mips-tdump.o version.o $(LIBDEPS)
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ mips-tdump.o version.o $(LIBS)
mips-tdump.o : mips-tdump.c $(CONFIG_H) $(RTL_H) $(SYSTEM_H)
#\f
# Generate header and source files from the machine description,
# and compile them.
.PRECIOUS: insn-config.h insn-flags.h insn-codes.h insn-constants.h \
insn-emit.c insn-recog.c insn-extract.c insn-output.c insn-peep.c \
insn-attr.h insn-attrtab.c
# The following pair of rules has this effect:
# genconfig is run only if the md has changed since genconfig was last run;
# but the file insn-config.h is touched only when its contents actually change.
# Each of the other insn-* files is handled by a similar pair of rules.
# This causes an anomaly in the results of make -n
# because insn-* is older than s-*
# and thus make -n thinks that insn-* will be updated
# and force recompilation of things that depend on it.
# We use move-if-change precisely to avoid such recompilation.
# But there is no way to teach make -n that it will be avoided.
# Each of the insn-*.[ch] rules has a semicolon at the end,
# for otherwise the system Make on SunOS 4.1 never tries
# to recompile insn-*.o. To avoid problems and extra noise from
# versions of make which don't like empty commands (nothing after the
# trailing `;'), we call true for each.
insn-config.h: s-config ; @true
s-config : $(md_file) genconfig$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genconfig$(build_exeext) $(md_file) > tmp-config.h
$(SHELL) $(srcdir)/move-if-change tmp-config.h insn-config.h
$(STAMP) s-config
insn-conditions.c: s-conditions ; @true
s-conditions : $(md_file) genconditions$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genconditions$(build_exeext) $(md_file) > tmp-conditions.c
$(SHELL) $(srcdir)/move-if-change tmp-conditions.c insn-conditions.c
$(STAMP) s-conditions
insn-conditions.o : insn-conditions.c $(GCONFIG_H) $(SYSTEM_H) $(RTL_H) \
$(TM_P_H) $(REGS_H) function.h $(RECOG_H) real.h output.h flags.h \
hard-reg-set.h resource.h toplev.h reload.h gensupport.h insn-constants.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) insn-conditions.c
dummy-conditions.o : dummy-conditions.c $(HCONFIG_H) $(SYSTEM_H) gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) \
$(srcdir)/dummy-conditions.c $(OUTPUT_OPTION)
insn-flags.h: s-flags ; @true
s-flags : $(md_file) genflags$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genflags$(build_exeext) $(md_file) > tmp-flags.h
$(SHELL) $(srcdir)/move-if-change tmp-flags.h insn-flags.h
$(STAMP) s-flags
insn-codes.h: s-codes ; @true
s-codes : $(md_file) gencodes$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./gencodes$(build_exeext) $(md_file) > tmp-codes.h
$(SHELL) $(srcdir)/move-if-change tmp-codes.h insn-codes.h
$(STAMP) s-codes
insn-constants.h: s-constants ; @true
s-constants : $(md_file) genconstants$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genconstants$(build_exeext) $(md_file) > tmp-constants.h
$(SHELL) $(srcdir)/move-if-change tmp-constants.h insn-constants.h
$(STAMP) s-constants
insn-emit.o : insn-emit.c $(CONFIG_H) $(RTL_H) $(EXPR_H) real.h output.h \
insn-config.h $(OPTABS_H) $(SYSTEM_H) reload.h $(RECOG_H) toplev.h \
function.h flags.h hard-reg-set.h resource.h $(TM_P_H)
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -c insn-emit.c \
$(OUTPUT_OPTION)
insn-emit.c: s-emit ; @true
s-emit : $(md_file) genemit$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genemit$(build_exeext) $(md_file) > tmp-emit.c
$(SHELL) $(srcdir)/move-if-change tmp-emit.c insn-emit.c
$(STAMP) s-emit
insn-recog.o : insn-recog.c $(CONFIG_H) $(RTL_H) insn-config.h $(RECOG_H) \
real.h output.h flags.h $(SYSTEM_H) function.h hard-reg-set.h resource.h \
$(TM_P_H) toplev.h reload.h
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -c insn-recog.c \
$(OUTPUT_OPTION)
insn-recog.c: s-recog ; @true
s-recog : $(md_file) genrecog$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genrecog$(build_exeext) $(md_file) > tmp-recog.c
$(SHELL) $(srcdir)/move-if-change tmp-recog.c insn-recog.c
$(STAMP) s-recog
insn-opinit.o : insn-opinit.c $(CONFIG_H) $(RTL_H) \
insn-config.h flags.h $(RECOG_H) $(EXPR_H) $(OPTABS_H) reload.h $(SYSTEM_H)
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -c insn-opinit.c \
$(OUTPUT_OPTION)
insn-opinit.c: s-opinit ; @true
s-opinit : $(md_file) genopinit$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genopinit$(build_exeext) $(md_file) > tmp-opinit.c
$(SHELL) $(srcdir)/move-if-change tmp-opinit.c insn-opinit.c
$(STAMP) s-opinit
insn-extract.o : insn-extract.c $(CONFIG_H) $(RTL_H) $(SYSTEM_H) toplev.h \
insn-config.h $(RECOG_H)
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -c insn-extract.c \
$(OUTPUT_OPTION)
insn-extract.c: s-extract ; @true
s-extract : $(md_file) genextract$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genextract$(build_exeext) $(md_file) > tmp-extract.c
$(SHELL) $(srcdir)/move-if-change tmp-extract.c insn-extract.c
$(STAMP) s-extract
insn-peep.o : insn-peep.c $(CONFIG_H) $(RTL_H) $(REGS_H) output.h real.h \
$(SYSTEM_H) insn-config.h $(RECOG_H) except.h function.h $(TM_P_H)
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -c insn-peep.c \
$(OUTPUT_OPTION)
insn-peep.c: s-peep ; @true
s-peep : $(md_file) genpeep$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genpeep$(build_exeext) $(md_file) > tmp-peep.c
$(SHELL) $(srcdir)/move-if-change tmp-peep.c insn-peep.c
$(STAMP) s-peep
insn-attrtab.o : insn-attrtab.c $(CONFIG_H) $(RTL_H) $(REGS_H) real.h \
output.h $(INSN_ATTR_H) insn-config.h $(SYSTEM_H) toplev.h $(RECOG_H) \
$(TM_P_H) flags.h
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -c insn-attrtab.c \
$(OUTPUT_OPTION)
insn-attr.h: s-attr ; @true
s-attr : $(md_file) genattr$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genattr$(build_exeext) $(md_file) > tmp-attr.h
$(SHELL) $(srcdir)/move-if-change tmp-attr.h insn-attr.h
$(STAMP) s-attr
insn-attrtab.c: s-attrtab ; @true
s-attrtab : $(md_file) genattrtab$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genattrtab$(build_exeext) $(md_file) > tmp-attrtab.c
$(SHELL) $(srcdir)/move-if-change tmp-attrtab.c insn-attrtab.c
$(STAMP) s-attrtab
insn-output.o : insn-output.c $(CONFIG_H) $(RTL_H) $(GGC_H) $(REGS_H) real.h \
conditions.h hard-reg-set.h insn-config.h $(INSN_ATTR_H) $(EXPR_H) \
output.h $(RECOG_H) function.h $(SYSTEM_H) toplev.h flags.h \
insn-codes.h $(TM_P_H)
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -c insn-output.c \
$(OUTPUT_OPTION)
insn-output.c: s-output ; @true
s-output : $(md_file) genoutput$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genoutput$(build_exeext) $(md_file) > tmp-output.c
$(SHELL) $(srcdir)/move-if-change tmp-output.c insn-output.c
$(STAMP) s-output
genrtl.o : genrtl.c $(CONFIG_H) $(RTL_H) $(SYSTEM_H) $(GGC_H)
genrtl.c genrtl.h : s-genrtl
@true # force gnu make to recheck modification times.
s-genrtl: gengenrtl$(build_exeext) $(srcdir)/move-if-change $(RTL_BASE_H)
$(RUN_GEN) ./gengenrtl$(build_exeext) -h > tmp-genrtl.h
$(SHELL) $(srcdir)/move-if-change tmp-genrtl.h genrtl.h
$(RUN_GEN) ./gengenrtl$(build_exeext) > tmp-genrtl.c
$(SHELL) $(srcdir)/move-if-change tmp-genrtl.c genrtl.c
$(STAMP) s-genrtl
tm-preds.h: s-preds; @true
s-preds: genpreds$(build_exeext) $(srcdir)/move-if-change
$(RUN_GEN) ./genpreds$(build_exeext) > tmp-preds.h
$(SHELL) $(srcdir)/move-if-change tmp-preds.h tm-preds.h
$(STAMP) s-preds
GTFILES = $(GCONFIG_H) \
$(HASHTAB_H) $(SPLAY_TREE_H) $(srcdir)/cpplib.h \
$(srcdir)/location.h $(srcdir)/bitmap.h $(srcdir)/function.h \
$(srcdir)/rtl.h $(srcdir)/optabs.h $(srcdir)/tree.h $(srcdir)/libfuncs.h \
$(srcdir)/hashtable.h $(srcdir)/real.h \
$(srcdir)/varray.h $(srcdir)/ssa.h $(srcdir)/insn-addr.h $(srcdir)/cselib.h \
$(srcdir)/basic-block.h $(srcdir)/location.h \
$(srcdir)/c-common.h $(srcdir)/c-tree.h \
$(srcdir)/alias.c $(srcdir)/bitmap.c $(srcdir)/cselib.c \
$(srcdir)/dbxout.c $(srcdir)/dwarf2out.c $(srcdir)/dwarf2asm.c \
$(srcdir)/emit-rtl.c $(srcdir)/except.c $(srcdir)/explow.c $(srcdir)/expr.c \
$(srcdir)/fold-const.c $(srcdir)/function.c \
$(srcdir)/gcse.c $(srcdir)/integrate.c $(srcdir)/lists.c $(srcdir)/optabs.c \
$(srcdir)/profile.c $(srcdir)/ra-build.c $(srcdir)/regclass.c \
$(srcdir)/reg-stack.c \
$(srcdir)/sdbout.c $(srcdir)/stmt.c $(srcdir)/stor-layout.c \
$(srcdir)/stringpool.c $(srcdir)/tree.c $(srcdir)/varasm.c \
$(out_file) \
@all_gtfiles@
GTFILES_FILES_LANGS = @all_gtfiles_files_langs@
GTFILES_FILES_FILES = @all_gtfiles_files_files@
GTFILES_LANG_DIR_NAMES = @subdirs@
GTFILES_SRCDIR = @srcdir@
gtype-desc.h gtype-desc.c gt-except.h gt-function.h : s-gtype; @true
gt-integrate.h gt-stmt.h gt-tree.h gt-varasm.h gt-emit-rtl.h : s-gtype; @true
gt-explow.h gt-stor-layout.h gt-regclass.h gt-lists.h : s-gtype; @true
gt-alias.h gt-cselib.h gt-fold-const.h gt-gcse.h gt-profile.h : s-gtype; @true
gt-expr.h gt-sdbout.h gt-optabs.h gt-bitmap.h gt-dwarf2out.h : s-gtype ; @true
gt-ra-build.h gt-reg-stack.h gt-dwarf2asm.h gt-dbxout.h : s-gtype ; @true
gt-c-common.h gt-c-decl.h gt-c-parse.h gt-c-pragma.h : s-gtype; @true
gt-c-objc-common.h gtype-c.h gt-location.h gt-stringpool.h : s-gtype ; @true
gtyp-gen.h: Makefile
echo "/* This file is machine generated. Do not edit. */" > tmp-gtyp.h
echo "static const char *srcdir = " >> tmp-gtyp.h
echo "\"$(GTFILES_SRCDIR)\"" >> tmp-gtyp.h
echo ";" >> tmp-gtyp.h
echo "static const char *lang_files[] = {" >> tmp-gtyp.h
ll="$(GTFILES_FILES_FILES)"; \
for f in $$ll; do \
echo "\"$$f\", "; done >> tmp-gtyp.h
echo "NULL};" >> tmp-gtyp.h
echo "static const char *langs_for_lang_files[] = {" >> tmp-gtyp.h
ff="$(GTFILES_FILES_LANGS)"; \
for f in $$ff; do \
echo "\"$$f\", " ; done >> tmp-gtyp.h
echo "NULL};" >> tmp-gtyp.h
echo "static const char *all_files[] = {" >> tmp-gtyp.h
gf="$(GTFILES)"; \
for f in $$gf; do \
echo "\"$$f\", "; done >> tmp-gtyp.h
echo " NULL};" >> tmp-gtyp.h
echo "static const char *lang_dir_names[] = { \"c\", " >> tmp-gtyp.h
gf="$(GTFILES_LANG_DIR_NAMES)"; \
for l in $$gf; do \
echo "\"$$l\", "; done >> tmp-gtyp.h
echo "NULL};" >> tmp-gtyp.h
$(SHELL) $(srcdir)/move-if-change tmp-gtyp.h gtyp-gen.h
s-gtype: gengtype$(build_exeext) $(GTFILES)
$(RUN_GEN) ./gengtype
$(STAMP) s-gtype
#\f
# Compile the programs that generate insn-* from the machine description.
# They are compiled with $(HOST_CC), and associated libraries,
# since they need to run on this machine
# even if GCC is being compiled to run on some other machine.
# $(CONFIG_H) is omitted from the deps of the gen*.o
# because these programs don't really depend on anything
# about the target machine. They do depend on config.h itself,
# since that describes the host machine.
read-rtl.o: read-rtl.c $(HCONFIG_H) $(SYSTEM_H) $(RTL_H) \
$(OBSTACK_H) $(HASHTAB_H)
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/read-rtl.c $(OUTPUT_OPTION)
gensupport.o: gensupport.c $(RTL_H) $(OBSTACK_H) $(SYSTEM_H) errors.h gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/gensupport.c $(OUTPUT_OPTION)
genconfig$(build_exeext) : genconfig.o $(HOST_RTL) $(HOST_SUPPORT) \
$(HOST_PRINT) $(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genconfig.o $(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) \
$(HOST_ERRORS) $(HOST_LIBS)
genconfig.o : genconfig.c $(RTL_H) $(HCONFIG_H) \
$(SYSTEM_H) errors.h gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genconfig.c $(OUTPUT_OPTION)
genflags$(build_exeext) : genflags.o $(HOST_RTL) $(HOST_SUPPORT) \
$(HOST_PRINT) $(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genflags.o $(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) \
$(HOST_ERRORS) $(HOST_LIBS)
genflags.o : genflags.c $(RTL_H) $(OBSTACK_H) $(HCONFIG_H) \
$(SYSTEM_H) errors.h gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genflags.c $(OUTPUT_OPTION)
gencodes$(build_exeext) : gencodes.o $(HOST_RTL) $(HOST_SUPPORT) \
$(HOST_PRINT) $(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
gencodes.o $(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) \
$(HOST_ERRORS) $(HOST_LIBS)
gencodes.o : gencodes.c $(RTL_H) $(HCONFIG_H) \
$(SYSTEM_H) errors.h gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/gencodes.c $(OUTPUT_OPTION)
genconstants$(build_exeext) : genconstants.o $(HOST_RTL) $(HOST_EARLY_SUPPORT) \
$(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genconstants.o $(HOST_EARLY_SUPPORT) $(HOST_RTL) \
$(HOST_ERRORS) $(HOST_LIBS)
genconstants.o : genconstants.c $(RTL_H) $(HCONFIG_H) $(SYSTEM_H) errors.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genconstants.c $(OUTPUT_OPTION)
genemit$(build_exeext) : genemit.o $(HOST_RTL) $(HOST_SUPPORT) \
$(HOST_PRINT) $(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genemit.o $(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) \
$(HOST_ERRORS) $(HOST_LIBS)
genemit.o : genemit.c $(RTL_H) $(HCONFIG_H) $(SYSTEM_H) errors.h gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genemit.c $(OUTPUT_OPTION)
genopinit$(build_exeext) : genopinit.o $(HOST_RTL) $(HOST_SUPPORT) \
$(HOST_PRINT) $(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genopinit.o $(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) \
$(HOST_ERRORS) $(HOST_LIBS)
genopinit.o : genopinit.c $(RTL_H) $(HCONFIG_H) \
$(SYSTEM_H) errors.h gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genopinit.c $(OUTPUT_OPTION)
genrecog$(build_exeext) : genrecog.o $(HOST_RTL) $(HOST_SUPPORT) \
$(HOST_PRINT) $(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genrecog.o $(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) \
$(HOST_ERRORS) $(HOST_LIBS)
genrecog.o : genrecog.c $(RTL_H) $(HCONFIG_H) \
$(SYSTEM_H) errors.h gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genrecog.c $(OUTPUT_OPTION)
genextract$(build_exeext) : genextract.o $(HOST_RTL) $(HOST_SUPPORT) \
$(HOST_PRINT) $(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genextract.o $(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) \
$(HOST_ERRORS) $(HOST_LIBS)
genextract.o : genextract.c $(RTL_H) $(HCONFIG_H) \
$(SYSTEM_H) insn-config.h errors.h gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genextract.c $(OUTPUT_OPTION)
genpeep$(build_exeext) : genpeep.o $(HOST_RTL) $(HOST_SUPPORT) \
$(HOST_PRINT) $(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genpeep.o $(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) \
$(HOST_ERRORS) $(HOST_LIBS)
genpeep.o : genpeep.c $(RTL_H) $(HCONFIG_H) $(SYSTEM_H) errors.h gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genpeep.c $(OUTPUT_OPTION)
genattr$(build_exeext) : genattr.o $(HOST_RTL) $(HOST_SUPPORT) \
$(HOST_PRINT) $(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genattr.o $(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) \
$(HOST_ERRORS) $(HOST_LIBS)
genattr.o : genattr.c $(RTL_H) $(HCONFIG_H) $(SYSTEM_H) errors.h gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genattr.c $(OUTPUT_OPTION)
genattrtab$(build_exeext) : genattrtab.o genautomata.o \
$(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) $(HOST_ERRORS) $(HOST_VARRAY) \
$(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genattrtab.o genautomata.o \
$(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) $(HOST_ERRORS) \
$(HOST_VARRAY) $(HOST_LIBS) -lm
genattrtab.o : genattrtab.c $(RTL_H) $(OBSTACK_H) $(HCONFIG_H) \
$(SYSTEM_H) errors.h $(GGC_H) gensupport.h genattrtab.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genattrtab.c $(OUTPUT_OPTION)
genautomata.o : genautomata.c $(RTL_H) $(OBSTACK_H) $(HCONFIG_H) \
$(SYSTEM_H) errors.h varray.h genattrtab.h $(HASHTAB_H)
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genautomata.c $(OUTPUT_OPTION)
genoutput$(build_exeext) : genoutput.o $(HOST_RTL) $(HOST_SUPPORT) \
$(HOST_PRINT) $(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genoutput.o $(HOST_RTL) $(HOST_SUPPORT) $(HOST_PRINT) \
$(HOST_ERRORS) $(HOST_LIBS)
genoutput.o : genoutput.c $(RTL_H) $(HCONFIG_H) \
$(SYSTEM_H) errors.h gensupport.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genoutput.c $(OUTPUT_OPTION)
gengenrtl$(build_exeext) : gengenrtl.o $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
gengenrtl.o $(HOST_LIBS)
gengenrtl.o : gengenrtl.c $(RTL_BASE_H) $(HCONFIG_H) $(SYSTEM_H) real.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/gengenrtl.c $(OUTPUT_OPTION)
genpreds$(build_exeext) : genpreds.o $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genpreds.o $(HOST_LIBS)
genpreds.o : genpreds.c $(RTL_BASE_H) $(HCONFIG_H) $(SYSTEM_H)
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/genpreds.c $(OUTPUT_OPTION)
gengtype$(build_exeext) : gengtype.o gengtype-lex.o gengtype-yacc.o \
$(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
gengtype.o gengtype-lex.o gengtype-yacc.o $(HOST_LIBS)
gengtype.o : gengtype.c gengtype.h $(HCONFIG_H) $(SYSTEM_H) real.h rtl.def \
gtyp-gen.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) \
$(srcdir)/gengtype.c $(OUTPUT_OPTION)
gengtype-lex.o : $(parsedir)/gengtype-lex.c gengtype.h $(parsedir)/gengtype-yacc.c \
$(HCONFIG_H) $(SYSTEM_H)
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) \
$(parsedir)/gengtype-lex.c $(OUTPUT_OPTION)
gengtype-yacc.o : $(parsedir)/gengtype-yacc.c gengtype.h $(HCONFIG_H) $(SYSTEM_H)
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) \
$(parsedir)/gengtype-yacc.c $(OUTPUT_OPTION)
# The sed command works around a bug in flex-2.5.4.
$(parsedir)/gengtype-lex.c : $(srcdir)/gengtype-lex.l
cd $(parsedir) && \
$(FLEX) $(FLEXFLAGS) -t -o$@ $(srcdir)/gengtype-lex.l | \
sed 's/^\(char msg\[\];\)/yyconst \1/' > g-$$$$ ; \
if test $$? -eq 0 ; then \
mv -f g-$$$$ gengtype-lex.c ; \
else \
rm -f g-$$$$.* ; \
false ; \
fi
$(parsedir)/gengtype-yacc.c: $(srcdir)/gengtype-yacc.y
(cd $(parsedir) && \
$(BISON) $(BISONFLAGS) -d -o gengtype-yacc.c $(srcdir)/gengtype-yacc.y || \
( rm -f $@ && false ) )
genconditions$(build_exeext) : genconditions.o $(HOST_EARLY_SUPPORT) \
$(HOST_RTL) $(HOST_ERRORS) $(HOST_LIBDEPS)
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
genconditions.o $(HOST_EARLY_SUPPORT) $(HOST_RTL) \
$(HOST_ERRORS) $(HOST_LIBS)
genconditions.o : genconditions.c $(RTL_H) $(HCONFIG_H) $(SYSTEM_H) errors.h
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) \
$(srcdir)/genconditions.c $(OUTPUT_OPTION)
#\f
# Compile the libraries to be used by gen*.
# If we are not cross-building, gen* use the same .o's that cc1 will use,
# and BUILD_PREFIX_1 is `loser-', just to ensure these rules don't conflict
# with the rules for rtl.o, etc.
$(BUILD_PREFIX_1)rtl.o: $(srcdir)/rtl.c $(HCONFIG_H) $(SYSTEM_H) $(RTL_H) \
real.h $(GGC_H) errors.h
rm -f $(BUILD_PREFIX)rtl.c
sed -e 's/config[.]h/hconfig.h/' $(srcdir)/rtl.c > $(BUILD_PREFIX)rtl.c
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(BUILD_PREFIX)rtl.c $(OUTPUT_OPTION)
print-rtl1.o: $(srcdir)/print-rtl.c $(HCONFIG_H) \
$(RTL_H) $(TREE_H) hard-reg-set.h $(BASIC_BLOCK_H)
rm -f print-rtl1.c
sed -e 's/config[.]h/hconfig.h/' $(srcdir)/print-rtl.c > print-rtl1.c
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) print-rtl1.c $(OUTPUT_OPTION)
$(BUILD_PREFIX_1)bitmap.o: $(srcdir)/bitmap.c $(HCONFIG_H) $(SYSTEM_H) \
$(RTL_H) flags.h $(BASIC_BLOCK_H) $(REGS_H) $(GGC_H)
rm -f $(BUILD_PREFIX)bitmap.c
sed -e 's/config[.]h/hconfig.h/' $(srcdir)/bitmap.c > $(BUILD_PREFIX)bitmap.c
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(BUILD_PREFIX)bitmap.c $(OUTPUT_OPTION)
$(BUILD_PREFIX_1)errors.o: errors.c $(HCONFIG_H) $(SYSTEM_H) errors.h
rm -f $(BUILD_PREFIX)errors.c
sed -e 's/config[.]h/hconfig.h/' $(srcdir)/errors.c > $(BUILD_PREFIX)errors.c
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(BUILD_PREFIX)errors.c $(OUTPUT_OPTION)
$(BUILD_PREFIX_1)varray.o: varray.c $(HCONFIG_H) $(SYSTEM_H) varray.h \
$(RTL_H) $(GGC_H) $(TREE_H) bitmap.h errors.h
rm -f $(BUILD_PREFIX)varray.c
sed -e 's/config[.]h/hconfig.h/' $(srcdir)/varray.c > \
$(BUILD_PREFIX)varray.c
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) \
$(BUILD_PREFIX)varray.c $(OUTPUT_OPTION)
$(BUILD_PREFIX_1)ggc-none.o: ggc-none.c $(HCONFIG_H) $(SYSTEM_H) $(GGC_H)
rm -f $(BUILD_PREFIX)ggc-none.c
sed -e 's/config[.]h/hconfig.h/' $(srcdir)/ggc-none.c > $(BUILD_PREFIX)ggc-none.c
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(BUILD_PREFIX)ggc-none.c $(OUTPUT_OPTION)
#\f
# Remake internationalization support.
intl.o: intl.c $(CONFIG_H) system.h intl.h Makefile
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-DLOCALEDIR=\"$(localedir)\" \
-c $(srcdir)/intl.c $(OUTPUT_OPTION)
$(top_builddir)/intl/libintl.a: intl.all
$(INTL_TARGETS): $(CONFIG_H) $(parsedir)/c-parse.c
intl.all intl.install intl.uninstall \
intl.mostlyclean intl.clean intl.distclean intl.maintainer-clean:
@for d in $(INTL_SUBDIRS); do \
target=`expr $@ : 'intl.\(.*\)'` && \
echo "(cd $$d && $(MAKE) $$target)" && \
(cd $$d && AWK='$(AWK)' $(MAKE) $(SUBDIR_FLAGS_TO_PASS) $$target); \
if [ $$? -eq 0 ] ; then true ; else exit 1 ; fi ; \
done
# intl.all and intl.install need config.h to exist, and the files it includes.
# (FIXME: intl/*.c shouldn't need to see insn-foo.h!)
intl.all intl.install: config.h insn-flags.h insn-constants.h
# Make-lang.in should add dependencies of po-generated on any generated
# files which need to be scanned by gettext (usually Yacc-generated parsers).
po-generated: c-parse.c
#\f
# Remake cpp and protoize.
PREPROCESSOR_DEFINES = \
-DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
-DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \
-DGPLUSPLUS_TOOL_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/$(target_alias)\" \
-DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"$(gcc_gxx_include_dir)/backward\" \
-DLOCAL_INCLUDE_DIR=\"$(local_includedir)\" \
-DCROSS_INCLUDE_DIR=\"$(gcc_tooldir)/sys-include\" \
-DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\"
LIBCPP_OBJS = cpplib.o cpplex.o cppmacro.o cppexp.o cppfiles.o cpptrad.o \
cpphash.o cpperror.o cppinit.o cppdefault.o cppmain.o \
hashtable.o line-map.o mkdeps.o prefix.o mbchar.o cpppch.o
LIBCPP_DEPS = $(CPPLIB_H) cpphash.h line-map.h hashtable.h intl.h \
$(OBSTACK_H) $(SYSTEM_H)
# Most of the other archives built/used by this makefile are for
# targets. This one is strictly for the host.
libcpp.a: $(LIBCPP_OBJS)
-rm -rf libcpp.a
$(AR) $(AR_FLAGS) libcpp.a $(LIBCPP_OBJS)
-$(RANLIB) libcpp.a
cppmain.o: cppmain.c $(CONFIG_H) $(LIBCPP_DEPS)
cpperror.o: cpperror.c $(CONFIG_H) $(LIBCPP_DEPS)
cppexp.o: cppexp.c $(CONFIG_H) $(LIBCPP_DEPS)
cpplex.o: cpplex.c $(CONFIG_H) $(LIBCPP_DEPS) mbchar.h
cppmacro.o: cppmacro.c $(CONFIG_H) $(LIBCPP_DEPS)
cpplib.o: cpplib.c $(CONFIG_H) $(LIBCPP_DEPS)
cpphash.o: cpphash.c $(CONFIG_H) $(LIBCPP_DEPS)
cpptrad.o: cpptrad.c $(CONFIG_H) $(LIBCPP_DEPS)
cppfiles.o: cppfiles.c $(CONFIG_H) $(LIBCPP_DEPS) $(SPLAY_TREE_H) mkdeps.h
cppinit.o: cppinit.c $(CONFIG_H) $(LIBCPP_DEPS) cppdefault.h \
mkdeps.h prefix.h
cpppch.o: cpptrad.c $(CONFIG_H) $(LIBCPP_DEPS) mkdeps.h
cppdefault.o: cppdefault.c $(CONFIG_H) $(SYSTEM_H) cppdefault.h Makefile
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
$(PREPROCESSOR_DEFINES) \
-c $(srcdir)/cppdefault.c $(OUTPUT_OPTION)
mkdeps.o: mkdeps.c $(CONFIG_H) $(SYSTEM_H) mkdeps.h
# Note for the stamp targets, we run the program `true' instead of
# having an empty command (nothing following the semicolon).
proto: config.status protoize$(exeext) unprotoize$(exeext) SYSCALLS.c.X
PROTO_OBJS = intl.o version.o cppdefault.o
protoize$(exeext): protoize.o $(PROTO_OBJS) $(LIBDEPS)
$(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ protoize.o $(PROTO_OBJS) $(LIBS)
unprotoize$(exeext): unprotoize.o $(PROTO_OBJS) $(LIBDEPS)
$(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ unprotoize.o $(PROTO_OBJS) $(LIBS)
protoize.o: protoize.c $(srcdir)/../include/getopt.h $(CONFIG_H) $(SYSTEM_H) \
Makefile version.h
(SHLIB_LINK='$(SHLIB_LINK)' \
SHLIB_MULTILIB='$(SHLIB_MULTILIB)'; \
$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
$(DRIVER_DEFINES) \
$(srcdir)/protoize.c $(OUTPUT_OPTION))
unprotoize.o: protoize.c $(srcdir)/../include/getopt.h \
$(CONFIG_H) $(SYSTEM_H) Makefile version.h
(SHLIB_LINK='$(SHLIB_LINK)' \
SHLIB_MULTILIB='$(SHLIB_MULTILIB)'; \
$(CC) -c -DUNPROTOIZE $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
$(DRIVER_DEFINES) \
$(srcdir)/protoize.c $(OUTPUT_OPTION))
# This info describes the target machine, so compile with GCC just built.
SYSCALLS.c.X: $(srcdir)/sys-types.h $(srcdir)/sys-protos.h $(GCC_PASSES) \
stmp-int-hdrs
-rm -f SYSCALLS.c tmp-SYSCALLS.s
sed -e s/TARGET_GETGROUPS_T/$(TARGET_GETGROUPS_T)/ \
$(srcdir)/sys-types.h $(srcdir)/sys-protos.h > SYSCALLS.c
$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
-aux-info $@ -S -o tmp-SYSCALLS.s SYSCALLS.c
-rm -f SYSCALLS.c tmp-SYSCALLS.s
test-protoize-simple: ./protoize ./unprotoize $(GCC_PASSES)
-rm -f tmp-proto.[cso]
cp $(srcdir)/protoize.c tmp-proto.c
chmod u+w tmp-proto.c
./protoize -N -B ./ -x getopt.h -c "-B./ -Wall -Wwrite-strings \
$(GCC_CFLAGS) $(INCLUDES) \
-DGCC_INCLUDE_DIR=0 \
-DGPLUSPLUS_INCLUDE_DIR=0 \
-DCROSS_INCLUDE_DIR=0 \
-DTOOL_INCLUDE_DIR=0 \
-DSTANDARD_EXEC_PREFIX=0 \
-DDEFAULT_TARGET_MACHINE=0 \
-DDEFAULT_TARGET_VERSION=0" tmp-proto.c
@echo '**********' Expect 400 lines of differences.
-diff $(srcdir)/protoize.c tmp-proto.c > tmp-proto.diff
-wc -l tmp-proto.diff
./unprotoize -N -x getopt.h -c "-B./ -Wall -Wwrite-strings \
$(GCC_CFLAGS) $(INCLUDES) \
-DGCC_INCLUDE_DIR=0 \
-DGPLUSPLUS_INCLUDE_DIR=0 \
-DCROSS_INCLUDE_DIR=0 \
-DTOOL_INCLUDE_DIR=0 \
-DSTANDARD_EXEC_PREFIX=0 \
-DDEFAULT_TARGET_MACHINE=0 \
-DDEFAULT_TARGET_VERSION=0" tmp-proto.c
@echo Expect zero differences.
diff $(srcdir)/protoize.c tmp-proto.c | cat
-rm -f tmp-proto.[cs] tmp-proto$(objext)
gcov.o: gcov.c gcov-io.h intl.h $(SYSTEM_H) $(CONFIG_H)
# Only one of 'gcov' or 'gcov.exe' is actually built, depending
# upon whether $(exeext) is empty or not.
GCOV_OBJS = gcov.o intl.o version.o
gcov$(exeext): $(GCOV_OBJS) $(LIBDEPS)
$(CC) $(ALL_CFLAGS) $(LDFLAGS) $(GCOV_OBJS) $(LIBS) -o $@
#\f
# Build the include directory. The stamp files are stmp-* rather than
# s-* so that mostlyclean does not force the include directory to
# be rebuilt.
# Build the include directory
stmp-int-hdrs: $(STMP_FIXINC) $(USER_H) xlimits.h
# Copy in the headers provided with gcc.
# The sed command gets just the last file name component;
# this is necessary because VPATH could add a dirname.
# Using basename would be simpler, but some systems don't have it.
# The touch command is here to workaround an AIX/Linux NFS bug.
-if [ -d include ] ; then true; else mkdir include; chmod a+rx include; fi
for file in .. $(USER_H); do \
if [ X$$file != X.. ]; then \
realfile=`echo $$file | sed -e 's|.*/\([^/]*\)$$|\1|'`; \
$(STAMP) include/$$realfile; \
rm -f include/$$realfile; \
cp $$file include; \
chmod a+r include/$$realfile; \
fi; \
done
rm -f include/limits.h
cp xlimits.h include/limits.h
chmod a+r include/limits.h
# Install the README
rm -f include/README
cp $(srcdir)/README-fixinc include/README
chmod a+r include/README
$(STAMP) $@
# fixinc.sh depends on this, not on specs directly.
# The idea is to make sure specs gets built, but not rerun fixinc.sh
# after each stage just because specs' mtime has changed.
specs.ready: specs
-if [ -f specs.ready ] ; then \
true; \
else \
$(STAMP) specs.ready; \
fi
FIXINCSRCDIR=$(srcdir)/fixinc
fixinc.sh: $(FIXINCSRCDIR)/mkfixinc.sh $(FIXINCSRCDIR)/fixincl.c \
$(FIXINCSRCDIR)/procopen.c $(FIXINCSRCDIR)/gnu-regex.c \
$(FIXINCSRCDIR)/server.c $(FIXINCSRCDIR)/gnu-regex.h \
$(FIXINCSRCDIR)/server.h $(FIXINCSRCDIR)/inclhack.def specs.ready
(MAKE="$(MAKE)"; srcdir=`cd $(srcdir)/fixinc && ${PWD}` ; \
CC="$(HOST_CC)"; CFLAGS="$(HOST_CFLAGS)"; LDFLAGS="$(HOST_LDFLAGS)"; \
WARN_CFLAGS="$(WARN_CFLAGS)"; \
export MAKE srcdir CC CFLAGS LDFLAGS WARN_CFLAGS; cd ./fixinc && \
$(SHELL) $${srcdir}/mkfixinc.sh $(build_canonical) $(target))
# Build fixed copies of system files.
stmp-fixinc: fixinc.sh gsyslimits.h
rm -rf include; mkdir include
-chmod a+rx include
(TARGET_MACHINE='$(target)'; srcdir=`cd $(srcdir); ${PWD}`; \
SHELL='$(SHELL)' ;\
export TARGET_MACHINE srcdir SHELL ; \
$(SHELL) ./fixinc.sh `${PWD}`/include $(SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS); \
rm -f include/syslimits.h; \
if [ -f include/limits.h ]; then \
mv include/limits.h include/syslimits.h; \
else \
cp $(srcdir)/gsyslimits.h include/syslimits.h; \
fi; \
chmod a+r include/syslimits.h)
# If $(SYSTEM_HEADER_DIR) is $(build_tooldir)/sys-include, and
# that directory exists, then make sure that $(libsubdir) exists.
# This is because cpp is compiled to find $(gcc_tooldir)/include via
# $(libsubdir)/$(unlibsubdir), which will only work if $(libsubdir)
# exists.
# ??? Better would be to use -isystem $(build_tooldir)/sys-include,
# but fixincludes does not take such arguments.
if [ "$(SYSTEM_HEADER_DIR)" = "$(build_tooldir)/sys-include" ] \
&& [ -d $(build_tooldir)/sys-include ]; then \
if [ -d $(libdir) ] ; then true ; else mkdir $(libdir) ; fi; \
if [ -d $(libdir)/gcc-lib ] ; then true ; else mkdir $(libdir)/gcc-lib; fi; \
if [ -d $(libdir)/gcc-lib/$(target_alias) ] ; then true ; else mkdir $(libdir)/gcc-lib/$(target_alias) ; fi; \
if [ -d $(libdir)/gcc-lib/$(target_alias)/$(version) ] ; then true ; else mkdir $(libdir)/gcc-lib/$(target_alias)/$(version) ; fi; \
else true; fi
$(STAMP) stmp-fixinc
# Files related to the fixproto script.
# gen-protos and fix-header are compiled with HOST_CC, but they are only
# used in native and host-x-target builds, so it's safe to link them with
# libiberty.a.
deduced.h: $(GCC_PASSES) $(srcdir)/scan-types.sh stmp-int-hdrs
if [ -d $(SYSTEM_HEADER_DIR) ]; \
then \
CC="$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(ALL_CPPFLAGS) -I. -I$(srcdir) -isystem include -isystem ${SYSTEM_HEADER_DIR}"; \
export CC; \
$(SHELL) $(srcdir)/scan-types.sh "$(srcdir)" >tmp-deduced.h; \
mv tmp-deduced.h deduced.h; \
else \
$(STAMP) deduced.h; \
fi
GEN_PROTOS_OBJS = gen-protos.o scan.o
gen-protos$(build_exeext): $(GEN_PROTOS_OBJS)
${HOST_CC} $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ \
$(GEN_PROTOS_OBJS) $(HOST_LIBS)
gen-protos.o: gen-protos.c scan.h $(HCONFIG_H) $(SYSTEM_H)
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/gen-protos.c $(OUTPUT_OPTION)
scan.o: scan.c scan.h $(HCONFIG_H) $(SYSTEM_H)
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/scan.c $(OUTPUT_OPTION)
xsys-protos.h: $(GCC_PASSES) $(srcdir)/sys-protos.h deduced.h gen-protos$(build_exeext) Makefile
sed -e s/TARGET_GETGROUPS_T/$(TARGET_GETGROUPS_T)/ \
deduced.h $(srcdir)/sys-protos.h > tmp-fixtmp.c
mv tmp-fixtmp.c fixtmp.c
# APPLE LOCAL cpp-precomp
# stop the 100's of spurious errors due to cpp-precomp ilr
$(GCC_FOR_TARGET) fixtmp.c -w -U__SIZE_TYPE__ -U__PTRDIFF_TYPE__ -U__WCHAR_TYPE__ -E -no-cpp-precomp \
| sed -e 's/ / /g' -e 's/ *(/ (/g' -e 's/ [ ]*/ /g' -e 's/( )/()/' \
| $(RUN_GEN) ./gen-protos >xsys-protos.hT
mv xsys-protos.hT xsys-protos.h
rm -rf fixtmp.c
# This is nominally a 'build' program, but it's run only when host==build,
# so we can (indeed, must) use $(LIBDEPS) and $(LIBS).
# APPLE LOCAL PFE
# APPLE LOCAL indexing
fix-header$(build_exeext): fix-header.o scan-decls.o scan.o xsys-protos.h \
$(PFE_STUB_OBJS) genindex.o \
$(LIBDEPS) libcpp.a
$(HOST_CC) $(HOST_CFLAGS) $(HOST_LDFLAGS) -o $@ fix-header.o \
$(PFE_STUB_OBJS) genindex.o \
scan-decls.o scan.o libcpp.a $(LIBS)
fix-header.o: fix-header.c $(OBSTACK_H) scan.h \
xsys-protos.h $(HCONFIG_H) $(SYSTEM_H) $(CPPLIB_H)
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/fix-header.c $(OUTPUT_OPTION)
scan-decls.o: scan-decls.c scan.h $(CPPLIB_H) $(HCONFIG_H) $(SYSTEM_H)
$(HOST_CC) -c $(HOST_CFLAGS) $(HOST_CPPFLAGS) $(INCLUDES) $(srcdir)/scan-decls.c $(OUTPUT_OPTION)
# stmp-fixproto depends on this, not on fix-header directly.
# The idea is to make sure fix-header gets built,
# but not rerun fixproto after each stage
# just because fix-header's mtime has changed.
fixhdr.ready: fix-header$(build_exeext)
-if [ -f fixhdr.ready ] ; then \
true; \
else \
$(STAMP) fixhdr.ready; \
fi
# stmp-int-headers is to make sure fixincludes has already finished.
# The if statement is so that we don't run fixproto a second time
# if it has already been run on the files in `include'.
stmp-fixproto: fixhdr.ready fixproto stmp-int-hdrs
if [ -f include/fixed ] ; then true; \
else \
: This line works around a 'make' bug in BSDI 1.1.; \
FIXPROTO_DEFINES="$(FIXPROTO_DEFINES)"; export FIXPROTO_DEFINES; \
mkinstalldirs="$(SHELL) $(srcdir)/mkinstalldirs"; \
export mkinstalldirs; \
if [ -d $(SYSTEM_HEADER_DIR) ] ; then \
$(SHELL) ${srcdir}/fixproto include include $(SYSTEM_HEADER_DIR); \
if [ $$? -eq 0 ] ; then true ; else exit 1 ; fi ; \
else true; fi; \
$(STAMP) include/fixed; \
fi
$(STAMP) stmp-fixproto
#\f
# Remake the info files.
docdir = $(srcdir)/doc
doc: $(BUILD_INFO) $(GENERATED_MANPAGES) gccbug
info: $(docobjdir)/cpp.info $(docobjdir)/gcc.info $(docobjdir)/gccint.info $(docobjdir)/gccinstall.info lang.info $(docobjdir)/cppinternals.info
TEXI_CPP_FILES = $(docdir)/cpp.texi $(docdir)/include/fdl.texi \
$(docdir)/cppenv.texi $(docdir)/cppopts.texi
TEXI_GCC_FILES = $(docdir)/gcc.texi $(docdir)/include/gcc-common.texi \
$(docdir)/frontends.texi $(docdir)/standards.texi \
$(docdir)/invoke.texi $(docdir)/extend.texi $(docdir)/md.texi \
$(docdir)/objc.texi $(docdir)/gcov.texi $(docdir)/trouble.texi \
$(docdir)/bugreport.texi $(docdir)/service.texi \
$(docdir)/contribute.texi $(docdir)/vms.texi $(docdir)/compat.texi \
$(docdir)/include/funding.texi $(docdir)/gnu.texi \
$(docdir)/include/gpl.texi $(docdir)/include/fdl.texi \
$(docdir)/contrib.texi $(docdir)/cppenv.texi $(docdir)/cppopts.texi
TEXI_GCCINT_FILES = $(docdir)/gccint.texi \
$(docdir)/include/gcc-common.texi $(docdir)/contribute.texi \
$(docdir)/makefile.texi $(docdir)/configterms.texi \
$(docdir)/portability.texi $(docdir)/interface.texi \
$(docdir)/passes.texi $(docdir)/c-tree.texi \
$(docdir)/rtl.texi $(docdir)/md.texi $(docdir)/tm.texi \
$(docdir)/hostconfig.texi $(docdir)/fragments.texi \
$(docdir)/configfiles.texi $(docdir)/collect2.texi \
$(docdir)/headerdirs.texi $(docdir)/include/funding.texi \
$(docdir)/gnu.texi $(docdir)/include/gpl.texi \
$(docdir)/include/fdl.texi $(docdir)/contrib.texi \
$(docdir)/languages.texi $(docdir)/sourcebuild.texi \
$(docdir)/gty.texi
TEXI_GCCINSTALL_FILES = $(docdir)/install.texi $(docdir)/install-old.texi \
$(docdir)/include/fdl.texi
TEXI_CPPINT_FILES = $(docdir)/cppinternals.texi
<<<<<<< Makefile.in
$(docdir)/cpp.info: $(TEXI_CPP_FILES)
cd $(srcdir) && $(MAKEINFO) $(MAKEINFOFLAGS) -I doc -I doc/include -o doc/cpp.info doc/cpp.texi
$(docdir)/gcc.info: $(TEXI_GCC_FILES)
cd $(srcdir) && $(MAKEINFO) $(MAKEINFOFLAGS) -I doc -I doc/include -o doc/gcc.info doc/gcc.texi
=======
>>>>>>> 1.135
<<<<<<< Makefile.in
$(docdir)/gccint.info: $(TEXI_GCCINT_FILES)
cd $(srcdir) && $(MAKEINFO) $(MAKEINFOFLAGS) -I doc -I doc/include -o doc/gccint.info doc/gccint.texi
=======
$(docobjdir)/cpp.info: $(TEXI_CPP_FILES)
$(MAKEINFO) $(MAKEINFOFLAGS) -I $(docdir) -I $(docdir)/include \
-o $@ $(docdir)/cpp.texi
$(docobjdir)/gcc.info: $(TEXI_GCC_FILES)
$(MAKEINFO) $(MAKEINFOFLAGS) -I $(docdir) -I $(docdir)/include \
-o $@ $(docdir)/gcc.texi
$(docobjdir)/gccint.info: $(TEXI_GCCINT_FILES)
$(MAKEINFO) $(MAKEINFOFLAGS) -I $(docdir) -I $(docdir)/include \
-o $@ $(docdir)/gccint.texi
$(docobjdir)/gccinstall.info: $(TEXI_GCCINSTALL_FILES)
$(MAKEINFO) $(MAKEINFOFLAGS) -I $(docdir) -I $(docdir)/include \
-o $@ $(docdir)/install.texi
$(docobjdir)/cppinternals.info: $(TEXI_CPPINT_FILES)
$(MAKEINFO) $(MAKEINFOFLAGS) -I $(docdir) -I $(docdir)/include \
-o $@ $(docdir)/cppinternals.texi
>>>>>>> 1.135
<<<<<<< Makefile.in
$(docdir)/gccinstall.info: $(TEXI_GCCINSTALL_FILES)
cd $(srcdir) && $(MAKEINFO) $(MAKEINFOFLAGS) -I doc -I doc/include -o doc/gccinstall.info doc/install.texi
$(docdir)/cppinternals.info: $(TEXI_CPPINT_FILES)
cd $(srcdir) && $(MAKEINFO) $(MAKEINFOFLAGS) -I doc -I doc/include -o doc/cppinternals.info \
doc/cppinternals.texi
=======
>>>>>>> 1.135
dvi: gcc.dvi gccint.dvi gccinstall.dvi cpp.dvi lang.dvi cppinternals.dvi
# This works with GNU Make's default rule.
cpp.dvi: $(TEXI_CPP_FILES)
$(TEXI2DVI) -I $(docdir) -I $(docdir)/include $(docdir)/cpp.texi
gcc.dvi: $(TEXI_GCC_FILES)
$(TEXI2DVI) -I $(docdir) -I $(docdir)/include $(docdir)/gcc.texi
gccint.dvi: $(TEXI_GCCINT_FILES)
$(TEXI2DVI) -I $(docdir) -I $(docdir)/include $(docdir)/gccint.texi
gccinstall.dvi: $(TEXI_GCCINSTALL_FILES)
s=`cd $(srcdir); ${PWD}`; export s; \
$(TEXI2DVI) -I $$s/doc -I $$s/doc/include -o $@ $$s/doc/install.texi
cppinternals.dvi: $(TEXI_CPPINT_FILES)
$(TEXI2DVI) -I $(docdir) -I $(docdir)/include $(docdir)/cppinternals.texi
generated-manpages: $(docobjdir)/gcov.1 $(docobjdir)/cpp.1 $(docobjdir)/gcc.1 \
$(docobjdir)/gfdl.7 $(docobjdir)/gpl.7 $(docobjdir)/fsf-funding.7 \
lang.generated-manpages
$(docobjdir)/gcov.1: $(docobjdir)/gcov.texi
$(STAMP) $(docobjdir)/gcov.1
-$(TEXI2POD) $(docobjdir)/gcov.texi > gcov.pod
-($(POD2MAN) --section=1 gcov.pod > $(docobjdir)/gcov.1.T$$$$ && \
mv -f $(docobjdir)/gcov.1.T$$$$ $(docobjdir)/gcov.1) || \
(rm -f $(docobjdir)/gcov.1.T$$$$ && exit 1)
-rm -f gcov.pod
$(docobjdir)/cpp.1: $(docobjdir)/cpp.texi $(docobjdir)/cppenv.texi \
$(docobjdir)/cppopts.texi
$(STAMP) $(docobjdir)/cpp.1
-$(TEXI2POD) $(docobjdir)/cpp.texi > cpp.pod
-($(POD2MAN) --section=1 cpp.pod > $(docobjdir)/cpp.1.T$$$$ && \
mv -f $(docobjdir)/cpp.1.T$$$$ $(docobjdir)/cpp.1) || \
(rm -f $(docobjdir)/cpp.1.T$$$$ && exit 1)
-rm -f cpp.pod
$(docobjdir)/gcc.1: $(docobjdir)/invoke.texi $(docobjdir)/cppenv.texi \
$(docobjdir)/cppopts.texi
$(STAMP) $(docobjdir)/gcc.1
-$(TEXI2POD) $(docobjdir)/invoke.texi > gcc.pod
-($(POD2MAN) --section=1 gcc.pod > $(docobjdir)/gcc.1.T$$$$ && \
mv -f $(docobjdir)/gcc.1.T$$$$ $(docobjdir)/gcc.1) || \
(rm -f $(docobjdir)/gcc.1.T$$$$ && exit 1)
-rm -f gcc.pod
$(docobjdir)/gfdl.7: $(docobjdir)/include/fdl.texi
$(STAMP) $(docobjdir)/gfdl.7
-$(TEXI2POD) $(docobjdir)/include/fdl.texi > gfdl.pod
-($(POD2MAN) --section=7 gfdl.pod > $(docobjdir)/gfdl.7.T$$$$ && \
mv -f $(docobjdir)/gfdl.7.T$$$$ $(docobjdir)/gfdl.7) || \
(rm -f $(docobjdir)/gfdl.7.T$$$$ && exit 1)
-rm -f gfdl.pod
$(docobjdir)/gpl.7: $(docobjdir)/include/gpl.texi
$(STAMP) $(docobjdir)/gpl.7
-$(TEXI2POD) $(docobjdir)/include/gpl.texi > gpl.pod
-($(POD2MAN) --section=7 gpl.pod > $(docobjdir)/gpl.7.T$$$$ && \
mv -f $(docobjdir)/gpl.7.T$$$$ $(docobjdir)/gpl.7) || \
(rm -f $(docobjdir)/gpl.7.T$$$$ && exit 1)
-rm -f gpl.pod
$(docobjdir)/fsf-funding.7: $(docobjdir)/include/funding.texi
$(STAMP) $(docobjdir)/fsf-funding.7
-$(TEXI2POD) $(docobjdir)/include/funding.texi > fsf-funding.pod
-($(POD2MAN) --section=7 fsf-funding.pod \
> $(docobjdir)/fsf-funding.7.T$$$$ && \
mv -f $(docobjdir)/fsf-funding.7.T$$$$ $(docobjdir)/fsf-funding.7) || \
(rm -f $(docobjdir)/fsf-funding.7.T$$$$ && exit 1)
-rm -f fsf-funding.pod
#\f
# Deletion of files made during compilation.
# There are four levels of this:
# `mostlyclean', `clean', `distclean' and `maintainer-clean'.
# `mostlyclean' is useful while working on a particular type of machine.
# It deletes most, but not all, of the files made by compilation.
# It does not delete libgcc.a or its parts, so it won't have to be recompiled.
# `clean' deletes everything made by running `make all'.
# `distclean' also deletes the files made by config.
# `maintainer-clean' also deletes everything that could be regenerated
# automatically, except for `configure'.
# We remove as much from the language subdirectories as we can
# (less duplicated code).
INTL_MOSTLYCLEAN = intl.mostlyclean
mostlyclean: $(INTL_MOSTLYCLEAN) lang.mostlyclean
-rm -f $(STAGESTUFF)
-rm -f *$(coverageexts)
-rm -rf libgcc
# Delete the temporary source copies for cross compilation.
-rm -f $(BUILD_PREFIX_1)rtl.c $(BUILD_PREFIX_1)print-rtl.c
-rm -f $(BUILD_PREFIX_1)bitmap.c $(BUILD_PREFIX_1)errors.c
-rm -f $(BUILD_PREFIX_1)ggc-none.c
# Delete the temp files made in the course of building libgcc.a.
-rm -f xlimits.h
# Delete other built files.
-rm -f xsys-protos.hT
-rm -f specs.h options.h gencheck.h
# Delete the stamp and temporary files.
-rm -f s-* tmp-* stamp-* stmp-*
-rm -f */stamp-* */tmp-*
# Delete debugging dump files.
-rm -f *.[0-9][0-9].* */*.[0-9][0-9].*
# Delete some files made during installation.
-rm -f specs SYSCALLS.c.X SYSCALLS.c
-rm -f collect collect2 mips-tfile mips-tdump
# Delete files generated for fixproto
-rm -rf fix-header$(build_exeext) xsys-protos.h deduced.h tmp-deduced.h \
gen-protos$(build_exeext) fixproto.list fixtmp.* fixhdr.ready
# Delete files generated for fixincl
-rm -rf fixincl fixinc.sh specs.ready
(cd fixinc && $(MAKE) clean)
# Delete unwanted output files from TeX.
-rm -f *.toc *.log *.vr *.fn *.cp *.tp *.ky *.pg
-rm -f */*.toc */*.log */*.vr */*.fn */*.cp */*.tp */*.ky */*.pg
# Delete sorted indices we don't actually use.
-rm -f gcc.vrs gcc.kys gcc.tps gcc.pgs gcc.fns
# Delete core dumps.
-rm -f core */core
# Delete file generated for gengtype.c
-rm -f gtyp-gen.h
# Delete files generated by gengtype.c
-rm -f gtype-*
-rm -f gt-*
# Delete all files made by compilation
# that don't exist in the distribution.
INTL_CLEAN = intl.clean
clean: mostlyclean $(INTL_CLEAN) lang.clean
-rm -f libgcc.a libgcc_eh.a libgcc_s$(SHLIB_EXT) libgcc_s$(SHLIB_EXT).1
-rm -f config.h tconfig.h hconfig.h tm_p.h
-rm -f cs-*
-rm -rf libgcc
-rm -f *.dvi
-rm -f */*.dvi
# Delete the include directory.
-rm -rf include
# Delete files used by the "multilib" facility (including libgcc subdirs).
-rm -f multilib.h tmpmultilib*
-if [ "x$(MULTILIB_DIRNAMES)" != x ] ; then \
rm -rf $(MULTILIB_DIRNAMES); \
else if [ "x$(MULTILIB_OPTIONS)" != x ] ; then \
rm -rf `echo $(MULTILIB_OPTIONS) | sed -e 's/\// /g'`; \
fi ; fi
-rm -fr stage1 stage2 stage3 stage4
# Delete stamps of bootstrap stages
-rm -f stage?_*
-rm -f clean?_*
-rm -f stage_last
# Delete all files that users would normally create
# while building and installing GCC.
INTL_DISTCLEAN = intl.distclean
distclean: clean $(INTL_DISTCLEAN) lang.distclean
-rm -f auto-host.h auto-build.h
-rm -f cstamp-h
-rm -f config.status config.run config.cache config.bak
-rm -f Make-lang Make-hooks Make-host Make-target
-rm -f Makefile *.oaux
-rm -f gthr-default.h
-rm -f */stage1 */stage2 */stage3 */stage4 */include
-rm -f c-parse.output
-rm -f *.asm
-rm -f site.exp site.bak testsuite/site.exp testsuite/site.bak
-rm -f testsuite/*.log testsuite/*.sum
-cd testsuite && rm -f x *.x *.x? *.exe *.rpo *.o *.s *.S *.c
-cd testsuite && rm -f *.out *.gcov *.bb *.bbg
-rm -rf ${QMTEST_DIR} stamp-qmtest
-rm -f intl/libintl.h libintl.h
-rm -f cxxmain.c
-rm -f mklibgcc mkheaders gccbug .gdbinit configargs.h
-rm -f gcov.pod
-rm -f fixinc/Makefile
# Delete po/*.gmo only if we are not building in the source directory.
-if [ ! -f po/exgettext ]; then rm -f po/*.gmo; fi
-rmdir ada cp f java objc fixinc intl po testsuite 2>/dev/null
# Delete anything likely to be found in the source directory
# that shouldn't be in the distribution.
extraclean: distclean lang.extraclean
-rm -rf =* ./"#"* *~* config/=* config/"#"* config/*~*
-rm -f patch* *.orig *.rej config/patch* config/*.orig config/*.rej
-rm -f config/*/=* config/*/"#"* config/*/*~*
-rm -f config/*/*.orig config/*/*.rej
-rm -f *.dvi *.ps *.oaux *.d *.[zZ] *.gz
-rm -f *.tar *.xtar *diff *.diff.* *.tar.* *.xtar.* *diffs
-rm -f *lose config/*lose config/*/*lose
-rm -f *.s *.s[0-9] *.i config/ChangeLog
-rm -f y.tab.c yacc.*
-rm -f */=* */"#"* */*~*
-rm -f */patch* */*.orig */*.rej
-rm -f */*.dvi */*.oaux */*.d */*.[zZ] */*.gz
-rm -f */*.tar */*.xtar */*diff */*.diff.* */*.tar.* */*.xtar.* */*diffs
-rm -f */*lose */*.s */*.s[0-9] */*.i
# Get rid of every file that's generated from some other file, except for `configure'.
# Most of these files ARE PRESENT in the GCC distribution.
# We define INTL_DISTCLEAN, INTL_CLEAN & INTL_MOSTLYCLEAN to be empty in the
# submake, so that we don't descend into intl after its makefile has been
# removed.
maintainer-clean:
@echo 'This command is intended for maintainers to use; it'
@echo 'deletes files that may need special tools to rebuild.'
$(MAKE) INTL_DISTCLEAN= INTL_CLEAN= INTL_MOSTLYCLEAN= \
intl.maintainer-clean lang.maintainer-clean distclean
-rm -f c-parse.y c-parse.c c-parse.output TAGS
-rm -f cpp.??s cpp.*aux
-rm -f gcc.??s gcc.*aux
-rm -f $(docobjdir)/cpp.info* $(docobjdir)/gcc.info* $(docobjdir)/gccint.info*
-rm -f $(docobjdir)/cppinternals.info*
-rm -f $(docobjdir)/gcov.1 $(docobjdir)/cpp.1 $(docobjdir)/gcc.1
-rm -f $(docobjdir)/fsf-funding.7 $(docobjdir)/gfdl.7 $(docobjdir)/gpl.7
#\f
# Entry points `install' and `uninstall'.
# Also use `install-collect2' to install collect2 when the config files don't.
# Copy the compiler files into directories where they will be run.
# Install the driver last so that the window when things are
# broken is small.
install: install-common $(INSTALL_HEADERS) $(INSTALL_LIBGCC) \
install-cpp install-man install-info intl.install install-@POSUB@ \
lang.install-normal install-driver
# Handle cpp installation.
install-cpp: cpp$(exeext)
-if [ -f gcc-cross$(exeext) ] ; then \
rm -f $(bindir)/$(CPP_CROSS_NAME)$(exeext); \
$(INSTALL_PROGRAM) -m 755 cpp$(exeext) $(bindir)/$(CPP_CROSS_NAME)$(exeext); \
if [ x$(cpp_install_dir) != x ]; then \
rm -f $(prefix)/$(cpp_install_dir)/$(CPP_CROSS_NAME)$(exeext); \
$(INSTALL_PROGRAM) -m 755 cpp$(exeext) $(prefix)/$(cpp_install_dir)/$(CPP_CROSS_NAME)$(exeext); \
else true; fi; \
else \
rm -f $(bindir)/$(CPP_INSTALL_NAME)$(exeext); \
$(INSTALL_PROGRAM) -m 755 cpp$(exeext) $(bindir)/$(CPP_INSTALL_NAME)$(exeext); \
if [ x$(cpp_install_dir) != x ]; then \
rm -f $(prefix)/$(cpp_install_dir)/$(CPP_INSTALL_NAME)$(exeext); \
$(INSTALL_PROGRAM) -m 755 cpp$(exeext) $(prefix)/$(cpp_install_dir)/$(CPP_INSTALL_NAME)$(exeext); \
else true; fi; \
fi
# Create the installation directories.
installdirs:
-if [ -d $(prefix) ] ; then true ; else mkdir $(prefix) ; chmod a+rx $(prefix) ; fi
-if [ -d $(exec_prefix) ] ; then true ; else mkdir $(exec_prefix) ; chmod a+rx $(exec_prefix) ; fi
-if [ -d $(libdir) ] ; then true ; else mkdir $(libdir) ; chmod a+rx $(libdir) ; fi
-if [ -d $(libdir)/gcc-lib ] ; then true ; else mkdir $(libdir)/gcc-lib ; chmod a+rx $(libdir)/gcc-lib ; fi
# This dir isn't currently searched by cpp.
# -if [ -d $(libdir)/gcc-lib/include ] ; then true ; else mkdir $(libdir)/gcc-lib/include ; chmod a+rx $(libdir)/gcc-lib/include ; fi
-fdir= ; for dir in `echo $(libsubdir) | tr '/' ' '`; do \
fdir=$${fdir}/$${dir}; \
if [ -d $${fdir} ] ; then true ; else mkdir $${fdir}; chmod a+rx $${fdir}; fi ; \
done
-if [ -d $(bindir) ] ; then true ; else mkdir $(bindir) ; chmod a+rx $(bindir) ; fi
-if [ -d $(includedir) ] ; then true ; else mkdir $(includedir) ; chmod a+rx $(includedir) ; fi
-if [ -d $(infodir) ] ; then true ; else mkdir $(infodir) ; chmod a+rx $(infodir) ; fi
-if [ -d $(slibdir) ] ; then true ; else mkdir $(slibdir) ; chmod a+rx $(slibdir) ; fi
# We don't use mkdir -p to create the parents of man1dir,
# because some systems don't support it.
# Instead, we use this technique to create the immediate parent of man1dir.
-parent=`echo $(man1dir)|sed -e 's@/[^/]*$$@@'`; \
if [ -d $$parent ] ; then true ; else mkdir $$parent ; chmod a+rx $$parent ; fi
-if [ -d $(man1dir) ] ; then true ; else mkdir $(man1dir) ; chmod a+rx $(man1dir) ; fi
-if [ -d $(man7dir) ] ; then true ; else mkdir $(man7dir) ; chmod a+rx $(man7dir) ; fi
# Install the compiler executables built during cross compilation.
install-common: native $(EXTRA_PARTS) lang.install-common
for file in $(COMPILERS); do \
if [ -f $$file ] ; then \
rm -f $(libsubdir)/$$file; \
$(INSTALL_PROGRAM) $$file $(libsubdir)/$$file; \
else true; \
fi; \
done
for file in $(EXTRA_PASSES) $(EXTRA_PROGRAMS) $(USE_COLLECT2) ..; do \
if [ x"$$file" != x.. ]; then \
rm -f $(libsubdir)/$$file; \
$(INSTALL_PROGRAM) $$file $(libsubdir)/$$file; \
else true; fi; \
done
for file in $(EXTRA_PARTS) ..; do \
if [ x"$$file" != x.. ]; then \
rm -f $(libsubdir)/$$file; \
$(INSTALL_DATA) $$file $(libsubdir)/$$file; \
chmod a-x $(libsubdir)/$$file; \
else true; fi; \
done
# Don't mess with specs if it doesn't exist yet.
-if [ -f specs ] ; then \
rm -f $(libsubdir)/specs; \
$(INSTALL_DATA) specs $(libsubdir)/specs; \
chmod a-x $(libsubdir)/specs; \
fi
# Install protoize if it was compiled.
-if [ -f protoize$(exeext) ]; \
then \
if [ -f gcc-cross$(exeext) ] ; then \
rm -f $(bindir)/$(PROTOIZE_CROSS_NAME)$(exeext); \
$(INSTALL_PROGRAM) protoize$(exeext) $(bindir)/$(PROTOIZE_CROSS_NAME)$(exeext); \
rm -f $(bindir)/$(UNPROTOIZE_CROSS_NAME)$(exeext); \
$(INSTALL_PROGRAM) unprotoize$(exeext) $(bindir)/$(UNPROTOIZE_CROSS_NAME)$(exeext); \
else \
rm -f $(bindir)/$(PROTOIZE_INSTALL_NAME)$(exeext); \
$(INSTALL_PROGRAM) protoize$(exeext) $(bindir)/$(PROTOIZE_INSTALL_NAME)$(exeext); \
rm -f $(bindir)/$(UNPROTOIZE_INSTALL_NAME)$(exeext); \
$(INSTALL_PROGRAM) unprotoize$(exeext) $(bindir)/$(UNPROTOIZE_INSTALL_NAME)$(exeext); \
fi ; \
rm -f $(libsubdir)/SYSCALLS.c.X; \
$(INSTALL_DATA) SYSCALLS.c.X $(libsubdir)/SYSCALLS.c.X; \
chmod a-x $(libsubdir)/SYSCALLS.c.X; \
fi
# Install gcov if it was compiled.
-if [ -f gcov$(exeext) ]; \
then \
rm -f $(bindir)/gcov$(exeext); \
$(INSTALL_PROGRAM) gcov$(exeext) $(bindir)/$(GCOV_INSTALL_NAME)$(exeext); \
fi
$(INSTALL_SCRIPT) gccbug $(bindir)/$(GCCBUG_INSTALL_NAME)
# Install the driver program as $(target_alias)-gcc,
# $(target-alias)-gcc-$(version)
# and also as either gcc (if native) or $(gcc_tooldir)/bin/gcc.
install-driver: installdirs xgcc$(exeext)
-if [ -f gcc-cross$(exeext) ] ; then \
rm -f $(bindir)/$(GCC_CROSS_NAME)$(exeext); \
$(INSTALL_PROGRAM) gcc-cross$(exeext) $(bindir)/$(GCC_CROSS_NAME)$(exeext); \
rm -f $(bindir)/$(target_alias)-gcc-$(version); \
$(LN) $(bindir)/$(GCC_CROSS_NAME)$(exeext) $(bindir)/$(target_alias)-gcc-$(version) ; \
if [ -d $(gcc_tooldir)/bin/. ] ; then \
rm -f $(gcc_tooldir)/bin/gcc$(exeext); \
$(INSTALL_PROGRAM) gcc-cross$(exeext) $(gcc_tooldir)/bin/gcc$(exeext); \
else true; fi; \
else \
rm -f $(bindir)/$(GCC_INSTALL_NAME)$(exeext); \
$(INSTALL_PROGRAM) xgcc$(exeext) $(bindir)/$(GCC_INSTALL_NAME)$(exeext); \
rm -f $(bindir)/$(target_alias)-gcc-$(version); \
$(LN) $(bindir)/$(GCC_INSTALL_NAME)$(exeext) $(bindir)/$(target_alias)-gcc-$(version) ; \
rm -f $(bindir)/$(target_alias)-gcc-tmp$(exeext); \
$(LN) $(bindir)/$(GCC_INSTALL_NAME)$(exeext) $(bindir)/$(target_alias)-gcc-tmp$(exeext); \
mv $(bindir)/$(target_alias)-gcc-tmp$(exeext) $(bindir)/$(GCC_TARGET_INSTALL_NAME)$(exeext); \
fi
# Install the info files.
# $(INSTALL_DATA) might be a relative pathname, so we can't cd into srcdir
# to do the install.
install-info: doc installdirs lang.install-info
-rm -f $(infodir)/cpp.info* $(infodir)/gcc.info*
-rm -f $(infodir)/cppinternals.info* $(infodir)/gccint.info*
if [ -f $(docobjdir)/gcc.info ]; then \
for f in $(docobjdir)/cpp.info* $(docobjdir)/gcc.info* \
$(docobjdir)/cppinternals.info* $(docobjdir)/gccint.info*; do \
realfile=`echo $$f | sed -e 's|.*/\([^/]*\)$$|\1|'`; \
$(INSTALL_DATA) $$f $(infodir)/$$realfile; \
done; \
else true; fi
-if $(SHELL) -c 'install-info --version' >/dev/null 2>&1; then \
if [ -f $(infodir)/dir ] ; then \
for f in cpp.info gcc.info gccint.info cppinternals.info; do \
if [ -f $(infodir)/$$f ]; then \
install-info --dir-file=$(infodir)/dir $(infodir)/$$f; \
else true; fi; \
done; \
else true; fi; \
else true; fi;
-chmod a-x $(infodir)/cpp.info* $(infodir)/gcc.info*
-chmod a-x $(infodir)/cppinternals.info* $(infodir)/gccint.info*
# Install the man pages.
install-man: installdirs $(GENERATED_MANPAGES) lang.install-man
-if [ -f gcc-cross$(exeext) ] ; then \
rm -f $(man1dir)/$(GCC_CROSS_NAME)$(man1ext); \
$(INSTALL_DATA) $(docobjdir)/gcc.1 $(man1dir)/$(GCC_CROSS_NAME)$(man1ext); \
chmod a-x $(man1dir)/$(GCC_CROSS_NAME)$(man1ext); \
else \
rm -f $(man1dir)/$(GCC_INSTALL_NAME)$(man1ext); \
$(INSTALL_DATA) $(docobjdir)/gcc.1 $(man1dir)/$(GCC_INSTALL_NAME)$(man1ext); \
chmod a-x $(man1dir)/$(GCC_INSTALL_NAME)$(man1ext); \
fi
-rm -f $(man1dir)/cpp$(man1ext)
-$(INSTALL_DATA) $(docobjdir)/cpp.1 $(man1dir)/cpp$(man1ext)
-chmod a-x $(man1dir)/cpp$(man1ext)
-rm -f $(man1dir)/gcov$(man1ext)
-$(INSTALL_DATA) $(docobjdir)/gcov.1 $(man1dir)/gcov$(man1ext)
-chmod a-x $(man1dir)/gcov$(man1ext)
-rm -f $(man7dir)/fsf-funding$(man7ext)
-$(INSTALL_DATA) $(docobjdir)/fsf-funding.7 $(man7dir)/fsf-funding$(man7ext)
-chmod a-x $(man7dir)/fsf-funding$(man7ext)
-rm -f $(man7dir)/gfdl$(man7ext)
-$(INSTALL_DATA) $(docobjdir)/gfdl.7 $(man7dir)/gfdl$(man7ext)
-chmod a-x $(man7dir)/gfdl$(man7ext)
-rm -f $(man7dir)/gpl$(man7ext)
-$(INSTALL_DATA) $(docobjdir)/gpl.7 $(man7dir)/gpl$(man7ext)
-chmod a-x $(man7dir)/gpl$(man7ext)
# Install the library.
install-libgcc: libgcc.mk libgcc.a installdirs
$(MAKE) GCC_FOR_TARGET="$(GCC_FOR_TARGET)" \
BUILD_PREFIX="$(BUILD_PREFIX)" BUILD_PREFIX_1="$(BUILD_PREFIX_1)" \
AR_FOR_TARGET="$(AR_FOR_TARGET)" \
AR_CREATE_FOR_TARGET="$(AR_CREATE_FOR_TARGET)" \
AR_FLAGS_FOR_TARGET="$(AR_FLAGS_FOR_TARGET)" \
CFLAGS="$(CFLAGS) $(WARN_CFLAGS)" \
NM_FOR_TARGET="$(NM_FOR_TARGET)" AWK="$(AWK)" \
LIBGCC2_CFLAGS="$(LIBGCC2_CFLAGS)" \
INCLUDES="$(INCLUDES)" \
CONFIG_H="$(TCONFIG_H)" MACHMODE_H="$(MACHMODE_H)" \
LIB1ASMSRC='$(LIB1ASMSRC)' \
MAKEOVERRIDES= \
INSTALL_DATA="$(INSTALL_DATA)" \
RANLIB_FOR_TARGET="$(RANLIB_FOR_TARGET)" \
libsubdir="$(libsubdir)" \
slibdir="$(slibdir)" \
-f libgcc.mk install
# Install multiple versions of libgcc.a.
install-multilib: stmp-multilib installdirs
$(MAKE) GCC_FOR_TARGET="$(GCC_FOR_TARGET)" \
BUILD_PREFIX="$(BUILD_PREFIX)" BUILD_PREFIX_1="$(BUILD_PREFIX_1)" \
AR_FOR_TARGET="$(AR_FOR_TARGET)" \
AR_CREATE_FOR_TARGET="$(AR_CREATE_FOR_TARGET)" \
AR_FLAGS_FOR_TARGET="$(AR_FLAGS_FOR_TARGET)" \
CFLAGS="$(CFLAGS) $(WARN_CFLAGS)" \
NM_FOR_TARGET="$(NM_FOR_TARGET)" AWK="$(AWK)" \
LIBGCC2_CFLAGS="$(LIBGCC2_CFLAGS)" \
INCLUDES="$(INCLUDES)" \
CONFIG_H="$(CONFIG_H)" MACHMODE_H="$(MACHMODE_H)" \
LIB1ASMSRC='$(LIB1ASMSRC)' \
MAKEOVERRIDES= \
INSTALL_DATA="$(INSTALL_DATA)" \
RANLIB_FOR_TARGET="$(RANLIB_FOR_TARGET)" \
libsubdir="$(libsubdir)" \
slibdir="$(slibdir)" \
-f libgcc.mk install
# Install all the header files built in the include subdirectory.
install-headers: $(INSTALL_HEADERS_DIR)
# Fix symlinks to absolute paths in the installed include directory to
# point to the installed directory, not the build directory.
# Don't need to use LN_S here since we really do need ln -s and no substitutes.
-files=`cd $(libsubdir)/include; find . -type l -print 2>/dev/null`; \
if [ $$? -eq 0 ]; then \
dir=`cd include; ${PWD}`; \
for i in $$files; do \
dest=`ls -ld $(libsubdir)/include/$$i | sed -n 's/.*-> //p'`; \
if expr "$$dest" : "$$dir.*" > /dev/null; then \
rm -f $(libsubdir)/include/$$i; \
ln -s `echo $$i | sed "s|/[^/]*|/..|g" | sed 's|/..$$||'``echo "$$dest" | sed "s|$$dir||"` $(libsubdir)/include/$$i; \
fi; \
done; \
fi
# Create or recreate the gcc private include file directory.
install-include-dir: installdirs
-rm -rf $(libsubdir)/include
mkdir $(libsubdir)/include
-chmod a+rx $(libsubdir)/include
# Install the include directory using tar.
install-headers-tar: stmp-int-hdrs $(STMP_FIXPROTO) install-include-dir
# We use `pwd`/include instead of just include to problems with CDPATH
# Unless a full pathname is provided, some shells would print the new CWD,
# found in CDPATH, corrupting the output. We could just redirect the
# output of `cd', but some shells lose on redirection within `()'s
(cd `${PWD}`/include ; \
tar -cf - .; exit 0) | (cd $(libsubdir)/include; tar xpf - )
# /bin/sh on some systems returns the status of the first tar,
# and that can lose with GNU tar which always writes a full block.
# So use `exit 0' to ignore its exit status.
# Install the include directory using cpio.
install-headers-cpio: stmp-int-hdrs $(STMP_FIXPROTO) install-include-dir
# See discussion about the use of `pwd` above
cd `${PWD}`/include ; \
find . -print | cpio -pdum $(libsubdir)/include
# Install the include directory using cp.
install-headers-cp: stmp-int-hdrs $(STMP_FIXPROTO) install-include-dir
cp -p -r include $(libsubdir)
itoolsdir = $(libsubdir)/install-tools
# Don't install the headers. Instead, install appropriate scripts
# and supporting files for fixincludes to be run later.
install-mkheaders: stmp-int-hdrs $(STMP_FIXPROTO) install-include-dir \
mkheaders xlimits.h
-rm -rf $(itoolsdir)
$(SHELL) $(srcdir)/mkinstalldirs $(itoolsdir)/include
for file in $(USER_H); do \
realfile=`echo $$file | sed -e 's|.*/\([^/]*\)$$|\1|'`; \
$(INSTALL_DATA) $$file \
$(itoolsdir)/include/$$realfile ; \
done
$(INSTALL_DATA) xlimits.h $(itoolsdir)/include/limits.h
if [ x$(STMP_FIXINC) != x ] ; then \
$(INSTALL_DATA) $(srcdir)/README-fixinc \
$(itoolsdir)/include/README ; \
$(INSTALL_PROGRAM) fixinc.sh $(itoolsdir)/fixinc.sh ; \
$(INSTALL_PROGRAM) fixinc/fixincl $(itoolsdir)/fixincl ; \
$(INSTALL_DATA) $(srcdir)/gsyslimits.h $(itoolsdir)/gsyslimits.h ; \
else :; fi
if [ x$(STMP_FIXPROTO) != x ] ; then \
$(INSTALL_PROGRAM) $(srcdir)/mkinstalldirs \
$(itoolsdir)/mkinstalldirs ; \
$(INSTALL_PROGRAM) $(srcdir)/fixproto $(itoolsdir)/fixproto ; \
$(INSTALL_PROGRAM) fix-header$(build_exeext) \
$(itoolsdir)/fix-header$(build_exeext) ; \
else :; fi
$(INSTALL_PROGRAM) mkheaders $(itoolsdir)/mkheaders
echo 'SYSTEM_HEADER_DIR="$(SYSTEM_HEADER_DIR)"' \
> $(itoolsdir)/mkheaders.conf
echo 'OTHER_FIXINCLUDES_DIRS="$(OTHER_FIXINCLUDES_DIRS)"' \
>> $(itoolsdir)/mkheaders.conf
echo 'FIXPROTO_DEFINES="$(FIXPROTO_DEFINES)"' \
>> $(itoolsdir)/mkheaders.conf
echo 'STMP_FIXPROTO="$(STMP_FIXPROTO)"' >> $(itoolsdir)/mkheaders.conf
echo 'STMP_FIXINC="$(STMP_FIXINC)"' >> $(itoolsdir)/mkheaders.conf
# Use this target to install the program `collect2' under the name `collect2'.
install-collect2: collect2 installdirs
$(INSTALL_PROGRAM) collect2$(exeext) $(libsubdir)/collect2$(exeext)
# Install the driver program as $(libsubdir)/gcc for collect2.
$(INSTALL_PROGRAM) xgcc$(exeext) $(libsubdir)/gcc$(exeext)
# Cancel installation by deleting the installed files.
uninstall: intl.uninstall lang.uninstall
-rm -rf $(libsubdir)
-rm -rf $(bindir)/$(GCC_INSTALL_NAME)$(exeext)
-rm -rf $(bindir)/$(GCC_CROSS_NAME)$(exeext)
-rm -f $(bindir)/$(CPP_INSTALL_NAME)$(exeext)
-rm -f $(bindir)/$(CPP_CROSS_NAME)$(exeext)
-if [ x$(cpp_install_dir) != x ]; then \
rm -f $(prefix)/$(cpp_install_dir)/$(CPP_INSTALL_NAME)$(exeext); \
rm -f $(prefix)/$(cpp_install_dir)/$(CPP_CROSS_NAME)$(exeext); \
else true; fi
-rm -rf $(bindir)/$(PROTOIZE_INSTALL_NAME)$(exeext)
-rm -rf $(bindir)/$(PROTOIZE_CROSS_NAME)$(exeext)
-rm -rf $(bindir)/$(UNPROTOIZE_INSTALL_NAME)$(exeext)
-rm -rf $(bindir)/$(UNPROTOIZE_CROSS_NAME)$(exeext)
-rm -rf $(bindir)/$(GCOV_INSTALL_NAME)$(exeext)
-rm -rf $(man1dir)/$(GCC_INSTALL_NAME)$(man1ext)
-rm -rf $(man1dir)/$(GCC_CROSS_NAME)$(man1ext)
-rm -rf $(man1dir)/cpp$(man1ext)
-rm -rf $(man1dir)/protoize$(man1ext)
-rm -rf $(man1dir)/unprotoize$(man1ext)
-rm -f $(infodir)/cpp.info* $(infodir)/gcc.info*
-rm -f $(infodir)/cppinternals.info* $(infodir)/gccint.info*
#\f
# These targets are for the dejagnu testsuites. The file site.exp
# contains global variables that all the testsuites will use.
# Set to $(target_alias)/ for cross.
target_subdir = @target_subdir@
site.exp: ./config.status Makefile
@echo "Making a new config file..."
-@rm -f ./tmp?
@$(STAMP) site.exp
-@mv site.exp site.bak
@echo "## these variables are automatically generated by make ##" > ./tmp0
@echo "# Do not edit here. If you wish to override these values" >> ./tmp0
@echo "# add them to the last section" >> ./tmp0
@echo "set rootme \"`${PWD}`\"" >> ./tmp0
@echo "set srcdir \"`cd ${srcdir}; ${PWD}`\"" >> ./tmp0
@echo "set host_triplet $(host_canonical)" >> ./tmp0
@echo "set build_triplet $(build_canonical)" >> ./tmp0
@echo "set target_triplet $(target)" >> ./tmp0
@echo "set target_alias $(target_alias)" >> ./tmp0
# CFLAGS is set even though it's empty to show we reserve the right to set it.
@echo "set CFLAGS \"\"" >> ./tmp0
@echo "set CXXFLAGS \"-I$(objdir)/../$(target_subdir)libio -I\$$srcdir/../libg++/src -I\$$srcdir/../libio -I\$$srcdir/../libstdc++ -I\$$srcdir/../libstdc++/stl -L$(objdir)/../$(target_subdir)libg++ -L$(objdir)/../$(target_subdir)libstdc++\"" >> ./tmp0
@echo "set TESTING_IN_BUILD_TREE 1" >> ./tmp0
@echo "set HAVE_LIBSTDCXX_V3 1" >> ./tmp0
# If newlib has been configured, we need to pass -B to gcc so it can find
# newlib's crt0.o if it exists. This will cause a "path prefix not used"
# message if it doesn't, but the testsuite is supposed to ignore the message -
# it's too difficult to tell when to and when not to pass -B (not all targets
# have crt0's). We could only add the -B if ../newlib/crt0.o exists, but that
# seems like too selective a test.
# ??? Another way to solve this might be to rely on linker scripts. Then
# theoretically the -B won't be needed.
# We also need to pass -L ../ld so that the linker can find ldscripts.
@if [ -d $(objdir)/../$(target_subdir)newlib ] ; then \
echo "set newlib_cflags \"-I$(objdir)/../$(target_subdir)newlib/targ-include -I\$$srcdir/../newlib/libc/include\"" >> ./tmp0; \
echo "set newlib_ldflags \"-B$(objdir)/../$(target_subdir)newlib/\"" >> ./tmp0; \
echo "append CFLAGS \" \$$newlib_cflags\"" >> ./tmp0; \
echo "append CXXFLAGS \" \$$newlib_cflags\"" >> ./tmp0; \
echo "append LDFLAGS \" \$$newlib_ldflags\"" >> ./tmp0; \
else true; \
fi
@if [ -d $(objdir)/../ld ] ; then \
echo "append LDFLAGS \" -L$(objdir)/../ld\"" >> ./tmp0; \
else true; \
fi
echo "set tmpdir $(objdir)/testsuite" >> ./tmp0
@echo "set srcdir \"\$${srcdir}/testsuite\"" >> ./tmp0
@if [ "X$(ALT_CXX_UNDER_TEST)" != "X" ] ; then \
echo "set ALT_CXX_UNDER_TEST $(ALT_CXX_UNDER_TEST)" >> ./tmp0; \
else true; \
fi
@if [ "X$(COMPAT_OPTIONS)" != "X" ] ; then \
echo "set COMPAT_OPTIONS $(COMPAT_OPTIONS)" >> ./tmp0; \
else true; \
fi
@echo "## All variables above are generated by configure. Do Not Edit ##" >> ./tmp0
@cat ./tmp0 > site.exp
@cat site.bak | sed \
-e '1,/^## All variables above are.*##/ d' >> site.exp
-@rm -f ./tmp?
CHECK_TARGETS = check-gcc @check_languages@
check-c++ : check-g++
check-f77 : check-g77
check-java :
check: $(CHECK_TARGETS)
# The idea is to parallelize testing of multilibs, for example:
# make -j3 check-gcc//sh-hms-sim/{-m1,-m2,-m3,-m3e,-m4}/{,-nofpu}
# will run 3 concurrent sessions of check-gcc, eventually testing
# all 10 combinations. GNU make is required, as is a shell that expands
# alternations within braces.
check-gcc//% check-g++//% check-g77//% check-objc//%: site.exp
target=`echo "$@" | sed 's,//.*,,'`; \
variant=`echo "$@" | sed 's,^[^/]*//,,'`; \
vardots=`echo "$$variant" | sed 's,/,.,g'`; \
$(MAKE) TESTSUITEDIR="testsuite.$$vardots" \
RUNTESTFLAGS="--target_board=$$variant $(RUNTESTFLAGS)" \
"$$target"
TESTSUITEDIR = testsuite
$(TESTSUITEDIR)/site.exp: site.exp
test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
-rm -f $@
sed '/set tmpdir/ s|testsuite|$(TESTSUITEDIR)|' < site.exp > $@
check-g++: $(TESTSUITEDIR)/site.exp
-(rootme=`${PWD}`; export rootme; \
srcdir=`cd ${srcdir}; ${PWD}` ; export srcdir ; \
cd $(TESTSUITEDIR); \
EXPECT=${EXPECT} ; export EXPECT ; \
if [ -f $${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWD}` ; \
export TCL_LIBRARY ; fi ; \
$(RUNTEST) --tool g++ $(RUNTESTFLAGS))
check-gcc: $(TESTSUITEDIR)/site.exp
-(rootme=`${PWD}`; export rootme; \
srcdir=`cd ${srcdir}; ${PWD}` ; export srcdir ; \
cd $(TESTSUITEDIR); \
EXPECT=${EXPECT} ; export EXPECT ; \
if [ -f $${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWD}` ; \
export TCL_LIBRARY ; fi ; \
$(RUNTEST) --tool gcc $(RUNTESTFLAGS))
check-g77: $(TESTSUITEDIR)/site.exp
-(rootme=`${PWD}`; export rootme; \
srcdir=`cd ${srcdir}; ${PWD}` ; export srcdir ; \
cd $(TESTSUITEDIR); \
EXPECT=${EXPECT} ; export EXPECT ; \
if [ -f $${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWD}` ; \
export TCL_LIBRARY ; fi ; \
$(RUNTEST) --tool g77 $(RUNTESTFLAGS))
check-objc: $(TESTSUITEDIR)/site.exp
-(rootme=`${PWD}`; export rootme; \
srcdir=`cd ${srcdir}; ${PWD}` ; export srcdir ; \
cd $(TESTSUITEDIR); \
EXPECT=${EXPECT} ; export EXPECT ; \
if [ -f $${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWD}` ; \
export TCL_LIBRARY ; fi ; \
$(RUNTEST) --tool objc $(RUNTESTFLAGS))
check-objc++: $(TESTSUITEDIR)/site.exp
-(rootme=`pwd`; export rootme; \
srcdir=`cd ${srcdir}; pwd` ; export srcdir ; \
cd $(TESTSUITEDIR); \
EXPECT=${EXPECT} ; export EXPECT ; \
if [ -f $${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; pwd` ; \
export TCL_LIBRARY ; fi ; \
$(RUNTEST) --tool obj-c++ $(RUNTESTFLAGS))
check-consistency: testsuite/site.exp
-rootme=`${PWD}`; export rootme; \
srcdir=`cd ${srcdir}; ${PWD}` ; export srcdir ; \
cd testsuite; \
EXPECT=${EXPECT} ; export EXPECT ; \
if [ -f $${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWD}` ; \
export TCL_LIBRARY ; fi ; \
$(RUNTEST) --tool consistency $(RUNTESTFLAGS)
# QMTest targets
# The path to qmtest.
QMTEST_PATH=qmtest
# The flags to pass to qmtest.
QMTESTFLAGS=
# The flags to pass to "qmtest run".
QMTESTRUNFLAGS=
# The command to use to invoke qmtest.
QMTEST=${QMTEST_PATH} ${QMTESTFLAGS}
# The tests (or suites) to run.
QMTEST_GPP_TESTS=gpp
# The subdirectory of the OBJDIR that will be used to store the QMTest
# test database configuration and that will be used for temporary
# scratch space during QMTest's execution.
QMTEST_DIR=qmtestsuite
# Create the QMTest database configuration.
${QMTEST_DIR} stamp-qmtest:
debug_options=""; \
${STAMP} empty.C; \
for option in \
-gdwarf-2 -gstabs -gstabs+ -gxcoff -gxcoff+ -gcoff; do \
(./cc1plus -q $${option} empty.C 2>&1 | \
grep "unknown or unsupported -g option" > /dev/null) || \
debug_options="$${debug_options}$${option} "; done; \
${QMTEST} -D ${QMTEST_DIR} create-tdb \
-c gcc_database.GCCDatabase \
-a GCCDatabase.testsuite_root=`cd ${srcdir}/testsuite && pwd` \
-a GCCDatabase.debug_options="$${debug_options}"
rm -f empty.C empty.s
$(STAMP) stamp-qmtest
# Create the QMTest context file.
${QMTEST_DIR}/context: stamp-qmtest
echo "GCCTest.flags=-B${objdir}" >> $@
echo "GCCTest.objdir=${objdir}/.." >> $@
echo "GCCTest.host=${host_canonical}" >> $@
echo "GCCTest.target=${target}" >> $@
echo "GCCTest.gcov=${objdir}/gcov" >> $@
echo "GPPTest.gpp=${objdir}/g++" >> $@
echo "DGTest.demangler=${objdir}/c++filt" >> $@
# Run the G++ testsuite using QMTest.
qmtest-g++: ${QMTEST_DIR}/context ${QMTEST_DIR}/gpp-expected.qmr
cd ${QMTEST_DIR} && ${QMTEST} run ${QMTESTRUNFLAGS} -C context \
-o gpp.qmr -O gpp-expected.qmr \
${QMTEST_GPP_TESTS}
# Use the QMTest GUI.
qmtest-gui: ${QMTEST_DIR}/context
cd ${QMTEST_DIR} && ${QMTEST} gui -C context
# Build the set of expected G++ failures.
${QMTEST_DIR}/gpp-expected.qmr: ${QMTEST_DIR}/context
echo "Determining expected results..."
cd ${QMTEST_DIR} && ${QMTEST} run ${QMTESTRUNFLAGS} -C context \
-c "GCCTest.generate_xfails=1" -o gpp-expected.qmr \
${QMTEST_GPP_TESTS} \
> /dev/null
.PHONY: qmtest-g++
# Run Paranoia on real.c.
paranoia.o: $(srcdir)/../contrib/paranoia.cc $(CONFIG_H) $(SYSTEM_H) \
real.h $(TREE_H)
g++ -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
paranoia: paranoia.o real.o $(LIBIBERTY)
g++ -o $@ paranoia.o real.o $(LIBIBERTY)
# These exist for maintenance purposes.
# Update the tags table.
TAGS: force
(cd $(srcdir); \
mkdir tmp-tags; \
mv -f c-parse.[ch] =*.[chy] tmp-tags; \
etags *.y *.h *.c; \
mv tmp-tags/* .; \
rmdir tmp-tags)
# A list of files to be destroyed during "lean" builds.
# APPLE LOCAL PFE
VOL_FILES=`echo $(BACKEND) $(OBJS) $(C_OBJS) $(LIBCPP_OBJS) *.c *.h gen* $(PFE_STUB_OBJS)`
# Flags to pass to stage2 and later recursive makes. Note that the
# WARN_CFLAGS setting can't be to the expansion of GCC_WARN_CFLAGS in
# the context of the stage_x rule.
STAGE2_FLAGS_TO_PASS = \
ADAC="\$$(CC)" \
CFLAGS="$(BOOT_CFLAGS)" \
LDFLAGS="$(BOOT_LDFLAGS)" \
WARN_CFLAGS="\$$(GCC_WARN_CFLAGS)" \
STRICT_WARN="$(STRICT2_WARN)" \
libdir=$(libdir) \
LANGUAGES="$(LANGUAGES)" \
MAKEOVERRIDES= \
OUTPUT_OPTION="-o \$$@"
# Only build the C compiler for stage1, because that is the only one that
# we can guarantee will build with the native compiler, and also it is the
# only thing useful for building stage2. STAGE1_CFLAGS (via CFLAGS),
# MAKEINFO and MAKEINFOFLAGS are explicitly passed here to make them
# overrideable (for a bootstrap build stage1 also builds gcc.info).
stage1_build:
$(MAKE) CC="$(CC)" libdir=$(libdir) LANGUAGES="$(BOOT_LANGUAGES)" \
CFLAGS="$(STAGE1_CFLAGS)" MAKEINFO="$(MAKEINFO)" \
MAKEINFOFLAGS="$(MAKEINFOFLAGS)" COVERAGE_FLAGS=
$(STAMP) stage1_build
echo stage1_build > stage_last
stage1_copy: stage1_build
$(MAKE) stage1
$(STAMP) stage1_copy
echo stage2_build > stage_last
stage2_build: stage1_copy
$(MAKE) CC="$(STAGE_CC_WRAPPER) stage1/xgcc$(exeext) -Bstage1/ -B$(build_tooldir)/bin/" \
STAGE_PREFIX=stage1/ \
$(STAGE2_FLAGS_TO_PASS)
$(STAMP) stage2_build
echo stage2_build > stage_last
stage2_copy: stage2_build
$(MAKE) stage2
$(STAMP) stage2_copy
echo stage3_build > stage_last
stage3_build: stage2_copy
$(MAKE) CC="$(STAGE_CC_WRAPPER) stage2/xgcc$(exeext) -Bstage2/ -B$(build_tooldir)/bin/" \
STAGE_PREFIX=stage2/ \
$(STAGE2_FLAGS_TO_PASS)
$(STAMP) stage3_build
echo stage3_build > stage_last
# For bootstrap4:
stage3_copy: stage3_build
$(MAKE) stage3
$(STAMP) stage3_copy
echo stage4_build > stage_last
stage4_build: stage3_copy
$(MAKE) CC="$(STAGE_CC_WRAPPER) stage3/xgcc$(exeext) -Bstage3/ -B$(build_tooldir)/bin/" \
STAGE_PREFIX=stage3/ \
$(STAGE2_FLAGS_TO_PASS)
$(STAMP) stage4_build
echo stage4_build > stage_last
# Additional steps for *-lean targets:
clean_s1: stage1_copy
-(cd stage1 && rm -f $(VOL_FILES))
$(STAMP) clean_s1
clean_s2: stage2_copy
-rm -rf stage1
$(STAMP) clean_s2
# The various entry points for bootstrapping.
bootstrap: stage3_build
@echo
@echo Bootstrap complete - make \"quickstrap\" to redo last build,
@echo \"restage1\" through \"restage3\" to rebuild specific stages,
@echo \"restrap\" to redo the bootstrap from stage1, or
@echo \"cleanstrap\" to redo the bootstrap from scratch.
bootstrap-lean : clean_s1 clean_s2 stage3_build
@echo
@echo Bootstrap complete - make \"quickstrap\" to redo last build,
@echo or \"cleanstrap\" to redo the bootstrap from scratch.
bootstrap2: bootstrap
bootstrap2-lean : bootstrap-lean
bootstrap3 bootstrap3-lean: bootstrap
bootstrap4 bootstrap4-lean: stage4_build
unstage1 unstage2 unstage3 unstage4:
-set -vx; stage=`echo $@ | sed -e 's/un//'`; \
rm -f $$stage/as$(exeext); \
rm -f $$stage/ld$(exeext); \
rm -f $$stage/collect-ld$(exeext); \
if test -d $$stage; then \
mv $$stage/* . 2>/dev/null; \
for i in `cd $$stage; echo *` ; do \
if test -d $$stage/$$i; then \
mv $$stage/$$i/* $$i/. 2>/dev/null; \
else \
mv $$stage/$$i .; \
fi; \
done \
fi ; \
rm -f $${stage}_build $${stage}_copy ;\
echo $${stage}_build > stage_last
restage1: unstage1
$(MAKE) stage1_build
restage2: unstage2
$(MAKE) LANGUAGES="$(LANGUAGES)" stage2_build
restage3: unstage3
$(MAKE) LANGUAGES="$(LANGUAGES)" stage3_build
restage4: unstage4
$(MAKE) LANGUAGES="$(LANGUAGES)" stage4_build
bubblestrap:
if test -f stage3_build; then true; else \
echo; echo You must \"make bootstrap\" first.; \
exit 1; \
fi
for i in stage3 \
unstage1 stage1_build stage1_copy \
unstage2 stage2_build stage2_copy \
unstage3 stage3_build ; \
do \
$(MAKE) LANGUAGES="$(LANGUAGES)" $$i || exit 1 ; \
done
quickstrap:
if test -f stage_last ; then \
LAST=`cat stage_last`; rm $$LAST; $(MAKE) LANGUAGES="$(LANGUAGES)" $$LAST; \
else \
$(MAKE) stage1_build; \
fi
cleanstrap:
-$(MAKE) clean
$(MAKE) LANGUAGES="$(LANGUAGES)" bootstrap
unstrap:
-rm -rf stage[234]*
$(MAKE) unstage1
# Differs from cleanstrap in that it starts from the earlier stage1 build,
# not from scratch.
restrap:
$(MAKE) unstrap
$(MAKE) LANGUAGES="$(LANGUAGES)" bootstrap
# Compare the object files in the current directory with those in the
# stage2 directory.
# ./ avoids bug in some versions of tail.
compare compare3 compare4 compare-lean compare3-lean compare4-lean: force
-rm -f .bad_compare
case "$@" in compare | compare-lean ) stage=2 ;; * ) stage=`echo $@ | sed -e 's,^compare\([0-9][0-9]*\).*,\1,'` ;; esac; \
for file in *$(objext); do \
tail +16c ./$$file > tmp-foo1; \
tail +16c stage$$stage/$$file > tmp-foo2 \
&& (cmp tmp-foo1 tmp-foo2 > /dev/null 2>&1 || echo $$file differs >> .bad_compare) || true; \
done
case "$@" in compare | compare-lean ) stage=2 ;; * ) stage=`echo $@ | sed -e 's,^compare\([0-9][0-9]*\).*,\1,'` ;; esac; \
for dir in tmp-foo intl $(SUBDIRS); do \
if [ "`echo $$dir/*$(objext)`" != "$$dir/*$(objext)" ] ; then \
for file in $$dir/*$(objext); do \
tail +16c ./$$file > tmp-foo1; \
tail +16c stage$$stage/$$file > tmp-foo2 \
&& (cmp tmp-foo1 tmp-foo2 > /dev/null 2>&1 || echo $$file differs >> .bad_compare) || true; \
done; \
else true; fi; \
done
-rm -f tmp-foo*
case "$@" in compare | compare-lean ) stage=2 ;; * ) stage=`echo $@ | sed -e 's,^compare\([0-9][0-9]*\).*,\1,'` ;; esac; \
if [ -f .bad_compare ]; then \
echo "Bootstrap comparison failure!"; \
cat .bad_compare; \
exit 1; \
else \
case "$@" in \
*-lean ) rm -rf stage$$stage ;; \
*) ;; \
esac; true; \
fi
# Compare the object files in the current directory with those in the
# stage2 directory. Use gnu cmp (diffutils v2.4 or later) to avoid
# running tail and the overhead of twice copying each object file.
# An exit status of 1 is precisely the result we're looking for (other
# values mean other problems).
gnucompare gnucompare3 gnucompare4 gnucompare-lean gnucompare3-lean gnucompare4-lean: force
-rm -f .bad_compare
case "$@" in gnucompare | gnucompare-lean ) stage=2 ;; * ) stage=`echo $@ | sed -e 's,^gnucompare\([0-9][0-9]*\).*,\1,'` ;; esac; \
for file in *$(objext); do \
cmp --ignore-initial=16 $$file stage$$stage/$$file > /dev/null 2>&1; \
test $$? -eq 1 && echo $$file differs >> .bad_compare || true; \
done
case "$@" in gnucompare | gnucompare-lean ) stage=2 ;; * ) stage=`echo $@ | sed -e 's,^gnucompare\([0-9][0-9]*\).*,\1,'` ;; esac; \
for dir in tmp-foo intl $(SUBDIRS); do \
if [ "`echo $$dir/*$(objext)`" != "$$dir/*$(objext)" ] ; then \
for file in $$dir/*$(objext); do \
cmp --ignore-initial=16 $$file stage$$stage/$$file > /dev/null 2>&1; \
test $$? -eq 1 && echo $$file differs >> .bad_compare || true; \
done; \
else true; fi; \
done
case "$@" in gnucompare | gnucompare-lean ) stage=2 ;; * ) stage=`echo $@ | sed -e 's,^gnucompare\([0-9][0-9]*\).*,\1,'` ;; esac; \
if [ -f .bad_compare ]; then \
echo "Bootstrap comparison failure!"; \
cat .bad_compare; \
exit 1; \
else \
case "$@" in \
*-lean ) rm -rf stage$$stage ;; \
esac; true; \
fi
# Copy the object files from a particular stage into a subdirectory.
stage1-start:
-if [ -d stage1 ] ; then true ; else mkdir stage1 ; fi
$(MAKE) -f libgcc.mk libgcc-stage-start stage=stage1
-for dir in intl $(SUBDIRS) ; \
do \
if [ -d stage1/$$dir ] ; then true ; else mkdir stage1/$$dir ; fi ; \
done
-mv $(STAGESTUFF) stage1
-mv intl/*$(objext) stage1/intl
# Copy as/ld if they exist to stage dir, so that running xgcc from the stage
# dir will work properly.
-if [ -f as$(exeext) ] ; then (cd stage1 && $(LN_S) ../as$(exeext) .) ; else true ; fi
-if [ -f ld$(exeext) ] ; then (cd stage1 && $(LN_S) ../ld$(exeext) .) ; else true ; fi
-if [ -f collect-ld$(exeext) ] ; then (cd stage1 && $(LN_S) ../collect-ld$(exeext) .) ; else true ; fi
-rm -f stage1/libgcc.a stage1/libgcc_eh.a
-cp libgcc.a stage1
-$(RANLIB_FOR_TARGET) stage1/libgcc.a
-if [ -f libgcc_eh.a ] ; then cp libgcc_eh.a stage1; \
$(RANLIB_FOR_TARGET) stage1/libgcc_eh.a; \
fi
-for f in .. $(EXTRA_MULTILIB_PARTS); do if [ x$${f} != x.. ]; then \
cp stage1/$${f} . ; \
else true; \
fi; done
stage1: force stage1-start lang.stage1
stage2-start:
-if [ -d stage2 ] ; then true ; else mkdir stage2 ; fi
$(MAKE) -f libgcc.mk libgcc-stage-start stage=stage2
-for dir in intl $(SUBDIRS) ; \
do \
if [ -d stage2/$$dir ] ; then true ; else mkdir stage2/$$dir ; fi ; \
done
-mv $(STAGESTUFF) stage2
-mv intl/*$(objext) stage2/intl
# Copy as/ld if they exist to stage dir, so that running xgcc from the stage
# dir will work properly.
-if [ -f as$(exeext) ] ; then (cd stage2 && $(LN_S) ../as$(exeext) .) ; else true ; fi
-if [ -f ld$(exeext) ] ; then (cd stage2 && $(LN_S) ../ld$(exeext) .) ; else true ; fi
-if [ -f collect-ld$(exeext) ] ; then (cd stage2 && $(LN_S) ../collect-ld$(exeext) .) ; else true ; fi
-rm -f stage2/libgcc.a stage2/libgcc_eh.a
-cp libgcc.a stage2
-$(RANLIB_FOR_TARGET) stage2/libgcc.a
-if [ -f libgcc_eh.a ] ; then cp libgcc_eh.a stage2; \
$(RANLIB_FOR_TARGET) stage2/libgcc_eh.a; \
fi
-for f in .. $(EXTRA_MULTILIB_PARTS); do if [ x$${f} != x.. ]; then \
cp stage2/$${f} . ; \
else true; \
fi; done
stage2: force stage2-start lang.stage2
stage3-start:
-if [ -d stage3 ] ; then true ; else mkdir stage3 ; fi
$(MAKE) -f libgcc.mk libgcc-stage-start stage=stage3
-for dir in intl $(SUBDIRS) ; \
do \
if [ -d stage3/$$dir ] ; then true ; else mkdir stage3/$$dir ; fi ; \
done
-mv $(STAGESTUFF) stage3
-mv intl/*$(objext) stage3/intl
# Copy as/ld if they exist to stage dir, so that running xgcc from the stage
# dir will work properly.
-if [ -f as$(exeext) ] ; then (cd stage3 && $(LN_S) ../as$(exeext) .) ; else true ; fi
-if [ -f ld$(exeext) ] ; then (cd stage3 && $(LN_S) ../ld$(exeext) .) ; else true ; fi
-if [ -f collect-ld$(exeext) ] ; then (cd stage3 && $(LN_S) ../collect-ld$(exeext) .) ; else true ; fi
-rm -f stage3/libgcc.a stage3/libgcc_eh.a
-cp libgcc.a stage3
-$(RANLIB_FOR_TARGET) stage3/libgcc.a
-if [ -f libgcc_eh.a ] ; then cp libgcc_eh.a stage3; \
$(RANLIB_FOR_TARGET) stage3/libgcc_eh.a; \
fi
-for f in .. $(EXTRA_MULTILIB_PARTS); do if [ x$${f} != x.. ]; then \
cp stage3/$${f} . ; \
else true; \
fi; done
stage3: force stage3-start lang.stage3
stage4-start:
-if [ -d stage4 ] ; then true ; else mkdir stage4 ; fi
$(MAKE) -f libgcc.mk libgcc-stage-start stage=stage4
-for dir in intl $(SUBDIRS) ; \
do \
if [ -d stage4/$$dir ] ; then true ; else mkdir stage4/$$dir ; fi ; \
done
-mv $(STAGESTUFF) stage4
-mv intl/*$(objext) stage4/intl
# Copy as/ld if they exist to stage dir, so that running xgcc from the stage
# dir will work properly.
-if [ -f as$(exeext) ] ; then (cd stage4 && $(LN_S) ../as$(exeext) .) ; else true ; fi
-if [ -f ld$(exeext) ] ; then (cd stage4 && $(LN_S) ../ld$(exeext) .) ; else true ; fi
-if [ -f collect-ld$(exeext) ] ; then (cd stage4 && $(LN_S) ../collect-ld$(exeext) .) ; else true ; fi
-rm -f stage4/libgcc.a stage4/libgcc_eh.a
-cp libgcc.a stage4
-$(RANLIB_FOR_TARGET) stage4/libgcc.a
-if [ -f libgcc_eh.a ] ; then cp libgcc_eh.a stage4; \
$(RANLIB_FOR_TARGET) stage4/libgcc_eh.a; \
fi
-for f in .. $(EXTRA_MULTILIB_PARTS); do if [ x$${f} != x.. ]; then \
cp stage4/$${f} . ; \
else true; \
fi; done
stage4: force stage4-start lang.stage4
# Copy just the executable files from a particular stage into a subdirectory,
# and delete the object files. Use this if you're just verifying a version
# that is pretty sure to work, and you are short of disk space.
risky-stage1: stage1
-$(MAKE) clean
risky-stage2: stage2
-$(MAKE) clean
risky-stage3: stage3
-$(MAKE) clean
risky-stage4: stage4
-$(MAKE) clean
#In GNU Make, ignore whether `stage*' exists.
.PHONY: stage1 stage2 stage3 stage4 clean maintainer-clean TAGS bootstrap
.PHONY: risky-stage1 risky-stage2 risky-stage3 risky-stage4
force:
# Rules for generating translated message descriptions.
# Disabled by autoconf if the tools are not available.
XGETTEXT = @XGETTEXT@
GMSGFMT = @GMSGFMT@
MSGMERGE = msgmerge
PACKAGE = @PACKAGE@
CATALOGS = @CATALOGS@
.PHONY: build- install- build-po install-po update-po
# Dummy rules to deal with dependencies produced by use of
# "build-@POSUB@" and "install-@POSUB@" above, when NLS is disabled.
build-: ; @true
install-: ; @true
build-po: $(CATALOGS)
# This notation should be acceptable to all Make implementations used
# by people who are interested in updating .po files.
update-po: $(CATALOGS:.gmo=.pox)
# N.B. We do not attempt to copy these into $(srcdir). The snapshot
# script does that.
.po.gmo:
-test -d po || mkdir po
$(GMSGFMT) --statistics -o $@ $<
# The new .po has to be gone over by hand, so we deposit it into
# build/po with a different extension.
# If build/po/$(PACKAGE).pot exists, use it (it was just created),
# else use the one in srcdir.
.po.pox:
-test -d po || mkdir po
$(MSGMERGE) $< `if test -f po/$(PACKAGE).pot; \
then echo po/$(PACKAGE).pot; \
else echo $(srcdir)/po/$(PACKAGE).pot; fi` -o $@
# This rule has to look for .gmo modules in both srcdir and
# the cwd, and has to check that we actually have a catalog
# for each language, in case they weren't built or included
# with the distribution.
install-po:
$(SHELL) $(srcdir)/mkinstalldirs $(DESTDIR)$(datadir)
for cat in $(CATALOGS); do \
lang=`basename $$cat | sed 's/\.gmo$$//'`; \
if [ -f $$cat ]; then :; \
elif [ -f $(srcdir)/$$cat ]; then cat=$(srcdir)/$$cat; \
else continue; \
fi; \
dir=$(localedir)/$$lang/LC_MESSAGES; \
echo $(SHELL) $(srcdir)/mkinstalldirs $(DESTDIR)$$dir; \
$(SHELL) $(srcdir)/mkinstalldirs $(DESTDIR)$$dir || exit 1; \
echo $(INSTALL_DATA) $$cat $(DESTDIR)$$dir/$(PACKAGE).mo; \
$(INSTALL_DATA) $$cat $(DESTDIR)$$dir/$(PACKAGE).mo; \
done
# Rule for regenerating the message template (gcc.pot).
# Instead of forcing everyone to edit POTFILES.in, which proved impractical,
# this rule has no dependencies and always regenerates gcc.pot. This is
# relatively harmless since the .po files do not directly depend on it.
# Note that exgettext has an awk script embedded in it which requires a
# fairly modern (POSIX-compliant) awk.
# The .pot file is left in the build directory.
$(PACKAGE).pot: po/$(PACKAGE).pot
po/$(PACKAGE).pot: force
-test -d po || mkdir po
$(MAKE) po-generated
AWK=$(AWK) $(SHELL) $(srcdir)/po/exgettext \
$(XGETTEXT) $(PACKAGE) $(srcdir)
[-- Attachment #4: configure.in --]
[-- Type: application/octet-stream, Size: 93650 bytes --]
# configure.in for GCC
# Process this file with autoconf to generate a configuration script.
# Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
#This file is part of GCC.
#GCC is free software; you can redistribute it and/or modify it under
#the terms of the GNU General Public License as published by the Free
#Software Foundation; either version 2, or (at your option) any later
#version.
#GCC is distributed in the hope that it will be useful, but WITHOUT
#ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
#FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
#for more details.
#You should have received a copy of the GNU General Public License
#along with GCC; see the file COPYING. If not, write to the Free
#Software Foundation, 59 Temple Place - Suite 330, Boston, MA
#02111-1307, USA.
# Initialization and defaults
AC_PREREQ(2.13)
AC_INIT(tree.c)
AC_CONFIG_HEADER(auto-host.h:config.in)
remove=rm
hard_link=ln
symbolic_link='ln -s'
copy=cp
# Check for bogus environment variables.
# Test if LIBRARY_PATH contains the notation for the current directory
# since this would lead to problems installing/building glibc.
# LIBRARY_PATH contains the current directory if one of the following
# is true:
# - one of the terminals (":" and ";") is the first or last sign
# - two terminals occur directly after each other
# - the path contains an element with a dot in it
AC_MSG_CHECKING(LIBRARY_PATH variable)
changequote(,)dnl
case ${LIBRARY_PATH} in
[:\;]* | *[:\;] | *[:\;][:\;]* | *[:\;]. | .[:\;]*| . | *[:\;].[:\;]* )
library_path_setting="contains current directory"
;;
*)
library_path_setting="ok"
;;
esac
changequote([,])dnl
AC_MSG_RESULT($library_path_setting)
if test "$library_path_setting" != "ok"; then
AC_MSG_ERROR([
*** LIBRARY_PATH shouldn't contain the current directory when
*** building gcc. Please change the environment variable
*** and run configure again.])
fi
# Test if GCC_EXEC_PREFIX contains the notation for the current directory
# since this would lead to problems installing/building glibc.
# GCC_EXEC_PREFIX contains the current directory if one of the following
# is true:
# - one of the terminals (":" and ";") is the first or last sign
# - two terminals occur directly after each other
# - the path contains an element with a dot in it
AC_MSG_CHECKING(GCC_EXEC_PREFIX variable)
changequote(,)dnl
case ${GCC_EXEC_PREFIX} in
[:\;]* | *[:\;] | *[:\;][:\;]* | *[:\;]. | .[:\;]*| . | *[:\;].[:\;]* )
gcc_exec_prefix_setting="contains current directory"
;;
*)
gcc_exec_prefix_setting="ok"
;;
esac
changequote([,])dnl
AC_MSG_RESULT($gcc_exec_prefix_setting)
if test "$gcc_exec_prefix_setting" != "ok"; then
AC_MSG_ERROR([
*** GCC_EXEC_PREFIX shouldn't contain the current directory when
*** building gcc. Please change the environment variable
*** and run configure again.])
fi
# Check for additional parameters
# With GNU ld
AC_ARG_WITH(gnu-ld,
[ --with-gnu-ld arrange to work with GNU ld.],
gnu_ld_flag="$with_gnu_ld",
gnu_ld_flag=no)
# With pre-defined ld
AC_ARG_WITH(ld,
[ --with-ld arrange to use the specified ld (full pathname)],
DEFAULT_LINKER="$with_ld")
if test x"${DEFAULT_LINKER+set}" = x"set"; then
if test ! -x "$DEFAULT_LINKER"; then
AC_MSG_WARN([cannot execute: $DEFAULT_LINKER: check --with-ld or env. var. DEFAULT_LINKER])
elif $DEFAULT_LINKER -v < /dev/null 2>&1 | grep GNU > /dev/null; then
gnu_ld_flag=yes
fi
AC_DEFINE_UNQUOTED(DEFAULT_LINKER,"$DEFAULT_LINKER",
[Define to enable the use of a default linker.])
fi
# With GNU as
AC_ARG_WITH(gnu-as,
[ --with-gnu-as arrange to work with GNU as],
gas_flag="$with_gnu_as",
gas_flag=no)
AC_ARG_WITH(as,
[ --with-as arrange to use the specified as (full pathname)],
DEFAULT_ASSEMBLER="$with_as")
if test x"${DEFAULT_ASSEMBLER+set}" = x"set"; then
if test ! -x "$DEFAULT_ASSEMBLER"; then
AC_MSG_WARN([cannot execute: $DEFAULT_ASSEMBLER: check --with-as or env. var. DEFAULT_ASSEMBLER])
elif $DEFAULT_ASSEMBLER -v < /dev/null 2>&1 | grep GNU > /dev/null; then
gas_flag=yes
fi
AC_DEFINE_UNQUOTED(DEFAULT_ASSEMBLER,"$DEFAULT_ASSEMBLER",
[Define to enable the use of a default assembler.])
fi
# With stabs
AC_ARG_WITH(stabs,
[ --with-stabs arrange to use stabs instead of host debug format],
stabs="$with_stabs",
stabs=no)
# With ELF
AC_ARG_WITH(elf,
[ --with-elf arrange to use ELF instead of host debug format],
elf="$with_elf",
elf=no)
# Specify the local prefix
local_prefix=
AC_ARG_WITH(local-prefix,
[ --with-local-prefix=DIR specifies directory to put local include],
[case "${withval}" in
yes) AC_MSG_ERROR(bad value ${withval} given for local include directory prefix) ;;
no) ;;
*) local_prefix=$with_local_prefix ;;
esac])
# Default local prefix if it is empty
if test x$local_prefix = x; then
local_prefix=/usr/local
fi
# Don't set gcc_gxx_include_dir to gxx_include_dir since that's only
# passed in by the toplevel make and thus we'd get different behavior
# depending on where we built the sources.
gcc_gxx_include_dir=
# Specify the g++ header file directory
AC_ARG_WITH(gxx-include-dir,
[ --with-gxx-include-dir=DIR
specifies directory to put g++ header files],
[case "${withval}" in
yes) AC_MSG_ERROR(bad value ${withval} given for g++ include directory) ;;
no) ;;
*) gcc_gxx_include_dir=$with_gxx_include_dir ;;
esac])
if test x${gcc_gxx_include_dir} = x; then
if test x${enable_version_specific_runtime_libs} = xyes; then
gcc_gxx_include_dir='${libsubdir}/include/c++'
else
topsrcdir=${srcdir}/.. . ${srcdir}/../config.if
changequote(<<, >>)dnl
gcc_gxx_include_dir="\$(libsubdir)/\$(unlibsubdir)/..\`echo \$(exec_prefix) | sed -e 's|^\$(prefix)||' -e 's|/[^/]*|/..|g'\`/include/"${libstdcxx_incdir}
changequote([, ])dnl
fi
fi
# Determine the host, build, and target systems
AC_CANONICAL_SYSTEM
# Set program_transform_name
AC_ARG_PROGRAM
# Find the native compiler
AC_PROG_CC
AC_PROG_CC_C_O
# autoconf is lame and doesn't give us any substitution variable for this.
if eval "test \"`echo '$ac_cv_prog_cc_'${ac_cc}_c_o`\" = no"; then
NO_MINUS_C_MINUS_O=yes
else
OUTPUT_OPTION='-o $@'
fi
AC_SUBST(NO_MINUS_C_MINUS_O)
AC_SUBST(OUTPUT_OPTION)
# See if GNAT has been installed
gcc_AC_PROG_GNAT
AC_CACHE_CHECK(whether ${CC-cc} accepts -Wno-long-long,
ac_cv_prog_cc_no_long_long,
[save_CFLAGS="$CFLAGS"
CFLAGS="-Wno-long-long"
AC_TRY_COMPILE(,,ac_cv_prog_cc_no_long_long=yes,
ac_cv_prog_cc_no_long_long=no)
CFLAGS="$save_CFLAGS"])
if test x$have_gnat != xno ; then
AC_CACHE_CHECK(whether ${ADAC} accepts -Wno-long-long,
ac_cv_prog_adac_no_long_long,
[cat >conftest.adb <<EOF
procedure conftest is begin null; end conftest;
EOF
if $ADAC -Wno-long-long -c conftest.adb 1>&5 2>&5 ; then
ac_cv_prog_adac_no_long_long=yes
else
ac_cv_prog_adac_no_long_long=no
fi
rm -f conftest*])
else
ac_cv_prog_adac_no_long_long=yes
fi
strict1_warn=
if test $ac_cv_prog_cc_no_long_long = yes && \
test $ac_cv_prog_adac_no_long_long = yes ; then
strict1_warn="-pedantic -Wno-long-long"
fi
AC_SUBST(strict1_warn)
AC_PROG_CPP
AC_C_INLINE
gcc_AC_C_VOLATILE
gcc_AC_C_LONG_DOUBLE
gcc_AC_C_LONG_LONG
gcc_AC_C__BOOL
# sizeof(char) is 1 by definition.
gcc_AC_COMPILE_CHECK_SIZEOF(short)
gcc_AC_COMPILE_CHECK_SIZEOF(int)
gcc_AC_COMPILE_CHECK_SIZEOF(long)
if test $ac_cv_c_long_long = yes; then
gcc_AC_COMPILE_CHECK_SIZEOF(long long)
fi
if test $ac_cv_c___int64 = yes; then
gcc_AC_COMPILE_CHECK_SIZEOF(__int64)
fi
gcc_AC_C_CHARSET
# If the native compiler is GCC, we can enable warnings even in stage1.
# That's useful for people building cross-compilers, or just running a
# quick `make'.
warn_cflags=
if test "x$GCC" = "xyes"; then
warn_cflags='$(GCC_WARN_CFLAGS)'
fi
AC_SUBST(warn_cflags)
# Determine whether or not multilibs are enabled.
AC_ARG_ENABLE(multilib,
[ --enable-multilib enable library support for multiple ABIs],
[], [enable_multilib=yes])
AC_SUBST(enable_multilib)
# Enable expensive internal checks
AC_ARG_ENABLE(checking,
[ --enable-checking[=LIST]
enable expensive run-time checks. With LIST,
enable only specific categories of checks.
Categories are: misc,tree,rtl,rtlflag,gc,gcac;
default is misc,tree,gc,rtlflag],
[ac_checking=
ac_tree_checking=
ac_rtl_checking=
ac_rtlflag_checking=
ac_gc_checking=
ac_gc_always_collect=
case "${enableval}" in
yes) ac_checking=1 ; ac_tree_checking=1 ; ac_gc_checking=1 ;
ac_rtlflag_checking=1 ;;
no) ;;
*) IFS="${IFS= }"; ac_save_IFS="$IFS"; IFS="$IFS,"
set fnord $enableval; shift
IFS="$ac_save_IFS"
for check
do
case $check in
misc) ac_checking=1 ;;
tree) ac_tree_checking=1 ;;
rtlflag) ac_rtlflag_checking=1 ;;
rtl) ac_rtl_checking=1 ;;
gc) ac_gc_checking=1 ;;
gcac) ac_gc_always_collect=1 ;;
valgrind) ac_checking_valgrind=1 ;;
*) AC_MSG_ERROR(unknown check category $check) ;;
esac
done
;;
esac
],
# Enable some checks by default for development versions of GCC
[ac_checking=1; ac_tree_checking=1; ac_gc_checking=1; ac_rtlflag_checking=1;])
nocommon_flag=""
if test x$ac_checking != x ; then
AC_DEFINE(ENABLE_CHECKING, 1,
[Define if you want more run-time sanity checks. This one gets a grab
bag of miscellaneous but relatively cheap checks.])
nocommon_flag=-fno-common
fi
AC_SUBST(nocommon_flag)
if test x$ac_tree_checking != x ; then
AC_DEFINE(ENABLE_TREE_CHECKING, 1,
[Define if you want all operations on trees (the basic data
structure of the front ends) to be checked for dynamic type safety
at runtime. This is moderately expensive.])
fi
if test x$ac_rtl_checking != x ; then
AC_DEFINE(ENABLE_RTL_CHECKING, 1,
[Define if you want all operations on RTL (the basic data structure
of the optimizer and back end) to be checked for dynamic type safety
at runtime. This is quite expensive.])
fi
if test x$ac_rtlflag_checking != x ; then
AC_DEFINE(ENABLE_RTL_FLAG_CHECKING, 1,
[Define if you want RTL flag accesses to be checked against the RTL
codes that are supported for each access macro. This is relatively
cheap.])
fi
if test x$ac_gc_checking != x ; then
AC_DEFINE(ENABLE_GC_CHECKING, 1,
[Define if you want the garbage collector to do object poisoning and
other memory allocation checks. This is quite expensive.])
fi
if test x$ac_gc_always_collect != x ; then
AC_DEFINE(ENABLE_GC_ALWAYS_COLLECT, 1,
[Define if you want the garbage collector to operate in maximally
paranoid mode, validating the entire heap and collecting garbage at
every opportunity. This is extremely expensive.])
fi
valgrind_path_defines=
valgrind_command=
if test x$ac_checking_valgrind != x ; then
# It is certainly possible that there's valgrind but no valgrind.h.
# GCC relies on making annotations so we must have both.
AC_CHECK_HEADER(valgrind.h, have_valgrind_h=yes, have_valgrind_h=no)
AM_PATH_PROG_WITH_TEST(valgrind_path, valgrind,
[$ac_dir/$ac_word --version | grep valgrind- >/dev/null 2>&1])
if test "x$valgrind_path" = "x" || test $have_valgrind_h = no; then
AC_MSG_ERROR([*** Can't find both valgrind and valgrind.h])
fi
valgrind_path_defines=-DVALGRIND_PATH='\"'$valgrind_path'\"'
valgrind_command="$valgrind_path -q"
AC_DEFINE(ENABLE_VALGRIND_CHECKING, 1,
[Define if you want to run subprograms and generated programs
through valgrind (a memory checker). This is extremely expensive.])
fi
AC_SUBST(valgrind_path_defines)
AC_SUBST(valgrind_command)
# Enable code coverage collection
AC_ARG_ENABLE(coverage,
[ --enable-coverage[=LEVEL]
enable compiler\'s code coverage collection.
Use to measure compiler performance and locate
unused parts of the compiler. With LEVEL, specificy
optimization. Values are opt, noopt,
default is noopt],
[case "${enableval}" in
yes|noopt)
coverage_flags="-fprofile-arcs -ftest-coverage -O0"
;;
opt)
coverage_flags="-fprofile-arcs -ftest-coverage -O2"
;;
*)
AC_MSG_ERROR(unknown coverage setting $enableval)
;;
esac],
[coverage_flags=""])
AC_SUBST(coverage_flags)
AC_ARG_WITH(cpp_install_dir,
[ --with-cpp-install-dir=DIR
install the user visible C preprocessor in DIR
(relative to PREFIX) as well as PREFIX/bin],
[if test x$withval = xyes; then
AC_MSG_ERROR([option --with-cpp-install-dir requires an argument])
elif test x$withval != xno; then
cpp_install_dir=$withval
fi])
# Enable __cxa_atexit for C++.
AC_ARG_ENABLE(__cxa_atexit,
[ --enable-__cxa_atexit enable __cxa_atexit for C++],
[], [])
if test x$enable___cxa_atexit = xyes; then
AC_DEFINE(DEFAULT_USE_CXA_ATEXIT, 1,
[Define if you want to use __cxa_atexit, rather than atexit, to
register C++ destructors for local statics and global objects.
This is essential for fully standards-compliant handling of
destructors, but requires __cxa_atexit in libc.])
fi
# Enable Multibyte Characters for C/C++
AC_ARG_ENABLE(c-mbchar,
[ --enable-c-mbchar enable multibyte characters for C and C++],
if test x$enable_c_mbchar != xno; then
AC_DEFINE(MULTIBYTE_CHARS, 1,
[Define if you want the C and C++ compilers to support multibyte
character sets for source code.])
fi)
# Enable threads
# Pass with no value to take the default
# Pass with a value to specify a thread package
AC_ARG_ENABLE(threads,
[ --enable-threads enable thread usage for target GCC
--enable-threads=LIB use LIB thread package for target GCC],,
enable_threads='')
enable_threads_flag=$enable_threads
# Check if a valid thread package
case x${enable_threads_flag} in
x | xno)
# No threads
target_thread_file='single'
;;
xyes)
# default
target_thread_file=''
;;
xdecosf1 | xirix | xmach | xos2 | xposix | xpthreads | xsingle | \
xsolaris | xwin32 | xdce | xrtems| xvxworks | xaix)
target_thread_file=$enable_threads_flag
;;
*)
echo "$enable_threads is an unknown thread package" 1>&2
exit 1
;;
esac
AC_ARG_ENABLE(objc-gc,
[ --enable-objc-gc enable the use of Boehm's garbage collector with
the GNU Objective-C runtime],
if test x$enable_objc_gc = xno; then
objc_boehm_gc=''
else
objc_boehm_gc=1
fi,
objc_boehm_gc='')
AC_ARG_WITH(dwarf2,
[ --with-dwarf2 force the default debug format to be DWARF 2],
dwarf2="$with_dwarf2",
dwarf2=no)
AC_ARG_ENABLE(shared,
[ --disable-shared don't provide a shared libgcc],
[
case $enable_shared in
yes | no) ;;
*)
enable_shared=no
IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS="${IFS}:,"
for pkg in $enableval; do
if test "X$pkg" = "Xgcc" || test "X$pkg" = "Xlibgcc"; then
enable_shared=yes
fi
done
IFS="$ac_save_ifs"
;;
esac
], [enable_shared=yes])
AC_SUBST(enable_shared)
# Stage specific cflags for build.
stage1_cflags=
case $build in
vax-*-*)
if test x$GCC = xyes
then
stage1_cflags="-Wa,-J"
else
stage1_cflags="-J"
fi
;;
powerpc-*-darwin*)
# The spiffy cpp-precomp chokes on some legitimate constructs in GCC
# sources; use -no-cpp-precomp to get to GNU cpp.
# Apple's GCC has bugs in designated initializer handling, so disable
# that too.
stage1_cflags="-no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0"
;;
esac
AC_SUBST(stage1_cflags)
AC_PROG_MAKE_SET
AC_MSG_CHECKING([whether a default assembler was specified])
if test x"${DEFAULT_ASSEMBLER+set}" = x"set"; then
if test x"$gas_flag" = x"no"; then
AC_MSG_RESULT([yes ($DEFAULT_ASSEMBLER)])
else
AC_MSG_RESULT([yes ($DEFAULT_ASSEMBLER - GNU as)])
fi
else
AC_MSG_RESULT(no)
fi
AC_MSG_CHECKING([whether a default linker was specified])
if test x"${DEFAULT_LINKER+set}" = x"set"; then
if test x"$gnu_ld_flag" = x"no"; then
AC_MSG_RESULT([yes ($DEFAULT_LINKER)])
else
AC_MSG_RESULT([yes ($DEFAULT_LINKER - GNU ld)])
fi
else
AC_MSG_RESULT(no)
fi
AC_MSG_CHECKING(for GNU C library)
AC_CACHE_VAL(gcc_cv_glibc,
[AC_TRY_COMPILE(
[#include <features.h>],[
#if ! (defined __GLIBC__ || defined __GNU_LIBRARY__)
#error Not a GNU C library system
#endif],
[gcc_cv_glibc=yes],
gcc_cv_glibc=no)])
AC_MSG_RESULT($gcc_cv_glibc)
if test $gcc_cv_glibc = yes; then
AC_DEFINE(_GNU_SOURCE, 1, [Always define this when using the GNU C Library])
fi
# Find some useful tools
AC_PROG_AWK
gcc_AC_PROG_LN
gcc_AC_PROG_LN_S
AC_PROG_RANLIB
gcc_AC_PROG_INSTALL
AC_HEADER_STDC
AC_HEADER_TIME
gcc_AC_HEADER_STDBOOL
gcc_AC_HEADER_STRING
AC_HEADER_SYS_WAIT
AC_CHECK_HEADERS(limits.h stddef.h string.h strings.h stdlib.h time.h \
fcntl.h unistd.h sys/file.h sys/time.h \
sys/resource.h sys/param.h sys/times.h sys/stat.h \
direct.h malloc.h langinfo.h)
# APPLE LOCAL Mach time
AC_CHECK_HEADERS(mach/mach_time.h)
# Check for thread headers.
AC_CHECK_HEADER(thread.h, [have_thread_h=yes], [have_thread_h=])
AC_CHECK_HEADER(pthread.h, [have_pthread_h=yes], [have_pthread_h=])
# These tests can't be done till we know if we have limits.h.
gcc_AC_C_CHAR_BIT
gcc_AC_C_COMPILE_ENDIAN
gcc_AC_C_FLOAT_FORMAT
# See if we have the mktemp command.
AC_CHECK_PROG(have_mktemp_command, mktemp, yes, no)
# Do we have a single-tree copy of texinfo?
if test -f $srcdir/../texinfo/Makefile.in; then
MAKEINFO='$(objdir)/../texinfo/makeinfo/makeinfo'
gcc_cv_prog_makeinfo_modern=yes
AC_MSG_RESULT([Using makeinfo from the unified source tree.])
else
# See if makeinfo has been installed and is modern enough
# that we can use it.
gcc_AC_CHECK_PROG_VER(MAKEINFO, makeinfo, --version,
[GNU texinfo.* \([0-9][0-9.]*\)],
[4.[1-9]*])
fi
if test $gcc_cv_prog_makeinfo_modern = no; then
AC_MSG_WARN([
*** Makeinfo is missing or too old.
*** Info documentation will not be built.])
BUILD_INFO=
else
BUILD_INFO=info AC_SUBST(BUILD_INFO)
fi
# Is pod2man recent enough to regenerate manpages?
AC_MSG_CHECKING([for recent Pod::Man])
if (perl -e 'use 1.10 Pod::Man') >/dev/null 2>&1; then
AC_MSG_RESULT(yes)
GENERATED_MANPAGES=generated-manpages AC_SUBST(GENERATED_MANPAGES)
else
AC_MSG_RESULT(no)
GENERATED_MANPAGES=
fi
# How about lex?
dnl Don't use AC_PROG_LEX; we insist on flex.
dnl LEXLIB is not useful in gcc.
if test -f $srcdir/../flex/skel.c; then
FLEX='$(objdir)/../flex/flex'
else
AC_CHECK_PROG(FLEX, flex, flex, ${CONFIG_SHELL-/bin/sh} ${srcdir}/../missing flex)
fi
# Bison?
# The -L switch is so bison can find its skeleton file.
if test -f $srcdir/../bison/bison.simple; then
BISON='$(objdir)/../bison/bison -L $(srcdir)/../bison/'
else
AC_CHECK_PROG(BISON, bison, bison, ${CONFIG_SHELL-/bin/sh} ${srcdir}/../missing bison)
fi
# These libraries may be used by collect2.
# We may need a special search path to get them linked.
AC_CACHE_CHECK(for collect2 libraries, gcc_cv_collect2_libs,
[save_LIBS="$LIBS"
for libs in '' -lld -lmld \
'-L/usr/lib/cmplrs/cc2.11 -lmld' \
'-L/usr/lib/cmplrs/cc3.11 -lmld'
do
LIBS="$libs"
AC_TRY_LINK_FUNC(ldopen,
[gcc_cv_collect2_libs="$libs"; break])
done
LIBS="$save_LIBS"
test -z "$gcc_cv_collect2_libs" && gcc_cv_collect2_libs='none required'])
case $gcc_cv_collect2_libs in
"none required") ;;
*) COLLECT2_LIBS=$gcc_cv_collect2_libs ;;
esac
AC_SUBST(COLLECT2_LIBS)
# When building Ada code on Alpha, we need exc_resume which is usually in
# -lexc. So test for it.
save_LIBS="$LIBS"
LIBS=
AC_SEARCH_LIBS(exc_resume, exc)
GNAT_LIBEXC="$LIBS"
LIBS="$save_LIBS"
AC_SUBST(GNAT_LIBEXC)
# See if the stage1 system preprocessor understands the ANSI C
# preprocessor stringification operator. (Used by symcat.h.)
AC_C_STRINGIZE
# Use <inttypes.h> only if it exists,
# doesn't clash with <sys/types.h>, and declares intmax_t.
AC_MSG_CHECKING(for inttypes.h)
AC_CACHE_VAL(gcc_cv_header_inttypes_h,
[AC_TRY_COMPILE(
[#include <sys/types.h>
#include <inttypes.h>],
[intmax_t i = -1;],
[gcc_cv_header_inttypes_h=yes],
gcc_cv_header_inttypes_h=no)])
AC_MSG_RESULT($gcc_cv_header_inttypes_h)
if test $gcc_cv_header_inttypes_h = yes; then
AC_DEFINE(HAVE_INTTYPES_H, 1,
[Define if you have a working <inttypes.h> header file.])
fi
dnl Disabled until we have a complete test for buggy enum bitfields.
dnl gcc_AC_C_ENUM_BF_UNSIGNED
AC_CHECK_FUNCS(times clock dup2 kill getrlimit setrlimit atoll atoq \
sysconf strsignal putc_unlocked fputc_unlocked fputs_unlocked \
fwrite_unlocked fprintf_unlocked getrusage nl_langinfo lstat \
scandir alphasort)
AC_CHECK_TYPE(ssize_t, int)
# Try to determine the array type of the second argument of getgroups
# for the target system (int or gid_t).
AC_TYPE_GETGROUPS
if test "${target}" = "${build}"; then
TARGET_GETGROUPS_T=$ac_cv_type_getgroups
else
case "${target}" in
# This condition may need some tweaking. It should include all
# targets where the array type of the second argument of getgroups
# is int and the type of gid_t is not equivalent to int.
*-*-sunos* | *-*-ultrix*)
TARGET_GETGROUPS_T=int
;;
*)
TARGET_GETGROUPS_T=gid_t
;;
esac
fi
AC_SUBST(TARGET_GETGROUPS_T)
gcc_AC_FUNC_PRINTF_PTR
case "${host}" in
*-*-uwin*)
AC_MSG_ERROR([
*** UWIN may not be used as a host platform because
*** linking with posix.dll is not allowed by the GNU GPL])
;;
*-*-*vms*)
# Under VMS, vfork works very different than on Unix. The standard test
# won't work, and it isn't easily adaptable. It makes more sense to
# just force it.
ac_cv_func_vfork_works=yes
;;
esac
AC_FUNC_VFORK
AC_FUNC_MMAP_ANYWHERE
AC_FUNC_MMAP_FILE
AM_ICONV
# We will need to find libiberty.h and ansidecl.h
saved_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -I${srcdir} -I${srcdir}/../include"
gcc_AC_CHECK_DECLS(getenv atol sbrk abort atof getcwd getwd \
strsignal putc_unlocked fputs_unlocked fwrite_unlocked \
fprintf_unlocked strstr errno vasprintf \
malloc realloc calloc free basename getopt clock, , ,[
#include "ansidecl.h"
#include "system.h"])
gcc_AC_CHECK_DECLS(getrlimit setrlimit getrusage, , ,[
#include "ansidecl.h"
#include "system.h"
#ifdef HAVE_SYS_RESOURCE_H
#include <sys/resource.h>
#endif
])
gcc_AC_CHECK_DECLS(times, , ,[
#include "ansidecl.h"
#include "system.h"
#ifdef HAVE_SYS_TIMES_H
#include <sys/times.h>
#endif
])
# More time-related stuff.
AC_CACHE_CHECK(for struct tms, ac_cv_struct_tms, [
AC_TRY_COMPILE([
#include "ansidecl.h"
#include "system.h"
#ifdef HAVE_SYS_TIMES_H
#include <sys/times.h>
#endif
], [struct tms tms;], ac_cv_struct_tms=yes, ac_cv_struct_tms=no)])
if test $ac_cv_struct_tms = yes; then
AC_DEFINE(HAVE_STRUCT_TMS, 1,
[Define if <sys/times.h> defines struct tms.])
fi
# use gcc_cv_* here because this doesn't match the behavior of AC_CHECK_TYPE.
# revisit after autoconf 2.50.
AC_CACHE_CHECK(for clock_t, gcc_cv_type_clock_t, [
AC_TRY_COMPILE([
#include "ansidecl.h"
#include "system.h"
], [clock_t x;], gcc_cv_type_clock_t=yes, gcc_cv_type_clock_t=no)])
if test $gcc_cv_type_clock_t = yes; then
AC_DEFINE(HAVE_CLOCK_T, 1,
[Define if <time.h> defines clock_t.])
fi
AC_ARG_ENABLE(initfini-array,
[ --enable-initfini-array use .init_array/.fini_array sections],
gcc_cv_initfinit_array=$enableval, [gcc_AC_INITFINI_ARRAY])
# Restore CFLAGS from before the gcc_AC_NEED_DECLARATIONS tests.
CFLAGS="$saved_CFLAGS"
# mkdir takes a single argument on some systems.
gcc_AC_FUNC_MKDIR_TAKES_ONE_ARG
# File extensions
manext='.1'
objext='.o'
AC_SUBST(manext)
AC_SUBST(objext)
target_gtfiles=
build_xm_file=
build_xm_defines=
build_install_headers_dir=install-headers-tar
build_exeext=
host_xm_file=
host_xm_defines=
host_xmake_file=
host_truncate_target=
host_exeext=
# Decode the host machine, then the target machine.
# For the host machine, we save the xm_file variable as host_xm_file;
# then we decode the target machine and forget everything else
# that came from the host machine.
for machine in $build $host $target; do
. ${srcdir}/config.gcc
done
extra_objs="${host_extra_objs} ${extra_objs}"
# Default the target-machine variables that were not explicitly set.
if test x"$tm_file" = x
then tm_file=$cpu_type/$cpu_type.h; fi
if test x"$extra_headers" = x
then extra_headers=; fi
if test x$md_file = x
then md_file=$cpu_type/$cpu_type.md; fi
if test x$out_file = x
then out_file=$cpu_type/$cpu_type.c; fi
if test x"$tmake_file" = x
then tmake_file=$cpu_type/t-$cpu_type
fi
if test x"$dwarf2" = xyes
then tm_file="$tm_file tm-dwarf2.h"
fi
# Say what files are being used for the output code and MD file.
echo "Using \`$srcdir/config/$out_file' for machine-specific logic."
echo "Using \`$srcdir/config/$md_file' as machine description file."
# If any of the xm_file variables contain nonexistent files, warn
# about them and drop them.
bx=
for x in $build_xm_file; do
if test -f $srcdir/config/$x
then bx="$bx $x"
else AC_MSG_WARN($srcdir/config/$x does not exist.)
fi
done
build_xm_file="$bx"
hx=
for x in $host_xm_file; do
if test -f $srcdir/config/$x
then hx="$hx $x"
else AC_MSG_WARN($srcdir/config/$x does not exist.)
fi
done
host_xm_file="$hx"
tx=
for x in $xm_file; do
if test -f $srcdir/config/$x
then tx="$tx $x"
else AC_MSG_WARN($srcdir/config/$x does not exist.)
fi
done
xm_file="$tx"
count=a
for f in $tm_file; do
count=${count}x
done
if test $count = ax; then
echo "Using \`$srcdir/config/$tm_file' as target machine macro file."
else
echo "Using the following target machine macro files:"
for f in $tm_file; do
echo " $srcdir/config/$f"
done
fi
count=a
for f in $host_xm_file; do
count=${count}x
done
if test $count = a; then
:
elif test $count = ax; then
echo "Using \`$srcdir/config/$host_xm_file' as host machine macro file."
else
echo "Using the following host machine macro files:"
for f in $host_xm_file; do
echo " $srcdir/config/$f"
done
fi
if test "$host_xm_file" != "$build_xm_file"; then
count=a
for f in $build_xm_file; do
count=${count}x
done
if test $count = a; then
:
elif test $count = ax; then
echo "Using \`$srcdir/config/$build_xm_file' as build machine macro file."
else
echo "Using the following build machine macro files:"
for f in $build_xm_file; do
echo " $srcdir/config/$f"
done
fi
fi
if test x$thread_file = x; then
if test x$target_thread_file != x; then
thread_file=$target_thread_file
else
thread_file='single'
fi
fi
# Look for a file containing extra machine modes.
if test -n "$extra_modes" && test -f $srcdir/config/$extra_modes; then
extra_modes_file='$(srcdir)'/config/${extra_modes}
AC_SUBST(extra_modes_file)
AC_DEFINE_UNQUOTED(EXTRA_MODES_FILE, "$extra_modes",
[Define to the name of a file containing a list of extra machine modes
for this architecture.])
AC_DEFINE(EXTRA_CC_MODES, 1,
[Define if the target architecture needs extra machine modes to represent
the results of comparisons.])
fi
# auto-host.h is the file containing items generated by autoconf and is
# the first file included by config.h.
# If host=build, it is correct to have hconfig include auto-host.h
# as well. If host!=build, we are in error and need to do more
# work to find out the build config parameters.
# APPLE LOCAL begin fat builds ilr
host_darwin="`echo $host | sed -e 's/.*-darwin$/darwin/'`"
build_darwin="`echo $build | sed -e 's/.*-darwin$/darwin/'`"
if test x$host = x$build -o "$host_darwin" = "$build_darwin" -a "$host_darwin" = "darwin"
# APPLE LOCAL end fat builds ilr
then
build_auto=auto-host.h
FORBUILD=..
else
# We create a subdir, then run autoconf in the subdir.
# To prevent recursion we set host and build for the new
# invocation of configure to the build for this invocation
# of configure.
tempdir=build.$$
rm -rf $tempdir
mkdir $tempdir
cd $tempdir
case ${srcdir} in
/* | [A-Za-z]:[\\/]* ) realsrcdir=${srcdir};;
*) realsrcdir=../${srcdir};;
esac
saved_CFLAGS="${CFLAGS}"
CC="${CC_FOR_BUILD}" CFLAGS="${CFLAGS_FOR_BUILD}" \
${realsrcdir}/configure \
--target=$target_alias --host=$build_alias --build=$build_alias
CFLAGS="${saved_CFLAGS}"
# We just finished tests for the build machine, so rename
# the file auto-build.h in the gcc directory.
mv auto-host.h ../auto-build.h
cd ..
rm -rf $tempdir
build_auto=auto-build.h
FORBUILD=../$build_alias
fi
AC_SUBST(FORBUILD)
tm_file="${tm_file} defaults.h"
host_xm_file="auto-host.h ansidecl.h ${host_xm_file} ${tm_file}"
build_xm_file="${build_auto} ansidecl.h ${build_xm_file} ${tm_file}"
# APPLE LOCAL begin PFE
# Always require pfe-config.h as part of a build.
host_xm_file="${host_xm_file} pfe-config.h"
build_xm_file="${build_xm_file} pfe-config.h"
# APPLE LOCAL end PFE
xm_file="ansidecl.h ${xm_file} ${tm_file}"
# Truncate the target if necessary
if test x$host_truncate_target != x; then
target=`echo $target | sed -e 's/\(..............\).*/\1/'`
fi
# Get the version trigger filename from the toplevel
if test "${with_gcc_version_trigger+set}" = set; then
gcc_version_trigger=$with_gcc_version_trigger
else
gcc_version_trigger=${srcdir}/version.c
fi
changequote(,)dnl
gcc_version_full=`grep version_string ${gcc_version_trigger} | sed -e 's/.*"\([^"]*\)".*/\1/'`
gcc_version=`echo ${gcc_version_full} | sed -e 's/\([^ ]*\) .*/\1/'`
# Compile in configure arguments.
if test -f configargs.h ; then
# Being re-configured.
gcc_config_arguments=`grep configuration_arguments configargs.h | sed -e 's/.*"\([^"]*\)".*/\1/'`
gcc_config_arguments="$gcc_config_arguments : (reconfigured) $TOPLEVEL_CONFIGURE_ARGUMENTS"
else
gcc_config_arguments="$TOPLEVEL_CONFIGURE_ARGUMENTS"
fi
cat > configargs.h <<EOF
/* Generated automatically. */
static const char configuration_arguments[] = "$gcc_config_arguments";
static const char thread_model[] = "$thread_file";
EOF
changequote([,])dnl
# Internationalization
PACKAGE=gcc
VERSION="$gcc_version"
/* APPLE LOCAL begin fat builds ilr */
AC_DEFINE_UNQUOTED(VERSION, "$VERSION",
[Define to the version of the distribution.])
/* APPLE LOCAL end fat builds ilr */
AC_SUBST(PACKAGE)
AC_SUBST(VERSION)
# Enable NLS support by default
AC_ARG_ENABLE(nls,
[ --enable-nls use Native Language Support (default)],
, enable_nls=yes)
# if cross compiling, disable NLS support.
# It's not worth the trouble, at least for now.
if test "${build}" != "${host}" && test "x$enable_nls" = "xyes"; then
AC_MSG_WARN(Disabling NLS support for canadian cross compiler.)
enable_nls=no
fi
AM_GNU_GETTEXT
# Windows32 Registry support for specifying GCC installation paths.
AC_ARG_ENABLE(win32-registry,
[ --disable-win32-registry
disable lookup of installation paths in the
Registry on Windows hosts
--enable-win32-registry enable registry lookup (default)
--enable-win32-registry=KEY
use KEY instead of GCC version as the last portion
of the registry key],,)
case $host_os in
win32 | pe | cygwin* | mingw32* | uwin*)
AC_MSG_CHECKING(whether windows registry support is requested)
if test "x$enable_win32_registry" != xno; then
AC_DEFINE(ENABLE_WIN32_REGISTRY, 1,
[Define to 1 if installation paths should be looked up in Windows32
Registry. Ignored on non windows32 hosts.])
AC_MSG_RESULT(yes)
AC_SEARCH_LIBS(RegOpenKeyExA, advapi32)
else
AC_MSG_RESULT(no)
fi
# Check if user specified a different registry key.
case "x${enable_win32_registry}" in
x | xyes)
# default.
gcc_cv_win32_registry_key="$VERSION"
;;
xno)
# no registry lookup.
gcc_cv_win32_registry_key=''
;;
*)
# user-specified key.
gcc_cv_win32_registry_key="$enable_win32_registry"
;;
esac
if test "x$enable_win32_registry" != xno; then
AC_MSG_CHECKING(registry key on windows hosts)
AC_DEFINE_UNQUOTED(WIN32_REGISTRY_KEY, "$gcc_cv_win32_registry_key",
[Define to be the last portion of registry key on windows hosts.])
AC_MSG_RESULT($gcc_cv_win32_registry_key)
fi
;;
esac
# Get an absolute path to the GCC top-level source directory
holddir=`${PWDCMD-pwd}`
cd $srcdir
topdir=`${PWDCMD-pwd}`
cd $holddir
# Conditionalize the makefile for this host machine.
# Make-host contains the concatenation of all host makefile fragments
# [there can be more than one]. This file is built by configure.frag.
host_overrides=Make-host
dep_host_xmake_file=
for f in .. ${host_xmake_file}
do
if test -f ${srcdir}/config/$f
then
dep_host_xmake_file="${dep_host_xmake_file} ${srcdir}/config/$f"
fi
done
# Conditionalize the makefile for this target machine.
# Make-target contains the concatenation of all host makefile fragments
# [there can be more than one]. This file is built by configure.frag.
target_overrides=Make-target
dep_tmake_file=
for f in .. ${tmake_file}
do
if test -f ${srcdir}/config/$f
then
dep_tmake_file="${dep_tmake_file} ${srcdir}/config/$f"
fi
done
# If the host doesn't support symlinks, modify CC in
# FLAGS_TO_PASS so CC="stage1/xgcc -Bstage1/" works.
# Otherwise, we can use "CC=$(CC)".
rm -f symtest.tem
if $symbolic_link $srcdir/gcc.c symtest.tem 2>/dev/null
then
cc_set_by_configure="\$(CC)"
quoted_cc_set_by_configure="\$(CC)"
stage_prefix_set_by_configure="\$(STAGE_PREFIX)"
quoted_stage_prefix_set_by_configure="\$(STAGE_PREFIX)"
else
rm -f symtest.tem
if cp -p $srcdir/gcc.c symtest.tem 2>/dev/null
then
symbolic_link="cp -p"
else
symbolic_link="cp"
fi
cc_set_by_configure="\`case '\$(CC)' in stage*) echo '\$(CC)' | sed -e 's|stage|../stage|g';; *) echo '\$(CC)';; esac\`"
quoted_cc_set_by_configure="\\\`case '\\\$(CC)' in stage*) echo '\\\$(CC)' | sed -e 's|stage|../stage|g';; *) echo '\\\$(CC)';; esac\\\`"
stage_prefix_set_by_configure="\`case '\$(STAGE_PREFIX)' in stage*) echo '\$(STAGE_PREFIX)' | sed -e 's|stage|../stage|g';; *) echo '\$(STAGE_PREFIX)';; esac\`"
quoted_stage_prefix_set_by_configure="\\\`case '\\\$(STAGE_PREFIX)' in stage*) echo '\\\$(STAGE_PREFIX)' | sed -e 's|stage|../stage|g';; *) echo '\\\$(STAGE_PREFIX)';; esac\\\`"
fi
rm -f symtest.tem
out_object_file=`basename $out_file .c`.o
tm_file_list=
for f in $tm_file; do
case $f in
ansidecl.h )
tm_file_list="${tm_file_list} \$(srcdir)/../include/ansidecl.h" ;;
defaults.h )
tm_file_list="${tm_file_list} \$(srcdir)/$f" ;;
*) tm_file_list="${tm_file_list} \$(srcdir)/config/$f" ;;
esac
done
tm_p_file_list=
for f in $tm_p_file; do
tm_p_file_list="${tm_p_file_list} \$(srcdir)/config/$f"
done
host_xm_file_list=
for f in $host_xm_file; do
case $f in
ansidecl.h )
host_xm_file_list="${host_xm_file_list} \$(srcdir)/../include/ansidecl.h" ;;
# APPLE LOCAL begin PFE ilr
pfe-config.h )
host_xm_file_list="${host_xm_file_list} \$(srcdir)/$f \$(srcdir)/pfe-config.def" ;;
# APPLE LOCAL end PFE ilr
auto-host.h )
host_xm_file_list="${host_xm_file_list} $f" ;;
defaults.h )
host_xm_file_list="${host_xm_file_list} \$(srcdir)/$f" ;;
*) host_xm_file_list="${host_xm_file_list} \$(srcdir)/config/$f" ;;
esac
done
build_xm_file_list=
for f in $build_xm_file; do
case $f in
ansidecl.h )
build_xm_file_list="${build_xm_file_list} \$(srcdir)/../include/ansidecl.h" ;;
# APPLE LOCAL begin PFE ilr
pfe-config.h )
build_xm_file_list="${build_xm_file_list} \$(srcdir)/$f \$(srcdir)/pfe-config.def" ;;
# APPLE LOCAL end PFE ilr
auto-build.h | auto-host.h )
build_xm_file_list="${build_xm_file_list} $f" ;;
defaults.h )
host_xm_file_list="${host_xm_file_list} \$(srcdir)/$f" ;;
*) build_xm_file_list="${build_xm_file_list} \$(srcdir)/config/$f" ;;
esac
done
# Define macro CROSS_COMPILE in compilation if this is a cross-compiler.
# Also use all.cross instead of all.internal and adjust SYSTEM_HEADER_DIR.
CROSS= AC_SUBST(CROSS)
ALL=all.internal AC_SUBST(ALL)
SYSTEM_HEADER_DIR='$(NATIVE_SYSTEM_HEADER_DIR)' AC_SUBST(SYSTEM_HEADER_DIR)
if test x$host != x$target
then
CROSS="-DCROSS_COMPILE"
ALL=all.cross
SYSTEM_HEADER_DIR='$(CROSS_SYSTEM_HEADER_DIR)'
case "$host","$target" in
i?86-*-*,x86_64-*-* \
| powerpc*-*-*,powerpc64*-*-*)
CROSS="$CROSS -DNATIVE_CROSS" ;;
esac
fi
# If this is a cross-compiler that does not
# have its own set of headers then define
# inhibit_libc
# If this is using newlib, then define inhibit_libc in LIBGCC2_CFLAGS.
# This prevents libgcc2 from containing any code which requires libc
# support.
inhibit_libc=
if [test x$host != x$target] && [test x$with_headers = x]; then
inhibit_libc=-Dinhibit_libc
else
if [test x$with_newlib = xyes]; then
inhibit_libc=-Dinhibit_libc
fi
fi
AC_SUBST(inhibit_libc)
# When building gcc with a cross-compiler, we need to adjust things so
# that the generator programs are still built with the native compiler.
# Also, we cannot run fixincludes or fix-header.
# Note that the terminology here is wrong; it should be BUILD_* throughout.
# FIXME.
# These are the normal (build=host) settings:
BUILD_PREFIX= AC_SUBST(BUILD_PREFIX)
BUILD_PREFIX_1=ignore- AC_SUBST(BUILD_PREFIX_1)
HOST_CC='$(CC)' AC_SUBST(HOST_CC)
HOST_CFLAGS='$(ALL_CFLAGS)' AC_SUBST(HOST_CFLAGS)
STMP_FIXINC=stmp-fixinc AC_SUBST(STMP_FIXINC)
STMP_FIXPROTO=stmp-fixproto AC_SUBST(STMP_FIXPROTO)
# And these apply if build != host.
if test x$build != x$host
then
BUILD_PREFIX=build-
BUILD_PREFIX_1=build-
HOST_CC='$(CC_FOR_BUILD)'
HOST_CFLAGS='$(INTERNAL_CFLAGS) $(T_CFLAGS) $(CFLAGS_FOR_BUILD) $(XCFLAGS)'
STMP_FIXINC=
STMP_FIXPROTO=
fi
# Expand extra_headers to include complete path.
# This substitutes for lots of t-* files.
extra_headers_list=
if test "x$extra_headers" = x
then true
else
# Prepend ${srcdir}/config/${cpu_type}/ to every entry in extra_headers.
for file in $extra_headers;
do
extra_headers_list="${extra_headers_list} \$(srcdir)/config/${cpu_type}/${file}"
done
fi
if test x$use_collect2 = xno; then
use_collect2=
fi
# Add a definition of USE_COLLECT2 if system wants one.
if test x$use_collect2 != x
then
host_xm_defines="${host_xm_defines} USE_COLLECT2"
xm_defines="${xm_defines} USE_COLLECT2"
fi
# If we have gas in the build tree, make a link to it.
if test -f ../gas/Makefile; then
rm -f as; $symbolic_link ../gas/as-new$host_exeext as$host_exeext 2>/dev/null
fi
# If we have nm and objdump in the build tree, make a link to them.
if test -f ../binutils/Makefile; then
rm -f nm; $symbolic_link ../binutils/nm-new$host_exeext nm$host_exeext 2>/dev/null
rm -f objdump; $symbolic_link ../binutils/objdump$host_exeext objdump$host_exeext 2>/dev/null
fi
# If we have ld in the build tree, make a link to it.
if test -f ../ld/Makefile; then
rm -f collect-ld; $symbolic_link ../ld/ld-new$host_exeext collect-ld$host_exeext 2>/dev/null
fi
# Figure out what assembler we will be using.
AC_MSG_CHECKING(what assembler to use)
gcc_cv_as=
gcc_cv_gas_major_version=
gcc_cv_gas_minor_version=
gcc_cv_as_gas_srcdir=`echo $srcdir | sed -e 's,/gcc$,,'`/gas
gcc_cv_as_bfd_srcdir=`echo $srcdir | sed -e 's,/gcc$,,'`/bfd
if test -x "$DEFAULT_ASSEMBLER"; then
gcc_cv_as="$DEFAULT_ASSEMBLER"
elif test -x "$AS"; then
gcc_cv_as="$AS"
elif test -x as$host_exeext; then
# Build using assembler in the current directory.
gcc_cv_as=./as$host_exeext
elif test -f $gcc_cv_as_gas_srcdir/configure.in -a -f ../gas/Makefile; then
# Single tree build which includes gas.
for f in $gcc_cv_as_bfd_srcdir/configure $gcc_cv_as_gas_srcdir/configure $gcc_cv_as_gas_srcdir/configure.in $gcc_cv_as_gas_srcdir/Makefile.in
do
changequote(,)dnl
gcc_cv_gas_version=`grep '^VERSION=[0-9]*\.[0-9]*' $f`
changequote([,])dnl
if test x$gcc_cv_gas_version != x; then
break
fi
done
changequote(,)dnl
gcc_cv_gas_major_version=`expr "$gcc_cv_gas_version" : "VERSION=\([0-9]*\)"`
gcc_cv_gas_minor_version=`expr "$gcc_cv_gas_version" : "VERSION=[0-9]*\.\([0-9]*\)"`
gcc_cv_gas_patch_version=`expr "$gcc_cv_gas_version" : "VERSION=[0-9]*\.[0-9]*\.\([0-9]*\)"`
changequote([,])dnl
fi
if test "x$gcc_cv_as" = x; then
# Search the same directories that the installed compiler will
# search. Else we may find the wrong assembler and lose. If we
# do not find a suitable assembler binary, then try the user's
# path.
#
# Also note we have to check MD_EXEC_PREFIX before checking the
# user's path. Unfortunately, there is no good way to get at the
# value of MD_EXEC_PREFIX here. So we do a brute force search
# through all the known MD_EXEC_PREFIX values. Ugh. This needs
# to be fixed as part of the make/configure rewrite too.
if test "x$exec_prefix" = xNONE; then
if test "x$prefix" = xNONE; then
test_prefix=/usr/local
else
test_prefix=$prefix
fi
else
test_prefix=$exec_prefix
fi
# If the loop below does not find an assembler, then use whatever
# one we can find in the users's path.
# user's path.
if test "x$program_prefix" != xNONE; then
gcc_cv_as=${program_prefix}as$host_exeext
else
gcc_cv_as=`echo as | sed ${program_transform_name}`$host_exeext
fi
test_dirs="$test_prefix/lib/gcc-lib/$target_alias/$gcc_version \
$test_prefix/lib/gcc-lib/$target_alias \
/usr/lib/gcc/$target_alias/$gcc_version \
/usr/lib/gcc/$target_alias \
$test_prefix/$target_alias/bin/$target_alias/$gcc_version \
$test_prefix/$target_alias/bin"
if test x$host = x$target; then
test_dirs="$test_dirs \
/usr/libexec \
/usr/ccs/gcc \
/usr/ccs/bin \
/udk/usr/ccs/bin \
/bsd43/usr/lib/cmplrs/cc \
/usr/cross64/usr/bin \
/usr/lib/cmplrs/cc \
/sysv/usr/lib/cmplrs/cc \
/svr4/usr/lib/cmplrs/cc \
/usr/bin"
fi
for dir in $test_dirs; do
if test -x $dir/as$host_exeext; then
gcc_cv_as=$dir/as$host_exeext
break;
fi
done
fi
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x; then
AC_MSG_RESULT("newly built gas")
else
AC_MSG_RESULT($gcc_cv_as)
fi
# Figure out what linker we will be using.
AC_MSG_CHECKING(what linker to use)
gcc_cv_ld=
gcc_cv_gld_major_version=
gcc_cv_gld_minor_version=
gcc_cv_ld_gld_srcdir=`echo $srcdir | sed -e 's,/gcc$,,'`/ld
gcc_cv_ld_bfd_srcdir=`echo $srcdir | sed -e 's,/gcc$,,'`/bfd
if test -x "$DEFAULT_LINKER"; then
gcc_cv_ld="$DEFAULT_LINKER"
elif test -x "$LD"; then
gcc_cv_ld="$LD"
elif test -x ld$host_exeext; then
# Build using linker in the current directory.
gcc_cv_ld=./ld$host_exeext
elif test -f $gcc_cv_ld_gld_srcdir/configure.in -a -f ../ld/Makefile; then
# Single tree build which includes ld.
for f in $gcc_cv_ld_bfd_srcdir/configure $gcc_cv_ld_gld_srcdir/configure $gcc_cv_ld_gld_srcdir/configure.in $gcc_cv_ld_gld_srcdir/Makefile.in
do
changequote(,)dnl
gcc_cv_gld_version=`grep '^VERSION=[0-9]*\.[0-9]*' $f`
changequote([,])dnl
if test x$gcc_cv_gld_version != x; then
break
fi
done
changequote(,)dnl
gcc_cv_gld_major_version=`expr "$gcc_cv_gld_version" : "VERSION=\([0-9]*\)"`
gcc_cv_gld_minor_version=`expr "$gcc_cv_gld_version" : "VERSION=[0-9]*\.\([0-9]*\)"`
changequote([,])dnl
fi
if test "x$gcc_cv_ld" = x; then
# Search the same directories that the installed compiler will
# search. Else we may find the wrong linker and lose. If we
# do not find a suitable linker binary, then try the user's
# path.
#
# Also note we have to check MD_EXEC_PREFIX before checking the
# user's path. Unfortunately, there is no good way to get at the
# value of MD_EXEC_PREFIX here. So we do a brute force search
# through all the known MD_EXEC_PREFIX values. Ugh. This needs
# to be fixed as part of the make/configure rewrite too.
if test "x$exec_prefix" = xNONE; then
if test "x$prefix" = xNONE; then
test_prefix=/usr/local
else
test_prefix=$prefix
fi
else
test_prefix=$exec_prefix
fi
# If the loop below does not find an linker, then use whatever
# one we can find in the users's path.
# user's path.
if test "x$program_prefix" != xNONE; then
gcc_cv_ld=${program_prefix}ld$host_exeext
else
gcc_cv_ld=`echo ld | sed ${program_transform_name}`$host_exeext
fi
test_dirs="$test_prefix/lib/gcc-lib/$target_alias/$gcc_version \
$test_prefix/lib/gcc-lib/$target_alias \
/usr/lib/gcc/$target_alias/$gcc_version \
/usr/lib/gcc/$target_alias \
$test_prefix/$target_alias/bin/$target_alias/$gcc_version \
$test_prefix/$target_alias/bin"
if test x$host = x$target; then
test_dirs="$test_dirs \
/usr/libexec \
/usr/ccs/gcc \
/usr/ccs/bin \
/udk/usr/ccs/bin \
/bsd43/usr/lib/cmplrs/cc \
/usr/cross64/usr/bin \
/usr/lib/cmplrs/cc \
/sysv/usr/lib/cmplrs/cc \
/svr4/usr/lib/cmplrs/cc \
/usr/bin"
fi
for dir in $test_dirs; do
if test -x $dir/ld$host_exeext; then
gcc_cv_ld=$dir/ld$host_exeext
break;
fi
done
fi
if test x$gcc_cv_gld_major_version != x -a x$gcc_cv_gld_minor_version != x; then
AC_MSG_RESULT("newly built ld")
else
AC_MSG_RESULT($gcc_cv_ld)
fi
# Figure out what nm we will be using.
AC_MSG_CHECKING(what nm to use)
if test -x nm$host_exeext; then
gcc_cv_nm=./nm$host_exeext
elif test "x$program_prefix" != xNONE; then
gcc_cv_nm=${program_prefix}nm$host_exeext
else
gcc_cv_nm=`echo nm | sed ${program_transform_name}`$host_exeext
fi
AC_MSG_RESULT($gcc_cv_nm)
# Figure out what objdump we will be using.
AC_MSG_CHECKING(what objdump to use)
if test -x objdump$host_exeext; then
gcc_cv_objdump=./objdump$host_exeext
elif test "x$program_prefix" != xNONE; then
gcc_cv_objdump=${program_prefix}objdump$host_exeext
else
gcc_cv_objdump=`echo objdump | sed ${program_transform_name}`$host_exeext
fi
AC_MSG_RESULT($gcc_cv_objdump)
# Figure out what assembler alignment features are present.
AC_MSG_CHECKING(assembler alignment features)
gcc_cv_as_alignment_features=none
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x; then
# Gas version 2.6 and later support for .balign and .p2align.
# bytes to skip when using .p2align.
if test "$gcc_cv_gas_major_version" -eq 2 -a "$gcc_cv_gas_minor_version" -ge 6 -o "$gcc_cv_gas_major_version" -gt 2; then
gcc_cv_as_alignment_features=".balign and .p2align"
AC_DEFINE(HAVE_GAS_BALIGN_AND_P2ALIGN)
fi
# Gas version 2.8 and later support specifying the maximum
# bytes to skip when using .p2align.
if test "$gcc_cv_gas_major_version" -eq 2 -a "$gcc_cv_gas_minor_version" -ge 8 -o "$gcc_cv_gas_major_version" -gt 2; then
gcc_cv_as_alignment_features=".p2align including maximum skip"
AC_DEFINE(HAVE_GAS_MAX_SKIP_P2ALIGN)
fi
elif test x$gcc_cv_as != x; then
# Check if we have .balign and .p2align
echo ".balign 4" > conftest.s
echo ".p2align 2" >> conftest.s
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_alignment_features=".balign and .p2align"
AC_DEFINE(HAVE_GAS_BALIGN_AND_P2ALIGN)
fi
rm -f conftest.s conftest.o
# Check if specifying the maximum bytes to skip when
# using .p2align is supported.
echo ".p2align 4,,7" > conftest.s
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_alignment_features=".p2align including maximum skip"
AC_DEFINE(HAVE_GAS_MAX_SKIP_P2ALIGN)
fi
rm -f conftest.s conftest.o
fi
AC_MSG_RESULT($gcc_cv_as_alignment_features)
AC_MSG_CHECKING(assembler subsection support)
gcc_cv_as_subsections=no
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x; then
if test "$gcc_cv_gas_major_version" -eq 2 -a "$gcc_cv_gas_minor_version" -ge 9 -o "$gcc_cv_gas_major_version" -gt 2 && grep 'obj_format = elf' ../gas/Makefile > /dev/null; then
gcc_cv_as_subsections="working .subsection -1"
fi
elif test x$gcc_cv_as != x; then
# Check if we have .subsection
echo ".subsection 1" > conftest.s
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_subsections=".subsection"
if test x$gcc_cv_nm != x; then
cat > conftest.s <<EOF
conftest_label1: .word 0
.subsection -1
conftest_label2: .word 0
.previous
EOF
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1; then
$gcc_cv_nm conftest.o | grep conftest_label1 > conftest.nm1
$gcc_cv_nm conftest.o | grep conftest_label2 | sed -e 's/label2/label1/' > conftest.nm2
if cmp conftest.nm1 conftest.nm2 > /dev/null 2>&1; then
:
else
gcc_cv_as_subsections="working .subsection -1"
fi
fi
fi
fi
rm -f conftest.s conftest.o conftest.nm1 conftest.nm2
fi
if test x"$gcc_cv_as_subsections" = x"working .subsection -1"; then
AC_DEFINE(HAVE_GAS_SUBSECTION_ORDERING, 1,
[Define if your assembler supports .subsection and .subsection -1 starts
emitting at the beginning of your section.])
fi
AC_MSG_RESULT($gcc_cv_as_subsections)
AC_MSG_CHECKING(assembler weak support)
gcc_cv_as_weak=no
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x; then
if test "$gcc_cv_gas_major_version" -eq 2 -a "$gcc_cv_gas_minor_version" -ge 2 -o "$gcc_cv_gas_major_version" -gt 2; then
gcc_cv_as_weak="yes"
fi
elif test x$gcc_cv_as != x; then
# Check if we have .weak
echo " .weak foobar" > conftest.s
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_weak="yes"
fi
rm -f conftest.s conftest.o conftest.nm1 conftest.nm2
fi
if test x"$gcc_cv_as_weak" = xyes; then
AC_DEFINE(HAVE_GAS_WEAK, 1, [Define if your assembler supports .weak.])
fi
AC_MSG_RESULT($gcc_cv_as_weak)
AC_MSG_CHECKING(assembler hidden support)
gcc_cv_as_hidden=no
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x; then
if test "$gcc_cv_gas_major_version" -eq 2 \
-a "$gcc_cv_gas_minor_version" -eq 12 \
-a "$gcc_cv_gas_patch_version" -ge 1 \
-o "$gcc_cv_gas_major_version" -eq 2 \
-a "$gcc_cv_gas_minor_version" -gt 12 \
-o "$gcc_cv_gas_major_version" -gt 2 \
&& grep 'obj_format = elf' ../gas/Makefile > /dev/null; then
gcc_cv_as_hidden="yes"
fi
elif test x$gcc_cv_as != x; then
# Check if we have .hidden
echo " .hidden foobar" > conftest.s
echo "foobar:" >> conftest.s
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_hidden="yes"
fi
rm -f conftest.s conftest.o conftest.nm1 conftest.nm2
# GNU LD versions before 2.12.1 have buggy support for STV_HIDDEN.
# This is irritatingly difficult to feature test for. Look for
# the date string after the version number.
ld_ver=`$gcc_cv_ld --version 2>/dev/null | head -1`
if echo "$ld_ver" | grep GNU > /dev/null; then
changequote(,)dnl
ld_vers=`echo $ld_ver | sed -n 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*\(\|\.[0-9][0-9]*\)\)\([ ].*\|\)$,\1,p'`
ld_date=`echo $ld_ver | sed -n 's,^.*\([2-9][0-9][0-9][0-9]\)[-]*\([01][0-9]\)[-]*\([0-3][0-9]\).*$,\1\2\3,p'`
if test 0"$ld_date" -lt 20020404; then
if test -n "$ld_date"; then
# If there was date string, but was earlier than 2002-04-04, fail
gcc_cv_as_hidden="no"
elif test -z "$ld_vers"; then
# If there was no date string nor ld version number, something is wrong
gcc_cv_as_hidden="no"
else
ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'`
ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'`
ld_vers_patch=`expr "$ld_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
test -z "$ld_vers_patch" && ld_vers_patch=0
if test "$ld_vers_major" -lt 2; then
gcc_cv_as_hidden="no"
elif test "$ld_vers_major" -eq 2 -a "$ld_vers_minor" -lt 12; then
gcc_cv_as_hidden="no"
elif test "$ld_vers_major" -eq 2 -a "$ld_vers_minor" -eq 12 \
-a "$ld_vers_patch" -eq 0; then
gcc_cv_as_hidden="no"
fi
fi
fi
changequote([,])dnl
fi
fi
if test x"$gcc_cv_as_hidden" = xyes; then
AC_DEFINE(HAVE_GAS_HIDDEN, 1,
[Define if your assembler supports .hidden.])
fi
AC_MSG_RESULT($gcc_cv_as_hidden)
libgcc_visibility=$gcc_cv_as_hidden
case "$target" in
mips-sgi-irix6*o32)
if test x"$gnu_ld_flag" = x"no"; then
# Even if using gas with .hidden support, the resulting object files
# cannot be linked with the IRIX 6 O32 linker.
libgcc_visibility=no
fi
;;
esac
AC_SUBST(libgcc_visibility)
AC_MSG_CHECKING(assembler leb128 support)
gcc_cv_as_leb128=no
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x; then
if test "$gcc_cv_gas_major_version" -eq 2 -a "$gcc_cv_gas_minor_version" -ge 11 -o "$gcc_cv_gas_major_version" -gt 2 && grep 'obj_format = elf' ../gas/Makefile > /dev/null; then
gcc_cv_as_leb128="yes"
fi
elif test x$gcc_cv_as != x; then
# Check if we have .[us]leb128, and support symbol arithmetic with it.
cat > conftest.s <<EOF
.data
.uleb128 L2 - L1
L1:
.uleb128 1280
.sleb128 -1010
L2:
EOF
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_leb128="yes"
# GAS versions before 2.11 do not support uleb128,
# despite appearing to.
# ??? There exists an elf-specific test that will crash
# the assembler. Perhaps it's better to figure out whether
# arbitrary sections are supported and try the test.
as_ver=`$gcc_cv_as --version 2>/dev/null | head -1`
if echo "$as_ver" | grep GNU > /dev/null; then
changequote(,)dnl
as_ver=`echo $as_ver | sed -e 's/GNU assembler \([0-9.][0-9.]*\).*/\1/'`
as_major=`echo $as_ver | sed 's/\..*//'`
as_minor=`echo $as_ver | sed 's/[^.]*\.\([0-9]*\).*/\1/'`
changequote([,])dnl
if test $as_major -eq 2 -a $as_minor -lt 11; then
gcc_cv_as_leb128="no"
fi
fi
fi
rm -f conftest.s conftest.o conftest.nm1 conftest.nm2
fi
if test x"$gcc_cv_as_leb128" = xyes; then
AC_DEFINE(HAVE_AS_LEB128, 1,
[Define if your assembler supports .uleb128.])
fi
AC_MSG_RESULT($gcc_cv_as_leb128)
AC_MSG_CHECKING(assembler eh_frame optimization)
gcc_cv_as_eh_frame=no
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x; then
if test "$gcc_cv_gas_major_version" -eq 2 -a "$gcc_cv_gas_minor_version" -ge 12 -o "$gcc_cv_gas_major_version" -gt 2 && grep 'obj_format = elf' ../gas/Makefile > /dev/null; then
gcc_cv_as_eh_frame="yes"
fi
elif test x$gcc_cv_as != x; then
# Check if this is GAS.
as_ver=`$gcc_cv_as --version < /dev/null 2> /dev/null | head -1`
rm -f a.out 2> /dev/null
if echo "$as_ver" | grep GNU > /dev/null; then
# Versions up to and including 2.11.0 may mis-optimize
# .eh_frame data. Try something.
cat > conftest.s <<EOF
.text
.LFB1:
.4byte 0
.L1:
.4byte 0
.LFE1:
.section .eh_frame,"aw",@progbits
__FRAME_BEGIN__:
.4byte .LECIE1-.LSCIE1
.LSCIE1:
.4byte 0x0
.byte 0x1
.ascii "z\0"
.byte 0x1
.byte 0x78
.byte 0x1a
.byte 0x0
.byte 0x4
.4byte 1
.p2align 1
.LECIE1:
.LSFDE1:
.4byte .LEFDE1-.LASFDE1
.LASFDE1:
.4byte .LASFDE1-__FRAME_BEGIN__
.4byte .LFB1
.4byte .LFE1-.LFB1
.byte 0x4
.4byte .LFE1-.LFB1
.byte 0x4
.4byte .L1-.LFB1
.LEFDE1:
EOF
cat > conftest.lit <<EOF
0000 10000000 00000000 017a0001 781a0004 .........z..x...
0010 01000000 12000000 18000000 00000000 ................
0020 08000000 04080000 0044 .........D
EOF
cat > conftest.big <<EOF
0000 00000010 00000000 017a0001 781a0004 .........z..x...
0010 00000001 00000012 00000018 00000000 ................
0020 00000008 04000000 0844 .........D
EOF
# If the assembler didn't choke, and we can objdump,
# and we got the correct data, then succeed.
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1 \
&& $gcc_cv_objdump -s -j .eh_frame conftest.o 2>/dev/null \
| tail -3 > conftest.got \
&& { cmp conftest.lit conftest.got > /dev/null 2>&1 \
|| cmp conftest.big conftest.got > /dev/null 2>&1; }
then
gcc_cv_as_eh_frame="yes"
else
gcc_cv_as_eh_frame="bad"
if $gcc_cv_as -o conftest.o --traditional-format /dev/null; then
AC_DEFINE(USE_AS_TRADITIONAL_FORMAT, 1,
[Define if your assembler mis-optimizes .eh_frame data.])
fi
fi
fi
rm -f conftest.*
fi
AC_MSG_RESULT($gcc_cv_as_eh_frame)
AC_MSG_CHECKING(assembler section merging support)
gcc_cv_as_shf_merge=no
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x; then
if test "$gcc_cv_gas_major_version" -eq 2 -a "$gcc_cv_gas_minor_version" -ge 12 -o "$gcc_cv_gas_major_version" -gt 2 && grep 'obj_format = elf' ../gas/Makefile > /dev/null; then
gcc_cv_as_shf_merge=yes
fi
elif test x$gcc_cv_as != x; then
# Check if we support SHF_MERGE sections
echo '.section .rodata.str, "aMS", @progbits, 1' > conftest.s
if $gcc_cv_as --fatal-warnings -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_shf_merge=yes
fi
rm -f conftest.s conftest.o
fi
if test x"$gcc_cv_as_shf_merge" = xyes; then
AC_DEFINE(HAVE_GAS_SHF_MERGE, 1,
[Define if your assembler supports marking sections with SHF_MERGE flag.])
fi
AC_MSG_RESULT($gcc_cv_as_shf_merge)
AC_MSG_CHECKING(assembler thread-local storage support)
gcc_cv_as_tls=no
conftest_s=
tls_first_major=
tls_first_minor=
case "$target" in
changequote(,)dnl
alpha*-*-*)
conftest_s='
.section ".tdata","awT",@progbits
foo: .long 25
.text
ldq $27,__tls_get_addr($29) !literal!1
lda $16,foo($29) !tlsgd!1
jsr $26,($27),__tls_get_addr !lituse_tlsgd!1
ldq $27,__tls_get_addr($29) !literal!2
lda $16,foo($29) !tlsldm!2
jsr $26,($27),__tls_get_addr !lituse_tlsldm!2
ldq $1,foo($29) !gotdtprel
ldah $2,foo($29) !dtprelhi
lda $3,foo($2) !dtprello
lda $4,foo($29) !dtprel
ldq $1,foo($29) !gottprel
ldah $2,foo($29) !tprelhi
lda $3,foo($2) !tprello
lda $4,foo($29) !tprel'
tls_first_major=2
tls_first_minor=13
;;
i[34567]86-*-*)
changequote([,])dnl
conftest_s='
.section ".tdata","awT",@progbits
foo: .long 25
.text
movl %gs:0, %eax
leal foo@TLSGD(,%ebx,1), %eax
leal foo@TLSLDM(%ebx), %eax
leal foo@DTPOFF(%eax), %edx
movl foo@GOTTPOFF(%ebx), %eax
subl foo@GOTTPOFF(%ebx), %eax
addl foo@GOTNTPOFF(%ebx), %eax
movl foo@INDNTPOFF, %eax
movl $foo@TPOFF, %eax
subl $foo@TPOFF, %eax
leal foo@NTPOFF(%ecx), %eax'
tls_first_major=2
tls_first_minor=14
;;
x86_64-*-*)
conftest_s='
.section ".tdata","awT",@progbits
foo: .long 25
.text
movq %fs:0, %rax
leaq foo@TLSGD(%rip), %rdi
leaq foo@TLSLD(%rip), %rdi
leaq foo@DTPOFF(%rax), %rdx
movq foo@GOTTPOFF(%rip), %rax
movq $foo@TPOFF, %rax'
tls_first_major=2
tls_first_minor=14
;;
ia64-*-*)
conftest_s='
.section ".tdata","awT",@progbits
foo: data8 25
.text
addl r16 = @ltoff(@dtpmod(foo#)), gp
addl r17 = @ltoff(@dtprel(foo#)), gp
addl r18 = @ltoff(@tprel(foo#)), gp
addl r19 = @dtprel(foo#), gp
adds r21 = @dtprel(foo#), r13
movl r23 = @dtprel(foo#)
addl r20 = @tprel(foo#), gp
adds r22 = @tprel(foo#), r13
movl r24 = @tprel(foo#)'
tls_first_major=2
tls_first_minor=13
;;
esac
if test -z "$tls_first_major"; then
:
elif test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x
then
if test "$gcc_cv_gas_major_version" -eq "$tls_first_major" \
-a "$gcc_cv_gas_minor_version" -ge "$tls_first_minor" \
-o "$gcc_cv_gas_major_version" -gt "$tls_first_major"; then
gcc_cv_as_tls=yes
fi
elif test x$gcc_cv_as != x; then
echo "$conftest_s" > conftest.s
if $gcc_cv_as --fatal-warnings -o conftest.o conftest.s > /dev/null 2>&1
then
gcc_cv_as_tls=yes
fi
rm -f conftest.s conftest.o
fi
if test "$gcc_cv_as_tls" = yes; then
AC_DEFINE(HAVE_AS_TLS, 1,
[Define if your assembler supports thread-local storage.])
fi
AC_MSG_RESULT($gcc_cv_as_tls)
case "$target" in
# All TARGET_ABI_OSF targets.
alpha*-*-osf* | alpha*-*-linux* | alpha*-*-*bsd*)
AC_CACHE_CHECK([assembler supports explicit relocations],
gcc_cv_as_explicit_relocs, [
gcc_cv_as_explicit_relocs=unknown
if test x$gcc_cv_gas_major_version != x \
-a x$gcc_cv_gas_minor_version != x
then
if test "$gcc_cv_gas_major_version" -eq 2 \
-a "$gcc_cv_gas_minor_version" -ge 12 \
-o "$gcc_cv_gas_major_version" -gt 2; then
gcc_cv_as_explicit_relocs=yes
fi
elif test x$gcc_cv_as != x; then
cat > conftest.s << 'EOF'
.set nomacro
.text
extbl $3, $2, $3 !lituse_bytoff!1
ldq $2, a($29) !literal!1
ldq $4, b($29) !literal!2
ldq_u $3, 0($2) !lituse_base!1
ldq $27, f($29) !literal!5
jsr $26, ($27), f !lituse_jsr!5
ldah $29, 0($26) !gpdisp!3
lda $0, c($29) !gprel
ldah $1, d($29) !gprelhigh
lda $1, d($1) !gprellow
lda $29, 0($29) !gpdisp!3
EOF
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_explicit_relocs=yes
else
gcc_cv_as_explicit_relocs=no
fi
rm -f conftest.s conftest.o
fi
])
if test "x$gcc_cv_as_explicit_relocs" = xyes; then
AC_DEFINE(HAVE_AS_EXPLICIT_RELOCS, 1,
[Define if your assembler supports explicit relocations.])
fi
;;
sparc*-*-*)
AC_CACHE_CHECK([assembler .register pseudo-op support],
gcc_cv_as_register_pseudo_op, [
gcc_cv_as_register_pseudo_op=unknown
if test x$gcc_cv_as != x; then
# Check if we have .register
echo ".register %g2, #scratch" > conftest.s
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_register_pseudo_op=yes
else
gcc_cv_as_register_pseudo_op=no
fi
rm -f conftest.s conftest.o
fi
])
if test "x$gcc_cv_as_register_pseudo_op" = xyes; then
AC_DEFINE(HAVE_AS_REGISTER_PSEUDO_OP, 1,
[Define if your assembler supports .register.])
fi
AC_CACHE_CHECK([assembler supports -relax],
gcc_cv_as_relax_opt, [
gcc_cv_as_relax_opt=unknown
if test x$gcc_cv_as != x; then
# Check if gas supports -relax
echo ".text" > conftest.s
if $gcc_cv_as -relax -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_relax_opt=yes
else
gcc_cv_as_relax_opt=no
fi
rm -f conftest.s conftest.o
fi
])
if test "x$gcc_cv_as_relax_opt" = xyes; then
AC_DEFINE(HAVE_AS_RELAX_OPTION, 1,
[Define if your assembler supports -relax option.])
fi
AC_CACHE_CHECK([assembler and linker support unaligned pc related relocs],
gcc_cv_as_sparc_ua_pcrel, [
gcc_cv_as_sparc_ua_pcrel=unknown
if test x$gcc_cv_as != x -a x$gcc_cv_ld != x; then
gcc_cv_as_sparc_ua_pcrel=no
echo ".text; foo: nop; .data; .align 4; .byte 0; .uaword %r_disp32(foo)" > conftest.s
if $gcc_cv_as -K PIC -o conftest.o conftest.s > /dev/null 2>&1 \
&& $gcc_cv_ld -o conftest conftest.o -G > /dev/null 2>&1; then
gcc_cv_as_sparc_ua_pcrel=yes
fi
rm -f conftest.s conftest.o conftest
fi
])
if test "x$gcc_cv_as_sparc_ua_pcrel" = xyes; then
AC_DEFINE(HAVE_AS_SPARC_UA_PCREL, 1,
[Define if your assembler and linker support unaligned PC relative relocs.])
fi
AC_CACHE_CHECK([assembler and linker support unaligned pc related relocs against hidden symbols],
gcc_cv_as_sparc_ua_pcrel_hidden, [
if test "x$gcc_cv_as_sparc_ua_pcrel" = xyes; then
gcc_cv_as_sparc_ua_pcrel_hidden=unknown
if test x$gcc_cv_objdump != x; then
gcc_cv_as_sparc_ua_pcrel_hidden=no
echo ".data; .align 4; .byte 0x31; .uaword %r_disp32(foo)" > conftest.s
echo ".byte 0x32, 0x33, 0x34; .global foo; .hidden foo" >> conftest.s
echo "foo: .skip 4" >> conftest.s
if $gcc_cv_as -K PIC -o conftest.o conftest.s > /dev/null 2>&1 \
&& $gcc_cv_ld -o conftest conftest.o -G > /dev/null 2>&1 \
&& $gcc_cv_objdump -s -j .data conftest 2> /dev/null \
| grep ' 31000000 07323334' > /dev/null 2>&1; then
if $gcc_cv_objdump -R conftest 2> /dev/null \
| grep 'DISP32' > /dev/null 2>&1; then
:
else
gcc_cv_as_sparc_ua_pcrel_hidden=yes
fi
fi
fi
rm -f conftest.s conftest.o conftest
else
gcc_cv_as_sparc_ua_pcrel_hidden="$gcc_cv_as_sparc_ua_pcrel"
fi
])
if test "x$gcc_cv_as_sparc_ua_pcrel_hidden" = xyes; then
AC_DEFINE(HAVE_AS_SPARC_UA_PCREL_HIDDEN, 1,
[Define if your assembler and linker support unaligned PC relative relocs against hidden symbols.])
fi
AC_CACHE_CHECK([for assembler offsetable %lo() support],
gcc_cv_as_offsetable_lo10, [
gcc_cv_as_offsetable_lo10=unknown
if test "x$gcc_cv_as" != x; then
# Check if assembler has offsetable %lo()
echo "or %g1, %lo(ab) + 12, %g1" > conftest.s
echo "or %g1, %lo(ab + 12), %g1" > conftest1.s
if $gcc_cv_as -xarch=v9 -o conftest.o conftest.s \
> /dev/null 2>&1 &&
$gcc_cv_as -xarch=v9 -o conftest1.o conftest1.s \
> /dev/null 2>&1; then
if cmp conftest.o conftest1.o > /dev/null 2>&1; then
gcc_cv_as_offsetable_lo10=no
else
gcc_cv_as_offsetable_lo10=yes
fi
else
gcc_cv_as_offsetable_lo10=no
fi
rm -f conftest.s conftest.o conftest1.s conftest1.o
fi
])
if test "x$gcc_cv_as_offsetable_lo10" = xyes; then
AC_DEFINE(HAVE_AS_OFFSETABLE_LO10, 1,
[Define if your assembler supports offsetable %lo().])
fi
;;
changequote(,)dnl
i[34567]86-*-* | x86_64-*-*)
changequote([,])dnl
AC_MSG_CHECKING(assembler instructions)
gcc_cv_as_instructions=
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x; then
if test "$gcc_cv_gas_major_version" -eq 2 -a "$gcc_cv_gas_minor_version" -ge 9 -o "$gcc_cv_gas_major_version" -gt 2; then
gcc_cv_as_instructions="filds fists"
fi
elif test x$gcc_cv_as != x; then
set "filds fists" "filds mem; fists mem"
while test $# -gt 0
do
echo "$2" > conftest.s
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_instructions=${gcc_cv_as_instructions}$1" "
fi
shift 2
done
rm -f conftest.s conftest.o
fi
if test x"$gcc_cv_as_instructions" != x; then
AC_DEFINE_UNQUOTED(HAVE_GAS_`echo "$gcc_cv_as_instructions" | sed -e 's/ $//' | tr '[a-z ]' '[A-Z_]'`)
fi
AC_MSG_RESULT($gcc_cv_as_instructions)
AC_MSG_CHECKING(assembler GOTOFF in data directives)
gcc_cv_as_gotoff_in_data=no
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x
then
if test "$gcc_cv_gas_major_version" -eq 2 \
-a "$gcc_cv_gas_minor_version" -ge 11 \
-o "$gcc_cv_gas_major_version" -gt 2; then
gcc_cv_as_gotoff_in_data=yes
fi
elif test x$gcc_cv_as != x; then
cat > conftest.s <<EOF
.text
.L0:
nop
.data
.long .L0@GOTOFF
EOF
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1; then
gcc_cv_as_gotoff_in_data=yes
fi
fi
AC_DEFINE_UNQUOTED(HAVE_AS_GOTOFF_IN_DATA,
[`if test $gcc_cv_as_gotoff_in_data = yes; then echo 1; else echo 0; fi`],
[Define true if the assembler supports '.long foo@GOTOFF'.])
AC_MSG_RESULT($gcc_cv_as_gotoff_in_data)
;;
esac
AC_MSG_CHECKING(assembler dwarf2 debug_line support)
gcc_cv_as_dwarf2_debug_line=no
# ??? Not all targets support dwarf2 debug_line, even within a version
# of gas. Moreover, we need to emit a valid instruction to trigger any
# info to the output file. So, as supported targets are added to gas 2.11,
# add some instruction here to (also) show we expect this might work.
# ??? Once 2.11 is released, probably need to add first known working
# version to the per-target configury.
case "$target" in
i?86*-*-* | mips*-*-* | alpha*-*-* | powerpc*-*-* | sparc*-*-* | m68*-*-* \
| x86_64*-*-* | hppa*-*-* | arm*-*-* | strongarm*-*-* | xscale*-*-*)
insn="nop"
;;
ia64*-*-*)
insn="nop 0"
;;
esac
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x;
then
if test "$gcc_cv_gas_major_version" -eq 2 \
-a "$gcc_cv_gas_minor_version" -ge 11 \
-o "$gcc_cv_gas_major_version" -gt 2 \
&& grep 'obj_format = elf' ../gas/Makefile > /dev/null \
&& test x"$insn" != x ; then
gcc_cv_as_dwarf2_debug_line="yes"
fi
elif test x$gcc_cv_as != x -a x"$insn" != x ; then
echo ' .file 1 "conftest.s"' > conftest.s
echo ' .loc 1 3 0' >> conftest.s
echo " $insn" >> conftest.s
# ??? This fails with non-gnu grep.
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1 \
&& grep debug_line conftest.o > /dev/null 2>&1 ; then
# The .debug_line file table must be in the exact order that
# we specified the files, since these indices are also used
# by DW_AT_decl_file. Approximate this test by testing if
# the assembler bitches if the same index is assigned twice.
echo ' .file 1 "foo.s"' > conftest.s
echo ' .file 1 "bar.s"' >> conftest.s
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1
then
gcc_cv_as_dwarf2_debug_line="no"
else
gcc_cv_as_dwarf2_debug_line="yes"
fi
fi
rm -f conftest.s conftest.o conftest.nm1 conftest.nm2
fi
if test x"$gcc_cv_as_dwarf2_debug_line" = xyes; then
AC_DEFINE(HAVE_AS_DWARF2_DEBUG_LINE, 1,
[Define if your assembler supports dwarf2 .file/.loc directives,
and preserves file table indices exactly as given.])
fi
AC_MSG_RESULT($gcc_cv_as_dwarf2_debug_line)
AC_MSG_CHECKING(assembler --gdwarf2 support)
gcc_cv_as_gdwarf2_flag=no
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x;
then
if test "$gcc_cv_gas_major_version" -eq 2 \
-a "$gcc_cv_gas_minor_version" -ge 11 \
-o "$gcc_cv_gas_major_version" -gt 2 \
&& grep 'obj_format = elf' ../gas/Makefile > /dev/null \
&& test x"$insn" != x ; then
gcc_cv_as_gdwarf2_flag="yes"
fi
elif test x$gcc_cv_as != x -a x"$insn" != x ; then
echo '' > conftest.s
# ??? This fails with non-gnu grep.
if $gcc_cv_as --gdwarf2 -o conftest.o conftest.s > /dev/null 2>&1
then
gcc_cv_as_gdwarf2_flag="yes"
fi
rm -f conftest.s conftest.o
fi
if test x"$gcc_cv_as_gdwarf2_flag" = xyes; then
AC_DEFINE(HAVE_AS_GDWARF2_DEBUG_FLAG, 1,
[Define if your assembler supports the --gdwarf2 option.])
fi
AC_MSG_RESULT($gcc_cv_as_gdwarf2_flag)
# APPLE LOCAL coalescing --matt
AC_MSG_CHECKING([whether assembler supports weak section attribute.])
cat > conftest.s <<EOF
.section __TEXT,text,coalesced,weak_definitions
.align 2
.globl foo
foo:
EOF
apple_gcc_as_weak_section_attribute=no
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1 ; then
apple_gcc_as_weak_section_attribute="yes"
fi
rm -f conftest.s conftest.o
if test x"$apple_gcc_as_weak_section_attribute" = xyes; then
AC_DEFINE(APPLE_WEAK_SECTION_ATTRIBUTE, 1,
[APPLE LOCAL coalescing
Define if your assembler supports weak section attribute.])
AC_MSG_RESULT(yes)
else
AC_MSG_RESULT(no)
fi
AC_MSG_CHECKING([whether assembler supports weak assembler directive.])
apple_gcc_as_weak_assembler_directive=no
cat > conftest.s <<EOF
.section __TEXT,text,coalesced
.align 2
.weak_definition foo
.globl foo
foo:
EOF
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1 ; then
apple_gcc_as_weak_assembler_directive="yes"
fi
rm -f conftest.s conftest.o
if test x"$apple_gcc_as_weak_assembler_directive" = xyes; then
AC_DEFINE(APPLE_WEAK_ASSEMBLER_DIRECTIVE, 1,
[APPLE LOCAL coalescing
Define if your assembler supports weak assembler directives.])
AC_MSG_RESULT(yes)
else
AC_MSG_RESULT(no)
fi
AC_MSG_CHECKING([whether assembler supports strip static syms assembler directive.])
apple_gcc_as_strip_static_syms_assembler_directive=no
cat > conftest.s <<EOF
.section __TEXT,text,coalesced,no_toc+strip_static_syms
.weak_definition foo
.globl foo
foo:
EOF
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1 ; then
apple_gcc_as_strip_static_syms_assembler_directive="yes"
fi
rm -f conftest.s conftest.o
if test x"$apple_gcc_as_strip_static_syms_assembler_directive" = xyes; then
AC_DEFINE(APPLE_STRIP_STATIC_SYMS_SECTION_ATTRIBUTE, 1,
[APPLE LOCAL coalescing
Define if your assembler supports strip static syms section attribute.])
AC_MSG_RESULT(yes)
else
AC_MSG_RESULT(no)
fi
# APPLE LOCAL end coalescing --matt
AC_MSG_CHECKING(assembler --gstabs support)
gcc_cv_as_gstabs_flag=no
if test x$gcc_cv_gas_major_version != x -a x$gcc_cv_gas_minor_version != x;
then
if test "$gcc_cv_gas_major_version" -eq 2 \
-a "$gcc_cv_gas_minor_version" -ge 11 \
-o "$gcc_cv_gas_major_version" -gt 2 \
&& grep 'obj_format = elf' ../gas/Makefile > /dev/null \
&& test x"$insn" != x ; then
gcc_cv_as_gstabs_flag="yes"
fi
elif test x$gcc_cv_as != x -a x"$insn" != x ; then
echo '' > conftest.s
# ??? This fails with non-gnu grep.
if $gcc_cv_as --gstabs -o conftest.o conftest.s > /dev/null 2>&1 ; then
gcc_cv_as_gstabs_flag="yes"
fi
rm -f conftest.s conftest.o
fi
if test x"$gcc_cv_as_gstabs_flag" = xyes; then
AC_DEFINE(HAVE_AS_GSTABS_DEBUG_FLAG, 1,
[Define if your assembler supports the --gstabs option.])
fi
AC_MSG_RESULT($gcc_cv_as_gstabs_flag)
AC_MSG_CHECKING(linker read-only and read-write section mixing)
gcc_cv_ld_ro_rw_mix=unknown
if test x$gcc_cv_gld_major_version != x -a x$gcc_cv_gld_minor_version != x; then
if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge 10 -o "$gcc_cv_gld_major_version" -gt 2 && grep 'EMUL = elf' ../ld/Makefile > /dev/null; then
gcc_cv_ld_ro_rw_mix=read-write
fi
elif test x$gcc_cv_as != x -a x$gcc_cv_ld != x -a x$gcc_cv_objdump != x ; then
echo '.section "myfoosect", "a"' > conftest1.s
echo '.section "myfoosect", "aw"' > conftest2.s
echo '.byte 1' >> conftest2.s
echo '.section "myfoosect", "a"' > conftest3.s
echo '.byte 0' >> conftest3.s
if $gcc_cv_as -o conftest1.o conftest1.s \
&& $gcc_cv_as -o conftest2.o conftest2.s \
&& $gcc_cv_as -o conftest3.o conftest3.s \
&& $gcc_cv_ld -shared -o conftest1.so conftest1.o \
conftest2.o conftest3.o; then
gcc_cv_ld_ro_rw_mix=`$gcc_cv_objdump -h conftest1.so \
| grep -A1 myfoosect`
if echo "$gcc_cv_ld_ro_rw_mix" | grep CONTENTS > /dev/null; then
if echo "$gcc_cv_ld_ro_rw_mix" | grep READONLY > /dev/null; then
gcc_cv_ld_ro_rw_mix=read-only
else
gcc_cv_ld_ro_rw_mix=read-write
fi
fi
fi
changequote(,)dnl
rm -f conftest.* conftest[123].*
changequote([,])dnl
fi
if test x$gcc_cv_ld_ro_rw_mix = xread-write; then
AC_DEFINE(HAVE_LD_RO_RW_SECTION_MIXING, 1,
[Define if your linker links a mix of read-only
and read-write sections into a read-write section.])
fi
AC_MSG_RESULT($gcc_cv_ld_ro_rw_mix)
AC_MSG_CHECKING(linker PT_GNU_EH_FRAME support)
gcc_cv_ld_eh_frame_hdr=no
if test x$gcc_cv_gld_major_version != x -a x$gcc_cv_gld_minor_version != x; then
if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge 12 -o "$gcc_cv_gld_major_version" -gt 2 && grep 'EMUL = elf' ../ld/Makefile > /dev/null; then
gcc_cv_ld_eh_frame_hdr=yes
fi
elif test x$gcc_cv_ld != x; then
# Check if linker supports --eh-frame-hdr option
if $gcc_cv_ld --help 2>/dev/null | grep eh-frame-hdr > /dev/null; then
gcc_cv_ld_eh_frame_hdr=yes
fi
fi
if test x"$gcc_cv_ld_eh_frame_hdr" = xyes; then
AC_DEFINE(HAVE_LD_EH_FRAME_HDR, 1,
[Define if your linker supports --eh-frame-hdr option.])
fi
AC_MSG_RESULT($gcc_cv_ld_eh_frame_hdr)
# Miscellaneous target-specific checks.
case "$target" in
mips*-*-*)
AC_MSG_CHECKING(whether libgloss uses STARTUP directives consistently)
gcc_cv_mips_libgloss_startup=no
gcc_cv_libgloss_srcdir=`echo $srcdir | sed -e 's,/gcc$,,'`/libgloss
if test "x$exec_prefix" = xNONE; then
if test "x$prefix" = xNONE; then
test_prefix=/usr/local
else
test_prefix=$prefix
fi
else
test_prefix=$exec_prefix
fi
for f in $gcc_cv_libgloss_srcdir/mips/idt.ld $test_prefix/$target_alias/lib/idt.ld
do
if grep '^STARTUP' $f > /dev/null 2>&1; then
gcc_cv_mips_libgloss_startup=yes
break
fi
done
if test x"$gcc_cv_mips_libgloss_startup" = xyes; then
AC_DEFINE(HAVE_MIPS_LIBGLOSS_STARTUP_DIRECTIVES, 1,
[Define if your MIPS libgloss linker scripts consistently include STARTUP directives.])
fi
AC_MSG_RESULT($gcc_cv_mips_libgloss_startup)
;;
esac
if test "$prefix" != "/usr" && test "x$prefix" != "x$local_prefix" ; then
AC_DEFINE_UNQUOTED(PREFIX_INCLUDE_DIR, "$prefix/include")
fi
# Figure out what language subdirectories are present.
# Look if the user specified --enable-languages="..."; if not, use
# the environment variable $LANGUAGES if defined. $LANGUAGES might
# go away some day.
# NB: embedded tabs in this IF block -- do not untabify
if test x"${enable_languages+set}" != xset; then
if test x"${LANGUAGES+set}" = xset; then
enable_languages="${LANGUAGES}"
AC_MSG_WARN([setting LANGUAGES is deprecated, use --enable-languages instead])
else
enable_languages=all
fi
else
if test x"${enable_languages}" = x \
|| test x"${enable_languages}" = xyes;
then
AC_MSG_ERROR([--enable-languages needs at least one language argument])
fi
fi
enable_languages=`echo "${enable_languages}" | sed -e 's/[[ ,]][[ ,]]*/,/g' -e 's/,$//'`
# First scan to see if an enabled language requires some other language.
# We assume that a given config-lang.in will list all the language
# front ends it requires, even if some are required indirectly.
for lang in ${srcdir}/*/config-lang.in ..
do
case $lang in
..)
;;
# The odd quoting in the next line works around
# an apparent bug in bash 1.12 on linux.
changequote(,)dnl
${srcdir}/[*]/config-lang.in)
;;
*)
lang_alias=`sed -n -e 's,^language=['"'"'"'"]\(.*\)["'"'"'"'].*$,\1,p' -e 's,^language=\([^ ]*\).*$,\1,p' $lang`
this_lang_requires=`sed -n -e 's,^lang_requires=['"'"'"'"]\(.*\)["'"'"'"'].*$,\1,p' -e 's,^lang_requires=\([^ ]*\).*$,\1,p' $lang`
for other in $this_lang_requires
do
case ,${enable_languages}, in
*,$other,*)
;;
*,all,*)
;;
*,$lang_alias,*)
enable_languages="$enable_languages,$other"
;;
esac
done
;;
changequote([,])dnl
esac
done
expected_languages=`echo ,${enable_languages}, | sed -e 's:,: :g' -e 's: *: :g' -e 's: *: :g' -e 's:^ ::' -e 's: $::'`
found_languages=
subdirs=
for lang in ${srcdir}/*/config-lang.in ..
do
case $lang in
..) ;;
# The odd quoting in the next line works around
# an apparent bug in bash 1.12 on linux.
changequote(,)dnl
${srcdir}/[*]/config-lang.in) ;;
*)
lang_alias=`sed -n -e 's,^language=['"'"'"'"]\(.*\)["'"'"'"'].*$,\1,p' -e 's,^language=\([^ ]*\).*$,\1,p' $lang`
this_lang_libs=`sed -n -e 's,^target_libs=['"'"'"'"]\(.*\)["'"'"'"'].*$,\1,p' -e 's,^target_libs=\([^ ]*\).*$,\1,p' $lang`
build_by_default=`sed -n -e 's,^build_by_default=['"'"'"'"]\(.*\)["'"'"'"'].*$,\1,p' -e 's,^build_by_default=\([^ ]*\).*$,\1,p' $lang`
if test "x$lang_alias" = x
then
echo "$lang doesn't set \$language." 1>&2
exit 1
fi
case ${build_by_default},${enable_languages}, in
*,$lang_alias,*) add_this_lang=yes ;;
no,*) add_this_lang=no ;;
*,all,*) add_this_lang=yes ;;
*) add_this_lang=no ;;
esac
found_languages="${found_languages} ${lang_alias}"
if test x"${add_this_lang}" = xyes; then
case $lang in
${srcdir}/ada/config-lang.in)
if test x$have_gnat = xyes ; then
subdirs="$subdirs `echo $lang | sed -e 's,^.*/\([^/]*\)/config-lang.in$,\1,'`"
fi
;;
*)
subdirs="$subdirs `echo $lang | sed -e 's,^.*/\([^/]*\)/config-lang.in$,\1,'`"
;;
esac
fi
;;
changequote([,])dnl
esac
done
missing_languages=
for expected_language in ${expected_languages} ..
do
if test "${expected_language}" != ..; then
missing_language="${expected_language}"
if test "${expected_language}" = "c" \
|| test "${expected_language}" = "all"; then
missing_language=
fi
for found_language in ${found_languages} ..
do
if test "${found_language}" != ..; then
if test "${expected_language}" = "${found_language}"; then
missing_language=
fi
fi
done
if test "x${missing_language}" != x; then
missing_languages="${missing_languages} ${missing_language}"
fi
fi
done
if test "x$missing_languages" != x; then
AC_MSG_ERROR([
The following requested languages were not found:${missing_languages}
The following languages were available: c${found_languages}])
fi
# Make gthr-default.h if we have a thread file.
gthread_flags=
if test $thread_file != single; then
rm -f gthr-default.h
echo "#include \"gthr-${thread_file}.h\"" > gthr-default.h
gthread_flags=-DHAVE_GTHR_DEFAULT
fi
AC_SUBST(gthread_flags)
# Find out what GC implementation we want, or may, use.
AC_ARG_WITH(gc,
[ --with-gc={simple,page,placeholder} choose the garbage collection mechanism to use
with the compiler],
[case "$withval" in
simple | page | placeholder)
GGC=ggc-$withval
;;
*)
AC_MSG_ERROR([$withval is an invalid option to --with-gc])
;;
esac],
[GGC=ggc-page])
AC_SUBST(GGC)
echo "Using $GGC for garbage collection."
# Use the system's zlib library.
zlibdir=-L../zlib
zlibinc="-I\$(srcdir)/../zlib"
AC_ARG_WITH(system-zlib,
[ --with-system-zlib use installed libz],
zlibdir=
zlibinc=
)
AC_SUBST(zlibdir)
AC_SUBST(zlibinc)
dnl Very limited version of automake's enable-maintainer-mode
AC_MSG_CHECKING([whether to enable maintainer-specific portions of Makefiles])
dnl maintainer-mode is disabled by default
AC_ARG_ENABLE(maintainer-mode,
[ --enable-maintainer-mode
enable make rules and dependencies not useful
(and sometimes confusing) to the casual installer],
maintainer_mode=$enableval,
maintainer_mode=no)
AC_MSG_RESULT($maintainer_mode)
if test "$maintainer_mode" = "yes"; then
MAINT=''
else
MAINT='#'
fi
AC_SUBST(MAINT)dnl
# With Setjmp/Longjmp based exception handling.
AC_ARG_ENABLE(sjlj-exceptions,
[ --enable-sjlj-exceptions
arrange to use setjmp/longjmp exception handling],
[sjlj=`if test $enableval = yes; then echo 1; else echo 0; fi`
AC_DEFINE_UNQUOTED(CONFIG_SJLJ_EXCEPTIONS, $sjlj,
[Define 0/1 to force the choice for exception handling model.])])
# Use libunwind based exception handling.
AC_ARG_ENABLE(libunwind-exceptions,
[ --enable-libunwind-exceptions force use libunwind for exceptions],
use_libunwind_exceptions=$enableval,
use_libunwind_exceptions=no)
if test x"$use_libunwind_exceptions" = xyes; then
AC_DEFINE(USE_LIBUNWIND_EXCEPTIONS, 1,
[Define if gcc should use -lunwind.])
fi
# APPLE LOCAL begin debugging ilr
# Enable ENABLE_IDEBUG support by default
AC_ARG_ENABLE(idebug,
[ --disable-idebug APPLE LOCAL debugging
Dont't define functions for most tree and
rtl accessors for use with debugger.],
, enable_idebug=yes)
AC_MSG_CHECKING([whether debugging functions for tree and rtl nodes requested])
if test x${enable_idebug} = xyes; then
AC_MSG_RESULT(yes)
AC_DEFINE(ENABLE_IDEBUG, 1, [APPLE LOCAL debugging
Define if you want tree and rtl debugger function accessors.])
else
AC_MSG_RESULT(no)
fi
# Enable ENABLE_DMP_TREE support by default
AC_ARG_ENABLE(dmp-tree,
[ --disable-dmp-tree APPLE LOCAL debugging
Don't provide dmp_tree() support for debugger.],
, enable_dmp_tree=yes)
AC_MSG_CHECKING([whether dmp_tree() support for debugger was requested])
if test x${enable_dmp_tree} = xyes; then
AC_MSG_RESULT(yes)
AC_DEFINE(ENABLE_DMP_TREE, 1, [APPLE LOCAL debugging
Define if you want dmp_tree() enabled for debugging.])
else
AC_MSG_RESULT(no)
fi
# APPLE LOCAL end debugging ilr
# APPLE LOCAL begin fat builds ilr
AC_ARG_ENABLE(build_gcc,
[ --enable-build_gcc APPLE LOCAL fat builds
Enable building release compilers with build_gcc.],
, enable_build_gcc=no)
AC_MSG_CHECKING([whether configuring from build_gcc])
if test x${enable_build_gcc} = xyes; then
AC_MSG_RESULT(yes)
AC_DEFINE(PHAT, 1, [APPLE LOCAL fat builds
Define if you want builds to use Apple gcc release conventions.])
else
AC_MSG_RESULT(no)
fi
AC_SUBST(enable_build_gcc)
# APPLE LOCAL end fat builds ilr
# Make empty files to contain the specs and options for each language.
# Then add #include lines to for a compiler that has specs and/or options.
lang_specs_files=
lang_options_files=
lang_tree_files=
for subdir in . $subdirs
do
if test -f $srcdir/$subdir/lang-specs.h; then
lang_specs_files="$lang_specs_files $srcdir/$subdir/lang-specs.h"
fi
if test -f $srcdir/$subdir/lang-options.h; then
lang_options_files="$lang_options_files $srcdir/$subdir/lang-options.h"
fi
if test -f $srcdir/$subdir/$subdir-tree.def; then
lang_tree_files="$lang_tree_files $srcdir/$subdir/$subdir-tree.def"
fi
done
# These (without "all_") are set in each config-lang.in.
# `language' must be a single word so is spelled singularly.
all_languages=
all_boot_languages=
all_compilers=
all_stagestuff=
all_outputs='Makefile intl/Makefile fixinc/Makefile gccbug mklibgcc mkheaders'
# List of language makefile fragments.
all_lang_makefiles=
# Files for gengtype
all_gtfiles="$target_gtfiles"
# Files for gengtype with language
all_gtfiles_files_langs=
all_gtfiles_files_files=
# Add the language fragments.
# Languages are added via two mechanisms. Some information must be
# recorded in makefile variables, these are defined in config-lang.in.
# We accumulate them and plug them into the main Makefile.
# The other mechanism is a set of hooks for each of the main targets
# like `clean', `install', etc.
language_fragments="Make-lang"
language_hooks="Make-hooks"
for s in .. $subdirs
do
if test $s != ".."
then
language=
boot_language=
compilers=
stagestuff=
outputs=
gtfiles=
. ${srcdir}/$s/config-lang.in
if test "x$language" = x
then
echo "${srcdir}/$s/config-lang.in doesn't set \$language." 1>&2
exit 1
fi
all_lang_makefiles="$all_lang_makefiles ${srcdir}/$s/Make-lang.in"
if test -f ${srcdir}/$s/Makefile.in
then all_lang_makefiles="$all_lang_makefiles ${srcdir}/$s/Makefile.in"
fi
all_languages="$all_languages $language"
if test "x$boot_language" = xyes
then
all_boot_languages="$all_boot_languages $language"
fi
all_compilers="$all_compilers $compilers"
all_stagestuff="$all_stagestuff $stagestuff"
all_outputs="$all_outputs $outputs"
all_gtfiles="$all_gtfiles $gtfiles"
for f in .. $gtfiles
do
if test $f != ".."
then
all_gtfiles_files_langs="$all_gtfiles_files_langs ${s} "
all_gtfiles_files_files="$all_gtfiles_files_files ${f} "
fi
done
fi
done
# Pick up gtfiles for c
gtfiles=
s="c"
. ${srcdir}/c-config-lang.in
all_gtfiles="$all_gtfiles $gtfiles"
for f in .. $gtfiles
do
if test $f != ".."
then
all_gtfiles_files_langs="$all_gtfiles_files_langs ${s} "
all_gtfiles_files_files="$all_gtfiles_files_files ${f} "
fi
done
check_languages=
for language in .. $all_languages
do
if test $language != ".."
then
check_languages="$check_languages check-$language"
fi
done
# Since we can't use `::' targets, we link each language in
# with a set of hooks, reached indirectly via lang.${target}.
rm -f Make-hooks
touch Make-hooks
target_list="all.build all.cross start.encap rest.encap \
info dvi generated-manpages \
install-normal install-common install-info install-man \
uninstall \
mostlyclean clean distclean extraclean maintainer-clean \
stage1 stage2 stage3 stage4"
for t in $target_list
do
x=
for lang in .. $all_languages
do
if test $lang != ".."; then
x="$x $lang.$t"
fi
done
echo "lang.$t: $x" >> Make-hooks
done
# Create .gdbinit.
echo "dir ." > .gdbinit
echo "dir ${srcdir}" >> .gdbinit
if test x$gdb_needs_out_file_path = xyes
then
echo "dir ${srcdir}/config/"`dirname ${out_file}` >> .gdbinit
fi
if test "x$subdirs" != x; then
for s in $subdirs
do
echo "dir ${srcdir}/$s" >> .gdbinit
done
fi
echo "source ${srcdir}/gdbinit.in" >> .gdbinit
# Define variables host_canonical and build_canonical
# because some Cygnus local changes in the Makefile depend on them.
build_canonical=${build}
host_canonical=${host}
target_subdir=
if test "${host}" != "${target}" ; then
target_subdir=${target_alias}/
fi
AC_SUBST(build_canonical)
AC_SUBST(host_canonical)
AC_SUBST(target_subdir)
# If $(exec_prefix) exists and is not the same as $(prefix), then compute an
# absolute path for gcc_tooldir based on inserting the number of up-directory
# movements required to get from $(exec_prefix) to $(prefix) into the basic
# $(libsubdir)/@(unlibsubdir) based path.
# Don't set gcc_tooldir to tooldir since that's only passed in by the toplevel
# make and thus we'd get different behavior depending on where we built the
# sources.
if test x$exec_prefix = xNONE -o x$exec_prefix = x$prefix; then
gcc_tooldir='$(libsubdir)/$(unlibsubdir)/../$(target_alias)'
else
changequote(<<, >>)dnl
# An explanation of the sed strings:
# -e 's|^\$(prefix)||' matches and eliminates 'prefix' from 'exec_prefix'
# -e 's|/$||' match a trailing forward slash and eliminates it
# -e 's|^[^/]|/|' forces the string to start with a forward slash (*)
# -e 's|/[^/]*|../|g' replaces each occurrence of /<directory> with ../
#
# (*) Note this pattern overwrites the first character of the string
# with a forward slash if one is not already present. This is not a
# problem because the exact names of the sub-directories concerned is
# unimportant, just the number of them matters.
#
# The practical upshot of these patterns is like this:
#
# prefix exec_prefix result
# ------ ----------- ------
# /foo /foo/bar ../
# /foo/ /foo/bar ../
# /foo /foo/bar/ ../
# /foo/ /foo/bar/ ../
# /foo /foo/bar/ugg ../../
#
dollar='$$'
gcc_tooldir="\$(libsubdir)/\$(unlibsubdir)/\`echo \$(exec_prefix) | sed -e 's|^\$(prefix)||' -e 's|/\$(dollar)||' -e 's|^[^/]|/|' -e 's|/[^/]*|../|g'\`\$(target_alias)"
changequote([, ])dnl
fi
AC_SUBST(gcc_tooldir)
AC_SUBST(dollar)
# Find a directory in which to install a shared libgcc.
AC_ARG_ENABLE(version-specific-runtime-libs,
[ --enable-version-specific-runtime-libs
specify that runtime libraries should be
installed in a compiler-specific directory])
AC_ARG_WITH(slibdir,
[ --with-slibdir=DIR shared libraries in DIR [LIBDIR]],
slibdir="$with_slibdir",
if test "${enable_version_specific_runtime_libs+set}" = set; then
slibdir='$(libsubdir)'
elif test "$host" != "$target"; then
slibdir='$(build_tooldir)/lib'
else
slibdir='$(libdir)'
fi)
AC_SUBST(slibdir)
objdir=`${PWDCMD-pwd}`
AC_SUBST(objdir)
# Process the language and host/target makefile fragments.
${CONFIG_SHELL-/bin/sh} $srcdir/configure.frag $srcdir "$subdirs" "$dep_host_xmake_file" "$dep_tmake_file"
# Substitute configuration variables
AC_SUBST(subdirs)
AC_SUBST(srcdir)
AC_SUBST(all_boot_languages)
AC_SUBST(all_compilers)
AC_SUBST(all_gtfiles)
AC_SUBST(all_gtfiles_files_langs)
AC_SUBST(all_gtfiles_files_files)
AC_SUBST(all_lang_makefiles)
AC_SUBST(all_languages)
AC_SUBST(all_stagestuff)
AC_SUBST(build_exeext)
AC_SUBST(build_install_headers_dir)
AC_SUBST(build_xm_file_list)
AC_SUBST(build_xm_file)
AC_SUBST(build_xm_defines)
AC_SUBST(check_languages)
AC_SUBST(cc_set_by_configure)
AC_SUBST(quoted_cc_set_by_configure)
AC_SUBST(cpp_install_dir)
AC_SUBST(dep_host_xmake_file)
AC_SUBST(dep_tmake_file)
AC_SUBST(extra_headers_list)
AC_SUBST(extra_objs)
AC_SUBST(extra_parts)
AC_SUBST(extra_passes)
AC_SUBST(extra_programs)
AC_SUBST(float_h_file)
AC_SUBST(gcc_config_arguments)
AC_SUBST(gcc_gxx_include_dir)
AC_SUBST(libstdcxx_incdir)
AC_SUBST(gcc_version)
AC_SUBST(gcc_version_full)
AC_SUBST(gcc_version_trigger)
AC_SUBST(host_exeext)
AC_SUBST(host_extra_gcc_objs)
AC_SUBST(host_xm_file_list)
AC_SUBST(host_xm_file)
AC_SUBST(host_xm_defines)
AC_SUBST(install)
AC_SUBST(lang_options_files)
AC_SUBST(lang_specs_files)
AC_SUBST(lang_tree_files)
AC_SUBST(local_prefix)
AC_SUBST(md_file)
AC_SUBST(objc_boehm_gc)
AC_SUBST(out_file)
AC_SUBST(out_object_file)
AC_SUBST(stage_prefix_set_by_configure)
AC_SUBST(quoted_stage_prefix_set_by_configure)
AC_SUBST(symbolic_link)
AC_SUBST(thread_file)
AC_SUBST(tm_file_list)
AC_SUBST(tm_file)
AC_SUBST(tm_defines)
AC_SUBST(tm_p_file_list)
AC_SUBST(tm_p_file)
AC_SUBST(xm_file)
AC_SUBST(xm_defines)
AC_SUBST(target_alias)
AC_SUBST(c_target_objs)
AC_SUBST(cxx_target_objs)
AC_SUBST(target_cpu_default)
AC_SUBST_FILE(target_overrides)
AC_SUBST_FILE(host_overrides)
AC_SUBST_FILE(language_fragments)
AC_SUBST_FILE(language_hooks)
# Echo that links are built
if test x$host = x$target
then
str1="native "
else
str1="cross-"
str2=" from $host"
fi
if test x$host != x$build
then
str3=" on a $build system"
fi
if test "x$str2" != x || test "x$str3" != x
then
str4=
fi
echo "Links are now set up to build a ${str1}compiler for ${target}$str4" 1>&2
if test "x$str2" != x || test "x$str3" != x
then
echo " ${str2}${str3}." 1>&2
fi
# Truncate the target if necessary
if test x$host_truncate_target != x; then
target=`echo $target | sed -e 's/\(..............\).*/\1/'`
fi
# Configure the subdirectories
# AC_CONFIG_SUBDIRS($subdirs)
# Create the Makefile
# and configure language subdirectories
AC_OUTPUT($all_outputs,
[
case x$CONFIG_HEADERS in
xauto-host.h:config.in)
echo > cstamp-h ;;
esac
# If the host supports symlinks, point stage[1234] at ../stage[1234] so
# bootstrapping and the installation procedure can still use
# CC="stage1/xgcc -Bstage1/". If the host doesn't support symlinks,
# FLAGS_TO_PASS has been modified to solve the problem there.
# This is virtually a duplicate of what happens in configure.lang; we do
# an extra check to make sure this only happens if ln -s can be used.
if test "$symbolic_link" = "ln -s"; then
for d in .. ${subdirs} fixinc ; do
if test $d != ..; then
STARTDIR=`${PWDCMD-pwd}`
cd $d
for t in stage1 stage2 stage3 stage4 include
do
rm -f $t
$symbolic_link ../$t $t 2>/dev/null
done
cd $STARTDIR
fi
done
else true ; fi
# Avoid having to add intl to our include paths.
if test -f intl/libintl.h; then
echo creating libintl.h
echo '#include "intl/libintl.h"' >libintl.h
fi
# APPLE LOCAL begin PFE ilr
echo "creating pfe directory in" `pwd`
test ! -d pfe && mkdir pfe
# APPLE LOCAL end PFE ilr
],
[subdirs='$subdirs'
symbolic_link='$symbolic_link'
])
[-- Attachment #5: Type: text/plain, Size: 968 bytes --]
The test was with the top of Apple's CVS tree at the time I did it,
which was about a month ago. It's pretty similar to the current
top of the 3.3 release branch, but if you feel like being really precise
and going to Apple's CVS server, the tag to look at is gcc3-1310.
> Also did you keep your actual numbers, and what was your machine
> configuration.
I tested running cc1plus only, on a preprocessed source file. I don't
think I can include that source file, I'm afraid, because it's
proprietary
Apple code. I was running the tests on a PPC running OS X
10.2.2.
Numbers:
TOT 2.6s real, 2.3s user, 0.3s sys
TOT with placeholder gc 2.3s real, 2.0s user, 0.3s sys
The numbers changed a bit depending on how large the chunks were
that I allocated with ggc-placeholder.c. I can probably find some more
detailed numbers if I try.
And I have to say, these results surprised me. I expected to see bigger
gains, because of improved locality.
--Matt
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:54 ` Devang Patel
2003-02-03 22:32 ` Geoff Keating
@ 2003-02-04 20:17 ` Tim Josling
2003-02-04 20:47 ` Matt Austern
1 sibling, 1 reply; 115+ messages in thread
From: Tim Josling @ 2003-02-04 20:17 UTC (permalink / raw)
To: Devang Patel; +Cc: gcc, Matt Austern, To, be, precise, geoffk
Devang Patel wrote:
> > Tests I did last year showed that even without doing collection, gcc
> > is slowed
> > down by the requirements of GC...
> >
>
> Matt Austern at Apple did similar experiment by using ggc placeholder.
> (same interface as ggc, no collection, allocate memory using mmap in
> chunks and
> satisfy memory allocation requests from these chunks etc..).
>
> He got around ~12% speedup for sample c++ source.
>
> -Devang
> (also from Geoff Keating in another email)
>
> To be precise, Matt found that the speedup of using the ggc
> placeholder was about equivalent to the speedup of using ggc-page but
> disabling garbage collection. This contradicts the results that Tim
> Josling got above.
>
> --
> - Geoffrey Keating <\x03>
Geoffrey,
The first rule of performance testing is to change one thing at a time. Here
we have several variables:
gcc code versus unspecified c++ code.
Matt's versus Tim's minimal non-gc implementation.
Different machine/cpu/OS (presumably).
I will dig out my minimal implementation and post it as a patch, so people can
verify my numbers for themselves.
Matt,
Any chance I could get a copy of your c++ source and/or your minimal non-gc
implementation so I can see what is under the discrepancy?
Also did you keep your actual numbers, and what was your machine
configuration.
I have a PIII with 256 mb ram, running gnu/linux 2.4 (Red Hat 7.1), but I did
not keep the actual numbers.
Tim Josling
\x18
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-04 0:05 ` Tim Hollebeek
@ 2003-02-04 20:07 ` Tim Josling
0 siblings, 0 replies; 115+ messages in thread
From: Tim Josling @ 2003-02-04 20:07 UTC (permalink / raw)
To: tim, gcc
Tim Hollebeek wrote:
>
> > Use a simple contiguous allocator, up to a certain amount of memory. If that
> > runs out, restart the compile using ggc-page. Most compiles would not be
> > affected, and the few that do need GC will get it without too much overhead.
> > You could have an option -ggc-force to avoid the restarts.
>
> it would be even more interesting to find a (perhaps file size based)
> heuristic that can predict memory needs well enough to usually get the
> decision right up front.
>
> -Tim
Yes, however if you choose no-gc you need to be able to switch if you look
like running out of memory.
Tim Josling
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-04 2:03 ` Richard Henderson
2003-02-04 2:26 ` Zack Weinberg
@ 2003-02-04 4:14 ` Daniel Berlin
1 sibling, 0 replies; 115+ messages in thread
From: Daniel Berlin @ 2003-02-04 4:14 UTC (permalink / raw)
To: Richard Henderson
Cc: Tim Josling, gcc, Neil Booth, Mike Stump, Benjamin Kosnik
On Mon, 3 Feb 2003, Richard Henderson wrote:
> On Mon, Feb 03, 2003 at 07:04:00PM +1100, Tim Josling wrote:
> > 1. Allocating storage of similar sizes together, sacrificing locality.
> > 2. Wasting space by rounding up allocations to the next power of 2, wasting
> > space and increasing working set sizes.
> > 3. Having bits of GC code all over the place impacting code locality and
> > working set sizes.
>
> Number 2 is already done. We special case the few non-power-of-2
> cases that actually get used.
>
> As for the rest, I had a patch (before the pch merge) that changed
> the allocator such that there were only two size buckets: larger
> and smaller than 1 page. I did get somewhat better peak memory
> usage, but the compiler actually slowed down some more (!), which
> is why I havn't pushed the code in.
Err, the generational copying collector patch i posted actually solves 1 +
2 + part of 3, but only for things besides rtl and trees (which are
pointed to by non-roots, and thus, would require stack scanning, etc).
--Dan
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-04 2:03 ` Richard Henderson
@ 2003-02-04 2:26 ` Zack Weinberg
2003-02-04 4:14 ` Daniel Berlin
1 sibling, 0 replies; 115+ messages in thread
From: Zack Weinberg @ 2003-02-04 2:26 UTC (permalink / raw)
To: Richard Henderson
Cc: Tim Josling, gcc, Neil Booth, Mike Stump, Benjamin Kosnik
[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]
Richard Henderson <rth@redhat.com> writes:
> On Mon, Feb 03, 2003 at 07:04:00PM +1100, Tim Josling wrote:
>> 1. Allocating storage of similar sizes together, sacrificing locality.
>> 2. Wasting space by rounding up allocations to the next power of 2, wasting
>> space and increasing working set sizes.
>> 3. Having bits of GC code all over the place impacting code locality and
>> working set sizes.
>
> Number 2 is already done. We special case the few non-power-of-2
> cases that actually get used.
This turns out not to be the case. I have statistics saying that, in
an average compilation, nontrivial numbers of objects are allocated in
every size that's a multiple of 4 between 4 and 60 bytes (inclusive)
on a 32-bit system; on a 64-bit system, it's every multiple of 8
between 8 and 120 bytes.
At the time I did these calculations, the optimal set of bucket sizes
for an average compilation, in terms solely of memory usage, was
[8 12 16 24 28 32 40 52 56 64 88 112 192 256 272 292 312 340 372 408
452 512 584 680 816 1024 1364 2048 >2048]. I never tried to do
anything with these numbers because they're fragile against changes to
the compiler (for instance, 112 is in there because it was
sizeof(struct tree_decl) at the time) and making them robust was too
hard.
Attached is a gnumeric spreadsheet with all my calculations - I'm
afraid this was a long time ago and I no longer remember what the
column heads mean.
zw
[-- Attachment #2: bucket-sizes.gnumeric --]
[-- Type: application/x-gnumeric, Size: 65086 bytes --]
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 19:50 ` Tim Josling
2003-02-03 21:54 ` Devang Patel
2003-02-04 0:05 ` Tim Hollebeek
@ 2003-02-04 2:03 ` Richard Henderson
2003-02-04 2:26 ` Zack Weinberg
2003-02-04 4:14 ` Daniel Berlin
2 siblings, 2 replies; 115+ messages in thread
From: Richard Henderson @ 2003-02-04 2:03 UTC (permalink / raw)
To: Tim Josling; +Cc: gcc, Neil Booth, Mike Stump, Benjamin Kosnik
On Mon, Feb 03, 2003 at 07:04:00PM +1100, Tim Josling wrote:
> 1. Allocating storage of similar sizes together, sacrificing locality.
> 2. Wasting space by rounding up allocations to the next power of 2, wasting
> space and increasing working set sizes.
> 3. Having bits of GC code all over the place impacting code locality and
> working set sizes.
Number 2 is already done. We special case the few non-power-of-2
cases that actually get used.
As for the rest, I had a patch (before the pch merge) that changed
the allocator such that there were only two size buckets: larger
and smaller than 1 page. I did get somewhat better peak memory
usage, but the compiler actually slowed down some more (!), which
is why I havn't pushed the code in.
r~
^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: GCC 3.3, GCC 3.4
2003-02-03 22:30 ` Jack Lloyd
@ 2003-02-04 1:21 ` Scott Robert Ladd
0 siblings, 0 replies; 115+ messages in thread
From: Scott Robert Ladd @ 2003-02-04 1:21 UTC (permalink / raw)
To: Jack Lloyd; +Cc: gcc
> I can't imagine what exactly a core gcc would look like;
> what features would it include or not include as compared
> to a standard FSF release?
To me, the core is the ability to compile the required languages into
working object code. However...
> As you can tell from my wishy-washy language, I don't really know what I'm
> talking about. :)
...I'm probably the one who's ignorant in this regard. For example, ABI
differences between versions of gcc would render them incompatible, in spite
of the different compiler's ability to compile the same source code.
What I suggested may not be easily possible or practical. What I'm looking
for is a way to address the community-at-large while accomodating the
desires of commercial developers.
..Scott
^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: GCC 3.3, GCC 3.4
[not found] <1044318563.708.247.camel@steven>
@ 2003-02-04 1:13 ` Scott Robert Ladd
0 siblings, 0 replies; 115+ messages in thread
From: Scott Robert Ladd @ 2003-02-04 1:13 UTC (permalink / raw)
To: Steven Bosscher; +Cc: mark, tromey, jbuck, gcc
> That means that you would expect to see people fixing bugs now. I don't
> believe that people push in half-finished features from branches and
> then move on to the next project.
I'm responding to Mark's concern about people adding features and then
moving on to "cooler" activities without participating in bug fixing and
testing.
> If "management" wanted the features to be merged, it's
> probably in their interest that they actually work, too.
Perhaps I misunderstood; I thought Mark was refering to "paying" company
managers who employ people that work on gcc. There has been a problem in the
past with commercial firms releasing "versions" of gcc that are incompatible
with FSF gcc. Such developments are created for the good of the commercial
company, and compatability with the world at large is not important.
Considering the buggy nature of many commercial projects, please forgive me
if I lack faith in management's desire to see things "work."
> In addition to that, there are important areas of common interest. For
> example, compiler speed. This is now a "focal point": The "players" all
> have the same interest here, so it's more than likely that it will be
> fixed one way or another.
I've had a lot of correspondence with people who are very concerned with
gcc's speed; many are working with platforms that do not fall within the
purview of the "players."
Once a technological path is taken, it is difficult to back-track; what may
be a good idea for x86 Linux developers is not necessarily good for all
users of gcc.
> (Let's just hope that no new branches with major work like that show up
> for a while... That too is in everybody's interest IMHO.)
I most heartily agree.
> > A reliable, functional gcc is critical to the success of free
> > software; it is the foundation upon which the other packages
> > rest. Somehow, we need to impress this upon the commercial
> > vendors who fund development. Freedom exists because of
> > cooperation; if the developers of gcc do not cooperate, free
> > software will not succeed in the long run.
>
> Let's not over-dramatize here. Fact is that GCC right now is better
> than ever before, just slower but like I said, that's something that can
> and will be fixed, *because* it's in everybody's interest.
I agree the gcc is better than ever before FOR SPECIFIC ENVIRONMENTS. I have
heard from many people who can not use the current gcc because it's compile
times are excessively slow in their environment.
Commercial sofwtare is driven by marketing; free software is driven by who
is willing (and ABLE) to do the work. In both cases, biases exist that may
not be good for the user community as a whole.
> Linu[sx] has a completely different management style. The FSF does not
> like forks and separate source trees at all. Linus *encourages* forks!
I find it humorous that "free as in speech" software is against the freedom
to create forks. But the definition of "free" is something best left to
another forum... ;)
> GCC is a single big system from the middle end to assembly, and even the
> front ends are not entirely separate. So the linux model doesn't work
> for GCC.
I wasn't clear; my apologies. I don't expect gcc to be manage in the same
fashion as Linux. However, I believe that gcc's current direction favors a
development model that may not be in the best interest of gcc's users.
> Therefore I would think that it is in the vendors' interest that there's
> only one GCC.
Therein lies the problem -- Mark is correct that gcc needs to address the
needs of commercial vendors, lest they create (as they have in the past)
their own unique, incompatible versions. However, commercial concerns may
not necessarily mesh with each other (Vendor A may want feature X, while
vendor B wants Y) or members of the broader community (compile speed).
..Scott
^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: GCC 3.3, GCC 3.4
@ 2003-02-04 0:31 Steven Bosscher
0 siblings, 0 replies; 115+ messages in thread
From: Steven Bosscher @ 2003-02-04 0:31 UTC (permalink / raw)
To: gcc
[ Yuck, I'm a spammer according to the mail server :-/ ]
Scott Robert Ladd wrote:
> Mark Mitchell wrote:
> > As soon as they implement one feature so that it mostly works,
> > they are off to implement another, often due to constraints from
> > management. As a result, they don't have time to fix bugs, even
> > bugs in the work they just did. We often get many of the
> > regressions out, but a few hard ones linger.
>
> (snip)
>
> > We have nobody that can fill that supervisory role. It is
> > simply not possible; the players have very divergent interests.
>
> The above is a serious threat to the success of free software.
> The lack ofcoherent cooperation is more troublesome than any
> worries about whether a certain OS should be called "Linux" or
> "GNU/Linux".
That's not entirely true really.
Yes, the number of regressions has been growing lately because everybody
had his/her pet project. (I have said before that there were too many
branches). Right now most of these projects are being merged or have
already been merged. The only really seriously hugely different active
branch is the tree-ssa branch, and only three or four people are
focusing on that branch.
That means that you would expect to see people fixing bugs now. I don't
believe that people push in half-finished features from branches and
then move on to the next project. If "management" wanted the features
to be merged, it's probably in their interest that they actually work,
too.
In addition to that, there are important areas of common interest. For
example, compiler speed. This is now a "focal point": The "players" all
have the same interest here, so it's more than likely that it will be
fixed one way or another.
(Let's just hope that no new branches with major work like that show up
for a while... That too is in everybody's interest IMHO.)
> A reliable, functional gcc is critical to the success of free
> software; it is the foundation upon which the other packages
> rest. Somehow, we need to impress this upon the commercial
> vendors who fund development. Freedom exists because of
> cooperation; if the developers of gcc do not cooperate, free
> software will not succeed in the long run.
Let's not over-dramatize here. Fact is that GCC right now is better
than ever before, just slower but like I said, that's something that can
and will be fixed, *because* it's in everybody's interest.
> > In some other free software projects, people do fill that
> > supervisory role. Linus is the ultimate authority for Linux,
> > for example. We have a different structure.
>
> Linux can be rather chaotic, even with Linus' influence. True,
> he controls the definitive distribution -- but there are many
> side branches and unique versions for each distro. Remember the
> fracas over the Linux VM? Is it possible that FSF gcc should
> define a core gcc, with possible branches for vendor specific
> variants?
Linu[sx] has a completely different management style. The FSF does not
like forks and separate source trees at all. Linus *encourages* forks!
Anyone can take bits and pieces from eachothers tree because there's no
copyright assignment to, say. Linus. So this wouldn't work for GCC.
Also, linux has far more independent subsystems (archs, file systems,
etc). and people can hack on their favorite part pretty much independent
of each other.
GCC is a single big system from the middle end to assembly, and even the
front ends are not entirely separate. So the linux model doesn't work
for GCC.
Therefore I would think that it is in the vendors' interest that there's
only one GCC.
Greetz
Steven
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 19:50 ` Tim Josling
2003-02-03 21:54 ` Devang Patel
@ 2003-02-04 0:05 ` Tim Hollebeek
2003-02-04 20:07 ` Tim Josling
2003-02-04 2:03 ` Richard Henderson
2 siblings, 1 reply; 115+ messages in thread
From: Tim Hollebeek @ 2003-02-04 0:05 UTC (permalink / raw)
To: Tim Josling; +Cc: gcc, Neil Booth, Mike Stump, Benjamin Kosnik
> Use a simple contiguous allocator, up to a certain amount of memory. If that
> runs out, restart the compile using ggc-page. Most compiles would not be
> affected, and the few that do need GC will get it without too much overhead.
> You could have an option -ggc-force to avoid the restarts.
it would be even more interesting to find a (perhaps file size based)
heuristic that can predict memory needs well enough to usually get the
decision right up front.
-Tim
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 22:34 ` Tom Tromey
@ 2003-02-03 23:03 ` David Edelsohn
0 siblings, 0 replies; 115+ messages in thread
From: David Edelsohn @ 2003-02-03 23:03 UTC (permalink / raw)
To: tromey; +Cc: Mark Mitchell, Benjamin Kosnik, jbuck, gcc
>>>>> Tom Tromey writes:
> What I understood is that we would have a mix between a feature-driven
> approach and a date-driven approach.
> For instance, when the 3.3 branch was made we
> could have all agreed: "PCH, the new C++ parser, and the new RA will
> all be in 3.4 -- they are all major new features that we collectively
> consider to be ready. However, the priority is to stabilize 3.3. So,
> if a merge of one of these branches goes past the ordinary stage 1
> dates, that's ok". We can still apply the usual thinking we apply
> right now. For instance, tree-ssa wasn't ready for 3.3 by the old
> rules, and it wouldn't be by the new ones either. If it somehow was
> prepared before, say, PCH was merged in, we could still say "no, that
> is a 3.4 feature".
Thank you very much for your clarification. This matches what I
was trying to describe.
Thanks, David
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:10 ` Mark Mitchell
2003-02-03 21:31 ` David Edelsohn
2003-02-03 21:45 ` Benjamin Kosnik
@ 2003-02-03 22:34 ` Tom Tromey
2003-02-03 23:03 ` David Edelsohn
2 siblings, 1 reply; 115+ messages in thread
From: Tom Tromey @ 2003-02-03 22:34 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Benjamin Kosnik, dje, jbuck, gcc
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
Mark> That's basically a feature-driven approach -- "we want these new
Mark> features". The problem with that is that we have no way of
Mark> knowing whether people will actually do the work to implement
Mark> the features or not.
Perhaps I misunderstood David's suggestion.
What I understood is that we would have a mix between a feature-driven
approach and a date-driven approach.
For small patches and features, we would use dates and stages as we do
now.
For the merging of major branches, we would make determinations based
on features, presumably modified by the likelihood of a given branch
being ready.
I see this idea more as a realignment of our current approach than a
major new approach. In particular I think it tries to address a
specific problem, namely that some of our core developers have
incentive to avoid working on a release branch in favor of getting
their new work into the main line.
Mark> Right now, we have a window in which to merge branches. If
Mark> you're ready, you merge; if you're not, you don't. We
Mark> successfuly merged some major technology that way for 3.4.
I agree, and I wouldn't change the readiness requirement.
It seems to me that the merges for 3.4 were timed in such as way as to
cause a penalty for 3.3. For instance, my impression is that the new
C++ parser required many bug fixes after it was merged in. Since the
Stage 1 window is pretty narrow, you had a lot of incentive to merge
it as soon as the window opened. This meant a lot of unavoidable bug
fixing (I think we can assume that no branch will get as much testing
as the trunk, and therefore any major merge will be bug-free mostly by
accident) during the time that 3.3 was, in theory, also being
prepared.
I don't think any of these decisions were made in error, especially
given current rules.
However, perhaps the timing could have been different with a different
approach to the stages. For instance, when the 3.3 branch was made we
could have all agreed: "PCH, the new C++ parser, and the new RA will
all be in 3.4 -- they are all major new features that we collectively
consider to be ready. However, the priority is to stabilize 3.3. So,
if a merge of one of these branches goes past the ordinary stage 1
dates, that's ok". We can still apply the usual thinking we apply
right now. For instance, tree-ssa wasn't ready for 3.3 by the old
rules, and it wouldn't be by the new ones either. If it somehow was
prepared before, say, PCH was merged in, we could still say "no, that
is a 3.4 feature".
Tom
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:54 ` Devang Patel
@ 2003-02-03 22:32 ` Geoff Keating
2003-02-04 20:17 ` Tim Josling
1 sibling, 0 replies; 115+ messages in thread
From: Geoff Keating @ 2003-02-03 22:32 UTC (permalink / raw)
To: Devang Patel; +Cc: gcc, Matt Austern
Devang Patel <dpatel@apple.com> writes:
> On Monday, February 3, 2003, at 12:04 AM, Tim Josling wrote:
>
> >
> >> On Thursday, January 30, 2003, at 03:38 PM, Neil Booth wrote:
> >>> I'm interested in improving the quality of GCC. Your statment above
> >>> indicates you're interested in pointing to a number and saying "look,
> >>> it's lower", regardless of what that means long-term. Hell, let's
> >>> not free anything at all and turn GC off altogether; GCC would be
> >>> faster
> >>> for 90% of files I imagine.
> >>
> >> Guess what? For smaller programs, it already does that! So, you are
> >> just describing status quo.
> >
> > It is one thing to stop collecting; it is another to turn off GC.
> >
> > Tests I did last year showed that even without doing collection, gcc
> > is slowed
> > down by the requirements of GC:
> >
> > 1. Allocating storage of similar sizes together, sacrificing locality.
> > 2. Wasting space by rounding up allocations to the next power of 2,
> > wasting
> > space and increasing working set sizes.
> > 3. Having bits of GC code all over the place impacting code locality
> > and
> > working set sizes.
> >
> > Turning off GC slows down the part of the build of GCC attributable
> > to the
> > xgcc/cc1/ld by 5%.
> >
> > However removing it and allocating sequentially (each allocation is
> > next to
> > the previous one) reduces build xgcc/cc1/ld compile time by about 5%.
> >
> > Add these together and the requirements of GC slow down the compiler
> > by about
> > 10% (though collecting gets half of it back)! And most compiles
> > don't need or
> > benefit from it!
>
> Matt Austern at Apple did similar experiment by using ggc placeholder.
> (same interface as ggc, no collection, allocate memory using mmap in
> chunks and
> satisfy memory allocation requests from these chunks etc..).
>
> He got around ~12% speedup for sample c++ source.
To be precise, Matt found that the speedup of using the ggc
placeholder was about equivalent to the speedup of using ggc-page but
disabling garbage collection. This contradicts the results that Tim
Josling got above.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: GCC 3.3, GCC 3.4
2003-02-03 22:16 ` Scott Robert Ladd
@ 2003-02-03 22:30 ` Jack Lloyd
2003-02-04 1:21 ` Scott Robert Ladd
0 siblings, 1 reply; 115+ messages in thread
From: Jack Lloyd @ 2003-02-03 22:30 UTC (permalink / raw)
To: Scott Robert Ladd; +Cc: gcc
On Mon, 3 Feb 2003, Scott Robert Ladd wrote:
> Linux can be rather chaotic, even with Linus' influence. True, he controls
> the definitive distribution -- but there are many side branches and unique
> versions for each distro. Remember the fracas over the Linux VM? Is it
> possible that FSF gcc should define a core gcc, with possible branches for
> vendor specific variants?
From what I've seen of the various GCC branches, it doesn't seem so modular
as to really allow that kind of thing. With the local kernel variants, it
mostly seems like "let's include feature X" (ext3, zero copy NFS, whatever)
before Linus decides that he wants it in his tree. Even with the 2 or 3 VMs
that were running around in 2.4, most of the changes were very
pick-one-VM-or-the-other, and didn't affect the majority of the tree
(drivers, bootstrap process, etc). I can't imagine what exactly a core gcc
would look like; what features would it include or not include as compared
to a standard FSF release?
As you can tell from my wishy-washy language, I don't really know what I'm
talking about. :)
-Jack
^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: GCC 3.3, GCC 3.4
2003-02-03 21:53 ` Mark Mitchell
@ 2003-02-03 22:16 ` Scott Robert Ladd
2003-02-03 22:30 ` Jack Lloyd
0 siblings, 1 reply; 115+ messages in thread
From: Scott Robert Ladd @ 2003-02-03 22:16 UTC (permalink / raw)
To: Mark Mitchell, David Edelsohn; +Cc: Benjamin Kosnik, tromey, jbuck, gcc
Mark Mitchell wrote:
> The biggest real problem is that our developers are overbooked.
> As soon as they implement one feature so that it mostly works, they are
> off to implement another, often due to constraints from management. As
> a result, they don't have time to fix bugs, even bugs in the work they
> just did. We often get many of the regressions out, but a few hard ones
> linger.
>
(snip)
>
> We have nobody that can fill that supervisory role. It is simply not
> possible; the players have very divergent interests.
The above is a serious threat to the success of free software. The lack of
coherent cooperation is more troublesome than any worries about whether a
certain OS should be called "Linux" or "GNU/Linux".
A reliable, functional gcc is critical to the success of free software; it
is the foundation upon which the other packages rest. Somehow, we need to
impress this upon the commercial vendors who fund development. Freedom
exists because of cooperation; if the developers of gcc do not cooperate,
free software will not succeed in the long run.
> In some other free software projects, people do fill that supervisory
> role. Linus is the ultimate authority for Linux, for example. We
> have a different structure.
Linux can be rather chaotic, even with Linus' influence. True, he controls
the definitive distribution -- but there are many side branches and unique
versions for each distro. Remember the fracas over the Linux VM? Is it
possible that FSF gcc should define a core gcc, with possible branches for
vendor specific variants?
> I suggest the following:
>
> - Rather than free-form discussion on this mailing list, let's
> write up complete proposal(s) and post them on our web site.
Good idea. The process is already rolling for the next few releases; once
those are complete, we can try to improve the process.
..Scott
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Professional programming for science and engineering;
Interesting and unusual bits of very free code.
^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: GCC 3.3, GCC 3.4
2003-02-03 21:31 ` David Edelsohn
2003-02-03 21:53 ` Mark Mitchell
@ 2003-02-03 22:03 ` Scott Robert Ladd
1 sibling, 0 replies; 115+ messages in thread
From: Scott Robert Ladd @ 2003-02-03 22:03 UTC (permalink / raw)
To: David Edelsohn, Mark Mitchell; +Cc: Benjamin Kosnik, tromey, jbuck, gcc
Dave Edelsohn wrote:
> Either extreme of schedule driven or feature driven development
> causes grief. We need to find a flexible middle ground. I think our
> current schedule places developers in a catch-22 situation that is
> discouraging and demoralizing.
Discouraging, in my case.
I am seriously interested in working on gcc -- in fact, I've been active in
the "GOMP" group that has just started working on an OpenMP implementation.
However, I find the current schedule rather daunting; we're talking 3.2.2,
3.3, and 3.4 in (what appears to me) rapid succession. I think there is a
middle ground between Microsoft's "yawn, we'll fix it someday" attitude, and
rabbit-rapid releases.
> Again, accomodating developers both frees up more developers to
> fix bugs in the current release branches and encourages those developers
> to fix bugs in the next release branch so that their improvements are
> available in a release. Currently the development process discourages
> developers and creates the small pool of people fixing bugs, about which
> you have complained. The current policy is part of the problem.
In my experience, the best development process is rapid, small releases
punctuated by occasional major releases. In gcc terms, that might mean (and
this is *only* a suggestion) a 0.0.x release every month or six weeks, with
bug and regression fixes, with major releases (0.x) every four to six
months. This provide stability while also "moving forward."
> GCC releases already are delayed because of regressions and PRs,
> so allowing a longer window for integrating recommended goal features will
> not make it worse if the same developers are able to help with bug fixes.
Moving too quickly in large chunks is a recipe for generating bugs. I've
just slowed one of my commercial projects for that very reason; my client
kept adding or changing major features before we could straighten out bugs
and "refactors." Getting to market is a Good Thing; getting to market with a
troubled product is a Bad Thing.
Writing cool new features is always more fun the debugging -- but debugging
is less onerous and more fun if taken in small bites. And bugs may not
appear as often if we move to a more graduated process.
..Scott
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Professional programming for science and engineering;
Interesting and unusual bits of very free code.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:45 ` Benjamin Kosnik
@ 2003-02-03 21:56 ` Mark Mitchell
0 siblings, 0 replies; 115+ messages in thread
From: Mark Mitchell @ 2003-02-03 21:56 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: tromey, dje, jbuck, gcc
--On Monday, February 03, 2003 03:45:50 PM -0600 Benjamin Kosnik
<bkoz@redhat.com> wrote:
>
>> Right now, we have a window in which to merge branches. If you're
>> ready, you merge; if you're not, you don't. We successfuly merged
>> some major technology that way for 3.4.
>
> I guess your definition of "ready to merge" is what I don't understand.
> Could you please elaborate on it?
The PCH and parser branches caused no regressions in the testsuite, and,
in the opinion of people with approval authority, were in good shape.
They met the criteria of working on a variety of platforms.
I don't know of branches that are not in that shape, because I haven't
been involved with them. This is something where we have to trust the
branch maintainers, largely.
However, certainly the parser wasn't ready for the last release. For
example, there were still numerous test failures, it was very slow, and
there were pieces of C++ that weren't handled correctly.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 19:50 ` Tim Josling
@ 2003-02-03 21:54 ` Devang Patel
2003-02-03 22:32 ` Geoff Keating
2003-02-04 20:17 ` Tim Josling
2003-02-04 0:05 ` Tim Hollebeek
2003-02-04 2:03 ` Richard Henderson
2 siblings, 2 replies; 115+ messages in thread
From: Devang Patel @ 2003-02-03 21:54 UTC (permalink / raw)
To: Tim Josling; +Cc: Devang Patel, gcc, Matt Austern
On Monday, February 3, 2003, at 12:04 AM, Tim Josling wrote:
>
>> On Thursday, January 30, 2003, at 03:38 PM, Neil Booth wrote:
>>> I'm interested in improving the quality of GCC. Your statment above
>>> indicates you're interested in pointing to a number and saying "look,
>>> it's lower", regardless of what that means long-term. Hell, let's
>>> not free anything at all and turn GC off altogether; GCC would be
>>> faster
>>> for 90% of files I imagine.
>>
>> Guess what? For smaller programs, it already does that! So, you are
>> just describing status quo.
>
> It is one thing to stop collecting; it is another to turn off GC.
>
> Tests I did last year showed that even without doing collection, gcc
> is slowed
> down by the requirements of GC:
>
> 1. Allocating storage of similar sizes together, sacrificing locality.
> 2. Wasting space by rounding up allocations to the next power of 2,
> wasting
> space and increasing working set sizes.
> 3. Having bits of GC code all over the place impacting code locality
> and
> working set sizes.
>
> Turning off GC slows down the part of the build of GCC attributable to
> the
> xgcc/cc1/ld by 5%.
>
> However removing it and allocating sequentially (each allocation is
> next to
> the previous one) reduces build xgcc/cc1/ld compile time by about 5%.
>
> Add these together and the requirements of GC slow down the compiler
> by about
> 10% (though collecting gets half of it back)! And most compiles don't
> need or
> benefit from it!
Matt Austern at Apple did similar experiment by using ggc placeholder.
(same interface as ggc, no collection, allocate memory using mmap in
chunks and
satisfy memory allocation requests from these chunks etc..).
He got around ~12% speedup for sample c++ source.
-Devang
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:31 ` David Edelsohn
@ 2003-02-03 21:53 ` Mark Mitchell
2003-02-03 22:16 ` Scott Robert Ladd
2003-02-03 22:03 ` Scott Robert Ladd
1 sibling, 1 reply; 115+ messages in thread
From: Mark Mitchell @ 2003-02-03 21:53 UTC (permalink / raw)
To: David Edelsohn; +Cc: Benjamin Kosnik, tromey, jbuck, gcc
> Again, accomodating developers both frees up more developers to
> fix bugs in the current release branches and encourages those developers
> to fix bugs in the next release branch so that their improvements are
> available in a release.
We have already modified the schedule to eliminate the release/freeze
overlap that we had; they are now offset by a month. I've already asked
what branches people want to get in to 3.4, and when they're likely to
be ready.
The biggest real problem is that our developers are overbooked.
As soon as they implement one feature so that it mostly works, they are
off to implement another, often due to constraints from management. As
a result, they don't have time to fix bugs, even bugs in the work they
just did. We often get many of the regressions out, but a few hard ones
linger.
In a "traditional" release process, we'd all implement some stuff, and
then fix bugs for a while, and then do a release. Or maybe some of us
would implement and some of us would fix. In either case, someone would
supervise and tell us what was most important and move some fixers to
help implement and some implementors to help fix and so forth.
We have nobody that can fill that supervisory role. It is simply not
possible; the players have very divergent interests.
In some other free software projects, people do fill that supervisory
role. Linus is the ultimate authority for Linux, for example. We
have a different structure.
I am very willing to consider other alternative ways of accomplishing
what I consider the basic goal: making high-quality releases on a
frequent enough basis that most development is focused on the FSF
versions of GCC, rather than on various forks.
I suggest the following:
- Rather than free-form discussion on this mailing list, let's
write up complete proposal(s) and post them on our web site.
- What methodology to you have in mind?
- When do release branches get made?
- When do releases get made?
- Are there development stages? If so, what are they, and
how are the transitions managed?
- Who will make decisions?
- How will conflicts and disagreements be dealt with?
- How will this be an improvement over our current system?
- What primary problems are you trying to solve? How are
they solved?
- What new problems do you forsee? How will they be dealt
with?
I'd expect these to be 3-5 page proposals. When we've got one
or two ready, let's talk about them a bit, present them to the
SC, and decide.
- Let's take this off the table for 3.4. Consider it a 3.5 and
beyond project. Any discussion of this magnitude takes a *lot*
of time and effort.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:10 ` Mark Mitchell
2003-02-03 21:31 ` David Edelsohn
@ 2003-02-03 21:45 ` Benjamin Kosnik
2003-02-03 21:56 ` Mark Mitchell
2003-02-03 22:34 ` Tom Tromey
2 siblings, 1 reply; 115+ messages in thread
From: Benjamin Kosnik @ 2003-02-03 21:45 UTC (permalink / raw)
To: Mark Mitchell; +Cc: tromey, dje, jbuck, gcc
>Right now, we have a window in which to merge branches. If you're
>ready, you merge; if you're not, you don't. We successfuly merged
>some major technology that way for 3.4.
I guess your definition of "ready to merge" is what I don't understand.
Could you please elaborate on it?
If you could, please use as specific examples the pch branch and the new
parser branch. You might also add as an example a branch that is not
ready to merge, just so I have something to compare against.
I'm just thinking about a refinement on the current process, not a
complete overhaul.
-benjamin
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:29 ` Mark Mitchell
2003-02-03 21:41 ` David Edelsohn
@ 2003-02-03 21:42 ` Gabriel Dos Reis
1 sibling, 0 replies; 115+ messages in thread
From: Gabriel Dos Reis @ 2003-02-03 21:42 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Benjamin Kosnik, tromey, dje, jbuck, gcc
Mark Mitchell <mark@codesourcery.com> writes:
| --On Monday, February 03, 2003 10:16:51 PM +0100 Gabriel Dos Reis
| <gdr@integrable-solutions.net> wrote:
|
| > In parallel, we may have an experimental
| > branch in stage 1 for more than 4 months...
|
| Unfortunately, this is how we get weird releases of GCC not based on
| any FSF release.
[...]
| However, this is not a simple problem. It is one I have spent a lot
| of time thinking about and a lot of time talking to people about.
|
| It is over-constrained, and no matter what we do there will be
| some unhappy people.
I believe the current plan is overly constrained. That is what most
of the people have been trying to phrase. If we don't address that
issue now, we'll find ourselves reopening the same debate over and
over. If we don't address that problem now, I think we may see major
contributors asking for extending schedules, over and over.
I know you have been doing a terrific work. On the other hand, I
believe some people are feeling uneasy with not knowing exactly
where they're going, what they'll get in the end. That is not meant
to criticize you.
-- Gaby
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:29 ` Mark Mitchell
@ 2003-02-03 21:41 ` David Edelsohn
2003-02-03 21:42 ` Gabriel Dos Reis
1 sibling, 0 replies; 115+ messages in thread
From: David Edelsohn @ 2003-02-03 21:41 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Gabriel Dos Reis, Benjamin Kosnik, tromey, jbuck, gcc
>>>>> Mark Mitchell writes:
Mark> If we were able to get all the stakeholders (GNU/Linux distributors,
Mark> end users, embedded systems vendors) together to agree on when they
Mark> wanted releases, things would be simpler: it would make sense to
Mark> tailor the releases to their needs. But, in practice, all these
Mark> groups are in conflict.
I conducted a poll of those groups for the GCC SC and they were in
agreement.
Mark> I'd rather see us fixing bugs and making progress towards 3.3 and 3.4
Mark> than opening up a whole new can of worms.
When is a good time to discuss this? With whom? I think we
should welcome an open discussion and feedback about the current
development model.
David
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:10 ` Mark Mitchell
@ 2003-02-03 21:31 ` David Edelsohn
2003-02-03 21:53 ` Mark Mitchell
2003-02-03 22:03 ` Scott Robert Ladd
2003-02-03 21:45 ` Benjamin Kosnik
2003-02-03 22:34 ` Tom Tromey
2 siblings, 2 replies; 115+ messages in thread
From: David Edelsohn @ 2003-02-03 21:31 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Benjamin Kosnik, tromey, jbuck, gcc
>>>>> Mark Mitchell writes:
Mark> --On Monday, February 03, 2003 03:01:51 PM -0600 Benjamin Kosnik
Mark> <bkoz@redhat.com> wrote:
>> On 03 Feb 2003 13:32:38 -0700
>> Tom Tromey <tromey@redhat.com> wrote:
>>
>>> This sounds good to me. What's the next step? Maybe suggest a patch
>>> to the development plan?
>>
>> Sounds good to me.
Mark> It doesn't sound that good to me.
Mark> That's basically a feature-driven approach -- "we want these new
Mark> features". The problem with that is that we have no way of knowing
Mark> whether people will actually do the work to implement the features
Mark> or not. To a large extent, this is where we were way-back-when
Mark> before 3.0; we tried to wait until stuff got done, it always took
Mark> longer than anyone expected, while we were waiting other people
Mark> wanted to add in more stuff, that other stuff was buggy, etc.
Mark, redefining a proposal and then arguing against it is
fallacious reasoning. That is exactly what you are doing. I never
suggested extending the schedule indefinitely.
Either extreme of schedule driven or feature driven development
causes grief. We need to find a flexible middle ground. I think our
current schedule places developers in a catch-22 situation that is
discouraging and demoralizing.
Again, accomodating developers both frees up more developers to
fix bugs in the current release branches and encourages those developers
to fix bugs in the next release branch so that their improvements are
available in a release. Currently the development process discourages
developers and creates the small pool of people fixing bugs, about which
you have complained. The current policy is part of the problem.
GCC releases already are delayed because of regressions and PRs,
so allowing a longer window for integrating recommended goal features will
not make it worse if the same developers are able to help with bug fixes.
David
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:17 ` Gabriel Dos Reis
@ 2003-02-03 21:29 ` Mark Mitchell
2003-02-03 21:41 ` David Edelsohn
2003-02-03 21:42 ` Gabriel Dos Reis
0 siblings, 2 replies; 115+ messages in thread
From: Mark Mitchell @ 2003-02-03 21:29 UTC (permalink / raw)
To: Gabriel Dos Reis, Benjamin Kosnik; +Cc: tromey, dje, jbuck, gcc
--On Monday, February 03, 2003 10:16:51 PM +0100 Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> In parallel, we may have an experimental
> branch in stage 1 for more than 4 months...
Unfortunately, this is how we get weird releases of GCC not based on
any FSF release.
It is something of a disaster for the GCC project when releases get made
out of the middle of nowhere; we get the bug reports, we get crticized,
we have to deal with compatibility issues we didn't know about, and some
of our best contributors end up stabilizing a release we don't really know
exists, with the result that a lot of that work has to be done again in
the mainline later.
If we were able to get all the stakeholders (GNU/Linux distributors,
end users, embedded systems vendors) together to agree on when they
wanted releases, things would be simpler: it would make sense to
tailor the releases to their needs. But, in practice, all these
groups are in conflict.
Arguing over whether particular branches are important, and whether we
should wait for them, and so forth is incredibly unpleasant. That is
what will result if we start trying to plan by weird sets of major
features.
And, at some point we still have to stop and stabilize, and people
will still want to add more features and will still complain that
they can't both fix bugs and implement new stuff.
==
I fully recognize that the current process leaves plenty to be desired.
However, this is not a simple problem. It is one I have spent a lot
of time thinking about and a lot of time talking to people about.
It is over-constrained, and no matter what we do there will be
some unhappy people.
Frankly, I think the process we have now is about as good as any other
process. Not better, but approximately as good. After all, we've done
a number of releases since 3.0, and most have been pretty well received.
Most people agree that, on balance, 3.2.1 was a good release.
I'd rather see us fixing bugs and making progress towards 3.3 and 3.4
than opening up a whole new can of worms.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:02 ` Benjamin Kosnik
2003-02-03 21:10 ` Mark Mitchell
@ 2003-02-03 21:17 ` Gabriel Dos Reis
2003-02-03 21:29 ` Mark Mitchell
1 sibling, 1 reply; 115+ messages in thread
From: Gabriel Dos Reis @ 2003-02-03 21:17 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: tromey, dje, jbuck, gcc, mark
Benjamin Kosnik <bkoz@redhat.com> writes:
| On 03 Feb 2003 13:32:38 -0700
| Tom Tromey <tromey@redhat.com> wrote:
|
| >This sounds good to me. What's the next step? Maybe suggest a patch
| >to the development plan?
|
| Sounds good to me.
Agreed. However, we should set a upper bound on the duration of stage
1 -- it won't be practical to have mainline in stage 1 for two
years...
|
| Do you think it sounds like a good idea to try and fit this new process
| into 3.4? Ie, pick what branches get merged for it?
I'll try to expand on an idea I emitted earlier.
Firstly, I'm not convinced we should rush into making the highest
possible number of MAJOR releases per rather. I think regular (e.g. on
4-months basis) releases would be highly welcome; for the most part,
they would be dot releases. In parallel, we may have an experimental
branch in stage 1 for more than 4 months...
-- Gaby
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 21:02 ` Benjamin Kosnik
@ 2003-02-03 21:10 ` Mark Mitchell
2003-02-03 21:31 ` David Edelsohn
` (2 more replies)
2003-02-03 21:17 ` Gabriel Dos Reis
1 sibling, 3 replies; 115+ messages in thread
From: Mark Mitchell @ 2003-02-03 21:10 UTC (permalink / raw)
To: Benjamin Kosnik, tromey; +Cc: dje, jbuck, gcc
--On Monday, February 03, 2003 03:01:51 PM -0600 Benjamin Kosnik
<bkoz@redhat.com> wrote:
> On 03 Feb 2003 13:32:38 -0700
> Tom Tromey <tromey@redhat.com> wrote:
>
>> This sounds good to me. What's the next step? Maybe suggest a patch
>> to the development plan?
>
> Sounds good to me.
It doesn't sound that good to me.
That's basically a feature-driven approach -- "we want these new
features". The problem with that is that we have no way of knowing
whether people will actually do the work to implement the features
or not. To a large extent, this is where we were way-back-when
before 3.0; we tried to wait until stuff got done, it always took
longer than anyone expected, while we were waiting other people
wanted to add in more stuff, that other stuff was buggy, etc.
Right now, we have a window in which to merge branches. If you're
ready, you merge; if you're not, you don't. We successfuly merged
some major technology that way for 3.4.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-03 20:44 ` Tom Tromey
@ 2003-02-03 21:02 ` Benjamin Kosnik
2003-02-03 21:10 ` Mark Mitchell
2003-02-03 21:17 ` Gabriel Dos Reis
0 siblings, 2 replies; 115+ messages in thread
From: Benjamin Kosnik @ 2003-02-03 21:02 UTC (permalink / raw)
To: tromey; +Cc: dje, jbuck, gcc, bkoz, mark
On 03 Feb 2003 13:32:38 -0700
Tom Tromey <tromey@redhat.com> wrote:
>This sounds good to me. What's the next step? Maybe suggest a patch
>to the development plan?
Sounds good to me.
Do you think it sounds like a good idea to try and fit this new process
into 3.4? Ie, pick what branches get merged for it?
-benjamin
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
[not found] <200301312121.QAA22864@makai.watson.ibm.com>
@ 2003-02-03 20:44 ` Tom Tromey
2003-02-03 21:02 ` Benjamin Kosnik
0 siblings, 1 reply; 115+ messages in thread
From: Tom Tromey @ 2003-02-03 20:44 UTC (permalink / raw)
To: David Edelsohn; +Cc: Joe Buck, gcc, Benjamin Kosnik, Mark Mitchell
>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:
David> Instead of the development plan being driven solely by dates, I
David> would like to see some technology goals. For instance, we want
David> to merge in 3.4-bib, itanium-branch, pch-branch, rtlopt-branch,
David> and new-regalloc. We allow those branches in plan to be merged
David> after Stage 1 and after the GCC 3.3 release, if necessary.
David> That's controlled instability, as opposed to considering any
David> major patch far into the GCC 3.4 development cycle. We don't
David> want a deluge of patches right after the GCC 3.3 release, but
David> we also shouldn't make it so hard for developers.
This sounds good to me. What's the next step? Maybe suggest a patch
to the development plan?
Tom
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
[not found] <1043976898.27601.ezmlm@gcc.gnu.org>
@ 2003-02-03 19:50 ` Tim Josling
2003-02-03 21:54 ` Devang Patel
` (2 more replies)
0 siblings, 3 replies; 115+ messages in thread
From: Tim Josling @ 2003-02-03 19:50 UTC (permalink / raw)
To: gcc; +Cc: Neil Booth, Mike Stump, Benjamin Kosnik
> On Thursday, January 30, 2003, at 03:38 PM, Neil Booth wrote:
> > I'm interested in improving the quality of GCC. Your statment above
> > indicates you're interested in pointing to a number and saying "look,
> > it's lower", regardless of what that means long-term. Hell, let's
> > not free anything at all and turn GC off altogether; GCC would be
> > faster
> > for 90% of files I imagine.
>
> Guess what? For smaller programs, it already does that! So, you are
> just describing status quo.
It is one thing to stop collecting; it is another to turn off GC.
Tests I did last year showed that even without doing collection, gcc is slowed
down by the requirements of GC:
1. Allocating storage of similar sizes together, sacrificing locality.
2. Wasting space by rounding up allocations to the next power of 2, wasting
space and increasing working set sizes.
3. Having bits of GC code all over the place impacting code locality and
working set sizes.
Turning off GC slows down the part of the build of GCC attributable to the
xgcc/cc1/ld by 5%.
However removing it and allocating sequentially (each allocation is next to
the previous one) reduces build xgcc/cc1/ld compile time by about 5%.
Add these together and the requirements of GC slow down the compiler by about
10% (though collecting gets half of it back)! And most compiles don't need or
benefit from it!
One possible solution is:
Use a simple contiguous allocator, up to a certain amount of memory. If that
runs out, restart the compile using ggc-page. Most compiles would not be
affected, and the few that do need GC will get it without too much overhead.
You could have an option -ggc-force to avoid the restarts.
Tim Josling
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
[not found] ` <jmy9516lsd.fsf@desire.geoffk.org>
@ 2003-02-01 4:32 ` Kaveh R. Ghazi
0 siblings, 0 replies; 115+ messages in thread
From: Kaveh R. Ghazi @ 2003-02-01 4:32 UTC (permalink / raw)
To: geoffk; +Cc: gcc, jbuck, mark
> From: Geoff Keating <geoffk@geoffk.org>
>
> I see that gcc-testresults now gets quite a bit of traffic anyway, so
> I'll add a bit of code to send summary results there.
Thanks.
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-01 0:21 ` Michael Matz
@ 2003-02-01 3:18 ` David Edelsohn
0 siblings, 0 replies; 115+ messages in thread
From: David Edelsohn @ 2003-02-01 3:18 UTC (permalink / raw)
To: Michael Matz; +Cc: Mark Mitchell, Matt Austern, gcc
>>>>> Michael Matz writes:
Michael> There are parts in the regalloc branch, which are not in a mergeable
Michael> state and I'm not optimistic about getting them into such until the
Michael> deadline (partly they are still buggy, and partly they duplicate so much
Michael> code, that it's not funny). This includes all the machinery around
Michael> pre-reload. I believe, it's possible to merge most parts except
Michael> pre-reload to mainline in six weeks, but it requires some porting in the
Michael> allocator code itself (to not make use of pre-reload), so is not simple
Michael> copy-over work.
And there are a number of groups standing by to help with this
porting effort.
David
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-01 1:28 ` Joe Buck
@ 2003-02-01 1:49 ` Michel LESPINASSE
0 siblings, 0 replies; 115+ messages in thread
From: Michel LESPINASSE @ 2003-02-01 1:49 UTC (permalink / raw)
To: Joe Buck; +Cc: Tom Lord, mstump, gcc
On Fri, Jan 31, 2003 at 05:28:39PM -0800, Joe Buck wrote:
> On Fri, Jan 31, 2003 at 03:11:56PM -0800, Tom Lord wrote:
> > Please see my reply to Kenner and Mark on the subject of better
> > alternatives.
>
> Claims that an alternative is better need to be backed up. If your
> "continuous release management" scheme is better, please point to
> a sizable free software project that uses it. If you cannot, then
> it may not be socially responsible to risk GCC for the sake of your
> experiment.
What Tom is arguing for reminds me a lot of what debian is doing with
its testing distribution. Their goal here is to always maintain one
software tree (testing in their case) in a close-to-releaseable
state. From what I understand, they're also pushing more in that
direction as time goes, for example there is an effort to keep the
boot-floppies up to date so they can install testing at any time,
rather than just rushing to make them work before a supposed release
date. As far as I can tell, this has been a very good model for Debian
since they adopted it. I understand it might be harder to adopt for
the GCC project, and in particular harder to automate, since there you
can not reason in terms of packages to move, but rather in terms of
branches to merge, which needs to be a manual operation.
Cheers,
--
Michel "Walken" LESPINASSE
Is this the best that god can do ? Then I'm not impressed.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-02-01 1:32 ` Mark Mitchell
@ 2003-02-01 1:43 ` Jan Hubicka
0 siblings, 0 replies; 115+ messages in thread
From: Jan Hubicka @ 2003-02-01 1:43 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Benjamin Kosnik, Matt Austern, jsm28, gcc
>
>
> --On Friday, January 31, 2003 04:54:29 PM -0600 Benjamin Kosnik
> <bkoz@redhat.com> wrote:
>
> >
> >Agreed. Seems to be a common concern.
> >
> >Mark, I think keeping at least a month in between the two events is
> >advisable.
>
> That actually is our normal plan.
>
> But it's a bit hard to have it both ways -- if we can't commit to a
> 3.3 date (as you suggested yesterday that we should not) then we can't
> really schedule the 3.4 cutoff.
>
> But, we have been in 3.4 stage one for quite some time now, and Geoff
> and I both managed to get our work ready at that time. Stage 1 isn't
> really for *developing* new major changes, it's for *integrating* them.
We would like to integrate the rtlopt branch as well. The changes are
already developed for quite some time, so I believe they are ready for
being added into mainline now. Hope it will fir the schedule.
Honza
>
> We could just close the mainline during a release, but it's very clear
> that nobody wants to do that -- we want to make sure development can
> happen while a release is being prepared. That inherently means that
> there's going to be some division of people's time between the two
> branches.
>
> --
> Mark Mitchell mark@codesourcery.com
> CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
[not found] <20030131165429.32d4d907.bkoz@redhat.com>
@ 2003-02-01 1:32 ` Mark Mitchell
2003-02-01 1:43 ` Jan Hubicka
0 siblings, 1 reply; 115+ messages in thread
From: Mark Mitchell @ 2003-02-01 1:32 UTC (permalink / raw)
To: Benjamin Kosnik, Matt Austern; +Cc: jsm28, gcc
--On Friday, January 31, 2003 04:54:29 PM -0600 Benjamin Kosnik
<bkoz@redhat.com> wrote:
>
> Agreed. Seems to be a common concern.
>
> Mark, I think keeping at least a month in between the two events is
> advisable.
That actually is our normal plan.
But it's a bit hard to have it both ways -- if we can't commit to a
3.3 date (as you suggested yesterday that we should not) then we can't
really schedule the 3.4 cutoff.
But, we have been in 3.4 stage one for quite some time now, and Geoff
and I both managed to get our work ready at that time. Stage 1 isn't
really for *developing* new major changes, it's for *integrating* them.
We could just close the mainline during a release, but it's very clear
that nobody wants to do that -- we want to make sure development can
happen while a release is being prepared. That inherently means that
there's going to be some division of people's time between the two
branches.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
[not found] ` <200301312311.PAA15835@emf.net>
@ 2003-02-01 1:28 ` Joe Buck
2003-02-01 1:49 ` Michel LESPINASSE
0 siblings, 1 reply; 115+ messages in thread
From: Joe Buck @ 2003-02-01 1:28 UTC (permalink / raw)
To: Tom Lord; +Cc: mstump, gcc
On Fri, Jan 31, 2003 at 03:11:56PM -0800, Tom Lord wrote:
> Please see my reply to Kenner and Mark on the subject of better
> alternatives.
Claims that an alternative is better need to be backed up. If your
"continuous release management" scheme is better, please point to
a sizable free software project that uses it. If you cannot, then
it may not be socially responsible to risk GCC for the sake of your
experiment.
As for the rest, I have no interest in any effort to "put our foot down".
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 20:23 ` Mark Mitchell
@ 2003-02-01 0:21 ` Michael Matz
2003-02-01 3:18 ` David Edelsohn
0 siblings, 1 reply; 115+ messages in thread
From: Michael Matz @ 2003-02-01 0:21 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Matt Austern, gcc
Hi,
On Fri, 31 Jan 2003, Mark Mitchell wrote:
> > I have two concerns about the March 15 deadline.
> >
> > First, a technical concern: people have also been talking about putting
> > the new register allocator into 3.4. I'd like to see that as a third
> > major piece of new technology, which would imply a later deadline.
>
> What's the prognosis for the register allocator? When will it be ready
> to check in, and when will the bugs be out?
There are parts in the regalloc branch, which are not in a mergeable
state and I'm not optimistic about getting them into such until the
deadline (partly they are still buggy, and partly they duplicate so much
code, that it's not funny). This includes all the machinery around
pre-reload. I believe, it's possible to merge most parts except
pre-reload to mainline in six weeks, but it requires some porting in the
allocator code itself (to not make use of pre-reload), so is not simple
copy-over work.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
[not found] <200301312258.OAA14911@emf.net>
@ 2003-02-01 0:00 ` Mike Stump
0 siblings, 0 replies; 115+ messages in thread
From: Mike Stump @ 2003-02-01 0:00 UTC (permalink / raw)
To: Tom Lord; +Cc: kenner, mark, gcc
On Friday, January 31, 2003, at 02:58 PM, Tom Lord wrote:
> No, problem (2), the funding situation, is the root problem.
> Mark, SC -- it's time to put your foot down.
Let's not get bogged down in a flame fest over this. Let's just say
that some of us disagree.
I will say that the gcc model is working and does go through
refinements from time to time. Use your model on arch, and tell us how
well it works. After you have a success, try it on another project,
and so on, and eventually, we will say, wow, look how well that model
works, let use it. Don't try and beat us into using it, we won't come
around that way.
So, how many projects use your model and are successes because of it?
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 22:59 ` Joel Sherrill
@ 2003-01-31 23:42 ` Devang Patel
0 siblings, 0 replies; 115+ messages in thread
From: Devang Patel @ 2003-01-31 23:42 UTC (permalink / raw)
To: Joel Sherrill; +Cc: Devang Patel, Mark Mitchell, gcc
On Friday, January 31, 2003, at 12:59 PM, Joel Sherrill wrote:
> The large number of host and target combinations means that it is
> probably just a fact of life that what is an improvement to one
> target has a probability to break something else.
Exactly. That's the point.
Can we change this fact of life? Is it possible to test improvements
before they go into cvs ? Is it possible to change current situation?
(I do not have answer for all these questions).
-Devang
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 13:50 ` Joseph S. Myers
2003-01-31 18:02 ` Mark Mitchell
@ 2003-01-31 23:12 ` Phil Edwards
1 sibling, 0 replies; 115+ messages in thread
From: Phil Edwards @ 2003-01-31 23:12 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Benjamin Kosnik, gcc, mark
On Fri, Jan 31, 2003 at 11:03:41AM +0000, Joseph S. Myers wrote:
> On Thu, 30 Jan 2003, Benjamin Kosnik wrote:
>
> > I think the longer gcc, as a project, goes on without an autobuild
> > continuous regression checker, the worse off things will get. It was
> > nice of Red Hat to initially support this effort, but it is obvious that
> > this time is past as the regression checker is long dead. Somebody else
> > will have to step up with the bandwidth, time, and machine to do this.
>
> The one that Geoff was running at Red Hat is now running at Apple (Darwin
> native only, rather than one native and two cross). I think there's also
> a separate one running on athlon_mp-pc-linux-gnu (look for Autocrasher in
> the gcc-regression archives).
Yeah, but since "make compare" and "make gnucompare" still don't seem to
be identical (on occasion), it generates false alarms (on occasion).
> However, we do need a simple system for anyone (with a fast enough system)
> to be able to set up the tester and run it,
I'm putting the finishing touches on an email-based binary search server.
One could send mail such as
% mail -s 'regression hunt cc1plus 3.3 assemble -O2' foo@foo.foo < PRnnnn.cc
and get back a message saying "It broke somewhere between the 12th and
the 13th."
Phil
--
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
- Edsger Dijkstra, 1930-2002
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 18:02 ` Mark Mitchell
` (2 preceding siblings ...)
2003-01-31 20:31 ` Richard Henderson
@ 2003-01-31 22:59 ` Andreas Jaeger
3 siblings, 0 replies; 115+ messages in thread
From: Andreas Jaeger @ 2003-01-31 22:59 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Joseph S. Myers, Benjamin Kosnik, gcc
Mark Mitchell <mark@codesourcery.com> writes:
> [...]
> As for GCC 3.3, I guess we'd better play it a bit by ear. It doesn't
> appear that most people think we can make March 1. I'm going to keep
> that as my own internal target, so that I have something to motivate
> me to fix a bug or two on a Saturday night, but we'll not be too firm
> about it.
I would prefer if you would be firm about it. For us gcc 3.3 looks
quite good already and I'd like to have a March 1 release [1].
Let me just tell you that some SuSE engineers will spend - and have
already spent - a good amount of time on GCC 3.3 [2]. We are working
on quality issues as indicated by some of the PRs that come in.
We're testing GCC 3.3 mainly on x86, x86-64, ia64 and PowerPC but also
do limited testing on some other platforms including s390. Testing
means building of over 2000 packages and testing those packages
reveals miscompilations, bootstrap failures, internal compiler errors,
errors in the packages etc. - and we try to fix those problems.
Thanks for everybody working on GCC!
Andreas
Footnotes:
[1] Or not much later.
[2] Unfortunatly some of them will be also tied to merge in patches
to 3.4, so I cannot commit anybody fulltime. Extending the 3.4
deadline might help here a bit but at this time I don't see this
as critical.
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 21:21 ` Devang Patel
@ 2003-01-31 22:59 ` Joel Sherrill
2003-01-31 23:42 ` Devang Patel
0 siblings, 1 reply; 115+ messages in thread
From: Joel Sherrill @ 2003-01-31 22:59 UTC (permalink / raw)
To: Devang Patel; +Cc: Joseph S. Myers, Mark Mitchell, gcc
Devang Patel wrote:
>
> On Friday, January 31, 2003, at 11:41 AM, Joseph S. Myers wrote:
>
> > On Fri, 31 Jan 2003, Devang Patel wrote:
> >
> >> Another thing, IMO we need to do is to look at the pace of
> >> development.
> >> More then 1400 checkins (total count from gcc-cvs mailing list) in
> >> this month only!. PCH and new C++ parser are major new items but
> >
> > How many of these checkins are actually on the mainline?
>
> I do not know, but it is not important for what I am saying.
>
> Even if we eliminate duplicate check-ins, I do not think in this
> month we have got ~1000 new features or genuine bug (bug that is
> in GCC since beginning of time) fixes in all branches combined.
Real quick analysis of December's via "grep Subject" and wc:
Total: 1020
version.c Updates: 176
gnatvsn.ads Updates: 124
So 300 are based upon an automated daily update of the version string.
There are 500 unique subject lines in the December log. This is not
a 100% accurate reflection of unique modifications because the
subject lines are truncated at about 64 characters and many start
with the same string "Subject: gcc/gcc ChangeLog " so there isn't much
room for being unique based upon files in a change set.
This is 5 minutes of looking and my point is just to be careful
looking at these. I agree that there are probably a fair number of
changes but gcc is a LARGE body of source code so I would expect
changes. Besides the compiler, there are test suites, documentation,
run-time libraries, and build support tools that support a variety
of host and target environments.
The large number of host and target combinations means that it is
probably just a fact of life that what is an improvement to one
target has a probability to break something else.
--joel
> -Devang
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 20:59 ` Joe Buck
@ 2003-01-31 22:44 ` Tom Tromey
0 siblings, 0 replies; 115+ messages in thread
From: Tom Tromey @ 2003-01-31 22:44 UTC (permalink / raw)
To: Joe Buck; +Cc: gcc, Benjamin Kosnik, Mark Mitchell
>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:
Joe> If 3.3 can be stabilized to the point where almost all the high-priority
Joe> bugs are fixed in it, then 3.3 (with its other improvements) would
Joe> be preferable to 3.2.3 (which may have bug fixes, but doesn't have 3.3's
Joe> new features). This is especially the case for any bugs that depend
Joe> on new infrastructure to fix.
Whether 3.3 is preferable depends on what you're using it for. For
gcj users, 3.3 is hugely better. I'd really, really like a 3.3, just
to get all the bug fixes out to the public. For gcj there's really no
comparison (gcj and libgcj are still changing quickly; each major
release is visible different from the previous one).
Joe> As the third digit increases, we should be more and more cautious
Joe> about what kinds of changes we apply. If we wind up backporting
Joe> large patches, it might be safer to just postpone fixes until
Joe> 3.3.
Yeah. Back-porting the gcj fixes would be a huge effort.
Joe> Still, I'm worried about whether we really have the resources to
Joe> have three flows going at once on a continuing basis. As long as
Joe> we do, I think that the middle one (3.3) will suffer: lots of
Joe> testing and fixing on 3.2, lots of gurus working on the cool
Joe> stuff in 3.4, but little effort on 3.3.
I worry about that too, especially since for gcj we decided not to do
any further work on 3.2 (a mistake we won't repeat in the future --
clearly pushing bug fixes to the older release is worthwhile). It
seems to me that when the 3.3 branch was made, people just kept
hacking on various other branches. In fact, after 3.3 it seemed like
work on other branches accelerated in order to get them merged to the
main line as soon as possible.
I assume that happened because stage 1 and release stabilization
happen at the same time. In other words, there is a strong incentive
to work on getting your development branch in in preference to working
on fixing regressions -- the development branches are more fun, the
window for merging them into the next release is not very long, and it
overlaps with the regression fixing period.
I suggest we change things around a bit. For instance, maybe we could
delay branch merging until some percentage of regressions has been
fixed. Or, extend stage 1 out past the branch's release, so that
there is no need to rush to get the new technology merged to the
trunk.
For gcj at least, when a release branch is made (this happened for 3.1
and now 3.3), it seems like tons of patches come out of the woodwork.
Suddenly patch review is a major part of my day. I don't know what to
do about this. I hate to prevent a bug fix from going into the next
release just because the timing is inconvenient. On the other hand,
it makes doing a release that much harder.
Tom
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 20:57 ` Devang Patel
@ 2003-01-31 21:35 ` Tom Tromey
0 siblings, 0 replies; 115+ messages in thread
From: Tom Tromey @ 2003-01-31 21:35 UTC (permalink / raw)
To: Devang Patel; +Cc: gcc
>>>>> "Devang" == Devang Patel <dpatel@apple.com> writes:
Devang> I'm thinking - "Can we check regression before commits?". Can
Devang> we have setup to queue all incoming commits and churn it
Devang> through regression testing machinery before actually
Devang> committing it?. I do not know if this is possible or not, but
Devang> it would be great.
Sure, that would be great. Especially if it could also apply the
patches for you -- lately I've been doing a lot of patch review and
application, and it gets tedious (especially with multiple branches,
slightly malformed patches, etc, etc).
I think the real problem is finding the funding and/or time to do it.
Certainly the technical challenges aren't insurmountable.
Tom
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 21:02 ` Joseph S. Myers
2003-01-31 21:13 ` Joel Sherrill
@ 2003-01-31 21:21 ` Devang Patel
2003-01-31 22:59 ` Joel Sherrill
1 sibling, 1 reply; 115+ messages in thread
From: Devang Patel @ 2003-01-31 21:21 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Devang Patel, Mark Mitchell, gcc
On Friday, January 31, 2003, at 11:41 AM, Joseph S. Myers wrote:
> On Fri, 31 Jan 2003, Devang Patel wrote:
>
>> Another thing, IMO we need to do is to look at the pace of
>> development.
>> More then 1400 checkins (total count from gcc-cvs mailing list) in
>> this month only!. PCH and new C++ parser are major new items but
>
> How many of these checkins are actually on the mainline?
I do not know, but it is not important for what I am saying.
Even if we eliminate duplicate check-ins, I do not think in this
month we have got ~1000 new features or genuine bug (bug that is
in GCC since beginning of time) fixes in all branches combined.
-Devang
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 21:02 ` Joseph S. Myers
@ 2003-01-31 21:13 ` Joel Sherrill
2003-01-31 21:21 ` Devang Patel
1 sibling, 0 replies; 115+ messages in thread
From: Joel Sherrill @ 2003-01-31 21:13 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Devang Patel, Mark Mitchell, gcc
"Joseph S. Myers" wrote:
>
> On Fri, 31 Jan 2003, Devang Patel wrote:
>
> > Another thing, IMO we need to do is to look at the pace of development.
> > More then 1400 checkins (total count from gcc-cvs mailing list) in
> > this month only!. PCH and new C++ parser are major new items but
>
> How many of these checkins are actually on the mainline?
And I wonder how many are closing PRs on multiple branches. I know that
some PRs closed on the 3.2 branch have also resulted in patches being
applied to the 3.3 branch and HEAD. That would result in the commits
being large in comparision to the number of PRs closed. And that
ignores
other branches where patches would be duplicated.
> --
> Joseph S. Myers
> jsm28@cam.ac.uk
--joel
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 11:52 ` Tom Lord
2003-01-31 20:52 ` Joe Buck
@ 2003-01-31 21:07 ` Mike Stump
1 sibling, 0 replies; 115+ messages in thread
From: Mike Stump @ 2003-01-31 21:07 UTC (permalink / raw)
To: Tom Lord; +Cc: bkoz, gcc, mark
Well, let me just say, i disagree in general with what you say, I'll
leave it at that.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 19:05 ` Devang Patel
2003-01-31 20:05 ` Mark Mitchell
@ 2003-01-31 21:02 ` Joseph S. Myers
2003-01-31 21:13 ` Joel Sherrill
2003-01-31 21:21 ` Devang Patel
1 sibling, 2 replies; 115+ messages in thread
From: Joseph S. Myers @ 2003-01-31 21:02 UTC (permalink / raw)
To: Devang Patel; +Cc: Mark Mitchell, gcc
On Fri, 31 Jan 2003, Devang Patel wrote:
> Another thing, IMO we need to do is to look at the pace of development.
> More then 1400 checkins (total count from gcc-cvs mailing list) in
> this month only!. PCH and new C++ parser are major new items but
How many of these checkins are actually on the mainline?
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 1:27 ` Gerald Pfeifer
2003-01-31 1:52 ` Benjamin Kosnik
@ 2003-01-31 20:59 ` Joe Buck
2003-01-31 22:44 ` Tom Tromey
1 sibling, 1 reply; 115+ messages in thread
From: Joe Buck @ 2003-01-31 20:59 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: gcc, Benjamin Kosnik, Mark Mitchell
On Fri, Jan 31, 2003 at 01:40:56AM +0100, Gerald Pfeifer wrote:
> Agreed. What worries me more, though, is that currently we have
> ~59 high priority PRs = regressions for the 3.2-branch (most of
> which also apply to 3.3).
69 against 3.2, 47 of these also againt 3.3 (meaning that 22 of the
69 are fixed in 3.3).
> I believe we should try to tackle these first (and deliver a
> sensibly improved GCC 3.2.3 after the forthcoming 3.2.2).
Well, maybe. But ...
If 3.3 can be stabilized to the point where almost all the high-priority
bugs are fixed in it, then 3.3 (with its other improvements) would
be preferable to 3.2.3 (which may have bug fixes, but doesn't have 3.3's
new features). This is especially the case for any bugs that depend
on new infrastructure to fix.
As the third digit increases, we should be more and more cautious about
what kinds of changes we apply. If we wind up backporting large patches,
it might be safer to just postpone fixes until 3.3.
So, if stabilization work got the 69/47 number above down to, say,
50/15, then we have the choice of either releasing 3.2.3 with 50
regressions, or 3.3 with 15 regressions but more likelihood of having
some new failure.
On the other hand, if most fixes are easily done in both branches, so
the number looks more like 20/15, then 3.2.3 would be a good idea.
Still, I'm worried about whether we really have the resources to have
three flows going at once on a continuing basis. As long as we do,
I think that the middle one (3.3) will suffer: lots of testing and
fixing on 3.2, lots of gurus working on the cool stuff in 3.4, but
little effort on 3.3. Then I'll probably have to issue another
"what's the point" message again. :-)
> >> There's more I'd like to say, but I can't. Hopefully soon.
> > This continues to annoy me, but I understand why you do it. The longer
> > you say this line, the less I believe there's anything to say.
>
> Given how many ABI bugs CodeSourcery developers have already fixed
> (and the fact that I cannot remember Mark ever promising something
> he hasn't kept), I'm much more optimistic.
>
> BTW, if you consider my finding of C ABI breakage for several, not so
> minor platforms today, apparently we could also use a C ABI testsuite.
>
> > I think the longer gcc, as a project, goes on without an autobuild
> > continuous regression checker, the worse off things will get. Somebody
> > [...] will have to step up with the bandwidth, time, and machine to do
> > this.
>
> Fully agreed.
>
> Well, why don't we send a "Call for support" to the gcc-announce list?
> Seriously.
>
> Gerald
> --
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.pfeifer.com/gerald/
--
Q. What's more of a headache than a bug in a compiler.
A. Bugs in six compilers. -- Mark Johnson
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 20:05 ` Mark Mitchell
2003-01-31 20:37 ` Graham Stott
@ 2003-01-31 20:57 ` Devang Patel
2003-01-31 21:35 ` Tom Tromey
1 sibling, 1 reply; 115+ messages in thread
From: Devang Patel @ 2003-01-31 20:57 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Devang Patel, gcc
On Friday, January 31, 2003, at 10:57 AM, Mark Mitchell wrote:
> From: Mark Mitchell <mark@codesourcery.com>
> Date: Fri Jan 31, 2003 10:57:48 AM US/Pacific
> To: Devang Patel <dpatel@apple.com>
> Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
> Subject: Re: GCC 3.3, GCC 3.4
>
>
>
> --On Friday, January 31, 2003 09:54:49 AM -0800 Devang Patel
> <dpatel@apple.com> wrote:
>
>>> If people have concerns about how I'm doing my job, I want to hear
>>> them.
>>
>> I really appreciate what you're doing, but (:-)) GCC project will
>> benefit more if you become little be more strict about regressions.
>
> I agree with most of what you say, including this. Would Apple care
> to donate some time/resources for you to set up a machine with more
> automated testing? (Obviously, we'd be happy to help, if anyone wants
> to outsource this kind of thing as well.)
I think Geoff has already setup darwin-ppc regression tester.
But we need to find ways to stop regressions so that we do not have to
lots of
spend time and resources to find and fix them.
I'm thinking - "Can we check regression before commits?". Can we have
setup to queue all incoming commits and churn it through regression
testing
machinery before actually committing it?. I do not know if this is
possible or
not, but it would be great.
> We do have a policy
> to deal with regressions -- but we almost never use it. I don't know
> that we want to be too agressive, but maybe we should be a little more.
> You can help! When you spot a regression, mention it to the person
> who caused it, post to the list, and notify me.
I will. Janis and Wolfgang and other people are doing really great job
in finding regressions. But it is disappointing that we have not done
much to help them. Wolfgang reported that he has encountered couple of
regressions that stop him building his library since last 6 weeks or so.
-Devang
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 11:52 ` Tom Lord
@ 2003-01-31 20:52 ` Joe Buck
[not found] ` <200301312311.PAA15835@emf.net>
2003-01-31 21:07 ` Mike Stump
1 sibling, 1 reply; 115+ messages in thread
From: Joe Buck @ 2003-01-31 20:52 UTC (permalink / raw)
To: Tom Lord; +Cc: bkoz, gcc, mark
On Fri, Jan 31, 2003 at 02:25:48AM -0800, Tom Lord wrote:
> A lot depends on GCC. There is social responsibility to taking care
> of GCC. The SC bears that responsibility by virtue of having the unique
> position to give it voice. If the project is under-resourced in a
> context where GCC is commercially important, and if the SC are truly
> independent of the vendors, then they have leverage and ought to bring
> that leverage to bare on the problem. I recommend a little insurrection
> against the vendors.
People on the SC are just volunteers, and have no power to make vendors
do anything. As I've said before, the SC only has negative power: we
can refuse to accept a patch, we can delay a release, we can bounce
a maintainer. But we can't make anyone volunteer to do something.
You appear to persist in the fantasy that some kind of "insurrection"
is possible. Do what? Go on strike?
> The commercial experiment of "what comes for free in free software" is
> over. We know the results. We know what doesn't come for free. We
> know what needs to be paid for. Labor and capital are distinct
> parties, for the most part. Pretending that isn't so does both a
> disservice. Mark himself, of course, is an exception that tests the
> rule :-)
Vendors *are* paying: Red Hat is contributing resources, HP is funding
Mark's RM efforts, Apple gave us the precompiled header stuff, and many
others have contributed work.
Your fantasy SC, which would have the power to fling real money around,
would be far more of a vendor tool than the present SC (since we'd
then be explicitly representing our companies and their interests).
It might be nice to have more resources, but the economy is crap,
in case you hadn't noticed.
> The SC ought to, both directly and through a RM, stop inciting
> volunteerism for commerical purposes. Volunteerism is for the
> benefit of the volunteers and for the benefit of society as a whole.
What? You think volunteers are such abundant resources that the SC
is in a position to refuse contributions???
> For years, before there was commercial interest in GCC, there was no
> pressure for release schedules that would accomodate the needs of
> Apple, IBM, Red Hat or others. There should not be now. It is
> _wrong_ for calls to change volunteer focus to bug-fixing to keep
> things "on schedule" in a context where the schedule is, in effect,
> imposed to accomodate the vendors.
We pushed on getting 3.2 out in an attempt to re-unify the GNU/Linux
world. This is more of a service to the users than having each vendor
using C++ compilers with incompatible ABIs. GCC is not done just
for its own sake: the users can't use it until we release it.
We gave something up so as not to have a repeat of "gcc 2.96".
I think that's a good thing. The consequence was that 3.2 wasn't
a great release, but 3.2.1 *was*.
> The "community" is a de facto employee of the vendors. The SC
> has a role in negotiating compensation, not seducing volunteers.
How can the SC negotiate compensation? It has none to give, and no
power to demand any.
We have release schedules because we think that this is a good way to
do software development. However, these schedules are not set in
stone; we will be more willing to slip them than a proprietary software
developer with contractual commitments might be.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 6:09 ` Joe Buck
2003-01-31 7:39 ` Zack Weinberg
@ 2003-01-31 20:43 ` Geoff Keating
[not found] ` <200301312127.QAA22861@caip.rutgers.edu>
2 siblings, 0 replies; 115+ messages in thread
From: Geoff Keating @ 2003-01-31 20:43 UTC (permalink / raw)
To: Joe Buck; +Cc: gcc, mark
Joe Buck <jbuck@synopsys.com> writes:
> > I think the longer gcc, as a project, goes on without an autobuild
> > continuous regression checker, the worse off things will get. It was
> > nice of Red Hat to initially support this effort, but it is obvious that
> > this time is past as the regression checker is long dead. Somebody else
> > will have to step up with the bandwidth, time, and machine to do this.
>
> Agreed. It may be easier to get someone to donate the bandwidth/machine
> if we can hand them a relatively-easy-to-setup hunk of software and just
> ask them to run it.
There is already a tester running, on powerpc-Darwin; you haven't
gotten any mail from it because the tree has been fairly stable
recently (even the new C++ parser went in without a big ripple). It
does need a web site; now that sources is upgraded maybe I'll ask
about putting its web site there.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 20:05 ` Mark Mitchell
@ 2003-01-31 20:37 ` Graham Stott
2003-01-31 20:57 ` Devang Patel
1 sibling, 0 replies; 115+ messages in thread
From: Graham Stott @ 2003-01-31 20:37 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Devang Patel, gcc
Mark Mitchell wrote:
>
>
> --On Friday, January 31, 2003 09:54:49 AM -0800 Devang Patel
> <dpatel@apple.com> wrote:
>
>>> If people have concerns about how I'm doing my job, I want to hear
>>> them.
>>
>>
>> I really appreciate what you're doing, but (:-)) GCC project will
>> benefit more if you become little be more strict about regressions.
>
>
> I agree with most of what you say, including this. Would Apple care
> to donate some time/resources for you to set up a machine with more
> automated testing? (Obviously, we'd be happy to help, if anyone wants
> to outsource this kind of thing as well.)
I've got loads of spare time and I'm on the look out for GCC work that'll
help pay my bills.
>
Graham
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 18:02 ` Mark Mitchell
2003-01-31 19:05 ` Devang Patel
2003-01-31 19:44 ` Matt Austern
@ 2003-01-31 20:31 ` Richard Henderson
2003-01-31 22:59 ` Andreas Jaeger
3 siblings, 0 replies; 115+ messages in thread
From: Richard Henderson @ 2003-01-31 20:31 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Joseph S. Myers, Benjamin Kosnik, gcc
On Fri, Jan 31, 2003 at 08:48:10AM -0800, Mark Mitchell wrote:
> Nobody seems to be objecting particularly much to the idea of leaving
> stage 1 for GCC 3.4 on March 15th. So, let's make that firm. We've
> already got two major pieces of new technology: a new C++ parser, and
> PCH support.
I am going to try to help get Jan and Zdenek's CFG-based loop
code in off of the branch(es) they've been maintaining since 3.1.
I think they have 5 recent merge patches waiting for review.
I don't expect 6 weeks to be a problem for this.
r~
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 19:44 ` Matt Austern
@ 2003-01-31 20:23 ` Mark Mitchell
2003-02-01 0:21 ` Michael Matz
0 siblings, 1 reply; 115+ messages in thread
From: Mark Mitchell @ 2003-01-31 20:23 UTC (permalink / raw)
To: Matt Austern; +Cc: Joseph S. Myers, Benjamin Kosnik, gcc
--On Friday, January 31, 2003 10:52:23 AM -0800 Matt Austern
<austern@apple.com> wrote:
> On Friday, January 31, 2003, at 08:48 AM, Mark Mitchell wrote:
>
>> Nobody seems to be objecting particularly much to the idea of leaving
>> stage 1 for GCC 3.4 on March 15th. So, let's make that firm. We've
>> already got two major pieces of new technology: a new C++ parser, and
>> PCH support.
>
> I have two concerns about the March 15 deadline.
>
> First, a technical concern: people have also been talking about putting
> the new register allocator into 3.4. I'd like to see that as a third
> major piece of new technology, which would imply a later deadline.
What's the prognosis for the register allocator? When will it be ready
to check in, and when will the bugs be out? (I consider the C++ parser
to still be too buggy to release, even though it works well for most
code. It passed the tests, which got it into the tree, but people have
certainly been finding problems.)
> Second, a process concern: March 15 for the end of 3.4 phase 1 is
> awfully close to the 3.3 code freeze.
I don't think we can worry about this much, since we don't really know
when the 3.3 freeze is going to be. There's not a whole lot of support
for doing a 3.3 release at all; at this point, I think we should see how
3.3 develops before worrying about it too much.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 12:54 ` Richard Earnshaw
@ 2003-01-31 20:22 ` Geoff Keating
0 siblings, 0 replies; 115+ messages in thread
From: Geoff Keating @ 2003-01-31 20:22 UTC (permalink / raw)
To: Richard.Earnshaw; +Cc: bkoz, neil, gcc, Richard.Earnshaw
> Date: Fri, 31 Jan 2003 10:38:55 +0000
> From: Richard Earnshaw <rearnsha@arm.com>
> > It's not the case that there's one number for this parameter that is
> > great for everyone. The current number is acceptable on small-memory
> > machines but not optimal for larger machines. A larger number would
> > be better for larger machines, but would cause small-memory machines
> > to be unusable.
>
> Can you define "large" and "small" here? I have a 32M machine which I use
> for building native ARM compilers, and I wouldn't consider that to be
> especially small, but these days the machine can't even bootstrap with -j1
> without thrashing the disk -- it used to be possible to bootstrap with -j2
> and have virtually no paging at all. Bootstrap times have crept up over
> the last couple of years or so from about 3 hours to 9+ now; and I haven't
> even attempted to build java yet on that machine :-(
>
> And this is called progress.
`large' and `small' are relative terms. I'm pretty sure a machine
with 32M is always small, and with 1G is large, but it depends on (for
instance) how many compiles are running and what else is on the
machine.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 19:05 ` Devang Patel
@ 2003-01-31 20:05 ` Mark Mitchell
2003-01-31 20:37 ` Graham Stott
2003-01-31 20:57 ` Devang Patel
2003-01-31 21:02 ` Joseph S. Myers
1 sibling, 2 replies; 115+ messages in thread
From: Mark Mitchell @ 2003-01-31 20:05 UTC (permalink / raw)
To: Devang Patel; +Cc: gcc
--On Friday, January 31, 2003 09:54:49 AM -0800 Devang Patel
<dpatel@apple.com> wrote:
>> If people have concerns about how I'm doing my job, I want to hear
>> them.
>
> I really appreciate what you're doing, but (:-)) GCC project will
> benefit more if you become little be more strict about regressions.
I agree with most of what you say, including this. Would Apple care
to donate some time/resources for you to set up a machine with more
automated testing? (Obviously, we'd be happy to help, if anyone wants
to outsource this kind of thing as well.)
I'm not sure what to say about the regressions. We do have a policy
to deal with regressions -- but we almost never use it. I don't know
that we want to be too agressive, but maybe we should be a little more.
You can help! When you spot a regression, mention it to the person
who caused it, post to the list, and notify me.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 18:02 ` Mark Mitchell
2003-01-31 19:05 ` Devang Patel
@ 2003-01-31 19:44 ` Matt Austern
2003-01-31 20:23 ` Mark Mitchell
2003-01-31 20:31 ` Richard Henderson
2003-01-31 22:59 ` Andreas Jaeger
3 siblings, 1 reply; 115+ messages in thread
From: Matt Austern @ 2003-01-31 19:44 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Joseph S. Myers, Benjamin Kosnik, gcc
On Friday, January 31, 2003, at 08:48 AM, Mark Mitchell wrote:
> Nobody seems to be objecting particularly much to the idea of leaving
> stage 1 for GCC 3.4 on March 15th. So, let's make that firm. We've
> already got two major pieces of new technology: a new C++ parser, and
> PCH support.
I have two concerns about the March 15 deadline.
First, a technical concern: people have also been talking about putting
the new register allocator into 3.4. I'd like to see that as a third
major
piece of new technology, which would imply a later deadline.
Second, a process concern: March 15 for the end of 3.4 phase 1 is
awfully close to the 3.3 code freeze. I hate to see major deadlines
on two branches so close to each other. I'm afraid people might get
nervous about missing a 3.4 deadline, and won't feel like they're able
to spend much time on 3.3 regressions. I'd be happier if the end of 3.4
phase 1 were well after the 3.3 code freeze.
--Matt
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 18:02 ` Mark Mitchell
@ 2003-01-31 19:05 ` Devang Patel
2003-01-31 20:05 ` Mark Mitchell
2003-01-31 21:02 ` Joseph S. Myers
2003-01-31 19:44 ` Matt Austern
` (2 subsequent siblings)
3 siblings, 2 replies; 115+ messages in thread
From: Devang Patel @ 2003-01-31 19:05 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Devang Patel, gcc
On Friday, January 31, 2003, at 08:48 AM, Mark Mitchell wrote:
> I completely agree that more automated testing, and non-automated
> testing, would be extremely helpful.
IMO, now we need to establish it as a kind of requirement to
ensure good progress on future release. Even though this is
volunteer work, IMO vendors need to provide hardware for testing
if they use GCC as main compiler on their system.
Someone mentioned in this thread earlier that it is not straight
forward to setup this even if hardwares and bandwidths are available.
In this case, I think, we need to allocate some serious time on it.
> I also agree that more bug-fixing
> would be good; right now we *know* about a lot of regressions -- but
> we don't have fixes for most of them. Architecture cleanups that make
> it harder to introduce bugs also help a lot.
IMO we need to change our thinking as far as regressions are
concerned. We can not continue development if we continue to
address regressions as part of life and find ways to live
with it. IMO, we need to start thinking in terms of zero
regression.
IMHO, We also need to allocate some time or even one minor release
to address regressions only. Only regression fixes are allowed
and no other check-ins are allowed (even cosmetic changes like
fixing spelling error comment) during this period. (We need to
stop the bus, check and fix oil leak and then continue even
though we are late.)
Another thing, IMO we need to do is to look at the pace of development.
More then 1400 checkins (total count from gcc-cvs mailing list) in
this month only!. PCH and new C++ parser are major new items but
they did not contribute large portion of this commits count. And
somebody pointed earlier that we have fixed 20 regressions from 3.2
and introduced new 29 regressions in 3.3. So we are working harder
but IMO, we need some discipline to take advantage of our hard work.
> If people have concerns about how I'm doing my job, I want to hear
> them.
I really appreciate what you're doing, but (:-)) GCC project will
benefit more if you become little be more strict about regressions.
I know this is volunteer work so one has to adjust to it, but
these are my thoughts.
-Devang
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 13:50 ` Joseph S. Myers
@ 2003-01-31 18:02 ` Mark Mitchell
2003-01-31 19:05 ` Devang Patel
` (3 more replies)
2003-01-31 23:12 ` Phil Edwards
1 sibling, 4 replies; 115+ messages in thread
From: Mark Mitchell @ 2003-01-31 18:02 UTC (permalink / raw)
To: Joseph S. Myers, Benjamin Kosnik; +Cc: gcc
--On Friday, January 31, 2003 11:03:41 AM +0000 "Joseph S. Myers"
<jsm28@cam.ac.uk> wrote:
> On Thu, 30 Jan 2003, Benjamin Kosnik wrote:
>
>> I think the longer gcc, as a project, goes on without an autobuild
>> continuous regression checker, the worse off things will get.
I've caught up now on this entire thread, and I spent about an hour
talking to Benjamin last night. I appreciate the time he took to
talk to me and the input he provided, including some practical notes
about when Red Hat people would be more likely to help and when they
wouldn't.
If people have concerns about how I'm doing my job, I want to hear
them.
My job as RM is to serve the FSF's interests -- not CodeSourcery's,
or anyone elses. It's a little unclear what the FSF's interests *are*,
other than the overall success of free software, but I've got to assume
that they include the widespread usage of GCC and the avoidance of forks,
which, to me, implies reasonably high-quality releases reasonably often.
I find it a very hard balancing act. Do releases often, and you're
always working on fixing regressions, testing, packaging, etc. Do
releases rarely and the bugs get so bad it's incredibly hard to fix
them all. Do them on a major GNU/Linux vendor's release schedule and
you get more help from those vendors, but maybe not at a time that's
terribly natural for the pace of other development. Decide that
there have been enough major changes for one release, and you risk
irritating the people who have been working on the branch that didn't
get in. Take the code anyhow and you risk introducing more bugs and
exposing users to immature technology. You get the picture. :-)
I completely agree that more automated testing, and non-automated
testing, would be extremely helpful. I also agree that more bug-fixing
would be good; right now we *know* about a lot of regressions -- but
we don't have fixes for most of them. Architecture cleanups that make
it harder to introduce bugs also help a lot.
Nobody seems to be objecting particularly much to the idea of leaving
stage 1 for GCC 3.4 on March 15th. So, let's make that firm. We've
already got two major pieces of new technology: a new C++ parser, and
PCH support. There are still serious bugs in both, no doubt, but we're
making good progress. I think if we get another branch merged in,
we'll have enough bugs to keep us busy forever.
As for GCC 3.3, I guess we'd better play it a bit by ear. It doesn't
appear that most people think we can make March 1. I'm going to keep
that as my own internal target, so that I have something to motivate
me to fix a bug or two on a Saturday night, but we'll not be too firm
about it.
Thanks to all of you for commenting.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 10:39 ` Mike Stump
@ 2003-01-31 17:54 ` Wolfgang Bangerth
0 siblings, 0 replies; 115+ messages in thread
From: Wolfgang Bangerth @ 2003-01-31 17:54 UTC (permalink / raw)
To: Mike Stump; +Cc: gcc, Benjamin Kosnik
On Thu, 30 Jan 2003, Mike Stump wrote:
> On Thursday, January 30, 2003, at 06:04 PM, Wolfgang Bangerth wrote:
> > - I can't get mainline to compile the lib since about mid-December,
> > due to a changing set of regressions.
>
> :-( Hate email to the gcc list everyday complaining about the
> unresolved regression?
Sorry if that sounded like whining. It's just the way it is. (Compilation
regressions are for package regression testers like me, what bootstrap
failures are for gcc developers.)
> The big problem is, if they one regression is fixed, and there is
> another behind it, it now is much harder for you to identify it for us.
Right.
If anyone really feels compelled to do something about it, below is info
about the two PRs that broke compiling the lib. I don't know what more is
broken behind them.
Wolfgang
======================================================================
PR 9457: introduced between 2003-1-12 and 2003-1-30. Testcase:
------------------------
template <typename> void foo (int count) {
int i = {count};
}
template void foo<int> (int);
------------------------
ICE:
PR9457+.cc: In function `void foo(int) [with {template default argument error} = int]':
PR9457+.cc:4: instantiated from here
PR9457+.cc:2: internal compiler error: in tsubst_copy, at cp/pt.c:7124
PR 9453: ICE introduced between 2003-01-05 and 2003-01-12 (was an error on
01-05, which also was wrong, but I think Kriang fixed that; it's the ICE
that's bothering me in the first place). Testcase:
------------------------
template <typename> class X {
private:
struct Inner;
template <typename R>
friend typename X<R>::Inner * foo () { return 0; };
};
template class X<void>;
struct U {
void bar () { foo<void> (); };
};
---------------------------
ICE:
9453+.cc: In function `typename X<R>::Inner* foo()':
9453+.cc:6: internal compiler error: in is_specialization_of, at cp/pt.c:863
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ticam.utexas.edu
www: http://www.ticam.utexas.edu/~bangerth/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 1:34 ` Zack Weinberg
@ 2003-01-31 17:53 ` Mark Mitchell
0 siblings, 0 replies; 115+ messages in thread
From: Mark Mitchell @ 2003-01-31 17:53 UTC (permalink / raw)
To: Zack Weinberg, Gabriel Dos Reis, lsb-cxx, debian-gcc; +Cc: Benjamin Kosnik, gcc
--On Thursday, January 30, 2003 04:52:41 PM -0800 Zack Weinberg
<zack@codesourcery.com> wrote:
> I'm relaying this to the LSB working group in charge of C++ and also
> to the Debian gcc team -- Debian is presently in the process of
> transitioning to the 3.2 ABI and I am pretty sure they also were
> operating under the assumption that it would not change ever again.
I know that we will change the C++ ABI a little bit more. Here are
the two areas that I know are buggy, and are buggy in ways that affect
correctness:
- Name mangling
Due to not being able to know exactly what's a dependent name and
what's not, there are some (obscure) cases involving templates where
we cannot really produce the right name given what we have now.
These cases are sufficiently odd that I'm not sure anyone will ever
run into them in real code. For example, I doubt they come up in
V3.
- Object layout
For the most part, these are bugs involving empty class conflicts. As
far as I know, we've fixed all of these -- I do not know of any more
and I know we've looked pretty hard, in various ways. There is also at
least one bug involving virtual bases that might be somewhat more common.
I think the thing to do is wait until we are very confident that we've
finally nailed the name mangling issues and until the V3 people they've
nailed the runtime issues and then change the defaults. I don't know
much about the runtime side, but on the compiler side, I expect that
few people will notice.
To some extent, I think there's a communication issue. We (rightly) take
seriously *any* ABI change, but some are a lot more serious than others.
These are more like "If you have more than 32 parameters to a
function, and 14 of them are floats, and 18 are long doubles, and you
use varargs, then we quite match the spec" than "the size of int
will be now be 5" or "floating point values will now be passed on the
stack."
If we just said "this new version fixes a bug where two empty classes
of the same type can end up at the same address", people probably
wouldn't worry much -- but saying "we're breaking the C++ ABI" makes
them worry. Both perspectives are correct: they should worry, but not
*too* much.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
@ 2003-01-31 16:29 Richard Kenner
0 siblings, 0 replies; 115+ messages in thread
From: Richard Kenner @ 2003-01-31 16:29 UTC (permalink / raw)
To: lord; +Cc: gcc
The SC ought to, both directly and through a RM, stop inciting
volunteerism for commerical purposes. Volunteerism is for the
benefit of the volunteers and for the benefit of society as a whole.
I'm not sure what you mean by the first part of this. Obviously, volunteers
are important to the GCC development process and should be encouraged,
but if you look at GCC's history, the vast majority of work on GCC has
been done by companies that have a commercial interest in it. Are you
really trying to *discourage* that work?
For years, before there was commercial interest in GCC, there was no
pressure for release schedules that would accomodate the needs of
Apple, IBM, Red Hat or others. There should not be now.
True to the most part, in that no one company's release schedule should
dominate GCC development, but if we want the continued support of these
companies, we do have to keep their collective neds (including schedules)
in mind.
It is _wrong_ for calls to change volunteer focus to bug-fixing to
keep things "on schedule" in a context where the schedule is, in
effect, imposed to accomodate the vendors.
No, that's not the case. Our work has no benefit to *anybody* is we don't
release it and frequent releases mean our work gets out to the user community
faster. It is unfortunately the case that one of the serious problems
with "volunteerism" is that volunteers mostly want to do "fun" work, which
means hacking away and adding new optimizations. It's not fun to do the
testing and bug-fixing, but that part is even more important than the
other development work since few will use a compiler that doesn't work.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 2:08 ` Mike Stump
@ 2003-01-31 16:01 ` Michael S. Zick
0 siblings, 0 replies; 115+ messages in thread
From: Michael S. Zick @ 2003-01-31 16:01 UTC (permalink / raw)
To: Mike Stump; +Cc: gcc
On Thursday 30 January 2003 07:22 pm, Mike Stump wrote:
>
> I'm trying to envision the documentation:
>
> --please-make-compiler-deterministic
>
> Eliminates non-determinism from the compiler.
>
> :-) It that an -f option, or an -m option?
I think that is a --sol-... option.
But to have any sort of meaningful comparisons between
--version=yesterday and --version=tomorrow
we do need some way to get the "GC noise" out of the
numbers.
Mike
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:37 Benjamin Kosnik
` (4 preceding siblings ...)
2003-01-31 11:52 ` Tom Lord
@ 2003-01-31 13:50 ` Joseph S. Myers
2003-01-31 18:02 ` Mark Mitchell
2003-01-31 23:12 ` Phil Edwards
5 siblings, 2 replies; 115+ messages in thread
From: Joseph S. Myers @ 2003-01-31 13:50 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: gcc, mark
On Thu, 30 Jan 2003, Benjamin Kosnik wrote:
> I think the longer gcc, as a project, goes on without an autobuild
> continuous regression checker, the worse off things will get. It was
> nice of Red Hat to initially support this effort, but it is obvious that
> this time is past as the regression checker is long dead. Somebody else
> will have to step up with the bandwidth, time, and machine to do this.
The one that Geoff was running at Red Hat is now running at Apple (Darwin
native only, rather than one native and two cross). I think there's also
a separate one running on athlon_mp-pc-linux-gnu (look for Autocrasher in
the gcc-regression archives).
However, we do need a simple system for anyone (with a fast enough system)
to be able to set up the tester and run it, and have the results all go
into a single mail if they arrive in time (to avoid twenty mails going out
whenever the tree is broken). All primary platforms should be covered,
and any secondary platforms or crosses with simulators available that
someone wants to run the tester for. Also testers running on release
branches would be useful.
And I think development policies need to be changed to freeze the tree if
a regression persists for more than a few days; too often the old tester
had regressions persisting, unfixed, for a month or more.
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 21:42 ` Mike Stump
@ 2003-01-31 13:31 ` Nathan Sidwell
0 siblings, 0 replies; 115+ messages in thread
From: Nathan Sidwell @ 2003-01-31 13:31 UTC (permalink / raw)
To: Mike Stump; +Cc: Mark Mitchell, Benjamin Kosnik, gcc
Mike Stump wrote:
> Sigh, I have a patch that gives a 10x improvement on compile speed...
> It makes template programming, fast.
>
> I think it rises up to the top of work to get into the tree next, I
> think...
>
> The change is to ditch the linked lists from the specializations,
> instantiations and mangling code.
cool!
FYI, I'm hacking around with binfos, it seems we're unlikely to collide.
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 2:40 ` Geoff Keating
@ 2003-01-31 12:54 ` Richard Earnshaw
2003-01-31 20:22 ` Geoff Keating
0 siblings, 1 reply; 115+ messages in thread
From: Richard Earnshaw @ 2003-01-31 12:54 UTC (permalink / raw)
To: Geoff Keating; +Cc: Benjamin Kosnik, neil, gcc, Richard.Earnshaw
> It's not the case that there's one number for this parameter that is
> great for everyone. The current number is acceptable on small-memory
> machines but not optimal for larger machines. A larger number would
> be better for larger machines, but would cause small-memory machines
> to be unusable.
Can you define "large" and "small" here? I have a 32M machine which I use
for building native ARM compilers, and I wouldn't consider that to be
especially small, but these days the machine can't even bootstrap with -j1
without thrashing the disk -- it used to be possible to bootstrap with -j2
and have virtually no paging at all. Bootstrap times have crept up over
the last couple of years or so from about 3 hours to 9+ now; and I haven't
even attempted to build java yet on that machine :-(
And this is called progress.
R.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:37 Benjamin Kosnik
` (3 preceding siblings ...)
2003-01-31 6:09 ` Joe Buck
@ 2003-01-31 11:52 ` Tom Lord
2003-01-31 20:52 ` Joe Buck
2003-01-31 21:07 ` Mike Stump
2003-01-31 13:50 ` Joseph S. Myers
5 siblings, 2 replies; 115+ messages in thread
From: Tom Lord @ 2003-01-31 11:52 UTC (permalink / raw)
To: bkoz; +Cc: gcc, mark
I think the longer gcc, as a project, goes on without an
autobuild continuous regression checker, the worse off things
will get. It was nice of Red Hat to initially support this
effort, but it is obvious that this time is past as the
regression checker is long dead. Somebody else will have to
step up with the bandwidth, time, and machine to do this.
<stating the obvious>That problem isn't unique to GCC. It's an area
that needs investment. Of course, it's an area where generic
solutions can be developed that benefit not only GCC but other
projects as well. And it isn't vast investment that's needed --
on the contrary, quite moderate, by industry standards.
The vendors (who are, I realize, organizations, not persons) need to
realize that patch flow, automated testing, and automation assisted
project management and release management are really important, worthy
of study and strategic investment. There's plenty of evidence on this
list, for example, of the costs of neglecting such investment. Heck,
there's even some evidence in the infiltration of kernel development
by BK. Such investment would be a fine contribution to the community
and would reap commercial benefits to boot.
Some of these frustrations are with the development process,
and have nothing to do with you or the SC. Please keep in mind
that I have the utmost respect for both you and the SC.
I echo your sentiment of respect. I laughed when I read Mark's recent
apology -- whatever faults he has, he's doing far, far better than
most in similar positions. GCC positively shines, to those of us who
care about quality.
But to say that these process questions have nothing to do with the SC
or the maintainers is, frankly, bullcookies.
A lot depends on GCC. There is social responsibility to taking care
of GCC. The SC bears that responsibility by virtue of having the unique
position to give it voice. If the project is under-resourced in a
context where GCC is commercially important, and if the SC are truly
independent of the vendors, then they have leverage and ought to bring
that leverage to bare on the problem. I recommend a little insurrection
against the vendors.
The commercial experiment of "what comes for free in free software" is
over. We know the results. We know what doesn't come for free. We
know what needs to be paid for. Labor and capital are distinct
parties, for the most part. Pretending that isn't so does both a
disservice. Mark himself, of course, is an exception that tests the
rule :-)
The SC ought to, both directly and through a RM, stop inciting
volunteerism for commerical purposes. Volunteerism is for the
benefit of the volunteers and for the benefit of society as a whole.
For years, before there was commercial interest in GCC, there was no
pressure for release schedules that would accomodate the needs of
Apple, IBM, Red Hat or others. There should not be now. It is
_wrong_ for calls to change volunteer focus to bug-fixing to keep
things "on schedule" in a context where the schedule is, in effect,
imposed to accomodate the vendors.
The "community" is a de facto employee of the vendors. The SC
has a role in negotiating compensation, not seducing volunteers.
"Hard rock miner,"
-t
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 23:22 ` Michael Matz
2003-01-30 23:25 ` Michael S. Zick
@ 2003-01-31 11:16 ` Bernd Jendrissek
1 sibling, 0 replies; 115+ messages in thread
From: Bernd Jendrissek @ 2003-01-31 11:16 UTC (permalink / raw)
To: Michael Matz; +Cc: Michael S.Zick, gcc
On Thu, Jan 30, 2003 at 10:29:13PM +0100, Michael Matz wrote:
> On Thu, 30 Jan 2003, Michael S.Zick wrote:
> > > where the real problems lie), the new GC default is going to reduce or
> > > eliminate the impact of that improvement, an impact that would have been
> > > noticeable had the GC defaults not been changed, and the improvement
> > > is less likely to happen.
> > >
> > So, lets make part of the testing protocal: "disable GC"
>
> What can be disabled easily is collecting and reclaiming GC memory. What
> can _not_ be done easily is to go back to a memory management like in
> 2.95.x or earlier. But that would be needed to really calculate the cost
> of GC, because collecting is only a part of the overhead. The other part
> comes from different layout of memory, and the resulting slowness is
> distributed all over the compiler (so is not even measurable in one single
> function suddenly taking much more time). To this end we can't simply
> "disable" GC. One would need to rewrite the allocators too, but then have
> the problem that noone is freeing memory explicitely anymore, which would
> again be different to 2.95.x.
Could one hack valgrind to have adjustable memory latencies? Surely...
AFAICT the problem here is that GC bloats memory structures, which causes
the cache hit rates to drop. (Is raw memory bandwidth an issue here?) The
cache hit rate drops because fewer objects in GCC's "working set" fit into
the small cache. So, couldn't valgrind "compensate" for the effectively
smaller cache lines by pretending them to be, say, 48 bytes. Or maybe
something more dynamic based on hints from a hacked GC allocator?
Grr, I wish I could make more sense, but I'm out of my depth...
Bernd Jendrissek
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 5:15 Wolfgang Bangerth
@ 2003-01-31 10:39 ` Mike Stump
2003-01-31 17:54 ` Wolfgang Bangerth
0 siblings, 1 reply; 115+ messages in thread
From: Mike Stump @ 2003-01-31 10:39 UTC (permalink / raw)
To: Wolfgang Bangerth; +Cc: gcc, Benjamin Kosnik
On Thursday, January 30, 2003, at 06:04 PM, Wolfgang Bangerth wrote:
> - I can't get mainline to compile the lib since about mid-December,
> due to
> a changing set of regressions.
:-( Hate email to the gcc list everyday complaining about the
unresolved regression?
> - I can't build with 3.3 either since about the same time due to a
> regression introduced by Kriang and not fixed for a month or so (I
> think
> he just sent the patch today).
Ditto.
The big problem is, if they one regression is fixed, and there is
another behind it, it now is much harder for you to identify it for us.
I don't have a better answer. :-(
Thanks for hanging in there...
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 6:09 ` Joe Buck
@ 2003-01-31 7:39 ` Zack Weinberg
2003-01-31 20:43 ` Geoff Keating
[not found] ` <200301312127.QAA22861@caip.rutgers.edu>
2 siblings, 0 replies; 115+ messages in thread
From: Zack Weinberg @ 2003-01-31 7:39 UTC (permalink / raw)
To: Joe Buck; +Cc: Benjamin Kosnik, gcc, mark
Joe Buck <jbuck@synopsys.com> writes:
>> I think the longer gcc, as a project, goes on without an autobuild
>> continuous regression checker, the worse off things will get.
>
> Agreed. It may be easier to get someone to donate the bandwidth/machine
> if we can hand them a relatively-easy-to-setup hunk of software and just
> ask them to run it.
I've got standing offers of bandwidth and machine time from two
different companies, which I haven't had the time to do anything with;
if it was a matter of 'unpack this tarball, tweak the config file,
install the cron job' they'd be going already.
zw
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:37 Benjamin Kosnik
` (2 preceding siblings ...)
2003-01-31 1:27 ` Gerald Pfeifer
@ 2003-01-31 6:09 ` Joe Buck
2003-01-31 7:39 ` Zack Weinberg
` (2 more replies)
2003-01-31 11:52 ` Tom Lord
2003-01-31 13:50 ` Joseph S. Myers
5 siblings, 3 replies; 115+ messages in thread
From: Joe Buck @ 2003-01-31 6:09 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: gcc, mark
On Thu, Jan 30, 2003 at 06:13:13PM -0600, Benjamin Kosnik wrote:
> Shipping GCC 3.3.0 on March 1 will require enormous effort.
I would agree; this really seems like a stretch.
The more QA-oriented among us are currently working on making
sure that 3.2.2 is reasonably clean, and I don't see why the public
*needs* another bump less than a month later. Why not take more
time and do it right? A March 1 date would probably mean only
three more weeks for bug-fixing. I wouldn't ask for a big delay,
but I'd prefer a bit more time to do it right.
> Well, me too. However, I expected the SC to show more leadership on this
> issue. I'm disappointed by the current lack of policy. Matt had brought
> up this issue when the quick, "oops" 3.2.0 release was made. Now I
> see the wisdom of his comments.
We're set up at present to have an SC that does as little as possible,
leaving it to the RM for the most part to drive releases, with input from
people on the development list. About half of the SC is pretty much
inactive, busy with other things. It's this way on purpose, to minimize
the issue of having a secret cabal. The idea is that technical decisions
are in the open, on this list, as far as possible, and the SC deals with
the FSF relationship, the people issues if they come up, discussion of
code we have to rewrite because we don't have clear rights to it, things
like that, though occasionally issues with technical content come up.
Sometimes there are no messages on the SC mailing list for weeks at a
time, and things tend to be more interrupt-driven than they should have
been; it was kept too vague for a long time as to whether there would be
a 3.2.2 release.
> I've versioned the runtimes assuming that 3.3 will not break the 3.2
> ABI, and that 3.4 will. Lacking clear guidance on what to do, I think
> this was an ok decision.
No decision is really final until we've made a release, so it's an OK
decision even if we have to revisit it.
> I think the longer gcc, as a project, goes on without an autobuild
> continuous regression checker, the worse off things will get. It was
> nice of Red Hat to initially support this effort, but it is obvious that
> this time is past as the regression checker is long dead. Somebody else
> will have to step up with the bandwidth, time, and machine to do this.
Agreed. It may be easier to get someone to donate the bandwidth/machine
if we can hand them a relatively-easy-to-setup hunk of software and just
ask them to run it.
> Some of these frustrations are with the development process, and have
> nothing to do with you or the SC. Please keep in mind that I have the
> utmost respect for both you and the SC.
> best,
> benjamin
--
Q. What's more of a headache than a bug in a compiler.
A. Bugs in six compilers. -- Mark Johnson
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
@ 2003-01-31 5:15 Wolfgang Bangerth
2003-01-31 10:39 ` Mike Stump
0 siblings, 1 reply; 115+ messages in thread
From: Wolfgang Bangerth @ 2003-01-31 5:15 UTC (permalink / raw)
To: gcc; +Cc: Benjamin Kosnik
Benjamin Kosnik writes:
> > Would you please volunteer to run the tests and extract PRs for GNATs?
>
> Sorry, but no. I don't have the time to do this well. I think that Janis
> (and the rest of the regression hunters, bangerth in particular) are
> really doing a good job along these lines for mainline: they should be
> encouraged to continue efforts on the release branch.
Well, thanks for the kind words. I'm trying my best by building our
library every night in the hope that this will catch regressions as soon
as possible (about 50 of my PRs come from this library).
Alas,
- I can't get mainline to compile the lib since about mid-December, due to
a changing set of regressions.
- I can't build with 3.3 either since about the same time due to a
regression introduced by Kriang and not fixed for a month or so (I think
he just sent the patch today).
I'd like to test more, but this prevents me from it. The inability to
compile the lib also means that I have no clue whether middle- and
back-end changes introduced in the meantime (in particular the
basic-improvements branch) had any adverse effects.
Wolfgang
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ticam.utexas.edu
www: http://www.ticam.utexas.edu/~bangerth/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:17 ` Benjamin Kosnik
2003-01-31 0:21 ` Neil Booth
2003-01-31 1:54 ` Mike Stump
@ 2003-01-31 2:40 ` Geoff Keating
2003-01-31 12:54 ` Richard Earnshaw
2 siblings, 1 reply; 115+ messages in thread
From: Geoff Keating @ 2003-01-31 2:40 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: neil, gcc
Benjamin Kosnik <bkoz@redhat.com> writes:
> >> we're not really getting any faster.
> >
> >Yes, it really is faster. It really is better. Consider for example
> >that we had the value be 2KB, and 1% increase, and someone said bumping
> >it up to 30% and 8MB is wrong and just papers over the real problem.
> >We'd laugh at them, just the same way I laugh at you now.
>
> You know, I agree with you. I could not figure out why Neil was saying
> this, when I posted real timing numbers, based on increased numbers, and
> others backed me up.
>
> It seems as if the defaults were set arbitrarily: testing with various
> numbers tells me that bumping up to 16MB gets the maximum bang for the
> minimum setting.
>
> Holding on to these poorly picked initial numbers, in the face of data
> that suggests a better set of number, seems to be incredibly foolish.
It's not the case that there's one number for this parameter that is
great for everyone. The current number is acceptable on small-memory
machines but not optimal for larger machines. A larger number would
be better for larger machines, but would cause small-memory machines
to be unusable.
In this context, of course, 'large-memory' means simply that there's
lots of memory available now. Start a mozilla running and suddenly
you might find you're running on a small-memory machine :-). That's
why I want to make this parameter adjust at runtime.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:30 ` Neil Booth
@ 2003-01-31 2:08 ` Mike Stump
2003-01-31 16:01 ` Michael S. Zick
0 siblings, 1 reply; 115+ messages in thread
From: Mike Stump @ 2003-01-31 2:08 UTC (permalink / raw)
To: Neil Booth; +Cc: Phil Edwards, Mike Stump, Benjamin Kosnik, gcc
On Thursday, January 30, 2003, at 03:59 PM, Neil Booth wrote:
>> I detect the note of frustration, but I think this is an experiment
>> worth making. Say, allow --with-gc=none (re-allow?) to choose
>> ggc-none.c,
>> and see what happens.
>>
>> Perhaps the compiler need only turn on GC at all once a threshold
>> number
>> of... something... has been passed. (Statements? Tree nodes created?
>> Dunno.)
>
> Whatever we do, the worst thing is to make GCC non-deterministic.
>
> Someone suggested this (Geoff?) and someone else (Mike I think!)
> pointed
> out what a bad idea this was.
Scream now, as last I knew Geoff wanted to check the paging activity on
the system to dynamically tune the number. Last I knew, we planned a
mode where one could get the deterministic results, though,
unfortunately, if one wants to debug a problem, and when they ask for
determinism, if the problem goes away, we are sol. Geoff's contention
I think is that this is unlikely, and that there should be few bugs of
these sorts. I'm happy to try it out and see, we can decide later if
it really is a pain or not.
The biggest hit for me is, I must select the deterministic mode, as
otherwise, I cannot breakpoint on address equality, which I like so
very much.
I'm trying to envision the documentation:
--please-make-compiler-deterministic
Eliminates non-determinism from the compiler.
:-) It that an -f option, or an -m option?
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:21 ` Neil Booth
2003-01-31 0:25 ` Matt Austern
@ 2003-01-31 1:55 ` Mike Stump
1 sibling, 0 replies; 115+ messages in thread
From: Mike Stump @ 2003-01-31 1:55 UTC (permalink / raw)
To: Neil Booth; +Cc: Benjamin Kosnik, Mike Stump, gcc
On Thursday, January 30, 2003, at 03:47 PM, Neil Booth wrote:
> I agree the defaults might not be "right", and that in a sense getting
> them "right" improves the compiler. But it's not really improved the
> compiler, if you see what I mean.
I can agree with you on this.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:17 ` Benjamin Kosnik
2003-01-31 0:21 ` Neil Booth
@ 2003-01-31 1:54 ` Mike Stump
2003-01-31 2:40 ` Geoff Keating
2 siblings, 0 replies; 115+ messages in thread
From: Mike Stump @ 2003-01-31 1:54 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: Mike Stump, neil, gcc
On Thursday, January 30, 2003, at 03:41 PM, Benjamin Kosnik wrote:
> Or not fix it. Which seems to be what is happening.
Well, we hope to find a better way to fix it (the preferred method), or
failing that, we'll do some research and try and improve the number.
The patch will be submitted, if the FSF doesn't want it, we'll, lets
just say, that it will become just another local change. :-( We
already have two of them 100%/8MB (instead of the 30%/4MB) now, so
changing them to be 100%/16MB or 100%/32MB isn't that bad.
In addition to this, we hope to track down the actual regression that
led us to wanting to change the numbers...
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 1:27 ` Gerald Pfeifer
@ 2003-01-31 1:52 ` Benjamin Kosnik
2003-01-31 20:59 ` Joe Buck
1 sibling, 0 replies; 115+ messages in thread
From: Benjamin Kosnik @ 2003-01-31 1:52 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: gcc, mark
>I believe we should try to tackle these first (and deliver a
>sensibly improved GCC 3.2.3 after the forthcoming 3.2.2).
Agreed. I also think there should be a 3.2.3.
What do you think of Gaby's proposal for bugfix releases? This idea is
really growing on me. All branches could continue to have releases as
long as there is movement in the code: if, after 3 months, there are no
changes, well: no release. It's so simple it's appealing.
It would also allow branches to die off on their own accord.
>Given how many ABI bugs CodeSourcery developers have already fixed
>(and the fact that I cannot remember Mark ever promising something
>he hasn't kept), I'm much more optimistic.
I'm not trying to be mean, sorry if that was the way it was interpreted.
>BTW, if you consider my finding of C ABI breakage for several, not so
>minor platforms today, apparently we could also use a C ABI testsuite.
... why I said that I see no difference between now and 2.7 in terms of
ABI testing.
>Well, why don't we send a "Call for support" to the gcc-announce list?
>Seriously.
You can sign my name on this email. Also cc gnu-announce, etc. I don't
even mind looking at a banner ad if it's a tinderbox-style effort, I
don't care, as long as email gets sent when there is a new regression.
I won't mind overt commercialism on any of the infrastructure if it
means the necessary bits will actually get built. My opinion is my own,
of course, and I'm sure other developers will flame me for this.
You could do a separate one for the bugzilla effort as well, I'd supposed.
-benjamin
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 1:16 ` Gabriel Dos Reis
@ 2003-01-31 1:34 ` Zack Weinberg
2003-01-31 17:53 ` Mark Mitchell
0 siblings, 1 reply; 115+ messages in thread
From: Zack Weinberg @ 2003-01-31 1:34 UTC (permalink / raw)
To: Gabriel Dos Reis, lsb-cxx, debian-gcc; +Cc: Benjamin Kosnik, gcc, mark
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
> Zack Weinberg <zack@codesourcery.com> writes:
>
> | Benjamin Kosnik <bkoz@redhat.com> writes:
> | >
> | > I've versioned the runtimes assuming that 3.3 will not break the 3.2
> | > ABI, and that 3.4 will. Lacking clear guidance on what to do, I think
> | > this was an ok decision.
> |
> | There are groups out there, such as the LSB (Linux Standard Base)
> | effort, who are working on the assumption that the 3.2 ABI will
> | *never* be changed again.
>
> I believe the agreement was that the 3.2 and 3.3 won't be changed for
> the 3.2.x and 3.3.x series.
>
> But that agreement does not export to higher versions. People reading
> more into that agreement should be advised to coordinate/ask people
> workiing the C++ ABI and GCC/g++.
I'm relaying this to the LSB working group in charge of C++ and also
to the Debian gcc team -- Debian is presently in the process of
transitioning to the 3.2 ABI and I am pretty sure they also were
operating under the assumption that it would not change ever again.
Comments from both these teams are requested.
zw
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:37 Benjamin Kosnik
2003-01-31 0:52 ` Zack Weinberg
2003-01-31 1:14 ` Gabriel Dos Reis
@ 2003-01-31 1:27 ` Gerald Pfeifer
2003-01-31 1:52 ` Benjamin Kosnik
2003-01-31 20:59 ` Joe Buck
2003-01-31 6:09 ` Joe Buck
` (2 subsequent siblings)
5 siblings, 2 replies; 115+ messages in thread
From: Gerald Pfeifer @ 2003-01-31 1:27 UTC (permalink / raw)
To: gcc; +Cc: Benjamin Kosnik, Mark Mitchell
On Thu, 30 Jan 2003, Benjamin Kosnik wrote:
> Shipping GCC 3.3.0 on March 1 will require enormous effort.
Agreed. What worries me more, though, is that currently we have
~59 high priority PRs = regressions for the 3.2-branch (most of
which also apply to 3.3).
I believe we should try to tackle these first (and deliver a
sensibly improved GCC 3.2.3 after the forthcoming 3.2.2).
>> There's more I'd like to say, but I can't. Hopefully soon.
> This continues to annoy me, but I understand why you do it. The longer
> you say this line, the less I believe there's anything to say.
Given how many ABI bugs CodeSourcery developers have already fixed
(and the fact that I cannot remember Mark ever promising something
he hasn't kept), I'm much more optimistic.
BTW, if you consider my finding of C ABI breakage for several, not so
minor platforms today, apparently we could also use a C ABI testsuite.
> I think the longer gcc, as a project, goes on without an autobuild
> continuous regression checker, the worse off things will get. Somebody
> [...] will have to step up with the bandwidth, time, and machine to do
> this.
Fully agreed.
Well, why don't we send a "Call for support" to the gcc-announce list?
Seriously.
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.pfeifer.com/gerald/
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 1:14 ` Gabriel Dos Reis
@ 2003-01-31 1:25 ` Benjamin Kosnik
0 siblings, 0 replies; 115+ messages in thread
From: Benjamin Kosnik @ 2003-01-31 1:25 UTC (permalink / raw)
To: Gabriel Dos Reis; +Cc: gcc, mark
>I would suggest we really make major releases at most twice in the year
>(I don't believe there is any point in trying to make the highest
>number of major releases) but make dot or bug fix releases every two
>months.
I would really like this! Especially the bug fix release idea.
It would remove the issue that the current release plan has, where
nobody seems to know when to do a release of the older, stable branch
when there are new and shiny branches around to distract us.
We could try to do regular, 2 or 3 month releases of the 3_2-branch and
see how it worked out. I think that would be wonderful.
-benjamin
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 1:10 ` Benjamin Kosnik
@ 2003-01-31 1:22 ` Gabriel Dos Reis
0 siblings, 0 replies; 115+ messages in thread
From: Gabriel Dos Reis @ 2003-01-31 1:22 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: Matt Austern, neil, mrs, gcc
Benjamin Kosnik <bkoz@redhat.com> writes:
| >I would look at it a different way. It does improve the compiler, so
| >we should do it. But it doesn't identify where the 3.2 -> 3.3
| >regression came from; I think we're still no closer to identifying
| >that regression than we were.
|
| Agree, 100%. There are two issues.
|
| 1) Magic constants, setting memory to 16MB, improving compile speed
| right now. Arguments that bumping up this value doesn't speed compiles
| are ludicrous, and ignore experimental evidence.
|
| 2) figuring out what happened between 3.2 and 3.3, or 3.4 and 3.3. There
| are no clear fixes for this right now. There are a lot of clever people
| looking at it so I'm sure something will eventually turn up.
I believe (but I may be worng) that Neil's argument is that once 1) is
done, people will ignore or won't be interested into solving
2)... until it pops again in later versions. Quite understandable.
On the other hand, 3.3.0 deadline is approaching and people would like
to concentrate on other issues. Again, quite understandable.
-- Gaby
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:52 ` Zack Weinberg
@ 2003-01-31 1:16 ` Gabriel Dos Reis
2003-01-31 1:34 ` Zack Weinberg
0 siblings, 1 reply; 115+ messages in thread
From: Gabriel Dos Reis @ 2003-01-31 1:16 UTC (permalink / raw)
To: Zack Weinberg; +Cc: Benjamin Kosnik, gcc, mark
Zack Weinberg <zack@codesourcery.com> writes:
| Benjamin Kosnik <bkoz@redhat.com> writes:
| >
| > I've versioned the runtimes assuming that 3.3 will not break the 3.2
| > ABI, and that 3.4 will. Lacking clear guidance on what to do, I think
| > this was an ok decision.
|
| There are groups out there, such as the LSB (Linux Standard Base)
| effort, who are working on the assumption that the 3.2 ABI will
| *never* be changed again.
I believe the agreement was that the 3.2 and 3.3 won't be changed for
the 3.2.x and 3.3.x series.
But that agreement does not export to higher versions. People reading
more into that agreement should be advised to coordinate/ask people
workiing the C++ ABI and GCC/g++.
-- Gaby
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:37 Benjamin Kosnik
2003-01-31 0:52 ` Zack Weinberg
@ 2003-01-31 1:14 ` Gabriel Dos Reis
2003-01-31 1:25 ` Benjamin Kosnik
2003-01-31 1:27 ` Gerald Pfeifer
` (3 subsequent siblings)
5 siblings, 1 reply; 115+ messages in thread
From: Gabriel Dos Reis @ 2003-01-31 1:14 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: gcc, mark
Benjamin Kosnik <bkoz@redhat.com> writes:
| >Feel free to suggest a better one!
|
| Perhaps updating this would help this discussion:
| http://gcc.gnu.org/develop.html#future
|
| Shipping GCC 3.3.0 on March 1 will require enormous effort.
|
| I guess I'm more concerned about the timing on the gcc-3.4.0 effort.
| >From the above link, I cannot tell when it's supposed to be released.
|
| Anyway. I guess I'm just really leery of releases a la 3.1.0. That
| release was pushed back into the summer, when students are out of
| school, people are on vacation, etc.
I would suggest we really make major releases at most twice in the year
(I don't believe there is any point in trying to make the highest
number of major releases) but make dot or bug fix releases every two
months.
[...]
| I've versioned the runtimes assuming that 3.3 will not break the 3.2
| ABI, and that 3.4 will. Lacking clear guidance on what to do, I think
| this was an ok decision.
|
| I'd prefer a better process though.
Agreed.
-- Gaby
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:25 ` Matt Austern
@ 2003-01-31 1:10 ` Benjamin Kosnik
2003-01-31 1:22 ` Gabriel Dos Reis
0 siblings, 1 reply; 115+ messages in thread
From: Benjamin Kosnik @ 2003-01-31 1:10 UTC (permalink / raw)
To: Matt Austern; +Cc: neil, mrs, gcc
>I would look at it a different way. It does improve the compiler, so
>we should do it. But it doesn't identify where the 3.2 -> 3.3
>regression came from; I think we're still no closer to identifying
>that regression than we were.
Agree, 100%. There are two issues.
1) Magic constants, setting memory to 16MB, improving compile speed
right now. Arguments that bumping up this value doesn't speed compiles
are ludicrous, and ignore experimental evidence.
2) figuring out what happened between 3.2 and 3.3, or 3.4 and 3.3. There
are no clear fixes for this right now. There are a lot of clever people
looking at it so I'm sure something will eventually turn up.
I'd rather the people working on #2 set their memory limits artificially
low (just as easy, use the same command line flags) then continue to
make the rest of us suffer.
Apple has already done #1 in their production compiler. I'd advocate
that Red Hat should do the same.
-benjamin
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:37 Benjamin Kosnik
@ 2003-01-31 0:52 ` Zack Weinberg
2003-01-31 1:16 ` Gabriel Dos Reis
2003-01-31 1:14 ` Gabriel Dos Reis
` (4 subsequent siblings)
5 siblings, 1 reply; 115+ messages in thread
From: Zack Weinberg @ 2003-01-31 0:52 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: gcc, mark
Benjamin Kosnik <bkoz@redhat.com> writes:
>
> I've versioned the runtimes assuming that 3.3 will not break the 3.2
> ABI, and that 3.4 will. Lacking clear guidance on what to do, I think
> this was an ok decision.
There are groups out there, such as the LSB (Linux Standard Base)
effort, who are working on the assumption that the 3.2 ABI will
*never* be changed again.
zw
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:15 ` Neil Booth
2003-01-31 0:29 ` Phil Edwards
@ 2003-01-31 0:41 ` Mike Stump
1 sibling, 0 replies; 115+ messages in thread
From: Mike Stump @ 2003-01-31 0:41 UTC (permalink / raw)
To: Neil Booth; +Cc: Mike Stump, Benjamin Kosnik, gcc
On Thursday, January 30, 2003, at 03:38 PM, Neil Booth wrote:
> I'm interested in improving the quality of GCC. Your statment above
> indicates you're interested in pointing to a number and saying "look,
> it's lower", regardless of what that means long-term. Hell, let's
> not free anything at all and turn GC off altogether; GCC would be
> faster
> for 90% of files I imagine.
Guess what? For smaller programs, it already does that! So, you are
just describing status quo.
> The improvements you're justifying are short-term gratification, but
> make the genuine
> improvements harder to develop, hard to find, and less easy to justify.
> I don't think that's a good thing for the project long-term.
Does this mean that we should immediately change the 8MB to 0MB?
What I _am_ saying is, pretend the 8MB wasn't there. I want you to
come up with the right number, the best number, the number you can say,
this is the right number and I like it. Don't peek at what it was
before, that is cheating. Tell me, what is the best number, and why?
This is a serious question. Please support your number, so that we
know that it wasn't just a wild ass guess, as certainly, we are better
than that.
Each magic constant needs to be defended and tweaked from time to time,
that is just the nature of magic constants. I do agree with you, that
it is better to not have magic constants, it is better to have well
thought out algorithms in the compiler that don't need magic constants,
but I'm pragmatic on this point I guess. Look at all the magic
constants in the code already, it is littered with them. I don't think
I've seen a compelling existence proof that it _is_ possible to get rid
of them.
I don't think we should disallow fixing of broken magic constants, just
because it might be possible to write the code without them. If we can
find a better magic constant, and get a 25% speed improvement, why
should we sacrifice the improvement?
If we must make the compiler perform worse to try and trick someone
into substantially improving it, why is 100KB not a better magic
constant than 8MB? Surely that would cause more pain than the current
number?
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
@ 2003-01-31 0:37 Benjamin Kosnik
2003-01-31 0:52 ` Zack Weinberg
` (5 more replies)
0 siblings, 6 replies; 115+ messages in thread
From: Benjamin Kosnik @ 2003-01-31 0:37 UTC (permalink / raw)
To: gcc; +Cc: mark
>Feel free to suggest a better one!
Perhaps updating this would help this discussion:
http://gcc.gnu.org/develop.html#future
Shipping GCC 3.3.0 on March 1 will require enormous effort.
I guess I'm more concerned about the timing on the gcc-3.4.0 effort.
From the above link, I cannot tell when it's supposed to be released.
Anyway. I guess I'm just really leery of releases a la 3.1.0. That
release was pushed back into the summer, when students are out of
school, people are on vacation, etc.
It would seem to me that gcc-3.4, optimally, should be starting to enter
phase three around October. That's after Europe is back from break, and
students around the world are back on it.
Just a thought.
> I do not think this is not an issue for 3.3; no ABI breakage is supposed
> to occur there as far as I know.
Well, me too. However, I expected the SC to show more leadership on this
issue. I'm disappointed by the current lack of policy. Matt had brought
up this issue when the quick, "oops" 3.2.0 release was made. Now I
see the wisdom of his comments.
I've versioned the runtimes assuming that 3.3 will not break the 3.2
ABI, and that 3.4 will. Lacking clear guidance on what to do, I think
this was an ok decision.
I'd prefer a better process though.
> On the compiler side, I don't think there's much point in changing the
> ABI until we can get 100% compliant. (The ways in which we're wrong
> don't really affect users, and the fewer times we change the better.)
Sounds good. I'd prefer to not break the runtime ABI unless I knew wide
io worked. That effort is just starting. There are issues with the
current runtime ABI, that can be gleaned from the versioning patches of
last week.
>> 2) Any kind of ABI testing. I don't think the Intel ABI tester is
>> sufficient.
> This is a hard problem and one I'm very familar with.
> This is a problem we have had since forever with G++, and it is better
> than it has been.
I don't see how.
> There's more I'd like to say, but I can't. Hopefully soon.
This continues to annoy me, but I understand why you do it. The longer
you say this line, the less I believe there's anything to say.
> If you have suggestions, I'm sure they'd be very welcome!
My suggestion: somebody develop a GPL'd, FSF copyright (negotiable) ABI
testsuite. Both EDG and Codesourcery have them, the rest of us should too.
I continue to believe that proprietary testsuites are just as evil as
proprietary compilers and runtimes.
> Would you please volunteer to run the tests and extract PRs for GNATs?
Sorry, but no. I don't have the time to do this well. I think that Janis
(and the rest of the regression hunters, bangerth in particular) are
really doing a good job along these lines for mainline: they should be
encouraged to continue efforts on the release branch.
I think the longer gcc, as a project, goes on without an autobuild
continuous regression checker, the worse off things will get. It was
nice of Red Hat to initially support this effort, but it is obvious that
this time is past as the regression checker is long dead. Somebody else
will have to step up with the bandwidth, time, and machine to do this.
Some of these frustrations are with the development process, and have
nothing to do with you or the SC. Please keep in mind that I have the
utmost respect for both you and the SC.
best,
benjamin
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:29 ` Phil Edwards
@ 2003-01-31 0:30 ` Neil Booth
2003-01-31 2:08 ` Mike Stump
0 siblings, 1 reply; 115+ messages in thread
From: Neil Booth @ 2003-01-31 0:30 UTC (permalink / raw)
To: Phil Edwards; +Cc: Mike Stump, Benjamin Kosnik, gcc
Phil Edwards wrote:-
> I detect the note of frustration, but I think this is an experiment
> worth making. Say, allow --with-gc=none (re-allow?) to choose ggc-none.c,
> and see what happens.
>
> Perhaps the compiler need only turn on GC at all once a threshold number
> of... something... has been passed. (Statements? Tree nodes created?
> Dunno.)
Whatever we do, the worst thing is to make GCC non-deterministic.
Someone suggested this (Geoff?) and someone else (Mike I think!) pointed
out what a bad idea this was.
Neil.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:15 ` Neil Booth
@ 2003-01-31 0:29 ` Phil Edwards
2003-01-31 0:30 ` Neil Booth
2003-01-31 0:41 ` Mike Stump
1 sibling, 1 reply; 115+ messages in thread
From: Phil Edwards @ 2003-01-31 0:29 UTC (permalink / raw)
To: Neil Booth; +Cc: Mike Stump, Benjamin Kosnik, gcc
On Thu, Jan 30, 2003 at 11:38:24PM +0000, Neil Booth wrote:
> Hell, let's
> not free anything at all and turn GC off altogether; GCC would be faster
> for 90% of files I imagine.
I detect the note of frustration, but I think this is an experiment
worth making. Say, allow --with-gc=none (re-allow?) to choose ggc-none.c,
and see what happens.
Perhaps the compiler need only turn on GC at all once a threshold number
of... something... has been passed. (Statements? Tree nodes created?
Dunno.)
Phil
--
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
- Edsger Dijkstra, 1930-2002
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:21 ` Neil Booth
@ 2003-01-31 0:25 ` Matt Austern
2003-01-31 1:10 ` Benjamin Kosnik
2003-01-31 1:55 ` Mike Stump
1 sibling, 1 reply; 115+ messages in thread
From: Matt Austern @ 2003-01-31 0:25 UTC (permalink / raw)
To: Neil Booth; +Cc: Benjamin Kosnik, Mike Stump, gcc
On Thursday, January 30, 2003, at 03:47 PM, Neil Booth wrote:
> I agree the defaults might not be "right", and that in a sense getting
> them "right" improves the compiler. But it's not really improved the
> compiler, if you see what I mean.
I would look at it a different way. It does improve the compiler, so
we should do it. But it doesn't identify where the 3.2 -> 3.3
regression came from; I think we're still no closer to identifying
that regression than we were.
We should improve user experience, but we also have to learn what
changed between 3.2 and 3.3 that made things worse. I hate to think
that we'll release a 3.3 that's worse than 3.2 and that we won't even
know why.
--Matt
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-31 0:17 ` Benjamin Kosnik
@ 2003-01-31 0:21 ` Neil Booth
2003-01-31 0:25 ` Matt Austern
2003-01-31 1:55 ` Mike Stump
2003-01-31 1:54 ` Mike Stump
2003-01-31 2:40 ` Geoff Keating
2 siblings, 2 replies; 115+ messages in thread
From: Neil Booth @ 2003-01-31 0:21 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: Mike Stump, gcc
Benjamin Kosnik wrote:-
> >Yes, it really is faster. It really is better. Consider for example
> >that we had the value be 2KB, and 1% increase, and someone said bumping
> >it up to 30% and 8MB is wrong and just papers over the real problem.
> >We'd laugh at them, just the same way I laugh at you now.
>
> You know, I agree with you. I could not figure out why Neil was saying
> this, when I posted real timing numbers, based on increased numbers, and
> others backed me up.
But were you comparing against an earlier compiler with similarly
increased GC parameters? That's the comparison that matters, and
I'm sure you'd lose that one.
I agree the defaults might not be "right", and that in a sense getting
them "right" improves the compiler. But it's not really improved the
compiler, if you see what I mean.
Neil.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 23:55 ` Mike Stump
2003-01-31 0:11 ` Paolo Carlini
2003-01-31 0:15 ` Neil Booth
@ 2003-01-31 0:17 ` Benjamin Kosnik
2003-01-31 0:21 ` Neil Booth
` (2 more replies)
2 siblings, 3 replies; 115+ messages in thread
From: Benjamin Kosnik @ 2003-01-31 0:17 UTC (permalink / raw)
To: Mike Stump; +Cc: neil, gcc
>> we're not really getting any faster.
>
>Yes, it really is faster. It really is better. Consider for example
>that we had the value be 2KB, and 1% increase, and someone said bumping
>it up to 30% and 8MB is wrong and just papers over the real problem.
>We'd laugh at them, just the same way I laugh at you now.
You know, I agree with you. I could not figure out why Neil was saying
this, when I posted real timing numbers, based on increased numbers, and
others backed me up.
It seems as if the defaults were set arbitrarily: testing with various
numbers tells me that bumping up to 16MB gets the maximum bang for the
minimum setting.
Holding on to these poorly picked initial numbers, in the face of data
that suggests a better set of number, seems to be incredibly foolish.
Neil, did you miss out on the Monday thread on the garbage collector?
>We have two ways of fixing the problem, one trivial, and one hard, you
>suggest not fixing it the easy way, because we'd rather not fix it,
>than fix it the easy way? [blink]
Or not fix it. Which seems to be what is happening.
>The changes are not mutually exclusive. Both changes make gcc better.
>Each change by itself makes gcc better.
Right.
>Also, some of the slowdown as laid at the feet of a much larger
>libstdc++, not that that is bad, it just is. Now with PCH, maybe we
>want to have a header called <all> that includes all the normal C++
>headers and precompile it, and switch all the normal C++ headers to
>#include <all>.
>Hello world then sees a nice speed improvement.
Some of the slowdown between 2.95 and 3.0 can be laid at the feet of
libstdc++. The slowdown between 3.0 and 3.2, 3.2 and 3.3, and 3.4
cannot.
I sent Geoff K a way to make the standard C++ pch. I, and others,
continue to work with him to make C++ + pch play nice. If you're
interested, search gcc and other categories in GNATS for [pch].
You can count on libstdc++ changes to use PCH as soon as it becomes possible.
best,
benjamin
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 23:55 ` Mike Stump
2003-01-31 0:11 ` Paolo Carlini
@ 2003-01-31 0:15 ` Neil Booth
2003-01-31 0:29 ` Phil Edwards
2003-01-31 0:41 ` Mike Stump
2003-01-31 0:17 ` Benjamin Kosnik
2 siblings, 2 replies; 115+ messages in thread
From: Neil Booth @ 2003-01-31 0:15 UTC (permalink / raw)
To: Mike Stump; +Cc: Benjamin Kosnik, gcc
Mike Stump wrote:-
> Yes, it really is faster. It really is better. Consider for example
I'm interested in improving the quality of GCC. Your statment above
indicates you're interested in pointing to a number and saying "look,
it's lower", regardless of what that means long-term. Hell, let's
not free anything at all and turn GC off altogether; GCC would be faster
for 90% of files I imagine.
We're going to disagree; there's not much else to say. I know what
you are referring to, and you know what I'm referring to; after all
neither of us is stupid. I really want to see GCC getting better in an
undisputable sense, because I care deeply about GCC. The improvements
you're justifying are short-term gratification, but make the genuine
improvements harder to develop, hard to find, and less easy to justify.
I don't think that's a good thing for the project long-term.
Sorry to disagree,
Neil.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 23:53 Karel Gardas
@ 2003-01-31 0:13 ` Mike Stump
0 siblings, 0 replies; 115+ messages in thread
From: Mike Stump @ 2003-01-31 0:13 UTC (permalink / raw)
To: Karel Gardas; +Cc: GCC Mailing List
On Thursday, January 30, 2003, at 02:56 PM, Karel Gardas wrote:
> As a gcc user badly affected by slow c++ compilation
I'd recommend profiling the compiler during compilation of your
software, and publish the results. I think users should file bug
reports naming the routines at the top (say the top 10). Maintainers
can then know if a certain set of routines pops up time after time
after time, that those routines (or their callers) should be
investigated and fixed.
> I really would like to see such patches somewhere. So my question is:
> where
gcc-patches is where all patches should go.
> and when they'll appear in some of gcc branches?
As soon as they are ready.
> Or are they just available for download for 'brave' g++ user who can
> give them a try?
Not all patches are ready for prime time. If you want to try them as
they go by, you can, though, it is more work than most people want.
One back from that, after you know where your compilation time goes,
you can watch for that routine in gcc-patches, and the word speedup...
and after it goes into the mainline, you can just cvs update the
software, and give it a spin.
Also, it is useful for mere users to watch compile time performance of
their code with compilers from cvs, say weekly, or daily if you have
the spare cycles, and to yell when it suddenly is 5%+ slower. Every
10% you stop, is a 10% speed increase that might not otherwise be there.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 23:55 ` Mike Stump
@ 2003-01-31 0:11 ` Paolo Carlini
2003-01-31 0:15 ` Neil Booth
2003-01-31 0:17 ` Benjamin Kosnik
2 siblings, 0 replies; 115+ messages in thread
From: Paolo Carlini @ 2003-01-31 0:11 UTC (permalink / raw)
To: Mike Stump; +Cc: gcc
Mike Stump wrote:
> Also, some of the slowdown as laid at the feet of a much larger
> libstdc++, not that that is bad, it just is. Now with PCH, maybe we
> want to have a header called <all> that includes all the normal C++
> headers and precompile it, and switch all the normal C++ headers to
> #include <all>.
> Hello world then sees a nice speed improvement.
... but be careful not using std::endl ;-)
(other/9274)
Paolo.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 22:56 ` Neil Booth
2003-01-30 22:58 ` Michael S. Zick
@ 2003-01-30 23:55 ` Mike Stump
2003-01-31 0:11 ` Paolo Carlini
` (2 more replies)
1 sibling, 3 replies; 115+ messages in thread
From: Mike Stump @ 2003-01-30 23:55 UTC (permalink / raw)
To: Neil Booth; +Cc: Benjamin Kosnik, gcc
On Thursday, January 30, 2003, at 12:21 PM, Neil Booth wrote:
> As I pointed out elsewhere, changing a GC default is simply papering
> over the problem; we're not really getting any faster.
Yes, it really is faster. It really is better. Consider for example
that we had the value be 2KB, and 1% increase, and someone said bumping
it up to 30% and 8MB is wrong and just papers over the real problem.
We'd laugh at them, just the same way I laugh at you now.
The reason why it is better, is that taken on the whole, the sum time
of all compiles goes down and user satisfaction with build speed
improves.
Now, if the compiler were magically made to allocate less data using GC
during a compile, the compiler would also happen to be faster, and that
is also good. It is a win-win situation in that case.
If you want to prove me wrong, come up with the data that shows that
compile times would go down, and/or that users would be less happy. We
can then weigh how much we want to care about a 386 with 8MB compiling
X v the rest of the gcc users. Personally, I say special people,
special flags, though, it we can make it right for both sets of people,
that is even better. Geoff is trying the later.
> But it's worse than that - if someone later comes along with
> improvements that improve our algorithms and data structures (those are
> where the real problems lie), the new GC default is going to reduce or
> eliminate the impact of that improvement, an impact that would have
> been
> noticeable had the GC defaults not been changed, and the improvement
> is less likely to happen.
We have two ways of fixing the problem, one trivial, and one hard, you
suggest not fixing it the easy way, because we'd rather not fix it,
than fix it the easy way? [blink]
The changes are not mutually exclusive. Both changes make gcc better.
Each change by itself makes gcc better.
> I think it's fair to say that in all the slowdown since
> 2.95 we've never really identified anything that is causing it (apart
> from GC itself, but that doesn't apply for regressions from 3.0).
No it isn't. I found a regression dealing with GC to the tune of, what
was it, 10% or so. Geoff spotted why min_expand was miscalculated and
did the patch for it.
It is trivial to use the binary search script that finds regressions
and plug in your favorite test case, and find the patches that caused
the regressions. No one has cared to do that.
Hint, good beginner project.
Also, some of the slowdown as laid at the feet of a much larger
libstdc++, not that that is bad, it just is. Now with PCH, maybe we
want to have a header called <all> that includes all the normal C++
headers and precompile it, and switch all the normal C++ headers to
#include <all>.
Hello world then sees a nice speed improvement.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
@ 2003-01-30 23:53 Karel Gardas
2003-01-31 0:13 ` Mike Stump
0 siblings, 1 reply; 115+ messages in thread
From: Karel Gardas @ 2003-01-30 23:53 UTC (permalink / raw)
To: GCC Mailing List
Guys,
allow me just one question. As a gcc user badly affected by slow c++
compilation and as a result not using gcc/g++ for any other development, I
really would like to see such patches somewhere. So my question is: where
and when they'll appear in some of gcc branches? Or are they just
available for download for 'brave' g++ user who can give them a try?
Thanks a lot,
Karel
On Thursday, January 30, 2003, at 11:03 AM, Mark Mitchell wrote:
Well, Mike just checked in a patch that provides a 33% speedup. On the
head, I've checked in several patches that improve performance by several
percent, and have more in the works. Nathan is working on a patch to
remove exponential (no, not just quadratic, exponential) behavior in the
C++ front end that has been there since *forever* -- probably 2.7.2.
Sigh, I have a patch that gives a 10x improvement on compile speed...
It makes template programming, fast. I think it rises up to the top of
work to get into the tree next, I think... The change is to ditch the
linked lists from the specializations, instantiations and mangling code.
--
Karel Gardas kgardas@objectsecurity.com
ObjectSecurity Ltd. http://www.objectsecurity.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 23:22 ` Michael Matz
@ 2003-01-30 23:25 ` Michael S. Zick
2003-01-31 11:16 ` Bernd Jendrissek
1 sibling, 0 replies; 115+ messages in thread
From: Michael S. Zick @ 2003-01-30 23:25 UTC (permalink / raw)
To: Michael Matz; +Cc: gcc
On Thursday 30 January 2003 03:29 pm, Michael Matz wrote:
> Hi,
>
> On Thu, 30 Jan 2003, Michael S.Zick wrote:
> > > where the real problems lie), the new GC default is going to reduce or
> > > eliminate the impact of that improvement, an impact that would have
> > > been noticeable had the GC defaults not been changed, and the
> > > improvement is less likely to happen.
> >
> > So, lets make part of the testing protocal: "disable GC"
>
> What can be disabled easily is collecting and reclaiming GC memory. What
> can _not_ be done easily is to go back to a memory management like in
> 2.95.x or earlier. But that would be needed to really calculate the cost
> of GC, because collecting is only a part of the overhead.
>
Understood.
I wasn't clear what part of the statement my suggestion applied too.
The statement was that improvements in parts of the compiler
other than GC could (would) be hidden in the "noise" of changing
GC defaults.
I was suggesting that the "other parts" be compared by tests
run such that "GC noise" is worked around.
I seem to recall mention on this list of an option that can be passed
specifying, in effect: GC=never.
That is what I was suggesting - not a way to cost or measure
GC - a way to cost or measure everything else.
Mike
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 22:58 ` Michael S. Zick
@ 2003-01-30 23:22 ` Michael Matz
2003-01-30 23:25 ` Michael S. Zick
2003-01-31 11:16 ` Bernd Jendrissek
0 siblings, 2 replies; 115+ messages in thread
From: Michael Matz @ 2003-01-30 23:22 UTC (permalink / raw)
To: Michael S.Zick; +Cc: gcc
Hi,
On Thu, 30 Jan 2003, Michael S.Zick wrote:
> > where the real problems lie), the new GC default is going to reduce or
> > eliminate the impact of that improvement, an impact that would have been
> > noticeable had the GC defaults not been changed, and the improvement
> > is less likely to happen.
> >
> So, lets make part of the testing protocal: "disable GC"
What can be disabled easily is collecting and reclaiming GC memory. What
can _not_ be done easily is to go back to a memory management like in
2.95.x or earlier. But that would be needed to really calculate the cost
of GC, because collecting is only a part of the overhead. The other part
comes from different layout of memory, and the resulting slowness is
distributed all over the compiler (so is not even measurable in one single
function suddenly taking much more time). To this end we can't simply
"disable" GC. One would need to rewrite the allocators too, but then have
the problem that noone is freeing memory explicitely anymore, which would
again be different to 2.95.x.
Ciao,
Michael.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 22:56 ` Neil Booth
@ 2003-01-30 22:58 ` Michael S. Zick
2003-01-30 23:22 ` Michael Matz
2003-01-30 23:55 ` Mike Stump
1 sibling, 1 reply; 115+ messages in thread
From: Michael S. Zick @ 2003-01-30 22:58 UTC (permalink / raw)
To: Neil Booth, Benjamin Kosnik; +Cc: gcc
On Thursday 30 January 2003 02:21 pm, Neil Booth wrote:
> Benjamin Kosnik wrote:-
>
> > 3) Any kind of attempt at compile-time regressions or compile time
> > performance at all. Dropping the release criteria, or ignoring the
> > release criteria that deals with compile time performance is
> > unacceptable. Sane defaults in the garbage collector would be a big win
> > here.
>
> As I pointed out elsewhere, changing a GC default is simply papering
> over the problem; we're not really getting any faster.
>
> But it's worse than that - if someone later comes along with
> improvements that improve our algorithms and data structures (those are
> where the real problems lie), the new GC default is going to reduce or
> eliminate the impact of that improvement, an impact that would have been
> noticeable had the GC defaults not been changed, and the improvement
> is less likely to happen.
>
So, lets make part of the testing protocal: "disable GC"
My following this list does not date back to the 2.95.x era - so I don't
know "how it used to be done".
Other recent messages on the M-L mention various URL's with hints...
I have several machines collecting dust here;
they could be doing something useful -
if someone could contact me with details of
what and how you need things to be done.
Mike
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 20:00 Benjamin Kosnik
2003-01-30 21:29 ` Mark Mitchell
2003-01-30 22:15 ` Joseph S. Myers
@ 2003-01-30 22:56 ` Neil Booth
2003-01-30 22:58 ` Michael S. Zick
2003-01-30 23:55 ` Mike Stump
2 siblings, 2 replies; 115+ messages in thread
From: Neil Booth @ 2003-01-30 22:56 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: gcc
Benjamin Kosnik wrote:-
> 3) Any kind of attempt at compile-time regressions or compile time
> performance at all. Dropping the release criteria, or ignoring the
> release criteria that deals with compile time performance is unacceptable.
> Sane defaults in the garbage collector would be a big win here.
As I pointed out elsewhere, changing a GC default is simply papering
over the problem; we're not really getting any faster.
But it's worse than that - if someone later comes along with
improvements that improve our algorithms and data structures (those are
where the real problems lie), the new GC default is going to reduce or
eliminate the impact of that improvement, an impact that would have been
noticeable had the GC defaults not been changed, and the improvement
is less likely to happen.
I'm starting to feel quite pessimistic about these things ever genuinely
improving. I think it's fair to say that in all the slowdown since
2.95 we've never really identified anything that is causing it (apart
from GC itself, but that doesn't apply for regressions from 3.0).
Neil.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 20:00 Benjamin Kosnik
2003-01-30 21:29 ` Mark Mitchell
@ 2003-01-30 22:15 ` Joseph S. Myers
2003-01-30 22:56 ` Neil Booth
2 siblings, 0 replies; 115+ messages in thread
From: Joseph S. Myers @ 2003-01-30 22:15 UTC (permalink / raw)
To: Benjamin Kosnik; +Cc: gcc
On Thu, 30 Jan 2003, Benjamin Kosnik wrote:
> 4) Deficiencies in the testing plan. For gcc-3.0.0, Peter Schmidt did a
> wonderful job of keeping the rest of the developers in the know about
> how key software packages were performing when compiled with the
> soon-to-be-released compiler. A return to actually testing the software
> packages that are in the release criteria, and not shipping until they
> pass, would be welcome.
And for 2.95.3 there was thorough testing of both 2.95.2 and the branch
against a current testsuite version, to detect regressions shown up by the
testsuite <http://gcc.gnu.org/gcc-2.95/testing.html>. Similar testing was
done for previous releases as well. So instructions on how to test
previous compiler versions (whether installed or building them for the
purpose) with the current testsuite would be useful (with test results for
the past versions and the branch then sent to gcc-testresults); comparison
of the results on the primary and secondary platforms can then show what
regressions there are in the testsuite. (Revision 1.102 of
gcc-2.95/regress.html has some instructions that were used in the past on
testing with past installed versions.)
Of course having the testcase library of testcases for PRs
<http://gcc.gnu.org/ml/gcc/2002-12/msg01250.html> in the testsuite would
make such testing more useful.
--
Joseph S. Myers
jsm28@cam.ac.uk
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 21:29 ` Mark Mitchell
@ 2003-01-30 21:42 ` Mike Stump
2003-01-31 13:31 ` Nathan Sidwell
0 siblings, 1 reply; 115+ messages in thread
From: Mike Stump @ 2003-01-30 21:42 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Benjamin Kosnik, gcc
On Thursday, January 30, 2003, at 11:03 AM, Mark Mitchell wrote:
> Well, Mike just checked in a patch that provides a 33% speedup. On the
> head, I've checked in several patches that improve performance by
> several
> percent, and have more in the works. Nathan is working on a patch to
> remove exponential (no, not just quadratic, exponential) behavior in
> the
> C++ front end that has been there since *forever* -- probably 2.7.2.
Sigh, I have a patch that gives a 10x improvement on compile speed...
It makes template programming, fast.
I think it rises up to the top of work to get into the tree next, I
think...
The change is to ditch the linked lists from the specializations,
instantiations and mangling code.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 20:00 Benjamin Kosnik
@ 2003-01-30 21:29 ` Mark Mitchell
2003-01-30 21:42 ` Mike Stump
2003-01-30 22:15 ` Joseph S. Myers
2003-01-30 22:56 ` Neil Booth
2 siblings, 1 reply; 115+ messages in thread
From: Mark Mitchell @ 2003-01-30 21:29 UTC (permalink / raw)
To: Benjamin Kosnik, gcc
--On Thursday, January 30, 2003 12:29:10 PM -0600 Benjamin Kosnik
<bkoz@redhat.com> wrote:
>
> I think your proposed schedule is highly unrealistic.
Feel free to suggest a better one! (I like it when things like this
happen; a lot of times starting to move one way gets people excited
and they show us a better way to go.)
> 1) Some kind of planned ABI breakage. When? How is it tested? Putting
> this off to the last minute might be ok for the compiler, but I no
> longer think this is acceptable, in practice, for the C++ runtime.
> Versioning the runtime is non-trivial.
I do not think this is not an issue for 3.3; no ABI breakage is supposed
to occur there as far as I know.
I don't think that's been decided for 3.4 yet, but I think it's great
that you're bring it up. What do you think?
On the compiler side, I don't think there's much point in changing the
ABI until we can get 100% compliant. (The ways in which we're wrong
don't really affect users, and the fewer times we change the better.)
At this point, I believe our vtable, VTT, and object layout situation
is extremely good. In other words, I know of no bugs, and I've looked
very hard using lots of eyes and lots and lots of tests. (Thousands.)
I do know of name-mangling bugs, and my work on the mainline over the
past few days is designed to work towards solving these problems. We
need fully correct dependent name analysis in order to get this right,
and that's work in the front end.
> 2) Any kind of ABI testing. I don't think the Intel ABI tester is
> sufficient.
This is a hard problem and one I'm very familar with.
This is a problem we have had since forever with G++, and it is better
than it has been.
There's more I'd like to say, but I can't. Hopefully soon.
If you have suggestions, I'm sure they'd be very welcome!
> 3) Any kind of attempt at compile-time regressions or compile time
> performance at all. Dropping the release criteria, or ignoring the
> release criteria that deals with compile time performance is unacceptable.
> Sane defaults in the garbage collector would be a big win here.
Well, Mike just checked in a patch that provides a 33% speedup. On the
head, I've checked in several patches that improve performance by several
percent, and have more in the works. Nathan is working on a patch to
remove exponential (no, not just quadratic, exponential) behavior in the
C++ front end that has been there since *forever* -- probably 2.7.2.
My job as RM is to help with patches on the branch; I'll try to review
patches if you send them to me personally.
> 4) Deficiencies in the testing plan. For gcc-3.0.0, Peter Schmidt did a
> wonderful job of keeping the rest of the developers in the know about
> how key software packages were performing when compiled with the
> soon-to-be-released compiler. A return to actually testing the software
> packages that are in the release criteria, and not shipping until they
> pass, would be welcome.
Would you please volunteer to run the tests and extract PRs for GNATs?
That would be a huge help since it would allow people to focus on
whatever bugs have been introduced.
Also, would you send me a phone number where you can be reached? I'd
like to talk to you for a few minutes, if you're available.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 20:15 ` Mike Stump
@ 2003-01-30 20:59 ` Mark Mitchell
0 siblings, 0 replies; 115+ messages in thread
From: Mark Mitchell @ 2003-01-30 20:59 UTC (permalink / raw)
To: Mike Stump; +Cc: Mike Stump, gcc
--On Thursday, January 30, 2003 10:31:17 AM -0800 Mike Stump
<mstump@apple.com> wrote:
> On Thursday, January 30, 2003, at 10:16 AM, Mark Mitchell wrote:
>> If you point me at the URL for the patch, I will look at it.
>
> http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02271.html
>
> Ok for 3.3?
Thanks; I remember now. Yes, this is fine for 3.3, once you run it
through the usual testing.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 19:58 ` Mark Mitchell
@ 2003-01-30 20:15 ` Mike Stump
2003-01-30 20:59 ` Mark Mitchell
0 siblings, 1 reply; 115+ messages in thread
From: Mike Stump @ 2003-01-30 20:15 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Mike Stump, gcc
On Thursday, January 30, 2003, at 10:16 AM, Mark Mitchell wrote:
> If you point me at the URL for the patch, I will look at it.
http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02271.html
Ok for 3.3?
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 19:52 ` Mark Mitchell
@ 2003-01-30 20:11 ` David Edelsohn
0 siblings, 0 replies; 115+ messages in thread
From: David Edelsohn @ 2003-01-30 20:11 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc
>>>>> Mark Mitchell writes:
Mark> This is the problem with the whole volunteer thing; when push comes to
Mark> shove, I have just a few choices: fix stuff myself, release it anyway,
Mark> or delay it. Which one of those choices makes sense depends on where
Mark> we are and what everyone else thinks.
Mark> I've gotten more "flexible" with the release criteria over the years
Mark> because in practice it does not seem to be possible to actually achieve
Mark> them with the resources we have. I try to stay pretty zealous about
Mark> the GNATS PRs, though; those indicate things people have actually
Mark> noticed in the real world.
We have some general goals about improvements that should appear
in GCC 3.4. We certainly have merged large changes during Stage 2 and
Stage 3 development. We need to remain flexible to prevent development
divergence and to attract the largest number of developers to help get the
releases finished.
The best way to avoid your spending a lot of time fixing bugs
yourself is to create an environment that motivates the larger developer
community to fix the bugs.
Thanks, David
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
@ 2003-01-30 20:00 Benjamin Kosnik
2003-01-30 21:29 ` Mark Mitchell
` (2 more replies)
0 siblings, 3 replies; 115+ messages in thread
From: Benjamin Kosnik @ 2003-01-30 20:00 UTC (permalink / raw)
To: gcc
I think your proposed schedule is highly unrealistic.
What concerns me, however, is that here has been no attempt, by either
the RM or the Steering Committee, to address the problems with the 3.1.x
and subsequent 3.2.x release process.
These include, but are not limited to:
1) Some kind of planned ABI breakage. When? How is it tested? Putting
this off to the last minute might be ok for the compiler, but I no
longer think this is acceptable, in practice, for the C++ runtime.
Versioning the runtime is non-trivial.
2) Any kind of ABI testing. I don't think the Intel ABI tester is sufficient.
3) Any kind of attempt at compile-time regressions or compile time
performance at all. Dropping the release criteria, or ignoring the
release criteria that deals with compile time performance is unacceptable.
Sane defaults in the garbage collector would be a big win here.
4) Deficiencies in the testing plan. For gcc-3.0.0, Peter Schmidt did a
wonderful job of keeping the rest of the developers in the know about
how key software packages were performing when compiled with the
soon-to-be-released compiler. A return to actually testing the software
packages that are in the release criteria, and not shipping until they
pass, would be welcome.
-benjamin
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 19:07 ` Mike Stump
@ 2003-01-30 19:58 ` Mark Mitchell
2003-01-30 20:15 ` Mike Stump
0 siblings, 1 reply; 115+ messages in thread
From: Mark Mitchell @ 2003-01-30 19:58 UTC (permalink / raw)
To: Mike Stump; +Cc: gcc
--On Thursday, January 30, 2003 10:01:26 AM -0800 Mike Stump
<mstump@apple.com> wrote:
> On Wednesday, January 29, 2003, at 11:28 PM, Mark Mitchell wrote:
>> I would like to release GCC 3.3 on March 1.
>
>> I'll start banging on GCC 3.3 regressions, and encouraging others to
>> do the same.
>
> Matt will bring up the issue of compile time regressions... :-) To that
> end, I'd like to ask if I can move the regclass change from mainline to
> 3.3. While _it_ specifically didn't regress, it helps hide the other,
> real regressions. Those should be fixed as well...
If you point me at the URL for the patch, I will look at it.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 19:20 ` Matt Austern
@ 2003-01-30 19:52 ` Mark Mitchell
2003-01-30 20:11 ` David Edelsohn
0 siblings, 1 reply; 115+ messages in thread
From: Mark Mitchell @ 2003-01-30 19:52 UTC (permalink / raw)
To: Matt Austern; +Cc: gcc
--On Thursday, January 30, 2003 10:06:49 AM -0800 Matt Austern
<austern@apple.com> wrote:
> Do we have a plan for achieving our release criteria in the next three
> weeks, and a contingency plan for what happens if we get to February
> 22 and find that the release criteria aren't yet satisfied?
Not really. Nor do we ever. :-)
We have to make that decision when we get there.
This is the problem with the whole volunteer thing; when push comes to
shove, I have just a few choices: fix stuff myself, release it anyway,
or delay it. Which one of those choices makes sense depends on where
we are and what everyone else thinks.
I've gotten more "flexible" with the release criteria over the years
because in practice it does not seem to be possible to actually achieve
them with the resources we have. I try to stay pretty zealous about
the GNATS PRs, though; those indicate things people have actually
noticed in the real world.
Of course, the more bugs you fix, the better off we will be. :-)
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 11:22 Mark Mitchell
2003-01-30 19:07 ` Mike Stump
@ 2003-01-30 19:20 ` Matt Austern
2003-01-30 19:52 ` Mark Mitchell
1 sibling, 1 reply; 115+ messages in thread
From: Matt Austern @ 2003-01-30 19:20 UTC (permalink / raw)
To: mark; +Cc: gcc
On Wednesday, January 29, 2003, at 11:28 PM, Mark Mitchell wrote:
>
> I've been not doing as good a job as RM as I should have, and for that
> I apologize to all of you.
>
> I've cleared the decks to some extent and will be focusing more on
> these tasks in the days and weeks ahead.
>
> I would like to release GCC 3.3 on March 1. Therefore, I expect to
> completely freeze the compiler on February 22, which gives us a bit
> less than a month to fix up the regressions that apply there.
Do we have a plan for achieving our release criteria in the next three
weeks, and a contingency plan for what happens if we get to February
22 and find that the release criteria aren't yet satisfied?
--Matt
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: GCC 3.3, GCC 3.4
2003-01-30 11:22 Mark Mitchell
@ 2003-01-30 19:07 ` Mike Stump
2003-01-30 19:58 ` Mark Mitchell
2003-01-30 19:20 ` Matt Austern
1 sibling, 1 reply; 115+ messages in thread
From: Mike Stump @ 2003-01-30 19:07 UTC (permalink / raw)
To: mark; +Cc: gcc
On Wednesday, January 29, 2003, at 11:28 PM, Mark Mitchell wrote:
> I would like to release GCC 3.3 on March 1.
> I'll start banging on GCC 3.3 regressions, and encouraging others to
> do the same.
Matt will bring up the issue of compile time regressions... :-) To
that end, I'd like to ask if I can move the regclass change from
mainline to 3.3. While _it_ specifically didn't regress, it helps hide
the other, real regressions. Those should be fixed as well...
^ permalink raw reply [flat|nested] 115+ messages in thread
* GCC 3.3, GCC 3.4
@ 2003-01-30 11:22 Mark Mitchell
2003-01-30 19:07 ` Mike Stump
2003-01-30 19:20 ` Matt Austern
0 siblings, 2 replies; 115+ messages in thread
From: Mark Mitchell @ 2003-01-30 11:22 UTC (permalink / raw)
To: gcc
I've been not doing as good a job as RM as I should have, and for that
I apologize to all of you.
I've cleared the decks to some extent and will be focusing more on
these tasks in the days and weeks ahead.
I would like to release GCC 3.3 on March 1. Therefore, I expect to
completely freeze the compiler on February 22, which gives us a bit
less than a month to fix up the regressions that apply there. I think
that Feb 15th is clearly too optimistic at this stage, and I will be a
taking two days of vacation on the 13th and 14th, which makes the 15th
a particularly unfortunate time.
I'd like to enter stage 2 for GCC 3.4 two weeks after the release
actually occurs. I know that we normally allow a month, but I think
stage 1 has already brought in a lot of changes, and I think another
45 days should be enough to get enough new bugs, ahem, features,
checked in to keep us busy through the GCC 3.4 release cycle.
I'll start banging on GCC 3.3 regressions, and encouraging others to
do the same.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 115+ messages in thread
end of thread, other threads:[~2003-02-06 19:26 UTC | newest]
Thread overview: 115+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-02 6:17 GCC 3.3, GCC 3.4 Brad Lucier
[not found] <1044318563.708.247.camel@steven>
2003-02-04 1:13 ` Scott Robert Ladd
-- strict thread matches above, loose matches on Subject: below --
2003-02-04 0:31 Steven Bosscher
[not found] <200301312121.QAA22864@makai.watson.ibm.com>
2003-02-03 20:44 ` Tom Tromey
2003-02-03 21:02 ` Benjamin Kosnik
2003-02-03 21:10 ` Mark Mitchell
2003-02-03 21:31 ` David Edelsohn
2003-02-03 21:53 ` Mark Mitchell
2003-02-03 22:16 ` Scott Robert Ladd
2003-02-03 22:30 ` Jack Lloyd
2003-02-04 1:21 ` Scott Robert Ladd
2003-02-03 22:03 ` Scott Robert Ladd
2003-02-03 21:45 ` Benjamin Kosnik
2003-02-03 21:56 ` Mark Mitchell
2003-02-03 22:34 ` Tom Tromey
2003-02-03 23:03 ` David Edelsohn
2003-02-03 21:17 ` Gabriel Dos Reis
2003-02-03 21:29 ` Mark Mitchell
2003-02-03 21:41 ` David Edelsohn
2003-02-03 21:42 ` Gabriel Dos Reis
[not found] <1043976898.27601.ezmlm@gcc.gnu.org>
2003-02-03 19:50 ` Tim Josling
2003-02-03 21:54 ` Devang Patel
2003-02-03 22:32 ` Geoff Keating
2003-02-04 20:17 ` Tim Josling
2003-02-04 20:47 ` Matt Austern
2003-02-06 19:26 ` Tim Josling
2003-02-04 0:05 ` Tim Hollebeek
2003-02-04 20:07 ` Tim Josling
2003-02-04 2:03 ` Richard Henderson
2003-02-04 2:26 ` Zack Weinberg
2003-02-04 4:14 ` Daniel Berlin
[not found] <20030131165429.32d4d907.bkoz@redhat.com>
2003-02-01 1:32 ` Mark Mitchell
2003-02-01 1:43 ` Jan Hubicka
[not found] <200301312258.OAA14911@emf.net>
2003-02-01 0:00 ` Mike Stump
2003-01-31 16:29 Richard Kenner
2003-01-31 5:15 Wolfgang Bangerth
2003-01-31 10:39 ` Mike Stump
2003-01-31 17:54 ` Wolfgang Bangerth
2003-01-31 0:37 Benjamin Kosnik
2003-01-31 0:52 ` Zack Weinberg
2003-01-31 1:16 ` Gabriel Dos Reis
2003-01-31 1:34 ` Zack Weinberg
2003-01-31 17:53 ` Mark Mitchell
2003-01-31 1:14 ` Gabriel Dos Reis
2003-01-31 1:25 ` Benjamin Kosnik
2003-01-31 1:27 ` Gerald Pfeifer
2003-01-31 1:52 ` Benjamin Kosnik
2003-01-31 20:59 ` Joe Buck
2003-01-31 22:44 ` Tom Tromey
2003-01-31 6:09 ` Joe Buck
2003-01-31 7:39 ` Zack Weinberg
2003-01-31 20:43 ` Geoff Keating
[not found] ` <200301312127.QAA22861@caip.rutgers.edu>
[not found] ` <jmy9516lsd.fsf@desire.geoffk.org>
2003-02-01 4:32 ` Kaveh R. Ghazi
2003-01-31 11:52 ` Tom Lord
2003-01-31 20:52 ` Joe Buck
[not found] ` <200301312311.PAA15835@emf.net>
2003-02-01 1:28 ` Joe Buck
2003-02-01 1:49 ` Michel LESPINASSE
2003-01-31 21:07 ` Mike Stump
2003-01-31 13:50 ` Joseph S. Myers
2003-01-31 18:02 ` Mark Mitchell
2003-01-31 19:05 ` Devang Patel
2003-01-31 20:05 ` Mark Mitchell
2003-01-31 20:37 ` Graham Stott
2003-01-31 20:57 ` Devang Patel
2003-01-31 21:35 ` Tom Tromey
2003-01-31 21:02 ` Joseph S. Myers
2003-01-31 21:13 ` Joel Sherrill
2003-01-31 21:21 ` Devang Patel
2003-01-31 22:59 ` Joel Sherrill
2003-01-31 23:42 ` Devang Patel
2003-01-31 19:44 ` Matt Austern
2003-01-31 20:23 ` Mark Mitchell
2003-02-01 0:21 ` Michael Matz
2003-02-01 3:18 ` David Edelsohn
2003-01-31 20:31 ` Richard Henderson
2003-01-31 22:59 ` Andreas Jaeger
2003-01-31 23:12 ` Phil Edwards
2003-01-30 23:53 Karel Gardas
2003-01-31 0:13 ` Mike Stump
2003-01-30 20:00 Benjamin Kosnik
2003-01-30 21:29 ` Mark Mitchell
2003-01-30 21:42 ` Mike Stump
2003-01-31 13:31 ` Nathan Sidwell
2003-01-30 22:15 ` Joseph S. Myers
2003-01-30 22:56 ` Neil Booth
2003-01-30 22:58 ` Michael S. Zick
2003-01-30 23:22 ` Michael Matz
2003-01-30 23:25 ` Michael S. Zick
2003-01-31 11:16 ` Bernd Jendrissek
2003-01-30 23:55 ` Mike Stump
2003-01-31 0:11 ` Paolo Carlini
2003-01-31 0:15 ` Neil Booth
2003-01-31 0:29 ` Phil Edwards
2003-01-31 0:30 ` Neil Booth
2003-01-31 2:08 ` Mike Stump
2003-01-31 16:01 ` Michael S. Zick
2003-01-31 0:41 ` Mike Stump
2003-01-31 0:17 ` Benjamin Kosnik
2003-01-31 0:21 ` Neil Booth
2003-01-31 0:25 ` Matt Austern
2003-01-31 1:10 ` Benjamin Kosnik
2003-01-31 1:22 ` Gabriel Dos Reis
2003-01-31 1:55 ` Mike Stump
2003-01-31 1:54 ` Mike Stump
2003-01-31 2:40 ` Geoff Keating
2003-01-31 12:54 ` Richard Earnshaw
2003-01-31 20:22 ` Geoff Keating
2003-01-30 11:22 Mark Mitchell
2003-01-30 19:07 ` Mike Stump
2003-01-30 19:58 ` Mark Mitchell
2003-01-30 20:15 ` Mike Stump
2003-01-30 20:59 ` Mark Mitchell
2003-01-30 19:20 ` Matt Austern
2003-01-30 19:52 ` Mark Mitchell
2003-01-30 20:11 ` David Edelsohn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).