Re: [testsuite] Don't xfail gcc.dg/binop-xor1.c

[Richard Sandiford]

Hans-Peter Nilsson  writes:
> On Fri, 14 Feb 2014, Jakub Jelinek wrote:
>> On Fri, Feb 14, 2014 at 10:37:03AM -0700, Jeff Law wrote:
>> > On 02/13/14 03:54, Richard Sandiford wrote:
>> > >Richard Sandiford  writes:
>> > >>Hans-Peter Nilsson  writes:
>> > >>>On Tue, 4 Feb 2014, Rainer Orth wrote:
>> > AFAICT the gcc.dg/binop-xor1.c test is XPASSing everywhere since about
>> > 20131114:
>> > >>>
>> > >>>Bah, missing analysis. "Everywhere" does not include cris-elf,
>> > >>>powerpc64-unknown-linux-gnu, m68k-unknown-linux-gnu,
>> > >>>s390x-ibm-linux-gnu, powerpc-ibm-aix7.1.0.0.
>> > >>
>> > >>Based on this list I'm guessing it's another BRANCH_COST==1
>> > >
>> > >BRANCH_COST==1 || !LOGICAL_OP_NON_SHORT_CIRCUIT
>> > ISTM that we ought to have a dejagnu test which we can use to ignore
>> > or otherwise change the expected output on these targets.
>> >
>> > We could try and be clever and determine it from compiler output, or
>> > somehow arrange for GCC to make that information available to
>> > dejagnu. But by far the easiest way is just a list of targets.
>>
>> Yeah, the BRANCH_COST and/or LOGICAL_OP_NON_SHORT_CIRCUIT value could e.g.
>> be emitted in some comment in selected tree dump if details are requested 
>> (say
>> -fdump-tree-gimple-details) and then an effective target can check for that
>> easily.
>
> I've been thinking along those lines (though a RTL dump will be
> somewhat more appropriate).  A target list will be insufficient
> when the branch cost etc. depends on compiler options.

Or I suppose we could add some predefined macros (perhaps again only
if a particular option is selected).

But I don't have a problem with a list of targets either.  It's certainly
good enough for LOGICAL_OP_NON_SHORT_CIRCUIT on MIPS, which is always 0.
So this patch just moves the !LOGICAL_OP_NON_SHORT_CIRCUIT target lists
to a logical_op_short_circuit target, as H-P suggested.

In the case of avr*-*-* the !LOGICAL_OP_NON_SHORT_CIRCUIT comes from
BRANCH_COST being 0 while for arc*-*-* and arm_cortex_m it comes
from an explicit back-end definition.

I marked binop-xor1.c as an XFAIL rather than a skip because using ^
might be an improvement even for logical_op_short_circuit.

I didn't do anything about the branch cost since this is enough for MIPS.

Tested on x86_64-linux-gnu (including checking that the tests were still
being run) and mipsisa64-sde-elf.  OK to install?

Thanks,
Richard


gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_logical_op_short_circuit): New procedure.
* gcc.dg/binop-xor1.c: XFAIL for logical_op_short_circuit.
* gcc.dg/tree-ssa/forwprop-28.c: Use logical_op_short_circuit
instead of mips*-*-*, arc*-*-*, avr*-*-* and arm_cortex_m tests.
* gcc.dg/tree-ssa/vrp47.c: Likewise.
* gcc.dg/tree-ssa/vrp87.c: Likewise.
* gcc.dg/tree-ssa/ssa-dom-thread-4.c: Likewise.  Also use
logical_op_short_circuit for the alternative test, extending
it to arm_cortex_m.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   2014-02-15 17:51:13.001741846 
+
+++ gcc/testsuite/lib/target-supports.exp   2014-02-15 18:02:30.053843150 
+
@@ -5690,6 +5690,18 @@ proc check_effective_target_fenv_excepti
 } "-std=gnu99"]
 }
 
+# Return 1 if LOGICAL_OP_NON_SHORT_CIRCUIT is set to 0 for the current target.
+
+proc check_effective_target_logical_op_short_circuit {} {
+if { [istarget mips*-*-*]
+|| [istarget arc*-*-*]
+|| [istarget avr*-*-*]
+|| [check_effective_target_arm_cortex_m] } {
+   return 1
+}
+return 0
+}
+
 # Record that dg-final test TEST requires convential compilation.
 
 proc force_conventional_output_for { test } {
Index: gcc/testsuite/gcc.dg/binop-xor1.c
===
--- gcc/testsuite/gcc.dg/binop-xor1.c   2014-02-15 17:51:12.970741566 +
+++ gcc/testsuite/gcc.dg/binop-xor1.c   2014-02-15 17:51:13.439745797 +
@@ -7,5 +7,5 @@ foo (int a, int b, int c)
   return ((a && !b && c) || (!a && b && c));
 }
 
