[committed] Remove trailing whitespace from diagnostics (PR c/84910)

2018-03-16 Thread Jakub Jelinek
Hi!

All of warning, error_at and inform functions emit a newline after the
message, so trailing whitespace is undesirable there.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk as obvious.

2018-03-16  Jakub Jelinek  

PR c/84910
* c-warn.c (diagnose_mismatched_attributes): Remove trailing space from
diagnostics.

* parser.c (cp_parser_lambda_introducer): Remove trailing space from
diagnostics.
* method.c (synthesize_method): Likewise.
* pt.c (convert_nontype_argument): Likewise.

--- gcc/c-family/c-warn.c.jj2018-03-13 00:38:23.808662251 +0100
+++ gcc/c-family/c-warn.c   2018-03-16 17:36:31.431124231 +0100
@@ -2258,7 +2258,7 @@ diagnose_mismatched_attributes (tree old
   && DECL_UNINLINABLE (newdecl)
   && lookup_attribute ("noinline", DECL_ATTRIBUTES (newdecl)))
 warned |= warning (OPT_Wattributes, "declaration of %q+D with attribute "
-  "%qs follows inline declaration ", newdecl, noinline);
+  "%qs follows inline declaration", newdecl, noinline);
 
   return warned;
 }
--- gcc/cp/parser.c.jj  2018-03-15 08:36:27.982776658 +0100
+++ gcc/cp/parser.c 2018-03-16 17:35:17.628093001 +0100
@@ -10383,7 +10383,7 @@ cp_parser_lambda_introducer (cp_parser*
   && TREE_CODE (capture_init_expr) != PARM_DECL)
{
  error_at (capture_token->location,
-   "capture of non-variable %qE ",
+   "capture of non-variable %qE",
capture_init_expr);
  if (DECL_P (capture_init_expr))
inform (DECL_SOURCE_LOCATION (capture_init_expr),
--- gcc/cp/method.c.jj  2018-01-27 07:26:08.357912834 +0100
+++ gcc/cp/method.c 2018-03-16 17:35:42.024103324 +0100
@@ -950,7 +950,7 @@ synthesize_method (tree fndecl)
   pop_deferring_access_checks ();
 
   if (error_count != errorcount || warning_count != warningcount + werrorcount)
-inform (input_location, "synthesized method %qD first required here ",
+inform (input_location, "synthesized method %qD first required here",
fndecl);
 }
 
--- gcc/cp/pt.c.jj  2018-03-15 08:36:27.980776658 +0100
+++ gcc/cp/pt.c 2018-03-16 17:34:06.575062936 +0100
@@ -6753,7 +6753,7 @@ convert_nontype_argument (tree type, tre
  else
expr = cxx_constant_value (expr);
  if (errorcount > errs || warningcount + werrorcount > warns)
-   inform (loc, "in template argument for type %qT ", type);
+   inform (loc, "in template argument for type %qT", type);
  if (expr == error_mark_node)
return NULL_TREE;
  /* else cxx_constant_value complained but gave us

Jakub


[PATCH] PR fortran/65453 -- procedure statement vs subprogram name clash

2018-03-16 Thread Steve Kargl
The attached patch fixes an ICE by detecting a name
clash between a procedure statement and a contained
subprogram.  Regression tested on x86_64-*-freebsd.

2018-03-16  Steven G. Kargl  

PR fortran/65453
* decl.c (get_proc_name): Catch clash between a procedure statement
and a contained subprogram

2018-03-16  Steven G. Kargl  

PR fortran/65453
* gfortran.dg/pr65453.f90: New test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 258607)
+++ gcc/fortran/decl.c	(working copy)
@@ -1219,6 +1219,12 @@ get_proc_name (const char *name, gfc_symbol **result, 
 	gfc_error_now ("Procedure %qs at %C is already defined at %L",
 		   name, >declared_at);
 
+  if (sym->attr.external && sym->attr.procedure
+	  && gfc_current_state () == COMP_CONTAINS)
+	gfc_error_now ("Contained procedure %qs at %C clashes with "
+			"procedure defined at %L",
+		   name, >declared_at);
+
   /* Trap a procedure with a name the same as interface in the
 	 encompassing scope.  */
   if (sym->attr.generic != 0
Index: gcc/testsuite/gfortran.dg/pr65453.f90
===
--- gcc/testsuite/gfortran.dg/pr65453.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr65453.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/65453
+! Contributed by Tobias Burnus  
+procedure() :: foo   ! { dg-error "(1)" }
+  contains
+subroutine foo() ! { dg-error "clashes with procedure" }
+end
+end


Re: [PATCH] avoid warning for memcpy to self (PR 83456)

2018-03-16 Thread H.J. Lu
On Wed, Mar 7, 2018 at 3:01 PM, Martin Sebor  wrote:
> I have become convinced that issuing -Wrestrict in gimple-fold
> for calls to memcpy() where the source pointer is the same as
> the destination causes more trouble than it's worth, especially
> when inlining is involved, as in:
>
>   inline void bar (void *d, void *s, unsigned N)
>   {
> if (s != d)
>   memcpy (d, s, N);
>   }
>
>   void foo (void* src)
>   {
> bar (src, src, 1);
>   }
>
> It seems that there should be a way to teach GCC to avoid
> folding statements in dead blocks (e.g., in a block controlled
> by 'if (0 != 0)' as the one below), and that it might even speed
> up compilation, but in the meantime it leads to false positive
> -Wrestrict warnings.
>
> The attached patch removes this instance of the warning and
> adjusts tests not to expect it.

This caused:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919


-- 
H.J.


Re: [PATCH, rs6000] Finish implementation of __builtin_atlivec_lvx_v1ti

2018-03-16 Thread Segher Boessenkool
On Wed, Mar 14, 2018 at 04:27:31PM -0500, Kelvin Nilsen wrote:
> During code review, it was discovered that the implementation of
> __builtin_altivec_lvx_v1ti is not complete.  The constant
> ALTIVEC_BUILTINLVX_V1TI is introduced and is bound to the function
> __builtin_altivec_lvx_v1ti.  However, this function's implementation is
> incomplete because there is no call to the def_builtin function for this
> binding.
> 
> This patch provides the missing pieces to add support for this function.
> Additionally, this patch introduces four new __int128-based prototypes
> of the overloaded __builtin_vec_ld function.  This is the function that
> implements the vec_ld () macro expansion.  A new test case has been
> provided to exercise each of these prototypes.

Do we want/need stvx_v1ti as well?

> --- gcc/config/rs6000/rs6000.c(revision 258341)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -14452,6 +14452,7 @@ altivec_expand_lv_builtin (enum insn_code icode, t
>   LVXL and LVE*X expand to use UNSPECs to hide their special behavior,
>   so the raw address is fine.  */
>if (icode == CODE_FOR_altivec_lvx_v2df_2op
> +  || icode == CODE_FOR_altivec_lvx_v1ti_2op
>|| icode == CODE_FOR_altivec_lvx_v2di_2op
>|| icode == CODE_FOR_altivec_lvx_v4sf_2op
>|| icode == CODE_FOR_altivec_lvx_v4si_2op

That's a weird ordering; put v1ti first?

> @@ -15811,6 +15812,9 @@ altivec_expand_builtin (tree exp, rtx target, bool
>  case ALTIVEC_BUILTIN_LVX_V2DI:
>return altivec_expand_lv_builtin (CODE_FOR_altivec_lvx_v2di_2op,
>   exp, target, false);
> +case ALTIVEC_BUILTIN_LVX_V1TI:
> +  return altivec_expand_lv_builtin (CODE_FOR_altivec_lvx_v1ti_2op,
> + exp, target, false);
>  case ALTIVEC_BUILTIN_LVX_V4SF:
>return altivec_expand_lv_builtin (CODE_FOR_altivec_lvx_v4sf_2op,
>   exp, target, false);

Same here.

> --- gcc/testsuite/gcc.target/powerpc/altivec-ld-1.c   (nonexistent)
> +++ gcc/testsuite/gcc.target/powerpc/altivec-ld-1.c   (working copy)
> @@ -0,0 +1,67 @@
> +/* { dg-do run { target powerpc*-*-* } } */
> +/* { dg-require-effective-target powerpc_altivec_ok } */
> +/* { dg-require-effective-target lp64 } */
> +/* { dg-options "-maltivec -O0 -Wall -Wno-deprecated" } */

Since this is a run testcase you need vmx_hw instead of powerpc_altivec_ok.
You also need a test for int128.  I don't think you need lp64, please check.

Okay for trunk with that fixed.  Thanks!


Segher


Re: [PATCH v2, rs6000] Remove unused (and incorrect) code for internal store and load operations

2018-03-16 Thread Segher Boessenkool
Hi Kelvin,

Okay for trunk.  Thanks!


Segher


On Wed, Mar 14, 2018 at 02:22:44PM -0500, Kelvin Nilsen wrote:
> 2018-03-14  Kelvin Nilsen  
> 
>   * config/rs6000/rs6000-builtin.def: Remove various BU_ALTIVEC_X
>   macro expansions for definition of ST_INTERNAL_ and
>   LD_INTERNAL_ builtins.
>   * config/rs6000/rs6000-protos.h (rs6000_address_for_altivec):
>   Remove prototype.
>   * config/rs6000/rs6000.c (altivec_expand_ld_builtin): Delete this
>   function.
>   (altivec_expand_st_builtin): Likewise.
>   (altivec_expand_builtin): Remove calls to deleted functions.
>   (rs6000_address_for_altivec): Delete this function.
>   * config/rs6000/vector.md: Remove expands for
>   vector_altivec_load_ and vector_altivec_store_.


Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #1

2018-03-16 Thread Michael Meissner
In patch #4, I mentioned that the spec 2006 benchmark 'tonto' generated
different with the patches applied.  I tracked it down, and it was due to the
call I inserted in rs6000_debug_reg_print to update the conditional register
usage seemed to set the Altivec registers VS0..VS19 to call_used instead of
call_saved.  Since I no longer need to set the conditional register usage with
-mdebug=reg, it is simpler to just delete it.

2018-03-16  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_debug_reg_print): Eliminate call
to rs6000_conditional_register_usage.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 258576)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -1314,7 +1314,6 @@ static bool rs6000_debug_can_change_mode
reg_class_t);
 static bool rs6000_save_toc_in_prologue_p (void);
 static rtx rs6000_internal_arg_pointer (void);
-static void rs6000_conditional_register_usage (void);
 
 rtx (*rs6000_legitimize_reload_address_ptr) (rtx, machine_mode, int, int,
 int, int *)
@@ -2144,10 +2143,6 @@ rs6000_debug_reg_print (int first_regno,
 {
   int r, m;
 
-  /* Insure the conditional registers are up to date when printing the debug
- information.  */
-  rs6000_conditional_register_usage ();
-
   for (r = first_regno; r <= last_regno; ++r)
 {
   const char *comma = "";


Re: [PATCH ] PR 844422 Fix FCTID, FCTIW with -mcpu=power7

2018-03-16 Thread Segher Boessenkool
Hi Carl,

On Wed, Mar 14, 2018 at 08:27:08AM -0700, Carl Love wrote:
> The following patch fixes an ICE when compiling the test case
> 
>   gcc -mcpu=power7 builtin-fctid-fctiw-runnable.c
> 
> The GCC compiler now gives a message 
> 
> "error: builtin function ‘__builtin_fctiw’ requires the ‘-mpower8-vector’ 
> option" 
> 
> and exits without generating an internal error.

This is an improvement over the ICE, for sure.

But fctiw is an ISA 1.xx instruction already (and fctid is as well,
but explicitly undefined for 32-bit implementations until some 2.xx,
I forgot which, 2.02 I think?)

Requiring power8 for it is weird and surprising.  power8-vector doubly so.

It does not seem to be a good idea to only enable the builtin for cases
where the current implementation is not broken.

(The issue is that pre-power8 we do not allow SImode in FPR registers.
Which makes the current fctiw implementation fail).

I think we have two good options:

1) Remove these builtins;
or
2) Make them work.


Segher


New German PO file for 'gcc' (version 8.1-b20180128)

2018-03-16 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'gcc-8.1-b20180128.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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




[PR c++/84789] do not resolve typename into template-independent

2018-03-16 Thread Alexandre Oliva
resolve_typename_type may peek into template types that might still be
specialized.  In some cases, e.g. g++.dg/template/friend48.C or
g++.dg/template/decl2.C, that is exactly the right thing to do.  In
others, like the newly-added testcase g++.dg/template/pr84789.C, it
isn't, and if the qualifying scope happens to resolve to a non-template
type, we resolve to that and then fail the assert that checks we still
have a template-dependent scope.

It appears to me that, in cases in which the assert would fail, we are
missing the typename keyword, and we ought to report an error; if we
just return the incoming type unchanged, that's exactly what we get.
So, I'm turning such failed asserts into early returns, so that the
parser can recover and report an error.

Regstrapped on i686- and x86_64-linux-gnu.  Ok to install?


for  gcc/cp/ChangeLog

PR c++/84789
* pt.c (resolve_typename_type): Keep the type
template-dependent.

for  gcc/testsuite/ChangeLog

PR c++/84789
* g++.dg/template/pr84789.C: New.
---
 gcc/cp/pt.c |   19 +--
 gcc/testsuite/g++.dg/template/pr84789.C |   13 +
 2 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/template/pr84789.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 89024c10fe2b..067221fa78ea 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25195,8 +25195,23 @@ resolve_typename_type (tree type, bool only_current_p)
 /* scope is either the template itself or a compatible instantiation
like X, so look up the name in the original template.  */
 scope = CLASSTYPE_PRIMARY_TEMPLATE_TYPE (scope);
-  /* We shouldn't have built a TYPENAME_TYPE with a non-dependent scope.  */
-  gcc_checking_assert (uses_template_parms (scope));
+  /* We shouldn't have built a TYPENAME_TYPE with a non-dependent
+ scope.  However, it might be a dependent scope that's being
+ resolved to a non-dependent scope just because we're looking up
+ scopes we shouldn't, e.g.
+
+   template  class B { typedef int I; };
+   template  class C : B { B::I i; };
+
+ We need 'typename' before C::i's type, because we can't enter
+ the scope of B for an unbound template parameter T to tell I
+ identifies a type (that's why we need typename), but the parser
+ attempts to do so, presumably so that it can produce better error
+ messages.  However, we'd skip necessary errors if we resolved a
+ template-dependent type to a template-independent one, so don't
+ do that.  */
+  if (!uses_template_parms (scope))
+return type;
   /* If scope has no fields, it can't be a current instantiation.  Check this
  before currently_open_class to avoid infinite recursion (71515).  */
   if (!TYPE_FIELDS (scope))
diff --git a/gcc/testsuite/g++.dg/template/pr84789.C 
b/gcc/testsuite/g++.dg/template/pr84789.C
new file mode 100644
index ..bc1567f3fe77
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/pr84789.C
@@ -0,0 +1,13 @@
+// { dg-do compile }
+
+struct A
+{
+  typedef int I;
+};
+
+template struct B : A {};
+
+template struct C : B
+{
+  B::A::I::I i; // { dg-error "typename" }
+};


-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


[PATCH 2/3] Add htdocs/ansi2html.css

2018-03-16 Thread David Malcolm
Generated by:

  ansi2html.sh --css-only --bg=dark --palette=xterm
---
 htdocs/ansi2html.css | 287 +++
 1 file changed, 287 insertions(+)
 create mode 100644 htdocs/ansi2html.css

diff --git a/htdocs/ansi2html.css b/htdocs/ansi2html.css
new file mode 100644
index 000..3401288
--- /dev/null
+++ b/htdocs/ansi2html.css
@@ -0,0 +1,287 @@
+.ef0,.f0 { color: #00; } .eb0,.b0 { background-color: #00; }
+.ef1,.f1 { color: #CD; } .eb1,.b1 { background-color: #CD; }
+.ef2,.f2 { color: #00CD00; } .eb2,.b2 { background-color: #00CD00; }
+.ef3,.f3 { color: #CDCD00; } .eb3,.b3 { background-color: #CDCD00; }
+.ef4,.f4 { color: #EE; } .eb4,.b4 { background-color: #EE; }
+.ef5,.f5 { color: #CD00CD; } .eb5,.b5 { background-color: #CD00CD; }
+.ef6,.f6 { color: #00CDCD; } .eb6,.b6 { background-color: #00CDCD; }
+.ef7,.f7 { color: #E5E5E5; } .eb7,.b7 { background-color: #E5E5E5; }
+.ef8, .f0 > .bold,.bold > .f0 { color: #7F7F7F; font-weight: normal; }
+.ef9, .f1 > .bold,.bold > .f1 { color: #FF; font-weight: normal; }
+.ef10,.f2 > .bold,.bold > .f2 { color: #00FF00; font-weight: normal; }
+.ef11,.f3 > .bold,.bold > .f3 { color: #00; font-weight: normal; }
+.ef12,.f4 > .bold,.bold > .f4 { color: #5C5CFF; font-weight: normal; }
+.ef13,.f5 > .bold,.bold > .f5 { color: #FF00FF; font-weight: normal; }
+.ef14,.f6 > .bold,.bold > .f6 { color: #00; font-weight: normal; }
+.ef15,.f7 > .bold,.bold > .f7 { color: #FF; font-weight: normal; }
+.eb8  { background-color: #7F7F7F; }
+.eb9  { background-color: #FF; }
+.eb10 { background-color: #00FF00; }
+.eb11 { background-color: #00; }
+.eb12 { background-color: #5C5CFF; }
+.eb13 { background-color: #FF00FF; }
+.eb14 { background-color: #00; }
+.eb15 { background-color: #FF; }
+.ef16 { color: #00; } .eb16 { background-color: #00; }
+.ef17 { color: #5f; } .eb17 { background-color: #5f; }
+.ef18 { color: #87; } .eb18 { background-color: #87; }
+.ef19 { color: #af; } .eb19 { background-color: #af; }
+.ef20 { color: #d7; } .eb20 { background-color: #d7; }
+.ef21 { color: #ff; } .eb21 { background-color: #ff; }
+.ef22 { color: #005f00; } .eb22 { background-color: #005f00; }
+.ef23 { color: #005f5f; } .eb23 { background-color: #005f5f; }
+.ef24 { color: #005f87; } .eb24 { background-color: #005f87; }
+.ef25 { color: #005faf; } .eb25 { background-color: #005faf; }
+.ef26 { color: #005fd7; } .eb26 { background-color: #005fd7; }
+.ef27 { color: #005fff; } .eb27 { background-color: #005fff; }
+.ef28 { color: #008700; } .eb28 { background-color: #008700; }
+.ef29 { color: #00875f; } .eb29 { background-color: #00875f; }
+.ef30 { color: #008787; } .eb30 { background-color: #008787; }
+.ef31 { color: #0087af; } .eb31 { background-color: #0087af; }
+.ef32 { color: #0087d7; } .eb32 { background-color: #0087d7; }
+.ef33 { color: #0087ff; } .eb33 { background-color: #0087ff; }
+.ef34 { color: #00af00; } .eb34 { background-color: #00af00; }
+.ef35 { color: #00af5f; } .eb35 { background-color: #00af5f; }
+.ef36 { color: #00af87; } .eb36 { background-color: #00af87; }
+.ef37 { color: #00afaf; } .eb37 { background-color: #00afaf; }
+.ef38 { color: #00afd7; } .eb38 { background-color: #00afd7; }
+.ef39 { color: #00afff; } .eb39 { background-color: #00afff; }
+.ef40 { color: #00d700; } .eb40 { background-color: #00d700; }
+.ef41 { color: #00d75f; } .eb41 { background-color: #00d75f; }
+.ef42 { color: #00d787; } .eb42 { background-color: #00d787; }
+.ef43 { color: #00d7af; } .eb43 { background-color: #00d7af; }
+.ef44 { color: #00d7d7; } .eb44 { background-color: #00d7d7; }
+.ef45 { color: #00d7ff; } .eb45 { background-color: #00d7ff; }
+.ef46 { color: #00ff00; } .eb46 { background-color: #00ff00; }
+.ef47 { color: #00ff5f; } .eb47 { background-color: #00ff5f; }
+.ef48 { color: #00ff87; } .eb48 { background-color: #00ff87; }
+.ef49 { color: #00ffaf; } .eb49 { background-color: #00ffaf; }
+.ef50 { color: #00ffd7; } .eb50 { background-color: #00ffd7; }
+.ef51 { color: #00; } .eb51 { background-color: #00; }
+.ef52 { color: #5f; } .eb52 { background-color: #5f; }
+.ef53 { color: #5f005f; } .eb53 { background-color: #5f005f; }
+.ef54 { color: #5f0087; } .eb54 { background-color: #5f0087; }
+.ef55 { color: #5f00af; } .eb55 { background-color: #5f00af; }
+.ef56 { color: #5f00d7; } .eb56 { background-color: #5f00d7; }
+.ef57 { color: #5f00ff; } .eb57 { background-color: #5f00ff; }
+.ef58 { color: #5f5f00; } .eb58 { background-color: #5f5f00; }
+.ef59 { color: #5f5f5f; } .eb59 { background-color: #5f5f5f; }
+.ef60 { color: #5f5f87; } .eb60 { background-color: #5f5f87; }
+.ef61 { color: #5f5faf; } .eb61 { background-color: #5f5faf; }
+.ef62 { color: #5f5fd7; } .eb62 { background-color: #5f5fd7; }
+.ef63 { color: #5f5fff; } .eb63 { background-color: #5f5fff; }
+.ef64 { color: #5f8700; } .eb64 { background-color: #5f8700; }
+.ef65 { color: #5f875f; } .eb65 { 

[PATCH 1/3] bin: add ansi2html.sh

2018-03-16 Thread David Malcolm
---
 bin/ansi2html.sh | 520 +++
 1 file changed, 520 insertions(+)
 create mode 100755 bin/ansi2html.sh

diff --git a/bin/ansi2html.sh b/bin/ansi2html.sh
new file mode 100755
index 000..ae83a78
--- /dev/null
+++ b/bin/ansi2html.sh
@@ -0,0 +1,520 @@
+#!/bin/sh
+
+# Convert ANSI (terminal) colours and attributes to HTML
+
+# Licence: LGPLv2
+# Author:
+#http://www.pixelbeat.org/docs/terminal_colours/
+# Examples:
+#ls -l --color=always | ansi2html.sh > ls.html
+#git show --color | ansi2html.sh > last_change.html
+#Generally one can use the `script` util to capture full terminal output.
+# Changes:
+#V0.1, 24 Apr 2008, Initial release
+#V0.2, 01 Jan 2009, Phil Harnish 
+# Support `git diff --color` output by
+# matching ANSI codes that specify only
+# bold or background colour.
+#   p...@draigbrady.com
+# Support `ls --color` output by stripping
+# redundant leading 0s from ANSI codes.
+# Support `grep --color=always` by stripping
+# unhandled ANSI codes (specifically ^[[K).
+#V0.3, 20 Mar 2009, http://eexpress.blog.ubuntu.org.cn/
+# Remove cat -v usage which mangled non ascii input.
+# Cleanup regular expressions used.
+# Support other attributes like reverse, ...
+#   p...@draigbrady.com
+# Correctly nest  tags (even across lines).
+# Add a command line option to use a dark background.
+# Strip more terminal control codes.
+#V0.4, 17 Sep 2009, p...@draigbrady.com
+# Handle codes with combined attributes and color.
+# Handle isolated  attributes with css.
+# Strip more terminal control codes.
+#V0.24, 14 Sep 2017
+#  http://github.com/pixelb/scripts/commits/master/scripts/ansi2html.sh
+
+gawk --version >/dev/null || exit 1
+
+if [ "$1" = "--version" ]; then
+printf '0.23\n' && exit
+fi
+
+usage()
+{
+printf '%s\n' \
+'This utility converts ANSI codes in data passed to stdin
+It has 4 optional parameters:
+--bg=dark --palette=linux|solarized|tango|xterm --css-only|--body-only
+E.g.: ls -l --color=always | ansi2html.sh --bg=dark > ls.html' >&2
+exit
+}
+
+if [ "$1" = "--help" ]; then
+usage
+fi
+
+processArg()
+{
+[ "$1" = "--bg=dark" ] && { dark_bg=yes; return; }
+[ "$1" = "--css-only" ] && { css_only=yes; return; }
+[ "$1" = "--body-only" ] && { body_only=yes; return; }
+if [ "$1" = "--palette=solarized" ]; then
+   # See http://ethanschoonover.com/solarized
+   P0=073642;  P1=D30102;  P2=859900;  P3=B58900;
+   P4=268BD2;  P5=D33682;  P6=2AA198;  P7=EEE8D5;
+   P8=002B36;  P9=CB4B16; P10=586E75; P11=657B83;
+  P12=839496; P13=6C71C4; P14=93A1A1; P15=FDF6E3;
+  return;
+elif [ "$1" = "--palette=solarized-xterm" ]; then
+   # Above mapped onto the xterm 256 color palette
+   P0=262626;  P1=AF;  P2=5F8700;  P3=AF8700;
+   P4=0087FF;  P5=AF005F;  P6=00AFAF;  P7=E4E4E4;
+   P8=1C1C1C;  P9=D75F00; P10=585858; P11=626262;
+  P12=808080; P13=5F5FAF; P14=8A8A8A; P15=D7;
+  return;
+elif [ "$1" = "--palette=tango" ]; then
+   # Gnome default
+   P0=00;  P1=CC;  P2=4E9A06;  P3=C4A000;
+   P4=3465A4;  P5=75507B;  P6=06989A;  P7=D3D7CF;
+   P8=555753;  P9=EF2929; P10=8AE234; P11=FCE94F;
+  P12=729FCF; P13=AD7FA8; P14=34E2E2; P15=EC;
+  return;
+elif [ "$1" = "--palette=xterm" ]; then
+   P0=00;  P1=CD;  P2=00CD00;  P3=CDCD00;
+   P4=EE;  P5=CD00CD;  P6=00CDCD;  P7=E5E5E5;
+   P8=7F7F7F;  P9=FF; P10=00FF00; P11=00;
+  P12=5C5CFF; P13=FF00FF; P14=00; P15=FF;
+  return;
+else # linux console
+   P0=00;  P1=AA;  P2=00AA00;  P3=AA5500;
+   P4=AA;  P5=AA00AA;  P6=00;  P7=AA;
+   P8=55;  P9=FF; P10=55FF55; P11=55;
+  P12=FF; P13=FF55FF; P14=55; P15=FF;
+  [ "$1" = "--palette=linux" ] && return;
+fi
+}
+
+processArg #defaults
+for var in "$@"; do processArg $var; done
+[ "$css_only" ] && [ "$body_only" ] && usage
+
+# Mac OSX's GNU sed is installed as gsed
+# use e.g. homebrew 'gnu-sed' to get it
+if ! sed --version >/dev/null 2>&1; then
+  if gsed --version >/dev/null 2>&1; then
+alias sed=gsed
+  else
+echo "Error, can't find an acceptable GNU sed." >&2
+exit 1
+  fi
+fi
+
+[ "$css_only" ] || [ "$body_only" ] || printf '%s' "
+
+
+
+"
+[ "$body_only" ] || printf ".ef0,.f0 { color: #$P0; } .eb0,.b0 { 
background-color: #$P0; }
+.ef1,.f1 { color: #$P1; } .eb1,.b1 { background-color: #$P1; }
+.ef2,.f2 { color: #$P2; } .eb2,.b2 { 

[PATCH 0/3] wwwdocs: Updates for gcc 8 changes

2018-03-16 Thread David Malcolm
This patch kit is for the website; I generated it against a local
git mirror of the CVS repo.

It adds lots of examples of colorized output from GCC, which
I generated using ansi2html.sh, an LGPLv2 script for turning ANSI
color codes into HTML spans.  It also emits a .css file for mapping
the span classes into HTML colorization.

OK for the website?  (Note the caveats in patch 3)

Thanks

David Malcolm (3):
  bin: add ansi2html.sh
  Add htdocs/ansi2html.css
  Document my gcc 8 changes for the website

 bin/ansi2html.sh  | 520 ++
 htdocs/ansi2html.css  | 287 +
 htdocs/gcc-8/changes.html | 264 ++-
 3 files changed, 1070 insertions(+), 1 deletion(-)
 create mode 100755 bin/ansi2html.sh
 create mode 100644 htdocs/ansi2html.css

-- 
1.8.5.3



[PATCH 3/3] Document my gcc 8 changes for the website

2018-03-16 Thread David Malcolm
This patch documents various improvements in GCC 8 for our website.

There are lots of examples of colorized output from GCC (generated
using ansi2html); the patch uses the ansi2html.css from the previous
patch for styling them.

Caveat: I don't have the toolchain working for building the site, so
I was only able to test the CSS by manually hacking the  during
testing.  The patch adds the CSS there.  I hope this works.

Successfully checked as XHTML 1.0 Transitional.
---
 htdocs/gcc-8/changes.html | 264 +-
 1 file changed, 263 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-8/changes.html b/htdocs/gcc-8/changes.html
index 7b76e34..122d02d 100644
--- a/htdocs/gcc-8/changes.html
+++ b/htdocs/gcc-8/changes.html
@@ -1,6 +1,7 @@
 
 
 
+
 GCC 8 Release Series  Changes, New Features, and Fixes
 
 
@@ -120,11 +121,243 @@ a work-in-progress.
  default at all optimization levels.  Using
  -fsanitize=signed-integer-overflow is now the preferred
  way to audit code, -Wstrict-overflow is deprecated.
+When reporting mismatching argument types at a function call, the
+  C and C++ compilers now underline both the argument and the pertinent
+  parameter in the declaration.
+
+$ gcc arg-type-mismatch.cc
+arg-type-mismatch.cc: In function 'int caller(int, int, float)':
+arg-type-mismatch.cc:5:24: error: invalid conversion from 'int' to 'const char*' [-fpermissive]
+   return callee(first, second, third);
+^~
+arg-type-mismatch.cc:1:40: note:   initializing argument 2 of 'int callee(int, const char*, float)'
+ extern int callee(int one, const char 
*two, float three);
+^~~
+
+
+
+When reporting on unrecognized identifiers, the C and C++ compilers
+  will now emit fix-it hints suggesting #include directives
+  for various headers in the C and C++ standard libraries.
+
+$ gcc incomplete.c
+incomplete.c: In function 'test':
+incomplete.c:3:10: error: 'NULL' undeclared 
(first use in this function)
+   return NULL;
+  ^~~~
+incomplete.c:3:10: note: 'NULL' is defined in 
header 'stddef.h'; did you forget to '#include stddef.h'?
+incomplete.c:1:1:
++#include stddef.h
+ const char *test(void)
+incomplete.c:3:10:
+   return NULL;
+  ^~~~
+incomplete.c:3:10: note: each undeclared identifier is reported only once 
for each function it appears in
+
+
+
+$ gcc incomplete.cc
+incomplete.cc:1:6: error: 'string' in namespace 
'std' does not name a type
+ std::string s(hello 
world);
+  ^~
+incomplete.cc:1:1: note: 'std::string' is 
defined in header 'string'; did you forget to 
'#include string'?
++#include string
+ std::string s(hello 
world);
+ ^~~
+
+
+
+The C and C++ compilers now use more intuitive locations when
+  reporting on missing semicolons, and offer fix-it hints:
+
+$ gcc t.c
+t.c: In function 'test':
+t.c:3:12: error: 
expected ';' before '}' token
+   return 42
+^
+;
+ }
+ ~
+
+
+
+When reporting on missing '}' and ')' tokens, the C and C++
+  compilers will now highlight the corresponding '{' and '(' token,
+  issuing a 'note' if it's on a separate line:
+
+$ gcc unclosed.c
+unclosed.c: In function 'log_when_out_of_range':
+unclosed.c:12:50: error: expected ')' before 
'{' token
+(temperature  MIN || temperature  MAX) {
+  ^~
+  )
+unclosed.c:11:6: note: to match this '('
+   if (logging_enabled 
 check_range ()
+  ^
+
+  or highlighting it directly if it's on the same line:
+
+$ gcc unclosed-2.c
+unclosed-2.c: In function 'test':
+unclosed-2.c:8:45: error: expected ')' before 
'{' token
+   if (temperature  MIN || temperature  
MAX {
+  ~  ^~
+ )
+
+  They will also emit fix-it hints.
+
 
 
 C++
 
-  
+  When reporting on attempts to access private fields of a class or
+struct, the C++ compiler will now offer fix-it hints showing how to
+use an accessor function to get at the field in question, if one exists.
+
+$ gcc accessor.cc
+accessor.cc: In function 'void 
test(foo*)':
+accessor.cc:12:12: error: 'double foo::m_ratio' 
is private within this context
+   if (ptr-m_ratio = 
0.5)
+^~~
+accessor.cc:7:10: note: declared private here
+   double m_ratio;
+  ^~~
+accessor.cc:12:12: note: field 'double 
foo::m_ratio' can be accessed via 'double 
foo::get_ratio() const'
+   if (ptr-m_ratio = 
0.5)
+^~~
+get_ratio()
+
+
+  
+  The C++ compiler can now give you a hint if you use a macro before it
+was defined (e.g. if you mess up the order of your #include
+directives):
+
+$ gcc ordering.cc
+ordering.cc:2:24: error: expected ';' at end 
of member declaration
+   virtual void clone() const OVERRIDE { }
+   

Re: [PATCH] Fix postreload constant merging (PR target/84899)

2018-03-16 Thread Jeff Law
On 03/16/2018 02:17 PM, Jakub Jelinek wrote:
> Hi!
> 
> The following testcase ICEs on powerpc-linux, because we merge
> SImode constants 0x7fff and 1 into 0x8000, which is not valid SImode
> CONST_INT - -0x8000 is.  Fixed by calling trunc_int_for_mode, and to
> avoid UB in the compiler do the addition in unsigned type.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux and tested on the
> testcase with powerpc64-linux cross with -m32, ok for trunk?
> 
> 2018-03-16  Jakub Jelinek  
> 
>   PR target/84899
>   * postreload.c (reload_combine_recognize_pattern): Perform
>   INTVAL addition in unsigned HOST_WIDE_INT type to avoid UB and
>   truncate_int_for_mode the result for the destination's mode.
> 
>   * gcc.dg/pr84899.c: New test.
OK.
jeff


Re: [PATCH] Fix PR84873

2018-03-16 Thread Jakub Jelinek
On Fri, Mar 16, 2018 at 12:53:29PM +0100, Richard Biener wrote:
> > An alternative slightly more expensive patch is the following which
> > I'm now testing on x86_64-unknown-linux-gnu, the above testcase
> > is fixed with it (verified with a cross).
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok?
> 
> > 2018-03-16  Richard Biener  
> > 
> > PR c/84873
> > * c-gimplify.c (c_gimplify_expr): Revert previous change.  Instead
> > unshare the possibly folded expression.
> > 
> > + /* Make sure to unshare the result, tree sharing is invalid
> > +during gimplification.  */
> > + *op1_p = unshare_expr (convert (unsigned_type_node, *op1_p));

Ok, thanks.

Jakub


[PATCH] Fix x86 -march/-mtune after recent icelake-* split (PR target/84902)

2018-03-16 Thread Jakub Jelinek
Hi!

We now have more than 32 enumerators in enum processor_type (well, we had
33 already before the icelake-* split, but the last one isn't really used),
and while all the m_* macros were changed tom 1U<

PR target/84902
* config/i386/i386.c (initial_ix86_tune_features,
initial_ix86_arch_features): Use unsigned HOST_WIDE_INT rather than
unsigned long long.
(set_ix86_tune_features): Change ix86_tune_mask from unsigned int
to unsigned HOST_WIDE_INT, initialize to HOST_WIDE_INT_1U << ix86_tune
rather than 1u << ix86_tune.  Formatting fix.
(ix86_option_override_internal): Change ix86_arch_mask from
unsigned int to unsigned HOST_WIDE_INT, initialize to
HOST_WIDE_INT_1U << ix86_arch rather than 1u << ix86_arch.
(ix86_function_specific_restore): Likewise.

--- gcc/config/i386/i386.c.jj   2018-03-15 22:07:57.964242564 +0100
+++ gcc/config/i386/i386.c  2018-03-16 18:35:53.621105345 +0100
@@ -183,7 +183,7 @@ unsigned char ix86_tune_features[X86_TUN
 
 /* Feature tests against the various tunings used to create ix86_tune_features
based on the processor mask.  */
-static unsigned long long initial_ix86_tune_features[X86_TUNE_LAST] = {
+static unsigned HOST_WIDE_INT initial_ix86_tune_features[X86_TUNE_LAST] = {
 #undef DEF_TUNE
 #define DEF_TUNE(tune, name, selector) selector,
 #include "x86-tune.def"
@@ -195,7 +195,7 @@ unsigned char ix86_arch_features[X86_ARC
 
 /* Feature tests against the various architecture variations, used to create
ix86_arch_features based on the processor mask.  */
-static unsigned long long initial_ix86_arch_features[X86_ARCH_LAST] = {
+static unsigned HOST_WIDE_INT initial_ix86_arch_features[X86_ARCH_LAST] = {
   /* X86_ARCH_CMOV: Conditional move was added for pentiumpro.  */
   ~(m_386 | m_486 | m_PENT | m_LAKEMONT | m_K6),
 
@@ -3310,7 +3310,7 @@ parse_mtune_ctrl_str (bool dump)
 static void
 set_ix86_tune_features (enum processor_type ix86_tune, bool dump)
 {
-  unsigned int ix86_tune_mask = 1u << ix86_tune;
+  unsigned HOST_WIDE_INT ix86_tune_mask = HOST_WIDE_INT_1U << ix86_tune;
   int i;
 
   for (i = 0; i < X86_TUNE_LAST; ++i)
@@ -3318,7 +3318,8 @@ set_ix86_tune_features (enum processor_t
   if (ix86_tune_no_default)
 ix86_tune_features[i] = 0;
   else
-ix86_tune_features[i] = !!(initial_ix86_tune_features[i] & 
ix86_tune_mask);
+   ix86_tune_features[i]
+ = !!(initial_ix86_tune_features[i] & ix86_tune_mask);
 }
 
   if (dump)
@@ -3373,7 +3374,7 @@ ix86_option_override_internal (bool main
   struct gcc_options *opts_set)
 {
   int i;
-  unsigned int ix86_arch_mask;
+  unsigned HOST_WIDE_INT ix86_arch_mask;
   const bool ix86_tune_specified = (opts->x_ix86_tune_string != NULL);
 
   const wide_int_bitmask PTA_3DNOW (HOST_WIDE_INT_1U << 0);
@@ -4234,7 +4235,7 @@ ix86_option_override_internal (bool main
   XDELETEVEC (s);
 }
 
-  ix86_arch_mask = 1u << ix86_arch;
+  ix86_arch_mask = HOST_WIDE_INT_1U << ix86_arch;
   for (i = 0; i < X86_ARCH_LAST; ++i)
 ix86_arch_features[i] = !!(initial_ix86_arch_features[i] & ix86_arch_mask);
 
@@ -5159,7 +5160,7 @@ ix86_function_specific_restore (struct g
 {
   enum processor_type old_tune = ix86_tune;
   enum processor_type old_arch = ix86_arch;
-  unsigned int ix86_arch_mask;
+  unsigned HOST_WIDE_INT ix86_arch_mask;
   int i;
 
   /* We don't change -fPIC.  */
@@ -5210,7 +5211,7 @@ ix86_function_specific_restore (struct g
   /* Recreate the arch feature tests if the arch changed */
   if (old_arch != ix86_arch)
 {
-  ix86_arch_mask = 1u << ix86_arch;
+  ix86_arch_mask = HOST_WIDE_INT_1U << ix86_arch;
   for (i = 0; i < X86_ARCH_LAST; ++i)
ix86_arch_features[i]
  = !!(initial_ix86_arch_features[i] & ix86_arch_mask);

Jakub


[PATCH] Fix postreload constant merging (PR target/84899)

2018-03-16 Thread Jakub Jelinek
Hi!

The following testcase ICEs on powerpc-linux, because we merge
SImode constants 0x7fff and 1 into 0x8000, which is not valid SImode
CONST_INT - -0x8000 is.  Fixed by calling trunc_int_for_mode, and to
avoid UB in the compiler do the addition in unsigned type.

Bootstrapped/regtested on x86_64-linux and i686-linux and tested on the
testcase with powerpc64-linux cross with -m32, ok for trunk?

2018-03-16  Jakub Jelinek  

PR target/84899
* postreload.c (reload_combine_recognize_pattern): Perform
INTVAL addition in unsigned HOST_WIDE_INT type to avoid UB and
truncate_int_for_mode the result for the destination's mode.

* gcc.dg/pr84899.c: New test.

--- gcc/postreload.c.jj 2018-01-03 10:19:55.572534024 +0100
+++ gcc/postreload.c2018-03-16 18:19:17.819417570 +0100
@@ -1157,11 +1157,13 @@ reload_combine_recognize_pattern (rtx_in
 value in PREV, the constant loading instruction.  */
  validate_change (prev, _DEST (prev_set), index_reg, 1);
  if (reg_state[regno].offset != const0_rtx)
-   validate_change (prev,
-_SRC (prev_set),
-GEN_INT (INTVAL (SET_SRC (prev_set))
- + INTVAL (reg_state[regno].offset)),
-1);
+   {
+ HOST_WIDE_INT c
+   = trunc_int_for_mode (UINTVAL (SET_SRC (prev_set))
+ + UINTVAL (reg_state[regno].offset),
+ GET_MODE (index_reg));
+ validate_change (prev, _SRC (prev_set), GEN_INT (c), 1);
+   }
 
  /* Now for every use of REG that we have recorded, replace REG
 with REG_SUM.  */
--- gcc/testsuite/gcc.dg/pr84899.c.jj   2018-03-16 18:22:39.243512333 +0100
+++ gcc/testsuite/gcc.dg/pr84899.c  2018-03-16 18:22:22.353504390 +0100
@@ -0,0 +1,12 @@
+/* PR target/84899 */
+/* { dg-do compile } */
+/* { dg-options "-O -funroll-all-loops -fno-move-loop-invariants" } */
+
+void
+foo (int x)
+{
+  int a = 1 / x, b = 0;
+
+  while ((a + b + 1) < x)
+b = __INT_MAX__;
+}

Jakub


[committed] Fix "to to" -> "to" in diagnostics and comments (PR c/84909)

2018-03-16 Thread Jakub Jelinek
Hi!

Duplicated word in diagnostics and the same issues in 3 comments.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.

2018-03-16  Jakub Jelinek  

PR c/84909
* c-warn.c (conversion_warning): Replace "to to" with "to" in
diagnostics.

* hsa-gen.c (mem_type_for_type): Fix comment typo.
* tree-vect-loop-manip.c (vect_create_cond_for_niters_checks):
Likewise.
* gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
Likewise.

--- gcc/c-family/c-warn.c.jj2018-03-16 17:36:31.431124231 +0100
+++ gcc/c-family/c-warn.c   2018-03-16 17:44:34.905341083 +0100
@@ -1138,8 +1138,7 @@ conversion_warning (location_t loc, tree
   conversion_kind = unsafe_conversion_p (loc, type, expr, result, true);
   if (conversion_kind == UNSAFE_IMAGINARY)
warning_at (loc, OPT_Wconversion,
-   "conversion from %qT to to %qT discards imaginary "
-   "component",
+   "conversion from %qT to %qT discards imaginary component",
expr_type, type);
   else
{
--- gcc/hsa-gen.c.jj2018-02-09 06:44:38.421804424 +0100
+++ gcc/hsa-gen.c   2018-03-16 17:46:00.981383468 +0100
@@ -691,7 +691,7 @@ mem_type_for_type (BrigType16_t type)
   /* HSA has non-intuitive constraints on load/store types.  If it's
  a bit-type it _must_ be B128, if it's not a bit-type it must be
  64bit max.  So for loading entities of 128 bits (e.g. vectors)
- we have to to B128, while for loading the rest we have to use the
+ we have to use B128, while for loading the rest we have to use the
  input type (??? or maybe also flattened to a equally sized non-vector
  unsigned type?).  */
   if ((type & BRIG_TYPE_PACK_MASK) == BRIG_TYPE_PACK_128)
--- gcc/tree-vect-loop-manip.c.jj   2018-03-13 21:32:00.976647708 +0100
+++ gcc/tree-vect-loop-manip.c  2018-03-16 17:46:21.065393353 +0100
@@ -2700,7 +2700,7 @@ vect_do_peeling (loop_vec_info loop_vinf
 /* Function vect_create_cond_for_niters_checks.
 
Create a conditional expression that represents the run-time checks for
-   loop's niter.  The loop is guaranteed to to terminate if the run-time
+   loop's niter.  The loop is guaranteed to terminate if the run-time
checks hold.
 
Input:
--- gcc/gimple-ssa-warn-restrict.c.jj   2018-03-09 20:11:55.135835711 +0100
+++ gcc/gimple-ssa-warn-restrict.c  2018-03-16 17:45:03.983355395 +0100
@@ -417,7 +417,7 @@ builtin_memref::set_base_and_offset (tre
 
   poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
 
-  /* Convert the poly_int64 offset to to offset_int.  The offset
+  /* Convert the poly_int64 offset to offset_int.  The offset
  should be constant but be prepared for it not to be just in
  case.  */
   offset_int cstoff;

Jakub


[Committed] PR fortran/69395 -- Correct error condition

2018-03-16 Thread Steve Kargl
The following patch fixes essentially and off-by-one
in the error condition.  Committed as obvious.

2018-03-16  Steven G. Kargl  

PR fortran/69395
* decl.c (merge_array_spec): Correct the error condition.

2018-03-16  Steven G. Kargl  

PR fortran/69395
* gfortran.dg/pr69395.f90: Add test for max dimensions

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 258581)
+++ gcc/fortran/decl.c  (working copy)
@@ -871,7 +871,7 @@ merge_array_spec (gfc_array_spec *from, gfc_array_spec
}
 }
 
-  if (to->rank + to->corank >= GFC_MAX_DIMENSIONS)
+  if (to->rank + to->corank > GFC_MAX_DIMENSIONS)
 {
   gfc_error ("Sum of array rank %d and corank %d at %C exceeds maximum "
 "allowed dimensions of %d",
Index: gcc/testsuite/gfortran.dg/pr69395.f90
===
--- gcc/testsuite/gfortran.dg/pr69395.f90   (revision 258580)
+++ gcc/testsuite/gfortran.dg/pr69395.f90   (working copy)
@@ -1,5 +1,6 @@
 ! { dg-do compile }
 ! { dg-options "-fcoarray=single" }
 program p
+real, dimension(1,2,1,2,1,2,1,2), codimension[1,2,1,2,1,2,*] :: y
 real, dimension(1,2,1,2,1,2,1,2), codimension[1,2,1,2,1,2,1,*] :: z  ! { 
dg-error "allowed dimensions" }
 end

-- 
Steve


libgo patch committed: add missing entry to noinst_DATA

2018-03-16 Thread Ian Lance Taylor
This libgo patch adds runtime/pprof/internal/profile.gox to
noinst_DATA.  That package is only used by tests, so it needs to be in
noinst_DATA to ensure that it is built when tests are run.

It also adds noinst_DATA to CHECK_DEPS; it's not needed in practice
since `make` will build noinst_DATA, but it's logically required and
will make a difference if any of the noinst_DATA sources change
between `make` and `make check`.

As an aside,
Tony Reix figured out why omitting packages from noinst_DATA didn't
seem to matter: because if gccgo can't find foo.gox, it will fall back
to reading the export data in foo.o, and foo.o will exist because
these packages go into libgo.a.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 258565)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-e4464efc767b8dee4f4c18ffaf6c891f7b9deee7
+e9c0e4d8fd3d951a367bb6a50e5cb546e01b81a8
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 258392)
+++ libgo/Makefile.am   (working copy)
@@ -399,7 +399,8 @@ noinst_DATA = \
internal/testenv.gox \
internal/trace.gox \
net/internal/socktest.gox \
-   os/signal/internal/pty.gox
+   os/signal/internal/pty.gox \
+   runtime/pprof/internal/profile.gox
 
 if LIBGO_IS_RTEMS
 rtems_task_variable_add_file = runtime/rtems-task-variable-add.c
@@ -1094,6 +1095,7 @@ CHECK_DEPS = \
$(toolexeclibgotext_DATA) \
$(toolexeclibgotexttemplate_DATA) \
$(toolexeclibgounicode_DATA) \
+   $(noinst_DATA) \
$(noinst_LIBRARIES)
 
 if GOC_IS_LLGO


Re: C++ PATCH for c++/84720, ICE with rvalue ref template parameter

2018-03-16 Thread Jason Merrill
On Tue, Mar 13, 2018 at 2:54 PM, Jason Merrill  wrote:
> It's unclear to me that it is ever possible to instantiate a template
> taking an rvalue ref parameter, but I guess we might as well handle it
> properly.

...except that such parameters are actually ill-formed, so we should reject.
commit dea7cfdf2f1e7f17befbe3987badba9f74a6b2b9
Author: Jason Merrill 
Date:   Fri Mar 16 14:01:14 2018 -0400

PR c++/84720 - ICE with rvalue ref non-type argument.

* pt.c (invalid_nontype_parm_type_p): Prohibit rvalue reference.
(convert_nontype_argument): Revert earlier change.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 6c96424152e..f7b1b0dd9aa 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -23985,7 +23985,10 @@ invalid_nontype_parm_type_p (tree type, tsubst_flags_t complain)
 {
   if (INTEGRAL_OR_ENUMERATION_TYPE_P (type))
 return false;
-  else if (POINTER_TYPE_P (type))
+  else if (TYPE_PTR_P (type))
+return false;
+  else if (TREE_CODE (type) == REFERENCE_TYPE
+	   && !TYPE_REF_IS_RVALUE (type))
 return false;
   else if (TYPE_PTRMEM_P (type))
 return false;
diff --git a/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C b/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C
index b8e0daba0f7..06516dfa2b9 100644
--- a/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C
@@ -1,7 +1,7 @@
 // PR c++/84720
 // { dg-do compile { target c++11 } }
 
-template
+template		// { dg-error "not a valid type" }
 struct a {
   template
   static void b() {


patch to fix PR84876

2018-03-16 Thread Vladimir Makarov

The following patch fixes

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84876

and another problem with LRA cycling which occurred on the same test.

The patch was successfully bootstrapped and tested on i686 and x86_64.

Committed as rev. 258602.


Index: ChangeLog
===
--- ChangeLog	(revision 258601)
+++ ChangeLog	(working copy)
@@ -1,3 +1,11 @@
+2018-03-16  Vladimir Makarov  
+
+	PR target/84876
+	* lra-assigns.c (lra_split_hard_reg_for): Don't use
+	regno_allocno_class_array and sorted_pseudos.
+	* lra-constraints.c (spill_hard_reg_in_range): Ignore hard regs in
+	insns where regno is used.
+
 2018-03-16  Martin Liska  
 
 	PR ipa/84833
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog	(revision 258601)
+++ testsuite/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2018-03-16  Vladimir Makarov  
+
+	PR target/84876
+	* gcc.target/i386/pr84876.c: New test.
+
 2018-03-16  Martin Liska  
 
 	PR ipa/84833
Index: lra-assigns.c
===
--- lra-assigns.c	(revision 258504)
+++ lra-assigns.c	(working copy)
@@ -1737,41 +1737,46 @@ find_reload_regno_insns (int regno, rtx_
 bool
 lra_split_hard_reg_for (void)
 {
-  int i, regno, n;
+  int i, regno;
   rtx_insn *insn, *first, *last;
   unsigned int u;
   bitmap_iterator bi;
+  enum reg_class rclass;
   int max_regno = max_reg_num ();
   /* We did not assign hard regs to reload pseudos after two
  iterations.  Either it's an asm and something is wrong with the
  constraints, or we have run out of spill registers; error out in
  either case.  */
   bool asm_p = false;
-  bitmap_head failed_reload_insns;
+  bitmap_head failed_reload_insns, failed_reload_pseudos;
   
   if (lra_dump_file != NULL)
 fprintf (lra_dump_file,
 	 "\n** Splitting a hard reg after assignment #%d: **\n\n",
 	 lra_assignment_iter);
-  for (n = 0, i = lra_constraint_new_regno_start; i < max_regno; i++)
+  bitmap_initialize (_reload_pseudos, _obstack);
+  for (i = lra_constraint_new_regno_start; i < max_regno; i++)
 if (reg_renumber[i] < 0 && lra_reg_info[i].nrefs != 0
-	&& regno_allocno_class_array[i] != NO_REGS
+	&& (rclass = lra_get_allocno_class (i)) != NO_REGS
 	&& ! bitmap_bit_p (_reload_pseudos, i))
   {
-	sorted_pseudos[n++] = i;
 	if (! find_reload_regno_insns (i, first, last))
 	  continue;
-	if (spill_hard_reg_in_range (i, regno_allocno_class_array[i],
- first, last))
-	  return true;
+	if (spill_hard_reg_in_range (i, rclass, first, last))
+	  {
+	bitmap_clear (_reload_pseudos);
+	return true;
+	  }
+	bitmap_set_bit (_reload_pseudos, i);
   }
   bitmap_initialize (_reload_insns, _obstack);
-  for (i = 0; i < n; i++)
+  EXECUTE_IF_SET_IN_BITMAP (_reload_pseudos, 0, u, bi)
 {
-  regno = sorted_pseudos[i];
+  regno = u;
   bitmap_ior_into (_reload_insns,
 		   _reg_info[regno].insn_bitmap);
-  lra_setup_reg_renumber (regno, ira_class_hard_regs[regno_allocno_class_array[regno]][0], false);
+  lra_setup_reg_renumber
+	(regno, ira_class_hard_regs[lra_get_allocno_class (regno)][0], false);
 }
   EXECUTE_IF_SET_IN_BITMAP (_reload_insns, 0, u, bi)
 {
@@ -1805,5 +1810,7 @@ lra_split_hard_reg_for (void)
 	  fatal_insn ("this is the insn:", insn);
 	}
 }
+  bitmap_clear (_reload_pseudos);
+  bitmap_clear (_reload_insns);
   return false;
 }
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 258504)
+++ lra-constraints.c	(working copy)
@@ -5680,13 +5680,30 @@ spill_hard_reg_in_range (int regno, enum
   int i, hard_regno;
   int rclass_size;
   rtx_insn *insn;
+  unsigned int uid;
+  bitmap_iterator bi;
+  HARD_REG_SET ignore;
   
   lra_assert (from != NULL && to != NULL);
+  CLEAR_HARD_REG_SET (ignore);
+  EXECUTE_IF_SET_IN_BITMAP (_reg_info[regno].insn_bitmap, 0, uid, bi)
+{
+  lra_insn_recog_data_t id = lra_insn_recog_data[uid];
+  struct lra_static_insn_data *static_id = id->insn_static_data;
+  struct lra_insn_reg *reg;
+  
+  for (reg = id->regs; reg != NULL; reg = reg->next)
+	if (reg->regno <= FIRST_PSEUDO_REGISTER)
+	  SET_HARD_REG_BIT (ignore, reg->regno);
+  for (reg = static_id->hard_regs; reg != NULL; reg = reg->next)
+	SET_HARD_REG_BIT (ignore, reg->regno);
+}
   rclass_size = ira_class_hard_regs_num[rclass];
   for (i = 0; i < rclass_size; i++)
 {
   hard_regno = ira_class_hard_regs[rclass][i];
-  if (! TEST_HARD_REG_BIT (lra_reg_info[regno].conflict_hard_regs, hard_regno))
+  if (! TEST_HARD_REG_BIT (lra_reg_info[regno].conflict_hard_regs, hard_regno)
+	  || TEST_HARD_REG_BIT (ignore, hard_regno))
 	continue;
   for (insn = from; insn != NEXT_INSN (to); insn = NEXT_INSN (insn))
 	if (bitmap_bit_p 

C++ PATCH for c++/80227, SFINAE and negative array size

2018-03-16 Thread Jason Merrill
In this testcase, because sizeof (T) - 5 has unsigned type, it ends up
being an extremely large number rather than a negative one.
valid_constant_size_p seems to be a useful predicate for recognizing
problematic cases; tree_int_cst_sign_bit should also work, but seems
more subtle.

While I was looking at this I also noticed that the standard has
changed to specify that array bounds are converted constant
expressions, which allows us to simplify some of the code earlier in
the function.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit d4ae942cdaf2f3a5b64c187d68a0907e5f611fbd
Author: Jason Merrill 
Date:   Fri Mar 16 10:50:59 2018 -0400

PR c++/80227 - SFINAE and negative array size.

* decl.c (compute_array_index_type): Use
build_converted_constant_expr and valid_constant_size_p.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 727bb04a394..546468bf79f 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -9514,8 +9514,6 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
 
   if (!type_dependent_expression_p (size))
 {
-  tree type = TREE_TYPE (size);
-
   size = mark_rvalue_use (size);
 
   if (cxx_dialect < cxx11 && TREE_CODE (size) == NOP_EXPR
@@ -9525,29 +9523,8 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
   else
 	{
 	  size = instantiate_non_dependent_expr_sfinae (size, complain);
-
-	  if (CLASS_TYPE_P (type)
-	  && CLASSTYPE_LITERAL_P (type))
-	{
-	  size = build_expr_type_conversion (WANT_INT, size, true);
-	  if (!size)
-		{
-		  if (!(complain & tf_error))
-		return error_mark_node;
-		  if (name)
-		error ("size of array %qD has non-integral type %qT",
-			   name, type);
-		  else
-		error ("size of array has non-integral type %qT", type);
-		  size = integer_one_node;
-		}
-	  if (size == error_mark_node)
-		return error_mark_node;
-	  type = TREE_TYPE (size);
-	}
-
-	  if (INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (type))
-	size = maybe_constant_value (size);
+	  size = build_converted_constant_expr (size_type_node, size, complain);
+	  size = maybe_constant_value (size);
 
 	  if (!TREE_CONSTANT (size))
 	size = osize;
@@ -9557,6 +9534,7 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
 	return error_mark_node;
 
   /* The array bound must be an integer type.  */
+  tree type = TREE_TYPE (size);
   if (!INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (type))
 	{
 	  if (!(complain & tf_error))
@@ -9566,7 +9544,6 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
 	  else
 	error ("size of array has non-integral type %qT", type);
 	  size = integer_one_node;
-	  type = TREE_TYPE (size);
 	}
 }
 
@@ -9604,15 +9581,12 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
   /* Normally, the array-bound will be a constant.  */
   if (TREE_CODE (size) == INTEGER_CST)
 {
-  /* Check to see if the array bound overflowed.  Make that an
-	 error, no matter how generous we're being.  */
-  constant_expression_error (size);
-
   /* An array must have a positive number of elements.  */
-  if (tree_int_cst_lt (size, integer_zero_node))
+  if (!valid_constant_size_p (size))
 	{
 	  if (!(complain & tf_error))
 	return error_mark_node;
+
 	  if (name)
 	error ("size of array %qD is negative", name);
 	  else
diff --git a/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg8.C b/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg8.C
new file mode 100644
index 000..8d9b2d26f01
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg8.C
@@ -0,0 +1,10 @@
+// PR c++/80227
+// { dg-do compile { target c++11 } }
+
+template 
+int foo (T);
+
+template 
+int foo (T, U* = 0);
+
+int i = foo (123);
diff --git a/gcc/testsuite/g++.dg/gomp/pr47963.C b/gcc/testsuite/g++.dg/gomp/pr47963.C
index 7c94e6422a7..5b0c60b80a4 100644
--- a/gcc/testsuite/g++.dg/gomp/pr47963.C
+++ b/gcc/testsuite/g++.dg/gomp/pr47963.C
@@ -5,7 +5,7 @@
 void
 foo (float n)
 {
-  int A[n][n];	// { dg-error "has non-integral type" }
+  int A[n][n];	// { dg-error "has non-integral type|converted constant expression" }
 #pragma omp parallel private(A)
   ;
 }
diff --git a/gcc/testsuite/g++.dg/init/new37.C b/gcc/testsuite/g++.dg/init/new37.C
index 3255a696143..9ecbfd7903d 100644
--- a/gcc/testsuite/g++.dg/init/new37.C
+++ b/gcc/testsuite/g++.dg/init/new37.C
@@ -32,7 +32,7 @@ template 
 void *
 callnew_fail_3()
 {
-  return new T[2][T::n]; // { dg-error "size of array has non-integral type" }
+  return new T[2][T::n]; // { dg-error "size of array has non-integral type|converted constant expression" }
 }
 
 struct T1 {
diff --git a/gcc/testsuite/g++.dg/init/new44.C b/gcc/testsuite/g++.dg/init/new44.C
index ab6e3484cc8..4ab73209e22 100644
--- a/gcc/testsuite/g++.dg/init/new44.C
+++ b/gcc/testsuite/g++.dg/init/new44.C
@@ -87,10 +87,10 @@ test_one_dim_short_array ()
 static void 

C++ PATCH for c++/84906, silent wrong code with ambiguous conversion

2018-03-16 Thread Jason Merrill
The problem here was that when we initially looked for the conversion
we were in direct-initialization context, but then when we tried to do
the lookup again to get an error it was done in copy-initialization
context, so it was no longer ambiguous.  Fixed by remembering which
we're in.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0959fc01e907ccc575d09280154b437efce97f33
Author: Jason Merrill 
Date:   Fri Mar 16 11:24:23 2018 -0400

PR c++/84906 - silent wrong code with ambiguous conversion.

* call.c (build_user_type_conversion_1): Set need_temporary_p on
ambiguous conversion.
(convert_like_real): Check it.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index a32f41915fc..23d4f82a1a0 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -93,7 +93,8 @@ struct conversion {
   BOOL_BITFIELD bad_p : 1;
   /* If KIND is ck_ref_bind ck_base_conv, true to indicate that a
  temporary should be created to hold the result of the
- conversion.  */
+ conversion.  If KIND is ck_ambig, true if the context is
+ copy-initialization.  */
   BOOL_BITFIELD need_temporary_p : 1;
   /* If KIND is ck_ptr or ck_pmem, true to indicate that a conversion
  from a pointer-to-derived to pointer-to-base is being performed.  */
@@ -3943,6 +3944,8 @@ build_user_type_conversion_1 (tree totype, tree expr, int flags,
   cand->second_conv->user_conv_p = true;
   if (!any_strictly_viable (candidates))
 	cand->second_conv->bad_p = true;
+  if (flags & LOOKUP_ONLYCONVERTING)
+	cand->second_conv->need_temporary_p = true;
   /* If there are viable candidates, don't set ICS_BAD_FLAG; an
 	 ambiguous conversion is no worse than another user-defined
 	 conversion.  */
@@ -6834,8 +6837,10 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum,
   if (complain & tf_error)
 	{
 	  /* Call build_user_type_conversion again for the error.  */
-	  build_user_type_conversion (totype, convs->u.expr, LOOKUP_IMPLICIT,
-  complain);
+	  int flags = (convs->need_temporary_p
+		   ? LOOKUP_IMPLICIT : LOOKUP_NORMAL);
+	  build_user_type_conversion (totype, convs->u.expr, flags, complain);
+	  gcc_assert (seen_error ());
 	  if (fn)
 	inform (DECL_SOURCE_LOCATION (fn),
 		"  initializing argument %P of %qD", argnum, fn);
diff --git a/gcc/testsuite/g++.dg/cpp1y/auto-fn50.C b/gcc/testsuite/g++.dg/cpp1y/auto-fn50.C
new file mode 100644
index 000..a2c7e40755b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/auto-fn50.C
@@ -0,0 +1,23 @@
+// PR c++/84906
+// { dg-do compile { target c++14 } }
+
+extern "C" int puts(const char*);
+
+struct aa {
+  operator auto() {
+puts("auto");
+return false;
+  }
+  explicit operator bool() {
+puts("bool");
+return true;
+  }
+};
+
+int main() {
+  aa x;
+  if (x)			// { dg-error "ambiguous" }
+puts("here");
+  else
+puts("there");
+}


Re: Enable string_view assertions

2018-03-16 Thread Jonathan Wakely
On 15 March 2018 at 00:18, Jonathan Wakely wrote:
> On 14 March 2018 at 23:27, Jonathan Wakely wrote:
>> Here's one way to generalize this idea. We could potentially replace
>> most of the lightweight __glibcxx_assert checks with this, to get
>> zero-overhead static checking at compile-time whenever possible (even
>> in constexpr functions) and have optional run-time assertions for the
>> remaining cases.
>
> Thinking about this some more, we probably don't want to do this for
> most __glibcxx_assert uses, because it's probably rare that we can
> statically detect most errors in something like
> std::vector::operator[]. I doubt we would catch many bugs that way, as
> most bugs would involve non-constant indices and vectors that have
> changed size dynamically at run-time.
>
> It *might* be useful  in vector::front, vector::back, string::front,
> deque::front etc. to catch bugs where users do:
>
> std::string s;
> // ...
> someFunction((), s.size());
>
> It seems most valuable in constexpr functions (where we definitely
> expect constant arguments in many cases) and where run-time arguments
> will typically be constants, like in the attached patch for atomic
> objects.

Those patches aren't quite right. It's OK to make compilation fail
when undefined behaviour is detected in a constant expression, but if
we detect it in other contexts (because optimization means all the
inputs are known at compile-time) we need to use
__attribute((__warning__(""))) not __error__. Those cases are only
undefined if the code is executed, so we can only warn and then fail
at run-time.


New Ukrainian PO file for 'gcc' (version 8.1-b20180128)

2018-03-16 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'gcc-8.1-b20180128.uk.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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




Re: [RFC Patch], PowerPC memory support pre-gcc9, patch #4

2018-03-16 Thread Michael Meissner
Here is patch #4 that moves the MOVDF/MOVDD insns into calling C code.  I added
documentation to the various MOVD{F,D} patterns similar to the documentation
I've done on the other patterns to make it simpler to track which two
constraints match which instruction and which instruction type is used.

The next patch may tackle an instruction discrepancy that I've noticed in
building Spec 2006.  The tonto benchmark generates slightly different code with
these changes than with.  It doesn't affect the runtime of the benchmark, but
for these infrastructure changes, they should generate the same code.

After that, I will tackle the 32-bit moves and then the 8/16-bit moves.

2018-03-16  Michael Meissner  

* config/rs6000/rs6000-output.c (rs6000_output_move_64bit): Deal
with SPR<-SPR where the register is the same.
* config/rs6000/rs6000.md (mov_hardfloat32): Add comments
and spacing to allow easier understanding of which constraints are
used for which alternative.  Use rs6000_valid_move_p to validate
the move.  Use rs6000_output_move_64bit to print out the correct
instruction.
(mov_softfloat32): Likewise.
(mov_hardfloat64): Likewise.
(mov_softfloat64): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000-output.c
===
--- gcc/config/rs6000/rs6000-output.c   (revision 258576)
+++ gcc/config/rs6000/rs6000-output.c   (working copy)
@@ -162,7 +162,13 @@ rs6000_output_move_64bit (rtx operands[]
 
   /* Moves to SPRs.  */
   else if (reg_is_spr_p (dest))
-   return "mt%0 %1";
+   {
+ if (src_gpr_p)
+   return "mt%0 %1";
+
+ else if (dest_regno == src_regno)
+   return "nop";
+   }
 }
 
   /* Loads.  */
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 258576)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -7398,92 +7398,108 @@ (define_split
 ;; If we have FPR registers, rs6000_emit_move has moved all constants to 
memory,
 ;; except for 0.0 which can be created on VSX with an xor instruction.
 
+;;   STFD LFD FMR LXSDSTXSD
+;;   LXSD STXSD   XXLOR   XXLXOR  GPR<-0
+;;   LWZ  STW MR
+
 (define_insn "*mov_hardfloat32"
-  [(set (match_operand:FMOVE64 0 "nonimmediate_operand" 
"=m,d,d,,wY,,Z,,,!r,Y,r,!r")
-   (match_operand:FMOVE64 1 "input_operand" 
"d,m,d,wY,,Z,r,Y,r"))]
+  [(set (match_operand:FMOVE64 0 "nonimmediate_operand"
+"=m,  d,  d,  ,   wY,
+  ,   Z,  ,  ,  !r,
+  Y,  r,  !r")
+
+   (match_operand:FMOVE64 1 "input_operand"
+ "d,  m,  d,  wY, ,
+  Z,  ,   ,  ,  ,
+  r,  Y,  r"))]
+
   "! TARGET_POWERPC64 && TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT 
-   && (gpc_reg_operand (operands[0], mode)
-   || gpc_reg_operand (operands[1], mode))"
-  "@
-   stfd%U0%X0 %1,%0
-   lfd%U1%X1 %0,%1
-   fmr %0,%1
-   lxsd %0,%1
-   stxsd %1,%0
-   lxsd%U1x %x0,%y1
-   stxsd%U0x %x1,%y0
-   xxlor %x0,%x1,%x1
-   xxlxor %x0,%x0,%x0
-   #
-   #
-   #
-   #"
-  [(set_attr "type" 
"fpstore,fpload,fpsimple,fpload,fpstore,fpload,fpstore,veclogical,veclogical,two,store,load,two")
+   && rs6000_valid_move_p (operands[0], operands[1])"
+  "* return rs6000_output_move_64bit (operands);"
+  [(set_attr "type"
+"fpstore, fpload, fpsimple,   fpload, fpstore,
+ fpload,  fpstore,veclogical, veclogical, two,
+ store,   load,   two")
+
(set_attr "size" "64")
-   (set_attr "length" "4,4,4,4,4,4,4,4,4,8,8,8,8")])
+   (set_attr "length"
+"4,   4,  4,  4,  4,
+ 4,   4,  4,  4,  8,
+ 8,   8,  8")])
+
+;;   STW  LWZ MR  G-const H-const F-const
 
 (define_insn "*mov_softfloat32"
-  [(set (match_operand:FMOVE64 0 "nonimmediate_operand" "=Y,r,r,r,r,r")
-   (match_operand:FMOVE64 1 "input_operand" "r,Y,r,G,H,F"))]
-  "! TARGET_POWERPC64 
-   && (TARGET_SINGLE_FLOAT || TARGET_SOFT_FLOAT)
-   && (gpc_reg_operand (operands[0], mode)
-   || gpc_reg_operand (operands[1], mode))"
-  "#"
-  [(set_attr "type" "store,load,two,*,*,*")
-   (set_attr "length" "8,8,8,8,12,16")])
+  [(set (match_operand:FMOVE64 0 "nonimmediate_operand"
+   "=Y,   r,  r,  r,  r,  r")
+
+   (match_operand:FMOVE64 1 "input_operand"
+"r,   Y,  r,  G,  H,  F"))]
+
+  "! TARGET_POWERPC64 

New German PO file for 'gcc' (version 8.1-b20180128)

2018-03-16 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'gcc-8.1-b20180128.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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




Re: [committed] Fix ICE for missing header fix-it hints with overlarge #line directives (PR c/84852)

2018-03-16 Thread David Malcolm
On Fri, 2018-03-16 at 10:18 +, Bin.Cheng wrote:
> On Thu, Mar 15, 2018 at 1:32 AM, Paul Hua 
> wrote:
> > Hi:
> > 
> > The fixits-pr84852-1.c fails on mips64el target.
> 
> Hi,
> It fails on aarch64/arm bare-metal cross toolchains with different
> message like:
> ERROR: gcc.dg/fixits-pr84852-1.c: bad option "-812156810": must be
> -exact, -glob, -regexp, or -- for " dg-warning 15 "incompatible
> implicit declaration of built-in function 'strlen'" "" { target *-*-*
> } -812156810 "

Sorry about that.  I *think* that's coming from saved-dg-warning, which
is the dg-warning from DejaGnu.  Which version of DejaGnu is this with?

Works for me with 1.5.2


[PATCH][OBVIOUS] Fix UBSAN in regrename.c (PR rtl-optimization/84635).

2018-03-16 Thread Martin Liška
Hi.

It's quite obvious mistake, where we access an array variable before
we check index boundary.

I'll install it after bootstrap & regression tests.

Martin

gcc/ChangeLog:

2018-03-16  Martin Liska  

PR rtl-optimization/84635
* regrename.c (build_def_use): Use matches_mode only when
matches >= 0.
---
 gcc/regrename.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)


diff --git a/gcc/regrename.c b/gcc/regrename.c
index dcec77adf75..45754812f6c 100644
--- a/gcc/regrename.c
+++ b/gcc/regrename.c
@@ -1703,14 +1703,18 @@ build_def_use (basic_block bb)
 		 and we must instead make sure to make the operand visible
 		 to the machinery that tracks hard registers.  */
 		  machine_mode i_mode = recog_data.operand_mode[i];
-		  machine_mode matches_mode = recog_data.operand_mode[matches];
-		  if (matches >= 0
-		  && maybe_ne (GET_MODE_SIZE (i_mode),
-   GET_MODE_SIZE (matches_mode))
-		  && !verify_reg_in_set (op, _in_chains))
+		  if (matches >= 0)
 		{
-		  untracked_operands |= 1 << i;
-		  untracked_operands |= 1 << matches;
+		  machine_mode matches_mode
+			= recog_data.operand_mode[matches];
+
+		  if (maybe_ne (GET_MODE_SIZE (i_mode),
+GET_MODE_SIZE (matches_mode))
+			  && !verify_reg_in_set (op, _in_chains))
+			{
+			  untracked_operands |= 1 << i;
+			  untracked_operands |= 1 << matches;
+			}
 		}
 		}
 #ifdef STACK_REGS



Re: [PATCH] Fix PR84512

2018-03-16 Thread Tom de Vries

On 03/16/2018 12:55 PM, Richard Biener wrote:

On Fri, 16 Mar 2018, Tom de Vries wrote:


On 02/27/2018 01:42 PM, Richard Biener wrote:

Index: gcc/testsuite/gcc.dg/tree-ssa/pr84512.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr84512.c (nonexistent)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr84512.c (working copy)
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-tree-optimized" } */
+
+int foo()
+{
+  int a[10];
+  for(int i = 0; i < 10; ++i)
+a[i] = i*i;
+  int res = 0;
+  for(int i = 0; i < 10; ++i)
+res += a[i];
+  return res;
+}
+
+/* { dg-final { scan-tree-dump "return 285;" "optimized" } } */


This fails for nvptx, because it doesn't have the required vector operations.
To fix the fail, I've added requiring effective target vect_int_mult.


On targets that do not vectorize you should see the scalar loops unrolled
instead.  Or do you have only one loop vectorized?


Sort of. Loop vectorization has no effect, and the scalar loops are 
completely unrolled. But then slp vectorization vectorizes the stores.


So at optimized we have:
...
  MEM[(int *)] = { 0, 1 };
  MEM[(int *) + 8B] = { 4, 9 };
  MEM[(int *) + 16B] = { 16, 25 };
  MEM[(int *) + 24B] = { 36, 49 };
  MEM[(int *) + 32B] = { 64, 81 };
  _6 = a[0];
  _28 = a[1];
  res_29 = _6 + _28;
  _35 = a[2];
  res_36 = res_29 + _35;
  _42 = a[3];
  res_43 = res_36 + _42;
  _49 = a[4];
  res_50 = res_43 + _49;
  _56 = a[5];
  res_57 = res_50 + _56;
  _63 = a[6];
  res_64 = res_57 + _63;
  _70 = a[7];
  res_71 = res_64 + _70;
  _77 = a[8];
  res_78 = res_71 + _77;
  _2 = a[9];
  res_11 = _2 + res_78;
  a ={v} {CLOBBER};
  return res_11;
...

The stores and loads are eliminated by dse1 in the rtl phase, and in the 
end we have:

...
.visible .func (.param.u32 %value_out) foo
{
.reg.u32 %value;
.local .align 16 .b8 %frame_ar[48];
.reg.u64 %frame;
cvta.local.u64 %frame, %frame_ar;
mov.u32 %value, 285;
st.param.u32[%value_out], %value;
ret;
}
...


That's precisely
what the PR was about...  which means it isn't fixed for nvptx :/


Indeed the assembly is not optimal, and would be optimal if we'd have 
optimal code at optimized.


FWIW, using this patch we generate optimal code at optimized:
...
diff --git a/gcc/passes.def b/gcc/passes.def
index 3ebcfc30349..6b64f600c4a 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -325,6 +325,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_tracer);
   NEXT_PASS (pass_thread_jumps);
   NEXT_PASS (pass_dominator, false /* may_peel_loop_headers_p */);
+  NEXT_PASS (pass_fre);
   NEXT_PASS (pass_strlen);
   NEXT_PASS (pass_thread_jumps);
   NEXT_PASS (pass_vrp, false /* warn_array_bounds_p */);
...

and we get:
...
.visible .func (.param.u32 %value_out) foo
{
.reg.u32 %value;
mov.u32 %value, 285;
st.param.u32[%value_out], %value;
ret;
}
...

I could file a missing optimization PR for nvptx, but I'm not sure where 
this should be fixed.


Thanks,
- Tom


Re: [PATCH] Properly redirect alias for MVC (PR ipa/84722).

2018-03-16 Thread Martin Liška
On 03/13/2018 09:21 AM, Martin Liška wrote:
> Hi.
> 
> When having a weak alias that points to a multi-versioning function, one
> needs to redirect the alias properly.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> 
> Ready for trunk?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2018-03-12  Martin Liska  
> 
> PR ipa/84722
> * multiple_target.c (create_dispatcher_calls): Redirect also
> an alias.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-03-12  Martin Liska  
> 
> PR ipa/84722
> * gcc.target/i386/mvc10.c: New test.
> ---
>  gcc/multiple_target.c |  7 +++
>  gcc/testsuite/gcc.target/i386/mvc10.c | 16 
>  2 files changed, 23 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/i386/mvc10.c
> 
> 

Honza approved that offline.

Martin


Re: [PATCH] Redirect reference in the symbol table (PR ipa/84833).

2018-03-16 Thread Martin Liška
On 03/13/2018 02:35 PM, Martin Liška wrote:
> Hi.
> 
> This fixed issue where we have an ifunc function called from another ifunc 
> function.
> One needs to properly make a reference redirection.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> MVC tests on x86_64 also work fine.
> 
> Ready for trunk?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2018-03-13  Martin Liska  
> 
> PR ipa/84833
> * multiple_target.c (create_dispatcher_calls): Redirect
> reference in the symbol table.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-03-13  Martin Liska  
> 
> PR ipa/84833
> * gcc.target/i386/mvc11.c: New test.
> ---
>  gcc/multiple_target.c |  4 
>  gcc/testsuite/gcc.target/i386/mvc11.c | 28 
>  2 files changed, 32 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/i386/mvc11.c
> 
> 

Honza approved that offline.

Martin


Re: [PATCH] Handle -fno-guess-branch-probability properly in predict.c (PR ipa/84825).

2018-03-16 Thread Martin Liška
On 03/13/2018 01:13 PM, Martin Liška wrote:
> Hi.
> 
> This is a fix for situation where we use -fno-guess-branch-probability and 
> fnsplit happens.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> 
> Ready for trunk?
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> 2018-03-13  Martin Liska  
> 
> PR ipa/84825
> * predict.c (rebuild_frequencies): Handle case when we have
> PROFILE_ABSENT, but flag_guess_branch_prob is false.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-03-13  Martin Liska  
> 
> * g++.dg/ipa/pr84825.C: New test.
> ---
>  gcc/predict.c  |  3 +++
>  gcc/testsuite/g++.dg/ipa/pr84825.C | 18 ++
>  2 files changed, 21 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/ipa/pr84825.C
> 
> 

Honza asked about a place where a BB count is set up. It's here:

(gdb) bt
#0  init_lowered_empty_function (decl=0x7692a700, in_ssa=true, count=...) 
at ../../gcc/cgraphunit.c:1606
#1  0x00cddde1 in cgraph_node::expand_thunk (this=0x7692f2e0, 
output_asm_thunks=false, force_gimple_thunk=false) at 
../../gcc/cgraphunit.c:1856
#2  0x00cd9e01 in cgraph_node::analyze (this=0x7692f2e0) at 
../../gcc/cgraphunit.c:635
#3  0x00cdb85c in analyze_functions (first_time=true) at 
../../gcc/cgraphunit.c:1131
#4  0x00ce0510 in symbol_table::finalize_compilation_unit 
(this=0x767b0100) at ../../gcc/cgraphunit.c:2691
#5  0x012908d8 in compile_file () at ../../gcc/toplev.c:480
#6  0x012931fd in do_compile () at ../../gcc/toplev.c:2132
#7  0x012934ea in toplev::main (this=0x7fffd7de, argc=24, 
argv=0x7fffd8d8) at ../../gcc/toplev.c:2267
#8  0x01f69194 in main (argc=24, argv=0x7fffd8d8) at 
../../gcc/main.c:39

(gdb) p count.debug()
1 (estimated locally)
$7 = void

Martin


C++ PATCH for c++/83937, wrong C++17 overload resolution with constructor and {}

2018-03-16 Thread Jason Merrill
With T({}), the {} specifically initializes the first constructor
parameter, rather than T directly.  This is different from T{}, so we
need to check CONSTRUCTOR_IS_DIRECT_INIT.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 96fb2fc01280452682585dcc68038f54f416d034
Author: Jason Merrill 
Date:   Fri Mar 16 09:00:37 2018 -0400

PR c++/83937 - wrong C++17 handling of init-list ctor argument.

* call.c (build_special_member_call): Don't convert an init-list
argument directly to the class type.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 67438ff2e94..4bd3190b42e 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8829,7 +8829,12 @@ build_special_member_call (tree instance, tree name, vec **args,
 	/* If we're using this to initialize a non-temporary object, don't
 	   require the destructor to be accessible.  */
 	sub_complain |= tf_no_cleanup;
-  if (!reference_related_p (class_type, TREE_TYPE (arg)))
+  if (BRACE_ENCLOSED_INITIALIZER_P (arg)
+	  && !CONSTRUCTOR_IS_DIRECT_INIT (arg))
+	/* An init-list arg needs to convert to the parm type (83937), so fall
+	   through to normal processing.  */
+	arg = error_mark_node;
+  else if (!reference_related_p (class_type, TREE_TYPE (arg)))
 	arg = perform_implicit_conversion_flags (class_type, arg,
 		 sub_complain,
 		 flags);
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-ctor2.C b/gcc/testsuite/g++.dg/cpp0x/initlist-ctor2.C
new file mode 100644
index 000..ebacec0cff5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-ctor2.C
@@ -0,0 +1,15 @@
+// PR c++/83937
+// { dg-do run { target c++11 } }
+
+struct S
+{
+  S(int v = 42) {
+if (v != int{})
+  __builtin_abort();
+  }
+};
+
+int main()
+{
+  S( {} );
+} 


Re: [PATCH 1/3] [builtins] Generic support for __builtin_load_no_speculate()

2018-03-16 Thread Björn Weber
I ran a number of tests against this patch on non-ARM platforms and 
noticed something weird. The default_speculation_safe_load seems to have 
a logic twist. When cmpptr is greater or equal to the upper_bound the 
call is considered in-range.


In: gcc/targhooks.c
[..]
  do_compare_rtx_and_jump (cmpptr, upper_bound, GEU, true, ptr_mode,
   NULL, NULL, inrange_label,
   profile_probability::never ());
[..]

I am pretty certain that this is supposed to be LTU instead.
The code is the same for default_speculation_safe_load() in the V2 of 
the patch.


--
Bj\366rn Weber


[PATCH] Fix PR84859

2018-03-16 Thread Richard Biener

This fixes a bogus warning by performing MIN_EXPR detection on
memory which avoids bogus threading and isolating of a path with
a bogus memcpy.

I've gone back in time and at some point we had no MAX_STORES_TO_SINK
param but handled just the last_and_only_stmt case of sinking
two stores.  The param got added when the code was extended to handle
an arbitrary number of stores and thus did dependence checking which
eventually was thought to be too expensive to do without vectorization
or if-conversion enabled.

So this restores this ability even when MAX_STORES_TO_SINK is zero
and also generalizes it a bit to not only handle last_and_only_stmt
but the case where each BB has a single store without any following
loads.  In that case we can elide the dependence checking and perform
the desired transform (for the testcase one BB has another stmt
so last_and_only_stmt wouldn't have worked).

I've had to disable cselim on three testcases, one being a unit
test for PRE and two being unit tests (?!) for my very special
friend path splitting.

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok?

Thanks,
Richard.

2018-03-16  Richard Biener  

PR tree-optimization/84859
* tree-ssa-phiopt.c (single_trailing_store_in_bb): New function.
(cond_if_else_store_replacement): Perform sinking operation on
single-store BBs regardless of MAX_STORES_TO_SINK setting.
Generalize what a BB with a single eligible store is.

* gcc.dg/tree-ssa/pr84859.c: New testcase.
* gcc.dg/tree-ssa/pr35286.c: Disable cselim.
* gcc.dg/tree-ssa/split-path-6.c: Likewise.
* gcc.dg/tree-ssa/split-path-7.c: Likewise.

Index: gcc/tree-ssa-phiopt.c
===
--- gcc/tree-ssa-phiopt.c   (revision 258584)
+++ gcc/tree-ssa-phiopt.c   (working copy)
@@ -2035,6 +2035,36 @@ cond_if_else_store_replacement_1 (basic_
   return true;
 }
 
+/* Return the single store in BB with VDEF or NULL if there are
+   other stores in the BB or loads following the store.  */
+
+static gimple *
+single_trailing_store_in_bb (basic_block bb, tree vdef)
+{
+  if (SSA_NAME_IS_DEFAULT_DEF (vdef))
+return NULL;
+  gimple *store = SSA_NAME_DEF_STMT (vdef);
+  if (gimple_bb (store) != bb
+  || gimple_code (store) == GIMPLE_PHI)
+return NULL;
+
+  /* Verify there is no other store in this BB.  */
+  if (!SSA_NAME_IS_DEFAULT_DEF (gimple_vuse (store))
+  && gimple_bb (SSA_NAME_DEF_STMT (gimple_vuse (store))) == bb
+  && gimple_code (SSA_NAME_DEF_STMT (gimple_vuse (store))) != GIMPLE_PHI)
+return NULL;
+
+  /* Verify there is no load or store after the store.  */
+  use_operand_p use_p;
+  imm_use_iterator imm_iter;
+  FOR_EACH_IMM_USE_FAST (use_p, imm_iter, gimple_vdef (store))
+if (USE_STMT (use_p) != store
+   && gimple_bb (USE_STMT (use_p)) == bb)
+  return NULL;
+
+  return store;
+}
+
 /* Conditional store replacement.  We already know
that the recognized pattern looks like so:
 
@@ -2061,8 +2091,6 @@ static bool
 cond_if_else_store_replacement (basic_block then_bb, basic_block else_bb,
 basic_block join_bb)
 {
-  gimple *then_assign = last_and_only_stmt (then_bb);
-  gimple *else_assign = last_and_only_stmt (else_bb);
   vec then_datarefs, else_datarefs;
   vec then_ddrs, else_ddrs;
   gimple *then_store, *else_store;
@@ -2073,13 +2101,32 @@ cond_if_else_store_replacement (basic_bl
   tree then_lhs, else_lhs;
   basic_block blocks[3];
 
-  if (MAX_STORES_TO_SINK == 0)
+  /* Handle the case with single store in THEN_BB and ELSE_BB.  That is
+ cheap enough to always handle as it allows us to elide dependence
+ checking.  */
+  gphi *vphi = NULL;
+  for (gphi_iterator si = gsi_start_phis (join_bb); !gsi_end_p (si);
+   gsi_next ())
+if (virtual_operand_p (gimple_phi_result (si.phi (
+  {
+   vphi = si.phi ();
+   break;
+  }
+  if (!vphi)
 return false;
+  tree then_vdef = PHI_ARG_DEF_FROM_EDGE (vphi, single_succ_edge (then_bb));
+  tree else_vdef = PHI_ARG_DEF_FROM_EDGE (vphi, single_succ_edge (else_bb));
+  gimple *then_assign = single_trailing_store_in_bb (then_bb, then_vdef);
+  if (then_assign)
+{
+  gimple *else_assign = single_trailing_store_in_bb (else_bb, else_vdef);
+  if (else_assign)
+   return cond_if_else_store_replacement_1 (then_bb, else_bb, join_bb,
+then_assign, else_assign);
+}
 
-  /* Handle the case with single statement in THEN_BB and ELSE_BB.  */
-  if (then_assign && else_assign)
-return cond_if_else_store_replacement_1 (then_bb, else_bb, join_bb,
- then_assign, else_assign);
+  if (MAX_STORES_TO_SINK == 0)
+return false;
 
   /* Find data references.  */
   then_datarefs.create (1);
Index: gcc/testsuite/gcc.dg/tree-ssa/pr35286.c

Re: [PATCH][GCC][ARM] Fix can_change_mode_class for big-endian

2018-03-16 Thread Christophe Lyon
On 15 March 2018 at 11:19, Kyrill  Tkachov  wrote:
> Hi Tamar,
>
>
> On 05/03/18 16:51, Tamar Christina wrote:
>>
>> Hi All,
>>
>> Taking the subreg of a vector mode on big-endian may result in an infinite
>> recursion and eventually a segfault once we run out of stack space.
>>
>> As an example, taking a subreg of V4HF to SImode we end up in the
>> following
>> loop on big-endian:
>>
>> #861 0x008462e9 in operand_subword_force
>> src/gcc/gcc/emit-rtl.c:1787
>> #862 0x00882a90 in emit_move_multi_word src/gcc/gcc/expr.c:3621
>> #863 0x0087eea1 in emit_move_insn_1 src/gcc/gcc/expr.c:3698
>> #864 0x0087f350 in emit_move_insn src/gcc/gcc/expr.c:3757
>> #865 0x0085e326 in copy_to_reg src/gcc/gcc/explow.c:603
>> #866 0x008462e9 in operand_subword_force
>> src/gcc/gcc/emit-rtl.c:1787
>>
>> The reason is that operand_subword_force will always fail. When the value
>> is in
>> a register that can't be accessed as a multi word the code tries to create
>> a new
>> psuedo register and emit the value to it. Eventually you end up in
>> simplify_gen_subreg
>> which calls validate_subreg.
>>
>> validate_subreg will however always fail because of the
>> REG_CAN_CHANGE_MODE_P check.
>>
>> On little endian this check always returns true. On big-endian this check
>> is supposed
>> to prevent values that have a size larger than word size, due to those
>> being stored in
>> VFP registers.
>>
>> However we are only interested in a subreg of the vector mode, so we
>> should be checking
>> the unit size, not the size of the entire mode. Doing this fixes the
>> problem.
>>
>> Regtested on armeb-none-eabi and no regressions.
>> Bootstrapped on arm-none-linux-gnueabihf and no issues.
>>
>> Ok for trunk? and for backport to GCC 7?
>>
>
> Ok for trunk.
> Please wait for a few days before backporting.
>

Hi Tamar,

Strangely I have noticed regressions on armeb, I have updated bugzilla
accordingly.

Thanks,

Christophe

> Thanks,
> Kyrill
>
>
>> Thanks,
>> Tamar
>>
>> gcc/
>> 2018-03-05  Tamar Christina  
>>
>> PR target/84711
>> * config/arm/arm.c (arm_can_change_mode_class): Use
>> GET_MODE_UNIT_SIZE
>> instead of GET_MODE_SIZE when comparing Units.
>>
>> gcc/testsuite/
>> 2018-03-05  Tamar Christina  
>>
>> PR target/84711
>> * gcc.target/arm/big-endian-subreg.c: New.
>>
>> --
>
>


Re: [og7] vector_length extension part 5: libgomp and tests

2018-03-16 Thread Thomas Schwinge
Hi!

On Fri, 2 Mar 2018 12:47:23 -0800, Cesar Philippidis  
wrote:
> The attached patch is the last one in the vector length extension
> series. It consists of some tweaks to the libgomp nvptx plugin to
> accommodate larger vectors along with two test cases.
> 
> I only added two test cases because there's really not much interesting
> going on with longer vector lengths. We should eventually add more tests
> cases to handle situations where the nvptx BE falls back to using a
> shorter vector length. But right now GCC just makes those changes
> silently. There is precedent for the nvptx BE to emit a warning when
> vector length != 32, but that might be too verbose. On one hand, it
> could be argued that the compiler should error if it cannot satisfy the
> user's request. On the other hand, falling back to a smaller vector
> length ensures correctness.
> 
> Thomas, do you have any thoughts on the warnings/errors or there lack of?

Yeah, warning when "vector_length([bigger than 32])" is reduced to
"vector_length(32)" is probably too verbose/not useful.  But, it'd be
useful to have in "-fopt-info-omp"?


Grüße
 Thomas


Re: RFA (make_dispatcher_decl): PATCH for c++/83911, ICE with multiversioned constructor

2018-03-16 Thread Jason Merrill
On Thu, Mar 15, 2018 at 4:50 AM, Richard Biener
 wrote:
> On Wed, Mar 14, 2018 at 8:57 PM, Jason Merrill  wrote:
>> Ping
>>
>> On Fri, Mar 2, 2018 at 1:23 PM, Jason Merrill  wrote:
>>> As I mentioned in the PR, the problem here is that we're replacing a
>>> constructor with a dispatcher function which doesn't look much like a
>>> constructor.  This patch adjusts make_dispatcher_decl to make it look
>>> more like the functions it dispatches to, but other things are certain
>>> to break for similar reasons down the road.  A proper solution should
>>> be more transparent, like thunks.
>>>
>>> Tested x86_64-pc-linux-gnu.  Does this seem worth applying to fix the
>>> regression?
>
> The patch looks reasonable to me, you probably know best whether
> the cp/ parts are risky or not ;)
>
> So - OK from my POV.
>
> And yes, thunks may be a better representation for the dispatcher.

It occurred to me that I could handle this more locally by deferring
the function substitution until genericization time, so this is what
I'm checking in:
commit 05dda93e56e02859c65f93bd541dc7793bc7305c
Author: Jason Merrill 
Date:   Fri Feb 16 16:53:47 2018 -0500

PR c++/83911 - ICE with multiversioned constructor.

* cp-gimplify.c (cp_genericize_r): Replace versioned function with
dispatchere here.
* call.c (build_over_call): Not here.
PR c++/83911 - ICE with multiversioned constructor.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 45c22aaa312..67438ff2e94 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8204,23 +8204,6 @@ build_over_call (struct z_candidate *cand, int flags, tsubst_flags_t complain)
 	}
 }
 
-  /* For calls to a multi-versioned function, overload resolution
- returns the function with the highest target priority, that is,
- the version that will checked for dispatching first.  If this
- version is inlinable, a direct call to this version can be made
- otherwise the call should go through the dispatcher.  */
-
-  if (DECL_FUNCTION_VERSIONED (fn)
-  && (current_function_decl == NULL
-	  || !targetm.target_option.can_inline_p (current_function_decl, fn)))
-{
-  fn = get_function_version_dispatcher (fn);
-  if (fn == NULL)
-	return NULL;
-  if (!already_used)
-	mark_versions_used (fn);
-}
-
   if (!already_used
   && !mark_used (fn, complain))
 return error_mark_node;
diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index 0ddd435454c..653d1dcee26 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -1513,6 +1513,29 @@ cp_genericize_r (tree *stmt_p, int *walk_subtrees, void *data)
 		   == REFERENCE_TYPE))
 	*walk_subtrees = 0;
 	}
+  /* Fall through.  */
+case AGGR_INIT_EXPR:
+  /* For calls to a multi-versioned function, overload resolution
+	 returns the function with the highest target priority, that is,
+	 the version that will checked for dispatching first.  If this
+	 version is inlinable, a direct call to this version can be made
+	 otherwise the call should go through the dispatcher.  */
+  {
+	tree fn = cp_get_callee_fndecl (stmt);
+	if (fn && DECL_FUNCTION_VERSIONED (fn)
+	&& (current_function_decl == NULL
+		|| !targetm.target_option.can_inline_p (current_function_decl,
+			fn)))
+	  if (tree dis = get_function_version_dispatcher (fn))
+	{
+	  mark_versions_used (dis);
+	  dis = build_address (dis);
+	  if (TREE_CODE (stmt) == CALL_EXPR)
+		CALL_EXPR_FN (stmt) = dis;
+	  else
+		AGGR_INIT_EXPR_FN (stmt) = dis;
+	}
+  }
   break;
 
 default:
diff --git a/gcc/testsuite/g++.dg/ext/mv27.C b/gcc/testsuite/g++.dg/ext/mv27.C
new file mode 100644
index 000..443a54be765
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/mv27.C
@@ -0,0 +1,18 @@
+// PR c++/83911
+// { dg-do compile { target i?86-*-* x86_64-*-* } }
+// { dg-require-ifunc "" }
+
+class SimdFloat
+{
+public:
+__attribute__ ((target ("default")))
+SimdFloat(float x) {}
+
+__attribute__ ((target ("avx2")))
+SimdFloat(float x) {}
+};
+
+SimdFloat foo()
+{
+return 1;
+}


Re: [C++ PATCH] Fix ICE in reshape_init_class (PR c++/84874)

2018-03-16 Thread Jakub Jelinek
On Fri, Mar 16, 2018 at 12:29:58AM +0100, Jakub Jelinek wrote:
> As the testcase shows, even when we've already reshaped the initializer, if
> it uses designated initializers and skips using those over others, we can
> have field != d->cur->index.  The following patch handles that case.

Just to verify we don't ICE even with anonymous aggregates, I've added
another testcase, tested on x86_64-linux, committed to trunk as obvious.

2018-03-16  Jakub Jelinek  

PR c++/84874
* g++.dg/cpp2a/desig8.C: New test.

--- gcc/testsuite/g++.dg/cpp2a/desig8.C.jj  2018-03-16 09:42:08.585005338 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/desig8.C 2018-03-16 09:41:15.100019444 +0100
@@ -0,0 +1,31 @@
+// PR c++/84874
+// { dg-do run { target c++17 } }
+// { dg-options "" }
+
+struct A { int a; struct { int b; }; };
+struct B { A d; };
+
+void
+foo (B *x)
+{
+  *x = { .d = { .b = 5 } };
+}
+
+void
+bar (A *x)
+{
+  *x = { .b = 6 };
+}
+
+int
+main ()
+{
+  B b = { { 2, 3 } };
+  foo ();
+  if (b.d.a != 0 || b.d.b != 5)
+__builtin_abort ();
+  b.d.a = 8;
+  bar ();
+  if (b.d.a != 0 || b.d.b != 6)
+__builtin_abort ();
+}


Jakub


[testsuite] Require label_values in builtin-unreachable-6.c

2018-03-16 Thread Tom de Vries
[ was: Re: [PATCH][committed][PR tree-optimization/82123] 02/06 Perform 
EVRP analysis in sprintf warning pass ]


On 02/20/2018 07:52 PM, Jeff Law wrote:

This twiddles one test -- adding the calls into the analyzer from the
sprintf pass causes us to record a range for an object that didn't have
one before and compromises the test.  I just turn off VRP  which is
sufficient to obscure things so that we don't remove the
__builtin_unreachable.




diff --git a/gcc/testsuite/gcc.dg/builtin-unreachable-6.c 
b/gcc/testsuite/gcc.dg/builtin-unreachable-6.c
index 1915dd1..b0504be 100644
--- a/gcc/testsuite/gcc.dg/builtin-unreachable-6.c
+++ b/gcc/testsuite/gcc.dg/builtin-unreachable-6.c
@@ -1,5 +1,5 @@
  /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-fab1 -fno-tree-dominator-opts" } */
+/* { dg-options "-O2 -fdump-tree-fab1 -fno-tree-dominator-opts -fno-tree-vrp" 
} */
  
  void

  foo (int b, int c)



Preventing vrp triggered "sorry, unimplemented: target cannot support 
label values" on nvptx.


Fixed by requiring the effective target label_values.

Thanks,
- Tom
[testsuite] Require label_values in builtin-unreachable-6.c

2018-03-16  Tom de Vries  

	* gcc.dg/builtin-unreachable-6.c: Require effective target label_values.

---
 gcc/testsuite/gcc.dg/builtin-unreachable-6.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/builtin-unreachable-6.c b/gcc/testsuite/gcc.dg/builtin-unreachable-6.c
index b0504be..4c3b9bb 100644
--- a/gcc/testsuite/gcc.dg/builtin-unreachable-6.c
+++ b/gcc/testsuite/gcc.dg/builtin-unreachable-6.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fdump-tree-fab1 -fno-tree-dominator-opts -fno-tree-vrp" } */
+/* { dg-require-effective-target label_values } */
 
 void
 foo (int b, int c)


Re: [PATCH] Fix PR84512

2018-03-16 Thread Richard Biener
On Fri, 16 Mar 2018, Tom de Vries wrote:

> On 02/27/2018 01:42 PM, Richard Biener wrote:
> > Index: gcc/testsuite/gcc.dg/tree-ssa/pr84512.c
> > ===
> > --- gcc/testsuite/gcc.dg/tree-ssa/pr84512.c (nonexistent)
> > +++ gcc/testsuite/gcc.dg/tree-ssa/pr84512.c (working copy)
> > @@ -0,0 +1,15 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O3 -fdump-tree-optimized" } */
> > +
> > +int foo()
> > +{
> > +  int a[10];
> > +  for(int i = 0; i < 10; ++i)
> > +a[i] = i*i;
> > +  int res = 0;
> > +  for(int i = 0; i < 10; ++i)
> > +res += a[i];
> > +  return res;
> > +}
> > +
> > +/* { dg-final { scan-tree-dump "return 285;" "optimized" } } */
> 
> This fails for nvptx, because it doesn't have the required vector operations.
> To fix the fail, I've added requiring effective target vect_int_mult.

On targets that do not vectorize you should see the scalar loops unrolled
instead.  Or do you have only one loop vectorized?  That's precisely
what the PR was about...  which means it isn't fixed for nvptx :/

Richard.

> Thanks,
> - Tom
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)


Re: [PATCH] Fix PR84873

2018-03-16 Thread Richard Biener
On Fri, 16 Mar 2018, Richard Biener wrote:

> On Thu, 15 Mar 2018, Bin.Cheng wrote:
> 
> > On Thu, Mar 15, 2018 at 1:07 PM, Jakub Jelinek  wrote:
> > > On Thu, Mar 15, 2018 at 01:56:16PM +0100, Richard Biener wrote:
> > >> The following fixes the C familiy gimplification langhook to not
> > >> introduce tree sharing which isn't valid during gimplification.
> > >> For the specific case the tree sharing is introduced by
> > >> fold_binary_op_with_cond and is reached via convert () eventually
> > >> folding something.  I've kept folding constants here but for the
> > >> rest defer folding to GIMPLE (the gimplifier already folds most
> > >> generated stmts).
> > >>
> > >> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk and
> > >> branches?
> > Hi,
> > FYI, this causes below failure.
> > 
> > Failures:
> > gcc.target/aarch64/var_shift_mask_1.c
> 
> Ok, these look like narrowing only done via convert () and neither
> fold nor gimple folding.
> 
> An alternative slightly more expensive patch is the following which
> I'm now testing on x86_64-unknown-linux-gnu, the above testcase
> is fixed with it (verified with a cross).

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok?

Thanks,
Richard.

> Richard.
> 
> 2018-03-16  Richard Biener  
> 
> PR c/84873
> * c-gimplify.c (c_gimplify_expr): Revert previous change.  Instead
> unshare the possibly folded expression.
> 
> Index: gcc/c-family/c-gimplify.c
> ===
> --- gcc/c-family/c-gimplify.c   (revision 258584)
> +++ gcc/c-family/c-gimplify.c   (working copy)
> @@ -245,15 +245,9 @@ c_gimplify_expr (tree *expr_p, gimple_se
> unsigned_type_node)
> && !types_compatible_p (TYPE_MAIN_VARIANT (TREE_TYPE 
> (*op1_p)),
> integer_type_node))
> - {
> -   /* ???  Do not use convert () here or fold arbitrary trees
> -  since folding can introduce tree sharing which is not
> -  allowed during gimplification.  */
> -   if (TREE_CODE (*op1_p) == INTEGER_CST)
> - *op1_p = fold_convert (unsigned_type_node, *op1_p);
> -   else
> - *op1_p = build1 (NOP_EXPR, unsigned_type_node, *op1_p);
> - }
> + /* Make sure to unshare the result, tree sharing is invalid
> +during gimplification.  */
> + *op1_p = unshare_expr (convert (unsigned_type_node, *op1_p));
> break;
>}
>  
> 
> 
> 
> > Bisected to:
> > 
> > 
> > commit 676d61f64d05af5833ddd471cc99229cedbd59b4
> > Author: rguenth 
> > Date:   Thu Mar 15 13:10:24 2018 +
> > 
> > 2018-03-15  Richard Biener  
> > 
> >  PR c/84873
> >  * c-gimplify.c (c_gimplify_expr): Do not fold expressions.
> > 
> >  * c-c++-common/pr84873.c: New testcase.
> > 
> > 
> > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@258556
> > 138bc75d-0d04-0410-961f-82ee72b054a4
> > 
> > I will get more information about the failure.
> > 
> > Thanks,
> > bin
> > >>
> > >> Thanks,
> > >> Richard.
> > >>
> > >> 2018-03-15  Richard Biener  
> > >>
> > >>   PR c/84873
> > >>   * c-gimplify.c (c_gimplify_expr): Do not fold expressions.
> > >>
> > >>   * c-c++-common/pr84873.c: New testcase.
> > >
> > > Ok, thanks.
> > >
> > > Jakub
> > 
> > 
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)


Re: [PATCH AArch64]Fix test failure for pr84682-2.c

2018-03-16 Thread Kyrill Tkachov

Hi Bin,

On 16/03/18 11:42, Bin Cheng wrote:

Hi,
This simple patch fixes test case failure for pr84682-2.c by returning
false on wrong mode rtx in aarch64_classify_address, rather than assert.

Bootstrap and test on aarch64.  Is it OK?

Thanks,
bin

2018-03-16  Bin Cheng  

* config/aarch64/aarch64.c (aarch64_classify_address): Return false
on wrong mode rtx, rather than assert.


This looks ok to me in light of 
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00633.html
This function is used to validate inline asm operands too, not just 
internally-generated addresses.
Therefore all kinds of garbage must be rejected gracefully rather than ICEing.

You'll need an approval from an AArch64 maintainer though.

Thanks,
Kyrill


Re: [PATCH] Fix PR84512

2018-03-16 Thread Tom de Vries

On 02/27/2018 01:42 PM, Richard Biener wrote:

Index: gcc/testsuite/gcc.dg/tree-ssa/pr84512.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr84512.c (nonexistent)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr84512.c (working copy)
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-tree-optimized" } */
+
+int foo()
+{
+  int a[10];
+  for(int i = 0; i < 10; ++i)
+a[i] = i*i;
+  int res = 0;
+  for(int i = 0; i < 10; ++i)
+res += a[i];
+  return res;
+}
+
+/* { dg-final { scan-tree-dump "return 285;" "optimized" } } */


This fails for nvptx, because it doesn't have the required vector 
operations. To fix the fail, I've added requiring effective target 
vect_int_mult.


Thanks,
- Tom
[testsuite] Require vect_int_mult in pr84512.c

2018-03-16  Tom de Vries  

	* gcc.dg/tree-ssa/pr84512.c: Require effective target vect_int_mult.

---
 gcc/testsuite/gcc.dg/tree-ssa/pr84512.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr84512.c b/gcc/testsuite/gcc.dg/tree-ssa/pr84512.c
index 288fa5d..41b6c06 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr84512.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr84512.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O3 -fdump-tree-optimized" } */
+/* { dg-require-effective-target vect_int_mult } */
 
 int foo()
 {


[PATCH AArch64]Fix test failure for pr84682-2.c

2018-03-16 Thread Bin Cheng
Hi,
This simple patch fixes test case failure for pr84682-2.c by returning
false on wrong mode rtx in aarch64_classify_address, rather than assert.

Bootstrap and test on aarch64.  Is it OK?

Thanks,
bin

2018-03-16  Bin Cheng  

* config/aarch64/aarch64.c (aarch64_classify_address): Return false
on wrong mode rtx, rather than assert.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 07c55b1..8790902 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5674,8 +5674,10 @@ aarch64_classify_address (struct aarch64_address_info 
*info,
   && (code != POST_INC && code != REG))
 return false;
 
-  gcc_checking_assert (GET_MODE (x) == VOIDmode
-  || SCALAR_INT_MODE_P (GET_MODE (x)));
+  /* Wrong mode for an address expr.  */
+  if (GET_MODE (x) != VOIDmode
+  && ! SCALAR_INT_MODE_P (GET_MODE (x)))
+return false;
 
   switch (code)
 {


Re: [committed] Fix ICE for missing header fix-it hints with overlarge #line directives (PR c/84852)

2018-03-16 Thread Bin.Cheng
On Thu, Mar 15, 2018 at 1:32 AM, Paul Hua  wrote:
> Hi:
>
> The fixits-pr84852-1.c fails on mips64el target.
Hi,
It fails on aarch64/arm bare-metal cross toolchains with different message like:
ERROR: gcc.dg/fixits-pr84852-1.c: bad option "-812156810": must be
-exact, -glob, -regexp, or -- for " dg-warning 15 "incompatible
implicit declaration of built-in function 'strlen'" "" { target *-*-*
} -812156810 "

Thanks,
bin
>
> FAIL: gcc.dg/fixits-pr84852-1.c (test for excess errors)
> FAIL: gcc.dg/fixits-pr84852-1.c dg-regexp 25 not found:
> ".*fixits-pr84852.c:-812156810:25:"
>
> see this patch:
>
> diff --git a/gcc/testsuite/gcc.dg/fixits-pr84852-1.c
> b/gcc/testsuite/gcc.dg/fixits-pr84852-1.c
> index ed88434..98087ab 100644
> --- a/gcc/testsuite/gcc.dg/fixits-pr84852-1.c
> +++ b/gcc/testsuite/gcc.dg/fixits-pr84852-1.c
> @@ -22,4 +22,4 @@ int foo (void) { return strlen(""); }
>  #endif
>
>  /* We need this, to consume a stray line marker for the bogus line.  */
> -/* { dg-regexp ".*fixits-pr84852.c:-812156810:25:" } */
> +/* { dg-regexp ".*fixits-pr84852-1.c:-812156810:25:" } */
>
> Thanks.
>
> On Wed, Mar 14, 2018 at 10:10 PM, David Malcolm  wrote:
>> PR c/84852 reports an ICE inside diagnostic_show_locus when printing
>> a diagnostic for a source file with a #line >= 2^31:
>>
>>   #line 77
>>   int foo (void) { return strlen(""); }
>>
>> where we're attempting to print a fix-it hint at the top of the file
>> and underline the "strlen" (two "line spans").
>>
>> The
>>   #line 77
>> won't fix within the 32-bit linenum_type, and is truncated from
>>   0x1cf977871
>> to
>>0xcf977871
>> i.e. 3482810481 in decimal.
>>
>> Such a #line is reported by -pedantic and -pedantic-errors, but we
>> shouldn't ICE.
>>
>> The ICE is an assertion failure within layout::calculate_line_spans,
>> where the line spans have not been properly sorted.
>>
>> The layout_ranges are stored as int, rather than linenum_type,
>> giving line -812156815 for the error, and line 1 for the fix-it hint.
>>
>> However, line_span uses linenum_type rather than int.
>>
>> line_span::comparator compares these values as int, and hence
>> decides that (linenum_type)3482810481 aka (int)-812156815 is less
>> than line 1.
>>
>> This leads to this assertion failing in layout::calculate_line_spans:
>>
>> 1105  gcc_assert (next->m_first_line >= current->m_first_line);
>>
>> since it isn't the case that 1 >= 3482810481.
>>
>> The underlying problem is the mix of types for storing line numbers:
>> in parts of libcpp and diagnostic-show-locus.c we use linenum_type;
>> in other places (including libcpp's expanded_location) we use int.
>>
>> I looked at using linenum_type throughout, but doing so turned into
>> a large patch, so this patch fixes the ICE in a less invasive way
>> by merely using linenum_type more consistently just within
>> diagnostic-show-locus.c, and fixing line_span::comparator to properly
>> handle line numbers (and line number differences) >= 2^31, by using
>> a new helper function for linenum_type differences, computing the
>> difference using long long, and using the sign of the difference
>> (as the difference might not fit in the "int" return type imposed
>> by qsort).
>>
>> (The new testcases assume the host's "unsigned int" is 32 bits; is
>> there anything we support where that isn't the case?)
>>
>> I can self-approve the libcpp, diagnostic-show-locus.c and input.c
>> changes.
>>
>> As part of the selftests, I needed to add ASSERT_GT and ASSERT_LT
>> to selftest.h; I'm treating those parts of the patch as "obvious".
>>
>> Successfully bootstrapped and regression-tested on x86_64-pc-linux-gnu;
>> adds 14 PASS results to gcc.sum.
>>
>> Committed to trunk as r258526.
>>
>> gcc/ChangeLog:
>> PR c/84852
>> * diagnostic-show-locus.c (class layout_point): Convert m_line
>> from int to linenum_type.
>> (line_span::comparator): Use linenum "compare" function when
>> comparing line numbers.
>> (test_line_span): New function.
>> (layout_range::contains_point): Convert param "row" from int to
>> linenum_type.
>> (layout_range::intersects_line_p): Likewise.
>> (layout::will_show_line_p): Likewise.
>> (layout::print_source_line): Likewise.
>> (layout::should_print_annotation_line_p): Likewise.
>> (layout::print_annotation_line): Likewise.
>> (layout::print_leading_fixits): Likewise.
>> (layout::annotation_line_showed_range_p): Likewise.
>> (struct line_corrections): Likewise for field m_row.
>> (line_corrections::line_corrections): Likewise for param "row".
>> (layout::print_trailing_fixits): Likewise.
>> (layout::get_state_at_point): Likewise.
>> (layout::get_x_bound_for_row): Likewise.
>> (layout::print_line): Likewise.
>> (diagnostic_show_locus): Likewise for locals "last_line" and
>> "row".

Re: [PATCH][committed][Fortran] Add a few new tests for -fdec-static and -fdec-structure

2018-03-16 Thread Jakub Jelinek
On Thu, Mar 15, 2018 at 11:09:13PM -0600, Jeff Law wrote:
> Tested on x86_64-linux-gnu.  Installing on the trunk.

ENOPATCH.

Jakub


Re: [PATCH][committed][Fortran] Add a few new tests for -fdec-static and -fdec-structure

2018-03-16 Thread Jakub Jelinek
On Fri, Mar 16, 2018 at 09:01:30AM +0100, Jakub Jelinek wrote:
> On Thu, Mar 15, 2018 at 11:09:13PM -0600, Jeff Law wrote:
> > Tested on x86_64-linux-gnu.  Installing on the trunk.
> 
> ENOPATCH.

Here it is from svn:

03-16-2018  Mark Doffman  
Jim MacArthur  

* gfortran.dg/automatic_1.f90: New test.
* gfortran.dg/automatic_repeat.f90: New test
* gfortran.dg/automatic_save.f90: New test.
* gfortran.dg/vax_structure.f90: New test.

--- testsuite/gfortran.dg/automatic_repeat.f90  (nonexistent)
+++ testsuite/gfortran.dg/automatic_repeat.f90  (revision 258584)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! { dg-options "-fdec-static" }
+! An AUTOMATIC statement cannot duplicated
+FUNCTION X()
+REAL, AUTOMATIC, AUTOMATIC :: Y ! { dg-error "Duplicate AUTOMATIC attribute" }
+y = 1
+END FUNCTION X
+END
--- testsuite/gfortran.dg/automatic_save.f90(nonexistent)
+++ testsuite/gfortran.dg/automatic_save.f90(revision 258584)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! { dg-options "-fdec-static" }
+! An AUTOMATIC statement cannot be used with SAVE
+FUNCTION X()
+REAL, SAVE, AUTOMATIC :: Y ! { dg-error "AUTOMATIC attribute conflicts with 
SAVE attribute" }
+y = 1
+END FUNCTION X
+END
--- testsuite/gfortran.dg/automatic_1.f90   (nonexistent)
+++ testsuite/gfortran.dg/automatic_1.f90   (revision 258584)
@@ -0,0 +1,31 @@
+! { dg-do run }
+! { dg-options "-O2 -fdec-static -fno-automatic" }
+  subroutine foo (b)
+logical b
+integer i, j
+character*24 s
+automatic i
+if (b) then
+  i = 26
+  j = 131
+  s = 'This is a test string'
+else
+  if (i .eq. 26 .or. j .ne. 131) call abort
+  if (s .ne. 'This is a test string') call abort
+end if
+  end subroutine foo
+  subroutine bar (s)
+character*42 s
+if (s .ne. '0123456789012345678901234567890123456') call abort
+call foo (.false.)
+  end subroutine bar
+  subroutine baz
+character*42 s
+! Just clobber stack a little bit.
+s = '0123456789012345678901234567890123456'
+call bar (s)
+  end subroutine baz
+  call foo (.true.)
+  call baz
+  call foo (.false.)
+  end
--- testsuite/gfortran.dg/vax_structure_1.f90   (nonexistent)
+++ testsuite/gfortran.dg/vax_structure_1.f90   (revision 258584)
@@ -0,0 +1,27 @@
+! { dg-do compile }
+! { dg-options "-fdec-structure" }
+! Tests the VAX STRUCTURE and RECORD statements.
+! These are syntactic sugar for TYPE statements.
+
+  program vax_structure_1
+  structure /stocklevel/
+ integer*2   A
+ integer*4   B
+ integer*4   CS(0:15)
+ byteD(0:15)
+  end structure
+
+  record /stocklevel/ rec1, recs(100)
+  integer x
+  integer*2 y
+
+  rec1.A = 100
+  recs(100).CS(10)=1
+  x = 150
+  y = 150
+
+  print *, rec1.B.eq.100
+  print *, rec1.A.eq.x ! {dg-error "are INTEGER(2)/INTEGER(4)"}
+  print *, rec1.A.eq.y
+  print *, recs(100).CS(10)
+  end program

Jakub


[C++ PATCH] Fix ICE in reshape_init_class (PR c++/84874)

2018-03-16 Thread Jakub Jelinek
Hi!

As the testcase shows, even when we've already reshaped the initializer, if
it uses designated initializers and skips using those over others, we can
have field != d->cur->index.  The following patch handles that case.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-03-15  Jakub Jelinek  

PR c++/84874
* decl.c (reshape_init_class): Don't assert d->cur->index == field
if d->cur->index is a FIELD_DECL, instead set field to d->cur->index.

* g++.dg/cpp2a/desig7.C: New test.

--- gcc/cp/decl.c.jj2018-03-15 18:44:21.662300888 +0100
+++ gcc/cp/decl.c   2018-03-15 19:55:54.831039431 +0100
@@ -5885,8 +5885,17 @@ reshape_init_class (tree type, reshape_i
return error_mark_node;
 
  if (TREE_CODE (d->cur->index) == FIELD_DECL)
-   /* We already reshaped this.  */
-   gcc_assert (d->cur->index == field);
+   {
+ /* We already reshaped this.  */
+ if (field != d->cur->index)
+   {
+ tree id = DECL_NAME (d->cur->index);
+ gcc_assert (id);
+ gcc_checking_assert (d->cur->index
+  == get_class_binding (type, id, false));
+ field = d->cur->index;
+   }
+   }
  else if (TREE_CODE (d->cur->index) == IDENTIFIER_NODE)
field = get_class_binding (type, d->cur->index, false);
  else
--- gcc/testsuite/g++.dg/cpp2a/desig7.C.jj  2018-03-15 19:54:47.060017400 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/desig7.C 2018-03-15 19:54:47.060017400 +0100
@@ -0,0 +1,31 @@
+// PR c++/84874
+// { dg-do run { target c++11 } }
+// { dg-options "" }
+
+struct A { int a, b; };
+struct B { A d; };
+
+void
+foo (B *x)
+{
+  *x = { .d = { .b = 5 } };
+}
+
+void
+bar (A *x)
+{
+  *x = { .b = 6 };
+}
+
+int
+main ()
+{
+  B b = { { 2, 3 } };
+  foo ();
+  if (b.d.a != 0 || b.d.b != 5)
+__builtin_abort ();
+  b.d.a = 8;
+  bar ();
+  if (b.d.a != 0 || b.d.b != 6)
+__builtin_abort ();
+}

Jakub


Re: libgo patch committed: Force LANG=C when looking for compiler version

2018-03-16 Thread Andreas Schwab
On Mär 15 2018, Ian Lance Taylor  wrote:

> On Thu, Mar 15, 2018 at 11:24 AM, Andreas Schwab  
> wrote:
>> On Mär 15 2018, Ian Lance Taylor  wrote:
>>
>>> On Thu, Mar 15, 2018 at 10:10 AM, Andreas Schwab  
>>> wrote:
 On Mär 15 2018, Ian Lance Taylor  wrote:

> + env = append(env, "LANG=C")

 You should use LC_ALL=C instead.
>>>
>>> Does it really matter?  Do you think that this approach won't work?
>>
>> LANG has lowest priority.
>
> The code strips out all the other possibly relevant environment variables.

That sets a bad example.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: [PATCH] Fix reassoc with -frounding-math or IBM long double (PR tree-optimization/84841)

2018-03-16 Thread Richard Biener
On Thu, 15 Mar 2018, Jakub Jelinek wrote:

> Hi!
> 
> If any argument of * is negated, reassoc adds an artificial -1.0 multiplier.
> The code then relies on folding at least all those artificial multipliers
> through const_binop.  That function can fail if the result is inexact for
> -frounding-math or for composite modes, and we only try to recursively fold
> the last constant with previous one.
> 
> The following patch fixes it by sorting the constants that never cause
> inexact results (-1.0 and 1.0) last, so we fold at least all those together
> and at least with one other constant.  As I said in the PR, we could also
> try up to O(n^2) attempts folding each constant with each other if there
> were any failures in the folding, perhaps bound by some constant.
> 
> The comment above constant_type says we want to sort the integral constants
> last, but we actually among all constants sort them first, so the patch
> fixes that too.  As constant_type returns something (at least before this
> patch) only based on type, I fail to see when constants in the same ops
> vector could have different kinds.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Richard.

> 2018-03-15  Jakub Jelinek  
> 
>   PR tree-optimization/84841
>   * tree-ssa-reassoc.c (INTEGER_CONST_TYPE): Change to 1 << 4 from
>   1 << 3.
>   (FLOAT_ONE_CONST_TYPE): Define.
>   (constant_type): Return FLOAT_ONE_CONST_TYPE for -1.0 and 1.0.
>   (sort_by_operand_rank): Put entries with higher constant_type last
>   rather than first to match comments.
> 
>   * gcc.dg/pr84841.c: New test.
> 
> --- gcc/tree-ssa-reassoc.c.jj 2018-01-03 10:19:53.804533730 +0100
> +++ gcc/tree-ssa-reassoc.c2018-03-15 17:46:08.871748372 +0100
> @@ -470,7 +470,8 @@ get_rank (tree e)
>  
>  /* We want integer ones to end up last no matter what, since they are
> the ones we can do the most with.  */
> -#define INTEGER_CONST_TYPE 1 << 3
> +#define INTEGER_CONST_TYPE 1 << 4
> +#define FLOAT_ONE_CONST_TYPE 1 << 3
>  #define FLOAT_CONST_TYPE 1 << 2
>  #define OTHER_CONST_TYPE 1 << 1
>  
> @@ -482,7 +483,14 @@ constant_type (tree t)
>if (INTEGRAL_TYPE_P (TREE_TYPE (t)))
>  return INTEGER_CONST_TYPE;
>else if (SCALAR_FLOAT_TYPE_P (TREE_TYPE (t)))
> -return FLOAT_CONST_TYPE;
> +{
> +  /* Sort -1.0 and 1.0 constants last, while in some cases
> +  const_binop can't optimize some inexact operations, multiplication
> +  by -1.0 or 1.0 can be always merged with others.  */
> +  if (real_onep (t) || real_minus_onep (t))
> + return FLOAT_ONE_CONST_TYPE;
> +  return FLOAT_CONST_TYPE;
> +}
>else
>  return OTHER_CONST_TYPE;
>  }
> @@ -504,7 +512,7 @@ sort_by_operand_rank (const void *pa, co
>if (oea->rank == 0)
>  {
>if (constant_type (oeb->op) != constant_type (oea->op))
> - return constant_type (oeb->op) - constant_type (oea->op);
> + return constant_type (oea->op) - constant_type (oeb->op);
>else
>   /* To make sorting result stable, we use unique IDs to determine
>  order.  */
> --- gcc/testsuite/gcc.dg/pr84841.c.jj 2018-03-15 17:46:40.142765079 +0100
> +++ gcc/testsuite/gcc.dg/pr84841.c2018-03-15 17:25:05.032150810 +0100
> @@ -0,0 +1,9 @@
> +/* PR tree-optimization/84841 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fassociative-math -frounding-math -fno-signed-zeros 
> -fno-trapping-math -fno-tree-forwprop" } */
> +
> +double
> +foo (double x)
> +{
> +  return -x * 0.1 * 0.1;
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)


Re: [PATCH] Fix PR84873

2018-03-16 Thread Richard Biener
On Thu, 15 Mar 2018, Bin.Cheng wrote:

> On Thu, Mar 15, 2018 at 1:07 PM, Jakub Jelinek  wrote:
> > On Thu, Mar 15, 2018 at 01:56:16PM +0100, Richard Biener wrote:
> >> The following fixes the C familiy gimplification langhook to not
> >> introduce tree sharing which isn't valid during gimplification.
> >> For the specific case the tree sharing is introduced by
> >> fold_binary_op_with_cond and is reached via convert () eventually
> >> folding something.  I've kept folding constants here but for the
> >> rest defer folding to GIMPLE (the gimplifier already folds most
> >> generated stmts).
> >>
> >> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk and
> >> branches?
> Hi,
> FYI, this causes below failure.
> 
> Failures:
> gcc.target/aarch64/var_shift_mask_1.c

Ok, these look like narrowing only done via convert () and neither
fold nor gimple folding.

An alternative slightly more expensive patch is the following which
I'm now testing on x86_64-unknown-linux-gnu, the above testcase
is fixed with it (verified with a cross).

Richard.

2018-03-16  Richard Biener  

PR c/84873
* c-gimplify.c (c_gimplify_expr): Revert previous change.  Instead
unshare the possibly folded expression.

Index: gcc/c-family/c-gimplify.c
===
--- gcc/c-family/c-gimplify.c   (revision 258584)
+++ gcc/c-family/c-gimplify.c   (working copy)
@@ -245,15 +245,9 @@ c_gimplify_expr (tree *expr_p, gimple_se
unsigned_type_node)
&& !types_compatible_p (TYPE_MAIN_VARIANT (TREE_TYPE 
(*op1_p)),
integer_type_node))
- {
-   /* ???  Do not use convert () here or fold arbitrary trees
-  since folding can introduce tree sharing which is not
-  allowed during gimplification.  */
-   if (TREE_CODE (*op1_p) == INTEGER_CST)
- *op1_p = fold_convert (unsigned_type_node, *op1_p);
-   else
- *op1_p = build1 (NOP_EXPR, unsigned_type_node, *op1_p);
- }
+ /* Make sure to unshare the result, tree sharing is invalid
+during gimplification.  */
+ *op1_p = unshare_expr (convert (unsigned_type_node, *op1_p));
break;
   }
 



> Bisected to:
> 
> 
> commit 676d61f64d05af5833ddd471cc99229cedbd59b4
> Author: rguenth 
> Date:   Thu Mar 15 13:10:24 2018 +
> 
> 2018-03-15  Richard Biener  
> 
>  PR c/84873
>  * c-gimplify.c (c_gimplify_expr): Do not fold expressions.
> 
>  * c-c++-common/pr84873.c: New testcase.
> 
> 
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@258556
> 138bc75d-0d04-0410-961f-82ee72b054a4
> 
> I will get more information about the failure.
> 
> Thanks,
> bin
> >>
> >> Thanks,
> >> Richard.
> >>
> >> 2018-03-15  Richard Biener  
> >>
> >>   PR c/84873
> >>   * c-gimplify.c (c_gimplify_expr): Do not fold expressions.
> >>
> >>   * c-c++-common/pr84873.c: New testcase.
> >
> > Ok, thanks.
> >
> > Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)


Re: [PATCH] PR gcc/68256 Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.

2018-03-16 Thread vladimir . mezentsev

On 03/15/2018 07:07 AM, Bin.Cheng wrote:
> On Fri, Feb 16, 2018 at 5:18 PM,   wrote:
>> From: Vladimir Mezentsev 
>>
>> Ramana Radhakrishnan made a workaround in gcc/config/aarch64/aarch64.c to 
>> resolve
>> bootstrap comparison failure (2015-11-10, commit 
>> bc443a71dafa2e707bae4b2fa74f83b05dea37ab).
>> The real bug is in gcc/varasm.c.
>> hash_section() returns an unstable value.
>> As result, two blocks are created in get_block_for_section() for one unnamed 
>> section.
>> A list of objects in these blocks depends on the -gtoggle option.
>> I removed Ramana's workaround in gcc/config/aarch64/aarch64.c and  
>> I fixed hash_section() in gcc/varasm.c
>>
>> Bootstrapped on aarch64-unknown-linux-gnu including (c,c++ and go).
>> Testing finished ok.
> Hi Vladimir,
> Thanks for fixing the long standing issue, but this change causes below 
> failure,
> could you have a look?  Thanks
I did not see this failure.
I cannot tell why.
I use one CFARM machine (gcc116) and when my fix was approved I clean up
my directories
on this machine (including binaries and log files).

ramana.radhakrish...@arm.com implemented (2015-11-06, commit
cd4fcdb8ff16ec2dad56f9e736ac4552f8f52001)
a new feature ('Switch constant pools to separate rodata sections').
An additional fix is needed for this feature.

The test below demonstrates problem:
% cat t.c
extern void abort(void);
typedef int vtype;
static vtype Wv12 __attribute__((weakref ("wv12")));
extern vtype wv12 __attribute__((weak));

#define chk(p) do { if (!p) abort (); } while (0)

int main () {
  chk (!);
  chk (!);
  return (0);
}

% gcc  t.c
/tmp/cciZgRxK.o:(.rodata+0x0): undefined reference to `wv12'
/tmp/cciZgRxK.o:(.rodata+0x8): undefined reference to `wv12'

% gcc  t.c -S
% cat t.s

    .size   main, .-main
*    .weakref    Wv12,wv12   *<<   Not here. This should be
after definitions of Wv12 and wv12.
Wv12    .section    .rodata
    .align  3
.LC0:
    .xword  Wv12
    .align  3
.LC1:
    .xword  wv12


I can file a new PR and fix it by Tuesday/Wednesday
or we can  temporary restore Ramana's workaround in 
aarch64_use_blocks_for_constant_p:
% git diff
gcc/config/aarch64/aarch64.c
   

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 4b5183b..222ea33 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -7735,7 +7735,11 @@ aarch64_use_blocks_for_constant_p (machine_mode,
const_rtx)
 {
   /* We can't use blocks for constants when we're using a per-function
  constant pool.  */
-  return !aarch64_can_use_per_function_literal_pools_p ();
+  /* Fixme::
+ return !aarch64_can_use_per_function_literal_pools_p ();
+ This return statement breaks gcc.dg/attr-weakref-1.c test.
+ For now we workaround this by returning false here.  */
+  return false;
 }
 
 /* Select appropriate section for constants depending


-Vladimir

>
> Failures:
> gcc.dg/attr-weakref-1.c
>
> Bisected to:
>
>
> commit 536728c16d6a0173930ecfe370302baa471c299e
> Author: rguenth 
> Date:   Thu Mar 15 08:55:04 2018 +
>
> 2018-03-15  Vladimir Mezentsev  
>
> PR target/68256
> * varasm.c (hash_section): Return an unchangeble hash value
> * config/aarch64/aarch64.c (aarch64_use_blocks_for_constant_p):
> Return !aarch64_can_use_per_function_literal_pools_p ().
>
>
> Thanks,
> bin
>> ChangeLog:
>> 2018-02-15  Vladimir Mezentsev  
>>
>> PR gcc/68256
>> * varasm.c (hash_section): Return an unchangeble hash value
>> * config/aarch64/aarch64.c (aarch64_use_blocks_for_constant_p):
>> Return !aarch64_can_use_per_function_literal_pools_p ();
>> ---
>>  gcc/config/aarch64/aarch64.c | 8 +++-
>>  gcc/varasm.c | 2 +-
>>  2 files changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> index 174310c..a0a495d 100644
>> --- a/gcc/config/aarch64/aarch64.c
>> +++ b/gcc/config/aarch64/aarch64.c
>> @@ -7596,11 +7596,9 @@ aarch64_can_use_per_function_literal_pools_p (void)
>>  static bool
>>  aarch64_use_blocks_for_constant_p (machine_mode, const_rtx)
>>  {
>> -  /* Fixme:: In an ideal world this would work similar
>> - to the logic in aarch64_select_rtx_section but this
>> - breaks bootstrap in gcc go.  For now we workaround
>> - this by returning false here.  */
>> -  return false;
>> +  /* We can't use blocks for constants when we're using a per-function
>> + constant pool.  */
>> +  return !aarch64_can_use_per_function_literal_pools_p ();
>>  }
>>
>>  /* Select appropriate section for constants depending
>> diff --git a/gcc/varasm.c b/gcc/varasm.c
>> index b045efa..5aae5b4 100644
>> --- a/gcc/varasm.c
>> +++