[Patch, Fortran] -fcoarray=lib: Change handling of this_image() and num_images()

[Tobias Burnus]

The current coarray implementation uses a global static variable for 
this_image() and num_images(), which is set by the CAF init function, 
which is called by before the Fortran main function.


I somehow had the thinko that this permits for better optimizations than 
a library call. However, global variables are not really optimization 
friendly and I failed to come up with a scenario, where a global 
variable works better.


In addition, there are two problems with a global variable: If the code 
uses coarrays in a library but no in the main code (e.g. the main 
program is written in C), the variable won't be initialized at all.


And the second problem relates to the upcoming Technical Specification 
(TS) 18508 on Additional Parallel Features in Fortran. That TS 
introduces teams - and calling this_image() from within a team will give 
a different result to  this_image(distance=1), which applies to the 
parent's team.


Hence, the attached patch adds a this_image() and num_images() library 
function. As the library is only build statically and -fcoarray=lib is 
not widely used due to lacking communication support, I wouldn't count 
this patch as real ABI break and there shouldn't be a problem from that 
side.


I do include the distance= argument for both intrinsics and for 
num_images also a failed= argument. Those have been proposed in TS18508. 
I think it makes sense to prepare for that TS - if it won't be accepted, 
one can still remove it (cf. argument above). Regarding the failed: One 
needs to support three states: Unset (-1, all images); set to .false. 
(0, all nonfailed images), and .true. (1, all failed images).


Additionally, I have changed the "size" argument to the unsigned size_t, 
which matches both the current type in the front-end and the 
conventional type for malloc calls.


Built and currently regtesting on x86-64-gnu-linux. When successful:
OK for the trunk?  (It should be localized enough for 4.9 but 4.10 is 
probably more appropriate.)


Tobias

PS: Regarding TS18508: My impression is that the current draft (14-130 / 
N2007) is quite well shaped and will be accepted with only minor 
modifications. There will be soon a WG5 letter ballot, after which it 
should be even clearer where the standard is heading to.


PPS: I intent to create an SVN branch to collect the coarray changes.
gcc/fortran/
2014-03-07  Tobias Burnus  

	* gfortran.h (gfc_init_coarray_decl): Remove.
	* parse.c (translate_all_program_units): Remove call to it.
	(gfc_parse_file): Update call.
	* trans.h (gfor_fndecl_caf_this_image,
	gfor_fndecl_caf_num_images): Add.
	(gfort_gvar_caf_num_images,
	gfort_gvar_caf_this_image): Remove.
	* trans-decl.c (gfor_fndecl_caf_this_image,
	gfor_fndecl_caf_num_images): Add.
	(gfort_gvar_caf_num_images,
	gfort_gvar_caf_this_image): Remove.
	(gfc_build_builtin_function_decls): Init new decl.
	(gfc_init_coarray_dec): Remove.
	(create_main_function): Change calls.
	* trans-intrinsic.c (trans_this_image, trans_image_index,
	conv_intrinsic_cobound): Generate call to new library function
	instead of to a static variable.
	* trans-stmt.c (gfc_trans_sync): Ditto.
	
libgfortran/
2014-03-07  Tobias Burnus  

	* caf/libcaf.h (_gfortran_caf_this_image, _gfortran_caf_num_images):
	New prototypes.
	(_gfortran_caf_init): Change prototype.
	* caf/mpi.c (_gfortran_caf_this_image, _gfortran_caf_num_images):
New functions.
	(_gfortran_caf_init): Update.
	* caf/single.c (_gfortran_caf_this_image, _gfortran_caf_num_images):
