Re: [google/gcc-4_8] Fix libatomic testsuite for when GCC_UNDER_TEST is not plain xgcc

[Ollie Wild]

On Wed, May 1, 2013 at 9:04 AM, 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 invocation (for example, when $CC requires a special -sysroot).  Fix
 testsuite files so that it uniformly uses CC_UNDER_TEST rather than any result
 from libgloss find_gcc.

 Okay for google/gcc-4_8?  google/main?

Any reason to not also submit this to trunk?

Ollie

Fix incorrect libstdc++ @headername macro invocation.

[Ollie Wild]

This patch fixes an incorrect invocation of the @headername Doxygen
macro.  Namely, multiple values must be separated by commas, not or.
 The effect can be observed at
http://gcc.gnu.org/onlinedocs/gcc-4.7.2/libstdc++/api/a01484.html:

This is an internal header file, included by other library headers.
Do not attempt to use it directly. Instead, include map or=
set=.

Submitting as trivial, and will backport to google/gcc-4_7.

Google ref b/7621728.

Ollie


2012-11-27  Ollie Wild  a...@google.com

* include/bits/stl_tree.h (@headername): Fix incorrect Doxygen macro
invocation.
commit 952030841d65ce1d6153f5b682944b2215edc306
Author: Ollie Wild a...@google.com
Date:   Tue Nov 27 14:37:05 2012 -0600

Fix incorrect @headername Doxygen macro invocation.

Format is @headername{hdr1,hdr2} not @headername{hdr1 or hdr2}.

2012-11-27  Ollie Wild  a...@google.com

* include/bits/stl_tree.h (@headername): Fix incorrect Doxygen macro
invocation.

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index c6d0687..9d22b9d 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,8 @@
+2012-11-27  Ollie Wild  a...@google.com
+
+   * include/bits/stl_tree.h (@headername): Fix incorrect Doxygen macro
+   invocation.
+
 2012-11-26  Jonathan Wakely  jwakely@gmail.com
 
* include/std/functional (__is_socketlike): Change from class
diff --git a/libstdc++-v3/include/bits/stl_tree.h 
b/libstdc++-v3/include/bits/stl_tree.h
index 03a5e30..037aad3 100644
--- a/libstdc++-v3/include/bits/stl_tree.h
+++ b/libstdc++-v3/include/bits/stl_tree.h
@@ -54,7 +54,7 @@
 
 /** @file bits/stl_tree.h
  *  This is an internal header file, included by other library headers.
- *  Do not attempt to use it directly. @headername{map or set}
+ *  Do not attempt to use it directly. @headername{map,set}
  */
 
 #ifndef _STL_TREE_H

Re: [patch][google/gcc-4_7] Extend expiration date for pr54127 (issue6817091)

[Ollie Wild]

OK.

Ollie


On Mon, Nov 5, 2012 at 12:40 PM, Paul Pluzhnikov ppluzhni...@google.com wrote:
 Greetings,

 This patch is for google/gcc-4_7 branch.

 Thanks,


 2012-11-05  Paul Pluzhnikov  ppluzhni...@google.com

 * contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail:
 extend expiration date for pr54127.

 Index: contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail
 ===
 --- contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail (revision 
 193176)
 +++ contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail (working copy)
 @@ -1,9 +1,9 @@
  # Temporarily ignore gcc pr54127.
 -expire=20121031 | FAIL: gcc.dg/torture/pr53589.c -O3 -g  (test for excess 
 errors)
 -expire=20121031 | FAIL: gcc.dg/torture/pr53589.c  -O3 -g  (internal compiler 
 error)
 +expire=20121231 | FAIL: gcc.dg/torture/pr53589.c -O3 -g  (test for excess 
 errors)
 +expire=20121231 | FAIL: gcc.dg/torture/pr53589.c  -O3 -g  (internal compiler 
 error)
  # Temporarily ignore Google ref b/6983319.
 -expire=20121031 | FAIL: gcc.target/powerpc/regnames-1.c (test for excess 
 errors)
 -expire=20121031 | FAIL: gcc.target/powerpc/regnames-1.c (internal compiler 
 error)
 +expire=20121231 | FAIL: gcc.target/powerpc/regnames-1.c (test for excess 
 errors)
 +expire=20121231 | FAIL: gcc.target/powerpc/regnames-1.c (internal compiler 
 error)

  FAIL: gfortran.dg/bessel_6.f90  -O0  execution test
  FAIL: gfortran.dg/bessel_6.f90  -O1  execution test

 --
 This patch is available for review at http://codereview.appspot.com/6817091

Re: Second ping: Re: Add a configure option to disable system header canonicalizations (issue6495088)

[Ollie Wild]

Tom, this is mainly a libcpp change.  Would you mind taking a look?

Thanks,
Ollie

On Mon, Oct 1, 2012 at 9:56 AM, 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.  No comments
  or code changes since.  Patch description left below for convenience.
 
  
   Add flags to disable system header canonicalizations.
  
   Libcpp may canonicalize system header paths with lrealpath() for
   diagnostics,
   dependency output, and similar.  If gcc is held in a symlink farm the
   canonicalized paths may be meaningless to users, and will also
   conflict with
   build frameworks that (for example) disallow absolute paths to header
   files.
  
   This change adds -f[no-]canonical-system-headers to the gcc command
   line, and
   a configure option --[en/dis]able-canonical-system-headers to set
   default
   behaviour, allowing the user to select whether or not to implement
   r186991.
   Default is enabled.  See also PR c++/52974.
  
   Tested for regressions with bootstrap builds of C and C++, both with
   and
   without configure --disable-canonical-system-headers.
 
  --
  Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
  Palace Road, London SW1W 9TQ | Registered in England Number: 3977902




 --
 Google UK Limited | Registered Office: Belgrave House, 76 Buckingham
 Palace Road, London SW1W 9TQ | Registered in England Number: 3977902

[google/gcc-4_7] fix race in __cxa_guard_acquire

[Ollie Wild]

This is a merge of r191125 and r191191 from gcc-4_7-branch.  It fixes
a race in __cxa_guard_acquire which can cause duplicate initialization
of static variables within functions.

Okay for google/gcc-4_7?

Thanks,
Ollie


Google ref b/7173106.

* libsupc++/guard.cc (__cxa_guard_acquire): Exit the loop earlier if
we detect that another thread has had success. Don't compare_exchange
from a finished state back to a waiting state.  Fix up the last
argument of the first __atomic_compare_exchange_n.  Comment.
commit 40ec687ace62b4d4c64f72be2bdf4321f5213107
Author: Ollie Wild a...@google.com
Date:   Wed Sep 19 14:52:53 2012 -0500

Merge r191125 and r191191 from gcc-4_7-branch.

Google ref b/7173106.

* libsupc++/guard.cc (__cxa_guard_acquire): Exit the loop earlier if
we detect that another thread has had success. Don't compare_exchange
from a finished state back to a waiting state.  Fix up the last
argument of the first __atomic_compare_exchange_n.  Comment.

diff --git a/libstdc++-v3/libsupc++/guard.cc b/libstdc++-v3/libsupc++/guard.cc
index adc9608..f8550c0 100644
--- a/libstdc++-v3/libsupc++/guard.cc
+++ b/libstdc++-v3/libsupc++/guard.cc
@@ -244,16 +244,16 @@ namespace __cxxabiv1
 if (__gthread_active_p ())
   {
int *gi = (int *) (void *) g;
-   int expected(0);
const int guard_bit = _GLIBCXX_GUARD_BIT;
const int pending_bit = _GLIBCXX_GUARD_PENDING_BIT;
const int waiting_bit = _GLIBCXX_GUARD_WAITING_BIT;
 
while (1)
  {
+   int expected(0);
if (__atomic_compare_exchange_n(gi, expected, pending_bit, false,
__ATOMIC_ACQ_REL,
-   __ATOMIC_RELAXED))
+   __ATOMIC_ACQUIRE))
  {
// This thread should do the initialization.
return 1;
@@ -264,13 +264,26 @@ namespace __cxxabiv1
// Already initialized.
return 0;   
  }
+
 if (expected == pending_bit)
   {
+// Use acquire here.
 int newv = expected | waiting_bit;
 if (!__atomic_compare_exchange_n(gi, expected, newv, false,
  __ATOMIC_ACQ_REL, 
- __ATOMIC_RELAXED))
-  continue;
+ __ATOMIC_ACQUIRE))
+  {
+if (expected == guard_bit)
+  {
+// Make a thread that failed to set the
+// waiting bit exit the function earlier,
+// if it detects that another thread has
+// successfully finished initialising.
+return 0;
+  }
+if (expected == 0)
+  continue;
+  }
 
 expected = newv;
   }

[google] remove versioned symbols from libstdc++.a

[Ollie Wild]

This is a Google-local fix to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54482.

When configured with --with-pic, libstdc++.a includes versioned
symbols, preventing it from being linked into shared libraries.  The
ultimate cause of this is a misuse of -DPIC as a proxy for, I'm being
compiled into a shared library.  Unfortunately, there is no obvious
alternative without first patching libtool.

This patch provides a temporary workaround for the google/* branches.
It creates new libtool options, -Xcompiler-static and
-Xcompiler-shared, which pass flags only when compiling static or
shared libraries, respectively.  I then use the new machinery to pass
-UPIC to the static library compilations.  This has the effect of
tricking libstdc++ into behaving properly.

Ideally, a new macro should be used, since there are legitimate cases
when PIC could be useful (e.g. in selecting between alternate assembly
implementations).  However, the current approach is less likely to
break under future merge activity, since any new compatibility changes
should just work.

Long term, the correct solution is to: (a) convert this to a suitable
libtool patch and push that upstream, (b) update GCC's libtool
version, and (c) rework the libstdc++ source files to key off a more
appropriate macro (e.g. SHARED_LIB).  That's going to take some time,
though, especially since upgrading libtool is a major (and rare)
event.

Okay for google/integration and google/gcc-4_7?

Thanks,
Ollie


2012-09-05  Ollie Wild  a...@google.com

* ltmain.sh (func_mode_compile): Add -Xcompiler-shared and
-Xcompiler-static options.
(func_mode_help): Document new options.
* libstdc++/src/Makefile.am (LTCXXCOMPILE): Pass -UPIC when compiling
static libraries.
* libstdc++/src/Makefile.in: Regenerate.
commit 7208cb10bcf3f1bfab77aa6756fc0b2672bd39fa
Author: Ollie Wild a...@google.com
Date:   Tue Sep 4 14:35:19 2012 -0500

Add new libtool options -Xcompiler-shared and -Xcompiler-static.

Use this to remove versioned symbols from libstdc++.a when configured with
--with-pic.

Google ref b/704

2012-09-05  Ollie Wild  a...@google.com

* ltmain.sh (func_mode_compile): Add -Xcompiler-shared and
-Xcompiler-static options.
(func_mode_help): Document new options.
* libstdc++/src/Makefile.am (LTCXXCOMPILE): Pass -UPIC when compiling
static libraries.
* libstdc++/src/Makefile.in: Regenerate.

diff --git a/libstdc++-v3/src/Makefile.am b/libstdc++-v3/src/Makefile.am
index a1eb04d..d166155 100644
--- a/libstdc++-v3/src/Makefile.am
+++ b/libstdc++-v3/src/Makefile.am
@@ -147,7 +147,8 @@ LTCXXCOMPILE = \
$(LIBTOOL) --tag CXX \
$(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=compile $(CXX) $(INCLUDES) \
-   $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)
+   $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) \
+   -Xcompiler-static -UPIC
 
 LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
 
diff --git a/libstdc++-v3/src/Makefile.in b/libstdc++-v3/src/Makefile.in
index b10d853..e0578a2 100644
--- a/libstdc++-v3/src/Makefile.in
+++ b/libstdc++-v3/src/Makefile.in
@@ -406,7 +406,8 @@ LTCXXCOMPILE = \
$(LIBTOOL) --tag CXX \
$(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=compile $(CXX) $(INCLUDES) \
-   $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS)
+   $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) \
+   -Xcompiler-static -UPIC
 
 LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
 
diff --git a/ltmain.sh b/ltmain.sh
index 6428631..3aac68f 100644
--- a/ltmain.sh
+++ b/ltmain.sh
@@ -1280,6 +1280,8 @@ func_mode_compile ()
 $opt_debug
 # Get the compilation command and the source file.
 base_compile=
+shared_compile=
+static_compile=
 srcfile=$nonopt  #  always keep a non-empty value in srcfile
 suppress_opt=yes
 suppress_output=
@@ -1303,6 +1305,20 @@ func_mode_compile ()
continue
;;
 
+  xcompiler-shared )
+arg_mode=normal
+   func_quote_for_eval $arg
+   shared_compile=$shared_compile $func_quote_for_eval_result
+   continue
+   ;;
+
+  xcompiler-static )
+arg_mode=normal
+   func_quote_for_eval $arg
+   static_compile=$static_compile $func_quote_for_eval_result
+   continue
+   ;;
+
   normal )
# Accept any command-line options.
case $arg in
@@ -1333,6 +1349,18 @@ func_mode_compile ()
  continue  #  The current srcfile will either be retained or
  ;;#  replaced later.  I would guess that would be a bug.
 
+   -Xcompiler-shared)
+ arg_mode=xcompiler-shared  #  the next one goes into the
+#  shared_compile arg list
+ continue
+ ;;
+
+   -Xcompiler-static)
+ arg_mode=xcompiler-static  #  the next

Re: [google/integration] Add a configure option to disable system header canonicalizations (issue6489063)

[Ollie Wild]

On Fri, Aug 31, 2012 at 10:30 AM, Simon Baldwin sim...@google.com wrote:

 Yes.  I meant --disable-canonical-prefixes.  That is a gcc configure
 flag that we use to control the default setting for
 -[no-]canonical-prefixes where neither flag is supplied on the gcc
 command line.  --disable/enable-canonical-prefixes is only in google
 branches.

I did a little archaeology.  AFAICT, there was no specific objection
to pushing --disable-canonical-prefixes into upstream trunk.  The
feedback I see to your initial post was send us a trunk-based patch
and here are some minor nits to cleanup.  It basically sounds like
upstream was neutral to the patch and would probably accept it if we
actually sent something for review.

I still think this is something that is both reasonable and feasible
to push upstream.  We should at least try to get some feedback first.
While there aren't a lot of people using symlink farms, I'd be
surprised if we were the only ones.

Ollie

Re: [google/integration] Add a configure option to disable system header canonicalizations (issue6489063)

[Ollie Wild]

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 output, and similar.  If gcc is held in a symlink farm the
 canonicalized paths may be meaningless to users, and will also conflict with
 build 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?

Seems like a reasonable candidate for trunk, and I'd rather have fewer
patches in google/integration than more.  Can you send a copy of this
patch for inclusion there?  Let's at least see what people say.

Ollie

Re: [google/integration] Add a configure option to disable system header canonicalizations (issue6489063)

[Ollie Wild]

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 something that affects only Google's use of
 gcc.

The criterion is more subtle than that.  The google/integration branch
is for things which: (a) cannot be submitted to trunk, and (b) are
required for inter-operability with our build/test systems.  The goal
is to keep any changes relative to trunk as minimal as possible, and
frankly, much of the stuff that's there now should be cleaned up and
submitted upstream.

  --no-canonical-prefixes is similar.  That too is only in our
 branches and not in trunk, for the same reason.

But -no-canonical-prefixes *is* in trunk.  Presumably the same people
who benefit from that will also benefit from this.  In fact, I think a
reasonable case could be made that header canonicalization should be
gated on the same flag.


 I'd rather keep this out of trunk unless there are known external use
 cases where it's beneficial.  That keeps both the review and the
 testing load to acceptable -- though still extremely high -- levels.

The same argument could be made about *any* patch we submit.  Pushing
upstream is always more work, but if we don't do it, we end up paying
for it later.

Ollie

Re: C++ PR 54197: lifetime of reference not properly extended

[Ollie Wild]

On Fri, Aug 31, 2012 at 10:37 AM, Jason Merrill ja...@redhat.com wrote:
 OK, sorry for the delay.

No worries.  Thanks.

Submitted to trunk and gcc-4_7-branch as r190834 and r190839.

Ollie

Re: C++ PR 54197: lifetime of reference not properly extended

[Ollie Wild]

On Mon, Aug 20, 2012 at 9:58 AM, Ollie Wild a...@google.com wrote:

 Jason, any idea when you can look at this?

 The patch is about as short as they come, so it shouldn't take long to
 review.

Ping?

Re: C++ PR 54197: lifetime of reference not properly extended

[Ollie Wild]

On Thu, Aug 16, 2012 at 2:13 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:

 On Wed, Aug 15, 2012 at 9:52 AM, Ollie Wild a...@google.com wrote:
  (Adding other C++ maintainers in case someone else wants to have a
  stab.)
 
  Ping?

 I consider Jason to be the expert on this; so let see what he says.

 -- Gaby

Jason, any idea when you can look at this?

The patch is about as short as they come, so it shouldn't take long to review.

Thanks,
Ollie

Re: C++ PR 54197: lifetime of reference not properly extended

[Ollie Wild]

On Thu, Aug 16, 2012 at 12:12 PM, Diego Novillo dnovi...@google.com wrote:

 I wonder if it wouldn't make more sense to iterate until we find the
 rightmost element in a compound_expr chain, but I don't think they are
 neither common nor long enough to matter.

Yeah, that was my thinking.  I can certainly do whatever the maintainers want.

 It looks like a good fix, but I would rather have a C++ maintainer
 give final approval for gcc-4_7-branch and trunk.  In the meantime,
 should we install it in google/gcc-4_7?  I can deal with any merge
 conflicts, in case the patch needs more work for the upstream
 branches.

I'll go ahead and submit to google/gcc-4_7, then.

Thanks,
Ollie

Re: C++ PR 54197: lifetime of reference not properly extended

[Ollie Wild]

(Adding other C++ maintainers in case someone else wants to have a stab.)

Ping?

Ollie


On Mon, Aug 13, 2012 at 4:01 PM, Ollie Wild a...@google.com wrote:

 On Mon, Aug 13, 2012 at 3:50 PM, Jakub Jelinek ja...@redhat.com wrote:
 
  The formatting doesn't match GCC coding conventions in several ways.
  You don't have spaces before (, and ( shouldn't be at the end of line if
  possible.

 Updated patch attached.

 Ollie

Re: C++ PR 54197: lifetime of reference not properly extended

[Ollie Wild]

On Mon, Aug 13, 2012 at 3:50 PM, Jakub Jelinek ja...@redhat.com wrote:

 The formatting doesn't match GCC coding conventions in several ways.
 You don't have spaces before (, and ( shouldn't be at the end of line if
 possible.

Updated patch attached.

Ollie
commit d023097c555a6f7cb84685fd7befedb550889d2c
Author: Ollie Wild a...@google.com
Date:   Mon Aug 13 15:36:24 2012 -0500

2012-08-13  Ollie Wild  a...@google.com

PR c++/54197
* gcc/cp/call.c (extend_ref_init_temps_1): Handle COMPOUND_EXPR trees.
* gcc/testsuite/g++.dg/init/lifetime3.C: New test.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 5345f2b..f3a73af 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8924,6 +8924,12 @@ extend_ref_init_temps_1 (tree decl, tree init, 
VEC(tree,gc) **cleanups)
   tree sub = init;
   tree *p;
   STRIP_NOPS (sub);
+  if (TREE_CODE (sub) == COMPOUND_EXPR)
+{
+  TREE_OPERAND (sub, 1)
+= extend_ref_init_temps_1 (decl, TREE_OPERAND (sub, 1), cleanups);
+  return init;
+}
   if (TREE_CODE (sub) != ADDR_EXPR)
 return init;
   /* Deal with binding to a subobject.  */
diff --git a/gcc/testsuite/g++.dg/init/lifetime3.C 
b/gcc/testsuite/g++.dg/init/lifetime3.C
new file mode 100644
index 000..d099699
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/lifetime3.C
@@ -0,0 +1,37 @@
+// PR c++/26714
+// { dg-do run }
+
+extern C void abort();
+
+bool ok = false;
+struct A {
+  A() { }
+  ~A() { if (!ok) abort(); }
+};
+
+struct B {
+  static A foo() { return A(); }
+};
+
+B b_g;
+
+struct scoped_ptr {
+  B* operator-() const { return b_g; }
+  B* get() const { return b_g; }
+};
+
+B *get() { return b_g; }
+
+int main()
+{
+  scoped_ptr f;
+  const A ref1 = f-foo();
+  const A ref2 = f.get()-foo();
+  const A ref3 = get()-foo();
+  const A ref4 = B::foo();
+  B *pf = f.get();
+  const A ref5 = pf-foo();
+
+
+  ok = true;
+}

