public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: David Edelsohn <dje.gcc@gmail.com>
Cc: Richard Guenther <richard.guenther@gmail.com>,
	       Paolo Bonzini <bonzini@gnu.org>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: PATCH RFA: Build system: Use AC_SYS_LARGEFILE
Date: Tue, 09 Nov 2010 15:26:00 -0000	[thread overview]
Message-ID: <mcriq061q1h.fsf@google.com> (raw)
In-Reply-To: <AANLkTikSW7ZP5xJ-0y6LLSLaX7EtwdpQOHxt6vx7BOEp@mail.gmail.com>	(David Edelsohn's message of "Tue, 9 Nov 2010 09:06:18 -0500")

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

David Edelsohn <dje.gcc@gmail.com> writes:

> Also, given this problem, I want to try a meta-experiment: At the GCC
> Summit, some Google developers proposed that any patch causing
> breakage immediately be reverted, following the practice at Google.
> Jakub mentioned on IRC that reverting the patch will break bootstrap
> on i386-linux and other targets.  So Googlers, how do you want to
> proceed and demonstrate your own proposed policy in action?

Although I was regularly interrupted during that discussion at the
summit, I tried a few times to say that in my opinion the policy would
only apply during the first few days after the patch was committed.
It's been a week for this patch now.

Also there is a conflict in that this patch fixed bootstrap for
i686-unknown-linux-gnu, a primary platform, whereas you are telling us
that it breaks bootstrap for powerpc-ibm-aix5.3.0.0 a secondary
platform.  The right step would have been to revert the earlier
simple_object patch, rather than this one.

So on both those grounds I'm not sure an immediate reversion of this
patch is appropriate now, but I will do it if you ask again.


Another approach would be the appended patch.  Does it fix the problem?
Build maintainers, any opinion?

Ian



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: LARGE --]
[-- Type: text/x-diff, Size: 2450 bytes --]

Index: configure.ac
===================================================================
--- configure.ac	(revision 166441)
+++ configure.ac	(working copy)
@@ -306,6 +306,14 @@ AC_C_INLINE
 
 AC_SYS_LARGEFILE
 
+# flex generated files do not include config.h first, so we need to
+# add _LARGE_FILES to CFLAGS on AIX.
+case $ac_cv_sys_large_files in
+  no | unknown) LFS_CFLAGS= ;;
+  *) LFS_CFLAGS="-D_LARGE_FILES=$ac_cv_sys_large_files" ;;
+esac
+AC_SUBST(LFS_CFLAGS)
+
 # sizeof(char) is 1 by definition.
 AC_CHECK_SIZEOF(void *)
 AC_CHECK_SIZEOF(short)
@@ -1768,7 +1776,7 @@ STMP_FIXINC=stmp-fixinc		AC_SUBST(STMP_F
 # And these apply if build != host, or we are generating coverage data
 if test x$build != x$host || test "x$coverage_flags" != x
 then
-    BUILD_CFLAGS='$(INTERNAL_CFLAGS) $(T_CFLAGS) $(CFLAGS_FOR_BUILD)'
+    BUILD_CFLAGS='$(LFS_CFLAGS) $(INTERNAL_CFLAGS) $(T_CFLAGS) $(CFLAGS_FOR_BUILD)'
     BUILD_LDFLAGS='$(LDFLAGS_FOR_BUILD)'
 fi
 
Index: Makefile.in
===================================================================
--- Makefile.in	(revision 166441)
+++ Makefile.in	(working copy)
@@ -374,7 +378,7 @@ GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./x
 # This is used instead of ALL_CFLAGS when compiling with GCC_FOR_TARGET.
 # It specifies -B./.
 # It also specifies -isystem ./include to find, e.g., stddef.h.
-GCC_CFLAGS=$(CFLAGS_FOR_TARGET) $(INTERNAL_CFLAGS) $(T_CFLAGS) $(LOOSE_WARN) $(C_LOOSE_WARN) -Wold-style-definition $($@-warn) -isystem ./include $(TCFLAGS)
+GCC_CFLAGS=$(CFLAGS_FOR_TARGET) $(LFS_CFLAGS) $(INTERNAL_CFLAGS) $(T_CFLAGS) $(LOOSE_WARN) $(C_LOOSE_WARN) -Wold-style-definition $($@-warn) -isystem ./include $(TCFLAGS)
 
 # ---------------------------------------------------
 # Programs which produce files for the target machine
@@ -985,10 +989,10 @@ INTERNAL_CFLAGS = -DIN_GCC @CROSS@
 # This is the variable actually used when we compile. If you change this,
 # you probably want to update BUILD_CFLAGS in configure.ac
 ALL_CFLAGS = $(T_CFLAGS) $(CFLAGS-$@) \
-  $(CFLAGS) $(INTERNAL_CFLAGS) $(COVERAGE_FLAGS) $(WARN_CFLAGS) @DEFS@
+  $(CFLAGS) $(LFS_CFLAGS) $(INTERNAL_CFLAGS) $(COVERAGE_FLAGS) $(WARN_CFLAGS) @DEFS@
 
 # The C++ version.
-ALL_CXXFLAGS = $(T_CFLAGS) $(CXXFLAGS) $(INTERNAL_CFLAGS) \
+ALL_CXXFLAGS = $(T_CFLAGS) $(CXXFLAGS) $(LFS_CFLAGS) $(INTERNAL_CFLAGS) \
   $(COVERAGE_FLAGS) $(WARN_CXXFLAGS) @DEFS@
 
 # Likewise.  Put INCLUDES at the beginning: this way, if some autoconf macro

  parent reply	other threads:[~2010-11-09 15:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-09 14:15 David Edelsohn
2010-11-09 14:19 ` Paolo Bonzini
2010-11-09 14:19   ` David Edelsohn
2010-11-09 15:26 ` Ian Lance Taylor [this message]
2010-11-09 15:35   ` David Edelsohn
2010-11-09 16:52     ` Ian Lance Taylor
2010-11-09 16:55       ` Paolo Bonzini
2010-11-09 18:19         ` David Edelsohn
2010-11-09 18:37           ` Ian Lance Taylor
2010-11-11 16:27         ` David Edelsohn
2010-11-11 19:58           ` Paolo Bonzini
  -- strict thread matches above, loose matches on Subject: below --
2010-11-02 22:21 Ian Lance Taylor
2010-11-03  1:01 ` Paolo Bonzini
2010-11-03  8:29   ` Jakub Jelinek
2010-11-03 10:49   ` Richard Guenther
2010-11-03 10:49     ` Paolo Bonzini
2010-11-03 14:41     ` Ian Lance Taylor
2010-11-03 14:51       ` Richard Guenther
2010-11-03 15:41         ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mcriq061q1h.fsf@google.com \
    --to=iant@google.com \
    --cc=bonzini@gnu.org \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).