-/* { dg-final { scan-tree-dump-times "\\\^" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "\\\^" 1 "optimized" { xfail 
logical_op_short_circuit } } } */
 /* { dg-final { cleanup-tree-dump "optimized" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c 2014-02-15 17:51:12.984741692 
+
+++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-28.c 2014-02-15 18:00:44.562893555 
+
@@ -1,9 +1,7 @@
-/* { dg-do compile { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-* 
v850*-*-* picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* 
powerpc*-*-* xtensa*-*-* arc*-*-* hppa*-*-* mips*-*-*"} } } */
+/* Setting LOGICAL_OP_NON_SHORT_CIRCUIT to 0 leads to two conditio

New Swedish PO file for 'gcc' (version 4.9-b20140202)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-4.9-b20140202.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [testsuite] Don't xfail gcc.dg/binop-xor1.c

[Mike Stump]

On Feb 16, 2014, at 2:34 AM, Richard Sandiford  
wrote:
> OK to install?

Ok.

Re: [PATCH] Fixing SEH exceptions for languages != C++

[Mike Stump]

On Feb 15, 2014, at 9:27 AM, Jonathan Schleifer  wrote:
> The following patch fixes a bug in SEH exception handling that made it
> crash with ObjC

>From an ObjC perspective, I’m fine with the work; though, an seh person needs 
>to weigh in.  I’m fine with the back port as well.

[PATCH, rs6000] Fix powerpc64le-linux bootstrap failure with -mcpu=power8

[Bill Schmidt]

Hi,

Now that I have Power8 hardware to test on, I've discovered that I
introduced a problem with
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01547.html that causes a
bootstrap failure when specifying -mcpu=power8.  I moved some logic from
rs6000_expand_vec_perm_const_1 into vsx_xxpermdi2__1.  I failed to
notice there is another path into vsx_xxpermdi2__1 that is
exercised during the bootstrap.

To avoid the problem, this patch adjusts the code generated along this
other path so that the later transformation will be correct.

Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu configured
both with -mcpu=power7 and with -mcpu=power8 with no regressions.  The
Power8 LE bootstrap now completes cleanly.  Is this ok for trunk?

Thanks,
Bill


2014-02-16  Bill Schmidt  

* config/rs6000/vsx.md (vsx_xxpermdi_): Handle little
endian targets.


Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 207809)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -1621,7 +1621,18 @@
  op1 = gen_lowpart (V2DImode, op1);
}
 }
-  emit_insn (gen (target, op0, op1, perm0, perm1));
+  /* In little endian mode, vsx_xxpermdi2__1 will perform a
+ transformation we don't want; it is necessary for
+ rs6000_expand_vec_perm_const_1 but not for this use.  So we
+ prepare for that by reversing the transformation here.  */
+  if (BYTES_BIG_ENDIAN)
+emit_insn (gen (target, op0, op1, perm0, perm1));
+  else
+{
+  rtx p0 = GEN_INT (3 - INTVAL (perm1));
+  rtx p1 = GEN_INT (3 - INTVAL (perm0));
+  emit_insn (gen (target, op1, op0, p0, p1));
+}
   DONE;
 })
 

[PATCH, rs6000] Provide little-endian support for vmrgew and vmrgow

[Bill Schmidt]

Hi,

With -mcpu=power8, we see two test cases (gcc.dg/vect/slp-perm-2.c and
gcc.dg/vect/slp-perm-5.c) regress for powerpc64le-linux.  GCC makes use
of some new Power8 instructions (vmrgew and vmrgow) which need
adjustment for little endian targets.  As with merge-high and merge-low,
we need to reverse the order of the input vectors and reverse the use of
the "odd" and "even" instructions (since the change in element ordering
changes which elements are odd and which are even).

Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
regressions.  The failing tests now run to completion.  Is this ok for
trunk?

Thanks,
Bill


2014-02-16  Bill Schmidt  

* config/rs6000/altivec.md (p8_vmrgew): Handle little endian
targets.
(p8_vmrgow): Likewise.



