Re: Remove mode argument from gen_rtx_SET

2015-05-09 Thread Richard Sandiford
DJ Delorie  writes:
>> ; This pattern is identical to the truncsipsi2 pattern except
>> ; that it uses a SUBREG instead of a TRUNC.  It is needed in
>> ; order to prevent reload from converting (set:SI (SUBREG:PSI (SI)))
>> ; into (SET:PSI (PSI)).
>> 
>> I'm not sure what that's supposed to mean (what's an SI set of a PSI
>> subreg?), but I suspect removing the mode would lose information,
>> so I left it alone.
>
> MSP430 has 20-bit registers (PSImode-sized).  One register can hold an
> HI or PSI sized value, but if you have an SI value it's stored as two
> HI registers.
>
> Thus, a PSImode value in a register is *not* just the 20 LSB of an
> SImode value.  Also, a PSImode subset of an SI value is stored
> different than a PSImode value on its own.
>
> Thus, consider code like this:
>
> (set (reg:SI 1)
>  (subreg:PSI (reg:SI 2)))
>
> (set (reg:PSI 1)
>  (reg:PSI 2))
>
> On most architectures, you'd say "these do the same thing" but on
> MSP430 they don't.

What I was confused about is that the first set isn't valid rtl.
The SET_SRC and SET_DEST always have to have the same mode
(or VOIDmode in the case of a CONST_INT, etc., where the mode
is implicitly the same as the SET_DEST).  So wouldn't it have
to be:

  (set (reg:SI 1)
   (subreg:SI (reg:PSI 2)))

or:

  (set (reg:PSI 1)
   (subreg:PSI (reg:SI 2)))

?

Thanks,
Richard



Re: [patch] defer C++ mangling aliases

2015-05-09 Thread Dominique Dhumieres
> ...
> I have tested it independently of everything else, 
> and would like permission to commit it to mainline.
> ...

This caused https://gcc.gnu.org/ml/gcc-bugs/2015-05/msg00748.html

Dominique


Re: PATCHes to help with C++11 bootstrap

2015-05-09 Thread Richard Biener
On May 9, 2015 6:30:49 AM GMT+02:00, Jason Merrill  wrote:
>One C++11 compatibility issue that turns up a lot in the GCC sources is
>
>that in C++98,
>
>#define BAR "bar"
>const char *p = "foo"BAR;
>
>is well-formed, giving p the value "foobar".  But in C++11 this is a 
>user-defined literal with the suffix BAR, which is ill-formed because 
>there is no BAR suffix defined.
>
>-Wc++11-compat didn't warn about this, which I'm fixing with the first 
>patch.
>
>The second patch fixes all the occurrences in GCC.
>
>The third patch fixes the warning to say "-Wc++11-compat" rather than 
>"-Wc++0x-compat".
>
>The fourth patch fixes a few G++ tests that were failing with the 
>compiler defaulting to C++11.
>
>Tested x86_64-cp-linux-gnu, applying to trunk.

Hmm, I wonder if we want to bootstrap with explicit -std=gnu04, our host 
compiler requirement.  Otherwise we'll silently sneak in C++11 features when 
that becomes the default?

Richard.




Re: [patch 1/10] debug-early merge: Ada front-end

2015-05-09 Thread Eric Botcazou
> My question exactly.  Perhaps that was my confusion.  Why is this using
> ->global_decl?

Because that's equivalent to ->type_decl (iter, false) in DWARF.

> For example, the C front-end uses rest_of_type_compilation (see
> finish_struct() in c/c-decl.c) which calls ->type_decl(), or it calls
> ->type_decl() from record_builtin_type().

All right, let's follow the gospel then. :-)  Patch attached and installed.

> I can put the code back, but calling ->type_decl()?  Assuming you folks
> (Ada) don't want to use rest_of_type_compilation().

No, we don't use it for local types either (it's a no-op in DWARF in this case 
and we don't support STABS anymore because of the need to manually delay the 
generation of debug info for local types, which is a real pain in Ada).


* gcc-interface/utils.c (gnat_write_global_declarations): Use type_decl
method instead of global_decl for TYPE_DECLs.


-- 
Eric BotcazouIndex: gcc-interface/utils.c
===
--- gcc-interface/utils.c	(revision 222673)
+++ gcc-interface/utils.c	(working copy)
@@ -5211,7 +5211,7 @@ gnat_write_global_declarations (void)
  finalized in the right context.  */
   FOR_EACH_VEC_SAFE_ELT (global_decls, i, iter)
 if (TREE_CODE (iter) == TYPE_DECL && !DECL_IGNORED_P (iter))
-  debug_hooks->global_decl (iter);
+  debug_hooks->type_decl (iter, false);
 
   /* Proceed to optimize and emit assembly. */
   symtab->finalize_compilation_unit ();

Re: [patch 1/10] debug-early merge: Ada front-end

2015-05-09 Thread Eric Botcazou
> Ah, I see what you mean.  I'll address this and repost.

Thanks.  Did the first version pass the GDB testsuite?  I thought we had a 
testcase exercising the pointer to Taft amendment type case in it.

-- 
Eric Botcazou


Re: [patch, Fortran] Fix PR 66041

2015-05-09 Thread Mikael Morin
Hello,

Le 09/05/2015 00:11, Thomas Koenig a écrit :
> Index: frontend-passes.c
> ===
> --- frontend-passes.c (Revision 222864)
> +++ frontend-passes.c (Arbeitskopie)
> @@ -2611,14 +2611,40 @@ scalarized_expr (gfc_expr *e_in, gfc_expr **index,
>   {
> /* Look at full individual sections, like a(:).  The 
> first index
>is the lbound of a full ref.  */
> -
> +   int j;
> gfc_array_ref *ar;
> +   gfc_expr *lbound_e;
>  
> -   ar = gfc_find_array_ref (e_in);
> +   lbound_e = gfc_copy_expr (e_in);
> +   ar = gfc_find_array_ref (lbound_e);
> +
> ar->type = AR_FULL;
> +   for (j = 0; j < ar->dimen; j++)
> + {
> +   gfc_free_expr (ar->start[j]);
> +   ar->start[j] = NULL;
> +   gfc_free_expr (ar->end[j]);
> +   ar->end[j] = NULL;
> +   gfc_free_expr (ar->stride[j]);
> +   ar->stride[j] = NULL;
> + }
> +
You also need to remove/free the trailing subreferences.

> +   /* We have to get rid of the shape, if thre is one.  Do
> +  so by freeing it and calling gfc_resolve to rebuild it,
> +  if necessary.  */
> +  
> +   if (lbound_e->shape)
> + gfc_free_shape (&(lbound_e->shape), lbound_e->rank);
> +

> +   lbound_e->rank = ar->dimen;
ar->dimen is  not what you think it is.
It is 3 for array(1, 1, :), while the rank is 1.
gfc_resolve_expr should set the rank for you, so just remove this line.

> + 
> +   gfc_resolve_expr (lbound_e);
> +   lbound = get_array_inq_function (GFC_ISYM_LBOUND,
> +lbound_e, i + 1);
free lbound_e?

>   }
> -   lbound = get_array_inq_function (GFC_ISYM_LBOUND, e_in,
> -i_index + 1);
> +   else
> + lbound = get_array_inq_function (GFC_ISYM_LBOUND, e_in,
> +  i_index + 1);
You can't reuse e_in if it has subreferences.

One suggestion: you may want to move all the above to a function
extracting the full array.

>   }
> 
> ar->dimen_type[i] = DIMEN_ELEMENT;
> @@ -2639,6 +2665,8 @@ scalarized_expr (gfc_expr *e_in, gfc_expr **index,
> i_index ++;
>   }
>  }
> +  gfc_free_expr (e_in);
> +
This side effect is asking for trouble.
Instead of this, remove the copies made in the callers.
This is independant from the rest, so it can be made later as a follow-up.