[google/gcc-4_7] XFAIL libitm failures

[Ollie Wild]

As discussed, this patch XFAILs the libitm failures uncovered by
http://gcc.gnu.org/viewcvs?view=revisionrevision=190233.

OK for google/gcc-4_7?

Ollie

2012-08-09  Ollie Wild  a...@google.com

* testsuite-management/x86_64-grtev3-linux-gnu.xfail: XFAIL libitm
failuires.
commit 8d78568138de78f11935f92b3143149733ea0172
Author: Ollie Wild a...@google.com
Date:   Thu Aug 9 14:38:51 2012 -0500

2012-08-09  Ollie Wild  a...@google.com

* testsuite-management/x86_64-grtev3-linux-gnu.xfail: XFAIL libitm
failuires.

diff --git a/contrib/ChangeLog.google-4_7 b/contrib/ChangeLog.google-4_7
index c1664f9..fbfc0f5 100644
--- a/contrib/ChangeLog.google-4_7
+++ b/contrib/ChangeLog.google-4_7
@@ -1,3 +1,8 @@
+2012-08-09  Ollie Wild  a...@google.com
+
+   * testsuite-management/x86_64-grtev3-linux-gnu.xfail: XFAIL libitm
+   failuires.
+
 2012-08-08  Ollie Wild  a...@google.com
 
* testsuite-management/powerpc-grtev3-linux-gnu.xfail: xfail
diff --git a/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail 
b/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
index 4fa47ec..d68b543 100644
--- a/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
+++ b/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
@@ -68,3 +68,34 @@ flaky | FAIL: libgomp.graphite/force-parallel-6.c execution 
test
 # that is resolved.
 UNRESOLVED: 23_containers/map/element_access/2.cc compilation failed to 
produce executable
 FAIL: 23_containers/map/element_access/2.cc (test for excess errors)
+
+# libitm failures caused by missing --sysroot.
+UNRESOLVED: libitm.c++/dropref.C compilation failed to produce executable
+FAIL: libitm.c++/dropref.C (test for excess errors)
+UNRESOLVED: libitm.c++/eh-1.C compilation failed to produce executable
+FAIL: libitm.c++/eh-1.C (test for excess errors)
+FAIL: libitm.c++/throwdown.C (test for excess errors)
+FAIL: libitm.c/cancel.c (test for excess errors)
+UNRESOLVED: libitm.c/cancel.c compilation failed to produce executable
+FAIL: libitm.c/clone-1.c (test for excess errors)
+UNRESOLVED: libitm.c/clone-1.c compilation failed to produce executable
+FAIL: libitm.c/dropref-2.c (test for excess errors)
+UNRESOLVED: libitm.c/dropref-2.c compilation failed to produce executable
+UNRESOLVED: libitm.c/dropref.c compilation failed to produce executable
+FAIL: libitm.c/dropref.c (test for excess errors)
+FAIL: libitm.c/memcpy-1.c (test for excess errors)
+UNRESOLVED: libitm.c/memcpy-1.c compilation failed to produce executable
+FAIL: libitm.c/memset-1.c (test for excess errors)
+UNRESOLVED: libitm.c/memset-1.c compilation failed to produce executable
+UNRESOLVED: libitm.c/notx.c compilation failed to produce executable
+FAIL: libitm.c/notx.c (test for excess errors)
+UNRESOLVED: libitm.c/reentrant.c compilation failed to produce executable
+FAIL: libitm.c/reentrant.c (test for excess errors)
+FAIL: libitm.c/simple-1.c (test for excess errors)
+UNRESOLVED: libitm.c/simple-1.c compilation failed to produce executable
+UNRESOLVED: libitm.c/simple-2.c compilation failed to produce executable
+FAIL: libitm.c/simple-2.c (test for excess errors)
+FAIL: libitm.c/stackundo.c (test for excess errors)
+UNRESOLVED: libitm.c/stackundo.c compilation failed to produce executable
+UNRESOLVED: libitm.c/txrelease.c compilation failed to produce executable
+FAIL: libitm.c/txrelease.c (test for excess errors)

[google/gcc-4_7] XFAIL map element_access test

[Ollie Wild]

As previously discussed, this patch XFAIL's the new libstdc++ failure
caused by http://gcc.gnu.org/viewcvs?revision=190129view=revision.
It will be reverted once the issues discussed at
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00141.html have been
resolved.

Okay to submit to google/gcc-4_7?

Ollie


2012-08-08  Ollie Wild  a...@google.com

   * testsuite-management/powerpc-grtev3-linux-gnu.xfail: xfail
   23_containers/map/element_access/2.cc from libstdc++.
   * testsuite-management/x86_64-grtev3-linux-gnu.xfail: Ditto.
commit 0e6b70f28b33c1c017afb7374fc724cd61b62745
Author: Ollie Wild a...@google.com
Date:   Wed Aug 8 16:48:19 2012 -0500

XFail 23_containers/map/element_access/2.cc compilation from libstedc++.

To be reverted once issues at
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00141.html are resolved.

diff --git a/contrib/ChangeLog.google-4_7 b/contrib/ChangeLog.google-4_7
index 4217fc8..c1664f9 100644
--- a/contrib/ChangeLog.google-4_7
+++ b/contrib/ChangeLog.google-4_7
@@ -1,3 +1,9 @@
+2012-08-08  Ollie Wild  a...@google.com
+
+   * testsuite-management/powerpc-grtev3-linux-gnu.xfail: xfail
+   23_containers/map/element_access/2.cc from libstdc++.
+   * testsuite-management/x86_64-grtev3-linux-gnu.xfail: Ditto.
+
 2012-08-06  Simon Baldwin  sim...@google.com
 
 Cherry pick r190180 from google/main.
diff --git a/contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail 
b/contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail
index 14cd6c5..45752f8 100644
--- a/contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail
+++ b/contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail
@@ -170,3 +170,8 @@ FAIL: gcc.target/powerpc/pr46728-3.c scan-assembler-not pow
 FAIL: gcc.target/powerpc/pr46728-4.c scan-assembler-not pow
 FAIL: gcc.target/powerpc/pr46728-7.c scan-assembler-not pow
 FAIL: gcc.target/powerpc/pr46728-8.c scan-assembler-not pow
+
+# See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00141.html.  Revert once
+# that is resolved.
+UNRESOLVED: 23_containers/map/element_access/2.cc compilation failed to 
produce executable
+FAIL: 23_containers/map/element_access/2.cc (test for excess errors)
diff --git a/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail 
b/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
index 38ab201..4fa47ec 100644
--- a/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
+++ b/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
@@ -63,3 +63,8 @@ flaky | FAIL: libmudflap.cth/pass40-frag.c output pattern test
 flaky | FAIL: libmudflap.cth/pass40-frag.c (-O2) execution test
 flaky | FAIL: libmudflap.cth/pass39-frag.c (-O3) (rerun 10) execution test
 flaky | FAIL: libgomp.graphite/force-parallel-6.c execution test
+
+# See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00141.html.  Revert once
+# that is resolved.
+UNRESOLVED: 23_containers/map/element_access/2.cc compilation failed to 
produce executable
+FAIL: 23_containers/map/element_access/2.cc (test for excess errors)

Re: Value type of map need not be default copyable

[Ollie Wild]

On Sat, Aug 4, 2012 at 10:34 AM, Paolo Carlini paolo.carl...@oracle.com wrote:


 First, I think we should add libstdc++ in CC.

 Thus, I would recommend people working in this area to begin with
 unordered_map, because in that case emplace is already available, assuming
 that's really the point (and therefore reverting the patch was a good idea,
 luckily an existing testcase helped us)

 At the same time an implementation of emplace is definitely welcome, in
 any case.

I've attached a patch for unordered_map which solves the rvalue
reference problem.  For efficiency, I've created a new
_M_emplace_bucket method rather than call emplace directly.

I've verified all libstdc++ tests pass (sorry for the previous
oversight) and am running the full GCC test suite now.  However, I'd
appreciate any feedback on whether this is a reasonable approach.  STL
hacking is way outside my comfort zone.  ;-)

If this looks good, I'll take a stab at std::map.

Thanks,
Ollie


2012-08-03  Ollie Wild  a...@google.com

* include/bits/hashtable.h (_M_emplace_bucket): New function.
* include/bits/hashtable_policy.h (operator[](key_type)): Replace
_M_insert_bucket call with _M_emplace_bucket.
* testsuite/23_containers/unordered_map/operators/2.cc: New test.
commit dd690a5f164326c552c2450af6270ec27e9bfd8e
Author: Ollie Wild a...@google.com
Date:   Tue Aug 7 16:34:05 2012 -0500

2012-08-03  Ollie Wild  a...@google.com

* include/bits/hashtable.h (_M_emplace_bucket): New function.
* include/bits/hashtable_policy.h (operator[](key_type)): Replace
_M_insert_bucket call with _M_emplace_bucket.
* testsuite/23_containers/unordered_map/operators/2.cc: New test.

 2012-08-04  Paolo Carlini  paolo.carl...@oracle.com
 
Revert:
diff --git a/libstdc++-v3/include/bits/hashtable.h 
b/libstdc++-v3/include/bits/hashtable.h
index 2faf0b3..869b0e9 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -588,6 +588,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
iterator
_M_insert_bucket(_Arg, size_type, __hash_code);
 
+  templatetypename... _Args
+   iterator
+   _M_emplace_bucket(size_type, __hash_code, _Args... __args);
+
 
   templatetypename... _Args
std::pairiterator, bool
@@ -1356,6 +1360,51 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  }
   }
 
+  // Insert v in bucket n (assumes no element with its key already present).
+  templatetypename _Key, typename _Value,
+  typename _Alloc, typename _ExtractKey, typename _Equal,
+  typename _H1, typename _H2, typename _Hash, typename _RehashPolicy,
+  typename _Traits
+templatetypename... _Args
+  typename _Hashtable_Key, _Value, _Alloc, _ExtractKey, _Equal,
+ _H1, _H2, _Hash, _RehashPolicy,
+ _Traits::iterator
+  _Hashtable_Key, _Value, _Alloc, _ExtractKey, _Equal,
+_H1, _H2, _Hash, _RehashPolicy, _Traits::
+  _M_emplace_bucket(size_type __n, __hash_code __code, _Args... __args)
+  {
+   // First build the node to get access to the hash code
+   __node_type* __node = _M_allocate_node(std::forward_Args(__args)...);
+   __try
+ {
+
+   const __rehash_state __saved_state = _M_rehash_policy._M_state();
+   std::pairbool, std::size_t __do_rehash
+ = _M_rehash_policy._M_need_rehash(_M_bucket_count,
+   _M_element_count, 1);
+
+   if (__do_rehash.first)
+ {
+   const key_type __k = this-_M_extract()(__node-_M_v);
+   __n = __hash_code_base::_M_bucket_index(__k, __code,
+   __do_rehash.second);
+ }
+
+   this-_M_store_code(__node, __code);
+   if (__do_rehash.first)
+ _M_rehash(__do_rehash.second, __saved_state);
+
+   _M_insert_bucket_begin(__n, __node);
+   ++_M_element_count;
+   return iterator(__node);
+ }
+   __catch(...)
+ {
+   _M_deallocate_node(__node);
+   __throw_exception_again;
+ }
+  }
+
   // Insert v if no element with its key is already present.
   templatetypename _Key, typename _Value,
   typename _Alloc, typename _ExtractKey, typename _Equal,
diff --git a/libstdc++-v3/include/bits/hashtable_policy.h 
b/libstdc++-v3/include/bits/hashtable_policy.h
index 27790f2..addf9d13 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -598,9 +598,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __node_type* __p = __h-_M_find_node(__n, __k, __code);
 
   if (!__p)
-   return __h-_M_insert_bucket(std::make_pair(std::move(__k),
-   mapped_type()),
-__n, __code)-second;
+   return __h

Re: [google/main] Add powerpc-grtev3-linux-gnu.xfail to contrib/testsuite-management (issue6447087)

[Ollie Wild]

OK.  Don't forget to add xfail files for google/trunk and google/gcc-4_7, too.

Ollie


On Fri, Aug 3, 2012 at 9:14 AM, Simon Baldwin sim...@google.com wrote:

 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-gnu.xfail
 ===
 --- contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail (revision
 0)
 +++ contrib/testsuite-management/powerpc-grtev3-linux-gnu.xfail (revision
 0)
 @@ -0,0 +1,172 @@
 +# Temporarily ignore gcc pr54127.
 +expire=20121031 | FAIL: gcc.dg/torture/pr53589.c -O3 -g  (test for excess
 errors)
 +expire=20121031 | FAIL: gcc.dg/torture/pr53589.c  -O3 -g  (internal
 compiler error)
 +
 +FAIL: gfortran.dg/bessel_6.f90  -O0  execution test
 +FAIL: gfortran.dg/bessel_6.f90  -O1  execution test
 +FAIL: gfortran.dg/bessel_6.f90  -O2  execution test
 +FAIL: gfortran.dg/bessel_6.f90  -O3 -fomit-frame-pointer  execution test
 +FAIL: gfortran.dg/bessel_6.f90  -O3 -fomit-frame-pointer -funroll-loops
 execution test
 +FAIL: gfortran.dg/bessel_6.f90  -O3 -fomit-frame-pointer
 -funroll-all-loops -finline-functions  execution test
 +FAIL: gfortran.dg/bessel_6.f90  -O3 -g  execution test
 +FAIL: gfortran.dg/bessel_6.f90  -Os  execution test
 +XPASS: gfortran.dg/nint_2.f90  -O0  execution test
 +FAIL: gfortran.dg/unf_io_convert_3.f90  -O0  execution test
 +FAIL: gfortran.dg/unf_io_convert_3.f90  -O1  execution test
 +FAIL: gfortran.dg/unf_io_convert_3.f90  -O2  execution test
 +FAIL: gfortran.dg/unf_io_convert_3.f90  -O3 -fomit-frame-pointer
 execution test
 +FAIL: gfortran.dg/unf_io_convert_3.f90  -O3 -fomit-frame-pointer
 -funroll-loops  execution test
 +FAIL: gfortran.dg/unf_io_convert_3.f90  -O3 -fomit-frame-pointer
 -funroll-all-loops -finline-functions  execution test
 +FAIL: gfortran.dg/unf_io_convert_3.f90  -O3 -g  execution test
 +FAIL: gfortran.dg/unf_io_convert_3.f90  -Os  execution test
 +FAIL: gfortran.dg/x_slash_2.f  -O0  execution test
 +FAIL: g++.dg/abi/forced.C -std=gnu++98 execution test
 +FAIL: g++.dg/abi/forced.C -std=gnu++11 execution test
 +FAIL: g++.dg/ext/cleanup-10.C -std=gnu++98 execution test
 +FAIL: g++.dg/ext/cleanup-10.C -std=gnu++11 execution test
 +FAIL: g++.dg/ext/cleanup-11.C -std=gnu++98 execution test
 +FAIL: g++.dg/ext/cleanup-11.C -std=gnu++11 execution test
 +FAIL: g++.dg/ext/cleanup-8.C -std=gnu++98 execution test
 +FAIL: g++.dg/ext/cleanup-8.C -std=gnu++11 execution test
 +FAIL: g++.dg/ext/cleanup-9.C -std=gnu++98 execution test
 +FAIL: g++.dg/ext/cleanup-9.C -std=gnu++11 execution test
 +FAIL: g++.dg/warn/Wself-assign-2.C -std=gnu++11  (test for warnings, line
 12)
 +FAIL: g++.dg/tree-prof/lipo/vcall1_0.C scan-ipa-dump-times profile
 Indirect call - direct call 2
 +FAIL: g++.dg/tree-prof/lipo/vcall1_0.C scan-ipa-dump-times profile
 Indirect call - direct call 2
 +FAIL: g++.dg/tree-prof/lipo/vcall1_0.C scan-ipa-dump-times profile
 Indirect call - direct call 2
 +FAIL: g++.dg/tree-prof/lipo/vcall1_0.C scan-ipa-dump-times profile
 Indirect call - direct call 2
 +FAIL: g++.dg/tree-prof/lipo/vcall1_0.C scan-ipa-dump-times profile
 Indirect call - direct call 2
 +FAIL: g++.dg/tree-prof/lipo/vcall1_0.C scan-ipa-dump-times profile
 Indirect call - direct call 2
 +FAIL: g++.dg/tree-prof/lipo/vcall1_0.C scan-ipa-dump-times profile
 Indirect call - direct call 2
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file Callgraph
 group : main _Z3barv _Z3foov\n
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file
 .text.*.main\n.text.*._Z3barv\n.text.*._Z3foov\n.text.*._Z9notcalledv
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file Callgraph
 group : main _Z3barv _Z3foov\n
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file
 .text.*.main\n.text.*._Z3barv\n.text.*._Z3foov\n.text.*._Z9notcalledv
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file Callgraph
 group : main _Z3barv _Z3foov\n
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file
 .text.*.main\n.text.*._Z3barv\n.text.*._Z3foov\n.text.*._Z9notcalledv
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file Callgraph
 group : main _Z3barv _Z3foov\n
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file
 .text.*.main\n.text.*._Z3barv\n.text.*._Z3foov\n.text.*._Z9notcalledv
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file Callgraph
 group : main _Z3barv _Z3foov\n
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file
 .text.*.main\n.text.*._Z3barv\n.text.*._Z3foov\n.text.*._Z9notcalledv
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file Callgraph
 group : main _Z3barv _Z3foov\n
 +UNRESOLVED: g++.dg/tree-prof/callgraph-profiles.C scan-file
 .text.*.main\n.text.*._Z3barv\n.text.*._Z3foov\n.text.*._Z9notcalledv
 

Re: Value type of map need not be default copyable

[Ollie Wild]

On Fri, Aug 3, 2012 at 2:39 AM, Paolo Carlini paolo.carl...@oracle.com wrote:

 Ok, but, can you also double check and in case fix unordered_map too?
 Looks like we have the same issue, right?

Indeed, we do.  I'll send a separate patch for the unordered_map problem.


 Thanks!
 Paolo.

 PS: remember that all the library patches go to libstdc++@ too, and
 preferably please add something to the Subject about the library (like [v3]
 ... )

Thanks for the reminder.

Ollie

Value type of map need not be default copyable

[Ollie Wild]

Patch courtesy Richard Smith at Google:

Fix bug in the implementation of std::map's operator[]. Construct an
object of type value_type, rather than using std::make_pair, so as to
allow mapped_type to have an *explicit* copy constructor.

See [map.access] (23.4.4.3)/5 for the corresponding standardese.

Tested via bootstrap + test.

Okay for trunk?

Thanks,
Ollie


2012-08-02  Ollie Wild  a...@google.com
Richard Smith  richardsm...@google.com

* include/bits/stl_map.h (operator[](key_type)): Replace
std::make_pair with value_type.
* testsuite/23_containers/map/operators/2.cc: New test.
diff --git a/libstdc++-v3/include/bits/stl_map.h 
b/libstdc++-v3/include/bits/stl_map.h
index cfd478a..a3abdd4 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -475,7 +475,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
iterator __i = lower_bound(__k);
// __i-first is greater than or equivalent to __k.
if (__i == end() || key_comp()(__k, (*__i).first))
-  __i = insert(__i, std::make_pair(std::move(__k), mapped_type()));
+  __i = insert(__i, value_type(std::move(__k), mapped_type()));
return (*__i).second;
   }
 #endif
diff --git a/libstdc++-v3/testsuite/23_containers/map/operators/2.cc 
b/libstdc++-v3/testsuite/23_containers/map/operators/2.cc
new file mode 100644
index 000..ce633d7
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/map/operators/2.cc
@@ -0,0 +1,38 @@
+// Copyright (C) 2012
+// Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library 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 3, or (at your option)
+// any later version.
+
+// This library 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 this library; see the file COPYING3.  If not see
+// http://www.gnu.org/licenses/.
+
+// 23.4.4 template class map
+
+// This test verifies that the value type of a map need not be default
+// copyable.
+
+// { dg-do compile }
+// { dg-options -std=gnu++11 }
+
+#include map
+
+struct Mapped {
+Mapped();
+explicit Mapped(const Mapped);
+};
+
+Mapped  foo()
+{
+  std::mapint, Mapped m;
+  return m[0];
+}

[google/gcc-4_7] Allow static const floats unless -pedantic is passed (issue6212051)

[Ollie Wild]

To be applied to google/gcc-4_7.

Allow static const floats unless -pedantic is passed.

This patch allows us to migrate to C++11 more incrementally, since we can leave
the static const float initializations in place, flip the switch, and then
change it to use constexpr.