Index: gcc/config/rs6000/altivec.md
===
--- gcc/config/rs6000/altivec.md(revision 207809)
+++ gcc/config/rs6000/altivec.md(working copy)
@@ -1234,7 +1234,12 @@
  (parallel [(const_int 0) (const_int 4)
 (const_int 2) (const_int 6)])))]
   "TARGET_P8_VECTOR"
-  "vmrgew %0,%1,%2"
+{
+  if (BYTES_BIG_ENDIAN)
+return "vmrgew %0,%1,%2";
+  else
+return "vmrgow %0,%2,%1";
+}
   [(set_attr "type" "vecperm")])
 
 (define_insn "p8_vmrgow"
@@ -1246,7 +1251,12 @@
  (parallel [(const_int 1) (const_int 5)
 (const_int 3) (const_int 7)])))]
   "TARGET_P8_VECTOR"
-  "vmrgow %0,%1,%2"
+{
+  if (BYTES_BIG_ENDIAN)
+return "vmrgow %0,%1,%2";
+  else
+return "vmrgew %0,%2,%1";
+}
   [(set_attr "type" "vecperm")])
 
 (define_expand "vec_widen_umult_even_v16qi"

Re: [PATCH] [libgomp] make it possible to use OMP on both sides of a fork

[Nathaniel Smith]

On Fri, Feb 14, 2014 at 3:14 PM, Richard Henderson  wrote:
> On 02/14/2014 12:21 AM, Jakub Jelinek wrote:
>>> Any reason not to just run gomp_free_thread_pool from 
>>> gomp_after_fork_callback
>>> directly?  I see no restrictions on what kind of code is allowed to execute
>>> during that callback.
>>
>> Well, fork is async signal safe function, so calling malloc/free, or any
>> kind of synchronization primitives is completely unsafe there.
>
> That's as may be, but even the opengroup's rationale for pthread_atfork
> mentions using locks in the three callbacks.  I strongly suspect that no real
> use of pthread_atfork can ever really be async safe.

Yes, but the problem is that depending on what the user intends to do
after forking, our pthread_atfork handler might help or it might hurt,
and we don't know which. Consider these two cases:
  - fork+exec
  - fork+continue to use OMP in child
The former case is totally POSIX-legal, even when performed at
arbitrary places, even when another thread is, say, in the middle of
calling malloc(). If we register a pthread_atfork handler which calls
non-signal-safe functions, then we risk breaking POSIX-legal programs
like this. The latter case is broken in current GOMP, but we would
like it to work as well -- at least when possible. So the way the
patch is structured the way it is, is to ensure that we have minimal
impact on the former case while still giving the latter case a chance
to succeed.

Updated patch addressing your other comments attached.

2014-02-12  Nathaniel J. Smith  

* team.c (gomp_free_pool_helper): Move per-thread cleanup to main
thread.
(gomp_free_thread): Delegate implementation to...
(gomp_free_thread_pool): ...this new function. Like old
gomp_free_thread, but does per-thread cleanup, and has option to
skip everything that involves interacting with actual threads,
which is useful when called after fork.
(gomp_after_fork_callback): New function.
(gomp_team_start): Register atfork handler, and check for fork on
entry.

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
Index: team.c
===
--- team.c  (revision 207398)
+++ team.c  (working copy)
@@ -28,6 +28,7 @@
 #include "libgomp.h"
 #include 
 #include 
+#include 
 
 /* This attribute contains PTHREAD_CREATE_DETACHED.  */
 pthread_attr_t gomp_thread_attr;
@@ -43,6 +44,8 @@ __thread struct gomp_thread gomp_tls_data;
 pthread_key_t gomp_tls_key;
 #endif
 
+/* This is to enable best-effort cleanup after fork.  */
+static bool gomp_we_are_forked;
 
 /* This structure is used to communicate across pthread_create.  */
 
@@ -204,42 +207,41 @@ static struct gomp_thread_pool *gomp_new_thread_po
   return pool;
 }
 
+/* Free a thread pool and release its threads. */
+
 static void
 gomp_free_pool_helper (void *thread_pool)
 {
-  struct gomp_thread *thr = gomp_thread ();
   struct gomp_thread_pool *pool
 = (struct gomp_thread_pool *) thread_pool;
   gomp_barrier_wait_last (&pool->threads_dock);
-  gomp_sem_destroy (&thr->release);
-  thr->thread_pool = NULL;
-  thr->task = NULL;
   pthread_exit (NULL);
 }
 