New functions.
	(_gfortran_caf_init): Update.


 gcc/fortran/gfortran.h|  1 -
 gcc/fortran/parse.c   | 10 ++
 gcc/fortran/trans-decl.c  | 77 ---
 gcc/fortran/trans-intrinsic.c | 41 +--
 gcc/fortran/trans-stmt.c  |  5 ++-
 gcc/fortran/trans.h   |  6 ++--
 libgfortran/caf/libcaf.h  |  9 +++--
 libgfortran/caf/mpi.c | 22 +
 libgfortran/caf/single.c  | 22 ++---
 9 files changed, 83 insertions(+), 110 deletions(-)

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index cd2a913..ccdba35 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2947,7 +2947,6 @@ bool gfc_convert_to_structure_constructor (gfc_expr *, gfc_symbol *,
 /* trans.c */
 void gfc_generate_code (gfc_namespace *);
 void gfc_generate_module_code (gfc_namespace *);
-void gfc_init_coarray_decl (bool);
 
 /* trans-intrinsic.c */
 bool gfc_inline_intrinsic_function_p (gfc_expr *);
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index d9af60e..c55a02e 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -4496,19 +4496,13 @@ clean_up_modules (gfc_gsymbol *gsym)
 /* Translate all the program units. This could be in a different order
to resolution if there are forward references in the file.  */
 static void
-translate_all_program_units (gfc_namespace *gfc_global_ns_list,
-			 bool main_in_tu)
+translate_all_program_units (gfc_names

Re: [PATCH] Fix up make bootstrap-lean; make install (PR bootstrap/58572)

[Paolo Bonzini]

Il 06/03/2014 19:58, Jakub Jelinek ha scritto:

Hi!

As discussed in the PR, doing
make bootstrap-lean
make install
right now may fail (if host compiler is too old), or recompile various
objects of the compiler with system gcc before it is installed.
This happens because starting with the automatic dependency changes,
we have in gcc/.deps/*.Po lines like:
dfp.Po: 
/usr/src/gcc/obj942/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/gstdint.h
 \
alias.Po: 
/usr/src/gcc/obj942/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/cstring \
alias.Po: 
/usr/src/gcc/obj942/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdlib \
(apparently just those 3 headers so far), but the prev-* directories are for
bootstrap-lean removed as soon as the new stage finishes (or after
comparison finishes), so they aren't available during make install.

As that is the whole point of the *-lean bootstraps to save disk space,
keeping the previous stage around is against the intent of that.
I've tried to manually just symlink
ln -sf x86_64-unknown-linux-gnu prev-x86_64-unknown-linux-gnu
but that apparently didn't help either.

So, this patch instead ensures we don't add the libstdc++-v3/ headers
into the *.Po files at all.  As the libstdc++ headers are all already
#pragma GCC system_header, this patch should make no change to
what warnings are emitted and will only affect the .deps/* files.

Bootstrapped/regtested on x86_64-linux and i686-linux and tested also
with make bootstrap-lean; make install, ok for trunk?


Nice fix!  Did you check that on a regular bootstrap (formerly 
bubblestrap) you can modify the source code for the affected headers in 
libstdc++-v3, and alias.o/dfp.o will be rebuilt?


If so, the patch is ok.  Thanks!

Paolo


2014-03-06  Jakub Jelinek  

PR bootstrap/58572
* configure.ac (CXX_FOR_TARGET): Replace -I with -isystem
in testsuite_flags --build-includes output.
* Makefile.tpl (POSTSTAGE1_CXX_EXPORT): Use -isystem instead of
-I for libstdc++-v3 includes.
* configure: Regenerated.
* Makefile.in: Regenerated.

--- configure.ac.jj 2014-03-03 00:55:36.0 +0100
+++ configure.ac2014-03-06 15:24:47.067298246 +0100
@@ -3208,7 +3208,7 @@ GCC_TARGET_TOOL(as, AS_FOR_TARGET, AS, [
 GCC_TARGET_TOOL(cc, CC_FOR_TARGET, CC, [gcc/xgcc -B$$r/$(HOST_SUBDIR)/gcc/])
 dnl see comments for CXX_FOR_TARGET_FLAG_TO_PASS
 GCC_TARGET_TOOL(c++, CXX_FOR_TARGET, CXX,
-   [gcc/xg++ -B$$r/$(HOST_SUBDIR)/gcc/ -nostdinc++ `if test -f 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags; then $(SHELL) 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags --build-includes; 
else echo -funconfigured-libstdc++-v3 ; fi` 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs],
+   [gcc/xg++ -B$$r/$(HOST_SUBDIR)/gcc/ -nostdinc++ `if test -f 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags; then $(SHELL) 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags --build-includes | sed 
"s/^-I/-isystem /;s/ -I/ -isystem /g"; else echo -funconfigured-libstdc++-v3 ; 
fi` -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs],
c++)
 GCC_TARGET_TOOL(c++ for libstdc++, RAW_CXX_FOR_TARGET, CXX,
[gcc/xgcc -shared-libgcc -B$$r/$(HOST_SUBDIR)/gcc -nostdinc++ 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs],
--- Makefile.tpl.jj 2013-11-11 22:38:29.0 +0100
+++ Makefile.tpl2014-03-06 15:49:02.290211483 +0100
@@ -242,9 +242,9 @@ POSTSTAGE1_CXX_EXPORT = \
  -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \
  -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \
  -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \
- -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \
- -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \
- -I$$s/libstdc++-v3/libsupc++ \
+ -isystem 
$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \
+ -isystem $$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \
+ -isystem $$s/libstdc++-v3/libsupc++ \
  -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \
  -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs"; \
  export CXX; \
--- configure.jj2014-03-03 00:55:36.0 +0100
+++ configure   2014-03-06 15:28:41.094284292 +0100
@@ -13847,7 +13847,7 @@ else
   esac
   if test $ok = yes; then
 # An in-tree tool is available and we can use it
-CXX_FOR_TARGET='$$r/$(HOST_SUBDIR)/gcc/xg++ -B$$r/$(HOST_SUBDIR)/gcc/ 
-nostdinc++ `if test -f 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags; then $(SHELL) 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts

Merge from trunk to gccgo branch

[Ian Lance Taylor]

I merged GCC trunk revision 208392 to the gccgo branch.

Ian

Re: Patch RFC: Use internal qsort function in libbacktrace

[Ian Lance Taylor]

On Tue, Mar 4, 2014 at 7:34 PM, Ian Lance Taylor  wrote:
> The GNU glibc qsort function will call malloc in some cases.  That makes
> it unsuitable for libbacktrace, which is intended to work when called
> from a signal handler.  This patch changes libbacktrace to use an
> internal qsort function.
>
> I'm posting this for comments in case anybody sees anything wrong with
> the implementation.  I'll commit it in a day or two if I don't hear
> anything.

I've committed this patch as follows.  It's pretty much the same but I
tweaked the sort to use explicit tail recursion, and to do the
non-tail recursion for the smaller part of the array.  This limits the
function call depth to the log of the size of the array.

Ian


2014-03-06  Ian Lance Taylor  

* sort.c: New file.
* stest.c: New file.
* internal.h (backtrace_qsort): Declare.
* dwarf.c (read_abbrevs): Call backtrace_qsort instead of qsort.
(read_line_info, read_function_entry): Likewise.
(read_function_info, build_dwarf_data): Likewise.
* elf.c (elf_initialize_syminfo): Likewise.
* Makefile.am (libbacktrace_la_SOURCES): Add sort.c.
(stest_SOURCES, stest_LDADD): Define.
(check_PROGRAMS): Add stest.
Index: stest.c
===
--- stest.c	(revision 0)
+++ stest.c	(revision 0)
@@ -0,0 +1,137 @@
+/* stest.c -- Test for libbacktrace internal sort function
+   Copyright (C) 2012-2014 Free Software Foundation, Inc.
+   Written by Ian Lance Taylor, Google.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are
+met:
+
+(1) Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer. 
+
+(2) Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.  
+
+(3) The name of the author may not be used to
+endorse or promote products derived from this software without
+specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
+INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.  */
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+
+#include "backtrace.h"
+#include "internal.h"
+
+/* Test the local qsort implementation.  */
+
+#define MAX 10
+
+struct test
+{
+  size_t count;
+  int input[MAX];
+  int output[MAX];
+};
+
+static struct test tests[] =
+  {
+{
+  10,
+  { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 },
+  { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 }
+},
+{
+  9,
+  { 1, 2, 3, 4, 5, 6, 7, 8, 9 },
+  { 1, 2, 3, 4, 5, 6, 7, 8, 9 }
+},
+{
+  10,
+  { 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 },
+  { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 },
+},
+{
+  9,
+  { 9, 8, 7, 6, 5, 4, 3, 2, 1 },
+  { 1, 2, 3, 4, 5, 6, 7, 8, 9 },
+},
+{
+  10,
+  { 2, 4, 6, 8, 10, 1, 3, 5, 7, 9 },
+  { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 },
+},
+{
+  5,
+  { 4, 5, 3, 1, 2 },
+  { 1, 2, 3, 4, 5 },
+},
+{
+  5,
+  { 1, 1, 1, 1, 1 },
+  { 1, 1, 1, 1, 1 },
+},
+{
+  5,
+  { 1, 1, 2, 1, 1 },
+  { 1, 1, 1, 1, 2 },
+},
+{
+  5,
+  { 2, 1, 1, 1, 1 },
+  { 1, 1, 1, 1, 2 },
+},
+  };
+
+static int
+compare (const void *a, const void *b)
+{
+  const int *ai = (const int *) a;
+  const int *bi = (const int *) b;
+
+  return *ai - *bi;
+}
+
+int
+main (int argc ATTRIBUTE_UNUSED, char **argv ATTRIBUTE_UNUSED)
+{
+  int failures;
+  size_t i;
+  int a[MAX];
+
+  failures = 0;
+  for (i = 0; i < sizeof tests / sizeof tests[0]; i++)
+{
+  memcpy (a, tests[i].input, tests[i].count * sizeof (int));
+  backtrace_qsort (a, tests[i].count, sizeof (int), compare);
+  if (memcmp (a, tests[i].output, tests[i].count * sizeof (int)) != 0)
+	{
+	  size_t j;
+
+	  fprintf (stderr, "test %d failed:", (int) i);
+	  for (j = 0; j < tests[i].count; j++)
+	fprintf (stderr, " %d", a[j]);
+	  fprintf (stderr, "\n");
+	  ++failures;
+	}
+}
+
+  exit (failures > 0 ? EXIT_FAILURE : EXIT_SUCCESS);
+}
Index: dwarf.c
=

libgo patch committed: In syscall save all regs for GC

[Ian Lance Taylor]

This patch to libgo fixes a rare but serious bug.  The Go garbage
collector only examines Go stacks.  When Go code calls a function that
is not written in Go, it first calls syscall.Entersyscall.  Entersyscall
records the position of the Go stack pointer and saves a copy of all the
registers.  If the garbage collector runs while the thread is executing
the non-Go code, the garbage collector fetches the stack pointer and
registers from the saved location.

Entersyscall saves the registers using the getcontext function.
Unfortunately I didn't consider the possibility that Entersyscall might
itself change a register before calling getcontext.  This only matters
for callee-saved registers, as caller-saved registers would be visible
on the saved stack.  And it only matters if Entersyscall is compiled to
save and modify a callee-saved register before it calls getcontext.  And
it only matters if a garbage collection occurs while the non-Go code is
executing.  And it only matters if the only copy of a valid Go pointer
happens to be in the callee-saved register when Entersyscall is called.
When all those conditions are true, the Go pointer might get collected
incorrectly, leading to memory corruption.

This patch tries to avoid the problem by splitting Entersyscall into two
functions.  The first is a simple function that just calls getcontext
and then calls the rest of Entersyscall.  This should fix the problem,
provided the simple Entersyscall function does not itself modify any
callee-saved registers before calling getcontext.  That seems to be true
on the systems I checked.  But since the argument to getcontext is an
offset from a TLS variable, it won't be true on a system which needs to
save callee-saved registers in order to get the address of a TLS
variable.  I don't know why any system would work that way, but I don't
know how to rule it out.  I think that on any such system this will have
to be implemented in assembler.  I can't put the ucontext_t structure on
the stack, because this function can not split stacks, and the
ucontext_t structure is large enough that it could cause a stack
overflow.

For this patch I bootstrapped and ran the Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline and 4.8 branch.

Ian

diff -r de64b19b480e libgo/runtime/proc.c
--- a/libgo/runtime/proc.c	Thu Mar 06 16:00:18 2014 -0800
+++ b/libgo/runtime/proc.c	Thu Mar 06 20:55:49 2014 -0800
@@ -1857,10 +1857,30 @@
 // entersyscall is going to return immediately after.
 
 void runtime_entersyscall(void) __attribute__ ((no_split_stack));
+static void doentersyscall(void) __attribute__ ((no_split_stack, noinline));
 
 void
 runtime_entersyscall()
 {
+	// Save the registers in the g structure so that any pointers
+	// held in registers will be seen by the garbage collector.
+	getcontext(&g->gcregs);
+
+	// Do the work in a separate function, so that this function
+	// doesn't save any registers on its own stack.  If this
+	// function does save any registers, we might store the wrong
+	// value in the call to getcontext.
+	//
+	// FIXME: This assumes that we do not need to save any
+	// callee-saved registers to access the TLS variable g.  We
+	// don't want to put the ucontext_t on the stack because it is
+	// large and we can not split the stack here.
+	doentersyscall();
+}
+
+static void
+doentersyscall()
+{
 	// Disable preemption because during this function g is in Gsyscall status,
 	// but can have inconsistent g->sched, do not let GC observe it.
 	m->locks++;
@@ -1878,10 +1898,6 @@
 	}
 #endif
 
-	// Save the registers in the g structure so that any pointers
-	// held in registers will be seen by the garbage collector.
-	getcontext(&g->gcregs);
-
 	g->status = Gsyscall;
 
 	if(runtime_atomicload(&runtime_sched.sysmonwait)) {  // TODO: fast atomic

[jit] Visit parent contexts in disassociate_from_playback

[David Malcolm]

Committed to branch dmalcolm/jit:

My libgccjit port of GNU Octave's JIT was segfaulting due to corruption
of playback::location values when running Octave's JIT unittests.  After
lots of debugging, I found that recording::locations in a parent context
weren't having their playback::locations cleaned away between compiles,
and hence continue to point to a GC-allocated object for which no marking
is performed (by design: these objects aren't meant to outlive the compile
and hence should always be collected).

Hence we have pointers to supposedly-dead objects that don't get NULLed,
and point to bytes that eventually get repurposed by the GC, leading
to crashes.

The fix is to ensure that when clearing the playback objects from all
recording objects we visit those in parent contexts (and above), and not
just those in the bottommost context.

This bug was elusive, since most recording classes blithely
overwrite the old invalid pointers on replay, but recording::location
checks for a pre-existing playback::location (since
gcc_jit_context_dump_to_file can lead to playback::locations being needed
before they would normally be created), and can thus reuse the now-invalid
pointer - provided it's in a parent context.

We can reproduce this bug by using gcc_jit_context_dump_to_file in
test-nested-contexts.c on each context, to set up fake "source locations"
on the various entities in each context.  Doing so also gives us test
coverage of that function.

gcc/jit/
* internal-api.c (gcc::jit::recording::context::
disassociate_from_playback): Recursively visit parent contexts.

gcc/testsuite/
* jit.dg/test-nested-contexts.c (main): Dump the contexts to
files, setting up source locations, and adding test coverage for
gcc_jit_context_dump_to_file.
---
 gcc/jit/ChangeLog.jit   |  5 +
 gcc/jit/internal-api.c  |  4 
 gcc/testsuite/ChangeLog.jit |  6 ++
 gcc/testsuite/jit.dg/test-nested-contexts.c | 12 
 4 files changed, 27 insertions(+)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 3e2799f..b0058b9 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,8 @@
+2014-03-06  David Malcolm  
+
+   * internal-api.c (gcc::jit::recording::context::
+   disassociate_from_playback): Recursively visit parent contexts.
+
 2014-03-05  David Malcolm  
 
* libgccjit.h (gcc_jit_function_dump_to_dot): New.
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index 62301b2..f80c40b 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -243,6 +243,10 @@ recording::context::disassociate_from_playback ()
 {
   int i;
   memento *m;
+
+  if (m_parent_ctxt)
+m_parent_ctxt->disassociate_from_playback ();
+
   FOR_EACH_VEC_ELT (m_mementos, i, m)
 {
   m->set_playback_obj (NULL);
diff --git a/gcc/testsuite/ChangeLog.jit b/gcc/testsuite/ChangeLog.jit
index f66a844..52b606e 100644
--- a/gcc/testsuite/ChangeLog.jit
+++ b/gcc/testsuite/ChangeLog.jit
@@ -1,3 +1,9 @@
+2014-03-06  David Malcolm  
+
+   * jit.dg/test-nested-contexts.c (main): Dump the contexts to
+   files, setting up source locations, and adding test coverage for
+   gcc_jit_context_dump_to_file.
+
 2014-03-04  David Malcolm  
 
* jit.dg/test-error-mismatching-types-in-call.c: New test case,
diff --git a/gcc/testsuite/jit.dg/test-nested-contexts.c 
b/gcc/testsuite/jit.dg/test-nested-contexts.c
index e34d2dd..16bc63f 100644
--- a/gcc/testsuite/jit.dg/test-nested-contexts.c
+++ b/gcc/testsuite/jit.dg/test-nested-contexts.c
@@ -552,6 +552,10 @@ main (int argc, char **argv)
   /* No errors should have occurred.  */
   CHECK_VALUE (gcc_jit_context_get_first_error (top_level.ctxt), NULL);
 
+  gcc_jit_context_dump_to_file (top_level.ctxt,
+   "dump-of-test-nested-contexts-top.c",
+   1);
+
   for (j = 1; j <= NUM_MIDDLE_ITERATIONS; j++)
{
  /* Create and populate the middle-level context, using
@@ -575,6 +579,10 @@ main (int argc, char **argv)
  CHECK_VALUE (gcc_jit_context_get_first_error (middle_level.ctxt),
   NULL);
 
+ gcc_jit_context_dump_to_file (middle_level.ctxt,
+   "dump-of-test-nested-contexts-middle.c",
+   1);
+
  gcc_jit_result *middle_result =
gcc_jit_context_compile (middle_level.ctxt);
  CHECK_NON_NULL (middle_result);
@@ -607,6 +615,10 @@ main (int argc, char **argv)
  CHECK_VALUE (gcc_jit_context_get_first_error (bottom_level.ctxt),
   NULL);
 
+ gcc_jit_context_dump_to_file (bottom_level.ctxt,
+   
"dump-of-test-nested-contexts-bottom.c",
+   1);
+
  gcc_jit_result *bottom_result =
  

[PATCH] Change contrib/test_installed for testing cross compilers

[Steve Ellcey]

I was doing some testing of an installed cross-compiler using the
test_installed script in contrib and I noticed that there was no way
to set the target_triplet in the site.exp script that test_installed
creates.  This patch adds a new option (--target) that can be used to
set target_triplet in site.exp before running the testsuite, thus
making it more useful when testing cross-compilers.  If you don't use
the option nothing is changed.

OK to checkin?

Steve Ellcey
sell...@mips.com


2014-03-06  Steve Ellcey  

* test_installed (--target=): New option.


diff --git a/contrib/test_installed b/contrib/test_installed
index e518cbc..8102e7f 100755
--- a/contrib/test_installed
+++ b/contrib/test_installed
@@ -46,7 +46,7 @@ while true; do
   case "$1" in
   --with-testsuite=*) testsuite=`echo "$1" | sed 's/[^=]*=//'`; shift;;
   --srcdir=*) srcdir=`echo "$1" | sed 's/[^=]*=//'`; shift;;
-
+  --target=*) target=`echo "$1" | sed 's/[^=]*=//'`; shift;;
   --prefix=*) prefix=`echo "$1" | sed 's/[^=]*=//'`; shift;;
   --with-gcc=*) GCC_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
   --with-g++=*) GXX_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
@@ -71,6 +71,9 @@ Supported arguments:
 --srcdir=/some/dirsame as --with-testsuite=/some/dir/gcc/testsuite
   [deduced from shell-script pathname]
 
+--target=triplet  The target architecture of the compiler being
+  tested if different then the host.
+
 --prefix=/some/diruse gcc, g++ and gfortran from /some/dir/bin 
[PATH]
 --with-gcc=/some/dir/bin/gcc  use specified gcc program [gcc]
 --with-g++=/some/dir/bin/g++  use specified g++ program [g++]
@@ -112,6 +115,9 @@ set GXX_UNDER_TEST 
"${GXX_UNDER_TEST-${prefix}${prefix+/bin/}g++}"
 set GFORTRAN_UNDER_TEST 
"${GFORTRAN_UNDER_TEST-${prefix}${prefix+/bin/}gfortran}"
 set OBJC_UNDER_TEST "${OBJC_UNDER_TEST-${prefix}${prefix+/bin/}gcc}"
 EOF
+if test x${target} != x; then
+  echo "set target_triplet $target" >> site.exp
+fi
 
 test x"${GCC_UNDER_TEST}" = x"no" || runtest --tool gcc ${1+"$@"}
 test x"${GXX_UNDER_TEST}" = x"no" || runtest --tool g++ ${1+"$@"}

Re: [PATCH] Mark fira-loop-pressure as optimization

[Paulo J. Matos]

On 06/03/14 23:34, Paulo J. Matos wrote:

Hi,

This patch marks fira-loop-pressure as an optimization so it shows in
gcc --help=optimizers.

2014-03-06  Paulo Matos  

 * common.opt (fira-loop-pressure): Mark as optimization.

OK to commit?



Patch is attached.

--
PMatos
Index: gcc/common.opt
===
--- gcc/common.opt	(revision 208385)
+++ gcc/common.opt	(working copy)
@@ -1443,7 +1443,7 @@ Use IRA based register pressure calculat
 in RTL hoist optimizations.
 
 fira-loop-pressure
-Common Report Var(flag_ira_loop_pressure)
+Common Report Var(flag_ira_loop_pressure) Optimization
 Use IRA based register pressure calculation
 in RTL loop optimizations.
 

[PATCH] Mark fira-loop-pressure as optimization

[Paulo J. Matos]

Hi,

This patch marks fira-loop-pressure as an optimization so it shows in 
gcc --help=optimizers.


2014-03-06  Paulo Matos  

* common.opt (fira-loop-pressure): Mark as optimization.

OK to commit?

--
PMatos

Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc

[Paulo Matos]

On 06/03/14 11:19, Richard Biener wrote:

On Wed, Mar 5, 2014 at 12:55 PM, Paulo Matos  wrote:

On 05/03/2014 11:51, Richard Biener wrote:


On Wed, Mar 5, 2014 at 12:43 PM, Dominique Dhumieres 
wrote:



Revision 208312 causes

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427



Uhm.  pointer comparison against double_type_node ...

I'd say we want to revert the patch.  Paulo, please do that.  Let's
do the alternate approach of marking -fshort-double eligible for LTO
as well and handle it there properly.



Sure, I will prepare a new patch and post it for approval by the end of the
day.

Apologies for the regression.


I have reverted the patch for now.

Richard.




Please find new patch attached. I have enabled LTO for short-double and 
passed flag_short_double to build_common_tree_nodes.


I have tested this for C on powerpc-eabipse (target for which we are 
fixing pr55113), and C/Fortran on a x86_64. Saw no regressions.


OK to commit?

gcc/c-family/
2014-03-06  Paulo Matos  

* c.opt: Enable LTO FE for fshort-double.

gcc/lto/
2014-03-06  Paulo Matos  

* lto-lang.c (lto_init): Pass flag_short_double to
build_common_tree_nodes.

gcc/testsuite/
2014-03-06  Paulo Matos  

* gcc.dg/lto/pr55113_0.c: New testcase.


--
Paulo Matos
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt	(revision 208385)
+++ gcc/c-family/c.opt	(working copy)
@@ -1141,7 +1141,7 @@ C++ ObjC++ Optimization Var(flag_rtti) I
 Generate run time type descriptor information
 
 fshort-double
-C ObjC C++ ObjC++ Optimization Var(flag_short_double)
+C ObjC C++ ObjC++ LTO Optimization Var(flag_short_double)
 Use the same size for double as for float
 
 fshort-enums
Index: gcc/lto/lto-lang.c
===
--- gcc/lto/lto-lang.c	(revision 208385)
+++ gcc/lto/lto-lang.c	(working copy)
@@ -1158,7 +1158,7 @@ lto_init (void)
   flag_generate_lto = (flag_wpa != NULL);
 
   /* Create the basic integer types.  */
-  build_common_tree_nodes (flag_signed_char, /*short_double=*/false);
+  build_common_tree_nodes (flag_signed_char, flag_short_double);
 
   /* The global tree for the main identifier is filled in by
  language-specific front-end initialization that is not run in the
Index: gcc/testsuite/gcc.dg/lto/pr55113_0.c
===
--- gcc/testsuite/gcc.dg/lto/pr55113_0.c	(revision 0)
+++ gcc/testsuite/gcc.dg/lto/pr55113_0.c	(working copy)
@@ -0,0 +1,13 @@
+/* PR 55113 */
+/* { dg-lto-do link } */
+/* { dg-lto-options { { -flto -fshort-double -O0 } } }*/
+/* { dg-skip-if "PR60410" { { x86_64-*-* i?86-*-* } && lp64 } } */
+
+int 
+main(void)
+{
+  float a = 1.0;
+  float b = 2.0;
+  double f = a + b * 1e-12;
+  return (int)f - 1;
+}

Re: [PATCH] Fix up make bootstrap-lean; make install (PR bootstrap/58572)

[DJ Delorie]

In the non-lean case, would this mean a change to a header (i.e. you
edit it in the source tree) wouldn't cause a proper re-build if you
re-bootstrapped?

Re: [Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)

[Janus Weil]

>> Please commit the patch to trunk.
>
> Will do!

I have just committed the patch as r208386, thereby implementing
deferred-length character components on 4.9 trunk. One big plea to the
users: Please test this as soon as possible!

Cheers,
Janus



>> On Mar 6, 2014 9:59 PM, "Janus Weil"  wrote:
>>>
>>> Hi Paul,
>>>
>>> > I am trying to respond to Mikael's comment that only kind=1 is handled.
>>> > I'll
>>> > use your patch as a basis.
>>>
>>> actually the last version of the patch that I posted yesterday should
>>> already handle that (and includes a kind=4 test case). But if you find
>>> any remaining problems, please let me know.
>>>
>>> Also Tobias already told me privately that his "mixed feeling" were
>>> not strong enough to oppose against committing the patch. So right now
>>> the only thing standing between the patch and trunk seems to be you ;)
>>>
>>> Cheers,
>>> Janus
>>>
>>>
>>>
>>> > On Mar 5, 2014 2:53 PM, "Janus Weil"  wrote:
>>> >>
>>> >> Hi Mikael,
>>> >>
>>> >> >> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>> >> >>
>>> >> > I'm asking for one more minor change, namely:
>>> >> >
>>> >> >> @@ -12364,6 +12356,25 @@ resolve_fl_derived0 (gfc_symbol *sym)
>>> >> >> return false;
>>> >> >>   }
>>> >> >>
>>> >> >> +  /* Add the hidden deferred length field.  */
>>> >> >> +  if (c->ts.type == BT_CHARACTER && c->ts.deferred &&
>>> >> >> !c->attr.function
>>> >> >> +   && !sym->attr.is_class)
>>> >> >> + {
>>> >> >> +   char name[GFC_MAX_SYMBOL_LEN+1];
>>> >> >> +   gfc_component *strlen;
>>> >> >> +   sprintf (name, "_%s", c->name);
>>> >> >
>>> >> > It's not more costly to have a more explicit name like "_%s_length"
>>> >> > or
>>> >> > something, and I prefer having the latter in complicated dumps or in
>>> >> > the
>>> >> > debugger.
>>> >>
>>> >> I agree.
>>> >>
>>> >>
>>> >> > OK with that change, with the associated buffer size update.  Also
>>> >> > Steve
>>> >> > noted that the buffer size should take the terminating null character
>>> >> > into account.
>>> >>
>>> >> Steve's comment somehow got lost in the noise. I have updated both the
>>> >> name and the buffer size now in resolve_fl_derived0 as well as
>>> >> gfc_deferred_strlen. Updated patch attached.
>>> >>
>>> >> A few people expressed mixed feelings, therefore I'll wait a couple of
>>> >> days to allow the naysayers to chime in. In the absence of further
>>> >> feedback, I'll commit the patch on the weekend.
>>> >>
>>> >> Cheers,
>>> >> Janus

Re: [PATCH] Use the LTO linker plugin by default

[Jan Hubicka]

> On Thu, 6 Mar 2014, Jan Hubicka wrote:
> 
> > > On Tue, 4 Mar 2014, Jan Hubicka wrote:
> > > 
> > > > > 
> > > > > The following patch addresses the common (?) issue of people
> > > > > omitting -flto from the linker command-line which gets more
> > > > > severe with GCC 4.9 where slim LTO objects are emitted by
> > > > > default.  The patch simply _always_ arranges for the linker
> > > > > plugin to be used, so if there are any (slim) LTO objects
> > > > > on the link LTO will be done on them.  Similarly the
> > > > > non-linker-plugin path in collect2 is adjusted.
> > > > > 
> > > > > You can still disable this by specifying -fno-lto on the 
> > > > > linker command-line.
> > > > > 
> > > > > One side-effect of enabling the linker-plugin by default
> > > > > (for HAVE_LTO_PLUGIN == 2) is that collect2 will then
> > > > > use the configured plugin ld rather than the default ld.
> > > > > Not sure if that is desired.
> > > > > 
> > > > > Comments?
> > > > 
> > > > I like it; it was on my TODO list, but I was only worried about
> > > > --with-plugin-ld and did not find time, yet, to look into the 
> > > > consequences.
> > > > These days, I do not think we need to worry much aboud --with-plugin-ld.
> > > 
> > > Yeah, I think we should eventually remove that capability.
> > > 
> > > Now as of the two patches (compute a default link-time optimization
> > > level and this patch, make considering LTO at link-time the default),
> > > they only make sense together (at least the default opt level at
> > > link-time doesn't improve real-world situations without also considering
> > > all links to be possibly -flto).
> > > 
> > > So the question remains if we want to have both patches at this
> > > stage or if we want to wait with them for 4.10 (we do have the
> > > user-visible change of slim-lto objects by default with 4.9
> > > already).
> > 
> > I think it makes things easier, so I would like to see this in 4.9
> 
> Ok.  I'll push this to trunk now and then prepare a documentation
> update for LTO opts handling (as promised some time ago ...).
> 
> If any issues show up with these two patches then we'll revert
> and revisit this for 4.10.

Thanks,
I definitely saw issues without these patches even on projects that are kind of
LTO enabled, like libreoffice (whose --enable-lto does linking of couple 3rd
party libraries without -flto) and firefox (that links everything with -flto
but sometimes forget optimization flags).  So for a while I am using wrapper
script that adds -O3 -flto to gcc command line just to be sure setup is not
completely insane.  Having this done automatically by a wrapper is nice.

Honza
> 
> Thanks,
> Richard.

Re: [Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)

[Janus Weil]

Hi,

> In that case, go for it! I am on vacation in Tenerife right now and have
> very limited access.

wow, in that case I guess you better enjoy your holidays ;)


> Please commit the patch to trunk.

Will do!

Thanks,
Janus




> On Mar 6, 2014 9:59 PM, "Janus Weil"  wrote:
>>
>> Hi Paul,
>>
>> > I am trying to respond to Mikael's comment that only kind=1 is handled.
>> > I'll
>> > use your patch as a basis.
>>
>> actually the last version of the patch that I posted yesterday should
>> already handle that (and includes a kind=4 test case). But if you find
>> any remaining problems, please let me know.
>>
>> Also Tobias already told me privately that his "mixed feeling" were
>> not strong enough to oppose against committing the patch. So right now
>> the only thing standing between the patch and trunk seems to be you ;)
>>
>> Cheers,
>> Janus
>>
>>
>>
>> > On Mar 5, 2014 2:53 PM, "Janus Weil"  wrote:
>> >>
>> >> Hi Mikael,
>> >>
>> >> >> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>> >> >>
>> >> > I'm asking for one more minor change, namely:
>> >> >
>> >> >> @@ -12364,6 +12356,25 @@ resolve_fl_derived0 (gfc_symbol *sym)
>> >> >> return false;
>> >> >>   }
>> >> >>
>> >> >> +  /* Add the hidden deferred length field.  */
>> >> >> +  if (c->ts.type == BT_CHARACTER && c->ts.deferred &&
>> >> >> !c->attr.function
>> >> >> +   && !sym->attr.is_class)
>> >> >> + {
>> >> >> +   char name[GFC_MAX_SYMBOL_LEN+1];
>> >> >> +   gfc_component *strlen;
>> >> >> +   sprintf (name, "_%s", c->name);
>> >> >
>> >> > It's not more costly to have a more explicit name like "_%s_length"
>> >> > or
>> >> > something, and I prefer having the latter in complicated dumps or in
>> >> > the
>> >> > debugger.
>> >>
>> >> I agree.
>> >>
>> >>
>> >> > OK with that change, with the associated buffer size update.  Also
>> >> > Steve
>> >> > noted that the buffer size should take the terminating null character
>> >> > into account.
>> >>
>> >> Steve's comment somehow got lost in the noise. I have updated both the
>> >> name and the buffer size now in resolve_fl_derived0 as well as
>> >> gfc_deferred_strlen. Updated patch attached.
>> >>
>> >> A few people expressed mixed feelings, therefore I'll wait a couple of
>> >> days to allow the naysayers to chime in. In the absence of further
>> >> feedback, I'll commit the patch on the weekend.
>> >>
>> >> Cheers,
>> >> Janus

Re: [Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)

[Janus Weil]

Hi Paul,

> I am trying to respond to Mikael's comment that only kind=1 is handled. I'll
> use your patch as a basis.

actually the last version of the patch that I posted yesterday should
already handle that (and includes a kind=4 test case). But if you find
any remaining problems, please let me know.

Also Tobias already told me privately that his "mixed feeling" were
not strong enough to oppose against committing the patch. So right now
the only thing standing between the patch and trunk seems to be you ;)

Cheers,
Janus



> On Mar 5, 2014 2:53 PM, "Janus Weil"  wrote:
>>
>> Hi Mikael,
>>
>> >> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>> >>
>> > I'm asking for one more minor change, namely:
>> >
>> >> @@ -12364,6 +12356,25 @@ resolve_fl_derived0 (gfc_symbol *sym)
>> >> return false;
>> >>   }
>> >>
>> >> +  /* Add the hidden deferred length field.  */
>> >> +  if (c->ts.type == BT_CHARACTER && c->ts.deferred &&
>> >> !c->attr.function
>> >> +   && !sym->attr.is_class)
>> >> + {
>> >> +   char name[GFC_MAX_SYMBOL_LEN+1];
>> >> +   gfc_component *strlen;
>> >> +   sprintf (name, "_%s", c->name);
>> >
>> > It's not more costly to have a more explicit name like "_%s_length" or
>> > something, and I prefer having the latter in complicated dumps or in the
>> > debugger.
>>
>> I agree.
>>
>>
>> > OK with that change, with the associated buffer size update.  Also Steve
>> > noted that the buffer size should take the terminating null character
>> > into account.
>>
>> Steve's comment somehow got lost in the noise. I have updated both the
>> name and the buffer size now in resolve_fl_derived0 as well as
>> gfc_deferred_strlen. Updated patch attached.
>>
>> A few people expressed mixed feelings, therefore I'll wait a couple of
>> days to allow the naysayers to chime in. In the absence of further
>> feedback, I'll commit the patch on the weekend.
>>
>> Cheers,
>> Janus

[PATCH] Fix up make bootstrap-lean; make install (PR bootstrap/58572)

[Jakub Jelinek]

Hi!

As discussed in the PR, doing
make bootstrap-lean
make install
right now may fail (if host compiler is too old), or recompile various
objects of the compiler with system gcc before it is installed.
This happens because starting with the automatic dependency changes,
we have in gcc/.deps/*.Po lines like:
dfp.Po: 
/usr/src/gcc/obj942/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/gstdint.h
 \
alias.Po: 
/usr/src/gcc/obj942/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/cstring \
alias.Po: 
/usr/src/gcc/obj942/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdlib \
(apparently just those 3 headers so far), but the prev-* directories are for
bootstrap-lean removed as soon as the new stage finishes (or after
comparison finishes), so they aren't available during make install.

As that is the whole point of the *-lean bootstraps to save disk space,
keeping the previous stage around is against the intent of that.
I've tried to manually just symlink
ln -sf x86_64-unknown-linux-gnu prev-x86_64-unknown-linux-gnu
but that apparently didn't help either.

So, this patch instead ensures we don't add the libstdc++-v3/ headers
into the *.Po files at all.  As the libstdc++ headers are all already
#pragma GCC system_header, this patch should make no change to
what warnings are emitted and will only affect the .deps/* files.

Bootstrapped/regtested on x86_64-linux and i686-linux and tested also
with make bootstrap-lean; make install, ok for trunk?

2014-03-06  Jakub Jelinek  

PR bootstrap/58572
* configure.ac (CXX_FOR_TARGET): Replace -I with -isystem
in testsuite_flags --build-includes output.
* Makefile.tpl (POSTSTAGE1_CXX_EXPORT): Use -isystem instead of
-I for libstdc++-v3 includes.
* configure: Regenerated.
* Makefile.in: Regenerated.

--- configure.ac.jj 2014-03-03 00:55:36.0 +0100
+++ configure.ac2014-03-06 15:24:47.067298246 +0100
@@ -3208,7 +3208,7 @@ GCC_TARGET_TOOL(as, AS_FOR_TARGET, AS, [
 GCC_TARGET_TOOL(cc, CC_FOR_TARGET, CC, [gcc/xgcc -B$$r/$(HOST_SUBDIR)/gcc/])
 dnl see comments for CXX_FOR_TARGET_FLAG_TO_PASS
 GCC_TARGET_TOOL(c++, CXX_FOR_TARGET, CXX,
-   [gcc/xg++ -B$$r/$(HOST_SUBDIR)/gcc/ -nostdinc++ `if test -f 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags; then $(SHELL) 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags --build-includes; 
else echo -funconfigured-libstdc++-v3 ; fi` 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs],
+   [gcc/xg++ -B$$r/$(HOST_SUBDIR)/gcc/ -nostdinc++ `if test -f 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags; then $(SHELL) 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags --build-includes | 
sed "s/^-I/-isystem /;s/ -I/ -isystem /g"; else echo 
-funconfigured-libstdc++-v3 ; fi` -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs],
c++)
 GCC_TARGET_TOOL(c++ for libstdc++, RAW_CXX_FOR_TARGET, CXX,
[gcc/xgcc -shared-libgcc -B$$r/$(HOST_SUBDIR)/gcc -nostdinc++ 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs],
--- Makefile.tpl.jj 2013-11-11 22:38:29.0 +0100
+++ Makefile.tpl2014-03-06 15:49:02.290211483 +0100
@@ -242,9 +242,9 @@ POSTSTAGE1_CXX_EXPORT = \
  -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \
  -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \
  -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \
- -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \
- -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \
- -I$$s/libstdc++-v3/libsupc++ \
+ -isystem 
$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \
+ -isystem $$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \
+ -isystem $$s/libstdc++-v3/libsupc++ \
  -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \
  -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs"; \
  export CXX; \
--- configure.jj2014-03-03 00:55:36.0 +0100
+++ configure   2014-03-06 15:28:41.094284292 +0100
@@ -13847,7 +13847,7 @@ else
   esac
   if test $ok = yes; then
 # An in-tree tool is available and we can use it
-CXX_FOR_TARGET='$$r/$(HOST_SUBDIR)/gcc/xg++ -B$$r/$(HOST_SUBDIR)/gcc/ 
-nostdinc++ `if test -f 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags; then $(SHELL) 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags --build-includes; 
else echo -funconfigured-libstdc++-v3 ; fi` 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs'
+CXX_FOR_TARGET='$$r/$(HOST_SUBDIR)/gcc/xg++ -B$$r/$(

Re: ICE in gcc/c/c-typeck.c:c_finish_omp_clauses -- The error_mark_node is not an OpenMP mappable type

[Jakub Jelinek]

On Thu, Mar 06, 2014 at 07:08:18PM +0100, Thomas Schwinge wrote:
> > This does not happen for C++, because gcc/cp/decl2.c:cp_omp_mappable_type
> > catches the »type == error_mark_node« case -- so I suggest to do the same
> > generically/for C.  OK to commit the following to trunk, once tested?
> 
> Test results are looking fine.
> 
> > commit 63aa927ea54304f6bfd119ad7f72a0322e059637
> > Author: Thomas Schwinge 
> > Date:   Wed Mar 5 17:06:50 2014 +0100
> > 
> > The error_mark_node is not an OpenMP mappable type.
> > 
> > gcc/
> > * langhooks.c (lhd_omp_mappable_type): The error_mark_node is 
> > not
> > an OpenMP mappable type.
> > gcc/c/
> > * c-decl.c (c_decl_attributes): Use
> > lang_hooks.types.omp_mappable_type.
> > * c-typeck.c (c_finish_omp_clauses): Likewise.
> > gcc/testsuite/
> > * c-c++-common/gomp/map-1.c: Extend.

Ok for trunk.

Jakub

Fwd: [c++-concepts] Shorthand notation

[Andrew Sutton]

I'm resending this patch for constrained template parameters for
review. It's been languishing for a while without review and it has
some interesting features in the implementation (namely, resolution
mechanism or constrained template parameters).

Andrew

-- Forwarded message --
From: Andrew Sutton 
Date: Wed, Oct 16, 2013 at 9:59 AM
Subject: [c++-concepts] Shorthand notation
To: gcc-patches@gcc.gnu.org, Jason Merrill 


I've committed initial support for shorthand constraints. This patch
adds support for parsing a concept-names as non-class names. When
introducing a template parameter, the concept name is transformed into
a constraint on the template parameter. Constrained parameters can
introduce type, non-type and template template parameters.

This has initial support for variadic constraints, but it's not well tested.

This patch does not yet support default arguments for constrained
template parameters, nor does it support the use of concept ids of
this form:

  template F>
void f();

There are a couple of interesting things in the patch. I'm using a
PLACEHOLDER_EXPR as a template argument in order to resolve constraint
names. Effectively, I deduce concepts by creating an expression like:

  Equality_comparable()

where ? is a placeholder, and after coerce_template_arguments
completes, I can extract the matched parameter from the placeholder.
This works nicely when concepts are overloaded or have default
arguments (although I'm not sure I'm testing that very thoroughly
right now).

With variadic constraints, I've had to add functionality to expand a
pack as a conjunction of requirements. For example, if you declare:

  template // Class() must be true for each T in Ts
void f();

The transformation is:

  template
requires Class()...
  void f();

Where Class()... expands to Class() && Class() && ... etc.
I feel like the current implementation is a bit hacky, and I'm
wondering if I should introduce a new node for a pack conjunction.

Change log follows.

2013-10-16  Andrew Sutton  
* gcc/cp/constraint.cc (conjoin_requiremens): New.
(resolve_constraint_check): Filter non-concept candidates before
coercing arguments. Perform deduction in a template-decl processing
context to prevent errors during diagnosis.
(finish_concept_name), (finish_shorthand_requirement),
(get_shorthand_requirements): New.
* gcc/cp/pt.c (template_parm_to_arg): Make non-static.
(process_templat_parm): Build shorthand requirements from the
parameter description.
(end_templat_parm_list): New.
(convert_placeholder_argument): New.
(convert_template_argument): Match placeholder arguments against
any template parameter.
(tsubst_pack_conjuction):  New.
(tsubst_expr): Expand a pack as a conjunction.
(type_dependent_expression_p): Placeholders are always type
dependent.
* gcc/cp/parser.c (cp_is_constrained_parameter),
(cp_finish_template_type_parm), (cp_finish_template_template_parm)
(cp_finish_non_type_template_parm), (cp_finish_constrined_parameter):
New.
(cp_parser_template_parameter): Handle constrained parameters.
(cp_parser_nonclass_name): An identifier naming an overload set
may declare a constrained parameter.
(cp_parser_type_parameter), (cp_parser_template_declaration_after_exp):
Get shorthand requirements from the tmeplate parameter list.
* gcc/cp/cp-tree.h (TEMPLATE_PARM_CONSTRAINTS): New.

Committed in 203704.

Andrew Sutton

Re: ICE in gcc/c/c-typeck.c:c_finish_omp_clauses -- The error_mark_node is not an OpenMP mappable type

[Thomas Schwinge]

Hi!

On Wed, 05 Mar 2014 17:55:28 +0100, I wrote:
> ../../map.c: In function 'main':
> ../../map.c:4:21: error: array type has incomplete element type
>extern struct foo s2[1];
>  ^
> ../../map.c:8:11: internal compiler error: tree check: expected class 
> 'type', have 'exceptional' (error_mark) in c_finish_omp_clauses, at 
> c/c-typeck.c:12126
>#pragma omp target map(s2) /* { dg-error "array type has incomplete 
> element type" } */
>^
> 0xe5cf3a tree_class_check_failed(tree_node const*, tree_code_class, char 
> const*, int, char const*)
> ../../source/gcc/tree.c:9271
> 0x580866 tree_class_check
> ../../source/gcc/tree.h:2894
> 0x580866 c_finish_omp_clauses(tree_node*)
> ../../source/gcc/c/c-typeck.c:12126
> 0x59f99b c_parser_omp_all_clauses
> ../../source/gcc/c/c-parser.c:11367
> 0x5ad404 c_parser_omp_target
> ../../source/gcc/c/c-parser.c:13081
> [...]
> 
> This does not happen for C++, because gcc/cp/decl2.c:cp_omp_mappable_type
> catches the »type == error_mark_node« case -- so I suggest to do the same
> generically/for C.  OK to commit the following to trunk, once tested?

Test results are looking fine.

> commit 63aa927ea54304f6bfd119ad7f72a0322e059637
> Author: Thomas Schwinge 
> Date:   Wed Mar 5 17:06:50 2014 +0100
> 
> The error_mark_node is not an OpenMP mappable type.
> 
>   gcc/
>   * langhooks.c (lhd_omp_mappable_type): The error_mark_node is not
>   an OpenMP mappable type.
>   gcc/c/
>   * c-decl.c (c_decl_attributes): Use
>   lang_hooks.types.omp_mappable_type.
>   * c-typeck.c (c_finish_omp_clauses): Likewise.
>   gcc/testsuite/
>   * c-c++-common/gomp/map-1.c: Extend.
> 
> diff --git gcc/c/c-decl.c gcc/c/c-decl.c
> index 7a7d68e..2c41bf2 100644
> --- gcc/c/c-decl.c
> +++ gcc/c/c-decl.c
> @@ -4024,7 +4024,7 @@ c_decl_attributes (tree *node, tree attributes, int 
> flags)
>   error ("%q+D in block scope inside of declare target directive",
>  *node);
>else if (TREE_CODE (*node) == VAR_DECL
> -&& !COMPLETE_TYPE_P (TREE_TYPE (*node)))
> +&& !lang_hooks.types.omp_mappable_type (TREE_TYPE (*node)))
>   error ("%q+D in declare target directive does not have mappable type",
>  *node);
>else
> diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
> index 191adfb..65ef1f3 100644
> --- gcc/c/c-typeck.c
> +++ gcc/c/c-typeck.c
> @@ -12082,7 +12082,7 @@ c_finish_omp_clauses (tree clauses)
> else
>   {
> t = OMP_CLAUSE_DECL (c);
> -   if (!COMPLETE_TYPE_P (TREE_TYPE (t)))
> +   if (!lang_hooks.types.omp_mappable_type (TREE_TYPE (t)))
>   {
> error_at (OMP_CLAUSE_LOCATION (c),
>   "array section does not have mappable type "
> @@ -12111,9 +12111,9 @@ c_finish_omp_clauses (tree clauses)
>   }
> else if (!c_mark_addressable (t))
>   remove = true;
> -   else if (!COMPLETE_TYPE_P (TREE_TYPE (t))
> -&& !(OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
> - && OMP_CLAUSE_MAP_KIND (c) == OMP_CLAUSE_MAP_POINTER))
> +   else if (!(OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
> +  && OMP_CLAUSE_MAP_KIND (c) == OMP_CLAUSE_MAP_POINTER)
> +&& !lang_hooks.types.omp_mappable_type (TREE_TYPE (t)))
>   {
> error_at (OMP_CLAUSE_LOCATION (c),
>   "%qD does not have a mappable type in %qs clause", t,
> diff --git gcc/langhooks.c gcc/langhooks.c
> index eca0299..d00ebd8 100644
> --- gcc/langhooks.c
> +++ gcc/langhooks.c
> @@ -524,13 +524,15 @@ lhd_omp_firstprivatize_type_sizes (struct 
> gimplify_omp_ctx *c ATTRIBUTE_UNUSED,
>  {
>  }
>  
> -/* Return true if TYPE is an OpenMP mappable type.  By default return true
> -   if type is complete.  */
> +/* Return true if TYPE is an OpenMP mappable type.  */
>  
>  bool
>  lhd_omp_mappable_type (tree type)
>  {
> -  return COMPLETE_TYPE_P (type);
> +  /* Mappable type has to be complete.  */
> +  if (type == error_mark_node || !COMPLETE_TYPE_P (type))
> +return false;
> +  return true;
>  }
>  
>  /* Common function for add_builtin_function and
> diff --git gcc/testsuite/c-c++-common/gomp/map-1.c 
> gcc/testsuite/c-c++-common/gomp/map-1.c
> index 694d88c..5dad7d6 100644
> --- gcc/testsuite/c-c++-common/gomp/map-1.c
> +++ gcc/testsuite/c-c++-common/gomp/map-1.c
> @@ -8,6 +8,8 @@ int k[10], l[10], m[10], n[10], o;
>  int *p;
>  int **q;
>  int r[4][4][4][4][4];
> +extern struct s s1;
> +extern struct s s2[1]; /* { dg-error "array type has incomplete element 
> type" "" { target c } } */
>  int t[10];
>  #pragma omp threadprivate (t)
>  #pragma omp declare target
> @@ -32,6 +34,10 @@ foo (int g[3][10], int h[4][8], int i[2][10], int j[][9],
>  ;
>#pragma omp target map(

Re: [PING^4][PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope

[Dimitris Papavasiliou]

Ping!

On 02/27/2014 11:44 AM, Dimitris Papavasiliou wrote:

Ping!

On 02/20/2014 12:11 PM, Dimitris Papavasiliou wrote:

Hello all,

Pinging this patch review request again. See previous messages quoted
below for details.

Regards,
Dimitris

On 02/13/2014 04:22 PM, Dimitris Papavasiliou wrote:

Hello,

Pinging this patch review request. Can someone involved in the
Objective-C language frontend have a quick look at the description of
the proposed features and tell me if it'd be ok to have them in the
trunk so I can go ahead and create proper patches?

Thanks,
Dimitris

On 02/06/2014 11:25 AM, Dimitris Papavasiliou wrote:

Hello,

This is a patch regarding a couple of Objective-C related dialect
options and warning switches. I have already submitted it a while ago
but gave up after pinging a couple of times. I am now informed that
should have kept pinging until I got someone's attention so I'm
resending it.

The patch is now against an old revision and as I stated originally
it's
probably not in a state that can be adopted as is. I'm sending it as is
so that the implemented features can be assesed in terms of their
usefulness and if they're welcome I'd be happy to make any necessary
changes to bring it up-to-date, split it into smaller patches, add
test-cases and anything else that is deemed necessary.

Here's the relevant text from my initial message:

Two of these switches are related to a feature request I submitted a
while ago, Bug 56044
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044). I won't reproduce
the entire argument here since it is available in the feature request.
The relevant functionality in the patch comes in the form of two
switches:

-Wshadow-ivars which controls the "local declaration of ‘somevar’ hides
instance variable" warning which curiously is enabled by default
instead
of being controlled at least by -Wshadow. The patch changes it so that
this warning can be enabled and disabled specifically through
-Wshadow-ivars as well as with all other shadowing-related warnings
through -Wshadow.

The reason for the extra switch is that, while searching through the
Internet for a solution to this problem I have found out that other
people are inconvenienced by this particular warning as well so it
might
be useful to be able to turn it off while keeping all the other
shadowing-related warnings enabled.

-flocal-ivars which when true, as it is by default, treats instance
variables as having local scope. If false (-fno-local-ivars) instance
variables must always be referred to as self->ivarname and
references of
ivarname resolve to the local or global scope as usual.

I've also taken the opportunity of adding another switch unrelated to
the above but related to instance variables:

-fivar-visibility which can be set to either private, protected (the
default), public and package. This sets the default instance variable
visibility which normally is implicitly protected. My use-case for
it is
basically to be able to set it to public and thus effectively disable
this visibility mechanism altogether which I find no use for and
therefore have to circumvent. I'm not sure if anyone else feels the
same
way towards this but I figured it was worth a try.

I'm attaching a preliminary patch against the current revision in case
anyone wants to have a look. The changes are very small and any blatant
mistakes should be immediately obvious. I have to admit to having
virtually no knowledge of the internals of GCC but I have tried to keep
in line with formatting guidelines and general style as well as looking
up the particulars of the way options are handled in the available
documentation to avoid blind copy-pasting. I have also tried to test
the
functionality both in my own (relatively large, or at least not too
small) project and with small test programs and everything works as
expected. Finallly, I tried running the tests too but these fail to
complete both in the patched and unpatched version, possibly due to the
way I've configured GCC.

Dimitris

Re: [PATCH] Change HONOR_REG_ALLOC_ORDER to a marco for C expression

[Kito Cheng]

> Although this patch is safe.  I guess it could wait for stage 1 as right now
> we don't need this functionality.
>
> The patch is ok for the stage1 which is probably about a month away.
>
> Thanks for the patch.

Got it, thanks for your review :)

>
>
>> On Thu, Feb 27, 2014 at 12:32 PM, Kito Cheng  wrote:
>>>
>>> Hi all:
>>>
>>> Sorry for repeat patch content in last mail, here is the clean version
>>> for this patch.
>>>
>>> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
>>> index 7ca47a7..1638332 100644
>>> --- a/gcc/config/arm/arm.h
>>> +++ b/gcc/config/arm/arm.h
>>> @@ -1152,7 +1152,7 @@ extern int arm_regs_in_sequence[];
>>>
>>>   /* Tell IRA to use the order we define rather than messing it up with
>>> its
>>>  own cost calculations.  */
>>> -#define HONOR_REG_ALLOC_ORDER
>>> +#define HONOR_REG_ALLOC_ORDER 1
>>>
>>>   /* Interrupt functions can only use registers that have already been
>>>  saved by the prologue, even if they would normally be
>>> diff --git a/gcc/config/nds32/nds32.h b/gcc/config/nds32/nds32.h
>>> index 38847e5..8f966ec 100644
>>> --- a/gcc/config/nds32/nds32.h
>>> +++ b/gcc/config/nds32/nds32.h
>>> @@ -553,7 +553,7 @@ enum nds32_builtins
>>>
>>>   /* Tell IRA to use the order we define rather than messing it up with
>>> its
>>>  own cost calculations.  */
>>> -#define HONOR_REG_ALLOC_ORDER
>>> +#define HONOR_REG_ALLOC_ORDER 1
>>>
>>>   /* The number of consecutive hard regs needed starting at
>>>  reg "regno" for holding a value of mode "mode".  */
>>> diff --git a/gcc/defaults.h b/gcc/defaults.h
>>> index f94ae17..1c48759 100644
>>> --- a/gcc/defaults.h
>>> +++ b/gcc/defaults.h
>>> @@ -1085,6 +1085,10 @@ see the files COPYING3 and COPYING.RUNTIME
>>> respectively.  If not, see
>>>   #define LOCAL_REGNO(REGNO)  0
>>>   #endif
>>>
>>> +#ifndef HONOR_REG_ALLOC_ORDER
>>> +#define HONOR_REG_ALLOC_ORDER 0
>>> +#endif
>>> +
>>>   /* EXIT_IGNORE_STACK should be nonzero if, when returning from a
>>> function,
>>>  the stack pointer does not matter.  The value is tested only in
>>>  functions that have frame pointers.  */
>>> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
>>> index f204936..c0de478 100644
>>> --- a/gcc/doc/tm.texi
>>> +++ b/gcc/doc/tm.texi
>>> @@ -2044,8 +2044,8 @@ Normally, IRA tries to estimate the costs for
>>> saving a register in the
>>>   prologue and restoring it in the epilogue.  This discourages it from
>>>   using call-saved registers.  If a machine wants to ensure that IRA
>>>   allocates registers in the order given by REG_ALLOC_ORDER even if some
>>> -call-saved registers appear earlier than call-used ones, this macro
>>> -should be defined.
>>> +call-saved registers appear earlier than call-used ones, then define
>>> this
>>> + macro as a C expression to nonzero. Default is 0.
>>>   @end defmac
>>>
>>>   @defmac IRA_HARD_REGNO_ADD_COST_MULTIPLIER (@var{regno})
>>> diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
>>> index 50f412c..d7ae6a7 100644
>>> --- a/gcc/doc/tm.texi.in
>>> +++ b/gcc/doc/tm.texi.in
>>> @@ -1849,8 +1849,8 @@ Normally, IRA tries to estimate the costs for
>>> saving a register in the
>>>   prologue and restoring it in the epilogue.  This discourages it from
>>>   using call-saved registers.  If a machine wants to ensure that IRA
>>>   allocates registers in the order given by REG_ALLOC_ORDER even if some
>>> -call-saved registers appear earlier than call-used ones, this macro
>>> -should be defined.
>>> +call-saved registers appear earlier than call-used ones, then define
>>> this
>>> + macro as a C expression to nonzero. Default is 0.
>>>   @end defmac
>>>
>>>   @defmac IRA_HARD_REGNO_ADD_COST_MULTIPLIER (@var{regno})
>>> diff --git a/gcc/ira-color.c b/gcc/ira-color.c
>>> index c20aaf7..773c86e 100644
>>> --- a/gcc/ira-color.c
>>> +++ b/gcc/ira-color.c
>>> @@ -1599,7 +1599,6 @@ check_hard_reg_p (ira_allocno_t a, int hard_regno,
>>>   }
>>> return j == nregs;
>>>   }
>>> -#ifndef HONOR_REG_ALLOC_ORDER
>>>
>>>   /* Return number of registers needed to be saved and restored at
>>>  function prologue/epilogue if we allocate HARD_REGNO to hold value
>>> @@ -1618,7 +1617,6 @@ calculate_saved_nregs (int hard_regno, enum
>>> machine_mode mode)
>>> nregs++;
>>> return nregs;
>>>   }
>>> -#endif
>>>
>>>   /* Choose a hard register for allocno A.  If RETRY_P is TRUE, it means
>>>  that the function called from function
>>> @@ -1653,11 +1651,9 @@ assign_hard_reg (ira_allocno_t a, bool retry_p)
>>> enum reg_class aclass;
>>> enum machine_mode mode;
>>> static int costs[FIRST_PSEUDO_REGISTER],
>>> full_costs[FIRST_PSEUDO_REGISTER];
>>> -#ifndef HONOR_REG_ALLOC_ORDER
>>> int saved_nregs;
>>> enum reg_class rclass;
>>> int add_cost;
>>> -#endif
>>>   #ifdef STACK_REGS
>>> bool no_stack_reg_p;
>>>   #endif
>>> @@ -1823,19 +1819,21 @@ assign_hard_reg (ira_allocno_t a, bool retry_p)
>>>continue;
>>> cost = costs[i];
>>> full_cost = full_costs[i]

Re: [patch,avr] Device specific instructions support for avr

[Denis Chertykov]

2014-03-06 10:57 GMT+04:00 S, Pitchumani :
> Hi Denis,
>
>> -Original Message-
>> From: Denis Chertykov [mailto:cherty...@gmail.com]
>> Sent: Monday, March 03, 2014 10:45 PM
>> 2014-03-03 13:34 GMT+04:00 S, Pitchumani :
>> > Hi,
>> >
>> > Few AVR Xmega devices have specific instruction support than the
>> architecture
>> > it belongs to. For example atxmega128b1 device has RMW instructions
>> (XCH,LAC,
>> > LAS and LAT) support, but not all avrxmega6 devices have.
>> >
>> > Now, avr-gcc passes architecture name to assembler instead of device
>> name. So,
>> > RMW instructions are not recognized (illegal opcode error) by assembler.
>> >
>> > To address this issue, we could add device specific ISA to device
>> details
>> > in GCC. Driver can pass additional option based on specific ISA that a
>> device
>> > has. Assembler can add device specific ISA to architecture ISA based on
>> the
>> > option it receives.
>> >
>> > I have attached patches for avr-gcc.
>> >
>> > device-specific-isa-avr-gcc.patch:
>> > * Device specific ISA information is added to device details.
>> > * avr-gcc passes -mrmw option to assembler if the selected device
>> > has RMW instruction support.
>>
>> I don't like additional option '-mrmw' because we already have a way
>> for passing device specific ISA.
>> IMHO better to add new avr_arch (ie atxmega128b1 is ARCH_AVRXMEGA6U)
>> GAS already have AVR_ISA_XMEGAU for RMW instructions.
>
> New avr_arch can be added. But there are devices in avrxmega2, 4, 5, 6 and 7
> architectures which has rmw instructions. In this case, new architecture 
> required
> for above variants as well. Also there is DES instruction which is available 
> only
> for few avr devices. So, I thought adding an option will avoid creating many 
> new
> architectures.
>
> Related binutils PR: http://sourceware.org/PR15043
> Related discussion: 
> http://lists.nongnu.org/archive/html/avr-gcc-list/2014-03/msg0.html
>
> Please suggest.

It seems you're right
Please, recreate patches against latest source tree.

Denis.

Re: [PATCH, PR52252] Vectorization for load/store groups of size 3.

[Evgeny Stupachenko]

Missed attachment.

On Thu, Mar 6, 2014 at 6:42 PM, Evgeny Stupachenko  wrote:
> I've separated the patch into 2: cost model tuning and load/store
> groups parallelism.
> SLM tuning was partially introduced in the patch:
> http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00226.html
> The patch introducing vectorization for load/store groups of size 3 attached.
>
> Is it ok for stage1?
>
> ChangeLog:
>
> 2014-03-06  Evgeny Stupachenko  
>
>* tree-vect-data-refs.c (vect_grouped_store_supported): New
>check for stores group of length 3.
>(vect_permute_store_chain): New permutations for stores group of
>length 3.
>(vect_grouped_load_supported): New check for loads group of length 3.
>(vect_permute_load_chain): New permutations for loads group of length 
> 3.
>* tree-vect-stmts.c (vect_model_store_cost): Change cost
>of vec_perm_shuffle for the new permutations.
>(vect_model_load_cost): Ditto.
>
>
>
> On Tue, Feb 11, 2014 at 7:19 PM, Richard Biener  wrote:
>> On Tue, 11 Feb 2014, Evgeny Stupachenko wrote:
>>
>>> Missed patch attached in plain-text.
>>>
>>> I have copyright assignment on file with the FSF covering work on GCC.
>>>
>>> Load/stores groups of length 3 is the most frequent non-power-of-2
>>> case. It is used in RGB image processing (like test case in PR52252).
>>> For sure we can extend the patch to length 5 and more. However, this
>>> potentially affect performance on some other architectures and
>>> requires larger testing. So length 3 it is just first step.The
>>> algorithm in the patch could be modified for a general case in several
>>> steps.
>>>
>>> I understand that the patch should wait for the stage 1, however since
>>> its ready we can discuss it right now and make some changes (like
>>> general size of group).
>>
>> Other than that I'd like to see a vectorizer hook querying the cost of a
>> vec_perm_const expansion instead of adding vec_perm_shuffle
>> (thus requires the constant shuffle mask to be passed as well
>> as the vector type).  That's more useful for other uses that
>> would require (arbitrary) shuffles.
>>
>> Didn't look at the rest of the patch yet - queued in my review
>> pipeline.
>>
>> Thanks,
>> Richard.
>>
>>> Thanks,
>>> Evgeny
>>>
>>> On Tue, Feb 11, 2014 at 5:00 PM, Richard Biener  wrote:
>>> >
>>> > On Tue, 11 Feb 2014, Evgeny Stupachenko wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > The patch gives an expected 3 times gain for the test case in the 
>>> > > PR52252
>>> > > (and even 6 times for AVX2).
>>> > > It passes make check and bootstrap on x86.
>>> > > spec2000/spec2006 got no regressions/gains on x86.
>>> > >
>>> > > Is this patch ok?
>>> >
>>> > I've worked on generalizing the permutation support in the light
>>> > of the availability of the generic shuffle support in the IL
>>> > but hit some road-blocks in the way code-generation works for
>>> > group loads with permutations (I don't remember if I posted all patches).
>>> >
>>> > This patch seems to be to a slightly different place but it again
>>> > special-cases a specific permutation.  Why's that?  Why can't we
>>> > support groups of size 7 for example?  So - can this be generalized
>>> > to support arbitrary non-power-of-two load/store groups?
>>> >
>>> > Other than that the patch has to wait for stage1 to open again,
>>> > of course.  And it misses a testcase.
>>> >
>>> > Btw, do you have a copyright assignment on file with the FSF covering
>>> > work on GCC?
>>> >
>>> > Thanks,
>>> > Richard.
>>> >
>>> > > ChangeLog:
>>> > >
>>> > > 2014-02-11  Evgeny Stupachenko  
>>> > >
>>> > > * target.h (vect_cost_for_stmt): Defining new cost 
>>> > > vec_perm_shuffle.
>>> > > * tree-vect-data-refs.c (vect_grouped_store_supported): New
>>> > > check for stores group of length 3.
>>> > > (vect_permute_store_chain): New permutations for stores group of
>>> > > length 3.
>>> > > (vect_grouped_load_supported): New check for loads group of 
>>> > > length
>>> > > 3.
>>> > > (vect_permute_load_chain): New permutations for loads group of
>>> > > length 3.
>>> > > * tree-vect-stmts.c (vect_model_store_cost): New cost
>>> > > vec_perm_shuffle
>>> > > for the new permutations.
>>> > > (vect_model_load_cost): Ditto.
>>> > > * config/aarch64/aarch64.c (builtin_vectorization_cost): Adding
>>> > > vec_perm_shuffle cost as equvivalent of vec_perm cost.
>>> > > * config/arm/arm.c: Ditto.
>>> > > * config/rs6000/rs6000.c: Ditto.
>>> > > * config/spu/spu.c: Ditto.
>>> > > * config/i386/x86-tune.def (TARGET_SLOW_PHUFFB): Target for slow
>>> > > byte
>>> > > shuffle on some x86 architectures.
>>> > > * config/i386/i386.h (processor_costs): Defining pshuffb cost.
>>> > > * config/i386/i386.c (processor_costs): Adding pshuffb cost.
>>> > > (ix86_builtin_vectorization_cost): Adding cost for the new
>>> > > permutati

Re: [PATCH, PR52252] Vectorization for load/store groups of size 3.

[Evgeny Stupachenko]

I've separated the patch into 2: cost model tuning and load/store
groups parallelism.
SLM tuning was partially introduced in the patch:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00226.html
The patch introducing vectorization for load/store groups of size 3 attached.

Is it ok for stage1?

ChangeLog:

2014-03-06  Evgeny Stupachenko  

   * tree-vect-data-refs.c (vect_grouped_store_supported): New
   check for stores group of length 3.
   (vect_permute_store_chain): New permutations for stores group of
   length 3.
   (vect_grouped_load_supported): New check for loads group of length 3.
   (vect_permute_load_chain): New permutations for loads group of length 3.
   * tree-vect-stmts.c (vect_model_store_cost): Change cost
   of vec_perm_shuffle for the new permutations.
   (vect_model_load_cost): Ditto.



On Tue, Feb 11, 2014 at 7:19 PM, Richard Biener  wrote:
> On Tue, 11 Feb 2014, Evgeny Stupachenko wrote:
>
>> Missed patch attached in plain-text.
>>
>> I have copyright assignment on file with the FSF covering work on GCC.
>>
>> Load/stores groups of length 3 is the most frequent non-power-of-2
>> case. It is used in RGB image processing (like test case in PR52252).
>> For sure we can extend the patch to length 5 and more. However, this
>> potentially affect performance on some other architectures and
>> requires larger testing. So length 3 it is just first step.The
>> algorithm in the patch could be modified for a general case in several
>> steps.
>>
>> I understand that the patch should wait for the stage 1, however since
>> its ready we can discuss it right now and make some changes (like
>> general size of group).
>
> Other than that I'd like to see a vectorizer hook querying the cost of a
> vec_perm_const expansion instead of adding vec_perm_shuffle
> (thus requires the constant shuffle mask to be passed as well
> as the vector type).  That's more useful for other uses that
> would require (arbitrary) shuffles.
>
> Didn't look at the rest of the patch yet - queued in my review
> pipeline.
>
> Thanks,
> Richard.
>
>> Thanks,
>> Evgeny
>>
>> On Tue, Feb 11, 2014 at 5:00 PM, Richard Biener  wrote:
>> >
>> > On Tue, 11 Feb 2014, Evgeny Stupachenko wrote:
>> >
>> > > Hi,
>> > >
>> > > The patch gives an expected 3 times gain for the test case in the PR52252
>> > > (and even 6 times for AVX2).
>> > > It passes make check and bootstrap on x86.
>> > > spec2000/spec2006 got no regressions/gains on x86.
>> > >
>> > > Is this patch ok?
>> >
>> > I've worked on generalizing the permutation support in the light
>> > of the availability of the generic shuffle support in the IL
>> > but hit some road-blocks in the way code-generation works for
>> > group loads with permutations (I don't remember if I posted all patches).
>> >
>> > This patch seems to be to a slightly different place but it again
>> > special-cases a specific permutation.  Why's that?  Why can't we
>> > support groups of size 7 for example?  So - can this be generalized
>> > to support arbitrary non-power-of-two load/store groups?
>> >
>> > Other than that the patch has to wait for stage1 to open again,
>> > of course.  And it misses a testcase.
>> >
>> > Btw, do you have a copyright assignment on file with the FSF covering
>> > work on GCC?
>> >
>> > Thanks,
>> > Richard.
>> >
>> > > ChangeLog:
>> > >
>> > > 2014-02-11  Evgeny Stupachenko  
>> > >
>> > > * target.h (vect_cost_for_stmt): Defining new cost 
>> > > vec_perm_shuffle.
>> > > * tree-vect-data-refs.c (vect_grouped_store_supported): New
>> > > check for stores group of length 3.
>> > > (vect_permute_store_chain): New permutations for stores group of
>> > > length 3.
>> > > (vect_grouped_load_supported): New check for loads group of 
>> > > length
>> > > 3.
>> > > (vect_permute_load_chain): New permutations for loads group of
>> > > length 3.
>> > > * tree-vect-stmts.c (vect_model_store_cost): New cost
>> > > vec_perm_shuffle
>> > > for the new permutations.
>> > > (vect_model_load_cost): Ditto.
>> > > * config/aarch64/aarch64.c (builtin_vectorization_cost): Adding
>> > > vec_perm_shuffle cost as equvivalent of vec_perm cost.
>> > > * config/arm/arm.c: Ditto.
>> > > * config/rs6000/rs6000.c: Ditto.
>> > > * config/spu/spu.c: Ditto.
>> > > * config/i386/x86-tune.def (TARGET_SLOW_PHUFFB): Target for slow
>> > > byte
>> > > shuffle on some x86 architectures.
>> > > * config/i386/i386.h (processor_costs): Defining pshuffb cost.
>> > > * config/i386/i386.c (processor_costs): Adding pshuffb cost.
>> > > (ix86_builtin_vectorization_cost): Adding cost for the new
>> > > permutations.
>> > > Fixing cost for other permutations.
>> > > (expand_vec_perm_even_odd_1): Avoid byte shuffles when they are
>> > > slow (TARGET_SLOW_PHUFFB).
>> > > (ix86_add_stmt_cost): Adding cost when

[build, i386] Improve @tlsldmplt test on Solaris 11/x86

[Rainer Orth]

While checking my TLS LD patch, I noticed that unlike on Solaris
10/x86, the @tlsldmplt configure test was failing on Solaris 11/x86 with
Sun ld.  This went unnoticed since the Solaris 11 ld also supports the
TLS LD code sequence expected by GNU ld.

The failure happens because S11 ld is pickier than its S10 counterpart:

ld: fatal: symbol 'tls_ld' in file tlsldmplt.o (STT_TLS), is defined in a 
non-SHF_TLS section

I've quieted the error by adapting the testcase to work with both
versions.  It requires the infrastructure laid by my previous patch:

http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00225.html

I didn't adapt it to gas/gld (enforcing 32-bit assembly/linking) since
neither supports @tlsldmplt yet.

Bootstrapped without regressions on i386-pc-solaris2.1[01] and
x86_64-unknown-linux-gnu, will commit once the build part of the
previous patch has been approved.

Thanks.
Rainer


2014-03-06  Rainer Orth  

* configure.ac (HAVE_AS_IX86_TLSLDMPLT): Improve test for Solaris
11/x86 ld.
* configure: Regenerate.

# HG changeset patch
# Parent bf7371f29fbafbce722a20c3de6dbe27c6180539
Improve @tlsldmplt test on Solaris 11/x86

diff --git a/gcc/configure.ac b/gcc/configure.ac
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -3920,10 +3920,14 @@ foo:	nop
   [AC_DEFINE(HAVE_AS_IX86_TLSGDPLT, 1,
 [Define if your assembler and linker support @tlsgdplt.])])
 
+conftest_s='
+	.section .tdata,"aw'$tls_section_flag'",@progbits
+tls_ld:
+	.section .text,"ax",@progbits
+	 calltls_ld@tlsldmplt'
 gcc_GAS_CHECK_FEATURE([R_386_TLS_LDM_PLT reloc],
 gcc_cv_as_ix86_tlsldmplt,,,
-	[tls_ld:
-	 calltls_ld@tlsldmplt],
+	[$conftest_s],
 	[if test x$gcc_cv_ld != x \
 	 && $gcc_cv_ld -o conftest conftest.o -G > /dev/null 2>&1; then
 	   gcc_cv_as_ix86_tlsldmplt=yes

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [build, libgcc] Don't install vtv_*.o unless --enable-vtable-verify (PR libgcc/59339)

[Richard Biener]

On Thu, Mar 6, 2014 at 1:13 PM, Paolo Bonzini  wrote:
> Il 06/03/2014 12:55, Rainer Orth ha scritto:
>
>> Uros pointed me at PR libgcc/59339 where make install tries to install
>> the vtv_*.o files even if they aren't built, leading to install
>> warnings.
>>
>> The following patch fixes this by ensuring that the files are only
>> installed if built.
>>
>> Tested with make install in libgcc on x86-64-unknown-linux-gnu
>> --enable-vtable-verify (files are installed) and i686-unknown-linux-gnu
>> (no installation attempted).
>>
>> Ok for mainline?
>>
>> Rainer
>>
>>
>> 2014-03-06  Rainer Orth  
>>
>> PR libgcc/59339
>> * config.host (*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu)
>> (*-*-knetbsd*-gnu, *-*-gnu*, *-*-kopensolaris*-gnu): Only add
>> vtv_*.o to extra_parts if enable_vtable_verify.
>>
>>
>>
>>
>
> Ok.

I wondered why we build libvtv when --enable-vtable-verify is not
enabled.  IMHO that doesn't make sense as you can't use it
anyway because the start files vtv_*.o are neither built nor
installed.

Richard.

> Paolo

Re: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation

[Ilya Verbin]

2014-03-06 15:53 GMT+04:00 Bernd Schmidt :
> No. I don't think we need a global constructor for registering
> __OPENMP_TARGET_HOST__ - this would unnecessarily bloat crtbegin/crtend.  We
> also shouldn't need to have the target tables known outside of the image
> constructed by the mkoffload tools.  The way I imagine it, every mkoffload
> tool creates its own constructor that looks like something like this:
>
>
> __attribute__ ((constructor)) static void
> init (void)
> {
>GOMP_offload_register_target (__OPENMP_TARGET_HOST__,
>  PTX_ID, ptx_target_table);
> }
>
> That creates a mapping between host and target table for PTX_ID. If there
> are multiple shared libraries with offload support, you can still obtain the
> ordering you want from these GOMP_offload_register_target calls. Everything
> is nicely private to the mkoffload-generated image.
>
> It's implemented in almost this fashion (slightly different naming and args,
> and no real support in libgomp) in the patch kit I sent.

OK, now I get it, this looks good. I will rewrite the patch for
libgomp posted above to support this scheme.
Since we will pass __OPENMP_HOST_TABLE__ to GOMP_offload_register,
there is no need to pass it to GOMP_target[data/update], right?

  -- Ilya

Re: [build, libgcc] Don't install vtv_*.o unless --enable-vtable-verify (PR libgcc/59339)

[Paolo Bonzini]

Il 06/03/2014 12:55, Rainer Orth ha scritto:

Uros pointed me at PR libgcc/59339 where make install tries to install
the vtv_*.o files even if they aren't built, leading to install
warnings.

The following patch fixes this by ensuring that the files are only
installed if built.

Tested with make install in libgcc on x86-64-unknown-linux-gnu
--enable-vtable-verify (files are installed) and i686-unknown-linux-gnu
(no installation attempted).

Ok for mainline?

Rainer


2014-03-06  Rainer Orth  

PR libgcc/59339
* config.host (*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu)
(*-*-knetbsd*-gnu, *-*-gnu*, *-*-kopensolaris*-gnu): Only add
vtv_*.o to extra_parts if enable_vtable_verify.






Ok.

Paolo

Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc

[Paulo Matos]

On 06/03/2014 11:19, Richard Biener wrote:


I have reverted the patch for now.

Richard.


That's fine Richard, thanks. I got stuck with another issue in the 
meantime but I will look at it again very soon.


--
Paulo Matos

[build, libgcc] Don't install vtv_*.o unless --enable-vtable-verify (PR libgcc/59339)

[Rainer Orth]

Uros pointed me at PR libgcc/59339 where make install tries to install
the vtv_*.o files even if they aren't built, leading to install
warnings.

The following patch fixes this by ensuring that the files are only
installed if built.

Tested with make install in libgcc on x86-64-unknown-linux-gnu
--enable-vtable-verify (files are installed) and i686-unknown-linux-gnu
(no installation attempted).

Ok for mainline?

Rainer


2014-03-06  Rainer Orth  

PR libgcc/59339
* config.host (*-*-linux*, frv-*-*linux*, *-*-kfreebsd*-gnu)
(*-*-knetbsd*-gnu, *-*-gnu*, *-*-kopensolaris*-gnu): Only add
vtv_*.o to extra_parts if enable_vtable_verify.

# HG changeset patch
# Parent 4abfa544576aa354871a00d4ce08585ae72e8bce
 Don't install vtv_*.o unless --enable-vtable-verify (PR libgcc/59339)

diff --git a/libgcc/config.host b/libgcc/config.host
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -228,7 +228,10 @@ case ${host} in
   ;;
 *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | *-*-gnu* | *-*-kopensolaris*-gnu)
   tmake_file="$tmake_file t-crtstuff-pic t-libgcc-pic t-eh-dw2-dip t-slibgcc t-slibgcc-gld t-slibgcc-elf-ver t-linux"
-  extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o vtv_start.o vtv_end.o vtv_start_preinit.o vtv_end_preinit.o"
+  extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o"
+  if test x$enable_vtable_verify = xyes; then
+extra_parts="$extra_parts vtv_start.o vtv_end.o vtv_start_preinit.o vtv_end_preinit.o"
+  fi
   ;;
 *-*-lynxos*)
   tmake_file="$tmake_file t-lynx $cpu_type/t-crtstuff t-crtstuff-pic t-libgcc-pic"

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation

[Bernd Schmidt]

On 03/06/2014 12:11 PM, Ilya Verbin wrote:


Do I understand correctly, that you propose to do so:

extern void *_omp_host_func_table[];
extern void *_omp_host_var_table[];
extern void *_omp_host_funcs_end[];
extern void *_omp_host_vars_end[];

void *__OPENMP_TARGET_HOST__[]
__attribute__ ((visibility ("protected"))) =
{
   &_omp_host_func_table, &_omp_host_funcs_end,
   &_omp_host_var_table, &_omp_host_vars_end
};


So far, yes (maybe just call it __OPENMP_HOST_TABLE__).


extern void *__OPENMP_TARGET_MIC__[];
extern void *__OPENMP_TARGET_PTX__[];
extern void GOMP_offload_register_host (const void *);
extern void GOMP_offload_register_target (const void *);

__attribute__ ((constructor))
static void
init (void)
{
   GOMP_offload_register_host (__OPENMP_TARGET_HOST__);
   GOMP_offload_register_target (__OPENMP_TARGET_MIC__);
   GOMP_offload_register_target (__OPENMP_TARGET_PTX__);
}

Where __OPENMP_TARGET_MIC__ and __OPENMP_TARGET_PTX__ descriptors
should be generated in the corresponding mkoffload tools.


No. I don't think we need a global constructor for registering 
__OPENMP_TARGET_HOST__ - this would unnecessarily bloat crtbegin/crtend. 
 We also shouldn't need to have the target tables known outside of the 
image constructed by the mkoffload tools.  The way I imagine it, every 
mkoffload tool creates its own constructor that looks like something 
like this:


__attribute__ ((constructor)) static void
init (void)
{
   GOMP_offload_register_target (__OPENMP_TARGET_HOST__,
 PTX_ID, ptx_target_table);
}

That creates a mapping between host and target table for PTX_ID. If 
there are multiple shared libraries with offload support, you can still 
obtain the ordering you want from these GOMP_offload_register_target 
calls. Everything is nicely private to the mkoffload-generated image.


It's implemented in almost this fashion (slightly different naming and 
args, and no real support in libgomp) in the patch kit I sent.



Bernd

[Patch: RL78] Add support for 64-bit doubles

[Kaushik Phatak]

Hi,
Please find below a patch which adds support for 64-bit doubles to the RL78 
target.
This is largely based on the rx target port and uses similar option and 
multilibs.
I will be posting the binutils and newlib part of this patch shortly.

Kindly review the same and let me know if OK to commit.

Thanks & Best Regards,
Kaushik

2013-03-06  Kaushik Phatak  

* config/rl78/rl78.h (TARGET_CPU_CPP_BUILTINS): Define
__RL78_64BIT_DOUBLES__ or __RL78_32BIT_DOUBLES__.
(ASM_SPEC): Pass -m64bit-doubles or -m32bit-doubles on
to the assembler.
(DOUBLE_TYPE_SIZE): Use 64 bit if TARGET_64BIT_DOUBLES
is true.
(LIBGCC2_HAS_DF_MODE): Define based on __RL78_32BIT_DOUBLES__.
(LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Use 64 bit is
__RL78_64BIT_DOUBLES__ is defined.
* gcc/config/rl78/rl78.opt (m64bit-doubles): New option.
(m32bit-doubles) Likewise.
* gcc/config/rl78/t-rl78: Add 64-bit-double multilib.

Index: gcc/config/rl78/rl78.h
===
--- gcc/config/rl78/rl78.h  (revision 208379)
+++ gcc/config/rl78/rl78.h  (working copy)
@@ -23,18 +23,22 @@
 #define RL78_MUL_RL78  (rl78_mul_type == MUL_RL78)
 #define RL78_MUL_G13   (rl78_mul_type == MUL_G13)
 
-#define TARGET_CPU_CPP_BUILTINS()   \
-  do\
-{   \
-  builtin_define ("__RL78__"); \
-  builtin_assert ("cpu=RL78"); \
-  if (RL78_MUL_RL78)   \
-   builtin_define ("__RL78_MUL_RL78__");   \
-  if (RL78_MUL_G13)\
-   builtin_define ("__RL78_MUL_G13__");\
-  if (TARGET_G10)  \
-   builtin_define ("__RL78_G10__");\
-}   \
+#define TARGET_CPU_CPP_BUILTINS()  \
+  do\
+{   \
+  builtin_define ("__RL78__"); \
+  builtin_assert ("cpu=RL78"); \
+  if (RL78_MUL_RL78)   \
+   builtin_define ("__RL78_MUL_RL78__");   \
+  if (RL78_MUL_G13)\
+   builtin_define ("__RL78_MUL_G13__");\
+  if (TARGET_G10)  \
+   builtin_define ("__RL78_G10__");\
+  if (TARGET_64BIT_DOUBLES)\
+builtin_define ("__RL78_64BIT_DOUBLES__");  \
+  else \
+builtin_define ("__RL78_32BIT_DOUBLES__");  \
+}  \
   while (0)
 
 #undef  STARTFILE_SPEC
@@ -47,6 +51,8 @@
 #define ASM_SPEC "\
 %{mrelax:-relax} \
 %{mg10} \
+%{m64bit-doubles:-m64bit-doubles} \
+%{!m64bit-doubles:-m32bit-doubles} \
 "
 
 #undef  LINK_SPEC
@@ -95,11 +101,16 @@
 #define LONG_LONG_TYPE_SIZE64
 
 #define FLOAT_TYPE_SIZE32
-#define DOUBLE_TYPE_SIZE   32 /*64*/
+#define DOUBLE_TYPE_SIZE(TARGET_64BIT_DOUBLES ? 64 : 32)
 #define LONG_DOUBLE_TYPE_SIZE  64 /*DOUBLE_TYPE_SIZE*/
 
-#define LIBGCC2_HAS_DF_MODE1
+#ifdef __RL78_32BIT_DOUBLES__
+#define LIBGCC2_HAS_DF_MODE 0
+#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE   32
+#else
+#define LIBGCC2_HAS_DF_MODE 1
 #define LIBGCC2_LONG_DOUBLE_TYPE_SIZE   64
+#endif
 
 #define DEFAULT_SIGNED_CHAR0
 
Index: gcc/config/rl78/rl78.opt
===
--- gcc/config/rl78/rl78.opt(revision 208379)
+++ gcc/config/rl78/rl78.opt(working copy)
@@ -30,6 +30,14 @@
 Target RejectNegative Joined Var(rl78_mul_type) Report Tolower 
Enum(rl78_mul_types) Init(MUL_NONE)
 Select hardware or software multiplication support.
 
+m64bit-doubles
+Target RejectNegative Mask(64BIT_DOUBLES) Report
+Store doubles in 64 bits.
+
+m32bit-doubles
+Target RejectNegative InverseMask(64BIT_DOUBLES) Report
+Stores doubles in 32 bits.  This is the default
+
 Enum
 Name(rl78_mul_types) Type(enum rl78_mul_types)
 
Index: gcc/config/rl78/t-rl78
===
--- gcc/config/rl78/t-rl78  (revision 208379)
+++ gcc/config/rl78/t-rl78  (working copy)
@@ -23,5 +23,5 @@
 
 # Enable multilibs:
 
-MULTILIB_OPTIONS= mg10
-MULTILIB_DIRNAMES   = g10
+MULTILIB_OPTIONS= mg10 m64bit-doubles
+MULTILIB_DIRNAMES   = g10  64-bit-double

Re: [PATCH] [lto/55113] Fix use of -fshort-double with -flto for powerpc

[Richard Biener]

On Wed, Mar 5, 2014 at 12:55 PM, Paulo Matos  wrote:
> On 05/03/2014 11:51, Richard Biener wrote:
>>
>> On Wed, Mar 5, 2014 at 12:43 PM, Dominique Dhumieres 
>> wrote:
>>>
>>>
>>> Revision 208312 causes
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427
>>
>>
>> Uhm.  pointer comparison against double_type_node ...
>>
>> I'd say we want to revert the patch.  Paulo, please do that.  Let's
>> do the alternate approach of marking -fshort-double eligible for LTO
>> as well and handle it there properly.
>>
>
> Sure, I will prepare a new patch and post it for approval by the end of the
> day.
>
> Apologies for the regression.

I have reverted the patch for now.

Richard.

Re: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation

[Ilya Verbin]

2014-03-06 12:47 GMT+04:00 Bernd Schmidt :
> I don't see why you want the array of target descriptors - it would take
> some effort to construct, and as far as I can tell it's unnecessary. You
> can just pass a pointer to the corresponding descriptor to every
> GOMP_offload_register call.
>
> Once again, that seems unnecessarily complicated. The plugins can register
> their target ID with libgomp, and when libgomp sees a GOMP_offload_register
> call with the corresponding target ID, it can invoke the appropriate plugin
> immediately.

Do I understand correctly, that you propose to do so:

extern void *_omp_host_func_table[];
extern void *_omp_host_var_table[];
extern void *_omp_host_funcs_end[];
extern void *_omp_host_vars_end[];

void *__OPENMP_TARGET_HOST__[]
__attribute__ ((visibility ("protected"))) =
{
  &_omp_host_func_table, &_omp_host_funcs_end,
  &_omp_host_var_table, &_omp_host_vars_end
};

extern void *__OPENMP_TARGET_MIC__[];
extern void *__OPENMP_TARGET_PTX__[];
extern void GOMP_offload_register_host (const void *);
extern void GOMP_offload_register_target (const void *);

__attribute__ ((constructor))
static void
init (void)
{
  GOMP_offload_register_host (__OPENMP_TARGET_HOST__);
  GOMP_offload_register_target (__OPENMP_TARGET_MIC__);
  GOMP_offload_register_target (__OPENMP_TARGET_PTX__);
}

Where __OPENMP_TARGET_MIC__ and __OPENMP_TARGET_PTX__ descriptors
should be generated in the corresponding mkoffload tools.

  -- Ilya

[PATCH] Update -flto docs wrt option handling

[Richard Biener]

This updates the -flto documentation regarding the changes in
option handling.

Comments?

Thanks,
Richard.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 208374)
+++ gcc/doc/invoke.texi (working copy)
@@ -8527,8 +8527,9 @@ file.  When the object files are linked
 bodies are read from these ELF sections and instantiated as if they
 had been part of the same translation unit.
 
-To use the link-time optimizer, @option{-flto} needs to be specified at
-compile time and during the final link.  For example:
+To use the link-time optimizer, @option{-flto} and optimization
+options should be specified at compile time and during the final link.
+For example:
 
 @smallexample
 gcc -c -O2 -flto foo.c
@@ -8558,8 +8559,15 @@ merges them together into a single GIMPL
 them as usual to produce @file{myprog}.
 
 The only important thing to keep in mind is that to enable link-time
-optimizations the @option{-flto} flag needs to be passed to both the
-compile and the link commands.
+optimizations you need to use the GCC driver to perform the link-step.
+GCC then automatically performs link-time optimization if any of the
+objects involved were compiled with the @option{-flto}.  You generally
+should specify the optimization options to be used for link-time
+optimization though GCC will try to be clever at guessing an
+optimization level to use from the options used at compile-time
+if you fail to specify one at link-time.  You can always override
+the automatic decision to do link-time optimization at link-time
+by passing @option{-fno-lto} to the link command.
 
 To make whole program optimization effective, it is necessary to make
 certain whole program assumptions.  The compiler needs to know
@@ -8571,28 +8579,31 @@ the linker plugin is not available, @opt
 used to allow the compiler to make these assumptions, which leads
 to more aggressive optimization decisions.
 
-Note that when a file is compiled with @option{-flto}, the generated
-object file is larger than a regular object file because it 
-contains GIMPLE bytecodes and the usual final code.  This means that
+When @option{-fuse-linker-plugin} is not enabled then, when a file is
+compiled with @option{-flto}, the generated object file is larger than
+a regular object file because it contains GIMPLE bytecodes and the usual
+final code (see @option{-ffat-lto-objects}.  This means that
 object files with LTO information can be linked as normal object
-files; if @option{-flto} is not passed to the linker, no
-interprocedural optimizations are applied.
+files; if @option{-fno-lto} is not passed to the linker, no
+interprocedural optimizations are applied.  Note that when
+@option{-fno-fat-lto-objects} is enabled the compile-stage is faster
+but you cannot perform a regular, non-LTO link, on them.
 
 Additionally, the optimization flags used to compile individual files
 are not necessarily related to those used at link time.  For instance,
 
 @smallexample
-gcc -c -O0 -flto foo.c
-gcc -c -O0 -flto bar.c
-gcc -o myprog -flto -O3 foo.o bar.o
+gcc -c -O0 -ffat-lto-objects -flto foo.c
+gcc -c -O0 -ffat-lto-objects -flto bar.c
+gcc -o myprog -O3 foo.o bar.o
 @end smallexample
 
 This produces individual object files with unoptimized assembler
 code, but the resulting binary @file{myprog} is optimized at
-@option{-O3}.  If, instead, the final binary is generated without
-@option{-flto}, then @file{myprog} is not optimized.
+@option{-O3}.  If, instead, the final binary is generated with
+@option{-fno-lto}, then @file{myprog} is not optimized.
 
-When producing the final binary with @option{-flto}, GCC only
+When producing the final binary, GCC only
 applies link-time optimizations to those files that contain bytecode.
 Therefore, you can mix and match object files and libraries with
 GIMPLE bytecodes and final object code.  GCC automatically selects
@@ -8601,28 +8612,42 @@ further processing.
 
 There are some code generation flags preserved by GCC when
 generating bytecodes, as they need to be used during the final link
-stage.  Currently, the following options are saved into the GIMPLE
-bytecode files: @option{-fPIC}, @option{-fcommon} and all the
-@option{-m} target flags.
-
-At link time, these options are read in and reapplied.  Note that the
-current implementation makes no attempt to recognize conflicting
-values for these options.  If different files have conflicting option
-values (e.g., one file is compiled with @option{-fPIC} and another
-isn't), the compiler simply uses the last value read from the
-bytecode files.  It is recommended, then, that you compile all the files
-participating in the same link with the same options.
+stage.  Generally options specified at link-time override those
+specified at compile-time.
+
+Currently, the following options and their setting are take from
+the first object file that explicitely specified it: 
+@option{-fPIC}, @option{-fpic}, @option{-fpie}

Re: [v3] LWG 2106: move_iterator::reference

[Jonathan Wakely]

On 6 March 2014 09:35, Paolo Carlini wrote:
>
> Agreed. I remember being sloppy about issues not relative to a released
> Standard.

Yes, if it's just a change from one draft to another then it's just
"work in progress" and  not important to record that we've applied a
resolution.

> Well, in fact we also used to keep
>
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/bugs.html
>
> up to date...

Oh yes, I've definitely not been doing that!

Re: [v3] LWG 2106: move_iterator::reference

[Paolo Carlini]

Hi,

On 03/05/2014 10:47 PM, Jonathan Wakely wrote:

On 5 March 2014 21:35, Marc Glisse wrote:

On Wed, 5 Mar 2014, Jonathan Wakely wrote:


Please put _GLIBCXX_RESOLVE_DEFECTS (or whatever
it is we use elsewhere) in the comment, rather than just "DR 2106". I
think the point of that is to be able to grep for all DR fixes
(especially ones that aren't actually accepted as defects yet :-)


Believe it or not, I did look at other occurences in the code, and didn't
hit any that used such a keyword. Now that I know to look for it, there is
indeed _GLIBCXX_RESOLVE_LIB_DEFECTS (I'll add it), but it is missing in a
lot of places.

That's the one. I know I've not always been consistent about adding
it, but I try to when I remember.
Agreed. I remember being sloppy about issues not relative to a released 
Standard. Well, in fact we also used to keep


http://gcc.gnu.org/onlinedocs/libstdc++/manual/bugs.html

up to date...

Paolo.

[gomp4] Merge trunk r208346 (2014-03-05) into gomp-4_0-branch

[Thomas Schwinge]

Hi!

In r208376, I have committed a merge from trunk r208346 (2014-03-05) into
gomp-4_0-branch.


Grüße,
 Thomas


pgp5yuo26q7hH.pgp
Description: PGP signature

Re: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation

[Bernd Schmidt]

On 03/05/2014 06:15 PM, Ilya Verbin wrote:

On 28 Feb 17:21, Bernd Schmidt wrote:

I think it won't help that much - I still think this entire scheme
is likely to fail on nvptx. I'll try to construct an example at
some point.

One other thing about the split tables is that we don't have to
write a useless size of 1 for functions.


The concept of "image" is likely to vary somewhat between
accelerators. For ptx, it's just a string and it can't really be
generated the same way as for your target where you can manipulate
ELF images. So I think it is better to have a call to a gomp
registration function for every offload target. That should also
give you the ordering you said you wanted between shared
libraries.


Probably. I think the constructor call to the gomp registration
function would contain an opaque pointer to whatever data the
target wants, so it can arrange its image/table data in whatever
way it likes.


Assuming that we're using the scheme with tables. Every DSO with
offloading must contain a constructor call to GOMP_offload_register
(const void *openmp_target); The openmp_target descriptor in every
DSO will have target-independent entries (addresses of host tables)
and target-dependent entries for each target. Its format may be like
this:

void *__OPENMP_TARGET__[] = { _omp_host_func_table;
_omp_host_funcs_end; _omp_host_var_table; _omp_host_vars_end;
_omp_num_targets; _omp_target_descs[]; /* array of tgt_desc */ }


I don't see why you want the array of target descriptors - it would take
some effort to construct, and as far as I can tell it's unnecessary. You
can just pass a pointer to the corresponding descriptor to every
GOMP_offload_register call.



struct tgt_desc { int _omp_tgt_id; void *_omp_tgt_%s_image_start;
void *_omp_tgt_%s_image_end; void *_omp_tgt_%s_func_mappings; void
*_omp_tgt_%s_var_mappings; /* some other data if needed */ }


This looks reasonable.


During the devices initialization libgomp will pass the openmp_target
pointer to all plugins. Each plugin will scan over tgt_descs and find
the required entries using the _omp_tgt_id.


Once again, that seems unnecessarily complicated. The plugins can 
register their target ID with libgomp, and when libgomp sees a 
GOMP_offload_register call with the corresponding target ID, it can 
invoke the appropriate plugin immediately.



BTW, do you have any estimate when you will commit your patches to
the branch, so that we could merge them with ours, and get something
working for everybody?


I've been waiting for us to reach agreement on how things should look. 
If there are patches in the series that you're happy with, let me know 
and I can commit them (it may be next week though).



Bernd

Re: [PATCH] Use the LTO linker plugin by default

[Richard Biener]

On Thu, 6 Mar 2014, Jan Hubicka wrote:

> > On Tue, 4 Mar 2014, Jan Hubicka wrote:
> > 
> > > > 
> > > > The following patch addresses the common (?) issue of people
> > > > omitting -flto from the linker command-line which gets more
> > > > severe with GCC 4.9 where slim LTO objects are emitted by
> > > > default.  The patch simply _always_ arranges for the linker
> > > > plugin to be used, so if there are any (slim) LTO objects
> > > > on the link LTO will be done on them.  Similarly the
> > > > non-linker-plugin path in collect2 is adjusted.
> > > > 
> > > > You can still disable this by specifying -fno-lto on the 
> > > > linker command-line.
> > > > 
> > > > One side-effect of enabling the linker-plugin by default
> > > > (for HAVE_LTO_PLUGIN == 2) is that collect2 will then
> > > > use the configured plugin ld rather than the default ld.
> > > > Not sure if that is desired.
> > > > 
> > > > Comments?
> > > 
> > > I like it; it was on my TODO list, but I was only worried about
> > > --with-plugin-ld and did not find time, yet, to look into the 
> > > consequences.
> > > These days, I do not think we need to worry much aboud --with-plugin-ld.
> > 
> > Yeah, I think we should eventually remove that capability.
> > 
> > Now as of the two patches (compute a default link-time optimization
> > level and this patch, make considering LTO at link-time the default),
> > they only make sense together (at least the default opt level at
> > link-time doesn't improve real-world situations without also considering
> > all links to be possibly -flto).
> > 
> > So the question remains if we want to have both patches at this
> > stage or if we want to wait with them for 4.10 (we do have the
> > user-visible change of slim-lto objects by default with 4.9
> > already).
> 
> I think it makes things easier, so I would like to see this in 4.9

Ok.  I'll push this to trunk now and then prepare a documentation
update for LTO opts handling (as promised some time ago ...).

If any issues show up with these two patches then we'll revert
and revisit this for 4.10.

Thanks,
Richard.

Commit: MSP430: Add hardware multiply routines to libgcc

[Nick Clifton]

Hi Guys,

  I am applying the patch below to add libgcc functions to support
  hardware multiplies on the MSP430.

Cheers
  Nick
  
libgcc/ChangeLog
2014-03-06  Nick Clifton  

* config/msp430/t-msp430 (LIB2ADD): Add lib2hw_mul.S
* config/msp430/lib2hw_mul.S: New: Hardware multiply routines.

Index: libgcc/config/msp430/lib2hw_mul.S
===
--- libgcc/config/msp430/lib2hw_mul.S   (revision 0)
+++ libgcc/config/msp430/lib2hw_mul.S   (working copy)
@@ -0,0 +1,226 @@
+;   Copyright (C) 2014 Free Software Foundation, Inc.
+;   Contributed by Red Hat.
+; 
+; This file 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 file 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
+; .
+
+.macro start_func name
+   .pushsection .text.\name,"ax",@progbits
+   .align 2
+   .global \name
+   .type \name , @function
+\name:
+   PUSH.W  sr  ; Save current interrupt state
+   DINT; Disable interrupts
+   NOP ; Account for latency
+.endm
+
+.macro end_func name
+#ifdef __MSP430X_LARGE__
+   POP.W  sr
+RETA
+#else
+   RETI
+#endif
+   .size \name , . - \name
+   .popsection
+.endm
+
+.macro mult16 OP1, OP2, RESULT
+;* * 16-bit hardware multiply:  int16 = int16 * int16
+;*  
+;*   - Operand 1 is in R12
+;*   - Operand 2 is in R13
+;*   - Result is in R12
+;*
+;* To ensure that the multiply is performed atomically, interrupts are
+;* disabled upon routine entry.  Interrupt state is restored upon exit.
+;*
+;*   Registers used:  R12, R13
+;*
+;* Macro arguments are the memory locations of the hardware registers.
+   
+   MOV.W   r12, &\OP1  ; Load operand 1 into multiplier
+   MOV.W   r13, &\OP2  ; Load operand 2 which triggers MPY
+   MOV.W   &\RESULT, r12   ; Move result into return register
+.endm
+
+.macro mult1632 OP1, OP2, RESULT_LO, RESULT_HI
+;* * 16-bit hardware multiply with a 32-bit result:
+;* int32 = int16 * int16
+;* uint32 = uint16 * uint16
+;*  
+;*   - Operand 1 is in R12
+;*   - Operand 2 is in R13
+;*   - Result is in R12, R13
+;*
+;* To ensure that the multiply is performed atomically, interrupts are
+;* disabled upon routine entry.  Interrupt state is restored upon exit.
+;*
+;*   Registers used:  R12, R13
+;*
+;* Macro arguments are the memory locations of the hardware registers.
+   
+   MOV.W   r12, &\OP1  ; Load operand 1 into multiplier
+   MOV.W   r13, &\OP2  ; Load operand 2 which triggers MPY
+   MOV.W   &\RESULT_LO, r12; Move low result into return register
+   MOV.W   &\RESULT_HI, r13; Move high result into return register
+.endm
+
+.macro mult32 OP1, OP2, MAC_OP1, MAC_OP2, RESULT_LO, RESULT_HI
+;* * 32-bit hardware multiply with a 32-bit result using 16 multiply and 
accumulate:
+;* int32 = int32 * int32
+;*  
+;*   - Operand 1 is in R12, R13
+;*   - Operand 2 is in R14, R15
+;*   - Resultis in R12, R13
+;*
+;* To ensure that the multiply is performed atomically, interrupts are
+;* disabled upon routine entry.  Interrupt state is restored upon exit.
+;*
+;*   Registers used:  R12, R13, R14, R15
+;*
+;* Macro arguments are the memory locations of the hardware registers.
+   
+   MOV.W   r12, &\OP1  ; Load operand 1 Low into multiplier
+   MOV.W   r14, &\OP2  ; Load operand 2 Low which triggers MPY
+   MOV.W   r12, &\MAC_OP1  ; Load operand 1 Low into mac
+   MOV.W   &\RESULT_LO, r12; Low 16-bits of result ready for return
+   MOV.W   &\RESULT_HI, &\RESULT_LO; MOV intermediate mpy high into low
+   MOV.W   r15, &\MAC_OP2  ; Load operand 2 High, trigger MAC
+   MOV.W   r13, &\MAC_OP1  ; Load operand 1 High
+   MOV.W   r14, &\MAC_OP2  ; Load operand 2 Lo, trigger MAC
+   MOV.W   &\RESULT_LO, r13; Upper 16-bits result ready for return
+.endm
+
+
+.macro mult32_hw  OP1_LO  OP1_HI  OP2_LO  OP2_HI  RESULT_LO  RESULT_HI
+;* * 32-bit hardware multiply with a 32-bit result
+;* int32 =

[committed] Avoid -Wsign-compare warning on 4.8 branch

[Jakub Jelinek]

Hi!

I've noticed a new -Wsign-compare warning on 4.8 branch, this
patch just changes the code to look like on the trunk.
This is all guarded with if (dist > 0), so the cast is harmless.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed
to trunk as obvious.

2014-03-06  Jakub Jelinek  

PR tree-optimization/60276
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Avoid
a -Wsign-compare warning.

--- gcc/tree-vect-data-refs.c.jj2014-03-05 21:55:53.0 +0100
+++ gcc/tree-vect-data-refs.c   2014-03-05 22:38:29.004898095 +0100
@@ -744,7 +744,7 @@ vect_analyze_data_ref_dependence (struct
 Only need to handle read-after-write dependence.  */
  if (DR_IS_READ (drb)
  && (STMT_VINFO_MIN_NEG_DIST (stmtinfo_b) == 0
- || STMT_VINFO_MIN_NEG_DIST (stmtinfo_b) > dist))
+ || STMT_VINFO_MIN_NEG_DIST (stmtinfo_b) > (unsigned)dist))
STMT_VINFO_MIN_NEG_DIST (stmtinfo_b) = dist;
  continue;
}

Jakub

Backports to 4.8 branch

[Jakub Jelinek]

Hi!

I've backported a few bugfixes to 4.8 branch, bootstrapped/regtested on
x86_64-linux and i686-linux, committed to branch.

Jakub
2014-03-06  Jakub Jelinek  

PR preprocessor/60400
Backport from mainline
2013-06-24  Dehao Chen  

* files.c (_cpp_stack_include): Fix the highest_location when header
file is guarded by #ifndef and is included twice.

2014-03-03  Jakub Jelinek  

PR preprocessor/60400
* c-c++-common/cpp/pr60400.c: New test.
* c-c++-common/cpp/pr60400-1.h: New file.
* c-c++-common/cpp/pr60400-2.h: New file.

--- libcpp/files.c  (revision 200375)
+++ libcpp/files.c  (revision 200376)
@@ -983,6 +983,7 @@ _cpp_stack_include (cpp_reader *pfile, c
 {
   struct cpp_dir *dir;
   _cpp_file *file;
+  bool stacked;
 
   dir = search_path_head (pfile, fname, angle_brackets, type);
   if (!dir)
@@ -993,19 +994,26 @@ _cpp_stack_include (cpp_reader *pfile, c
   if (type == IT_DEFAULT && file == NULL)
 return false;
 
-  /* Compensate for the increment in linemap_add that occurs in
- _cpp_stack_file.  In the case of a normal #include, we're
- currently at the start of the line *following* the #include.  A
- separate source_location for this location makes no sense (until
- we do the LC_LEAVE), and complicates LAST_SOURCE_LINE_LOCATION.
- This does not apply if we found a PCH file (in which case
- linemap_add is not called) or we were included from the
- command-line.  */
+  /* Compensate for the increment in linemap_add that occurs if
+  _cpp_stack_file actually stacks the file.  In the case of a
+ normal #include, we're currently at the start of the line
+ *following* the #include.  A separate source_location for this
+ location makes no sense (until we do the LC_LEAVE), and
+ complicates LAST_SOURCE_LINE_LOCATION.  This does not apply if we
+ found a PCH file (in which case linemap_add is not called) or we
+ were included from the command-line.  */
   if (file->pchname == NULL && file->err_no == 0
   && type != IT_CMDLINE && type != IT_DEFAULT)
 pfile->line_table->highest_location--;
 
-  return _cpp_stack_file (pfile, file, type == IT_IMPORT);
+  stacked = _cpp_stack_file (pfile, file, type == IT_IMPORT);
+
+  if (!stacked)
+/* _cpp_stack_file didn't stack the file, so let's rollback the
+   compensation dance we performed above.  */
+pfile->line_table->highest_location++;
+
+  return stacked;
 }
 
 /* Could not open FILE.  The complication is dependency output.  */
--- gcc/testsuite/c-c++-common/cpp/pr60400.c(revision 0)
+++ gcc/testsuite/c-c++-common/cpp/pr60400.c(revision 208272)
@@ -0,0 +1,13 @@
+/* PR preprocessor/60400 */
+/* { dg-do compile } */
+/* { dg-options "-trigraphs -Wtrigraphs" } */
+
+??=include "pr60400-1.h"
+??=include "pr60400-2.h"
+
+/* { dg-warning "trigraph" "" { target *-*-* } 1 } */
+/* { dg-warning "trigraph" "" { target *-*-* } 2 } */
+/* { dg-warning "trigraph" "" { target *-*-* } 3 } */
+/* { dg-warning "trigraph" "" { target *-*-* } 4 } */
+/* { dg-warning "trigraph" "" { target *-*-* } 5 } */
+/* { dg-warning "trigraph" "" { target *-*-* } 6 } */
--- gcc/testsuite/c-c++-common/cpp/pr60400-1.h  (revision 0)
+++ gcc/testsuite/c-c++-common/cpp/pr60400-1.h  (revision 208272)
@@ -0,0 +1,3 @@
+??=ifndef PR60400_1_H
+??=define PR60400_1_H
+??=endif
--- gcc/testsuite/c-c++-common/cpp/pr60400-2.h  (revision 0)
+++ gcc/testsuite/c-c++-common/cpp/pr60400-2.h  (revision 208272)
@@ -0,0 +1,4 @@
+??=ifndef PR60400_2_H
+??=define PR60400_2_H
+??=include "pr60400-1.h"
+??=endif
2014-03-06  Jakub Jelinek  

Backport from mainline
2014-02-05  Jakub Jelinek  

PR middle-end/57499
* tree-eh.c (cleanup_empty_eh): Bail out on totally empty
bb with no successors.

* g++.dg/torture/pr57499.C: New test.

--- gcc/tree-eh.c   (revision 207503)
+++ gcc/tree-eh.c   (revision 207504)
@@ -4396,8 +4396,11 @@ cleanup_empty_eh (eh_landing_pad lp)
   /* If the block is totally empty, look for more unsplitting cases.  */
   if (gsi_end_p (gsi))
 {
-  /* For the degenerate case of an infinite loop bail out.  */
-  if (infinite_empty_loop_p (e_out))
+  /* For the degenerate case of an infinite loop bail out.
+If bb has no successors and is totally empty, which can happen e.g.
+because of incorrect noreturn attribute, bail out too.  */
+  if (e_out == NULL
+ || infinite_empty_loop_p (e_out))
return ret;
 
   return ret | cleanup_empty_eh_unsplit (bb, e_out, lp);
--- gcc/testsuite/g++.dg/torture/pr57499.C  (revision 0)
+++ gcc/testsuite/g++.dg/torture/pr57499.C  (revision 207504)
@@ -0,0 +1,14 @@
+// PR middle-end/57499
+// { dg-do compile }
+
+struct S
+{
+  ~S () __attribute__ ((noreturn)) {} // { dg-warning "function does return" }
+};
+
+void
+foo ()
+{
+  S s;
+  throw 1;
+}
2014-03-06  Jakub Jelinek  

Re: [PATCH ARM]: Fix more -mapcs-frame failures

[Ramana Radhakrishnan]

On Mon, Feb 24, 2014 at 9:11 AM, Christian Bruel  wrote:
> This patch improves the one sent previously,
> (http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01159.html),  to fix a few
> more failures in the testsuite that could arise with shrink-wrap and
> -fexceptions.
>
> To recall, the problem that it fixes is that with -mapcs-frame :
>
> -  the epilogue pops as
>
>  sub sp, fp, #12 @ does not set FRAME_RELATED_P
>  ldmia   sp, {fp, sp, lr}  @ XXX assert  def_cfa->reg is FP instead
> of SP
>
> - with vrp this is worse, we have
>
>fldmfdd ip!, {d8}@ FRAME_RELATED_P
>sub sp, fp, #20   ...
>ldmfd   sp, {r3, r4, fp, sp, pc}  @ XXX assert def_cfa->reg is IP
> instead of SP,
>
> Fixed by inserting a REG_CFA_DEF_CFA note, fixing the arm_unwind_emit
> machinery and setting the FRAME_RELATED_P . The comment says :
>
> /* The INSN is generated in epilogue.  It is set as RTX_FRAME_RELATED_P
>to get correct dwarf information for shrink-wrap.  We should not
>emit unwind information for it because these are used either for
>pretend arguments or notes to adjust sp and restore registers from
>stack.  */
>
> the  testsuite score improves without regression (improvements from -g
> and -fexeptions tests)
>
> === gcc Summary for arm-sim//-mapcs-frame ===
>
> # of expected passes77545
> # of unexpected failures31
> # of unexpected successes2
> # of expected failures172
> # of unsupported tests1336
>
>  === g++ Summary for arm-sim//-mapcs-frame ===
>
> # of expected passes50116
> # of unexpected failures9
> # of unexpected successes3
> # of expected failures280
> # of unsupported tests1229
>
> instead of
>
> === gcc Summary for arm-sim//-mapcs-frame ===
>
> # of expected passes77106
> # of unexpected failures500
> # of unexpected successes2
> # of expected failures172
> # of unresolved testcases111
> # of unsupported tests1336
>
> === g++ Summary for arm-sim//-mapcs-frame ===
>
> # of expected passes50021
> # of unexpected failures136
> # of unexpected successes3
> # of expected failures280
> # of unsupported tests1229
>
> Comments ? OK for trunk ?
>
> Many thanks
>
>

Please respin using plus_constant instead of gen_addsi3. Otherwise
this looks good to me.

Please repost updated patch and I will look at it again.


Ramana

Re: [PATCH, ARM] ICE when building kernel raid6 neon code

[Ramana Radhakrishnan]

On Tue, Jan 28, 2014 at 3:37 AM, Zhenqiang Chen
 wrote:
> On 28 January 2014 01:07, Ramana Radhakrishnan
>  wrote:
>> On Thu, Jan 16, 2014 at 5:44 AM, Zhenqiang Chen
>>  wrote:
>>> Thanks for comments.
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59837
>>>
>>> The patch with a test case is attached.
>>
>>
>>> +/* { dg-options " -Os -fno-omit-frame-pointer -mapcs -mabi=aapcs-linux 
>>> -marm  -mfloat-abi=softfp  -g " } */
>>
>> Can you instead do ?
>>
>> { dg-options "-Os -fno-omit-frame-pointer -mapcs" }
>> { dg-add-options arm_neon }
>>
>> I don't like this as it as it stands because the test relies on the
>> compiler being configured for neon by default.
>
> Thanks. The test case is updated according to your comments.
>
> The patch is also updated to skip dwarf info in function
> arm_emit_multi_reg_pop when shrink-wrap is not enabled. A new test
> case (pr59837-1.c) is added to reproduce the issue. And I double check
> the arm_expand_epilogue_apcs_frame. There is no more function which
> adds REG_CFA_ADJUST_CFA NOTE.


This is OK if no regressions and an RM doesn't object in 24 hours.
maps-frame is used in the kernel so fixing this up for 4.9 would be
good.

Cheers,
Ramana

>
> Thanks!
> -Zhenqiang
>
>
>>> 2014-01-16  Zhenqiang Chen  
>>>
>>> PR target/59837
>>> * config/arm/arm.c (arm_emit_vfp_multi_reg_pop): Do not add
>>> REG_CFA_ADJUST_CFA NOTE if shrink-wrap is not enabled.
>>>
>>> testsuite/ChangeLog:
>>> 2014-01-16  Zhenqiang Chen  
>>>
>>> * gcc.target/arm/pr59837.c: New testcase.
>>>
>>> On 15 January 2014 19:56, Ramana Radhakrishnan
>>>  wrote:
 Please also create a bugzilla entry for this and use the pr number here.

 Ramana


 Sent from Samsung Mobile



  Original message 
 From: Zhenqiang Chen 
 Date:
 To: gcc-patches@gcc.gnu.org
 Cc: Richard Earnshaw ,Ramana Radhakrishnan
 
 Subject: [PATCH, ARM] ICE when building kernel raid6 neon code


 Hi,

 The patch fixes ICE when building kernel raid6 neon code.

 lib/raid6/neon4.c: In function 'raid6_

 neon4_gen_syndrome_real':
 lib/raid6/neon4.c:113:1: internal compiler error: in
 dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1090
  }

 https://bugs.launchpad.net/gcc-linaro/+bug/1268893

 Root cause:
 When expanding epilogue, REG_CFA_ADJUST_CFA NOTE is added to handle
 dwarf info issue for shrink-wrap. But for TARGET_APCS_FRAME,
 shrink-wrap is disabled. And not all dwarf info in
 arm_expand_epilogue_apcs_frame are correctly updated.
 arm_emit_vfp_multi_reg_pop is called by both
 arm_expand_epilogue_apcs_frame and arm_expand_epilogue. So we should
 not add the NOTE in arm_emit_vfp_multi_reg_pop if shrink-wrap is not
 enabled.

 Boot strap and no make check regression on ARM Chromebook.

 OK for trunk?

 Thanks!
 -Zhenqiang

 ChangeLog:
 2014-01-15  Zhenqiang Chen  

 * config/arm/arm.c (arm_emit_vfp_multi_reg_pop): Do not add
 REG_CFA_ADJUST_CFA NOTE if shrink-wrap is not enabled.

 diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
 index 18196b3..1ccb796 100644
 --- a/gcc/config/arm/arm.c
 +++ b/gcc/config/arm/arm.c
 @@ -19890,8 +19890,12 @@ arm_emit_vfp_multi_reg_pop (int first_reg,
 int num_regs, rtx base_reg)
par = emit_insn (par);
REG_NOTES (par) = dwarf;

 -  arm_add_cfa_adjust_cfa_note (par, 2 * UNITS_PER_WORD * num_regs,
 -  base_reg, base_reg);
 +  /* REG_CFA_ADJUST_CFA NOTE is added to handle dwarf info issue when
 + shrink-wrap is enabled.  So when shrink-wrap is not enabled, we 
 should
 + not add the note.  */
 +  if (flag_shrink_wrap)
 +arm_add_cfa_adjust_cfa_note (par, 2 * UNITS_PER_WORD * num_regs,
 +base_reg, base_reg);
  }

  /* Generate and emit a pattern that will be recognized as LDRD
 pattern.  If even


 -- IMPORTANT NOTICE: The contents of this email and any attachments are
 confidential and may also be privileged. If you are not the intended
 recipient, please notify the sender immediately and do not disclose the
 contents to any other person, use it for any purpose, or store or copy the
 information in any medium. Thank you.

 ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
 Registered in England & Wales, Company No: 2557590
 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
 Registered in England & Wales, Company No: 2548782