This is a forward port of r180638 from google/gcc-4_6 (despite the fact that
that revision says to NOT forward-port this).  Minor additional fixups have
been applied.

2012-05-15   Ollie Wild  a...@google.com

* gcc/cp/decl.c (check_static_variable_definition): Only generate a
constexpr warning when -pedantic is enabled.
* gcc/testsuite/g++.dg/cpp0x/constexpr-static8.C: Replace -fpermissive
with -pedantic.
* gcc/testsuite/g++.dg/cpp0x/constexpr-static8_nonpedantic.C: New test.
* gcc/testsuite/g++.old-deja/g++.ext/memconst.C: Compile with -pedantic
-pedantic-errors to work around test failures with -std=gnu++11.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index bb26d15..d2fe731 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -7861,9 +7861,18 @@ check_static_variable_definition (tree decl, tree type)
error (in-class initialization of static data member %q#D of 
   incomplete type, decl);
   else if (literal_type_p (type))
-   permerror (input_location,
-  %constexpr% needed for in-class initialization of 
-  static data member %q#D of non-integral type, decl);
+   {
+  /* FIXME google: This local modification allows us to
+ transition from C++98 to C++11 without moving static
+ const floats out of the class during the transition.  It
+ should not be forward-ported to a 4.8 branch, since by
+ then we should be able to just fix the code to use
+ constexpr.  */
+  pedwarn (input_location, OPT_pedantic,
+   %constexpr% needed for in-class initialization of 
+   static data member %q#D of non-integral type, decl);
+  return 0;
+   }
   else
error (in-class initialization of static data member %q#D of 
   non-literal type, decl);
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-static8.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-static8.C
index 7c84cf8..658a458 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-static8.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-static8.C
@@ -1,5 +1,5 @@
 // PR c++/50258
-// { dg-options -std=c++0x -fpermissive }
+// { dg-options -std=c++0x -pedantic }
 
 struct Foo {
   static const double d = 3.14; // { dg-warning constexpr }
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-static8_nonpedantic.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-static8_nonpedantic.C
new file mode 100644
index 000..28d34a1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-static8_nonpedantic.C
@@ -0,0 +1,7 @@
+// PR c++/50258
+// { dg-options -std=c++0x }
+
+struct Foo {
+  static const double d = 3.14; // no warning
+};
+const double Foo::d;
diff --git a/gcc/testsuite/g++.old-deja/g++.ext/memconst.C 
b/gcc/testsuite/g++.old-deja/g++.ext/memconst.C
index d934763..7e86156 100644
--- a/gcc/testsuite/g++.old-deja/g++.ext/memconst.C
+++ b/gcc/testsuite/g++.old-deja/g++.ext/memconst.C
@@ -1,5 +1,5 @@
 // { dg-do assemble  }
-// { dg-options  }
+// { dg-options -pedantic -pedantic-errors }
 // From: ove.ewer...@syscon.uu.se (Ove Ewerlid)
 // Subject: ss-940630:cc1plus: internal error
 // Date: Sat, 2 Jul 1994 05:07:20 +0200

--
This patch is available for review at http://codereview.appspot.com/6212051

Re: [google] Hide all uses of __float128 from Clang (issue6195066)

[Ollie Wild]

On Wed, May 9, 2012 at 8:19 AM, Simon Baldwin sim...@google.com wrote:

 Hide all uses of __float128 from Clang.

 Brackets _GLIBCXX_USE_FLOAT128 with #ifndef __clang__.  Clang does not
 currently support the __float128 builtin, and so will fail to process
 libstdc++ headers that use it.

 Tested for full bootstrap and dejagnu testsuite.

 Okay for google/integration and google/gcc-4_7-integration branches?

Please check this into google/gcc-4_7 as well.

Ollie

Re: PR c++/52538 Extend C++11 UDLs to be compatible with inttypes.h macros (issue6109043)

[Ollie Wild]

On Thu, Apr 26, 2012 at 8:35 AM, Tom Tromey tro...@redhat.com wrote:

 This is ok with this change.

Thanks.  Updated and submitted to trunk.

Ollie

Re: PR c++/52538 Extend C++11 UDLs to be compatible with inttypes.h macros (issue6109043)

[Ollie Wild]

On Mon, Apr 23, 2012 at 8:28 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:

 Thanks.  Tom, I am satisfied with the diagnostic part.
 I think the CPP part makes sense but it is your call.

Hi, Tom, just a quick checkin to see if you've had a chance to review this, yet.

Thanks,
Ollie

Re: PR c++/52538 Extend C++11 UDLs to be compatible with inttypes.h macros (issue6109043)

[Ollie Wild]

On Mon, Apr 23, 2012 at 7:10 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
 On Sun, Apr 22, 2012 at 10:59 PM, Ollie Wild a...@google.com wrote:
 Add new option, -Wreserved-user-defined-literal.

 Just shorten it to -Wliteral-suffix.

I chose -Wreserved-user-defined-literal because that's the name used
by Clang.  It seemed better to maintain consistency between front ends
than to invent a new, concise option name.

Do you still want me to shorten in?

 the non-CPP part is OK with the above change.
 You would need Tom's approval for the CPP part.

Thanks.  Added Tom to the address list.

Ollie

Re: PR c++/52538 Extend C++11 UDLs to be compatible with inttypes.h macros (issue6109043)

[Ollie Wild]

On Mon, Apr 23, 2012 at 7:53 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
 On Mon, Apr 23, 2012 at 7:30 AM, Ollie Wild a...@google.com wrote:

 Do you still want me to shorten in?

 yes.

Done.  Updated patch attached.

Ollie
commit 3f53671fb7fc7811277f047e7914f78e127031a6
Author: Ollie Wild a...@google.com
Date:   Sun Apr 22 21:37:08 2012 -0500

Add new option, -Wreserved-user-defined-literal.

This option, which is enabled by default, causes the preprocessor to warn
when a string or character literal is followed by a ud-suffix which does
not begin with an underscore.  According to [lex.ext]p10, this is
ill-formed.

Also modifies the preprocessor to treat such ill-formed suffixes as separate
preprocessing tokens.  This is consistent with the Clang front end (see
http://llvm.org/viewvc/llvm-project?view=revrevision=152287), and enables
backwards compatibility with code that uses formatting macros from
inttypes.h, as in the following code block:

  int main() {
int64_t i64 = 123;
printf(My int64: %PRId64\n, i64);
  }

Google ref b/6377711.

2012-04-22   Ollie Wild  a...@google.com

* gcc/c-family/c-common.c: Add CPP_W_LITERAL_SUFFIX mapping.
* gcc/c-family/c-opts.c (c_common_handle_option): Handle
OPT_Wliteral_suffix.
* gcc/c-family/c.opt: Add Wliteral-suffix.
* gcc/doc/invoke.texi (Wliteral-suffix): Document new option.
* gcc/testsuite/g++.dg/cpp0x/Wliteral-suffix.c: New test.
* libcpp/include/cpplib.h (struct cpp_options): Add new field,
warn_literal_suffix.
(CPP_W_LITERAL_SUFFIX): New enum.
* libcpp/init.c (cpp_create_reader): Default initialization of
warn_literal_suffix.
* libcpp/lex.c (lex_raw_string): Treat user-defined literals which
don't begin with '_' as separate tokens and produce a warning.
(lex_string): Ditto.

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 4eacd19..bf5b034 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -8820,6 +8820,7 @@ static const struct reason_option_codes_t option_codes[] 
= {
   {CPP_W_NORMALIZE,OPT_Wnormalized_},
   {CPP_W_INVALID_PCH,  OPT_Winvalid_pch},
   {CPP_W_WARNING_DIRECTIVE,OPT_Wcpp},
+  {CPP_W_LITERAL_SUFFIX,   OPT_Wliteral_suffix},
   {CPP_W_NONE, 0}
 };
 
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 17e1958..2510747 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -476,6 +476,10 @@ c_common_handle_option (size_t scode, const char *arg, int 
value,
   cpp_opts-warn_invalid_pch = value;
   break;
 
+case OPT_Wliteral_suffix:
+  cpp_opts-warn_literal_suffix = value;
+  break;
+
 case OPT_Wlong_long:
   cpp_opts-cpp_warn_long_long = value;
   break;
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index d8c944d..db8ca81 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -449,6 +449,10 @@ Wjump-misses-init
 C ObjC Var(warn_jump_misses_init) Init(-1) Warning
 Warn when a jump misses a variable initialization
 
+Wliteral-suffix
+C++ ObjC++ Warning
+Warn when a string or character literal is followed by a ud-suffix which does 
not begin with an underscore.
+
 Wlogical-op
 C ObjC C++ ObjC++ Var(warn_logical_op) Init(0) Warning 
 Warn when a logical operator is suspiciously always evaluating to true or false
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8ca2f4e..3c9588a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -198,8 +198,8 @@ in the following sections.
 -fno-default-inline  -fvisibility-inlines-hidden @gol
 -fvisibility-ms-compat @gol
 -Wabi  -Wconversion-null  -Wctor-dtor-privacy @gol
--Wdelete-non-virtual-dtor -Wnarrowing -Wnoexcept @gol
--Wnon-virtual-dtor  -Wreorder @gol
+-Wdelete-non-virtual-dtor -Wliteral-suffix -Wnarrowing @gol
+-Wnoexcept -Wnon-virtual-dtor  -Wreorder @gol
 -Weffc++  -Wstrict-null-sentinel @gol
 -Wno-non-template-friend  -Wold-style-cast @gol
 -Woverloaded-virtual  -Wno-pmf-conversions @gol
@@ -2425,6 +2425,30 @@ an instance of a derived class through a pointer to a 
base class if the
 base class does not have a virtual destructor.  This warning is enabled
 by @option{-Wall}.
 
+@item -Wliteral-suffix @r{(C++ and Objective-C++ only)}
+@opindex Wliteral-suffix
+@opindex Wno-literal-suffix
+Warn when a string or character literal is followed by a ud-suffix which does
+not begin with an underscore.  As a conforming extension, GCC treats such
+suffixes as separate preprocessing tokens in order to maintain backwards
+compatibility with code that uses formatting macros from @code{inttypes.h}.
+For example:
+
+@smallexample
+#define __STDC_FORMAT_MACROS
+#include inttypes.h
+#include stdio.h
+
+int main() @{
+  int64_t i64 = 123;
+  printf(My int64: %PRId64\n, i64);
+@}
+@end smallexample

Re: [google/integration] Extend C++11 UDLs to be compatible with inttypes.h macros (issue6104051)

[Ollie Wild]

On Mon, Apr 23, 2012 at 2:39 PM, Diego Novillo dnovi...@google.com wrote:

 This would be for google/main, right?  It does not seem fit for
 google/integration.

It needs to be in google/integration because it blocks nearly all of
our code from compiling with -std=gnu++11, and there's no way to turn
this behavior off.  Without it, we can't do any google/integration
testing.

That said, I also sent out a patch for trunk (see my other gcc-patches
thread), and there have been some changes as a result of that.  I'm
currently waiting on a response from Tom Tromey regarding the libcpp
changes.

Ollie

Re: [google/integration] Extend C++11 UDLs to be compatible with inttypes.h macros (issue6104051)

[Ollie Wild]

On Mon, Apr 23, 2012 at 3:51 PM, Diego Novillo dnovi...@google.com wrote:

 Great, thanks.  Patch is OK with the ChangeLog entries filled-in.  Not sure 
 if you'd rather wait for the trunk commit to go in, though.  It may be better 
 to put this version in google/integration and deal with the merge later.

Thanks, Diego.

If the trunk change isn't approved today, I'll probably go ahead and
check in *that* patch to google/integration.  The main difference
relative to this is that the option name has been changed to
-Wliteral-suffix.  *That* part has been approved, so hopefully any
additional adjustments will be minor.

Ollie

[google/integration] Extend C++11 UDLs to be compatible with inttypes.h macros (issue6104051)

[Ollie Wild]

Add new option, -Wreserved-user-defined-literal.

This option, which is enabled by default, causes the preprocessor to warn
when a string or character literal is followed by a ud-suffix which does
not begin with an underscore.  According to [lex.ext]p10, this is
ill-formed.

Also modifies the preprocessor to treat such ill-formed suffixes as separate
preprocessing tokens.  This is consistent with the Clang front end (see
http://llvm.org/viewvc/llvm-project?view=revrevision=152287), and enables
backwards compatibility with code that uses formatting macros from
inttypes.h, as in the following code block:

  int main() {
int64_t i64 = 123;
printf(My int64: %PRId64\n, i64);
  }

Google ref b/6377711.

2012-04-22   Ollie Wild  a...@google.com

* gcc/c-family/c-common.c:
* gcc/c-family/c-opts.c (c_common_handle_option):
* gcc/c-family/c.opt:
* gcc/doc/invoke.texi (struct A):
* gcc/testsuite/g++.dg/cpp0x/Wreserved-user-defined-literal.C (test):
(main):
* libcpp/include/cpplib.h (struct cpp_options):
* libcpp/init.c (cpp_create_reader):
* libcpp/lex.c (lex_raw_string):
(lex_string):

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 1d19251..915dc25 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -8724,6 +8724,7 @@ static const struct reason_option_codes_t option_codes[] 
= {
   {CPP_W_NORMALIZE,OPT_Wnormalized_},
   {CPP_W_INVALID_PCH,  OPT_Winvalid_pch},
   {CPP_W_WARNING_DIRECTIVE,OPT_Wcpp},
+  {CPP_W_RESERVED_USER_LITERALS,   OPT_Wreserved_user_defined_literal},
   {CPP_W_NONE, 0}
 };
 
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 5118928..dab6ce5 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -509,6 +509,10 @@ c_common_handle_option (size_t scode, const char *arg, int 
value,
  break;
}
 
+case OPT_Wreserved_user_defined_literal:
+  cpp_opts-warn_reserved_user_literals = value;
+  break;
+
 case OPT_Wreturn_type:
   warn_return_type = value;
   break;
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 40ff96c..f610513 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -589,6 +589,10 @@ Wreorder
 C++ ObjC++ Var(warn_reorder) Warning
 Warn when the compiler reorders code
 
+Wreserved-user-defined-literal
+C++ ObjC++ Warning
+Warn when a string or character literal is followed by a ud-suffix which does 
not begin with an underscore.
+
 Wreturn-type
 C ObjC C++ ObjC++ Var(warn_return_type) Warning
 Warn whenever a function's return type defaults to \int\ (C), or about 
inconsistent return types (C++)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1b61e76..d425079 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -198,7 +198,7 @@ in the following sections.
 -fvisibility-ms-compat @gol
 -Wabi  -Wconversion-null  -Wctor-dtor-privacy @gol
 -Wdelete-non-virtual-dtor -Wnarrowing -Wnoexcept @gol
--Wnon-virtual-dtor  -Wreorder @gol
+-Wnon-virtual-dtor  -Wreorder -Wreserved-user-defined-literal @gol
 -Weffc++  -Wstrict-null-sentinel @gol
 -Wno-non-template-friend  -Wold-style-cast @gol
 -Woverloaded-virtual  -Wno-pmf-conversions @gol
@@ -2474,6 +2474,30 @@ struct A @{
 The compiler will rearrange the member initializers for @samp{i}
 and @samp{j} to match the declaration order of the members, emitting
 a warning to that effect.  This warning is enabled by @option{-Wall}.
+
+@item -Wreserved-user-defined-literal @r{(C++ and Objective-C++ only)}
+@opindex Wreserved-user-defined-literal
+@opindex Wno-reserved-user-defined-literal
+Warn when a string or character literal is followed by a ud-suffix which does
+not begin with an underscore.  As a conforming extension, GCC treats such
+suffixes as separate preprocessing tokens in order to maintain backwards
+compatibility with code that uses formatting macros from @code{inttypes.h}.
+For example:
+
+@smallexample
+#define __STDC_FORMAT_MACROS
+#include inttypes.h
+#include stdio.h
+
+int main() @{
+  int64_t i64 = 123;
+  printf(My int64: %PRId64\n, i64);
+@}
+@end smallexample
+
+In this case, @code{PRId64} is treated as a separate preprocessing token.
+
+This warning is enabled by default.
 @end table
 
 The following @option{-W@dots{}} options are not affected by @option{-Wall}.
diff --git a/gcc/testsuite/g++.dg/cpp0x/Wreserved-user-defined-literal.C 
b/gcc/testsuite/g++.dg/cpp0x/Wreserved-user-defined-literal.C
new file mode 100644
index 000..66de5c0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/Wreserved-user-defined-literal.C
@@ -0,0 +1,29 @@
+// { dg-do run }
+// { dg-options -std=c++0x }
+
+// Make sure -Wreserved-user-defined-literal is enabled by default and
+// triggers as expected.
+
+#define BAR bar
+#define PLUS_ONE + 1
+
+#include cstdint
+#include cassert
+
+
+void
+test()
+{
+  char c = '3'PLUS_ONE;  // { dg-warning invalid

Re: [google/integration] Extend C++11 UDLs to be compatible with inttypes.h macros (issue6104051)

[Ollie Wild]

Okay, I'll send out a trunk patch for review now, too.

Ollie

On Sun, Apr 22, 2012 at 10:29 PM, Jeffrey Yasskin jyass...@google.com wrote:

 Let's let the discussion _start_ before assuming it'll be protracted.
 ;) I don't think it'll kill us to run the next round of testing in
 C++98 mode. If the patch doesn't look close to acceptance in a couple
 days, I think it'll make sense to put the then-current version into
 the google branches while people are agreeing about what to do in the
 long run.

 On Sun, Apr 22, 2012 at 8:14 PM, Ollie Wild a...@google.com wrote:
  I'd like to get this into the google branches first because this is
  blocking
  testing.
 
  I fully expect this to result in some protracted discussion before it
  can be
  accepted into trunk.
 
  Ollie
 
 
  On Sun, Apr 22, 2012 at 10:10 PM, Jeffrey Yasskin jyass...@google.com
  wrote:
 
  Could you try to get this into mainline instead of just the google
  branches? In http://gcc.gnu.org/PR52538, Jonathan sounded like he'd
  consider accepting it.
 
  On Sun, Apr 22, 2012 at 7:54 PM, Ollie Wild a...@google.com wrote:
   Add new option, -Wreserved-user-defined-literal.
  
   This option, which is enabled by default, causes the preprocessor to
   warn
   when a string or character literal is followed by a ud-suffix which
   does
   not begin with an underscore.  According to [lex.ext]p10, this is
   ill-formed.
  
   Also modifies the preprocessor to treat such ill-formed suffixes as
   separate
   preprocessing tokens.  This is consistent with the Clang front end
   (see
   http://llvm.org/viewvc/llvm-project?view=revrevision=152287), and
   enables
   backwards compatibility with code that uses formatting macros from
   inttypes.h, as in the following code block:
  
    int main() {
      int64_t i64 = 123;
      printf(My int64: %PRId64\n, i64);
    }
  
   Google ref b/6377711.
  
   2012-04-22   Ollie Wild  a...@google.com
  
          * gcc/c-family/c-common.c:
          * gcc/c-family/c-opts.c (c_common_handle_option):
          * gcc/c-family/c.opt:
          * gcc/doc/invoke.texi (struct A):
          * gcc/testsuite/g++.dg/cpp0x/Wreserved-user-defined-literal.C
   (test):
          (main):
          * libcpp/include/cpplib.h (struct cpp_options):
          * libcpp/init.c (cpp_create_reader):
          * libcpp/lex.c (lex_raw_string):
          (lex_string):
  
   diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
   index 1d19251..915dc25 100644
   --- a/gcc/c-family/c-common.c
   +++ b/gcc/c-family/c-common.c
   @@ -8724,6 +8724,7 @@ static const struct reason_option_codes_t
   option_codes[] = {
     {CPP_W_NORMALIZE,                    OPT_Wnormalized_},
     {CPP_W_INVALID_PCH,                  OPT_Winvalid_pch},
     {CPP_W_WARNING_DIRECTIVE,            OPT_Wcpp},
   +  {CPP_W_RESERVED_USER_LITERALS,
   OPT_Wreserved_user_defined_literal},
     {CPP_W_NONE,                         0}
    };
  
   diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
   index 5118928..dab6ce5 100644
   --- a/gcc/c-family/c-opts.c
   +++ b/gcc/c-family/c-opts.c
   @@ -509,6 +509,10 @@ c_common_handle_option (size_t scode, const char
   *arg, int value,
            break;
          }
  
   +    case OPT_Wreserved_user_defined_literal:
   +      cpp_opts-warn_reserved_user_literals = value;
   +      break;
   +
       case OPT_Wreturn_type:
         warn_return_type = value;
         break;
   diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
   index 40ff96c..f610513 100644
   --- a/gcc/c-family/c.opt
   +++ b/gcc/c-family/c.opt
   @@ -589,6 +589,10 @@ Wreorder
    C++ ObjC++ Var(warn_reorder) Warning
    Warn when the compiler reorders code
  
   +Wreserved-user-defined-literal
   +C++ ObjC++ Warning
   +Warn when a string or character literal is followed by a ud-suffix
   which does not begin with an underscore.
   +
    Wreturn-type
    C ObjC C++ ObjC++ Var(warn_return_type) Warning
    Warn whenever a function's return type defaults to \int\ (C), or
   about inconsistent return types (C++)
   diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
   index 1b61e76..d425079 100644
   --- a/gcc/doc/invoke.texi
   +++ b/gcc/doc/invoke.texi
   @@ -198,7 +198,7 @@ in the following sections.
    -fvisibility-ms-compat @gol
    -Wabi  -Wconversion-null  -Wctor-dtor-privacy @gol
    -Wdelete-non-virtual-dtor -Wnarrowing -Wnoexcept @gol
   --Wnon-virtual-dtor  -Wreorder @gol
   +-Wnon-virtual-dtor  -Wreorder -Wreserved-user-defined-literal @gol
    -Weffc++  -Wstrict-null-sentinel @gol
    -Wno-non-template-friend  -Wold-style-cast @gol
    -Woverloaded-virtual  -Wno-pmf-conversions @gol
   @@ -2474,6 +2474,30 @@ struct A @{
    The compiler will rearrange the member initializers for @samp{i}
    and @samp{j} to match the declaration order of the members, emitting
    a warning to that effect.  This warning is enabled by
   @option{-Wall}.
   +
   +@item -Wreserved-user-defined-literal @r{(C++ and Objective-C++
   only

PR c++/52538 Extend C++11 UDLs to be compatible with inttypes.h macros (issue6109043)

[Ollie Wild]

Add new option, -Wreserved-user-defined-literal.

This option, which is enabled by default, causes the preprocessor to warn
when a string or character literal is followed by a ud-suffix which does
not begin with an underscore.  According to [lex.ext]p10, this is
ill-formed.

Also modifies the preprocessor to treat such ill-formed suffixes as separate
preprocessing tokens.  This is consistent with the Clang front end (see
http://llvm.org/viewvc/llvm-project?view=revrevision=152287), and enables
backwards compatibility with code that uses formatting macros from
inttypes.h, as in the following code block:

  int main() {
int64_t i64 = 123;
printf(My int64: %PRId64\n, i64);
  }

Tested via bootstrap + test.

Okay for trunk?

Thanks,
Ollie


2012-04-22   Ollie Wild  a...@google.com

* gcc/c-family/c-common.c:
* gcc/c-family/c-opts.c (c_common_handle_option):
* gcc/c-family/c.opt:
* gcc/doc/invoke.texi (struct A):
* gcc/testsuite/g++.dg/cpp0x/Wreserved-user-defined-literal.C (test):
(main):
* libcpp/include/cpplib.h (struct cpp_options):
* libcpp/init.c (cpp_create_reader):
* libcpp/lex.c (lex_raw_string):
(lex_string):

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 4eacd19..f79020c 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -8820,6 +8820,7 @@ static const struct reason_option_codes_t option_codes[] 
= {
   {CPP_W_NORMALIZE,OPT_Wnormalized_},
   {CPP_W_INVALID_PCH,  OPT_Winvalid_pch},
   {CPP_W_WARNING_DIRECTIVE,OPT_Wcpp},
+  {CPP_W_RESERVED_USER_LITERALS,   OPT_Wreserved_user_defined_literal},
   {CPP_W_NONE, 0}
 };
 
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 17e1958..a812762 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -510,6 +510,10 @@ c_common_handle_option (size_t scode, const char *arg, int 
value,
  break;
}
 
+case OPT_Wreserved_user_defined_literal:
+  cpp_opts-warn_reserved_user_literals = value;
+  break;
+
 case OPT_Wreturn_type:
   warn_return_type = value;
   break;
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index d8c944d..c8a0c84 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -593,6 +593,10 @@ Wreorder
 C++ ObjC++ Var(warn_reorder) Warning
 Warn when the compiler reorders code
 
+Wreserved-user-defined-literal
+C++ ObjC++ Warning
+Warn when a string or character literal is followed by a ud-suffix which does 
not begin with an underscore.
+
 Wreturn-type
 C ObjC C++ ObjC++ Var(warn_return_type) Warning
 Warn whenever a function's return type defaults to \int\ (C), or about 
inconsistent return types (C++)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8ca2f4e..ddf0fc6 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -199,7 +199,7 @@ in the following sections.
 -fvisibility-ms-compat @gol
 -Wabi  -Wconversion-null  -Wctor-dtor-privacy @gol
 -Wdelete-non-virtual-dtor -Wnarrowing -Wnoexcept @gol
--Wnon-virtual-dtor  -Wreorder @gol
+-Wnon-virtual-dtor  -Wreorder -Wreserved-user-defined-literal @gol
 -Weffc++  -Wstrict-null-sentinel @gol
 -Wno-non-template-friend  -Wold-style-cast @gol
 -Woverloaded-virtual  -Wno-pmf-conversions @gol
@@ -2478,6 +2478,30 @@ struct A @{
 The compiler rearranges the member initializers for @samp{i}
 and @samp{j} to match the declaration order of the members, emitting
 a warning to that effect.  This warning is enabled by @option{-Wall}.
+
+@item -Wreserved-user-defined-literal @r{(C++ and Objective-C++ only)}
+@opindex Wreserved-user-defined-literal
+@opindex Wno-reserved-user-defined-literal
+Warn when a string or character literal is followed by a ud-suffix which does
+not begin with an underscore.  As a conforming extension, GCC treats such
+suffixes as separate preprocessing tokens in order to maintain backwards
+compatibility with code that uses formatting macros from @code{inttypes.h}.
+For example:
+
+@smallexample
+#define __STDC_FORMAT_MACROS
+#include inttypes.h
+#include stdio.h
+
+int main() @{
+  int64_t i64 = 123;
+  printf(My int64: %PRId64\n, i64);
+@}
+@end smallexample
+
+In this case, @code{PRId64} is treated as a separate preprocessing token.
+
+This warning is enabled by default.
 @end table
 
 The following @option{-W@dots{}} options are not affected by @option{-Wall}.
diff --git a/gcc/testsuite/g++.dg/cpp0x/Wreserved-user-defined-literal.C 
b/gcc/testsuite/g++.dg/cpp0x/Wreserved-user-defined-literal.C
new file mode 100644
index 000..66de5c0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/Wreserved-user-defined-literal.C
@@ -0,0 +1,29 @@
+// { dg-do run }
+// { dg-options -std=c++0x }
+
+// Make sure -Wreserved-user-defined-literal is enabled by default and
+// triggers as expected.
+
+#define BAR bar
+#define PLUS_ONE + 1
+
+#include cstdint
+#include cassert
+
+
+void
+test()
+{
+  char c = '3'PLUS_ONE

[google/integration] Add -Xclang-only option (issue6047048)

[Ollie Wild]

To be submitted to the google/integration branch and merged into
google/{main,gcc-4_6,gcc-4_7}.

Add -Xclang-only option (which is ignored).

This is used by certain drivers to pass options selectively to clang.  Adding
support to the gcc driver makes it easier to test GCC in the absence of these
drivers.

Google ref 6302116.

2012-04-17   Ollie Wild  a...@google.com

* gcc/common.opt (Xclang-only): New option.
* gcc/doc/invoke.texi (Xclang-only): Document new option.
* gcc/gcc.c (display_help): Print new option.
(driver_handle_option): Support new option (ignoring args).


diff --git a/gcc/common.opt b/gcc/common.opt
index 4a751a9..39f0843 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -743,6 +743,9 @@ Warn when a vector operation is compiled outside the SIMD
 Xassembler
 Driver Separate
 
+Xclang-only
+Driver Joined
+
 Xlinker
 Driver Separate
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d980e9f..1b61e76 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9560,6 +9560,11 @@ systems using the GNU linker.  On some targets, such as 
bare-board
 targets without an operating system, the @option{-T} option may be required
 when linking to avoid references to undefined symbols.
 
+@item -Xclang-only @var{option}
+@opindex Xclang-only
+Ignore @var{option}.  This is used by some custom drivers to pass options
+to Clang but not GCC.
+
 @item -Xlinker @var{option}
 @opindex Xlinker
 Pass @var{option} as an option to the linker.  You can use this to
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 5f789fd..c6b48a6 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -2983,6 +2983,7 @@ display_help (void)
   fputs (_(  -Xassembler argPass arg on to the assembler\n), 
stdout);
   fputs (_(  -Xpreprocessor arg Pass arg on to the preprocessor\n), 
stdout);
   fputs (_(  -Xlinker arg   Pass arg on to the linker\n), 
stdout);
+  fputs (_(  -Xclang-only=arg   Ignore arg\n), stdout);
   fputs (_(  -save-temps  Do not delete intermediate files\n), 
stdout);
   fputs (_(  -save-temps=argDo not delete intermediate files\n), 
stdout);
   fputs (_(\
@@ -3353,6 +3354,11 @@ driver_handle_option (struct gcc_options *opts,
   do_save = false;
   break;
 
+case OPT_Xclang_only:
+  /* Ignore the argument.  Used by some drivers to selectively pass
+ arguments to clang.  */
+  break;
+
 case OPT_Xlinker:
   add_infile (arg, *);
   do_save = false;

--
This patch is available for review at http://codereview.appspot.com/6047048

Re: [google] Use delete with size parameter in STL deallocate (issue5794070)

[Ollie Wild]

On Mon, Mar 12, 2012 at 8:03 PM, Easwaran Raman era...@google.com wrote:

 OK for google/main and google/4_6 branches?

You will need to check this into google/gcc-4_7 as well.

Ollie

Re: Why are libgcc.a and libgcc_eh.a compiled with -fvisibility=hidden?

[Ollie Wild]

On Thu, Mar 8, 2012 at 7:23 AM, H.J. Lu hjl.to...@gmail.com wrote:

 If I understand it correctly, the reason Google doesn't want libgcc_s.so
 is Google believes GPLv3 exception only applies to libgcc,a and libgcc_eh,a,
 not libgcc_s.so.  If GPLv3 exception also applies to libgcc_s.so, Google
 may consider using libgcc_s.so.

It's an internal process thing.

We're not worried about licensing in this context.

Ollie

Re: Why are libgcc.a and libgcc_eh.a compiled with -fvisibility=hidden?

[Ollie Wild]

On Thu, Mar 8, 2012 at 12:38 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Wed, Mar 07, 2012 at 06:24:14PM -0800, Ollie Wild wrote:

 The reason why libgcc.a symbols are hidden is to avoid exporting those
 symbols from shared libraries for -static-libgcc etc. links.
 It used to cause big troubles, the symbols were e.g. exported from one
 shared library as implementation detail, and other shared libraries that
 needed the same symbols relied on those symbols exported from them, but
 if you slightly change the implementation of the shared library, the libgcc
 symbol might not be needed any longer, thus no longer exported, and suddenly
 the other shared libraries break, because they can't find their definitions.
 libgcc routines are usually short (dfp is an exception, but those really
 don't belong into libgcc), so duplicating them doesn't matter much
 and there is always -shared-libgcc.

Ah, that makes sense.  Thanks, Jakub.

Ollie

[google/integration] disable symbol hiding in libgcc for grtev3 targets (issue5792054)

[Ollie Wild]

To be submitted to google/integration and merged to google/{main,gcc-4_7}.
Would also like to have this considered for trunk, since this patch has no
impact on non-grtev3 targets.

Disable hiding of symbols in static libgcc libraries when built for GRTE v3.
This allows pthread_cancel to perform stack unwinding when libgcc_eh.a is
linked into dynamic executables.  However, this opens up a hole wherein shared
libraries linked with -static-libgcc cannot be individually modified without
risk of breaking dependent libraries.  That's okay in the GRTE v3 environment
because libgcc is compiled without -fPIC anyway.

See http://gcc.gnu.org/ml/gcc/2012-03/msg00104.html for details.

Google ref 5836136.

2012-03-08   Ollie Wild  a...@google.com

* libgcc/Makefile.in (vis_hide): Move default initialization before
inclusion of $(tmake_file).
* libgcc/config.host (*-grtev3-*): Disable hiding of symbols in static
libraries.
* libgcc/config/t-static-no-vis-hide: New file.

diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 23b72b9..41fbb96 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -334,6 +334,12 @@ LIBUNWIND =
 SHLIBUNWIND_LINK =
 SHLIBUNWIND_INSTALL =
 
+# For -fvisibility=hidden.  We need both a -fvisibility=hidden on
+# the command line, and a #define to prevent libgcc2.h etc from
+# overriding that with #pragmas.  This is set before including $(tmake_file)
+# so it can be overridden on a host-specific basis.
+vis_hide = @vis_hide@
+
 tmake_file = @tmake_file@
 include $(srcdir)/empty.mk $(tmake_file)
 
@@ -363,11 +369,6 @@ ifeq ($(enable_shared),yes)
 install-libunwind = install-libunwind
   endif
 
-# For -fvisibility=hidden.  We need both a -fvisibility=hidden on
-# the command line, and a #define to prevent libgcc2.h etc from
-# overriding that with #pragmas.
-vis_hide = @vis_hide@
-
 ifneq (,$(vis_hide))
 
 # If we have -fvisibility=hidden, then we need to generate hide
diff --git a/libgcc/config.host b/libgcc/config.host
index 257622a..242fbd5 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1174,3 +1174,10 @@ i[34567]86-*-linux* | x86_64-*-linux*)
tm_file=${tm_file} i386/value-unwind.h
;;
 esac
+
+case ${host} in
+*-grtev3-*)
+   # Don't hide symbols in static libraries.
+   tmake_file=${tmake_file} t-static-no-vis-hide
+   ;;
+esac
diff --git a/libgcc/config/t-static-no-vis-hide 
b/libgcc/config/t-static-no-vis-hide
new file mode 100644
index 000..955ff35
--- /dev/null
+++ b/libgcc/config/t-static-no-vis-hide
@@ -0,0 +1,2 @@
+# Don't hide symbols in static libraries.
+vis_hide =

--
This patch is available for review at http://codereview.appspot.com/5792054

Why are libgcc.a and libgcc_eh.a compiled with -fvisibility=hidden?

[Ollie Wild]

For reasons outside the scope of this discussion, we're experimenting
with statically linking libgcc.a and libgcc_eh.a into dynamically
linked applications which depend on libc but no other dynamic
libraries.  To make this work, libc needs to access a few functions
for stack unwinding inside pthread_cancel.  With suitable
modifications, everything works, except for one problem: libgcc_eh.a
is compiled with -fvisibility=hidden.

Now, I can put together a hack in our local source tree to remove this
... but why is this the case at all?  It might make sense for
libgcc_s.so, but that's compiled with default visibility (and the set
of explicitly visible symbols is broken)?  The only other use case I
can think of is for shared libraries which (for some reason) want to
embed private copies of these libraries, but on x86_64, libgcc*.a get
compiled by default without -fPIC, so that doesn't even work.

So ... is there a valid reason for this, or is this just an accident
of history?  AFICT, this behavior dates back to 2007 as of r120429
(http://gcc.gnu.org/viewcvs/trunk/libgcc/static-object.mk?view=markuppathrev=120429).

If no one knows a valid reason for this, I'll submit a patch to remove
it from trunk.  Otherwise, I'll just modify it locally.

Thanks,
Ollie

[google/main] update x86_64-grtev3-linux-gnu test manifest (issue5754049)

[Ollie Wild]

Update x86_64-grtev3-linux-gnu test manifest.

This is a copy of the corresponding x86_64-unknown-linux-gnu one.  Submitting
as obvious.

contrib/
* testsuite-management/x86_64-grtev3-linux-gnu.xfail: Updated to
reflect current x86_64-unknown-linux-gnu.xfail file.

diff --git a/contrib/ChangeLog.google-main b/contrib/ChangeLog.google-main
index f313f6f..937da9c 100644
--- a/contrib/ChangeLog.google-main
+++ b/contrib/ChangeLog.google-main
@@ -1,3 +1,8 @@
+2012-03-05  Ollie Wild  a...@google.com
+
+   * testsuite-management/x86_64-grtev3-linux-gnu.xfail: Updated to
+   reflect current x86_64-unknown-linux-gnu.xfail file.
+
 2012-02-13  Ollie Wild  a...@google.com
 
* testsuite-management/x86_64-unknown-linux-gnu.xfail: Update to
diff --git a/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail 
b/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
index 388da93..f4a3d08 100644
--- a/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
+++ b/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
@@ -1,6 +1,48 @@
-#*** libstdc++ for unix/-m32:
-#*** libstdc++ for unix/-m64:
-# Both of these fail because of the stl debug patch which changes line numbers.
+# Not important to triage if clang based solution is ready
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 10)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 13)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 15)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 18)
+FAIL: gcc.dg/thread_annot_lock-23.c  (test for warnings, line 19)
+FAIL: gcc.dg/thread_annot_lock-24.c  (test for warnings, line 8)
+FAIL: gcc.dg/thread_annot_lock-24.c  (test for warnings, line 9)
+FAIL: gcc.dg/thread_annot_lock-24.c  (test for warnings, line 10)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 8)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 9)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 10)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 22)
+FAIL: gcc.dg/thread_annot_lock-25.c  (test for warnings, line 30)
+FAIL: gcc.dg/thread_annot_lock-42.c  (test for warnings, line 9)
+
+# New regression -- only fail with -std=gnu+11 option
+FAIL: g++.dg/warn/Wself-assign-2.C -std=gnu++11  (test for warnings, line 12)
+
+# New xray failures
+UNRESOLVED: gcc.target/i386/patch-functions-1.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-1.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-2.c scan-assembler-not 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-2.c scan-assembler-not 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-3.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-3.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-4.c scan-assembler-not 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-4.c scan-assembler-not 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-5.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-5.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-6.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-6.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-7.c scan-assembler-not 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-7.c scan-assembler-not 
.byte\t0xeb,0x09(.*).byte\t0x90
+
+
+# These tests fail in trunk in all configurations.
+FAIL: gcc.dg/cproj-fails-with-broken-glibc.c execution test
+XPASS: gcc.dg/unroll_2.c (test for excess errors)
+XPASS: gcc.dg/unroll_3.c (test for excess errors)
+XPASS: gcc.dg/unroll_4.c (test for excess errors)
+FAIL: gcc.c-torture/execute/vshuf-v2di.c execution,  -Os 
+FAIL: gcc.c-torture/execute/vshuf-v8hi.c execution,  -Os 
+FAIL: gcc.target/i386/pr27827.c scan-assembler fmul[ \t]*%st
+FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test
 FAIL: 23_containers/vector/requirements/dr438/assign_neg.cc  (test for errors, 
line 1225)
 FAIL: 23_containers/vector/requirements/dr438/assign_neg.cc (test for excess 
errors)
 FAIL: 23_containers/vector/requirements/dr438/constructor_1_neg.cc  (test for 
errors, line 1155)
@@ -9,15 +51,6 @@ FAIL: 
23_containers/vector/requirements/dr438/constructor_2_neg.cc  (test for er
 FAIL: 23_containers/vector/requirements/dr438/constructor_2_neg.cc (test for 
excess errors)
 FAIL: 23_containers/vector/requirements/dr438/insert_neg.cc  (test for errors, 
line 1266)
 FAIL: 23_containers/vector/requirements/dr438/insert_neg.cc (test for excess 
errors)
-
-# These tests fail in trunk in all configurations

[google/integration] add x86_64-grtev3-linux-gnu target name (issue5718044)

[Ollie Wild]

Add an x86_64-grtev3-linux-gnu target.

For GRTE v2, we use the value of $with_sysroot to conditionally include spec
file changes.  This is inconsistent with what we do for other architectures
like ARM, and it's less flexible since (a) the feature machinery is really
designed to key off $target and (b) we're inferring fundamental things from
incidentals.

This should make it easier to add further GRTE-specific features (patches
forthcoming) and has the added bonus of allowing us to differentiate between
native bootstrap test failures and Crosstool build failures.

I will be submitting this to the google/integration branch and integrating to
google/main and google/gcc-4_7.

Ollie


2012-03-01   Ollie Wild  a...@google.com

* contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail:
* gcc/config.gcc:
* gcc/config/i386/linux.h:
* gcc/config/i386/linux64.h:
* gcc/config/linux-grtev3.h:

diff --git a/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail 
b/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
new file mode 100644
index 000..388da93
--- /dev/null
+++ b/contrib/testsuite-management/x86_64-grtev3-linux-gnu.xfail
@@ -0,0 +1,73 @@
+#*** libstdc++ for unix/-m32:
+#*** libstdc++ for unix/-m64:
+# Both of these fail because of the stl debug patch which changes line numbers.
+FAIL: 23_containers/vector/requirements/dr438/assign_neg.cc  (test for errors, 
line 1225)
+FAIL: 23_containers/vector/requirements/dr438/assign_neg.cc (test for excess 
errors)
+FAIL: 23_containers/vector/requirements/dr438/constructor_1_neg.cc  (test for 
errors, line 1155)
+FAIL: 23_containers/vector/requirements/dr438/constructor_1_neg.cc (test for 
excess errors)
+FAIL: 23_containers/vector/requirements/dr438/constructor_2_neg.cc  (test for 
errors, line 1155)
+FAIL: 23_containers/vector/requirements/dr438/constructor_2_neg.cc (test for 
excess errors)
+FAIL: 23_containers/vector/requirements/dr438/insert_neg.cc  (test for errors, 
line 1266)
+FAIL: 23_containers/vector/requirements/dr438/insert_neg.cc (test for excess 
errors)
+
+# These tests fail in trunk in all configurations.
+FAIL: gcc.dg/cproj-fails-with-broken-glibc.c execution test
+XPASS: gcc.dg/inline_3.c (test for excess errors)
+XPASS: gcc.dg/inline_4.c (test for excess errors)
+XPASS: gcc.dg/unroll_2.c (test for excess errors)
+XPASS: gcc.dg/unroll_3.c (test for excess errors)
+XPASS: gcc.dg/unroll_4.c (test for excess errors)
+FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test
+FAIL: gcc.c-torture/execute/vshuf-v2di.c execution,  -Os
+FAIL: gcc.c-torture/execute/vshuf-v8hi.c execution,  -Os
+FAIL: gcc.c-torture/execute/vshuf-v16qi.c execution,  -Os
+
+# These fail because we use non-standard 32-bit configuration.
+FAIL: gcc.target/i386/pr27827.c scan-assembler fmul[ \t]*%st
+FAIL: gcc.dg/pr52086.c (internal compiler error)
+FAIL: gcc.dg/pr52086.c (test for excess errors)
+
+# Failures in libitm.
+FAIL: libitm.c/stackundo.c (test for excess errors)
+UNRESOLVED: libitm.c/stackundo.c compilation failed to produce executable
+FAIL: libitm.c++/dropref.C (test for excess errors)
+UNRESOLVED: libitm.c++/dropref.C compilation failed to produce executable
+UNRESOLVED: libitm.c++/eh-1.C compilation failed to produce executable
+FAIL: libitm.c++/eh-1.C (test for excess errors)
+FAIL: libitm.c++/throwdown.C (test for excess errors)
+FAIL: libitm.c/cancel.c (test for excess errors)
+UNRESOLVED: libitm.c/cancel.c compilation failed to produce executable
+FAIL: libitm.c/clone-1.c (test for excess errors)
+UNRESOLVED: libitm.c/clone-1.c compilation failed to produce executable
+FAIL: libitm.c/dropref-2.c (test for excess errors)
+UNRESOLVED: libitm.c/dropref-2.c compilation failed to produce executable
+UNRESOLVED: libitm.c/dropref.c compilation failed to produce executable
+FAIL: libitm.c/dropref.c (test for excess errors)
+FAIL: libitm.c/memcpy-1.c (test for excess errors)
+UNRESOLVED: libitm.c/memcpy-1.c compilation failed to produce executable
+FAIL: libitm.c/memset-1.c (test for excess errors)
+UNRESOLVED: libitm.c/memset-1.c compilation failed to produce executable
+UNRESOLVED: libitm.c/notx.c compilation failed to produce executable
+FAIL: libitm.c/notx.c (test for excess errors)
+FAIL: libitm.c/reentrant.c (test for excess errors)
+UNRESOLVED: libitm.c/reentrant.c compilation failed to produce executable
+FAIL: libitm.c/simple-1.c (test for excess errors)
+UNRESOLVED: libitm.c/simple-1.c compilation failed to produce executable
+UNRESOLVED: libitm.c/simple-2.c compilation failed to produce executable
+FAIL: libitm.c/simple-2.c (test for excess errors)
+UNRESOLVED: libitm.c/txrelease.c compilation failed to produce executable
+FAIL: libitm.c/txrelease.c (test for excess errors)
+
+# These tests only fail when boehm-gc.c is enabled.
+FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors)
+
+# These are flaky when tested in loaded machines (they exceed the timeout)
+flaky | FAIL: libmudflap.cth

[google/gcc-4_7] update BASE-VER to 4.7.x-google (issue5696077)

[Ollie Wild]

commit d00e10980dde6c19ec3d8035a80769d54288
Author: Ollie Wild a...@google.com
Date:   Sun Feb 26 00:30:42 2012 -0600

Update BASE-VER to 4.7.x (for consistency across minor releases).  This is
what we do with the existing google/gcc-4_6 branch.

gcc/ChangeLog.google-4_7
2012-02-26  Ollie Wild  a...@google.com

* BASE-VER: Change to 4.7.x-google.

diff --git a/gcc/BASE-VER b/gcc/BASE-VER
index cfb495d..b256a44 100644
--- a/gcc/BASE-VER
+++ b/gcc/BASE-VER
@@ -1 +1 @@
-4.7.0-google
+4.7.x-google
diff --git a/gcc/ChangeLog.google-4_7 b/gcc/ChangeLog.google-4_7
index 9d40c1b..38802b2 100644
--- a/gcc/ChangeLog.google-4_7
+++ b/gcc/ChangeLog.google-4_7
@@ -1,3 +1,7 @@
+2012-02-26  Ollie Wild  a...@google.com
+
+   * BASE-VER: Change to 4.7.x-google.
+
 2012-02-23   Diego Novillo  dnovi...@google.com
 
* BASE-VER: Change to 4.7.0-google.

--
This patch is available for review at http://codereview.appspot.com/5696077

[google/integration] Add missing test failure. (issue5687075)

[Ollie Wild]

The latest Crosstool builds reveal one new test failure (and fix several
others).  This patch adds the missing failure to x86_64-unknown-linux-gnu.xfail.

2012-02-21  Ollie Wild  a...@google.com

* testsuite-management/x86_64-unknown-linux-gnu.xfail: Add
gcc.c-torture/execute/vshuf-v16qi.c failure.

diff --git a/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail 
b/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
index 2a5e01b..1c7196d 100644
--- a/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
+++ b/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
@@ -20,6 +20,7 @@ XPASS: gcc.dg/unroll_4.c (test for excess errors)
 FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test
 FAIL: gcc.c-torture/execute/vshuf-v2di.c execution,  -Os
 FAIL: gcc.c-torture/execute/vshuf-v8hi.c execution,  -Os
+FAIL: gcc.c-torture/execute/vshuf-v16qi.c execution,  -Os
 FAIL: gcc.target/i386/pr27827.c scan-assembler fmul[ \t]*%st
 
 # Failures in libitm.

--
This patch is available for review at http://codereview.appspot.com/5687075

Re: [google/gcc-4_6_2-mobile] PATCH: PR other/46770: Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[Ollie Wild]

Hey, Jing, you broke the google/gcc-4_6 branch by checking the new
header file into the wrong directory.

Fixed via r184386.

Ollie

On Fri, Feb 17, 2012 at 10:25 PM, Jing Yu jin...@google.com wrote:

 OK. Thanks for porting the patch.
 I will commit the patch into google/gcc-4_6_2-mobile for you.

 I would also like to commit it into google/gcc-4_6 branch if all tests
 pass. This patch is almost the same as Google Ref 47894.

 Thanks,
 Jing

 On Fri, Feb 17, 2012 at 5:20 PM, H.J. Lu hongjiu...@intel.com wrote:
  Hi,
 
  This patch backports the fix from trunk:
 
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
 
  for google/gcc-4_6_2-mobile branch.  This is needed to support C++
  global constructors/destructiors on Android/x86.  OK for
  google/gcc-4_6_2-mobile branch?
 
  Thanks.
 
  H.J.
  ---
  2011-08-20  H.J. Lu  hongjiu...@intel.com
 
         PR other/46770
         * config.gcc (tm_file): Add initfini-array.h if
         .init_arrary/.fini_array are supported.
 
         * crtstuff.c: Don't generate .ctors nor .dtors sections if
         USE_INITFINI_ARRAY is defined.
 
         * output.h (default_elf_init_array_asm_out_constructor): New.
         (default_elf_fini_array_asm_out_destructor): Likewise.
         * varasm.c (elf_init_array_section): Likewise.
         (elf_fini_array_section): Likewise.
         (get_elf_initfini_array_priority_section): Likewise.
         (default_elf_init_array_asm_out_constructor): Likewise.
         (default_elf_fini_array_asm_out_destructor): Likewise.
 
         * config/initfini-array.h: New.
 
  git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@177933 
  138bc75d-0d04-0410-961f-82ee72b054a4
 
  Conflicts:
 
         gcc/ChangeLog
  ---
   gcc/ChangeLog.hjl           |   21 +++
   gcc/config.gcc              |    5 +++
   gcc/config/initfini-array.h |   37 +++
   gcc/crtstuff.c              |   11 +++-
   gcc/output.h                |    2 +
   gcc/varasm.c                |   58 
  +++
   6 files changed, 133 insertions(+), 1 deletions(-)
   create mode 100644 gcc/ChangeLog.hjl
   create mode 100644 gcc/config/initfini-array.h
 
  diff --git a/gcc/ChangeLog.hjl b/gcc/ChangeLog.hjl
  new file mode 100644
  index 000..3527b27
  --- /dev/null
  +++ b/gcc/ChangeLog.hjl
  @@ -0,0 +1,21 @@
  +2011-12-07  H.J. Lu  hongjiu...@intel.com
  +
  +       Backport from mainline
  +       2011-08-20  H.J. Lu  hongjiu...@intel.com
  +
  +       PR other/46770
  +       * config.gcc (tm_file): Add initfini-array.h if
  +       .init_arrary/.fini_array are supported.
  +
  +       * crtstuff.c: Don't generate .ctors nor .dtors sections if
  +       USE_INITFINI_ARRAY is defined.
  +
  +       * output.h (default_elf_init_array_asm_out_constructor): New.
  +       (default_elf_fini_array_asm_out_destructor): Likewise.
  +       * varasm.c (elf_init_array_section): Likewise.
  +       (elf_fini_array_section): Likewise.
  +       (get_elf_initfini_array_priority_section): Likewise.
  +       (default_elf_init_array_asm_out_constructor): Likewise.
  +       (default_elf_fini_array_asm_out_destructor): Likewise.
  +
  +       * config/initfini-array.h: New.
  diff --git a/gcc/config.gcc b/gcc/config.gcc
  index d9ac0fa..b386424 100644
  --- a/gcc/config.gcc
  +++ b/gcc/config.gcc
  @@ -3176,6 +3176,11 @@ if test x$with_schedule = x; then
         esac
   fi
 
  +# Support --enable-initfini-array.
  +if test x$enable_initfini_array = xyes; then
  +  tm_file=${tm_file} initfini-array.h
  +fi
  +
   # Validate and mark as valid any --with options supported
   # by this target.  In order to use a particular --with option
   # you must list it in supported_defaults; validating the value
  diff --git a/gcc/config/initfini-array.h b/gcc/config/initfini-array.h
  new file mode 100644
  index 000..8aaadf6
  --- /dev/null
  +++ b/gcc/config/initfini-array.h
  @@ -0,0 +1,37 @@
  +/* Definitions for ELF systems with .init_array/.fini_array section
  +   support.
  +   Copyright (C) 2011
  +   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 3, 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 COPYING3.  If not see
  +   http://www.gnu.org/licenses/.  */
  +
  +#define USE_INITFINI_ARRAY
  +
  +#undef INIT_SECTION_ASM_OP
  +#undef FINI_SECTION_ASM_OP
  +
  +#undef INIT_ARRAY_SECTION_ASM_OP
  +#define INIT_ARRAY_SECTION_ASM_OP
  +
  +#undef 

[google/main] update known test failures (issue5654064)

[Ollie Wild]

commit cbd38ef0c58ac4a365913d2bb2a2e0c062516dbb
Author: Ollie Wild a...@google.com
Date:   Sat Feb 11 22:05:52 2012 -0600

Update known failures to reflect current reality.

diff --git a/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail 
b/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
index 2e651ef..1f9c3d6 100644
--- a/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
+++ b/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
@@ -16,21 +16,22 @@ FAIL: gcc.dg/thread_annot_lock-42.c  (test for warnings, 
line 9)
 
 # New regression -- only fail with -std=gnu+11 option
 FAIL: g++.dg/warn/Wself-assign-2.C -std=gnu++11  (test for warnings, line 12)
-FAIL: g++.dg/template/sfinae19.C -std=c++11 (test for excess errors)
 
 # New xray failures
-FAIL: gcc.target/i386/patch-functions-1.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
-FAIL: gcc.target/i386/patch-functions-1.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
-FAIL: gcc.target/i386/patch-functions-3.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
-FAIL: gcc.target/i386/patch-functions-3.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
-FAIL: gcc.target/i386/patch-functions-5.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
-FAIL: gcc.target/i386/patch-functions-5.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
-FAIL: gcc.target/i386/patch-functions-6.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
-FAIL: gcc.target/i386/patch-functions-6.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
-
-
-# gc failure
-FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors)
+UNRESOLVED: gcc.target/i386/patch-functions-1.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-1.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-2.c scan-assembler-not 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-2.c scan-assembler-not 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-3.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-3.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-4.c scan-assembler-not 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-4.c scan-assembler-not 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-5.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-5.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-6.c scan-assembler 
.byte\t0xeb,0x09(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-6.c scan-assembler 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-7.c scan-assembler-not 
ret(.*).byte\t0x90(.*).byte\t0x90
+UNRESOLVED: gcc.target/i386/patch-functions-7.c scan-assembler-not 
.byte\t0xeb,0x09(.*).byte\t0x90
 
 
 # These tests fail in trunk in all configurations.
@@ -63,7 +64,6 @@ UNRESOLVED: libitm.c++/dropref.C compilation failed to 
produce executable
 UNRESOLVED: libitm.c++/eh-1.C compilation failed to produce executable
 FAIL: libitm.c++/eh-1.C (test for excess errors)
 FAIL: libitm.c++/throwdown.C (test for excess errors)
- .merge-right.r183740
 FAIL: libitm.c/cancel.c (test for excess errors)
 UNRESOLVED: libitm.c/cancel.c compilation failed to produce executable
 FAIL: libitm.c/clone-1.c (test for excess errors)
@@ -82,8 +82,14 @@ FAIL: libitm.c++/dropref.C (test for excess errors)
 UNRESOLVED: libitm.c++/dropref.C compilation failed to produce executable
 FAIL: libitm.c++/eh-1.C (test for excess errors)
 UNRESOLVED: libitm.c++/eh-1.C compilation failed to produce executable
-FAIL: libitm.c++/static_ctor.C (test for excess errors)
-UNRESOLVED: libitm.c++/static_ctor.C compilation failed to produce executable
+UNRESOLVED: libitm.c/notx.c compilation failed to produce executable
+FAIL: libitm.c/notx.c (test for excess errors)
+UNRESOLVED: libitm.c/reentrant.c compilation failed to produce executable
+FAIL: libitm.c/reentrant.c (test for excess errors)
+UNRESOLVED: libitm.c/simple-2.c compilation failed to produce executable
+FAIL: libitm.c/simple-2.c (test for excess errors)
+UNRESOLVED: libitm.c/txrelease.c compilation failed to produce executable
+FAIL: libitm.c/txrelease.c (test for excess errors)
 
 # These are flaky when tested in loaded machines (they exceed the timeout)
 flaky | FAIL: libmudflap.cth/pass40-frag.c (-O2) output pattern test

--
This patch is available for review at http://codereview.appspot.com/5654064

Re: [PATCH] [Annotalysis] Add support for arrays in lock expressions

[Ollie Wild]

On Thu, Nov 3, 2011 at 1:20 PM, Delesley Hutchins deles...@google.com wrote:

 This patch adds support for array indexing (i.e. operator []) in lock
 expressions.  The current version of gcc seems to emit these as
 expressions involving pointer arithmetic, so we  update
 get_canonical_lock_expr() to handle such expressions.

This looks reasonable to me, but I don't have much familiarity with
Gimple.  Diego, can you please review?

Thanks,
Ollie

Re: [PATCH] [Annotalysis] Support trylock attributes on virtual methods.

[Ollie Wild]

On Tue, Nov 8, 2011 at 12:11 PM, Delesley Hutchins deles...@google.com wrote:
 This patch fixes a bug wherein the trylock attribute would not work if
 it was attached to a virtual method.

Diego, can you please review this?

Thanks,
Ollie

Re: [PATCH] [Annotalysis] Bugfix for spurious thread safety warnings with shared mutexes

[Ollie Wild]

On Wed, Oct 12, 2011 at 9:58 AM, Delesley Hutchins deles...@google.com wrote:

 I don't think that will fix this bug.  The bug occurs if:
 (1) The exclusive lock set has error_mark_node.
 (2) The shared lock set has the actual lock.

Oh, I see.  This change looks fine for google/gcc-4_6, then.

 If I understand your suggested fix correctly, lock_set_contains would
 still return non-null when the universal lock was present, which is
 not what we want.  IMHO, lock_set_contains is operating correctly; it
 was just passed the wrong arguments.

I still think there may be a bug in lock_set_contains, but my
knowledge of the code is insufficient to know if this can lead to
problems in practice.  Suppose the lock set contains both the supplied
lock and the universal lock, and ignore_universal_lock is false.  Then
lock_set_contains() will return the lock directly.  However, it
*should* return the canonicalized version of the lock.

Ollie

Re: [PATCH] [Annotalysis] Bugfix for spurious thread safety warnings with shared mutexes

[Ollie Wild]

On Mon, Oct 10, 2011 at 3:37 PM, Delesley Hutchins deles...@google.com wrote:

 --- gcc/tree-threadsafe-analyze.c       (revision 179771)
 +++ gcc/tree-threadsafe-analyze.c       (working copy)
 @@ -1830,14 +1830,27 @@ remove_lock_from_lockset (tree lockable, struct po

This feels like a bug in lock_set_contains(), not
remove_lock_from_lockset().  I'd modify lock_set_contains() as
follows:

1) During the universal lock conditional, remove the return statement.
 Instead, set default_lock = lock (where default_lock is a new
variable initialized to NULL_TREE).

2) Anywhere NULL_TREE is returned later, replace it with default_lock.

Ollie

Re: [PATCH] [Annotalysis] Fix internal compiler error on template methods

[Ollie Wild]

I think what you're looking for is:

if (DECL_CLONED_FUNCTION_P (clone)  DECL_CLONED_FUNCTION (clone) == decl)

That's a much cleaner implementation.

Ollie

On Tue, Sep 27, 2011 at 6:18 PM, Delesley Hutchins deles...@google.com wrote:

 This patch fixes a bug in the parser which cause an internal compiler
 error when copying attributes from cloned methods.  The bug occurs
 when a class has both an annotated constructor and a template method.

 Bootstrapped and passed gcc regression testsuite on
 x86_64-unknown-linux-gnu.  Okay for google/gcc-4_6?

  -DeLesley

 cp/Changelog.google-4_6:
 2011-9-27  DeLesley Hutchins  deles...@google.com

      * cp/parser.c  (cp_parser_late_parsing_attribute_arg_lists)
         fixed case where the potential clone is a template.

 testsuite/Changelog.google-4_6:
 2011-9-27  DeLesley Hutchins  deles...@google.com

      * testsuite/g++.dg/thread-ann/thread_annot_lock-81.C
        (new regression test)

 --
 DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315

Re: [PATCH] [Annotalysis] Fix internal compiler error on template methods

[Ollie Wild]

On Thu, Sep 29, 2011 at 10:13 AM, Delesley Hutchins deles...@google.com wrote:

 Unfortunately, DECL_CLONED_FUNCTION_P is not actually a predicate that allows 
 you to call DECL_CLONED_FUNCTION safely.  Look at the definition of the 
 macros; despite what the comments say, DECL_CLONED_FUNCTION_P may return true 
 in cases where DECL_CLONED_FUNCTION will still crash.  The correct fix is to 
 fix the macros, but I have no understanding of what they are actually doing.  
 :-(
   -DeLesley

Diego, can you comment?

Ollie

Re: [google] Merge trunk into google/integration

[Ollie Wild]

LGTM

Ollie

On Wed, Sep 14, 2011 at 3:29 PM, Diego Novillo dnovi...@google.com wrote:

 This merge brings google/integration up to rev 178783.  I also
 merged rev 178833 to get the testsuite validation script I
 committed to trunk yesterday.

 Simon, Ollie, I expect our internal builder to fail until I
 incorporate validate_failures.py into it.  It's a catch-22, but
 it is easier to keep the local changes to the builder than the
 whole merge.

 I have reverted all the xfail/skip markers we used to have.  I
 moved the ones that still fail to the new xfail manifest file in
 contrib/testsuite-management (we'll likely need manifests for
 other platforms as well).

 Tested on x86_64.  Committed to google/integration.


 2011-09-14   Diego Novillo  dnovi...@google.com

        Mainline merge rev 178783.
        Cherry pick mainline rev 178833.

 2011-09-14   Diego Novillo  dnovi...@google.com

 contrib/ChangeLog.google-integration

        * testsuite-management/x86_64-unknown-linux-gnu.xfail: New.

 gcc/testsuite/ChangeLog.google-integration

        * g++.dg/tree-prof/partition2.C: Revert to mainline variant.
        * g++.dg/tree-ssa/pr41186.C: Likewise.
        * gcc.dg/cproj-fails-with-broken-glibc.c: Likewise.
        * gcc.dg/guality/sra-1.c: Likewise.
        * gcc.dg/guality/vla-1.c: Likewise.
        * gcc.dg/guality/vla-2.c: Likewise.
        * gcc.dg/inline_3.c: Likewise.
        * gcc.dg/inline_4.c: Likewise.
        * gcc.dg/tree-ssa/vrp47.c: Likewise.
        * gcc.dg/uninit-B.c: Likewise.
        * gcc.dg/uninit-pr19430.c: Likewise.
        * gcc.dg/unroll_2.c: Likewise.
        * gcc.dg/unroll_3.c: Likewise.
        * gcc.dg/unroll_4.c: Likewise.
        * gcc.target/i386/pr27827.c: Likewise.
        * gcc.target/i386/sse4_1-blendps-2.c: Likewise.
        * gcc.target/i386/sse4_1-blendps.c: Likewise.

 libmudflap/ChangeLog.google-integration

        * testsuite/libmudflap.c++/pass55-frag.cxx: Revert to
        mainline variant.

 libstdc++-v3/ChangeLog.google-integration:

        * testsuite/23_containers/vector/requirements/dr438/assign_neg.cc:
        Revert to mainline variant.
        * 
 testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc: 
 Likewise.
        * 
 testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc: 
 Likewise.
        * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: 
 Likewise.

 diff --git 
 a/svnclient/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail 
 b/svnclient/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
 new file mode 100644
 index 000..b3e86a5
 --- /dev/null
 +++ b/svnclient/contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
 @@ -0,0 +1,59 @@
 +# These tests fail in trunk in all configurations.
 +FAIL: 23_containers/vector/requirements/dr438/assign_neg.cc (test for 
 errors, line 1222)
 +FAIL: 23_containers/vector/requirements/dr438/assign_neg.cc (test for excess 
 errors)
 +FAIL: 23_containers/vector/requirements/dr438/constructor_1_neg.cc (test for 
 excess errors)
 +FAIL: 23_containers/vector/requirements/dr438/constructor_1_neg.cc (test for 
 errors, line 1152)
 +FAIL: 23_containers/vector/requirements/dr438/constructor_2_neg.cc (test for 
 excess errors)
 +FAIL: 23_containers/vector/requirements/dr438/constructor_2_neg.cc (test for 
 errors, line 1152)
 +FAIL: 23_containers/vector/requirements/dr438/insert_neg.cc (test for excess 
 errors)
 +FAIL: 23_containers/vector/requirements/dr438/insert_neg.cc (test for 
 errors, line 1263)
 +FAIL: gcc.dg/cproj-fails-with-broken-glibc.c execution test
 +XPASS: gcc.dg/inline_3.c (test for excess errors)
 +XPASS: gcc.dg/inline_4.c (test for excess errors)
 +FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times dom1 x[^ ]*  y 1
 +XPASS: gcc.dg/uninit-B.c uninit i warning (test for warnings, line 12)
 +XPASS: gcc.dg/uninit-pr19430.c uninitialized (test for warnings, line 41)
 +XPASS: gcc.dg/uninit-pr19430.c (test for warnings, line 32)
 +XPASS: gcc.dg/unroll_2.c (test for excess errors)
 +XPASS: gcc.dg/unroll_3.c (test for excess errors)
 +XPASS: gcc.dg/unroll_4.c (test for excess errors)
 +FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test
 +
 +# The following tests are failing with gold.  The LTO plugin is not resolving
 +# names properly.  Only builds configured to use gold will show these.
 +UNRESOLVED: gcc.c-torture/execute/20010209-1.c execution,  -O2 -flto 
 -flto-partition=none
 +UNRESOLVED: gcc.c-torture/execute/20010209-1.c execution,  -O2 -flto
 +FAIL: gcc.c-torture/execute/20010209-1.c compilation,  -O2 -flto  (internal 
 compiler error)
 +FAIL: gcc.c-torture/execute/20010209-1.c compilation,  -O2 -flto 
 -flto-partition=none  (internal compiler error)
 +
 +# These tests fail in trunk when compiled with -m32.
 +FAIL: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors)
 +FAIL: gcc.target/i386/pr27827.c scan-assembler fmul[ \t]*%st
 +FAIL: gfortran.dg/actual_array_constructor_1.f90  -O1  (internal compiler 

Re: [PATCH] [google] [annotalysis] Fix remove operation from pointer_set in case of hash collisions

[Ollie Wild]

Okay for google/gcc-4_6.

Ollie

On Tue, Jul 26, 2011 at 7:27 PM, Delesley Hutchins deles...@google.com wrote:

 Le-Chun added the additional routine to remove pointers from a set;
 that code is unique to annotalysis.  I can't easily include a test
 case, because the bug is difficult to trigger.  It occurs only when
 there is a hash collision between two pointers in the set, and the
 first pointer is removed before the second.  I do have a test case,
 but it will only work for my particular build on my machine, since the
 actual pointer addresses involved will change as soon as you touch
 something.  I could write a unit test using bogus pointer values that
 are engineered to trigger a collision, but it wouldn't be a normal
 compiler test case; where would I put it?

  -DeLesley

 On Tue, Jul 26, 2011 at 5:59 PM, Diego Novillo dnovi...@google.com wrote:
  On Tue, Jul 26, 2011 at 16:13, Delesley Hutchins deles...@google.com 
  wrote:
  This patch fixes a bug in pointer_set.c, where removing a pointer from
  a pointer set would corrupt the hash table if the pointer was involved
  in any hash collisions.
 
  Could you include a test case?  It's not clear to me what you are
  fixing and when this happens.  Is this a bug in trunk as well?  The
  pointer-set implementation has been around for a while, so I'm
  surprised that you are running into this now.  Or is this something
  that only happens with the pointer set changes we have in for
  annotalysis?
 
 
  Thanks.  Diego.
 



 --
 DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315

Re: [google][patch] Put make_heap's declaration on a single line to work around inconsistent debug locations

[Ollie Wild]

Ok for inclusion in google/gcc-4_6.

Ollie

On Fri, Jul 22, 2011 at 5:46 PM, Jeffrey Yasskin jyass...@google.com wrote:

 For the google/gcc-4_6 branch _only_. I'll fix the inconsistency in
 debug locations later for trunk and google/main.

 In some translation units the debug location of make_heap is the
 location of its name; in other TUs it's the location of the closing
 ')'. This causes false positives in gold's ODR checker. Until I can
 find why the locations are inconsistent, we can work around the
 problem by putting the name and closing ')' on the same line.

 libstdc++-v3/ChangeLog
 2011-07-22   Jeffrey Yasskin  jyass...@google.com

        * include/bits/stl_heap.h(make_heap): Remove a newline.

Re: [PATCH] [Annotalysis] Fixes virtual method calls when type is unknown

[Ollie Wild]

On Thu, Jun 30, 2011 at 12:09 PM, Diego Novillo dnovi...@google.com wrote:

 On 11-06-30 13:01 , Delesley Hutchins wrote:

 Okay for branches/annotalysis and google/main?

 OK with some minor formatting nits below.

Please also cherry-pick this into the google/gcc_4-6 branch.  I've
sent you instructions out-of-band for doing so.

Ollie

Re: [google] Merged gcc-4_6-branch - google/gcc-4_6

[Ollie Wild]

On Wed, Jun 29, 2011 at 10:42 AM, Martin Jambor mjam...@suse.cz wrote:

 The fix for 49094 had to be changed and is still being tested, even
 for trunk, and thus I have committed a 4.6 backport of the fix for
 PR 49516 on its own today (as revision 175634).  Nevertheles yes, the
 patch is exactly the same, only with a minor line offset.

Great!  Please cherry-pick that change into the google/gcc-4_6 branch.

Ollie

Re: [google] Merged gcc-4_6-branch - google/gcc-4_6

[Ollie Wild]

On Wed, Jun 29, 2011 at 11:24 AM, Ollie Wild a...@google.com wrote:

 On Wed, Jun 29, 2011 at 10:42 AM, Martin Jambor mjam...@suse.cz wrote:
 
  The fix for 49094 had to be changed and is still being tested, even
  for trunk, and thus I have committed a 4.6 backport of the fix for
  PR 49516 on its own today (as revision 175634).  Nevertheles yes, the
  patch is exactly the same, only with a minor line offset.

 Great!  Please cherry-pick that change into the google/gcc-4_6 branch.

Oops!  Wrong Martin.  :-)

Diego will merge this to the google/gcc-4_6 branch.

Thanks for the fix!

Ollie

Re: [Patch] Make libstdc++'s abi_check more robust against readelf output format

[Ollie Wild]

Ok, for google/integration.  Please integrate to google/main and
google/gcc-4_6 as well.

Ollie

On Fri, May 20, 2011 at 10:05 AM, 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 for readelf output can vary where the library contains OS or processor
 specific bindings, or other unknown bindings.

 This patch replaces the strings that readelf outputs for such bindings
 with alternative strings that use underscores in place of space.  It
 preserves the count of fields for such cases, and allows the awk statement
 that follows to find the desired field 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
 ===
 --- libstdc++-v3/scripts/extract_symvers.in     (revision 173951)
 +++ libstdc++-v3/scripts/extract_symvers.in     (working copy)
 @@ -52,6 +52,9 @@ SunOS)
   ${readelf} ${lib} |\
   sed -e 's/ \[other: [A-Fa-f0-9]*\] //' -e '/\.dynsym/,/^$/p;d' |\
   egrep -v ' (LOCAL|UND) ' |\
 +  sed -e 's/ processor specific: / processor_specific:_/g' |\
 +  sed -e 's/ OS specific: / OS_specific:_/g' |\
 +  sed -e 's/ unknown: / unknown:_/g' |\
   awk '{ if ($4 == FUNC || $4 == NOTYPE)
            printf %s:%s\n, $4, $8;
          else if ($4 == OBJECT || $4 == TLS)

Re: [google] Re: Build more of libstdc++ exception throwing code with frame pointers (issue4539068)

[Ollie Wild]

Approved for google/integration (since Diego is on vacation).

Paul, please also merge this change only to google/main and google/gcc-4_6.

Thanks,
Ollie

On Thu, May 19, 2011 at 1:24 PM, Paul Pluzhnikov ppluzhni...@google.com wrote:

 This patch is for google/integration branch.

 Sorry about not setting the markers correctly.

 Tested by doing a bootstrap build and verifying that
 __gnu_cxx::__verbose_terminate_handler is built with frame pointers.

 On Thu, May 19, 2011 at 10:46 AM, Paul Pluzhnikov
 ppluzhni...@google.com wrote:
  2011-05-19  Paul Pluzhnikov  ppluzhni...@google.com
 
         * libstdc++-v3/libsupc++/Makefile.am: Add -fno-omit-frame-pointer
         to vterminate.
         * libstdc++-v3/libsupc++/Makefile.in: Regenerate.


 --
 Paul Pluzhnikov

[google] Remove unqualified lookups which break clang (issue4439085)

[Ollie Wild]

commit 99835abc5d2a7fd3ae0950c8a16fd6d223d408c9
Author: Ollie Wild a...@google.com
Date:   Fri Apr 29 13:03:57 2011 -0400

Remove unqualified lookups into dependent template base classes from
STL headers.  These break clang.

See http://clang.llvm.org/compatibility.html#dep_lookup_bases.

To be applied to google/main.  Would also like permissiont to submit to
trunk.

M   libstdc++-v3/include/ext/sso_string_base.h
M   libstdc++-v3/include/ext/vstring.h
M   libstdc++-v3/include/ext/vstring.tcc

Tested:
  Tested via buildit bootstrap and tests.

ChangeLog:

2011-05-02  Ollie Wild  a...@google.com

* include/ext/sso_string_base.h (__sso_string_base::_M_construct):
Fix unqualified lookup.
(__sso_string_base::_M_construct): Likewise.
(__sso_string_base::_M_construct): Likewise.
(__sso_string_base::_M_assign): Likewise.
(__sso_string_base::_M_reserve): Likewise.
(__sso_string_base::_M_mutate): Likewise.
(__sso_string_base::_M_erase): Likewise.
* include/ext/vstring.h (__versa_string::replace): Likewise.
(__versa_string::compare): Likewise.
* include/ext/vstring.tcc (__versa_string::compare): Likewise.
(__versa_string::compare): Likewise.
(__versa_string::compare): Likewise.
(__versa_string::compare): Likewise.
(__versa_string::compare): Likewise.

diff --git a/libstdc++-v3/include/ext/sso_string_base.h 
b/libstdc++-v3/include/ext/sso_string_base.h
index 638eeba..39a62d6 100644
--- a/libstdc++-v3/include/ext/sso_string_base.h
+++ b/libstdc++-v3/include/ext/sso_string_base.h
@@ -432,7 +432,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Allocate more space.
__capacity = __len + 1;
_CharT* __another = _M_create(__capacity, __len);
-   _S_copy(__another, _M_data(), __len);
+   this-_S_copy(__another, _M_data(), __len);
_M_dispose();
_M_data(__another);
_M_capacity(__capacity);
@@ -472,7 +472,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
// Check for out_of_range and length_error exceptions.
__try
- { _S_copy_chars(_M_data(), __beg, __end); }
+ { this-_S_copy_chars(_M_data(), __beg, __end); }
__catch(...)
  {
_M_dispose();
@@ -494,7 +494,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
   if (__n)
-   _S_assign(_M_data(), __n, __c);
+   this-_S_assign(_M_data(), __n, __c);
 
   _M_set_length_no_wipe(__n);
 }
@@ -519,7 +519,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
  if (__rsize)
-   _S_copy(_M_data(), __rcs._M_data(), __rsize);
+   this-_S_copy(_M_data(), __rcs._M_data(), __rsize);
 
  _M_set_length(__rsize);
}
@@ -541,14 +541,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  || __res  size_type(_S_local_capacity))
{
  _CharT* __tmp = _M_create(__res, __capacity);
- _S_copy(__tmp, _M_data(), _M_length() + 1);
+ this-_S_copy(__tmp, _M_data(), _M_length() + 1);
  _M_dispose();
  _M_data(__tmp);
  _M_capacity(__res);
}
  else if (!_M_is_local())
{
- _S_copy(_M_local_data, _M_data(), _M_length() + 1);
+ this-_S_copy(_M_local_data, _M_data(), _M_length() + 1);
  _M_destroy(__capacity);
  _M_data(_M_local_data);
}
@@ -567,12 +567,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _CharT* __r = _M_create(__new_capacity, _M_capacity());
 
   if (__pos)
-   _S_copy(__r, _M_data(), __pos);
+   this-_S_copy(__r, _M_data(), __pos);
   if (__s  __len2)
-   _S_copy(__r + __pos, __s, __len2);
+   this-_S_copy(__r + __pos, __s, __len2);
   if (__how_much)
-   _S_copy(__r + __pos + __len2,
-   _M_data() + __pos + __len1, __how_much);
+   this-_S_copy(__r + __pos + __len2,
+ _M_data() + __pos + __len1, __how_much);
   
   _M_dispose();
   _M_data(__r);
@@ -587,8 +587,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const size_type __how_much = _M_length() - __pos - __n;
 
   if (__how_much  __n)
-   _S_move(_M_data() + __pos, _M_data() + __pos + __n,
-   __how_much);
+   this-_S_move(_M_data() + __pos, _M_data() + __pos + __n, __how_much);
 
   _M_set_length(_M_length() - __n);
 }
diff --git a/libstdc++-v3/include/ext/vstring.h 
b/libstdc++-v3/include/ext/vstring.h
index 90a5683..57f36a6 100644
--- a/libstdc++-v3/include/ext/vstring.h
+++ b/libstdc++-v3/include/ext/vstring.h
@@ -1374,7 +1374,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__i2 = _M_iend());
  __glibcxx_requires_valid_range(__k1, __k2);
  typedef typename std::__is_integer_InputIterator::__type _Integral;
- return

Re: [google] Remove unqualified lookups which break clang (issue4439085)

[Ollie Wild]

Submitted to google/main.

Adding libstd...@gcc.gnu.org for trunk approval.

Ollie

On Mon, May 2, 2011 at 9:34 AM, Ollie Wild a...@google.com wrote:

 commit 99835abc5d2a7fd3ae0950c8a16fd6d223d408c9
 Author: Ollie Wild a...@google.com
 Date:   Fri Apr 29 13:03:57 2011 -0400

    Remove unqualified lookups into dependent template base classes from
    STL headers.  These break clang.

    See http://clang.llvm.org/compatibility.html#dep_lookup_bases.

    To be applied to google/main.  Would also like permissiont to submit to
    trunk.

 M       libstdc++-v3/include/ext/sso_string_base.h
 M       libstdc++-v3/include/ext/vstring.h
 M       libstdc++-v3/include/ext/vstring.tcc

 Tested:
  Tested via buildit bootstrap and tests.

 ChangeLog:

 2011-05-02  Ollie Wild  a...@google.com

        * include/ext/sso_string_base.h (__sso_string_base::_M_construct):
        Fix unqualified lookup.
        (__sso_string_base::_M_construct): Likewise.
        (__sso_string_base::_M_construct): Likewise.
        (__sso_string_base::_M_assign): Likewise.
        (__sso_string_base::_M_reserve): Likewise.
        (__sso_string_base::_M_mutate): Likewise.
        (__sso_string_base::_M_erase): Likewise.
        * include/ext/vstring.h (__versa_string::replace): Likewise.
        (__versa_string::compare): Likewise.
        * include/ext/vstring.tcc (__versa_string::compare): Likewise.
        (__versa_string::compare): Likewise.
        (__versa_string::compare): Likewise.
        (__versa_string::compare): Likewise.
        (__versa_string::compare): Likewise.

 diff --git a/libstdc++-v3/include/ext/sso_string_base.h 
 b/libstdc++-v3/include/ext/sso_string_base.h
 index 638eeba..39a62d6 100644
 --- a/libstdc++-v3/include/ext/sso_string_base.h
 +++ b/libstdc++-v3/include/ext/sso_string_base.h
 @@ -432,7 +432,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
                    // Allocate more space.
                    __capacity = __len + 1;
                    _CharT* __another = _M_create(__capacity, __len);
 -                   _S_copy(__another, _M_data(), __len);
 +                   this-_S_copy(__another, _M_data(), __len);
                    _M_dispose();
                    _M_data(__another);
                    _M_capacity(__capacity);
 @@ -472,7 +472,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

        // Check for out_of_range and length_error exceptions.
        __try
 -         { _S_copy_chars(_M_data(), __beg, __end); }
 +         { this-_S_copy_chars(_M_data(), __beg, __end); }
        __catch(...)
          {
            _M_dispose();
 @@ -494,7 +494,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
        }

       if (__n)
 -       _S_assign(_M_data(), __n, __c);
 +       this-_S_assign(_M_data(), __n, __c);

       _M_set_length_no_wipe(__n);
     }
 @@ -519,7 +519,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
            }

          if (__rsize)
 -           _S_copy(_M_data(), __rcs._M_data(), __rsize);
 +           this-_S_copy(_M_data(), __rcs._M_data(), __rsize);

          _M_set_length(__rsize);
        }
 @@ -541,14 +541,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
              || __res  size_type(_S_local_capacity))
            {
              _CharT* __tmp = _M_create(__res, __capacity);
 -             _S_copy(__tmp, _M_data(), _M_length() + 1);
 +             this-_S_copy(__tmp, _M_data(), _M_length() + 1);
              _M_dispose();
              _M_data(__tmp);
              _M_capacity(__res);
            }
          else if (!_M_is_local())
            {
 -             _S_copy(_M_local_data, _M_data(), _M_length() + 1);
 +             this-_S_copy(_M_local_data, _M_data(), _M_length() + 1);
              _M_destroy(__capacity);
              _M_data(_M_local_data);
            }
 @@ -567,12 +567,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
       _CharT* __r = _M_create(__new_capacity, _M_capacity());

       if (__pos)
 -       _S_copy(__r, _M_data(), __pos);
 +       this-_S_copy(__r, _M_data(), __pos);
       if (__s  __len2)
 -       _S_copy(__r + __pos, __s, __len2);
 +       this-_S_copy(__r + __pos, __s, __len2);
       if (__how_much)
 -       _S_copy(__r + __pos + __len2,
 -               _M_data() + __pos + __len1, __how_much);
 +       this-_S_copy(__r + __pos + __len2,
 +                     _M_data() + __pos + __len1, __how_much);

       _M_dispose();
       _M_data(__r);
 @@ -587,8 +587,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
       const size_type __how_much = _M_length() - __pos - __n;

       if (__how_much  __n)
 -       _S_move(_M_data() + __pos, _M_data() + __pos + __n,
 -               __how_much);
 +       this-_S_move(_M_data() + __pos, _M_data() + __pos + __n, __how_much);

       _M_set_length(_M_length() - __n);
     }
 diff --git a/libstdc++-v3/include/ext/vstring.h 
 b/libstdc++-v3/include/ext/vstring.h
 index 90a5683..57f36a6 100644
 --- a/libstdc++-v3/include/ext/vstring.h
 +++ b/libstdc++-v3/include/ext/vstring.h
 @@ -1374,7 +1374,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