-/* Free a thread pool and release its threads. */
-
-void
-gomp_free_thread (void *arg __attribute__((unused)))
+static void
+gomp_free_thread_pool (bool threads_are_running)
 {
   struct gomp_thread *thr = gomp_thread ();
   struct gomp_thread_pool *pool = thr->thread_pool;
   if (pool)
 {
+  int i;
   if (pool->threads_used > 0)
{
- int i;
- for (i = 1; i < pool->threads_used; i++)
+ if (threads_are_running)
{
- struct gomp_thread *nthr = pool->threads[i];
- nthr->fn = gomp_free_pool_helper;
- nthr->data = pool;
+ for (i = 1; i < pool->threads_used; i++)
+   {
+ struct gomp_thread *nthr = pool->threads[i];
+ nthr->fn = gomp_free_pool_helper;
+ nthr->data = pool;
+   }
+ /* This barrier undocks threads docked on pool->threads_dock.  */
+ gomp_barrier_wait (&pool->threads_dock);
+ /* And this waits till all threads have called
+gomp_barrier_wait_last in gomp_free_pool_helper.  */
+ gomp_barrier_wait (&pool->threads_dock);
}
- /* This barrier undocks threads docked on pool->threads_dock.  */
- gomp_barrier_wait (&pool->threads_dock);
- /* And this waits till all threads have called gomp_barrier_wait_last
-in gomp_free_pool_helper.  */
- gomp_barrier_wait (&pool->threads_dock);
  /* Now it is safe to destroy the barrier and free the pool.  */
  gomp_barrier_destroy (&pool->threads_dock);
 
@@ -251,6 +253,14 @@ gomp_free_pool_helper (void *thread_pool)
  gomp_managed_threads -= pool->threads_used - 1L;
  gomp_mutex_unlo

Re: [PATCH, rs6000] Fix powerpc64le-linux bootstrap failure with -mcpu=power8

[David Edelsohn]

On Sun, Feb 16, 2014 at 11:18 AM, Bill Schmidt
 wrote:
> Hi,
>
> Now that I have Power8 hardware to test on, I've discovered that I
> introduced a problem with
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01547.html that causes a
> bootstrap failure when specifying -mcpu=power8.  I moved some logic from
> rs6000_expand_vec_perm_const_1 into vsx_xxpermdi2__1.  I failed to
> notice there is another path into vsx_xxpermdi2__1 that is
> exercised during the bootstrap.
>
> To avoid the problem, this patch adjusts the code generated along this
> other path so that the later transformation will be correct.
>
> Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu configured
> both with -mcpu=power7 and with -mcpu=power8 with no regressions.  The
> Power8 LE bootstrap now completes cleanly.  Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> 2014-02-16  Bill Schmidt  
>
> * config/rs6000/vsx.md (vsx_xxpermdi_): Handle little
> endian targets.

I'm not really thrilled with the need to reverse the operands twice, but okay.

Thanks, David

Re: [PATCH, rs6000] Provide little-endian support for vmrgew and vmrgow

[David Edelsohn]

On Sun, Feb 16, 2014 at 12:19 PM, Bill Schmidt
 wrote:
> Hi,
>
> With -mcpu=power8, we see two test cases (gcc.dg/vect/slp-perm-2.c and
> gcc.dg/vect/slp-perm-5.c) regress for powerpc64le-linux.  GCC makes use
> of some new Power8 instructions (vmrgew and vmrgow) which need
> adjustment for little endian targets.  As with merge-high and merge-low,
> we need to reverse the order of the input vectors and reverse the use of
> the "odd" and "even" instructions (since the change in element ordering
> changes which elements are odd and which are even).
>
> Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
> regressions.  The failing tests now run to completion.  Is this ok for
> trunk?
>
> Thanks,
> Bill
>
>
> 2014-02-16  Bill Schmidt  
>
> * config/rs6000/altivec.md (p8_vmrgew): Handle little endian
> targets.
> (p8_vmrgow): Likewise.

Okay.

Thanks, David

[Patch, Fortran, Regression] PR 55907: ICE with -fno-automatic -finit-local-zero

[Janus Weil]

Hi all,

here is a small patch for a ICE-on-valid regression. Regtested on
x86_64-unknown-linux-gnu. Ok for trunk/4.8/4.7?

Cheers,
Janus


2014-02-16  Janus Weil  

PR fortran/55907
* resolve.c (build_default_init_expr): Don't initialize character
variable if -fno-automatic is given.


2014-02-16  Janus Weil  

PR fortran/55907
* gfortran.dg/init_flag_12.f90: New.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 207804)
+++ gcc/fortran/resolve.c   (working copy)
@@ -10530,7 +10530,7 @@ build_default_init_expr (gfc_symbol *sym)
  init_expr = NULL;
}
   if (!init_expr && gfc_option.flag_init_character == GFC_INIT_CHARACTER_ON
- && sym->ts.u.cl->length)
+ && sym->ts.u.cl->length && gfc_option.flag_max_stack_var_size != 0)
{
  gfc_actual_arglist *arg;
  init_expr = gfc_get_expr ();
! { dg-do compile }
! { dg-options "-fno-automatic -finit-local-zero" }
!
! PR 55907: [4.7/4.8/4.9 Regression] ICE with -fno-automatic -finit-local-zero
!
! Contributed by J.R. Garcia 

subroutine cchaine (i)
  implicit none
  integer :: i
  character(len=i) :: chaine
  write(*,*) chaine
end subroutine 

Re: [PATCH] [libgomp] make it possible to use OMP on both sides of a fork

[Nathaniel Smith]

On Fri, Feb 14, 2014 at 3:43 AM, Jakub Jelinek  wrote:
> On Fri, Feb 14, 2014 at 09:21:24AM +0100, Jakub Jelinek wrote:
>> Well, fork is async signal safe function, so calling malloc/free, or any
>> kind of synchronization primitives is completely unsafe there.
>>
>> The only safe thing could be to atomically or in some global flag (or set
>> some TLS flag?) and deal with the freeing next time you encounter omp
>> parallel.  But, the state of the old thread pool may be in some inconsistent
>> shape.
>
> BTW, I think far cleaner solution would be to discuss on Omp-lang and add
> some standard omp_* function which would allow to throw away all the cached
> OpenMP threads, after calling that function one could not assume
> threadprivate vars (other than in the initial thread) preserve their values.
> If this function would be only allowed outside of the parallel region (i.e.
> if omp_in_parallel () == 0, or even just if omp_get_level () == 0) and
> pretend to do
> #pragma omp parallel num_threads (1)
> ;
> i.e. something after which it isn't guaranteed to preserve threadprivate
> vars, then the library could perform this at the point where it is safe to
> do so (of course it wouldn't be async-signal-safe function) and isn't a
> performance issue (calling it when you are expecting to soon launch another
> #pragma omp parallel could of course slow things down a lot).
>
> Anything else is going to be either unsafe, or leak memory.

I think the core problem here is that it's not possible to "hide" OMP
usage inside an interface boundary, so you can't reliably compose
larger programs out of pieces that individually may or may not use
OMP. And unfortunately, I don't think your proposed
omp_forget_threadprivates() function helps solve that problem.

Like, consider the case of DGEMM implemented using OMP. Right now,
this means that calling DGEMM will break fork(). If DGEMM instead
called omp_forget_threadprivates(), then fork() would work. BUT, the
program might contain other code -- perhaps in a different library --
which also used threadprivates. And every time someone calls DGEMM,
this other code would find that their threadprivates had mysteriously
disappeared. (Or might find this, depending on whether fork() was
called in between, etc.) Whether it would be safe to call
omp_forget_threadprivates() is a global property of the whole program,
not something that can be determined by looking at any one piece in
isolation.

What *would* work is if GOMP started tracking whether there were any
threadprivate variables in existence. Then it would be possible to
dynamically determine at runtime whether this global property held,
and automatically clean up threads at pre-fork-time iff it was
globally safe to do so. Then we could document that *if* you want to
use OMP inside a composable library, then you have to avoid
threadprivates, and everything would just work. (In this particular
case, it is true that OpenBLAS already doesn't use any
threadprivates...)

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

RE: [Patch, testsuite]: Allow MicroBlaze .weakext pattern in regex match

[David Holsgrove]

Hi Mike,

> -Original Message-
> From: Mike Stump [mailto:mikest...@comcast.net]
> Sent: Friday, 14 February 2014 6:01 pm
> To: David Holsgrove
> Cc: gcc-patches@gcc.gnu.org; Michael Eager (ea...@eagerm.com); Vidhumouli
> Hunsigida; Nagaraju Mekala; John Williams; Edgar Iglesias
> Subject: Re: [Patch, testsuite]: Allow MicroBlaze .weakext pattern in regex 
> match
> 
> On Feb 13, 2014, at 10:07 PM, David Holsgrove 
> wrote:
> > I've attached a patch to extend the regex pattern to include optional 'ext' 
> > at the
> end of
> > '.weak' to match the MicroBlaze weak label '.weakext' in two of the g++ test
> cases.
> 
> I don’t feel strongly either way.  I'd like think weak(_definition)?(ext)?….. 
> is good
> enough, as this test doesn’t much care beyond that.
> 
> spec34 does:
> 
>  { dg-final { scan-assembler ".weak(_definition)?\[\t \]*_?_Z2f2IiEvT_”
> 
> for example.  Which I think is fairly readable/maintainable.
> 
> Let’s give others that might disagree with me an opportunity to do so…  I’m
> happy to defer to anyone that has a stronger opinion than mine.  If no one 
> steps
> forward, I’ll ok either way you want to go.
> 
> Wearing my hat as darwin/testsuite maintainer.  :-)

Thanks for the reply, I'd be happy with reducing the number of matches in those 
tests to use optional 'ext' or optional '_definition' as you suggested.

I've attached an updated patch to consolidate and remove the separate Darwin 
tests, so we can go with either approach if anyone else has an opinion.

ChangeLog/testsuite

2014-02-14  David Holsgrove 

 * gcc/testsuite/g++.dg/abi/rtti3.C: Extend scan-assembler
pattern to take optional patterns and remove darwin test.
 * gcc/testsuite/g++.dg/abi/thunk3.C: Likewise.
 * gcc/testsuite/g++.dg/abi/thunk4.C: Likewise.

thanks,
David





0005-Patch-testsuite-Extend-.weak-pattern-in-regex-match.patch
Description: 0005-Patch-testsuite-Extend-.weak-pattern-in-regex-match.patch

[wwwdocs] Consolidate GCC web pages documentation (3/3)

[Gerald Pfeifer]

After a bit of a hiatus, let me complete this now.

  Update and merge the list of open project for our web pages into
  the new master page (about.html).

Committed.

Gerald

Index: about.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/about.html,v
retrieving revision 1.19
diff -u -r1.19 about.html
--- about.html  18 Aug 2013 20:38:58 -  1.19
+++ about.html  17 Feb 2014 01:01:38 -
@@ -28,8 +28,22 @@
 mailing lists.
 
 
-Want to contribute? Please check our TODO 
list!
 
+Want to contribute?  Any help concerning the items below
+is welcome, as are suggestions.  Suggestions accompanied by patches have
+a higher chance of being implemented soon. ;-)
+
+
+  Improve navigation, with a consistent (short) menu on every page.
+
+  Set up a system that automatically checks the mirrors list.
+
+  It should detect mirrors that have gone away, are persistently
+  down, or very out of date (the last being easy to do for those
+  carrying snapshots, harder for those with releases only).
+  DJ Delorie d...@redhat.com>
+  has some scripts to do this already.
+
 
 
 
Index: projects/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/index.html,v
retrieving revision 1.66
diff -u -r1.66 index.html
--- projects/index.html 24 Apr 2013 15:14:26 -  1.66
+++ projects/index.html 17 Feb 2014 01:01:39 -
@@ -17,7 +17,7 @@
 Investigate bugs and attempt to fix bugs in our http://gcc.gnu.org/bugzilla/";>bug tracking system,
 see whether they still are present in current GCC.
-Projects for the GCC web pages.
+Projects for the GCC web pages.
 Projects for improving the GCC
 documentation.
 There are several development
Index: projects/web.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/web.html,v
retrieving revision 1.14
diff -u -r1.14 web.html
--- projects/web.html   18 Aug 2013 20:59:25 -  1.14
+++ projects/web.html   17 Feb 2014 01:01:39 -
@@ -18,27 +18,5 @@
 footer.  The MetaHTML style sheet is in
 wwwdocs/htdocs/style.mhtml.
 
-TODO
-
-Any help concerning open issues is highly welcome, as are
-suggestions.  Suggestions accompanied by patches have a higher chance
-of being implemented soon. ;-)
-
-
-  Move extra pages corresponding to technical news items into a
-  directory of their own. Add an index for these.
-
-  Improve navigation, with a consistent (short) menu on every page.
-
-  Set up a system that automatically checks the mirrors list.
-
-  It should detect mirrors that have gone away, are persistently
-  down, or are very out of date (the last being easy to do for those
-  carrying snapshots, harder for those with releases only).
-
-  DJ Delorie d...@redhat.com>
-  has some scripts to do this already.
-
-