Ping.
On 20 June 2013 20:19, Simon Baldwin sim...@google.com wrote:
Set $ac_aux_dir before use in libdecnumber/configure.
libdecnumber/configure uses $ac_aux_dir before it is set, causing incorrect
MISSING value. Fix with explicit AC_CONFIG_AUX_DIR.
Bootstrapped for c/c++. Okay for trunk
Set $ac_aux_dir before use in libdecnumber/configure.
libdecnumber/configure uses $ac_aux_dir before it is set, causing incorrect
MISSING value. Fix with explicit AC_CONFIG_AUX_DIR.
Bootstrapped for c/c++. Okay for trunk?
libdecnumber/ChangeLog
2013-06-20 Simon Baldwin sim...@google.com
Add new libitm failures to x86_64-grtev3-linux-gnu.xfail.
Okay for google/gcc-4_8? google/main? Thanks.
Index: contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
===
---
Ping. Also, any thoughts on suitability of this (or otherwise) for trunk?
On 1 May 2013 16:04, Simon Baldwin sim...@google.com wrote:
Fix libatomic testsuite for when GCC_UNDER_TEST is not plain xgcc.
Libatomic tests fail if GCC_UNDER_TEST is set to something other than a plain
xgcc
Fix libatomic testsuite for when GCC_UNDER_TEST is not plain xgcc.
Libatomic tests fail if GCC_UNDER_TEST is set to something other than a plain
xgcc invocation (for example, when $CC requires a special -sysroot). Fix
testsuite files so that it uniformly uses CC_UNDER_TEST rather than any result
Fix contrib/testsuite-management/powerpc64-grtev3-linux-gnu.xfail
Add empty attributes to FAIL: gcc.dg/pr44194-1.c entry to eliminate
confusion with '|' appearing in the error message. Fix two other comment
lines.
Okay?
contrib/ChangeLog
2013-04-22 Simon Baldwin sim...@google.com
Suppose you had a month in which to reorganise gcc so that it builds
its 3-stage bootstrap and runtime libraries in some massively parallel
fashion, without hardware or resource constraints(*). How might you
approach this?
I'm looking for ideas on improving the build time of gcc itself. So
far
Ignore r194995 for gcc pr55852.
Okay for google/gcc-4_7 branch? Thanks.
Index: contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail
===
--- contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail (revision
195808)
+++
FYI.
$ svn merge -c 194864
svn+ssh://sim...@gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch
...test, passes dejagnu
$ svn commit gcc/testsuite/g++.dg/cpp0x/constexpr-ctor11.C
gcc/cp/ChangeLog gcc/cp/semantics.c
Sendinggcc/cp/ChangeLog
Sendinggcc/cp/semantics.c
Adding
Extend expiration date for pr54127 and Google ref b/6983319.
Okay for google/gcc-4_7 branch? Thanks.
ChangeLog.google-4_7
2012-11-27 Simon Baldwin sim...@google.com
* contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail:
Extend expiration date for pr54127 and Google
Permanently ignore pr54127 and Google ref b/6983319.
Okay for google/gcc-4_7 branch? Thanks.
ChangeLog.google-4_7
2012-11-27 Simon Baldwin sim...@google.com
* contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail:
Permanently ignore pr54127 and Google ref b/6983319
-Specific Options
Index: gcc/c-family/ChangeLog.google-integration
===
--- gcc/c-family/ChangeLog.google-integration (revision 0)
+++ gcc/c-family/ChangeLog.google-integration (revision 0)
@@ -0,0 +1,13 @@
+2012-11-16 Simon Baldwin sim
Ping, again
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
--
Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
Palace Road, London SW1W 9TQ | Registered in England Number: 3977902
Ping, again.
On 1 October 2012 16:56, Simon Baldwin sim...@google.com wrote:
Ping, again.
On 21 September 2012 12:45, Simon Baldwin sim...@google.com wrote:
Ping.
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
Full text of previous message and context at URL above
I'm seeing an element of instability in files written by f951.
About one time in some tens or even hundreds of builds done with a
tight loop, the file libgomp/omp_lib.mod has a different checksum from
others.
This is slightly problematic because it means that binary
distributions of gcc can't be
Ping, again.
On 21 September 2012 12:45, Simon Baldwin sim...@google.com wrote:
Ping.
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
Full text of previous message and context at URL above. No comments
or code changes since. Patch description left below for convenience.
Add
Ping.
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
Full text of previous message and context at URL above. No comments
or code changes since. Patch description left below for convenience.
Add flags to disable system header canonicalizations.
Libcpp may canonicalize system
with bootstrap builds of C and C++, both with and
without configure --disable-canonical-system-headers.
Okay for trunk?
libcpp/ChangeLog
2012-09-07 Simon Baldwin sim...@google.com
* include/cpplib.h (struct cpp_options): Add canonical_system_headers.
* files.c (find_file_in_dir): Call
with and
without configure --disable-canonical-system-headers.
Okay for trunk?
libcpp/ChangeLog.google-integration
2012-09-05 Simon Baldwin sim...@google.com
* files.c (maybe_shorter_path): Suppress function definition if
ENABLE_CANONICAL_SYSTEM_HEADERS is not defined
On 5 September 2012 16:03, Ian Lance Taylor i...@google.com wrote:
On Wed, Sep 5, 2012 at 6:56 AM, Simon Baldwin sim...@google.com wrote:
Add a configure option to disable system header canonicalizations.
Why should this be a configure option rather than a command-line option?
The underlying
frameworks that (for example) disallow absolute paths to header files.
Tested with bootstrap builds of C and C++, both with and without configure
--disable-canonical-system-headers. Okay for google/integration?
libcpp/ChangeLog.google-integration
2012-08-31 Simon Baldwin sim...@google.com
On 31 August 2012 16:31, Ollie Wild a...@google.com wrote:
On Fri, Aug 31, 2012 at 7:20 AM, Simon Baldwin sim...@google.com wrote:
Add a configure option to disable system header canonicalizations.
Libcpp may canonicalize system header paths with lrealpath() for
diagnostics,
dependency
On 31 August 2012 17:25, Ollie Wild a...@google.com wrote:
On Fri, Aug 31, 2012 at 10:01 AM, Simon Baldwin sim...@google.com wrote:
On 31 August 2012 16:31, Ollie Wild a...@google.com wrote:
The patch exactly meets the definition of google/integration only,
which is that it fixes up
On 21 August 2012 17:18, Joseph S. Myers jos...@codesourcery.com wrote:
On Tue, 21 Aug 2012, Simon Baldwin wrote:
Index: gcc/doc/options.texi
===
--- gcc/doc/options.texi (revision 190535)
+++ gcc/doc/options.texi
On 20 August 2012 16:45, Joseph S. Myers jos...@codesourcery.com wrote:
On Mon, 20 Aug 2012, Simon Baldwin wrote:
OPT_* for Fortran options only exist when the Fortran front-end is in the
source tree (whether or not enabled). I think we try to avoid knowingly
breaking use cases where
On 17 August 2012 16:55, Joseph S. Myers jos...@codesourcery.com wrote:
On Fri, 17 Aug 2012, Simon Baldwin wrote:
You could have just added
case OPT_cpp_:
to the switch in gen_producer_string, instead of all this.
Thanks. I was under the impression, apparently mistaken
On 16 August 2012 21:28, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Aug 16, 2012 at 06:59:09PM +0200, Simon Baldwin wrote:
On 16 August 2012 16:40, Michael Matz m...@suse.de wrote:
,,,
Do you have considered to use a new option flag (usable in the .opt files)
instead
On 16 August 2012 09:38, Gerald Pfeifer ger...@pfeifer.com wrote:
On Wed, 15 Aug 2012, Simon Baldwin wrote:
This creates a problem for build and packaging systems that are
fanatical about binary reproducibility and checksums. Temporary file
names differ on each compilation, so that two
The default setting of -grecord-gcc-switches recently changed from 0 to 1:
2012-04-25 Jakub Jelinek ja...@redhat.com
* common.opt (flag_debug_types_section): Default to 0.
...
(dwarf_record_gcc_switches): Default to 1.
Because of this, by default all objects in
Update contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail.
Tested with build followed by validate_failures.py. Okay for all applicable
branches?
2012-08-14 Simon Baldwin sim...@google.com
* testsuite-management/powerpc-grtev3-linux-gnu.xfail: Add new entries
for soft
.html
For google/main, google/gcc-4_7 and google/gcc-4_7-integration. Tested for
bootstrap and regression.
2012-08-08 Simon Baldwin sim...@google.com
* Makefile.tpl: Omit another TARGET_LIB_PATH from RPATH_ENVVAR set
on bootstrap builds.
* Makefile.in: Regenerate.
Index
Add powerpc-grtev3-linux-gnu.xfail to contrib/testsuite-management.
Tested with build followed by validate_failures.py.
2012-08-03 Simon Baldwin sim...@google.com
* testsuite-management/powerpc-grtev3-linux-gnu.xfail: New.
Index: contrib/testsuite-management/powerpc-grtev3-linux
Omit TARGET_LIB_PATH from RPATH_ENVVAR in HOST_EXPORTS on bootstrap builds.
Discussion and rationale at: http://gcc.gnu.org/ml/gcc/2012-06/msg00314.html
For google/main. Tested for bootstrap and regression.
2012-08-02 Simon Baldwin sim...@google.com
* Makefile.tpl: Omit
Workround for Google ref b/6663281
Appends -fno-section-anchors to -fprofile-{generate,use} -fripa, for powerpc
targets only. No-op for other targets.
For google/main. Tested for bootstrap and regression.
2012-08-01 Simon Baldwin sim...@google.com
* gcc/testsuite/gcc.dg/tree-prof
I've recently encountered a gcc testsuite issue that is caused by the
libgcc_s in the built compiler being incompatible with, but the same
architecture as, the host's libc. I'm not sure what the right fix is,
so I'm looking for ideas.
I build gcc-4.7 for x86 on an x86 host. The bootstrap
Port r184840 from gcc-4_6.
Forward-port r184840, contrib/testsuite-management/validate_failures.py fix
for cross-compilers, from gcc-4_6 to gcc-4_7.
Okay for google/integration and google/gcc-4_7-integration branches?
2012-05-28 Simon Baldwin sim...@google.com
Port r184840 from gcc
On 28 May 2012 18:40, Simon Baldwin sim...@google.com wrote:
Port r184840 from gcc-4_6.
Forward-port r184840, contrib/testsuite-management/validate_failures.py fix
for cross-compilers, from gcc-4_6 to gcc-4_7.
Okay for google/integration and google/gcc-4_7-integration branches?
That should
and google/gcc-4_7-integration branches?
Thanks.
2012-05-09 Simon Baldwin sim...@google.com
* libstdc++-v3/acinclude.m4: Bracket _GLIBCXX_USE_FLOAT128
definition with ifndef __clang__.
* libstdc++-v3/config.h.in: Rebuild.
Index: libstdc++-v3/config.h.in
/integration? Also, OK for trunk?
libstdc++-v3/ChangeLog:
2011-05-20 Simon Baldwin sim...@google.com
* scripts/extract_symvers.in: Handle processor/OS specific or
unknown symbol binding strings from readelf.
Index: gcc/gengtype-state.c
that prefer or insist on binary compatibility.
This patch removes the comment line, to provide binary reproducibility for
any generated gtype.state files.
Tested for x86 and PowerPC, no bootstrap in both cases.
OK for google/integration? Also, OK for trunk?
gcc/ChangeLog:
2011-08-23 Simon Baldwin sim
Ping.
On 20 May 2011 17:05, Simon Baldwin sim...@google.com wrote:
Make libstdc++'s abi_check more robust against readelf output format.
libstdc++-abi/abi_check in the libstdc++-v3 testsuite relies on a fixed
number of space separated fields in readelf output. However, the field
count
/ChangeLog.google-integration:
2011-05-27 Simon Baldwin sim...@google.com
* testsuite/gcc.dg/plugin/selfassign.c (check_self_assign): Renamed
from warn_self_assign.
(execute_warn_self_assign): Call a function by its new name.
* testsuite/g++.dg/plugin/selfassign.c
Add placeholder -Wself-assign flag for compatibility with other branches.
Add -Wself-assign to common.opts so that invocations of gcc with the flag
do not cause compilation to fail. The flag is silently ignored.
OK for google/integration?
gcc/ChangeLog.google-integration:
2011-05-24 Simon
correctly with $n.
OK for trunk?
libstdc++-v3/ChangeLog:
2011-05-20 Simon Baldwin sim...@google.com
* scripts/extract_symvers.in: Handle processor/OS specific or
unknown symbol binding strings from readelf.
Index: libstdc++-v3/scripts/extract_symvers.in
On 22 March 2011 14:56, David Edelsohn dje@gmail.com wrote:
On Tue, Mar 22, 2011 at 9:25 AM, Simon Baldwin sim...@google.com wrote:
I'm currently trying to backport a small part of gcc 4.5 r151729 to
gcc 4.4.3. This revision fixes a problem in powerpc code generation
that leads to gcc
I'm currently trying to backport a small part of gcc 4.5 r151729 to
gcc 4.4.3. This revision fixes a problem in powerpc code generation
that leads to gcc not using lmw/stmw instructions in function prologue
and epilogues, where it could otherwise validly use them.
On the face of things, the
On 31 January 2011 01:20, Gerald Pfeifer ger...@pfeifer.com wrote:
On Fri, 28 Jan 2011, Ian Lance Taylor wrote:
Some archealogy turned up this as the reason canonicalization was
inserted:
http://gcc.gnu.org/ml/gcc/2003-02/msg01121.html
http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01697.html
A quick question about -no-canonical-prefixes...
By default, gcc calls realpath() on prefixes generated relative to
argv[0] in the gcc driver. If gcc is held as a symlink farm the
realpath() makes it fail (absent a lot of messy -B, -L, -isytem and so
on). It complains about not finding cc1 or
48 matches
Mail list logo