Re: [google] Normalize version number for google/gcc-4_6 (issue4454049)

[Ollie Wild]

On Mon, May 2, 2011 at 2:53 PM, Diego Novillo dnovi...@google.com wrote:

 Since google/gcc-4_6 follows the 4.6 branch, changes in minor
 revisions cause unnecessary churn in directory names.

 Fixed with this.  OK for google/gcc-4_6?

Yes, okay for google/gcc-4_6.

Thanks,
Ollie

[google] GRTE static link spec (issue4426065)

[Ollie Wild]

commit 44417f1103b0823f950f539a38a5539b8ff74330
Author: Ollie Wild a...@google.com
Date:   Mon Apr 25 21:55:44 2011 -0400

When using GRTE (libc) and linking statically, instead of just -lc add:

  -lc -lnss_borg -lnss_cache -lnss_dns -lnss_files -lresolv

to the link by modifying LIB_SPEC to redirect to several new specs
which are GRTE-specific.

To be applied to google/integration branch.


M   gcc/config.gcc
M   gcc/config/i386/linux.h
M   gcc/config/i386/linux64.h
A   gcc/config/linux-grtev2.h

Tested:
  Tested via buildit bootstrap and tests and by executing gcc with -v to
  validate supplied link options.

ChangeLog:
2011-04-27  Ollie Wild  a...@google.com