>return e;
>  }
>  
> 

I attach a variant of your inline_matmul_8.f90 that is not working yet
because of subreferences.

Mikael



--- inline_matmul_8.f90.old	2015-05-09 13:31:28.420790646 +0200
+++ inline_matmul_8.f90	2015-05-09 13:42:50.741799982 +0200
@@ -3,15 +3,22 @@
 ! PR 66041 - this used to ICE with an incomplete fix for the PR.
 program main
   implicit none
-  real, dimension(1,-2:0) :: a1
+  type :: t
+real :: c
+  end type t
+  type(t), dimension(1,-2:0) :: a1
   real, dimension(3,2) :: b1
   real, dimension(2) :: c1
+  real, dimension(1,2) :: c2
 
-  data a1 /17., -23., 29./
+  data a1%c /17., -23., 29./
   data b1 / 2.,  -3.,  5.,  -7., 11., -13./
 
-  c1 = matmul(a1(1,:), b1)
+  c1 = matmul(a1(1,:)%c, b1)
   if (any (c1-[248., -749.] /= 0.)) call abort
+
+  c2 = matmul(a1%c, b1)
+  if (any (c2-reshape([248., -749.],shape(c2)) /= 0.)) call abort
 end program main
 
 ! { dg-final { scan-tree-dump-times "_gfortran_matmul" 0 "original" } }




Re: conditional lim

2015-05-09 Thread Andi Kleen
Evgeniya Maenkova  writes:
>
> So, in my opinion it’s ok to generate additional phi node for debug
> case. But I’m not a compiler expert and maybe there is some
> requirement that debug and non-debug versions should differ only by
> debug statements, I don’t know.

gcc has such a requirement.

Otherwise you cannot debug code that was originally not compiled
with debugging.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only


Re: [Patch, fortran] PR65792 - allocation of scalar elemental function with structure constructor fails

2015-05-09 Thread Mikael Morin
Le 01/05/2015 20:25, Paul Richard Thomas a écrit :
> Dear All,
> 
> By the time I went to commit, something had changed and the patch
> caused a regression. I presume that the version that I had of Andre's
> patch was not the same as the one committed. I'll cast an eye over it
> this weekend and see if I can understand what gives.
> 
Hello Paul,

to get things moving again, I propose the attached fix to your patch.
Tested on alloc_comp_deep_copy_1 only for now.

Mikael



diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 6cf5fe2..532f4b7 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -7078,7 +7078,8 @@ gfc_trans_subcomponent_assign (tree dest, gfc_component * cm, gfc_expr * expr,
 	}
 	  gfc_add_modify (&block, dest,
 			  fold_convert (TREE_TYPE (dest), se.expr));