* config.gcc: Add GRTE detection.
* config/i386/linux.h (LINUX_GRTE_EXTRA_SPECS): New macro.
(SUBTARGET_EXTRA_SPECS): Add LINUX_GRTE_EXTRA_SPECS.
* config/i386/linux64.h (LINUX_GRTE_EXTRA_SPECS): New macro.
(SUBTARGET_EXTRA_SPECS): New macro with LINUX_GRTE_EXTRA_SPECS.
* config/linux-grtev2.h: New file.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 58f6787..dc7524f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1286,6 +1286,9 @@ i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | 
i[34567]86-*-knetbsd*-gnu | i
i[34567]86-*-gnu*) tm_file=$tm_file i386/linux.h gnu.h i386/gnu.h;;
esac
tmake_file=${tmake_file} i386/t-crtstuff i386/t-crtpc i386/t-crtfm 
t-dfprules
+   if [ $with_sysroot = /usr/grte/v2 ]; then
+ tm_file=${tm_file} linux-grtev2.h
+   fi
;;
 x86_64-*-linux* | x86_64-*-kfreebsd*-gnu | x86_64-*-knetbsd*-gnu)
tm_file=${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h gnu-user.h 
linux.h glibc-stdint.h \
@@ -1297,6 +1300,9 @@ x86_64-*-linux* | x86_64-*-kfreebsd*-gnu | 
x86_64-*-knetbsd*-gnu)
x86_64-*-knetbsd*-gnu) tm_file=${tm_file} knetbsd-gnu.h ;;
esac
tmake_file=${tmake_file} i386/t-linux64 i386/t-crtstuff i386/t-crtpc 
i386/t-crtfm t-dfprules
+   if [ $with_sysroot = /usr/grte/v2 ]; then
+ tm_file=${tm_file} linux-grtev2.h
+   fi
;;
 i[34567]86-pc-msdosdjgpp*)
xm_file=i386/xm-djgpp.h
diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
index 1d2a548..019cea9 100644
--- a/gcc/config/i386/linux.h
+++ b/gcc/config/i386/linux.h
@@ -101,8 +101,14 @@ along with GCC; see the file COPYING3.  If not see
 #define ASM_SPEC \
   --32 %{!mno-sse2avx:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}
 
+/* These may be provided by config/linux-grtev2.h.  */
+#ifndef LINUX_GRTE_EXTRA_SPECS
+#define LINUX_GRTE_EXTRA_SPECS
+#endif
+
 #undef  SUBTARGET_EXTRA_SPECS
 #define SUBTARGET_EXTRA_SPECS \
+  LINUX_GRTE_EXTRA_SPECS \
   { link_emulation, LINK_EMULATION },\
   { dynamic_linker, LINUX_DYNAMIC_LINKER }
 
diff --git a/gcc/config/i386/linux64.h b/gcc/config/i386/linux64.h
index 118e795..429c273 100644
--- a/gcc/config/i386/linux64.h
+++ b/gcc/config/i386/linux64.h
@@ -90,6 +90,15 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
   %{ SPEC_64 :-dynamic-linker  LINUX_DYNAMIC_LINKER64 }} \
 %{static:-static}}
 
+/* These may be provided by config/linux-grtev2.h.  */
+#ifndef LINUX_GRTE_EXTRA_SPECS
+#define LINUX_GRTE_EXTRA_SPECS
+#endif
+
+#undef  SUBTARGET_EXTRA_SPECS
+#define SUBTARGET_EXTRA_SPECS \
+  LINUX_GRTE_EXTRA_SPECS
+
 /* Similar to standard Linux, but adding -ffast-math support.  */
 #undef  ENDFILE_SPEC
 #define ENDFILE_SPEC \