-	  if (cm->ts.u.derived->attr.alloc_comp)
+	  if (cm->ts.u.derived->attr.alloc_comp
+	  && expr->expr_type != EXPR_NULL)
 	{
 	  tmp = gfc_copy_alloc_comp (cm->ts.u.derived, se.expr,
 	 dest, expr->rank);



Re: [patch] defer C++ mangling aliases

2015-05-09 Thread Aldy Hernandez

On 05/09/2015 02:53 AM, Dominique Dhumieres wrote:

...
I have tested it independently of everything else,
and would like permission to commit it to mainline.
...


This caused https://gcc.gnu.org/ml/gcc-bugs/2015-05/msg00748.html

Dominique



Fixed with the following patch.

Committed as obvious.

commit 3e820aa6675e608371ccf4f2ae691baa15a4be7f
Author: Aldy Hernandez 
Date:   Sat May 9 06:47:33 2015 -0700

PR bootstrap/66085
* decl2.c (note_mangling_alias): Declare arguments as unused.

diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 6101301..27bacab 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -4327,7 +4327,7 @@ generate_mangling_alias (tree decl, tree id2)
implementation.  */
 
 void
-note_mangling_alias (tree decl, tree id2)
+note_mangling_alias (tree decl ATTRIBUTE_UNUSED, tree id2 ATTRIBUTE_UNUSED)
 {
 #ifdef ASM_OUTPUT_DEF
   if (at_eof)


Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

2015-05-09 Thread Szabolcs Nagy
* H.J. Lu  [2015-04-17 05:36:30 -0700]:
> On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek  wrote:
> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
> >> > I don't like it.  Nonshared libgcc is libgcc.a, period.  No sense in
> >> > creating yet another library for that.
> >> > So, IMHO beyond making the __cpu* entrypoints compat symbols only (@ 
> >> > instead
> >> > of @@ symbol versions) the right fix is simply tweak init_gcc_spec, so 
> >> > that
> >> > static_name is always linked in, in the switch combinations that it isn't
> >> > right now of course after shared_name rather than before that.
> >> > I thought we've fixed that years ago...
> >> >

I think the patch committed for this is suboptimal.
(it breaks with musl libc on x86 if libgcc_s is linked into a binary)

the patch:
http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00878.html
original thread:
http://gcc.gnu.org/ml/gcc-patches/2015-03/msg01520.html

The symbol versioning hack for __cpu_model and __cpu_indicator_init
makes them invisible to the musl dynamic linker so their relocation
fails with 'symbol not found' error.
(affects anything linked with -lgcc_s)

I don't yet understand all the constraints, what I gathered is

* x86 multi-versioning was broken with libgcc_s because ifunc
resolution tried to use a libgcc_s function before it was relocated.
(mv dispatch uses ifunc before relocation is finished, that calls
__builtin_cpu_init that turns into a call to __cpu_indicator_init
that is a constructor in libgcc_s.so to initialize __cpu_model).

* old binaries that happened to work still have to work with new
libgcc_s.so so __cpu_* must have a definition there.

* new binaries must get their own definition of __cpu_*
(ie statically linked from libgcc.a) to avoid the ifunc issue.

I would rename the __cpu_* symbols and put those only in libgcc.a
while keeping the old __cpu_* symbols still available in
libgcc_s.so: old binaries work with new gcc, new binaries get the
right definitions (so they work on old systems and new systems
too, and yes -lgcc should be passed to c++ dso linking).
Did i miss something?

(This is not in the gcc-5 branch so I assume It is OK to work
on a less intrusive fix.)


PS.: It would be nice if there was a specification for the ifunc
interface contract before any ifunc/multiversioned interface gets
into the compiler runtime (see libatomic.so) to avoid similar bugs
and incompatibilities between the dynamic linker/loader and compiler,
the dynamic linker cannot guarantee arbitrary ifunc calls to work.


> >>
> >> We never pass -lgcc to linker when building C++ DSO:
> >>
> >>  /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/collect2 -plugin
> >> /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/liblto_plugin.so
> >> -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
> >> -plugin-opt=-fresolution=/tmp/ccZC7iqy.res
> >> -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
> >> -plugin-opt=-pass-through=-lgcc_s --build-id --no-add-needed
> >> --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -shared
> >> /usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64/crti.o
> >> /usr/lib/gcc/x86_64-redhat-linux/4.9.2/crtbeginS.o
> >> -L/usr/lib/gcc/x86_64-redhat-linux/4.9.2
> >> -L/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64
> >> -L/lib/../lib64 -L/usr/lib/../lib64
> >> -L/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../.. x.o -lstdc++ -lm
> >> -lgcc_s -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.9.2/crtendS.o
> >> /usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64/crtn.o
> >> [hjl@gnu-32 tmp]$
> >>
> >> That is why libgcc_nonshared.a is needed.
> >
> > See what I wrote.  I think it is a bug that we don't do that, in your case
> > we should pass -lgcc_s -lgcc -lc -lgcc_s -lgcc.
> > Or, if you don't want to change that, as the multi-versioning change is
> > i386/x86_64 only change, just ensure that those targets have
> > t-slibgcc-libgcc in libgcc/config.host and thus behave like most other linux
> > targets where -lgcc is linked in always after -lgcc_s.
> >
> > Jakub
> 
> This patch works for me.  OK for trunk?
> 
> gcc/testsuite/
> 
> PR target/65612
> * g++.dg/ext/mv18.C: New test.
> * g++.dg/ext/mv19.C: Likewise.
> * g++.dg/ext/mv20.C: Likewise.
> * g++.dg/ext/mv21.C: Likewise.
> * g++.dg/ext/mv22.C: Likewise.
> * g++.dg/ext/mv23.C: Likewise.
> 
> libgcc/
> 
> PR target/65612
> * config.host (tmake_file): Add t-slibgcc-libgcc for Linux/x86.
> * config/i386/cpuinfo.c (__cpu_model): Initialize.
> (__cpu_indicator_init@GCC_4.8.0): New.
> (__cpu_model@GCC_4.8.0): Likewise.
> * config/i386/t-linux (HOST_LIBGCC2_CFLAGS): Add
> -DUSE_ELF_SYMVER.
> 
> Thanks.
> 
> -- 
> H.J.




Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

2015-05-09 Thread H.J. Lu
On Mon, May 4, 2015 at 7:45 AM, Michael Matz  wrote:
> Hi,
>
> On Thu, 30 Apr 2015, Sriraman Tallam wrote:
>
>> We noticed that one of our benchmarks sped-up by ~1% when we eliminated
>> PLT stubs for some of the hot external library functions like memcmp,
>> pow.  The win was from better icache and itlb performance. The main
>> reason was that the PLT stubs had no spatial locality with the
>> call-sites. I have started looking at ways to tell the compiler to
>> eliminate PLT stubs (in-effect inline them) for specified external
>> functions, for x86_64. I have a proposal and a patch and I would like to
>> hear what you think.
>>
>> This comes with caveats.  This cannot be generally done for all
>> functions marked extern as it is impossible for the compiler to say if a
>> function is "truly extern" (defined in a shared library). If a function
>> is not truly extern(ends up defined in the final executable), then
>> calling it indirectly is a performance penalty as it could have been a
>> direct call.
>
> This can be fixed by Alans idea.
>
>> Further, the newly created GOT entries are fixed up at
>> start-up and do not get lazily bound.
>
> And this can be fixed by some enhancements in the linker and dynamic
> linker.  The idea is to still generate a PLT stub and make its GOT entry
> point to it initially (like a normal got.plt slot).  Then the first
> indirect call will use the address of PLT entry (starting lazy resolution)
> and update the GOT slot with the real address, so further indirect calls
> will directly go to the function.
>
> This requires a new asm marker (and hence new reloc) as normally if
> there's a GOT slot it's filled by the real symbols address, unlike if
> there's only a got.plt slot.  E.g. a
>
>   call *foo@GOTPLT(%rip)
>
> would generate a GOT slot (and fill its address into above call insn), but
> generate a JUMP_SLOT reloc in the final executable, not a GLOB_DAT one.
>

I added the "relax" prefix support to x86 assembler on users/hjl/relax
branch

at

https://sourceware.org/git/?p=binutils-gdb.git;a=summary

[hjl@gnu-tools-1 relax-3]$ cat r.S
.text
relax jmp foo
relax call foo
relax jmp foo@plt
relax call foo@plt
[hjl@gnu-tools-1 relax-3]$ ./as -o r.o r.S
[hjl@gnu-tools-1 relax-3]$ ./objdump -drw r.o

r.o: file format elf64-x86-64


Disassembly of section .text:

 <.text>:
   0: 66 e9 00 00 00 00 data16 jmpq 0x6 2: R_X86_64_RELAX_PC32 foo-0x4
   6: 66 e8 00 00 00 00 data16 callq 0xc 8: R_X86_64_RELAX_PC32 foo-0x4
   c: 66 e9 00 00 00 00 data16 jmpq 0x12 e: R_X86_64_RELAX_PLT32foo-0x4
  12: 66 e8 00 00 00 00 data16 callq 0x18 14: R_X86_64_RELAX_PLT32foo-0x4
[hjl@gnu-tools-1 relax-3]$

Right now, the relax relocations are treated as PC32/PLT32 relocations.
I am working on linker support.

-- 
H.J.


[RFC, PATCH] nonzero attribute, static array parameter

2015-05-09 Thread Martin Uecker

Hi,

here is a tentative patch to implement a new attribute nonzero,
which is similar to nonnull, but is not a function attribute
but a type attribute.

One reason is that nonnull is awkward to use. For this reason,
clang allows the use of nonnull in function parameters, but this
is incompatible with old and current use of this attribute in gcc
(though in a rather obscure use case).
See: https://gcc.gnu.org/ml/gcc/2015-05/msg00077.html

The other reason is that a nonzero type attribute is conceptually
much simpler and at the same time more general than the existing
nonnull and nonnull_return function attributes (and could replace
both), e.g. we can define non-zero types and diagnose all stores
of known constant 0 to variables of this type, use this for 
computing better value ranges, etc.

This patch implements the attribute and adds a warning if a 
zero constant is passed as argument with nonzero type attribute.
Also infer_nonnull_range in gcc/gimple.c is extended to make use 
of the attribute (which in turn is used by ubsan).

In addition, in C the attribute is automatically added to
pointers declared as array parameters with static, e.g:

void foo(int a[static 5]);


Martin

(tested on x86_64-unknown-linux-gnu)






diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 77d9352..2f79344 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-05-09  Martin Uecker  
+
+	* gcc/gimple.c (infer_nonnull_range): Process nonzero attribute.
+	* doc/invoki.texi
+
 2015-05-08  Jim Wilson  
 
 	* doc/install.texi (--enable-languages): Add missing jit and lto info.
diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
index 57f83c9..809ecf1 100644
--- a/gcc/c-family/ChangeLog
+++ b/gcc/c-family/ChangeLog
@@ -1,3 +1,9 @@
+2015-05-09  Martin Uecker  
+
+	* c-common.c (handle_nonzero_attribute): New.
+	(check_function_nonzero): New.
+	(check_nonzero_arg): New.
+
 2015-05-08  Marek Polacek  
 
 	PR c/64918
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 378f237..46fe749 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -380,6 +380,7 @@ static tree handle_deprecated_attribute (tree *, tree, tree, int,
 static tree handle_vector_size_attribute (tree *, tree, tree, int,
 	  bool *);
 static tree handle_nonnull_attribute (tree *, tree, tree, int, bool *);
+static tree handle_nonzero_attribute (tree *, tree, tree, int, bool *);
 static tree handle_nothrow_attribute (tree *, tree, tree, int, bool *);
 static tree handle_cleanup_attribute (tree *, tree, tree, int, bool *);
 static tree handle_warn_unused_result_attribute (tree *, tree, tree, int,
@@ -407,6 +408,7 @@ static tree handle_bnd_instrument (tree *, tree, tree, int, bool *);
 
 static void check_function_nonnull (tree, int, tree *);
 static void check_nonnull_arg (void *, tree, unsigned HOST_WIDE_INT);
+static void check_nonzero_arg (void *, tree, unsigned HOST_WIDE_INT);
 static bool nonnull_check_p (tree, unsigned HOST_WIDE_INT);
 static bool get_nonnull_operand (tree, unsigned HOST_WIDE_INT *);
 static int resort_field_decl_cmp (const void *, const void *);
@@ -751,6 +753,8 @@ const struct attribute_spec c_common_attribute_table[] =
 			  handle_tls_model_attribute, false },
   { "nonnull",0, -1, false, true, true,
 			  handle_nonnull_attribute, false },
+  { "nonzero",0, -1, false, true, false,
+  handle_nonzero_attribute, false },
   { "nothrow",0, 0, true,  false, false,
 			  handle_nothrow_attribute, false },
   { "may_alias",	  0, 0, false, true, false, NULL, false },
@@ -8940,6 +8944,26 @@ handle_vector_size_attribute (tree *node, tree name, tree args,
   return NULL_TREE;
 }
 
+
+/* Handle the "nonzero" attribute.  */
+static tree
+handle_nonzero_attribute (tree *node, tree ARG_UNUSED (name),
+			  tree ARG_UNUSED (args), int ARG_UNUSED (flags),
+			  bool *no_add_attrs)
+{
+  tree n = *node;
+
+  if ((TREE_CODE (n) != POINTER_TYPE)
+  && (TREE_CODE (n) != INTEGER_TYPE))
+{
+  warning (OPT_Wattributes, "%qE attribute ignored", name);
+  *no_add_attrs = true;
+}
+
+  return NULL_TREE;
+}
+
+
 /* Handle the "nonnull" attribute.  */
 static tree
 handle_nonnull_attribute (tree *node, tree ARG_UNUSED (name),
@@ -9016,6 +9040,34 @@ handle_nonnull_attribute (tree *node, tree ARG_UNUSED (name),
   return NULL_TREE;
 }
 
+
+static void
+check_function_nonzero (const_tree fntype, int nargs, tree *argarray)
+{
+  if (TREE_CODE (fntype) != FUNCTION_TYPE) // C++ lambdas
+return;
+
+  function_args_iterator iter;
+  tree type;
+  int i = 0;
+
+  FOREACH_FUNCTION_ARGS (fntype, type, iter)
+{
+  if (i == nargs)
+	break;
+
+  tree a = lookup_attribute ("nonzero", TYPE_ATTRIBUTES (type));
+
+  if (a != NULL_TREE)
+check_function_arguments_recurse (check_nonzero_arg, NULL,
+	  argarray[i], i + 1);
+
+  i++;
+   }
+}
+
+
+
 /* Check the argument list of a function call 

Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

2015-05-09 Thread H.J. Lu
On Sat, May 9, 2015 at 7:31 AM, Szabolcs Nagy  wrote:
> * H.J. Lu  [2015-04-17 05:36:30 -0700]:
>> On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek  wrote:
>> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
>> >> > I don't like it.  Nonshared libgcc is libgcc.a, period.  No sense in
>> >> > creating yet another library for that.
>> >> > So, IMHO beyond making the __cpu* entrypoints compat symbols only (@ 
>> >> > instead
>> >> > of @@ symbol versions) the right fix is simply tweak init_gcc_spec, so 
>> >> > that
>> >> > static_name is always linked in, in the switch combinations that it 
>> >> > isn't
>> >> > right now of course after shared_name rather than before that.
>> >> > I thought we've fixed that years ago...
>> >> >
>
> I think the patch committed for this is suboptimal.
> (it breaks with musl libc on x86 if libgcc_s is linked into a binary)
>
> the patch:
> http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00878.html
> original thread:
> http://gcc.gnu.org/ml/gcc-patches/2015-03/msg01520.html
>
> The symbol versioning hack for __cpu_model and __cpu_indicator_init
> makes them invisible to the musl dynamic linker so their relocation
> fails with 'symbol not found' error.
> (affects anything linked with -lgcc_s)

There are

 4: 2b70   806 FUNCGLOBAL DEFAULT   12
__cpu_indicator_init@GCC_4.8.0
38: 002153d016 OBJECT  GLOBAL DEFAULT   25 __cpu_model@GCC_4.8.0

and

0215000  00040001 R_X86_64_64
2b70 __cpu_indicator_init@GCC_4.8.0 + 0
00215220  00260006 R_X86_64_GLOB_DAT
002153d0 __cpu_model@GCC_4.8.0 + 0

in libgcc_s.so.1.  Musl ld.so must be fixed to handle it.



-- 
H.J.


[PATCH] D demangle: Correctly decode white or non-printable characters

2015-05-09 Thread Iain Buclaw
D templates can have string literals encoded inside them, which can
also include tabs, newlines, and other whitespace characters.  For
example:

return getHost!q{
auto he = gethostbyname(toStringz(param));
}(name);


In this case, rather than decoding and writing out every character
directly, whitespace or other non-printable characters should be
represented as escape sequences.

---
libiberty/ChangeLog:

2015-05-09 Iain Buclaw  

* d-demangle.c (dlang_parse_string): Represent embedded whitespace or
non-printable characters as hex or escape sequences.
* testsuite/d-demangle-expected: Add test for templates with tabs and
newlines embedded into the signature.
---
diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index bb481c0..fa01767 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -931,7 +931,38 @@ dlang_parse_string (string *decl, const char *mangled)
 	  char a = ascii2hex (mangled[0]);
 	  char b = ascii2hex (mangled[1]);
 	  char val = (a << 4) | b;
-	  string_appendn (decl, &val, 1);
+
+	  /* Sanitize white and non-printable characters.  */
+	  switch (val)
+	{
+	case ' ':
+	  string_append (decl, " ");
+	  break;
+	case '\t':
+	  string_append (decl, "\\t");
+	  break;
+	case '\n':
+	  string_append (decl, "\\n");
+	  break;
+	case '\r':
+	  string_append (decl, "\\r");
+	  break;
+	case '\f':
+	  string_append (decl, "\\f");
+	  break;
+	case '\v':
+	  string_append (decl, "\\v");
+	  break;
+
+	default:
+	  if (ISPRINT (val))
+		string_appendn (decl, &val, 1);
+	  else
+		{
+		  string_append (decl, "\\x");
+		  string_appendn (decl, mangled, 2);
+		}
+	}
 	}
   else
 	return NULL;
diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected
index 2aeacb8..b023f6d 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -934,3 +934,7 @@ serenity.persister.Sqlite.SqlitePersister!(serenity.persister.Sqlite.__unittest6
 --format=dlang
 _D4test4mainFZv5localMFZi
 test.main().local()
+#
+--format=dlang
+_D3std6socket12InternetHost221__T13getHostNoSyncVAyaa96_0a09202020206175746f2078203d2068746f6e6c28706172616d293b0a09202020206175746f206865203d20676574686f73746279616464722826782c20342c206361737428696e74294164647265737346616d696c792e494e4554293b0a09TkZ13getHostNoSyncMFkZb
+std.socket.InternetHost.getHostNoSync!("\n\tauto x = htonl(param);\n\tauto he = gethostbyaddr(&x, 4, cast(int)AddressFamily.INET);\n\t", uint).getHostNoSync(uint)


[PATCH] D demangle: Include type modifiers in demangled function symbols

2015-05-09 Thread Iain Buclaw
Like C++ const and volatile, in D mangled symbols can exist modifiers
that represent the const, immutable, inout and shared-ness of the
'this' parameter.

This information should be written out in the demangled symbol to show
that each variant has a unique identity.

---
libiberty/ChangeLog:

2015-05-09 Iain Buclaw  
* d-demangle.c (dlang_type_modifiers): New function.
(dlang_type_modifier_p): New function.
(dlang_call_convention_p): Ignore any kind of type modifier.
(dlang_parse_symbol): Emit the type modifier after the symbol.
* testsuite/d-demangle-expected: Add coverage tests for all valid
usages of functions symbols with type modifiers.
---
diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index bb481c0..9e6c46f 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -692,6 +692,44 @@ dlang_identifier (string *decl, const char *mangled)
   return mangled;
 }
 
+/* Extract the type modifiers from MANGLED and append them to DECL.
+   Returns the remaining signature on success or NULL on failure.  */
+static const char *
+dlang_type_modifiers (string *decl, const char *mangled)
+{
+  if (mangled == NULL || *mangled == '\0')
+return mangled;
+
+  switch (*mangled)
+{
+case 'x': /* const */
+  mangled++;
+  string_append (decl, " const");
+  return mangled;
+case 'y': /* immutable */
+  mangled++;
+  string_append (decl, " immutable");
+  return mangled;
+case 'O': /* shared */
+  mangled++;
+  string_append (decl, " shared");
+  return dlang_type_modifiers (decl, mangled);
+case 'N':
+  mangled++;
+  if (*mangled == 'g') /* wild */
+	{
+	  mangled++;
+	  string_append (decl, " inout");
+	  return dlang_type_modifiers (decl, mangled);
+	}
+  else
+	return NULL;
+
+default:
+  return mangled;
+}
+}
+
 /* Extract the integer value from MANGLED and append it to DECL,
where TYPE is the type it should be represented as.
Return the remaining string on success or NULL on failure.  */
@@ -1104,6 +1142,41 @@ dlang_value (string *decl, const char *mangled, const char *name, char type)
   return mangled;
 }
 
+/* Extract the type modifiers from MANGLED and return the string
+   length that it consumes in MANGLED on success or 0 on failure.  */
+static int
+dlang_type_modifier_p (const char *mangled)
+{
+  int i;
+
+  switch (*mangled)
+{
+case 'x': case 'y':
+  return 1;
+
+case 'O':
+  mangled++;
+  i = dlang_type_modifier_p (mangled);
+  return i + 1;
+
+case 'N':
+  mangled++;
+  if (*mangled == 'g')
+	{
+	  mangled++;
+	  i = dlang_type_modifier_p (mangled);
+	  return i + 2;
+	}
+
+default:
+  break;
+}
+
+  return 0;
+}
+
+/* Extract the function calling convention from MANGLED and
+   return 1 on success or 0 on failure.  */
 static int
 dlang_call_convention_p (const char *mangled)
 {
@@ -1116,9 +1189,9 @@ dlang_call_convention_p (const char *mangled)
   return 1;
 
 case 'M': /* Prefix for functions needing 'this' */
-  i = 1;
-  if (mangled[i] == 'x')
-	i++;
+  mangled++;
+  /* Skip over any type modifiers.  */
+  i = dlang_type_modifier_p (mangled);
 
   switch (mangled[i])
 	{
@@ -1147,11 +1220,16 @@ dlang_parse_symbol (string *decl, const char *mangled)
 
   if (mangled && dlang_call_convention_p (mangled))
 	{
+	  string mods;
 	  int saved;
 
 	  /* Skip over 'this' parameter.  */
 	  if (*mangled == 'M')
-	mangled += (mangled[1] == 'x') ? 2 : 1;
+	mangled++;
+
+	  /* Save the type modifiers for appending at the end.  */
+	  string_init (&mods);
+	  mangled = dlang_type_modifiers (&mods, mangled);
 
 	  /* Skip over calling convention and attributes in qualified name.  */
 	  saved = string_length (decl);
@@ -1170,6 +1248,10 @@ dlang_parse_symbol (string *decl, const char *mangled)
 	  mangled = dlang_type (decl, mangled);
 	  string_setlength (decl, saved);
 	}
+
+	  /* Add any const/immutable/shared modifier. */
+	  string_appendn (decl, mods.b, string_length (&mods));
+	  string_delete (&mods);
 	}
 }
   while (mangled && ISDIGIT (*mangled));
diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected
index 2aeacb8..358372a 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -753,6 +753,38 @@ demangle.test!(demangle.S(1, 2))
 _D8demangle35__T4testVS8demangle1SS2i1a3_616263Zv
 demangle.test!(demangle.S(1, "abc"))
 #
+--format=dlang
+_D8demangle4testMxFZv
+demangle.test() const
+#
+--format=dlang
+_D8demangle4testMyFZv
+demangle.test() immutable
+#
+--format=dlang
+_D8demangle4testMNgFZv
+demangle.test() inout
+#
+--format=dlang
+_D8demangle4testMNgxFZv
+demangle.test() inout const
+#
+--format=dlang
+_D8demangle4testMOFZv
+demangle.test() shared
+#
+--format=dlang
+_D8demangle4testMOxFZv
+demangle.test() shared const
+#
+--format=dlang
+_D8demangle4testMONgFZv
+demangle.

Re: PATCHes to help with C++11 bootstrap

2015-05-09 Thread Markus Trippelsdorf
On 2015.05.08 at 23:30 -0500, Jason Merrill wrote:
> One C++11 compatibility issue that turns up a lot in the GCC sources is 
> that in C++98,
> 
> #define BAR "bar"
> const char *p = "foo"BAR;
> 
> is well-formed, giving p the value "foobar".  But in C++11 this is a 
> user-defined literal with the suffix BAR, which is ill-formed because 
> there is no BAR suffix defined.
> 
> -Wc++11-compat didn't warn about this, which I'm fixing with the first 
> patch.
> 
> The second patch fixes all the occurrences in GCC.
> 
> The third patch fixes the warning to say "-Wc++11-compat" rather than 
> "-Wc++0x-compat".

This also enables the following bogus warning:

 ~ % cat test.cpp
template  struct X {};
template  struct Y { static int const c = 0; };
int main() { return Y>::c; }

 ~ % g++ -Wall -std=c++11 test.cpp
test.cpp: In function ‘int main()’:
test.cpp:3:26: warning: ‘>>’ operator is treated as two right angle brackets in 
C++11 [-Wc++11-compat]
 int main() { return Y>::c; }
  ^
test.cpp:3:26: note: suggest parentheses around ‘>>’ expression

-- 
Markus


Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

2015-05-09 Thread Szabolcs Nagy
* H.J. Lu  [2015-05-09 10:41:41 -0700]:
> On Sat, May 9, 2015 at 7:31 AM, Szabolcs Nagy  wrote:
> >
> > The symbol versioning hack for __cpu_model and __cpu_indicator_init
> > makes them invisible to the musl dynamic linker so their relocation
> > fails with 'symbol not found' error.
> > (affects anything linked with -lgcc_s)
> 
> There are
> 
>  4: 2b70   806 FUNCGLOBAL DEFAULT   12
> __cpu_indicator_init@GCC_4.8.0
> 38: 002153d016 OBJECT  GLOBAL DEFAULT   25 
> __cpu_model@GCC_4.8.0
> 
> and
> 
> 0215000  00040001 R_X86_64_64
> 2b70 __cpu_indicator_init@GCC_4.8.0 + 0
> 00215220  00260006 R_X86_64_GLOB_DAT
> 002153d0 __cpu_model@GCC_4.8.0 + 0
> 
> in libgcc_s.so.1.  Musl ld.so must be fixed to handle it.
> 

(sorry, i missed the other discussion about the same issue)

i still think a solution that avoids depending on symbol
versioning in the dynamic linker would be preferable.
(versioning is a sun/gnu elf extension as far as i understand,
eg. not supported by posix dlsym).

i think it might be enough to add __cpu_indicator_init_local
as an alias to __cpu_indicator_init in libgcc.a and then use
the *_local symbol from the ifunc resolver, that way no new
dependency is added to libgcc_s.so handling.

(adding versioning support to musl is problematic with the
current code, a simpler workaround for musl is to provide its
own weak definition of __cpu_indicator_init, but that's ugly.)


Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

2015-05-09 Thread Rich Felker
On Sat, May 09, 2015 at 10:41:41AM -0700, H.J. Lu wrote:
> On Sat, May 9, 2015 at 7:31 AM, Szabolcs Nagy  wrote:
> > * H.J. Lu  [2015-04-17 05:36:30 -0700]:
> >> On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek  wrote:
> >> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
> >> >> > I don't like it.  Nonshared libgcc is libgcc.a, period.  No sense in
> >> >> > creating yet another library for that.
> >> >> > So, IMHO beyond making the __cpu* entrypoints compat symbols only (@ 
> >> >> > instead
> >> >> > of @@ symbol versions) the right fix is simply tweak init_gcc_spec, 
> >> >> > so that
> >> >> > static_name is always linked in, in the switch combinations that it 
> >> >> > isn't
> >> >> > right now of course after shared_name rather than before that.
> >> >> > I thought we've fixed that years ago...
> >> >> >
> >
> > I think the patch committed for this is suboptimal.
> > (it breaks with musl libc on x86 if libgcc_s is linked into a binary)
> >
> > the patch:
> > http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00878.html
> > original thread:
> > http://gcc.gnu.org/ml/gcc-patches/2015-03/msg01520.html
> >
> > The symbol versioning hack for __cpu_model and __cpu_indicator_init
> > makes them invisible to the musl dynamic linker so their relocation
> > fails with 'symbol not found' error.
> > (affects anything linked with -lgcc_s)
> 
> There are
> 
>  4: 2b70   806 FUNCGLOBAL DEFAULT   12
> __cpu_indicator_init@GCC_4.8.0
> 38: 002153d016 OBJECT  GLOBAL DEFAULT   25 
> __cpu_model@GCC_4.8.0
> 
> and
> 
> 0215000  00040001 R_X86_64_64
> 2b70 __cpu_indicator_init@GCC_4.8.0 + 0
> 00215220  00260006 R_X86_64_GLOB_DAT
> 002153d0 __cpu_model@GCC_4.8.0 + 0
> 
> in libgcc_s.so.1.  Musl ld.so must be fixed to handle it.

The intent in musl was always not to support symbol versioning. There
are various reasons for this, which I could go into, but I'd rather
not turn this thread into an argument about the merits of symbol
versioning.

Originally, musl ignored the version data completely, and would
happily have resolved the above symbol, but this also led to problems
where third-party libraries used symbol versioning and at runtime we
got the oldest-versioned symbol instead of the desired current one. So
I changed the lookup to use the same logic as ld, rejecting all
symbols with the hidden bit set, and getting us the newest one (which
is the only one we intended to support).

We can't just do the same version processing as glibc because we want
symbols in libc itself to resolve regardless of the version in the
reference (this is needed for the glibc ABI compat we provide). It
might work to honor symbol versions only when the library being
searched has versions, and otherwise allow symbols to match any
version requested, but I haven't thought this through entirely yet.

In any case I'd like the decision for what musl does about symbol
versions (which are not intended to be supported, anyway) to be
independent of libgcc's solution of this problem. We can solve it with
a hack on our side (just providing dummy symbols by those names) but
that's ugly too and I'd rather not do it.

Could you clarify the reasoning for why libgcc is using this hack with
a reference to an 'obsolete' symbol version rather than just
visibility?

Rich


Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

2015-05-09 Thread Jakub Jelinek
On Sat, May 09, 2015 at 03:36:01PM -0400, Rich Felker wrote:
> Could you clarify the reasoning for why libgcc is using this hack with
> a reference to an 'obsolete' symbol version rather than just
> visibility?

Obviously for ABI compatibility reasons.  Older programs could be relying on
the symbols exported from libgcc_s.so.1 in the past.  We need to keep those
working, just don't want to allow linking new programs against this symbol
(because new programs should get their copy from libgcc.a now).

Jakub


Re: v3 PATCH to fix libstdc++ build/test with C++11 default compiler

2015-05-09 Thread Jason Merrill

On 05/08/2015 11:34 PM, Jason Merrill wrote:

The second patch fixes all but one of the testsuite failures that turned
up with a compiler that defaults to C++11.


And here's the fix for a C++14 compiler:


commit 42dc3f6f9af19c12d4201af8b6ef2e28bb08e944
Author: Jason Merrill 
Date:   Sat May 9 12:51:20 2015 -0500

	* testsuite/20_util/headers/functional/synopsis.cc: Add
	_GLIBCXX14_CONSTEXPR.
	* testsuite/25_algorithms/headers/algorithm/synopsis.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/20_util/headers/functional/synopsis.cc b/libstdc++-v3/testsuite/20_util/headers/functional/synopsis.cc
index 03d37a6..5e561de 100644
--- a/libstdc++-v3/testsuite/20_util/headers/functional/synopsis.cc
+++ b/libstdc++-v3/testsuite/20_util/headers/functional/synopsis.cc
@@ -50,9 +50,11 @@ namespace std {
   //  lib.negators, negators:
   template  struct unary_negate;
   template 
+  _GLIBCXX14_CONSTEXPR
   unary_negate  not1(const Predicate&);
   template  struct binary_negate;
   template 
+  _GLIBCXX14_CONSTEXPR
   binary_negate not2(const Predicate&);
 
   //  lib.binders, binders:
diff --git a/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/synopsis.cc b/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/synopsis.cc
index ba38f25..4758796 100644
--- a/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/synopsis.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/synopsis.cc
@@ -483,75 +483,93 @@ namespace std
 
   // 25.3.7, minimum and maximum:
   template 
+_GLIBCXX14_CONSTEXPR
 const _Tp& 
 min(const _Tp&, const _Tp&);
 
   template
+_GLIBCXX14_CONSTEXPR
 const _Tp& 
 min(const _Tp&, const _Tp&, _Compare);
 
   template 
+_GLIBCXX14_CONSTEXPR
 const _Tp& 
 max(const _Tp&, const _Tp&);
 
   template
+_GLIBCXX14_CONSTEXPR
 const _Tp& 
 max(const _Tp&, const _Tp&, _Compare);
 
   template
+_GLIBCXX14_CONSTEXPR
 _FIter 
 min_element(_FIter, _FIter);
 
   template
+_GLIBCXX14_CONSTEXPR
 _FIter 
 min_element(_FIter, _FIter, _Compare);
 
   template
+_GLIBCXX14_CONSTEXPR
 _FIter 
 max_element(_FIter, _FIter);
 
   template
+_GLIBCXX14_CONSTEXPR
 _FIter 
 max_element(_FIter, _FIter, _Compare);
 
 #if __cplusplus >= 201103L
   template
+_GLIBCXX14_CONSTEXPR
 pair
 minmax(const _Tp&, const _Tp&);
 
   template
+_GLIBCXX14_CONSTEXPR
 pair
 minmax(const _Tp&, const _Tp&, _Compare);
 
   template
+_GLIBCXX14_CONSTEXPR
 pair<_FIter, _FIter>
 minmax_element(_FIter, _FIter);
 
   template
+_GLIBCXX14_CONSTEXPR
 pair<_FIter, _FIter>
 minmax_element(_FIter, _FIter, _Compare);
 
   template
+_GLIBCXX14_CONSTEXPR
 _Tp
 min(initializer_list<_Tp>);
 
   template
+_GLIBCXX14_CONSTEXPR
 _Tp
 min(initializer_list<_Tp>, _Compare);
 
   template
+_GLIBCXX14_CONSTEXPR
 _Tp
 max(initializer_list<_Tp>);
 
   template
+_GLIBCXX14_CONSTEXPR
 _Tp
 max(initializer_list<_Tp>, _Compare);
 
   template
+_GLIBCXX14_CONSTEXPR
 pair<_Tp, _Tp>
 minmax(initializer_list<_Tp>);
 
   template
+_GLIBCXX14_CONSTEXPR
 pair<_Tp, _Tp>
 minmax(initializer_list<_Tp>, _Compare);
 #endif


Re: PATCHes to help with C++11 bootstrap

2015-05-09 Thread Jason Merrill

On 05/09/2015 01:27 PM, Markus Trippelsdorf wrote:

This also enables the following bogus warning:
  ~ % g++ -Wall -std=c++11 test.cpp
test.cpp:3:26: warning: ‘>>’ operator is treated as two right angle brackets in 
C++11 [-Wc++11-compat]


Fixed thus:



commit 1c492cd18b2869305cc3ee16f84b6464f98f4e4c
Author: Jason Merrill 
Date:   Sat May 9 16:16:46 2015 -0500

	* c-opts.c (c_common_post_options): Also clear
	cpp_opts->cpp_warn_cxx11_compat.

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index bd99871..e9eb511 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -905,6 +905,7 @@ c_common_post_options (const char **pfilename)
   /* If we're allowing C++0x constructs, don't warn about C++98
 	 identifiers which are keywords in C++0x.  */
   warn_cxx11_compat = 0;
+  cpp_opts->cpp_warn_cxx11_compat = 0;
 
   if (warn_narrowing == -1)
 	warn_narrowing = 1;
diff --git a/gcc/testsuite/g++.dg/cpp0x/bracket5.C b/gcc/testsuite/g++.dg/cpp0x/bracket5.C
new file mode 100644
index 000..22ac544
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/bracket5.C
@@ -0,0 +1,6 @@
+// { dg-options "-Wall" }
+// { dg-do compile { target c++11 } }
+
+template  struct X {};
+template  struct Y { static int const c = 0; };
+int main() { return Y>::c; }


Re: PATCHes to help with C++11 bootstrap

2015-05-09 Thread Jason Merrill

More patches:

The first makes changing the default just a matter of changing two lines 
(in the compiler and testsuite).


The second patch is a minor tidy of c.opt.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8c9891a3828dc6a4c91998b2437ef9fbf8659163
Author: Jason Merrill 
Date:   Fri May 8 17:01:37 2015 -0500

gcc/c-family/
	* c-common.h (enum cxx_dialect): Add cxx_unset.
	* c-common.c (cxx_dialect): Initialize to cxx_unset.
	* c-opts.c (c_common_post_options): Set C++ dialect to C++98 if unset.
gcc/testsuite/
	* lib/target-supports.exp (cxx_default): New global.
	(check_effective_target_c++11_only)
	(check_effective_target_c++14_only)
	(check_effective_target_c++98_only)
	(check_effective_target_c++1z_only): Check it.

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 378f237..93b3060 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -256,9 +256,9 @@ const char *constant_string_class_name;
 
 int flag_use_repository;
 
-/* The C++ dialect being used. C++98 is the default.  */
+/* The C++ dialect being used.  Default set in c_common_post_options.  */
 
-enum cxx_dialect cxx_dialect = cxx98;
+enum cxx_dialect cxx_dialect = cxx_unset;
 
 /* Maximum template instantiation depth.  This limit exists to limit the
time it takes to notice excessively recursive template instantiations.
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 603d3f0..5c1fa7b 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -671,6 +671,7 @@ extern int flag_use_repository;
 /* The supported C++ dialects.  */
 
 enum cxx_dialect {
+  cxx_unset,
   /* C++98 with TC1  */
   cxx98,
   cxx03 = cxx98,
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 8b17674..bd99871 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -896,6 +896,10 @@ c_common_post_options (const char **pfilename)
   if (flag_abi_version == 0)
 flag_abi_version = 8;
 
+  /* Set C++ standard to C++98 if not specified on the command line.  */
+  if (c_dialect_cxx () && cxx_dialect == cxx_unset)
+set_std_cxx98 (/*ISO*/false);
+
   if (cxx_dialect >= cxx11)
 {
   /* If we're allowing C++0x constructs, don't warn about C++98
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index d68b48b..3728927 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5892,15 +5892,23 @@ proc check_effective_target_c++ { } {
  return 0
 }
 
+set cxx_default "c++98"
 # Check whether the current active language standard supports the features
-# of C++11/C++14 by checking for the presence of one of the -std
-# flags.  This assumes that the default for the compiler is C++98, and that
+# of C++11/C++14 by checking for the presence of one of the -std flags.
+# This assumes that the default for the compiler is $cxx_default, and that
 # there will never be multiple -std= arguments on the command line.
 proc check_effective_target_c++11_only { } {
+global cxx_default
 if ![check_effective_target_c++] {
 	return 0
 }
-return [check-flags { { } { } { -std=c++0x -std=gnu++0x -std=c++11 -std=gnu++11 } }]
+if [check-flags { { } { } { -std=c++0x -std=gnu++0x -std=c++11 -std=gnu++11 } }] {
+	return 1
+}
+if { $cxx_default == "c++11" && [check-flags { { } { } { } { -std=* } }] } {
+	return 1
+}
+return 0
 }
 proc check_effective_target_c++11 { } {
 if [check_effective_target_c++11_only] {
@@ -5912,14 +5920,21 @@ proc check_effective_target_c++11_down { } {
 if ![check_effective_target_c++] {
 	return 0
 }
-return ![check_effective_target_c++14]
+return [expr ![check_effective_target_c++14] ]
 }
 
 proc check_effective_target_c++14_only { } {
+global cxx_default
 if ![check_effective_target_c++] {
 	return 0
 }
-return [check-flags { { } { } { -std=c++14 -std=gnu++14 -std=c++14 -std=gnu++14 } }]
+if [check-flags { { } { } { -std=c++14 -std=gnu++14 -std=c++14 -std=gnu++14 } }] {
+	return 1
+}
+if { $cxx_default == "c++14" && [check-flags { { } { } { } { -std=* } }] } {
+	return 1
+}
+return 0
 }
 
 proc check_effective_target_c++14 { } {
@@ -5932,21 +5947,35 @@ proc check_effective_target_c++14_down { } {
 if ![check_effective_target_c++] {
 	return 0
 }
-return ![check_effective_target_c++1z]
+return [expr ![check_effective_target_c++1z] ]
 }
 
 proc check_effective_target_c++98_only { } {
+global cxx_default
 if ![check_effective_target_c++] {
 	return 0
 }
-return ![check_effective_target_c++11]
+if [check-flags { { } { } { -std=c++98 -std=gnu++98 -std=c++03 -std=gnu++03 } }] {
+	return 1
+}
+if { $cxx_default == "c++98" && [check-flags { { } { } { } { -std=* } }] } {
+	return 1
+}
+return 0
 }
 
 proc check_effective_target_c++1z_only { } {
+global cxx_default
 if ![check_effective_target_c++] {
 	return 

Re: [patch, Fortran] Fix PR 66041

2015-05-09 Thread Thomas Koenig
Am 09.05.2015 um 13:59 schrieb Mikael Morin:

> You also need to remove/free the trailing subreferences.

That's right, I did that.  Although I will probably never understand
why lbound(a) should be different from lbound(a%r)...

>> +  /* We have to get rid of the shape, if thre is one.  Do
>> + so by freeing it and calling gfc_resolve to rebuild it,
>> + if necessary.  */
>> + 
>> +  if (lbound_e->shape)
>> +gfc_free_shape (&(lbound_e->shape), lbound_e->rank);
>> +
> 
>> +  lbound_e->rank = ar->dimen;
> ar->dimen is  not what you think it is.
> It is 3 for array(1, 1, :), while the rank is 1.

> gfc_resolve_expr should set the rank for you, so just remove this line.

It doesn't (for whatever reason), so I kept on setting it.

>> +
>> +  gfc_resolve_expr (lbound_e);
>> +  lbound = get_array_inq_function (GFC_ISYM_LBOUND,
>> +   lbound_e, i + 1);
> free lbound_e?

It will be part of the lbound expression, or be simplified away.

> 
>>  }
>> -  lbound = get_array_inq_function (GFC_ISYM_LBOUND, e_in,
>> -   i_index + 1);
>> +  else
>> +lbound = get_array_inq_function (GFC_ISYM_LBOUND, e_in,
>> + i_index + 1);
> You can't reuse e_in if it has subreferences.

Changed.

>>  }
>>
>>ar->dimen_type[i] = DIMEN_ELEMENT;
>> @@ -2639,6 +2665,8 @@ scalarized_expr (gfc_expr *e_in, gfc_expr **index,
>>i_index ++;
>>  }
>>  }
>> +  gfc_free_expr (e_in);
>> +
> This side effect is asking for trouble.
> Instead of this, remove the copies made in the callers.
> This is independant from the rest, so it can be made later as a follow-up.

Done (all in once).

I have attached the new patch (in which I also restructured the test),
plus the test cases.

OK for trunk?

Thomas

2015-05-08  Thomas Koenig  

PR fortran/66041
* frontend-passes.c (scalarized_expr): Copy first argument so it
is not necessary to call gfc_copy_expr() on its argument.  Set
correct dimension and shape for the expression to be passed to
lbound. Remove trailing references after array refrence.
(inline_matmul_assign):  Remove gfc_copy_expr() from calls
to scalarized_expr().

2015-05-08  Thomas Koenig  

PR fortran/66041
* gfortran.dg/inline_matmul_7.f90:  New test.
* gfortran.dg/inline_matmul_8.f90:  New test.
* gfortran.dg/inline_matmul_9.f90:  New test.
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 222864)
+++ frontend-passes.c	(Arbeitskopie)
@@ -2532,16 +2532,17 @@ get_size_m1 (gfc_expr *e, int dimen)
  references have been frozen.  */
 
 static gfc_expr*
-scalarized_expr (gfc_expr *e_in, gfc_expr **index, int count_index)
+scalarized_expr (gfc_expr *ei, gfc_expr **index, int count_index)
 {
   gfc_array_ref *ar;
   int i;
   int rank;
-  gfc_expr *e;
+  gfc_expr *e, *e_in;
   int i_index;
   bool was_fullref;
 
-  e = gfc_copy_expr(e_in);
+  e = gfc_copy_expr(ei);
+  e_in = gfc_copy_expr (ei);
 
   rank = e->rank;
 
@@ -2607,18 +2608,54 @@ static gfc_expr*
 		}
 	  else
 		{
+		  gfc_expr *lbound_e;
+		  gfc_ref *ref;
+
+		  lbound_e = gfc_copy_expr (e_in);
+
+		  for (ref = lbound_e->ref; ref; ref = ref->next)
+		if (ref->type == REF_ARRAY
+			&& (ref->u.ar.type == AR_FULL
+			|| ref->u.ar.type == AR_SECTION))
+		  break;
+
+		  if (ref->next)
+		{
+		  gfc_free_ref_list (ref->next);
+		  ref->next = NULL;
+		}
+
 		  if (!was_fullref)
 		{
 		  /* Look at full individual sections, like a(:).  The first index
 			 is the lbound of a full ref.  */
-
+		  int j;
 		  gfc_array_ref *ar;
 
-		  ar = gfc_find_array_ref (e_in);
+		  ar = &ref->u.ar;
 		  ar->type = AR_FULL;
+		  for (j = 0; j < ar->dimen; j++)
+			{
+			  gfc_free_expr (ar->start[j]);
+			  ar->start[j] = NULL;
+			  gfc_free_expr (ar->end[j]);
+			  ar->end[j] = NULL;
+			  gfc_free_expr (ar->stride[j]);
+			  ar->stride[j] = NULL;
+			}
+
+		  /* We have to get rid of the shape, if there is one.  Do
+			 so by freeing it and calling gfc_resolve to rebuild
+			 it, if necessary.  */
+
+		  if (lbound_e->shape)
+			gfc_free_shape (&(lbound_e->shape), lbound_e->rank);
+
+		  lbound_e->rank = ar->dimen;
+		  gfc_resolve_expr (lbound_e);
 		}
-		  lbound = get_array_inq_function (GFC_ISYM_LBOUND, e_in,
-		   i_index + 1);
+		  lbound = get_array_inq_function (GFC_ISYM_LBOUND, lbound_e,
+		   i + 1);
 		}
 	  
 	  ar->dimen_type[i] = DIMEN_ELEMENT;
@@ -2639,6 +2676,8 @@ static gfc_expr*
 	  i_index ++;
 	}

Re: PATCHes to help with C++11 bootstrap

2015-05-09 Thread Jason Merrill

On 05/09/2015 05:37 AM, Richard Biener wrote:

Hmm, I wonder if we want to bootstrap with explicit -std=gnu04, our host 
compiler requirement.  Otherwise we'll silently sneak in C++11 features when 
that becomes the default?


I think just for stage 1.

Jason