diff --git a/gcc/config/linux-grtev2.h b/gcc/config/linux-grtev2.h
new file mode 100644
index 000..29268fc
--- /dev/null
+++ b/gcc/config/linux-grtev2.h
@@ -0,0 +1,43 @@
+/* Definitions for Linux-based GRTE (Google RunTime Environment) version 2.
+   Copyright (C) 2009,2010,2011 Free Software Foundation, Inc.
+   Contributed by Chris Demetriou and Ollie Wild.
+
+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 3, 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.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+http://www.gnu.org/licenses/.  */
+
+/* Overrides LIB_SPEC from linux.h.  */
+#undef LIB_SPEC
+#define LIB_SPEC \
+  %{pthread:-lpthread} \
+   %{shared:-lc} \
+   %{!shared:%{mieee-fp:-lieee} %{profile:%(libc_p)}%{!profile:%(libc

Re: [lto][RFC] Do not emit hybrid object files

[Ollie Wild]

On Fri, Oct 17, 2008 at 12:32 PM, Diego Novillo [EMAIL PROTECTED] wrote:

 lto1 (even if -flto is not provided) and eventually we'll need to
 support archives in the reader.

Will we?  I thought one of the main justifications for implementing a
plugin architecture in the linker was to avoid having to do this in
collect2.

Not that unpacking an archive is particularly difficult. . .

Ollie

[lto] function to DECL associations for WPA repackaging

[Ollie Wild]

Doug,

Yesterday, we spoke briefly about the need to efficiently determine
the DECL's required by each function.  Here's a more detailed
overview.  During the WPA phase of WHOPR, we will be reading in a
collection of object files, performing analysis on call-graph/summary
data, and outputting repackaged object files.  This is described more
fully in the Repackaging section at
http://gcc.gnu.org/wiki/whopr/wpa.  During a first implementation, the
output files are likely to mirror the input files with inlinable
function bodies appended.  As our WPA implementation gets more
sophisticated, we will likely want to support more complex repackaging
schemes based on call-graph partitioning.

In either case, we need a way to efficiently determine which DECL's
must accompany a given set of function bodies.  DECL references are
currently stored as integral indexes within the serialized function
bodies.  These need to be reproduced elsewhere.  Right now, I'm
thinking the call-graph nodes are the best place for this.  Kenny
might have some suggestions on this front.

In the end, WPA should look something like this:

1) Read in call-graph nodes, DECL's, and summary data from the input files.
2) Do some analysis.  Partition the functions described in the call-graph nodes.
3) Scan each partition's call graph to determine which DECL's are needed.
4) Write each partition's function bodies, DECL's, and call-graph
nodes to an output file.

If you could work on the DECL association logic, that would be greatly
appreciated.

Ollie

[lto] What is lto_file_vtable for?

[Ollie Wild]

From what I can tell from grepping the lto source, the vtable entry in
lto_file is set but never used.  Is this old code that never got
removed or the beginning of an idea that never got implemented?

I'm inclined to remove it if it's not doing anything.

Ollie

Fwd: [whopr] Design/implementation alternatives for the driver and WPA

[Ollie Wild]

Reposting to the gcc list since my first email got bounced.

Ollie



On Tue, Jun 3, 2008 at 7:26 PM, Chris Lattner [EMAIL PROTECTED] wrote:

 This is a very interesting design, and a very nice evolution from the 
 previous proposal.  I'm not completely clear on the difference between LTO 
 and whopr here.  Is LTO the mode normal people will use, and whopr is the 
 mode where people with huge clusters will use?  Will LTO/whopr support 
 useful optimization on common multicore machines?

WHOPR is just an extension of the original LTO proposal.  It seeks to
augment the LTO design by providing a mechanism for parallelizing the
final (link-time) optimization phase.  The design has been based on a
distcc-like distributed compilation model, so it should be beneficial
even to those with small to moderate sized clusters.  This doesn't
preclude parallelization on multi-core machines (and that has been
discussed to some degree), but I at least have treated that as a
secondary consideration.  A good example of this is in the WPA
discussion below.  On a multicore machine, repackaging doesn't make a
lot of sense because the compiler can efficiently cherry-pick function
bodies from different files.  However, in a distcc compiler farm, the
entirety of a file must be transferred, so this would result in a lot
of excess network overhead.

 Are you focusing on inlining here as a specific example, or is this the only 
 planned IPA optimization that can use summaries?  It seems unfortunate to 
 design a system where inlining is the only real IPO transformation you can 
 do.  Does adding new interprocedural optimizations require adding whole new 
 phases?

The WPA document is a cleaned up transcription of an internal document
I wrote.  During the transcription, some context got lost.  It's not
meant to be a description of a final implementation but rather a
pro/con comparison between two possible draft implementations.  The
goal is to get some basic infrastructure in place so that we can start
experimenting with it and better parallelize additional work.
Inlining is chosen as an initial feature because it's relatively easy
to implement and can be (coarsely) handled without support for
serializing IPA summary information.  Other IPA passes (e.g.
inter-procedural constant propagation) require additional
serialization capabilities (which Kenneth Zadeck is working on now).

Ollie

Fwd: [whopr] Design/implementation alternatives for the driver and WPA

[Ollie Wild]

Reposting this as well.

Ollie


On Wed, Jun 4, 2008 at 9:14 AM, Chris Lattner [EMAIL PROTECTED] wrote:

 1) start with all code in memory and see how far you can get.  It seems that 
 on reasonable developer machines (e.g. 2GB memory) that we can handle C 
 programs on the order of a million lines of code, or C++ code on the order of 
 400K lines of code without a problem with LLVM.

This is essentially what the lto branch does today, and I don't see
any reason to disable this feature.  In the language of the WHOPR
design, the lto branch supports LGEN + LTRANS, with WPA bypassed
completely.  For implementing WPA, my intention is to add a new flag
(-fpartition or whatever else people think is suitable) to instruct
the lto1 front end to perform partitioning (aka repackaging) of .o
files, execute summary IPA analysese, and kick off a separate LTRANS
phase.

This gives us two modes of operation: one in which all object files
are loaded into memory and optimized using the full array of passes
available to GCC; and one which does some high-level analysis on the
whole program, partitions the program into smaller pieces, and does
more detailed analysis + grunt work on the smaller pieces.


 2) start leaving function bodies on disk, use lazily accesses, and a cache 
 manager to keep things in memory when needed.  I think this will let us scale 
 to tens or hundreds of million line code bases them.  I see no reason to take 
 a whopr approach just to be able to handle large programs.

In addition to memory consumption, there is also the question of time
consumption.  Alternative LTO implementations by HP, Intel, and others
follow this model and spend multiple hours optimizing even moderately
large programs.

Ollie

Re: [whopr] Design/implementation alternatives for the driver and WPA

[Ollie Wild]

On Wed, Jun 4, 2008 at 12:33 PM, Chris Lattner [EMAIL PROTECTED] wrote:

 Right, I understand that you design stacks on LTO.  It just seems strange
 to work on the advanced stuff before the basic GCC LTO stuff is close to
 being useful.

To some degree, we're scratching our own itch here.  Basic LTO doesn't
help us much.  Obviously, though, we want to implement this in a way
which is generally useful to the external community.  The scalability
techniques required to work with distcc are different from the
techniques which are useful on a single machine.

 I don't know anything about the implementation of the HP or Intel LTO
 implementation, but it sounds like there is much room for improvement there.
  With LLVM LTO, we see a compile-time slowdown on the order of 30-50% switch
 from O3 to O4, not an order of magnitude.  There is also still much room for
 improvement in the LLVM implementation of course.

I think we're working from different baselines.  We use distributed
techniques for compiling individual .o files.  With a tool like
distcc, you can get something on the order of 20x speedup.  Linking
becomes 20% or more of total execution time.  LTO *is* an order of
magnitude increase compared to a basic link operation.

Ollie

Re: Official GCC git repository

[Ollie Wild]

On Fri, Mar 14, 2008 at 1:44 PM, Stephen R. van den Berg [EMAIL PROTECTED] 
wrote:

 [svn]
noMetadata = true

This will prevent users from using the GCC git repository to bootstrap
their own local git-svn-aware repositories.  We definitely don't want
to do this.

Ollie

Re: Processor for header files.

[Ollie Wild]

On Feb 1, 2008 9:03 PM, James Courtier-Dutton [EMAIL PROTECTED] wrote:

 Can anyone point me to which part of the gcc source tree does the
 task, and also what format the data is stored in once processed.

The preprocessor is implemented by cpplib.  Take a look at the code in
libcpp as well as the C Preprocessor Internals manual at
http://gcc.gnu.org/onlinedocs/cppinternals.

Ollie

Re: [RFC] WHOPR - A whole program optimizer framework for GCC

[Ollie Wild]

On Dec 12, 2007 3:28 PM, Tim Josling [EMAIL PROTECTED] wrote:

 Do you have any thoughts on how this approach would be able to use
 profiling information, which is very a very powerful source of
 information for producing good optimisations?

The intent is for the WPA phase to utilize profile information, both
for making transformation decisions and for assigning call-graph edge
weights (which impacts partitioning and, hence, the local
optimizations available during LTRANS).  We've also discussed the
possibility of bypassing LTRANS altogether for portions of the
call-graph which profiling determines are insignificant.

 A few years back there were various suggestions about having files
 containing intermediate representations and this was criticised because
 it could make it possible for people for subvert the GPL by connecting
 to the optimisation phases via such an intermediate file. Arguably the
 language front end is then a different program and not covered by the
 GPL. It might be worth thinking about this aspect.

The lto branch is already doing this, so presumably that discussion
was resolved (Maybe someone in the know should pipe up.).  This
proposal aims to leverage (and augment) that work in progress.

 This also triggers the thought that if you have this intermediate
 representation, and it is somewhat robust to GCC patchlevels, you do not
 actually need source code of proprietary libraries to optimize into
 them. You only need the intermediate files, which may be easier to get
 than source code.

I believe a stable representation is an explicit non-goal of the LTO
project (Perhaps that was the resolution of the discussion above.).
It's an interesting idea, though.  Maybe this is something to revisit
once the representation has had a chance to stabilize.

Ollie

Re: [RFC] WHOPR - A whole program optimizer framework for GCC

[Ollie Wild]

On Dec 12, 2007 11:14 PM, Praveen Raghavan [EMAIL PROTECTED] wrote:

 1. Are there also plans to extend the global transformation
 capabilities. I see that the original set of global transformations is
 limited (rightfully so).

This is still at a very early design stage.  Additional
transformations could (and should) be added where they make sense.
The main constraints to consider are the time and memory requirements
of the WPA phase.  Since this is the only phase which can't be
parallelized, its scalability is paramount.

 2. Also any thoughts on how you keep the complete GIMPLE
 representation of millions of functions together? You would have some
 serious complexity issues inside the WPA engine?
 Or is it the idea that you start with the minimal information in the
 wpo1 file and if required read in the GIMPLE section?

You don't.  WPA is the only global phase, and it operates only on
summary data.  The actually reading of GIMPLE occurs in LTRANS, which
partitions the problem.  Depending on how large partitions need to be
before reasonable performance benefits are observed, it may be
necessary to allow LTRANS to swap functions in and out of memory.
That's still an open question.

 3. Is there a plan/schedule on when 'a' version of this would be out?

TBD.

Ollie

Re: Git and GCC

[Ollie Wild]

On Dec 5, 2007 11:08 AM, Daniel Berlin [EMAIL PROTECTED] wrote:
 So I tried a full history conversion using git-svn of the gcc
 repository (IE every trunk revision from 1-HEAD as of yesterday)
 The git-svn import was done using repacks every 1000 revisions.
 After it finished, I used git-gc --aggressive --prune.  Two hours
 later, it finished.
 The final size after this is 1.5 gig for all of the history of gcc for
 just trunk.

Out of curiosity, how much of that is the .git/svn directory?  This is
where git-svn-specific data is stored.  It is *very* inefficient, at
least for the 1.5.2.5 version I'm using.

Ollie

Re: Git and GCC

[Ollie Wild]

On Dec 5, 2007 1:40 PM, Daniel Berlin [EMAIL PROTECTED] wrote:

  Out of curiosity, how much of that is the .git/svn directory?  This is
  where git-svn-specific data is stored.  It is *very* inefficient, at
  least for the 1.5.2.5 version I'm using.
 

 I was only counting the space in .the packs dir.

In my personal client, which includes the entire history of GCC, the
packs dir is only 652MB.

Obviouisly, you're not a big fan of Git, and you're entitled to your
opinion.  I, however, find it very useful.  Given a choice between Git
and Mercurial, I choose git, but only because I have prior experience
working with the Linux kernel.  From what I've heard, both do the job
reasonably well.

Thanks to git-svn, using Git to develop GCC is practical with or
without explicit support from the GCC maintainers.  As I see it, the
main barrier is the inordinate amount of time it takes to bring up a
repository from scratch.  As has already been noted, Harvey has
provided a read-only copy, but it (a) only allows access to a subset
of GCC's branches and (b) doesn't provide a mechanism for developers
to push changes directly via git-svn.

This sounds like a homework project.  I'll do some investigation and
see if I can come up with a good bootstrap process.

Ollie

Re: Ada bootstrap broken

[Ollie Wild]

On 9/29/07, Eric Botcazou [EMAIL PROTECTED] wrote:

 Thanks, but this was not really necessary, Ada doesn't define
 LANG_HOOKS_EXPAND_CONSTANT, you only needed to restore lhd_return_tree.

Yes, but it was late, I had a toddler who needed putting to bed, and I
had no idea why I'd failed to notice that Ada hadn't built.

Seemed safer to just roll things back and sort it out later.

Ollie

Re: Ada bootstrap broken

[Ollie Wild]

On 9/28/07, John David Anglin [EMAIL PROTECTED] wrote:
 This change breaks Ada:

Sorry, folks.  I've rolled this back.

Ollie

libstdc++-v3/include/precompiled weirdness

[Ollie Wild]

I've recently noticed that every time I build GCC, the source files in
the libstdc++-v3/include/precompiled directory have their modification
timestamps updated.  Anyone know what's going on here?

Ollie

Re: Does g++ have a intel/msdn __COUNTER__ macro equivalent??

[Ollie Wild]

On 9/13/07, Tom Tromey [EMAIL PROTECTED] wrote:
  Ollie == Ollie Wild [EMAIL PROTECTED] writes:

 Ollie One quick question.  When I updated the gcc info page, Mark
 Ollie Mitchell felt strongly that it shouldn't mention distcc or
 Ollie ccache directly.  However, I think it's a good idea to give
 Ollie users some idea what the option is good for.  Is it appropriate
 Ollie to mention these applications in the release notes?

 I think it makes sense, but I wonder what Mark's objection was.

Mark, would you like to comment?

Ollie

Re: Does g++ have a intel/msdn __COUNTER__ macro equivalent??

[Ollie Wild]

On 9/13/07, Mark Mitchell [EMAIL PROTECTED] wrote:

 I wouldn't characterize my objections as terribly strong.  It's
 certainly nothing against distcc or ccache.  But, I think these kinds of
 mentions are odd to put in our documentation.  The manual should say
 what the options do.  Referencing specific tools, which may or may not
 continue to exist, etc., seems odd to me.  The manual is a reference
 text; this isn't reference information.

 In a tutorial, or in release notes, I have no objection.

Thanks, Mark.

Update sent to gcc-patches at
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01218.html.

Ollie

Re: Does g++ have a intel/msdn __COUNTER__ macro equivalent??

[Ollie Wild]

On 9/9/07, Gerald Pfeifer [EMAIL PROTECTED] wrote:
 Ollie, would you mind adding a snippet to htdocs/gcc-4.3/changes.html
 in the wwwdocs module of our CVS repository?  If you need any help with
 that, please let me know.

Sent to gcc-patches at
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01017.html.  Please
review.

Also, I recently added a new -fdirectives-only option which improves
distcc and ccache performance.  Does that merit a release note update
as well?

Ollie

Re: Does g++ have a intel/msdn __COUNTER__ macro equivalent??

[Ollie Wild]

On 9/11/07, Gerald Pfeifer [EMAIL PROTECTED] wrote:
 On Tue, 11 Sep 2007, Tom Tromey wrote:
  Also, I recently added a new -fdirectives-only option which improves
  distcc and ccache performance.  Does that merit a release note update
  as well?
  IMO, yes.

 Seconded. :-)

OK.  I'll add a blurb for -fdirectives-only as well.

One quick question.  When I updated the gcc info page, Mark Mitchell
felt strongly that it shouldn't mention distcc or ccache directly.
However, I think it's a good idea to give users some idea what the
option is good for.  Is it appropriate to mention these applications
in the release notes?

Ollie

Re: [RFC] Migrate pointers to members to the middle end

[Ollie Wild]

On 8/8/07, Daniel Berlin [EMAIL PROTECTED] wrote:
 I also haven't necessarily said what Ollie has proposed is a bad idea.
  I have simply said the way he has come up with what he proposed is
 not the way we should go about this.  It may turn out he has come up
 with exactly the representation we want (though I doubt this, for
 various reasons).The specification given also doesn't even explain
 where/how these operations can occur in GIMPLE, and what they do other
 than a C++ something something.

 Also given that someone already wrote a type-based devirtualizer that
 worked fine, and i don't see how a points-to one is much work, I'd
 like to see more justification for things like PTRMEM_PLUS_EXPR than
 hey, the C++ FE generates this internally.

OK.  It sounds like I need to go into a lot more detail.  The new
nodes I've proposed aren't actually motivated by the C++ front end,
but rather by a consideration of the semantics dictated by the C++
standard.  Naturally, this gives rise to some similarity, but for
instance, there is no PTRMEM_PLUS_EXPR in the C++ front end, and my
definition of PTRMEM_CST disagrees with the current node of the same
name.

Let's walk through them:


PTRMEM_TYPE

Contains the types of the member (TREE_TYPE) and class
(TYPE_PTRMEM_BASETYPE) of this pointer to member.  This is hopefully
self-explanatory.  In the language of the C++ standard, it is the type
of a pointer to member of class TYPE_PTRMEM_BASETYPE of type
TREE_TYPE.  This is the type of PTRMEM_CST's, PTRMEM_PLUS_EXPR's, and
various variable types (VAR_DECL, FIELD_DECL, PARM_DECL, etc.).


PTRMEM_CST

The C++ front end already has a PTRMEM_CST node.  However, the
existing node only contains a class (PTRMEM_CST_CLASS) and member
(PTRMEM_CST_MEMBER), and is unable to represent an arbitrary pointer
to member value.  This is especially evident when dealing with
multiple inheritance.  Consider the following example:

  struct B { int f (); };
  struct L : B {};
  struct R : B {};;
  struct D : L, R {};

  int (B::*pb)() = B::f;
  int (L::*pl)() = pb;
  int (R::*pr)() = pb;
  int (D::*pd[2])() = { pl, pr };

In this case, pd[0] and pd[1] both have the same type and point to the
same member of the same class (B::f), but they point to different base
class instances of B.  To represent this, we need an offset.  Now, one
might argue that rather than a numeric offset, we should point to the
_DECL of the base class subobject, but that breaks down because the
following is also legal:

  struct B {};
  struct D : B { int f (); };

  int (D::*pd)() = D::f;
  int (B::*pb)() = static_castint (B::*)()(pd);

In this case, pb points to D::f in the derived class.  Since there is
no subobject to point to, we see that a numeric offset representation
is required.

This leads to the definition of PTRMEM_CST which I have adopted.
Since the class type is already provided in its type, we store the
member (TREE_PTRMEM_CST_MEMBER) and numeric offset
(TREE_PTRMEM_CST_OFFSET).  The member is one of NULL (for NULL
pointers to members), a FIELD_DECL (for non-NULL pointers to data
members), or a FUNCTION_DECL (for non-NULL pointers to member
functions).  I've chosen the offset value according to convenience.
For NULL pointers to members, it's irrelevant.  For pointers to data
members, it's the offset of the member relative to the current class
(as determined by any type conversions).  For pointers to member
functions, it's the offset to the this pointer which must be passed to
the function.

PTRMEM_PLUS_EXPR

From the discussion above, it's clear that type conversions on
pointers to members require adjustments to the offsets (to fields or
this pointers).  We could handle this via CONVERT_EXPRs, but that has
two shortcomings: (1) it requires the middle end to compute offsets to
base class subobjects, and (2) as the first code example above
illustrates, multiple CONVERT_EXPRs cannot be folded together.  To
work around these issues, I've implemented the PTRMEM_PLUS_EXPR.  It's
a binary expression which takes two arguments, a PTRMEM_TYPE object,
and an integral offset expression.  These can be nicely constant
folded, either with other PTRMEM_PLUS_EXPRs or with PTRMEM_CSTs.

There's also an added benefit when dealing with NULL pointers to
members.  Consider the following code:

  struct B { int a; };
  struct L : B {};
  struct R : B {};;
  struct D : L, R {};

  int B::*pb = NULL;
  int L::*pl = pb;
  int R::*pr = pb;
  int D::*pd[2] = { pl, pr };

The C++ standard states that pd[0] == pd[1] since all NULL pointers to
members of the same type compare equal.  However, the current GCC
implementation gets this wrong because the C++ front end implements
pointer to data member via simple addition.  In practice, it needs to
check for NULL first.  However, folding stacked conversions then
requires optimizing code like:

  if (d != NULL_MARKER) d += offset1;
  if (d != NULL_MARKER) d += offset2;
  if (d != NULL_MARKER) d += offset3;

to

  if (d!= NULL_MARKER) d += 

Re: [RFC] Migrate pointers to members to the middle end

[Ollie Wild]

On 8/9/07, Mark Mitchell [EMAIL PROTECTED] wrote:
 Daniel Berlin wrote:

  This is the source of my current woes, as this may involve virtual
  function resolution, which can't be done with the information
  currently available to the middle end.

 Ollie, IIRC, you posted an example where, together with your front-end
 lowering patch (i.e., with the strategy that Daniel is advocating), we
 don't do some optimization that we could in theory do.  Have you worked
 out why not?  Perhaps that would shed some light on whether or not it's
 tractable to recover this information from our current IR.

The example I posted before indicated that the check to determine
whether or not the member function is virtual wasn't optimized out.
It didn't know that (fn_ptr  1) == 0.  That should be easy to fix by
incorporating pointer alignment requirements in fold_binary().

Offhand, I don't remember what happened with the various other cases,
but my testing at the time wasn't particularly thorough.  The feedback
I've gotten so far seems overwhelmingly negative, so I think the next
step is to revisit the lowering approach, exercise the hell out of it,
and see what, if any, limitations pop up.

Daniel mentioned something about a pre-existing type-based
devirtualizer.  I'd be interested to see how it works.  From what I've
been able to gleam from the GCC code, it seems that such an approach
would need to hook back into the front end, which is a showstopper
from an LTO perspective.  It's entirely possible that I'm missing
something, though.

Ollie

Re: [RFC] Migrate pointers to members to the middle end

[Ollie Wild]

On 8/8/07, Michael Matz [EMAIL PROTECTED] wrote:
 So those tree expressions would live throughout the middle-end and only
 then become lowered to RTL directly?  I'm not sure that's worthwhile.
 E.g. I'm not sure why there's a need to really get rid of the
 expand_constant langhook.  It's only important that it isn't called too
 late, i.e. ideally during gimplification.  It seems it only makes use of
 type information which should be available at that time, so if it
 currently is called too late (interfering with LTO in the future) it
 should be possible to move it earlier.

You're correct.  It is possible to remove the expand_constant language
hook without supporting pointers to members in the middle end.  In
fact, I submitted such a patch back in March
(http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01819.html).  The
various follow-up emails illustrate some of the reasons why migrating
pointers to members to the middle end is a good thing (at least for
C++).

It would have been more accurate for me to describe the language hooks
removal as a jumping off point.  Strictly speaking, the middle end
migration is only necessary for language hook removal if the C++
maintainers won't approve my patch.  :)

That said, I think there is real value in moving pointers to members
to the middle end.  Keep reading.

 I have a conceptual problem with moving pointer to members into the
 middle-end: my mental model of what the middle-end should be concerned
 about is complete expressions/constants/types, like adding two numbers,
 accessing an integer two words away from that address (i.e. you see I
 already sort of decompose structures in my mental model).  Pointers to
 members is a very different beast: they can't be accessed without a real
 object, yet they can be stored into objects themself (sort of an
 incomplete memory reference).  If anything they simply resemble offsets
 (perhaps variable ones), so you might perhaps model them as such.
 Conversions between them sometimes requires adjustments to 'this',
 resulting in real operations (the delta field of the struct, how pointer
 to member values are currently modelled).  IMHO it would be wrong if we
 wouldn't make those adjustments explicit in the middle end.

I think the primary purpose of the middle end is to provide a
representation which captures the semantics of a program at a
sufficiently high level to enable efficient optimization.  COMPLEX_CST
and COMPLEX_TYPE are a good example.  In theory, the middle end has
enough information to optimize complex arithmetic based solely on the
constituent operations on real and imaginary components, but it's
easier to deal with the complex number as an atomic unit.

Similarly, consider the following code fragment:

  struct S { virtual void f(); };
  typedef void (S::*P)(void);
  const P p = S::f, NULL;
 void g(S s) {
   (s.*p)();
 }

GCC should be able to optimize g() to call s.S::f() directly.  In
theory, it can optimize out the null pointer to member check, the
virtual bit check, and the vtable lookup, but that's a lot of work.
Right now, GCC can't do it.

 So, why do you think you need the PTRMEM_TYPE in the middle end?  And why
 the PTRMEM_CST (i.e. why couldn't it be lowered to some explicit constant
 during gimplificaton)?  Same for PTRMEM_PLUS_EXPR, why is (PTR_)PLUS_EXPR
 not enough, if the semantic is only to add the integer argument to the
 pointer argument (is that even an operation which can be done to pointers
 to members?)?  Also PTRMEM_REF seems to equivalent to a normal
 COMPONENT_REF, just that the second operand is a funny offset
 specification instead of a simple field decl.

The implementation is certainly negotiable.  That's part of why I sent
out this email.

For pointers to data members, PTRMEM_CST doesn't give much information
that isn't already provided by integers of OFFSET_TYPE (It does
explicitly indicate NULL pointers to members, which offsets do not.
In fact, GCC currently handles NULL pointer to member casts
incorrectly, as it fails to preserve NULLs).  However, for pointers to
member functions, it bypasses the need to decode an
architecture-dependent virtual bit, and replaces the virtual function
offset with FUNCTION_DECL, which means we don't need to decode vtable
lookups in order to inline function calls.

PTRMEM_PLUS_EXPR is supposed to represent casts (CAST_EXPR didn't seem
appropriate, but I could be convinced otherwise).  It expands to a
conditional which propagates NULL or increments the offset.  I don't
think PTR_PLUS_EXPR checks for NULL, and it's designed to increment
pointers.  A pointer to data member expands to an offset, and a
pointer to member function expands to a fairly complex structure.  In
fact, for some architectures, the offset field is shifted, so
PTRMEM_PLUS_EXPR (p, 1), would actually have to add 2 to the offset.

Take a look at the expand_ptrmemfunc_cst() and build_ptrmemfunc1()
calls inside cplus_expand_constant().  Now reverse that to see the
amount of work that 

[RFC] Migrate pointers to members to the middle end

[Ollie Wild]

Hi,

In response to a suggestion from Mark Mitchell, I've been attempting
to migrate pointers to members to the GCC middle end.  The goal of
this is twofold: (a) to enable conversion of pointer to member
dereferences to direct function calls and member accesses when
analysis determines this is unambiguous and (b) to obsolete the need
for the expand_constant language hook.

Under my current approach, I've added the following new nodes to gcc/tree.def:

  /* A C++ pointer-to-member type.
 The TREE_TYPE field is the member type.
 The TYPE_PTRMEM_BASETYPE points to the node for the class to which the
 member belongs.  */
  DEFTREECODE (PTRMEM_TYPE, ptrmem_type, tcc_type, 0)

  /* A pointer-to-member constant.
 TREE_PTRMEM_CST_MEMBER is the _DECL for the member.
 TREE_PTRMEM_CST_OFFSET takes on different interpretations depending on
 the type of the member.  If the member is NULL, it is ignored.  If the
 member is a FIELD_DECL it refers to the field offset.  Otherwise, it refers
 to the offset of the this pointer passed to methods.  */
  DEFTREECODE (PTRMEM_CST, ptrmem_cst, tcc_constant, 0)

  /* Pointer to member addition.  This is used in type conversions to adjust the
 pointer to member offset.  The first operand is a pointer to
member, and the
 second operand is an integer of type sizetype.  */
  DEFTREECODE (PTRMEM_PLUS_EXPR, ptrmem_plus_expr, tcc_binary, 2)

  /* A C++ pointer-to-member dereference.
 Operand 0 is a class expression.
 Operand 1 is a pointer-to-member.  */
  DEFTREECODE (PTRMEM_REF, ptrmem_ref, tcc_reference, 2)

I then modify the C++ front end to instantiate the new nodes, expand
them inside expand_expr_real_1 and output_constant, and perform
folding in the various fold-const functions.

However, pointers to virtual functions are turning out to be
problematic.  As far I can tell, the middle end has no concept of
virtual functions and virtual function tables: they appear to be
implemented solely in the C++ front end.  This suggests that a
migration of the virtual function machinery is a necessary
precondition to pointer to member migration.

Some questions for the GCC community:

1.  Is pointer to member migration worthwhile?  Can other languages
besides C++ benefit from this?

2.  Do the tree nodes I've discussed make sense?  Is there a better
way to represent pointer to member objects and operations?

3.  What can I do to handle virtual functions?  Is it possible to
handle this without migrating virtual functions to the middle end?

4.  Is a migration of virtual functions and virtual function tables
required?  Are the various language implementations sufficiently
similar to be handled by a common infrastructure?

Any and all feedback is appreciated.

Thanks,
Ollie

Re: Writing to Subversion via Git

[Ollie Wild]

On 7/3/07, Bernardo Innocenti [EMAIL PROTECTED] wrote:

Ollie Wild wrote:
 As an aside to the ongoing git repository discussion, I'm curious if
 anyone has experimented with committing changes to the GCC repository
 via git-svn's dcommit command.  I'm curious to know if it plays nicely
 with GCC's svn commit machinery.

It should.  git-svn is bidirectional.


My main concern is with whether or not git-svn preserves proper
formatting of change descriptions.  For instance, all the imported
changes have the tabs removed.  I know there are a number of scripts
which do things like update Bugzilla based on the descriptions.  I
just want to make sure git-svn won't break them and/or annoy the heck
out of other developers who are trying to view the logs via svn.

Ollie

Writing to Subversion via Git

[Ollie Wild]

As an aside to the ongoing git repository discussion, I'm curious if
anyone has experimented with committing changes to the GCC repository
via git-svn's dcommit command.  I'm curious to know if it plays nicely
with GCC's svn commit machinery.

Ollie

Re: Very Fast: Directly Coded Lexical Analyzer

[Ollie Wild]

On 5/31/07, Joseph S. Myers [EMAIL PROTECTED] wrote:

Zack had some ideas a few years ago (I don't think they were ever posted
to a public list) about how to speed up _cpp_clean_line in particular, and
some or all of translation phases 1 to 3 in general.  The idea is that you
have several Mealy machines (state machines where all the work happens in
transitions), where edges apply for a given set of input characters in a
given state and describe the actions to be taken in that case.  Actions
include both passing output to another machine, and emitting diagnostics.
So you start with converting character sets to UTF-8, then strip trailing
whitespace and canonicalise newlines, then convert trigraphs, then remove
backslash-newline pairs, then strip comments, then split the file into
preprocessing tokens.


This is an interesting idea.  I spent some time around the beginning
of the year trying to optimize the preprocessor to improve distcc
performance.  I've got some baseline oprofile results available at
http://docs.google.com/Doc?id=ddn4ddq4_34fsdqhv.  This is taken with a
Google modified version of gcc-4.1.1, so your mileage may vary.  It
shows that _cpp_lex_direct, _cpp_clean_line, and lex_identifier
collectively account for about 35% of preprocessing time.

I tried to improve performance without substantial changes to
functionality, but was only able to grab a few percentage points here
and there.  Ultimately, I implemented an optimized directives-only
preprocessor, which implements the bare minimum preprocessing required
to correctly implement include directives.  It gives about a 30%
decrease in preprocessor time.  The patch is available at
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg02178.html with an
updated summary at
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00786.html.  It's still
pending review at this time.

For comparison, the preprocessor in gcc-2.95 operates in about 1/3rd
the time of the preprocessor in gcc-4.1.1 (regardless of whether or
not traditional mode is used).  A good chunk of that time, though,
seems to be spent in the long tail of routines which consume
sub-percentage quantities of time.

Ollie

Re: Mercurial repository set up for GCC that mirrors SVN

[Ollie Wild]

Just another data point, my git-svn clone of trunk comes in at 414MB,
excluding the size of checked out files.  I'm assuming the public svn
is the complete history.


I'm about 35% through the process of cloning the entire gcc repository
via git-svnimport, and the .git directory is 5.0GB.  This includes all
branches.

Danny, which of these matches what you've done with mercurial?

Ollie

Re: Mercurial repository set up for GCC that mirrors SVN

[Ollie Wild]

git-svnimport will not pack incrementally as it runs, so it might get
pretty large.  git-svn offers and incremental repack every x commits
(I chose 1000) and that did wonders for the import time for me.
Otherwise it will create a huge number of files before the final pack.


FYI, doing a repack brought the size down from 5.0GB to 266MB.  Aside
from the question of whether or not it's wise to require users to
manually pack their repositories, it looks like the git tree is going
to be about 750MB, which brings it more or less on par with mercurial.

I'm keen to play around with mercurial a bit.  Danny, when is your
repository going to be publicly available?

Ollie

Re: GCC mini-summit - compiling for a particular architecture

[Ollie Wild]

Related to this: have you guys ever considered to making the -On
flags dependent on the architecture?


It came up in a few side conversations.  As I understand it, RMS has
decreed that the -On optimizations shall be architecture independent.
That said, there are generic optimizations which really only apply
to a single architecture, so there is some precedent for bending this
rule.

There were also suggestions of making the order of optimizations
command line configurable and allowing dynamically loaded libraries to
register new passes.

Ollie