Re: [PATCH] replace ICE with error for failed template deduction (PR 84355)

[Jason Merrill]

On Sun, Feb 18, 2018 at 11:39 PM, Jason Merrill  wrote:
> On Fri, Feb 16, 2018 at 4:33 PM, Martin Sebor  wrote:
>> On 02/16/2018 07:04 AM, Jason Merrill wrote:
>>>
>>> On Thu, Feb 15, 2018 at 6:36 PM, Martin Sebor  wrote:

 A failed template deduction in template member of a template
 triggers an ICE with -std=c++17 due to what seems like
 a missing handling of invalid input.  Replacing
 the gcc_unreachable() call that causes the ICE with a return
 statement indicating the deduction failure eliminates the ICE
 and restores sane diagnostics.
>>>
>>>
>>> Hmm, we really shouldn't have gotten there; that assert is checking
>>> that when we see a TEMPLATE_*_PARM node in the template signature, it
>>> corresponds to one of the actual parms of the template.  Sounds like
>>> something is going wrong in build_deduction_guide.
>>
>>
>> Are you suggesting that build_deduction_guide should fail somehow
>> (it's not expected to fail right now) or that the guide it creates
>> is wrong?
>
> The latter.  Maybe we're handling T wrong somehow?  We shouldn't be
> trying to deduce it.  In fact, we probably shouldn't be trying to
> deduce arguments for 'b' until we instantiate A.

Looks like the problem is that when we substitute into the
TEMPLATE_TYPE_PARM representing 'B' in the function, we don't touch
CLASS_PLACEHOLDER_TEMPLATE:

else if (tree pl = CLASS_PLACEHOLDER_TEMPLATE (t))
  {
if (DECL_TEMPLATE_TEMPLATE_PARM_P (pl))
  pl = tsubst (pl, args, complain, in_decl);
CLASS_PLACEHOLDER_TEMPLATE (r) = pl;
  }

This code is failing to replace A::B with A::B.

Jason

Re: C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692)

[Jason Merrill]

OK, thanks.

On Fri, Feb 23, 2018 at 9:29 AM, Marek Polacek  wrote:
> On Fri, Feb 16, 2018 at 04:10:20PM -0500, Jason Merrill wrote:
>> On Mon, Feb 5, 2018 at 1:45 PM, Jason Merrill  wrote:
>> > On Mon, Feb 5, 2018 at 8:37 AM, Marek Polacek  wrote:
>> >> On Fri, Feb 02, 2018 at 02:11:27PM -0500, Jason Merrill wrote:
>> >>> On Thu, Jan 25, 2018 at 4:16 PM, Marek Polacek  
>> >>> wrote:
>> >>> > This is a similar problem to 83116: we'd cached a constexpr call, but 
>> >>> > after a
>> >>> > store the result had become invalid, yet we used the wrong result 
>> >>> > again when
>> >>> > encountering the same call later.  This resulted in evaluating a 
>> >>> > THROW_EXPR
>> >>> > which doesn't work.  Details in
>> >>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692#c5
>> >>> >
>> >>> > The fix for 83116 didn't work here, because when evaluating the body 
>> >>> > of the
>> >>> > ctor via store_init_value -> cxx_constant_value we are in STRICT, so 
>> >>> > we do
>> >>> > cache.
>> >>>
>> >>> > It seems that we may no longer rely on the constexpr call table when we
>> >>> > do cxx_eval_store_expression, because that just rewrites *valp, i.e. 
>> >>> > the
>> >>> > value of an object.  Might be too big a hammer again, but I couldn't 
>> >>> > think
>> >>> > of how I could guard the caching of a constexpr call.
>> >>>
>> >>> > This doesn't manifest in C++14 because build_special_member_call in 
>> >>> > C++17 is
>> >>> > more aggressive with copy elisions (as required by P0135 which changed 
>> >>> > how we
>> >>> > view prvalues).  In C++14 build_special_member_call produces a 
>> >>> > CALL_EXPR, so
>> >>> > expand_default_init calls maybe_constant_init, for which STRICT is 
>> >>> > false, so
>> >>> > we avoid caching as per 83116.
>> >>>
>> >>> So it sounds like the problem is using cxx_constant_value for the
>> >>> diagnostic when it has different semantics from the
>> >>> maybe_constant_init that follows right after.  I guess we want a
>> >>> cxx_constant_init function that is a hybrid of the two.
>> >>
>> >> So like the following?  Thanks,
>> >>
>> >> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>> >>
>> >> 2018-02-04  Marek Polacek  
>> >>
>> >> PR c++/83692
>> >> * constexpr.c (cxx_constant_init): New function.
>> >> * cp-tree.h (cxx_constant_init): Declare.
>> >> * typeck2.c (store_init_value): Call cxx_constant_init instead of
>> >> cxx_constant_value.
>> >>
>> >> +/* Like cxx_constant_value, but non-strict mode.  */
>> >> +
>> >> +tree
>> >> +cxx_constant_init (tree t, tree decl)
>> >> +{
>> >> +  return cxx_eval_outermost_constant_expr (t, false, false, decl);
>> >> +}
>> >
>> > Hmm, that doesn't do the TARGET_EXPR stripping that
>> > maybe_constant_init does.  I was thinking of a version of
>> > maybe_constant_init that passes false to allow_non_constant.  Probably
>> > by making "maybe_constant_init" and cxx_constant_init both call the
>> > current function with an additional parameter.  And then the existing
>> > call to maybe_constant_init can move under an 'else' to avoid
>> > redundant constexpr evaluation.
>>
>> Want me to take this over?
>
> Sorry again for the delay.
>
> I tried to do what you suggested.  There was one twist: it regressed
> constexpr-nullptr-2.C, in particular we lost diagnostics for
>
> constexpr int* pj0 = &((S*)0)->j;   // { dg-error "not a constant 
> expression" }
> constexpr int* pj1 = &((S*)nullptr)->j;  // { dg-error "not a constant 
> expression" }
>
> because when maybe_constant_init_1 saw a constant:
>
> 5142   else if (CONSTANT_CLASS_P (t))
> 5143 /* No evaluation needed.  */;
>
> so it didn't call cxx_eval_outermost_constant_expr which is supposed to give
> the error.  I fixed it by adding "&& allow_non_constant" so now it gives the
> proper diagnostics.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-02-23  Marek Polacek  
>
> PR c++/83692
> * constexpr.c (maybe_constant_init_1): New function.
> (maybe_constant_init): Make it a wrapper around maybe_constant_init_1.
> (cxx_constant_init): New function.
> * cp-tree.h (cxx_constant_init): Declare.
> * typeck2.c (store_init_value): Call cxx_constant_init instead of
> cxx_constant_value.  Move the maybe_constant_init call under an 
> 'else'.
>
> * g++.dg/cpp1z/constexpr-83692.C: New test.
>
> diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
> index 47ff90cb055..26d0d099a05 100644
> --- gcc/cp/constexpr.c
> +++ gcc/cp/constexpr.c
> @@ -5123,8 +5123,8 @@ fold_non_dependent_expr (tree t)
>  /* Like maybe_constant_value, but returns a CONSTRUCTOR directly, rather
> than wrapped in a TARGET_EXPR.  */
>
> -tree
> -maybe_constant_init (tree t, tree decl)
> +static tree
> +maybe_constant_init_1 (tree t, tree decl, bool allow_non_constant)
>  {
>if (!t)
>

[PATCH] PR fortran/30792 -- Substring data-implied-do is invalid

[Steve Kargl]

The attached patch fixes PR fortran/30792.  A substring
reference is invalid for a data-implied-do.  Regression
tested on x86_64-*-freebsd.  OK to commit.

2018-02-23  Steven G. Kargl 

PR fortran/30792
* decl.c (gfc_match_data): Check for invalid substring in
data-implied-do

2018-02-23  Steven G. Kargl 

PR fortran/30792
* gfortran.dg/data_substring.f90: New test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 257951)
+++ gcc/fortran/decl.c	(working copy)
@@ -585,6 +585,20 @@ gfc_match_data (void)
   if (m != MATCH_YES)
 	goto cleanup;
 
+  if (new_data->var->iter.var
+	  && new_data->var->iter.var->ts.type == BT_INTEGER
+	  && new_data->var->iter.var->symtree->n.sym->attr.implied_index == 1
+	  && new_data->var->list
+	  && new_data->var->list->expr
+	  && new_data->var->list->expr->ts.type == BT_CHARACTER
+	  && new_data->var->list->expr->ref
+	  && new_data->var->list->expr->ref->type == REF_SUBSTRING)
+	{
+	  gfc_error ("Invalid substring in data-implied-do at %L in DATA "
+		 "statement", _data->var->list->expr->where);
+	  goto cleanup;
+	}
+
   m = top_val_list (new_data);
   if (m != MATCH_YES)
 	goto cleanup; 
Index: gcc/testsuite/gfortran.dg/data_substring.f90
===
--- gcc/testsuite/gfortran.dg/data_substring.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/data_substring.f90	(working copy)
@@ -0,0 +1,6 @@
+! { dg-do compile }
+! PR fortran/30792
+character string*1025
+integer i
+data (string(i:i),i=1,1025)/1025*'?'/  ! { dg-error "Invalid substring" }
+end

[PATCH] PR libstdc++/84532 prevent unwrapping of reference_wrapper arguments

[Jonathan Wakely]

When I refactored the std::thread internals I made it use
std::make_tuple, which rather than just DECAY_COPYing the arguments it
also unwraps any std::reference_wrapper arguments, which is wrong.
This constructs a std::tuple of the decayed types, instead of using
make_tuple, so that reference_wrapper arguments are preserved (and
convert to the wrapped type on invocation, if required).

PR libstdc++/84532
* include/std/thread (thread::__make_invoker): Construct tuple
directly instead of using make_tuple.
* testsuite/30_threads/async/84532.cc: New.
* testsuite/30_threads/thread/84532.cc: New.

Tested x86_64-linux, committed to trunk. Backport to gcc-7-branch will follow.
commit 241b2ec07ff9e174c60239706799a1b42818e8c8
Author: redi 
Date:   Fri Feb 23 23:23:43 2018 +

PR libstdc++/84532 prevent unwrapping of reference_wrapper arguments

PR libstdc++/84532
* include/std/thread (thread::__make_invoker): Construct tuple
directly instead of using make_tuple.
* testsuite/30_threads/async/84532.cc: New.
* testsuite/30_threads/thread/84532.cc: New.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@257956 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/libstdc++-v3/include/std/thread b/libstdc++-v3/include/std/thread
index 0c53294aac2..1cabd6ae0e6 100644
--- a/libstdc++-v3/include/std/thread
+++ b/libstdc++-v3/include/std/thread
@@ -243,21 +243,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ return _M_invoke(_Indices()); }
   };
 
-// Alias for _Invoker>
 template
-  using __invoker_type
-   = _Invoker()...))>;
+  using __decayed_tuple = tuple::type...>;
 
   public:
-// Returns a call wrapper that does
-// INVOKE(DECAY_COPY(__callable), DECAY_COPY(__args)).
+// Returns a call wrapper that stores
+// tuple{DECAY_COPY(__callable), DECAY_COPY(__args)...}.
 template
-  static __invoker_type<_Callable, _Args...>
+  static _Invoker<__decayed_tuple<_Callable, _Args...>>
   __make_invoker(_Callable&& __callable, _Args&&... __args)
   {
-   return { {
-   std::make_tuple(std::forward<_Callable>(__callable),
-   std::forward<_Args>(__args)...)
+   return { __decayed_tuple<_Callable, _Args...>{
+   std::forward<_Callable>(__callable), std::forward<_Args>(__args)...
} };
   }
   };
diff --git a/libstdc++-v3/testsuite/30_threads/async/84532.cc 
b/libstdc++-v3/testsuite/30_threads/async/84532.cc
new file mode 100644
index 000..480ed733ca3
--- /dev/null
+++ b/libstdc++-v3/testsuite/30_threads/async/84532.cc
@@ -0,0 +1,38 @@
+// { dg-do compile { target c++11 } }
+// { dg-require-cstdint "" }
+// { dg-require-gthreads "" }
+
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+
+// PR libstdc++/84532
+
+struct F
+{
+  template
+void operator()(T, U, int&)
+{
+  using std::is_same;
+  using std::reference_wrapper;
+  static_assert(is_same::value, "");
+  static_assert(is_same::value, "");
+}
+};
+int i = 0;
+auto fut = std::async(F{}, std::ref(i), std::cref(i), std::ref(i));
diff --git a/libstdc++-v3/testsuite/30_threads/thread/84532.cc 
b/libstdc++-v3/testsuite/30_threads/thread/84532.cc
new file mode 100644
index 000..f389b9b88e3
--- /dev/null
+++ b/libstdc++-v3/testsuite/30_threads/thread/84532.cc
@@ -0,0 +1,38 @@
+// { dg-do compile { target c++11 } }
+// { dg-require-cstdint "" }
+// { dg-require-gthreads "" }
+
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General 

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Martin Sebor]

On 02/23/2018 02:54 PM, Jakub Jelinek wrote:

On Fri, Feb 23, 2018 at 02:46:28PM -0700, Martin Sebor wrote:

This doesn't address any of my concerns that it is completely random
what {dst,src}ref->base is, apples and oranges; sometimes it is a pointer
(e.g. the argument of the function), sometimes the ADDR_EXPR operand,
sometimes the base of the reference, sometimes again address (if the
base of the reference is MEM_REF).  By the lack of consistency in what
it is, just deciding on its type whether you take TREE_TYPE or
TREE_TYPE (TREE_TYPE ()) of it also gives useless result.  You could e.g
call the memcpy etc. function with ADDR_EXPR of a VAR_DECL that has pointer
type, then if dstref->base is that VAR_DECL, POINTER_TYPE_P (basetype)
would be true.


I think I understand what you're saying but this block is only
used for string functions (not for memcpy), and only as a stopgap
to avoid false positives.  Being limited to (a subset of) string
functions the case I think you're concerned about, namely calling
strcpy with a pointer to a pointer, shouldn't come up in valid
code.  It's not bullet-proof but I don't think there is


Can you explain what is invalid on:
char *p;

void
foo (void)
{
  if (sizeof (p) < 8)
return;
  memcpy (, "abcdefg");
  strcpy ((char *) , (char *)  + 5);
}

and similar code?  Both memcpy and strcpy are defined as char accesses
that can alias anything.  If needed tweak it so that you run into this code.


This is arguably valid but (I hope you will agree) questionable
at best.  I haven't seen any warnings for code like this (I've
looked at all those in Marek's Fedora rebuild), nor have I seen
such code in practice.  But if I did come across it I wouldn't
be too concerned about warnings (in fact, I'd view warning for
it as helpful since it's most likely a bug).

That said, the test case as is doesn't trigger -Wrestrict because
there is no overlap.  Even with overlap I could find no way to
exercise the code because the strlen pass doesn't handle the
MEM_REF that the call to memcpy is folded into early on and so
-Wrestrict doesn't know how long the string is.

Without a way to test it I don't feel comfortable making changes
here at this stage.

This isn't meant to say there aren't bugs here.  Just that I don't
know about any (none has been reported) and that I have known bugs
I do need to get to.  If/when we find more here as I'm sure we
will, I'll deal with them as I always do.

Martin

Re: Merge from trunk to gccgo branch

[Ian Lance Taylor]

I merged trunk revision 257954 to the gccgo branch.

Ian

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

[Martin Sebor]

On 02/23/2018 01:32 PM, Siddhesh Poyarekar wrote:

On Saturday 24 February 2018 01:32 AM, Martin Sebor wrote:

Casting the address of a function that takes one or more arguments
to one that takes fewer is unsafe because when the pointer is used
to call the function the extra arguments have indeterminate values.
(This is also why void(*)(void) as a wildcard was a poor choice:
because it's only safe when it's an exact match.)

Casting in the opposite direction (fewer arguments to more) can
also lead to bugs under ABIs where the callee is responsible for
restoring the frame pointer.


I completely agree about the safety aspect of it, but my argument is
about user experience, not safety.  We are after all talking about
explicit casts, i.e. cast decisions that users have consciously made.


I agree.  That was also my first comment on the feature when
it was first proposed:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00275.html


The intent behind the warning is to help find instances of these
conversions that are unsafe and to drive improvements to code and
get it to adopt a single common wildcard.  The current choice
isn't ideal but expanding it even further would compromise
the goal of the warning even more.


While varargs may solve a lot of these problems, the best viable
solution or cases where such casts are necessary seems to be to switch
off the warning, which kinda defeats the goal anyway.  IMO we're better
off making the warnings as less intrusive as possible to begin with and
then gradually make them more aggressive.


In my mind that would be a perfectly reasonable approach.
A variation on it might be to leave a new warning disabled
in the first release, then include it in -Wextra the next
release, and finally put it in -Wall.

Unfortunately, in reality this rarely happens.  Most warnings
stay wherever they land when they're first added and only few
are ever tightened up.  Most also stay the same for many
releases.  (IME, it's not a fun or glamorous job to do the
work it takes to turn on a disabled warning, or to tighten
up an existing one and deal with the fallout.)

Martin

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Martin Sebor]

On 02/23/2018 01:13 PM, Jakub Jelinek wrote:

On Fri, Feb 23, 2018 at 12:57:14PM -0700, Martin Sebor wrote:

+  /* get_inner_reference is not expected to return null.  */
+  gcc_assert (base != NULL);
+
   poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);

-  HOST_WIDE_INT const_off;
-  if (!base || !bytepos.is_constant (_off))
-{
-  base = get_base_address (TREE_OPERAND (expr, 0));
-  return;
-}
-
+  /* There is no conversion from poly_int64 to offset_int even
+ though the latter is wider, so go through HOST_WIDE_INT.
+ The offset is expected to always be constant.  */
+  HOST_WIDE_INT const_off = bytepos.to_constant ();


The assert is ok, but removing the bytepos.is_constant (_off)
is wrong, I'm sure Richard S. can come up with some SVE testcase
where it will not be constant.  If it is not constant, you can handle
it like var_off (which as I said on IRC or in the PR also seems to be
incorrect, because if the base is not a decl the variable offset could be
negative).


That's what I did at first.  I took it out because it sounded
to me like you were saying it was a hypothetical possibility,
not something that would ever happen in practice, and because
I have no way of testing that code.  I have put it back in
the attached update.

Since you added Richard: can you please explain how to convert
a poly64_int to offset_int without converting it to HOST_WIDE_INT,
or if it can't be done, why not?  It's cumbersome and error-prone
to have to go through HWI, and doing so defeats the main goal of
using offset_int in the gimple-ssa-warn-restrict pass.  Should
the pass (and others like it) be changed to store offsets and
sizes in some flavor of poly_int instead of offset_int?


   offrange[0] += const_off;
   offrange[1] += const_off;

@@ -923,7 +923,11 @@ builtin_access::generic_overlap ()
   /* There's no way to distinguish an access to the same member
 of a structure from one to two distinct members of the same
 structure.  Give up to avoid excessive false positives.  */
-  tree basetype = TREE_TYPE (TREE_TYPE (dstref->base));
+  tree basetype = TREE_TYPE (dstref->base);
+  if (POINTER_TYPE_P (basetype)
+ || TREE_CODE (basetype) == ARRAY_TYPE)
+   basetype = TREE_TYPE (basetype);


This doesn't address any of my concerns that it is completely random
what {dst,src}ref->base is, apples and oranges; sometimes it is a pointer
(e.g. the argument of the function), sometimes the ADDR_EXPR operand,
sometimes the base of the reference, sometimes again address (if the
base of the reference is MEM_REF).  By the lack of consistency in what
it is, just deciding on its type whether you take TREE_TYPE or
TREE_TYPE (TREE_TYPE ()) of it also gives useless result.  You could e.g
call the memcpy etc. function with ADDR_EXPR of a VAR_DECL that has pointer
type, then if dstref->base is that VAR_DECL, POINTER_TYPE_P (basetype)
would be true.


I think I understand what you're saying but this block is only
used for string functions (not for memcpy), and only as a stopgap
to avoid false positives.  Being limited to (a subset of) string
functions the case I think you're concerned about, namely calling
strcpy with a pointer to a pointer, shouldn't come up in valid
code.  It's not bullet-proof but I don't think there is
a fundamental problem, either with this patch or with the one
that introduced it.  The fundamental problem is that MEM_REF
can be ambiguous and that's what this code is trying to combat.
See the example I gave here:
https://gcc.gnu.org/ml/gcc/2018-02/msg00136.html

If you think I'm missing something please put together a small
test case to help me see the problem.  I'm not nearly as
comfortable thinking in terms of the internal representation
to visualize all the possibilities here.

Martin
PR tree-optimization/84526 - ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860

gcc/ChangeLog:

	PR tree-optimization/84526
	* gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
	Remove dead code.
	(builtin_access::generic_overlap): Be prepared to handle non-array
	base objects.

gcc/testsuite/ChangeLog:

	PR tree-optimization/84526
	* gcc.dg/Wrestrict-10.c: New test.

Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c	(revision 257933)
+++ gcc/gimple-ssa-warn-restrict.c	(working copy)
@@ -43,6 +43,8 @@
 #include "cfgloop.h"
 #include "intl.h"
 
+location_t gloc;
+
 namespace {
 
 const pass_data pass_data_wrestrict = {
@@ -409,18 +411,24 @@ builtin_memref::set_base_and_offset (tree expr)
   base = get_inner_reference (expr, , , _off,
 			  , , , );
 
+  /* get_inner_reference is not expected to return null.  */
+  gcc_assert (base != NULL);
+
   poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
 
+  /* There is no conversion from poly_int64 to offset_int even
+ though the latter is wider, so go through HOST_WIDE_INT.
+   

Go patch committed: Ignore aliases in fieldtracking info

[Ian Lance Taylor]

This patch to the Go frontend ignores aliases when emitting
fieldtracking info.  We want to track references to fields in the real
struct, not in some alias to the struct.  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 257914)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-ed8647cc99652db2d689215c05f31ad038438a7e
+8b3d6091801d485c74a9c92740c69673e39160b0
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 257914)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -11696,7 +11696,7 @@ Field_reference_expression::do_lower(Gog
   Location loc = this->location();
 
   std::string s = "fieldtrack \"";
-  Named_type* nt = this->expr_->type()->named_type();
+  Named_type* nt = this->expr_->type()->unalias()->named_type();
   if (nt == NULL || nt->named_object()->package() == NULL)
 s.append(gogo->pkgpath());
   else

Re: PING: [PATCH] i386: Add TARGET_INDIRECT_BRANCH_REGISTER

[H.J. Lu]

On Thu, Feb 22, 2018 at 9:32 AM, H.J. Lu  wrote:
> On Thu, Feb 22, 2018 at 9:10 AM, Jeff Law  wrote:
>> On 02/22/2018 07:38 AM, Jan Hubicka wrote:
>>
>> Hi Jan,
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02233.html
>>
>> Is OK for trunk?
>
> I see that using register makes the problem go away and pushing address 
> to stack
> seemed bit odd anyway. However how does this work on other types of thunk?

 Kernel only uses  -mindirect-branch=thunk-extern.  I am working on a 
 proposal
 to use -mindirect-branch=thunk-extern in user space to support CET in a 
 single
 binary.  So at the end of the day, only
 -mindirect-branch=thunk-extern will be used.
>>>
>>> OK, so it is about the fact that we do not really want to support all
>>> -mindirect-branch options in the future? If we don't want to support the 
>>> correctly,
>>> I wonder why we are including them at all.  Shall we at least output 
>>> warning/sorry
>>> when user tries other thunk type with stack unwinding enabled?
>>> (does Kernel use it?)
>> A few notes.
>>
>> 1. It's not even clear at this time that retpolining user space binaries
>> makes any sense at all.   SO before doing anything to make this easier
>> I'd like to see a justification for why it's really needed.
>
> Hi Jeff,
>
> Which part were commenting? My patch to add TARGET_INDIRECT_BRANCH_REGISTER
> or removing -mindirect-branch choices?

Is my patch OK for trunk?

>> 2. On the other hand, the existing thunk options do make it easier to
>> test independent of hte kernel.  ie, I can turn on inline thunks by
>> default and test things in user space (ie, do thunks generally work
>> properly).
>
> It sounds reasonable.
>

Thanks.


-- 
H.J.

[PATCH] Fix up ipa_vr_ggc_hash_traits::hash

[Jakub Jelinek]

Hi!

ipa_vr_ggc_hash_traits::equal does
  return a->type == b->type && a->min == b->min && a->max == b->max;
so it requires pointer identical type (5 value enum) and min/max,
hopefully only INTEGER_CSTs.  Honza complained on IRC that during
firefox a lot of time is spent in this hash table, probably because
the hash function was poor, it hashes any ranges with the same
min/max values but different TREE_TYPE (p->min) the same.

The following patch adjusts the hash method to match the equal
method, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?

In theory we could get bigger savings by e.g. using operand_equal_p
on p->min and p->max instead of pointer comparison, but not really sure
if the VRP code is prepared for that.  E.g. VRP cares whether min
or max are the minimum or maximum of the corresponding type, but if we
ignore the type completely, it could be any other integral type.
We'd use the same value_range memory struct for unsigned char [5, 255]
range, where it is [5, +INF] and for int, where it is just [5, 255].
Does LTO canonicalize INTEGER_TYPEs using type_hash_canon?  In any case,
I think further optimizations should be postponed for GCC9.

2018-02-23  Jakub Jelinek  

* ipa-prop.c (ipa_vr_ggc_hash_traits::hash): Hash p->min and
p->max as pointers rather than using iterative_hash_expr.

--- gcc/ipa-prop.c.jj   2018-01-03 10:19:54.617533871 +0100
+++ gcc/ipa-prop.c  2018-02-23 14:43:08.983733102 +0100
@@ -111,12 +111,13 @@ struct ipa_vr_ggc_hash_traits : public g
   typedef value_range *compare_type;
   static hashval_t
   hash (const value_range *p)
-  {
-gcc_checking_assert (!p->equiv);
-hashval_t t = (hashval_t) p->type;
-t = iterative_hash_expr (p->min, t);
-return iterative_hash_expr (p->max, t);
-  }
+{
+  gcc_checking_assert (!p->equiv);
+  inchash::hash hstate (p->type);
+  hstate.add_ptr (p->min);
+  hstate.add_ptr (p->max);
+  return hstate.end ();
+}
   static bool
   equal (const value_range *a, const value_range *b)
 {

Jakub

Re: [PATCH] fix ICE in generic_overlap (PR 84526)

[Jakub Jelinek]

On Fri, Feb 23, 2018 at 12:57:14PM -0700, Martin Sebor wrote:
> +  /* get_inner_reference is not expected to return null.  */
> +  gcc_assert (base != NULL);
> +
>poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
>  
> -  HOST_WIDE_INT const_off;
> -  if (!base || !bytepos.is_constant (_off))
> -{
> -  base = get_base_address (TREE_OPERAND (expr, 0));
> -  return;
> -}
> -
> +  /* There is no conversion from poly_int64 to offset_int even
> + though the latter is wider, so go through HOST_WIDE_INT.
> + The offset is expected to always be constant.  */
> +  HOST_WIDE_INT const_off = bytepos.to_constant ();

The assert is ok, but removing the bytepos.is_constant (_off)
is wrong, I'm sure Richard S. can come up with some SVE testcase
where it will not be constant.  If it is not constant, you can handle
it like var_off (which as I said on IRC or in the PR also seems to be
incorrect, because if the base is not a decl the variable offset could be
negative).

>offrange[0] += const_off;
>offrange[1] += const_off;
>  
> @@ -923,7 +923,11 @@ builtin_access::generic_overlap ()
>/* There's no way to distinguish an access to the same member
>of a structure from one to two distinct members of the same
>structure.  Give up to avoid excessive false positives.  */
> -  tree basetype = TREE_TYPE (TREE_TYPE (dstref->base));
> +  tree basetype = TREE_TYPE (dstref->base);
> +  if (POINTER_TYPE_P (basetype)
> +   || TREE_CODE (basetype) == ARRAY_TYPE)
> + basetype = TREE_TYPE (basetype);

This doesn't address any of my concerns that it is completely random
what {dst,src}ref->base is, apples and oranges; sometimes it is a pointer
(e.g. the argument of the function), sometimes the ADDR_EXPR operand,
sometimes the base of the reference, sometimes again address (if the
base of the reference is MEM_REF).  By the lack of consistency in what
it is, just deciding on its type whether you take TREE_TYPE or
TREE_TYPE (TREE_TYPE ()) of it also gives useless result.  You could e.g
call the memcpy etc. function with ADDR_EXPR of a VAR_DECL that has pointer
type, then if dstref->base is that VAR_DECL, POINTER_TYPE_P (basetype)
would be true.

Jakub

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

[Siddhesh Poyarekar]

On Saturday 24 February 2018 01:32 AM, Martin Sebor wrote:
> Casting the address of a function that takes one or more arguments
> to one that takes fewer is unsafe because when the pointer is used
> to call the function the extra arguments have indeterminate values.
> (This is also why void(*)(void) as a wildcard was a poor choice:
> because it's only safe when it's an exact match.)
>
> Casting in the opposite direction (fewer arguments to more) can
> also lead to bugs under ABIs where the callee is responsible for
> restoring the frame pointer.

I completely agree about the safety aspect of it, but my argument is
about user experience, not safety.  We are after all talking about
explicit casts, i.e. cast decisions that users have consciously made.

> The intent behind the warning is to help find instances of these
> conversions that are unsafe and to drive improvements to code and
> get it to adopt a single common wildcard.  The current choice
> isn't ideal but expanding it even further would compromise
> the goal of the warning even more.

While varargs may solve a lot of these problems, the best viable
solution or cases where such casts are necessary seems to be to switch
off the warning, which kinda defeats the goal anyway.  IMO we're better
off making the warnings as less intrusive as possible to begin with and
then gradually make them more aggressive.

Siddhesh

[Committed] Update Fortran MATMUL documentation

[Steve Kargl]

I've committed the following patch after a 'make pdf'
to verify that the change is formatted correctly.  The
patch updates the documentation for Fortran's MATMUL
intrinsic.

2018-02-23  Steven G. Kargl  

* intrinsic.texi: Arguments to MATMUL cannot both be rank one.

Index: intrinsic.texi
===
--- intrinsic.texi  (revision 257951)
+++ intrinsic.texi  (working copy)
@@ -9870,6 +9870,7 @@ one or two.
 type; otherwise, an array of @code{LOGICAL} type. The rank shall be one
 or two, and the first (or only) dimension of @var{MATRIX_B} shall be
 equal to the last (or only) dimension of @var{MATRIX_A}.
+@var{MATRIX_A} and @var{MATRIX_B} shall not both be rank one arrays.
 @end multitable
 
 @item @emph{Return value}:

-- 
Steve

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

[Martin Sebor]

On 02/23/2018 11:52 AM, Siddhesh Poyarekar wrote:

On Saturday 24 February 2018 12:01 AM, Richard Biener wrote:

I don't see how the function cast is valid.

I've argued for void (*) () to/from void (*) (int), etc. In the past and that 
was shot down similarly. This looks like exactly the same thing.


That should not throw a warning because void (*) (void) is used as a
wildcard to match all functions.  My understanding from the discussions
around the patch implementation was that these are heuristics and are
not meant to catch all cases anyway.  In such a scenario it might be
prudent to avoid breaking behaviour that many programs seem to assume.


Casting the address of a function that takes one or more arguments
to one that takes fewer is unsafe because when the pointer is used
to call the function the extra arguments have indeterminate values.
(This is also why void(*)(void) as a wildcard was a poor choice:
because it's only safe when it's an exact match.)

Casting in the opposite direction (fewer arguments to more) can
also lead to bugs under ABIs where the callee is responsible for
restoring the frame pointer.

The intent behind the warning is to help find instances of these
conversions that are unsafe and to drive improvements to code and
get it to adopt a single common wildcard.  The current choice
isn't ideal but expanding it even further would compromise
the goal of the warning even more.

Martin

[PATCH] fix ICE in generic_overlap (PR 84526)

[Martin Sebor]

r257860 introduced an unsafe assumption under some conditions
that the base object referenced by a memcpy strcpy necessarily
has a pointer or array type.  The attached patch removes this
assumption.

In addition, as discussed in the bug and in IRC, the patch
also removes a test for the result of get_inner_reference()
being non-null (a vestige of handling the result of a call
to get_addr_base_and_unit_offset() made previously here),
and a test for the bit offset computed by get_inner_reference()
not being convertible to HOST_WIDE_INT.  As far as we can tell
poly64_int is always convertible to HOST_WIDE_INT (i.e.,
poly64_int::is_constant() always returns true).

The conversion from poly64_int to HOST_WIDE_INT is necessary
even though the result is stored in an offset_int because there
is apparently no way to convert from the former to the latter
directly, even though it's wider.

Martin
PR tree-optimization/84526 - ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860

gcc/ChangeLog:

	PR tree-optimization/84526
	* gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
	Remove dead code.
	(builtin_access::generic_overlap): Be prepared to handle non-array
	base objects.

gcc/testsuite/ChangeLog:

	PR tree-optimization/84526
	* gcc.dg/Wrestrict-10.c: New test.

Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c	(revision 257933)
+++ gcc/gimple-ssa-warn-restrict.c	(working copy)
@@ -409,15 +409,15 @@ builtin_memref::set_base_and_offset (tree expr)
   base = get_inner_reference (expr, , , _off,
 			  , , , );
 
+  /* get_inner_reference is not expected to return null.  */
+  gcc_assert (base != NULL);
+
   poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
 
-  HOST_WIDE_INT const_off;
-  if (!base || !bytepos.is_constant (_off))
-{
-  base = get_base_address (TREE_OPERAND (expr, 0));
-  return;
-}
-
+  /* There is no conversion from poly_int64 to offset_int even
+ though the latter is wider, so go through HOST_WIDE_INT.
+ The offset is expected to always be constant.  */
+  HOST_WIDE_INT const_off = bytepos.to_constant ();
   offrange[0] += const_off;
   offrange[1] += const_off;
 
@@ -923,7 +923,11 @@ builtin_access::generic_overlap ()
   /* There's no way to distinguish an access to the same member
 	 of a structure from one to two distinct members of the same
 	 structure.  Give up to avoid excessive false positives.  */
-  tree basetype = TREE_TYPE (TREE_TYPE (dstref->base));
+  tree basetype = TREE_TYPE (dstref->base);
+  if (POINTER_TYPE_P (basetype)
+	  || TREE_CODE (basetype) == ARRAY_TYPE)
+	basetype = TREE_TYPE (basetype);
+
   if (RECORD_OR_UNION_TYPE_P (basetype))
 	return false;
 }
Index: gcc/testsuite/gcc.dg/Wrestrict-10.c
===
--- gcc/testsuite/gcc.dg/Wrestrict-10.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/Wrestrict-10.c	(working copy)
@@ -0,0 +1,121 @@
+/* PR tree-optimization/84526 - ICE in generic_overlap
+   { dg-do compile }
+   { dg-options "-O2 -Wrestrict" } */
+
+typedef __SIZE_TYPE__ size_t;
+
+extern void* memcpy (void* restrict, const void* restrict, size_t);
+extern char* strcat (char* restrict, const char* restrict);
+extern char* strcpy (char* restrict, const char* restrict);
+extern char* strncat (char* restrict, const char* restrict, size_t);
+extern char* strncpy (char* restrict, const char* restrict, size_t);
+
+struct
+{
+  char a[1];
+} b;
+
+int i;
+size_t n;
+
+void __attribute__ ((noclone, noinline))
+test_arr_memcpy_1 (void)
+{
+  memcpy ([i], b.a, n);
+}
+
+void __attribute__ ((noclone, noinline))
+test_arr_memcpy_2 (void)
+{
+  memcpy (b.a, [i], n);
+}
+
+void __attribute__ ((noclone, noinline))
+test_arr_strcat_1 (void)
+{
+  strcat ([i], b.a);/* { dg-warning "\\\[-Wrestrict" } */
+}
+
+void __attribute__ ((noclone, noinline))
+test_arr_strcat_2 (void)
+{
+  /* This probably deserves a warning.  */
+  strcpy (b.a, [i]);
+}
+
+void __attribute__ ((noclone, noinline))
+test_arr_strncat_1 (void)
+{
+  strncat ([i], b.a, n);/* { dg-warning "\\\[-Wrestrict" } */
+}
+
+void __attribute__ ((noclone, noinline))
+test_arr_strncat_2 (void)
+{
+  strncat (b.a, [i], n);/* { dg-warning "\\\[-Wrestrict" } */
+}
+
+void __attribute__ ((noclone, noinline))
+test_arr_strcpy_1 (void)
+{
+  strcpy ([i], b.a);
+}
+
+void __attribute__ ((noclone, noinline))
+test_arr_strcpy_2 (void)
+{
+  strcpy (b.a, [i]);
+}
+
+
+struct S {
+  int a;
+  char b[10];
+} d;
+
+void __attribute__ ((noclone, noinline))
+test_obj_memcpy_1 (void)
+{
+  memcpy (d.b, (char *) , n);
+}
+
+void __attribute__ ((noclone, noinline))
+test_obj_memcpy_2 (void)
+{
+  memcpy ((char *) , d.b, n);
+}
+
+void __attribute__ ((noclone, noinline))
+test_obj_strcpy_1 (void)
+{
+  strcpy (d.b, (char *) );
+}
+
+void __attribute__ ((noclone, noinline))

[PATCH,AIX] aix71.h Increase ISA default

[David Edelsohn]

AIX 7.1 minimum hardware is Power6.  This patch changes TARGET_DEFAULT
to ISA 2.05.

Thanks, David

* config/rs6000/aix71.h (TARGET_DEFAULT): Change to ISA_2_5_MASKS_EMBEDDED.

Index: aix71.h
===
--- aix71.h (revision 257941)
+++ aix71.h (working copy)
@@ -127,8 +127,12 @@
%{mpe: -I%R/usr/lpp/ppe.poe/include}\
%{pthread: -D_THREAD_SAFE}"

+#define RS6000_CPU(NAME, CPU, FLAGS)
+#include "rs6000-cpus.def"
+#undef RS6000_CPU
+
 #undef  TARGET_DEFAULT
-#define TARGET_DEFAULT (MASK_PPC_GPOPT | MASK_PPC_GFXOPT | MASK_MFCRF)
+#define TARGET_DEFAULT ISA_2_5_MASKS_EMBEDDED

 #undef  PROCESSOR_DEFAULT
 #define PROCESSOR_DEFAULT PROCESSOR_POWER7

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

[Siddhesh Poyarekar]

On Saturday 24 February 2018 12:01 AM, Richard Biener wrote:
> I don't see how the function cast is valid. 
> 
> I've argued for void (*) () to/from void (*) (int), etc. In the past and that 
> was shot down similarly. This looks like exactly the same thing. 

That should not throw a warning because void (*) (void) is used as a
wildcard to match all functions.  My understanding from the discussions
around the patch implementation was that these are heuristics and are
not meant to catch all cases anyway.  In such a scenario it might be
prudent to avoid breaking behaviour that many programs seem to assume.

Siddhesh

Re: [Patch, fortran] PR83149 [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[Steve Kargl]

On Fri, Feb 23, 2018 at 06:08:23PM +, Paul Richard Thomas wrote:
> 
> The original bug is fixed as 'obvious' in revision 257938. This is
> indeed a regression.
> 
> The bug in comments 2 and 7 is fixed in revision 257934. This,
> however, is not a regression. The summary will be changed accordingly.
> 
> The 'obvious' tag comes about because both bugs have a common origin:
> referencing the components of ns->proc_name without testing to see if
> it is there.
> 
> Should I close this or should I apply the second part to 7-branch?
> 

If the back port is a trivial effort, then I would back port
to try to keep 6, 7, and trunk somewhat in sync.  This is
simply to aid in maintenance against future bug reports. I'll
leave the "trivial" decision up to you.

-- 
Steve

Re: [PATCH] Add sanitizer support for AArch64 ILP32

[Adhemerval Zanella]

On 23/02/2018 11:39, Jakub Jelinek wrote:
> On Fri, Feb 23, 2018 at 11:27:19AM -0300, Adhemerval Zanella wrote:
>> This patch adds asan support for aarch64 ilp32.  It is based on 'official'
>> glibc support branch [1] (which is in turn based on Linux branch [2]).
>>
>> Main changes for libsanitizer is the kernel ABI support for internal
>> syscalls. Different than x32, ILP32 tries to leverage 32-bits syscalls
>> with kernel ABI for 64 bit argument passing (ftruncate for instance)
>> are passed using the new Linux generic way for 32 bits (by splitting
>> high and low in two registers).
>>
>> So instead of adding more adhoc defines to ILP32 this patch extends the
>> SANITIZER_USES_CANONICAL_LINUX_SYSCALLS to represent both 64 bits
>> argument syscalls (value of 1) and 32 bits (value of 2).
>>
>> The shadow offset used is similar to the arm one (29).
>>
>> I did a sanity check on aarch64-linux-gnu and x86_64-linux-gnu without
>> any regressions.
>>
>> PS: I sent this change llvm-commit, but it got stalled because llvm
>> lack aarch64 ilp32 support and noone could confirm no breakage due
>> missing buildbot.  Also the idea is not sync it back to libsanitizer.
> 
> It will be a nightmare for merges from upstream, but because the upstream is
> so uncooperative probably there is no other way.

What I meant it the idea is to sync it back to libsanitizer, sorry for the
misunderstanding. I can try to push it again for compiler-rt, but it took
a long way to actually get any reply.

> 
>> gcc/
>>
>>  * gcc/config/aarch64/aarch64.c (aarch64_asan_shadow_offset): Add
> 
> No gcc/ prefixes in gcc/ChangeLog.

Right, fixed locally.

> 
>>  TARGET_ILP32 support.
>>
>> libsanitizer/
> 
> Nor libsanitizer/ prefixes in libsaniter/ChangeLog.
>> --- a/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
>> +++ b/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
>> @@ -117,9 +117,9 @@ typedef signed   long long sptr;  // NOLINT
>>  typedef unsigned long uptr;  // NOLINT
>>  typedef signed   long sptr;  // NOLINT
>>  #endif  // defined(_WIN64)
>> -#if defined(__x86_64__)
>> -// Since x32 uses ILP32 data model in 64-bit hardware mode, we must use
>> -// 64-bit pointer to unwind stack frame.
>> +#if defined(__x86_64__) || SANITIZER_AARCH64_ILP32
>> +// Since x32 adn AArch64 ILP32 use ILP32 data model in 64-bit hardware 
>> mode, 
> 
> s/adn/and/

Ack.

> 
>> @@ -445,11 +467,7 @@ uptr internal_execve(const char *filename, char *const 
>> argv[],
>>  // - sanitizer_common.h
>>  bool FileExists(const char *filename) {
>>struct stat st;
>> -#if SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
>> -  if (internal_syscall(SYSCALL(newfstatat), AT_FDCWD, filename, , 0))
>> -#else
>>if (internal_stat(filename, ))
>> -#endif
>>  return false;
>>// Sanity check: filename is a regular file.
>>return S_ISREG(st.st_mode);
> 
> I'm uneasy about this hunk, you change behavior not just on aarch64 ilp32,
> but for many other targets too.  Please don't.

My understanding it a noop since for SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
internal_stat would be a be a internal_syscall(newfstatat, ...) (also
the internal_* names are exactly to abstract this kind of constructions).

> 
> Do you really want it for GCC8?  We are in stage4 and this isn't a
> regression...
> 
>   Jakub
> 

I don't have a strong opinion about that, it would to good to have on GCC8,
but I think I can wait.

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

[Richard Biener]

On February 23, 2018 5:12:23 PM GMT+01:00, Siddhesh Poyarekar 
 wrote:
>On Friday 23 February 2018 09:20 PM, David Malcolm wrote:
>> Do we have a PR open for this yet?
>> 
>> I believe this is an example of where this bit (for the Python case):
>>   https://github.com/imageworks/OpenColorIO/pull/518
>
>There is now:
>
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84531
>
>Siddhesh

I don't see how the function cast is valid. 

I've argued for void (*) () to/from void (*) (int), etc. In the past and that 
was shot down similarly. This looks like exactly the same thing. 

Richard. 

Fix overflow in lto-partition.c

[Jan Hubicka]

Hi,
this patch fixes fork bomb gcc turns into when you compile firefox with LTO and
profile feedback.  We put partition size to INT_MAX to avoid creation of new
partition but because we compute partition_size * 3 / 2 we end up with negative
bound and producing individual partition for every new symbol.

Bootstrapped/regtested x86_64-linux, commited
We ought to backport this to all release branches.

Honza

Index: ChangeLog
===
--- ChangeLog   (revision 257938)
+++ ChangeLog   (working copy)
@@ -1,5 +1,9 @@
 2018-02-08  Jan Hubicka  
 
+   * lto-partition.c (lto_balanced_map): Watch overflow.
+
+2018-02-08  Jan Hubicka  
+
PR ipa/81360
* lto.c (unify_scc): Register prevailing trees, not trees to be freed.
(read_cgraph_and_symbols): Use
Index: lto-partition.c
===
--- lto-partition.c (revision 257938)
+++ lto-partition.c (working copy)
@@ -757,7 +757,8 @@ lto_balanced_map (int n_lto_partitions,
  if (npartitions < n_lto_partitions)
partition_size = total_size / (n_lto_partitions - npartitions);
  else
-   partition_size = INT_MAX;
+   /* Watch for overflow.  */
+   partition_size = INT_MAX / 16;
 
  if (partition_size < PARAM_VALUE (MIN_PARTITION_SIZE))
partition_size = PARAM_VALUE (MIN_PARTITION_SIZE);

Re: [PATCH] Fix up ipa_vr_ggc_hash_traits::hash

[Richard Biener]

On February 23, 2018 6:06:51 PM GMT+01:00, Jakub Jelinek  
wrote:
>Hi!
>
>ipa_vr_ggc_hash_traits::equal does
>  return a->type == b->type && a->min == b->min && a->max == b->max;
>so it requires pointer identical type (5 value enum) and min/max,
>hopefully only INTEGER_CSTs.  Honza complained on IRC that during
>firefox a lot of time is spent in this hash table, probably because
>the hash function was poor, it hashes any ranges with the same
>min/max values but different TREE_TYPE (p->min) the same.
>
>The following patch adjusts the hash method to match the equal
>method, bootstrapped/regtested on x86_64-linux and i686-linux,
>ok for trunk?
>
>In theory we could get bigger savings by e.g. using operand_equal_p
>on p->min and p->max instead of pointer comparison, but not really sure
>if the VRP code is prepared for that.  E.g. VRP cares whether min
>or max are the minimum or maximum of the corresponding type, but if we
>ignore the type completely, it could be any other integral type.

That would certainly lead to issues.

>We'd use the same value_range memory struct for unsigned char [5, 255]
>range, where it is [5, +INF] and for int, where it is just [5, 255].
>Does LTO canonicalize INTEGER_TYPEs using type_hash_canon? 

No.  It unifies with its own logic and types are not registered with the canon 
hash. 

 In any
>case,
>I think further optimizations should be postponed for GCC9.

OK. 

Thanks, 
Richard. 

>2018-02-23  Jakub Jelinek  
>
>   * ipa-prop.c (ipa_vr_ggc_hash_traits::hash): Hash p->min and
>   p->max as pointers rather than using iterative_hash_expr.
>
>--- gcc/ipa-prop.c.jj  2018-01-03 10:19:54.617533871 +0100
>+++ gcc/ipa-prop.c 2018-02-23 14:43:08.983733102 +0100
>@@ -111,12 +111,13 @@ struct ipa_vr_ggc_hash_traits : public g
>   typedef value_range *compare_type;
>   static hashval_t
>   hash (const value_range *p)
>-  {
>-gcc_checking_assert (!p->equiv);
>-hashval_t t = (hashval_t) p->type;
>-t = iterative_hash_expr (p->min, t);
>-return iterative_hash_expr (p->max, t);
>-  }
>+{
>+  gcc_checking_assert (!p->equiv);
>+  inchash::hash hstate (p->type);
>+  hstate.add_ptr (p->min);
>+  hstate.add_ptr (p->max);
>+  return hstate.end ();
>+}
>   static bool
>   equal (const value_range *a, const value_range *b)
> {
>
>   Jakub

[Patch, fortran] PR83149 [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[Paul Richard Thomas]

Hi All,

The original bug is fixed as 'obvious' in revision 257938. This is
indeed a regression.

The bug in comments 2 and 7 is fixed in revision 257934. This,
however, is not a regression. The summary will be changed accordingly.

The 'obvious' tag comes about because both bugs have a common origin:
referencing the components of ns->proc_name without testing to see if
it is there.

Should I close this or should I apply the second part to 7-branch?

Cheers

Paul

>revision 257938:

2018-02-23  Paul Thomas  

PR fortran/83149
* trans-types.c (gfc_sym_type): Test sym->ns->proc_name before
accessing its components.

2018-02-23  Paul Thomas  

PR fortran/83149
* gfortran.dg/pr83149_b.f90: New test.
* gfortran.dg/pr83149_a.f90: Additional source for previous.

>revision 257934:

2018-02-23  Paul Thomas  

PR fortran/83149
* trans-decl.c (gfc_finish_var_decl): Test sym->ns->proc_name
before accessing its components.

2018-02-23  Paul Thomas  

PR fortran/83149
* gfortran.dg/pr83149_1.f90: New test.
* gfortran.dg/pr83149.f90: Additional source for previous.

[PATCH] Fix *{add,sub,and,ior,xor}v*3 patterns on AVX512* (PR target/84524)

[Jakub Jelinek]

Hi!

The following testcase is miscompiled with -O3 -mavx512bw, the combiner
sees there isn't just *xorv32hi3 define_insn with no masking, but that
there is one with masking as well (with the same name) and uses it,
but 1) such instruction doesn't really exist, for masking we only have
VPXORD and VPXORQ, there is no VPXORW or VPXORB 2) the pattern emits
just non-masked string.  In tmp-mddump.md we can see:
;; ../../gcc/config/i386/sse.md: 11825
(define_insn ("*xorv32hi3")
 [
(set (match_operand:V32HI 0 ("register_operand") ("=x,x,v"))
(xor:V32HI (match_operand:V32HI 1 ("vector_operand") ("%0,x,v"))
(match_operand:V32HI 2 ("vector_operand") ("xBm,xm,vm"
] ("(TARGET_SSE && !(MEM_P (operands[1]) && MEM_P (operands[2]))) && 
(TARGET_AVX512F)") ("*{
...
  ops = "v%s%s\t{%%2, %%1, %%0|%%0, %%1, %%2}";
and
;; ../../gcc/config/i386/sse.md: 11825
(define_insn ("*xorv32hi3")
 [
(set (match_operand:V32HI 0 ("register_operand") ("=x,x,v"))
(vec_merge:V32HI (xor:V32HI (match_operand:V32HI 1 
("vector_operand") ("%0,x,v"))
(match_operand:V32HI 2 ("vector_operand") ("xBm,xm,vm")))
(match_operand:V32HI 3 ("vector_move_operand") ("0C,0C,0C"))
(match_operand:SI 4 ("register_operand") ("Yk,Yk,Yk"
] ("(TARGET_AVX512F) && ((TARGET_SSE && !(MEM_P (operands[1]) && MEM_P 
(operands[2]))) && (TARGET_AVX512F))") ("*{
...
  ops = "v%s%s\t{%%2, %%1, %%0|%%0, %%1, %%2}";
For the any_logic patterns we want masking only on the V*[SD][IF]mode patterns
and not on V*[HQ]Imode ones and most of the pattern does it right, except
there was  in set_attr rather than just orig,vex and even
a single subst attribute anywhere forces substitution.

I'd done
grep 'define_insn ' tmp-mddump.md | sort | uniq -c | sort -n | grep -v '^ *1 ' 
| less
to look for other occurrences of similar bug and indeed found another
pattern where we don't really want masking, in that case not because masking
would not be provided for that operation, but because we have explicit
masked define_insn for it, as we need two different for different sets of
modes - e.g. for *addv32hi3 there is one non-masked and one incorrect
masked define_insn created from sse.md: 10085 and explicit *addv32hi3_mask
from sse.md: 10114, the incorrect masked one has wrong condition and comes
first.  There are many other define_insns with duplicated (or more) names
in the above command, but most of them seemed due to :P iterator which is
probably fine for same named patterns, there will be just one pattern
enabled for 32-bit and one for 64-bit, so no need to obfuscate the names.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
This isn't a regression (except perhaps with -O3 -march=native on SKX),
but it is a serious wrong-code.

2018-02-23  Jakub Jelinek  

PR target/84524
* config/i386/sse.md (*3): Replace  with
orig,vex.
(*3): Likewise.  Remove  uses.

* gcc.c-torture/execute/pr84524.c: New test.
* gcc.target/i386/avx512bw-pr84524.c: New test.

--- gcc/config/i386/sse.md.jj   2018-02-13 09:31:24.769607162 +0100
+++ gcc/config/i386/sse.md  2018-02-23 11:51:00.271477979 +0100
@@ -10090,11 +10090,11 @@ (define_insn "*3"
   "TARGET_SSE2 && ix86_binary_operator_ok (, mode, operands)"
   "@
p\t{%2, %0|%0, %2}
-   vp\t{%2, %1, 
%0|%0, %1, %2}"
+   vp\t{%2, %1, %0|%0, %1, %2}"
   [(set_attr "isa" "noavx,avx")
(set_attr "type" "sseiadd")
(set_attr "prefix_data16" "1,*")
-   (set_attr "prefix" "")
+   (set_attr "prefix" "orig,vex")
(set_attr "mode" "")])
 
 (define_insn "*3_mask"
@@ -11899,7 +11899,7 @@ (define_insn "*3"
(eq_attr "mode" "TI"))
(const_string "1")
(const_string "*")))
-   (set_attr "prefix" ",evex")
+   (set_attr "prefix" "orig,vex,evex")
(set (attr "mode")
(cond [(and (match_test " == 16")
(match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL"))
--- gcc/testsuite/gcc.c-torture/execute/pr84524.c.jj2018-02-23 
11:54:51.913492631 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr84524.c   2018-02-23 
11:59:55.467511836 +0100
@@ -0,0 +1,41 @@
+/* PR target/84524 */
+
+__attribute__((noipa)) void
+foo (unsigned short *x)
+{
+  unsigned short i, v;
+  unsigned char j;
+  for (i = 0; i < 256; i++)
+{
+  v = i << 8;
+  for (j = 0; j < 8; j++)
+   if (v & 0x8000)
+ v = (v << 1) ^ 0x1021;
+   else
+ v = v << 1;
+  x[i] = v;
+}
+}
+
+int
+main ()
+{
+  unsigned short a[256];
+
+  foo (a);
+  for (int i = 0; i < 256; i++)
+{
+  unsigned short v = i << 8;
+  for (int j = 0; j < 8; j++)
+   {
+ asm volatile ("" : "+r" (v));
+ if (v & 0x8000)
+   v = (v << 1) ^ 0x1021;
+ else
+   v = v << 1;
+   }
+  if (a[i] != v)
+   __builtin_abort ();
+}
+  return 0;
+}
--- 

Re: [patch, fortran] Bug 84506 - [6/7/8 Regression]INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[Steve Kargl]

On Fri, Feb 23, 2018 at 08:27:18AM -0800, Jerry DeLisle wrote:
> 
> I will back port to 6 an 7 after approval here. I will use the case in 
> the PR as a new test case.
> 
> OK for trunk?
> 
> Regards,
> 
> Jerry
> 
> 2018-02-23  Jerry DeLisle  
> 
>   PR fortran/84506
>   * trans-io.c (set_parameter_value_inquire): Adjust range check of
>   negative unit values for kind=8 units to the kind=4 negative limit.

OK (with a testcase :-)

-- 
Steve

Re: [PATCH] correct -Wrestrict handling of arrays of arrays (PR 84095)

[Jakub Jelinek]

On Fri, Feb 23, 2018 at 08:52:19AM -0700, Martin Sebor wrote:
> There are a large number of failures in these reports in many
> tests that were reported previously (before r257910), suggesting
> something else is wrong.  They all seem to use -fpic.
> 
> If you referring to some other report or your own result please
> post a link or say what target/configuration, etc..

The testcase clearly relies on inlining all the wrap_* functions,
but as they are void wrap_* with -fpic/-fPIC obviously they can't be
inlined at -O2, the executable or some other shared library might define
some other implementation of those and interpose it.
Some targets default to -fpic even.

The following patch just adds static inline to them, so that it works
even with -fpic, as tested with:
make check-gcc check-g++ RUNTESTFLAGS='--target_board=unix\{,-fpic,-fpie\} 
dg.exp=Warray-bounds*'

Ok for trunk?

2018-02-23  Jakub Jelinek  

* c-c++-common/Warray-bounds-2.c (wrap_memcpy_src_xsize,
wrap_memcpy_src_diff_max, wrap_memcpy_dst_xsize,
wrap_memcpy_dst_diff_max, wrap_strcat_src_xsize,
wrap_strcat_dst_xsize, wrap_strcpy_src_xsize,
wrap_strcpy_dst_xsize, wrap_strncpy_src_xsize,
wrap_strncpy_src_diff_max, wrap_strncpy_dst_xsize,
wrap_strncpy_dst_diff_max, wrap_strncpy_dstarray_diff_neg): Add
static inline.

--- gcc/testsuite/c-c++-common/Warray-bounds-2.c.jj 2017-12-18 
14:57:15.601127538 +0100
+++ gcc/testsuite/c-c++-common/Warray-bounds-2.c2018-02-23 
17:12:47.114113757 +0100
@@ -1,4 +1,4 @@
-/* Test to exercise that -Warray-bounds warnings for memory and sring
+/* Test to exercise that -Warray-bounds warnings for memory and string
functions are issued even when they are declared in system headers
(i.e., not just when they are explicitly declared in the source
file.)
@@ -24,7 +24,7 @@ struct __attribute__ ((packed)) Array
 
 /* Exercise memcpy out-of-bounds offsets with an array of known size.  */
 
-void wrap_memcpy_src_xsize (char *d, const char *s, ptrdiff_t i, size_t n)
+static inline void wrap_memcpy_src_xsize (char *d, const char *s, ptrdiff_t i, 
size_t n)
 {
   memcpy (d, s + i, n);   /* { dg-warning "offset 46 is out of the bounds 
\\\[0, 45] of object .ar. with type .(struct )?Array." "memcpy" } */
 }
@@ -39,7 +39,7 @@ void call_memcpy_src_xsize (char *d, siz
 
 /* Exercise memcpy out-of-bounds offsets with an array of unknown size.  */
 
-void wrap_memcpy_src_diff_max (char *d, const char *s, ptrdiff_t i, size_t n)
+static inline void wrap_memcpy_src_diff_max (char *d, const char *s, ptrdiff_t 
i, size_t n)
 {
   memcpy (d, s + i, n);   /* { dg-warning "pointer overflow between offset 
\[0-9\]+ and size 3" "memcpy" } */
 }
@@ -49,7 +49,7 @@ void call_memcpy_src_diff_max (char *d,
   wrap_memcpy_src_diff_max (d, s, MAX, 3);
 }
 
-void wrap_memcpy_dst_xsize (char *d, const char *s, ptrdiff_t i, size_t n)
+static inline void wrap_memcpy_dst_xsize (char *d, const char *s, ptrdiff_t i, 
size_t n)
 {
   memcpy (d + i, s, n);   /* { dg-warning "offset 47 is out of the bounds 
\\\[0, 45] of object .ar1. with type .(struct )?Array." "memcpy" } */
 }
@@ -62,7 +62,7 @@ void call_memcpy_dst_xsize (const char *
   sink ();
 }
 
-void wrap_memcpy_dst_diff_max (char *d, const char *s, ptrdiff_t i, size_t n)
+static inline void wrap_memcpy_dst_diff_max (char *d, const char *s, ptrdiff_t 
i, size_t n)
 {
   memcpy (d + i, s, n);   /* { dg-warning "offset -?\[0-9\]+ is out of the 
bounds \\\[0, 45] of object .ar2. with type .(struct )?Array." "memcpy" } */
 }
@@ -76,7 +76,7 @@ void call_memcpy_dst_diff_max (const cha
 }
 
 
-void wrap_strcat_src_xsize (char *d, const char *s, ptrdiff_t i)
+static inline void wrap_strcat_src_xsize (char *d, const char *s, ptrdiff_t i)
 {
   strcat (d, s + i);   /* { dg-warning "offset 46 is out of the bounds \\\[0, 
45] of object .ar3. with type .(struct )?Array." "strcat" } */
 }
@@ -89,7 +89,7 @@ void call_strcat_src_xsize (char *d)
   sink ();
 }
 
-void wrap_strcat_dst_xsize (char *d, const char *s, ptrdiff_t i)
+static inline void wrap_strcat_dst_xsize (char *d, const char *s, ptrdiff_t i)
 {
   strcat (d + i, s);   /* { dg-warning "offset 47 is out of the bounds \\\[0, 
45] of object .ar4. with type .(struct )?Array." "strcat" } */
 }
@@ -103,7 +103,7 @@ void call_strcat_dst_xsize (const char *
 }
 
 
-void wrap_strcpy_src_xsize (char *d, const char *s, ptrdiff_t i)
+static inline void wrap_strcpy_src_xsize (char *d, const char *s, ptrdiff_t i)
 {
   strcpy (d, s + i);   /* { dg-warning "offset 48 is out of the bounds \\\[0, 
45] of object .ar5. with type .(struct )?Array." "strcpy" } */
 }
@@ -116,7 +116,7 @@ void call_strcpy_src_xsize (char *d)
   sink ();
 }
 
-void wrap_strcpy_dst_xsize (char *d, const char *s, ptrdiff_t i)
+static inline void wrap_strcpy_dst_xsize (char *d, const char *s, ptrdiff_t i)
 {
   strcpy (d + i, s);   /* { dg-warning "offset 49 is out of the bounds \\\[0, 
45] of 

Re: [PATCH] Add sanitizer support for AArch64 ILP32

[Jakub Jelinek]

On Fri, Feb 23, 2018 at 11:27:19AM -0300, Adhemerval Zanella wrote:
> This patch adds asan support for aarch64 ilp32.  It is based on 'official'
> glibc support branch [1] (which is in turn based on Linux branch [2]).
> 
> Main changes for libsanitizer is the kernel ABI support for internal
> syscalls. Different than x32, ILP32 tries to leverage 32-bits syscalls
> with kernel ABI for 64 bit argument passing (ftruncate for instance)
> are passed using the new Linux generic way for 32 bits (by splitting
> high and low in two registers).
> 
> So instead of adding more adhoc defines to ILP32 this patch extends the
> SANITIZER_USES_CANONICAL_LINUX_SYSCALLS to represent both 64 bits
> argument syscalls (value of 1) and 32 bits (value of 2).
> 
> The shadow offset used is similar to the arm one (29).
> 
> I did a sanity check on aarch64-linux-gnu and x86_64-linux-gnu without
> any regressions.
> 
> PS: I sent this change llvm-commit, but it got stalled because llvm
> lack aarch64 ilp32 support and noone could confirm no breakage due
> missing buildbot.  Also the idea is not sync it back to libsanitizer.

It will be a nightmare for merges from upstream, but because the upstream is
so uncooperative probably there is no other way.

> gcc/
> 
>   * gcc/config/aarch64/aarch64.c (aarch64_asan_shadow_offset): Add

No gcc/ prefixes in gcc/ChangeLog.

>   TARGET_ILP32 support.
> 
> libsanitizer/

Nor libsanitizer/ prefixes in libsaniter/ChangeLog.
> --- a/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
> +++ b/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
> @@ -117,9 +117,9 @@ typedef signed   long long sptr;  // NOLINT
>  typedef unsigned long uptr;  // NOLINT
>  typedef signed   long sptr;  // NOLINT
>  #endif  // defined(_WIN64)
> -#if defined(__x86_64__)
> -// Since x32 uses ILP32 data model in 64-bit hardware mode, we must use
> -// 64-bit pointer to unwind stack frame.
> +#if defined(__x86_64__) || SANITIZER_AARCH64_ILP32
> +// Since x32 adn AArch64 ILP32 use ILP32 data model in 64-bit hardware mode, 

s/adn/and/

> @@ -445,11 +467,7 @@ uptr internal_execve(const char *filename, char *const 
> argv[],
>  // - sanitizer_common.h
>  bool FileExists(const char *filename) {
>struct stat st;
> -#if SANITIZER_USES_CANONICAL_LINUX_SYSCALLS
> -  if (internal_syscall(SYSCALL(newfstatat), AT_FDCWD, filename, , 0))
> -#else
>if (internal_stat(filename, ))
> -#endif
>  return false;
>// Sanity check: filename is a regular file.
>return S_ISREG(st.st_mode);

I'm uneasy about this hunk, you change behavior not just on aarch64 ilp32,
but for many other targets too.  Please don't.

Do you really want it for GCC8?  We are in stage4 and this isn't a
regression...

Jakub

Fwd: Re: [PATCH] PR fortran/84511 -- Fix C_LOC in a transfer statement

[Jerry DeLisle]

 Forwarded Message 
Subject: Re: [PATCH] PR fortran/84511 -- Fix C_LOC in a transfer statement
Date: Fri, 23 Feb 2018 08:30:29 -0800
From: Jerry DeLisle 
To: s...@troutmask.apl.washington.edu

On 02/22/2018 12:01 PM, Steve Kargl wrote:

All,

The attached patch handles C_LOC in a transfer statement
such as "print *, c_loc(xxx)".  The bug report contains
two files that must be compiled separately to exhibit
the bug.  I have no idea how to write a testcase for this
situation.  If someone can write a testcase, I'm fine
with that.  If someone can tell me how to write a testcase,
I'm fine with that, too.

Regression tested on x86_64-*-freebsd.  OK to commit?


OK Steve.

Regards,

Jerry

Re: [PATCH, rs6000] Update altivec-7 testcase(s).

[Will Schmidt]

On Thu, 2018-02-22 at 12:06 -0600, Segher Boessenkool wrote:
> Hi Will,
> 
> On Wed, Feb 21, 2018 at 11:33:14AM -0600, Will Schmidt wrote:
> >   This patch moves the vsx related content from the altivec-7-be test into
> > a new vsx-7-be test.
> > This fixes up some test failures as seen on older power systems.
> 
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/vsx-7-be.c
> > @@ -0,0 +1,42 @@
> > +/* { dg-do compile { target powerpc64-*-* } } */
> 
> powerpc*-*-* please, and if you need 64-bit use lp64.

Thats an existing thing to help indicate 'be' versus 'le'.

altivec-7-be.c:/* { dg-do compile { target powerpc64-*-* } } */
altivec-7-le.c:/* { dg-do compile { target powerpc64le-*-* } } */

but yeah, we are potentially missing coverage for -m32. 

Should I instead try to combine the le,be tests, and set target markers
on any le/be unique scan-assembler stanzas?


> Otherwise fine.  Okay for trunk with that fixed.  Thanks!
> 
> (Is it useful to copy the altivec stuff here though?  The altivec-7-be
> test will be run as well).
> 
> 
> Segher
> 

Re: [PATCH] Correct debug for -mcall-ms2sysv-xlogues stubs (PR target/83917, take 2)

[Jakub Jelinek]

On Thu, Feb 22, 2018 at 03:56:15PM +0100, Jakub Jelinek wrote:
> Ok for trunk if it passes bootstrap/regtest on x86_64-linux and i686-linux?

Now successfully bootstrapped/regtested on these targets.

> 2018-02-22  Jakub Jelinek  
> 
>   PR debug/83917
>   * config/i386/i386-asm.h (PACKAGE_VERSION, PACKAGE_NAME,
>   PACKAGE_STRING, PACKAGE_TARNAME, PACKAGE_URL): Undefine between
>   inclusion of auto-target.h and auto-host.h.
>   (USE_GAS_CFI_DIRECTIVES): Define if not defined already based on
>   __GCC_HAVE_DWARF2_CFI_ASM.
>   (cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset,
>   cfi_def_cfa_register, cfi_def_cfa, cfi_register, cfi_offset, cfi_push,
>   cfi_pop): Define.
>   * config/i386/cygwin.S: Don't include auto-host.h here, just
>   define USE_GAS_CFI_DIRECTIVES to 1 or 0 and include i386-asm.h.
>   (cfi_startproc, cfi_endproc, cfi_adjust_cfa_offset,
>   cfi_def_cfa_register, cfi_register, cfi_push, cfi_pop): Remove.
>   * config/i386/resms64fx.h: Add cfi_* directives.
>   * config/i386/resms64x.h: Likewise.

Jakub

[patch, fortran] Bug 84506 - [6/7/8 Regression]INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[Jerry DeLisle]

Hi Folks,

This bug is a result of a range check we do on kind=8 unit numbers to 
make sure they fall within the range values of a kind=4 integer. We were 
limiting this range to positive values. I think when we introduced the 
newunit feature which uses negative unit values, we missed this adjustment.


The attached patch is trivial. Regression tested on x86_86-pc-linux-gnu.

I will back port to 6 an 7 after approval here. I will use the case in 
the PR as a new test case.


OK for trunk?

Regards,

Jerry

2018-02-23  Jerry DeLisle  

PR fortran/84506
* trans-io.c (set_parameter_value_inquire): Adjust range check of
negative unit values for kind=8 units to the kind=4 negative limit.


diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.c
index 021c788ba54..36adb034475 100644
--- a/gcc/fortran/trans-io.c
+++ b/gcc/fortran/trans-io.c
@@ -639,12 +639,12 @@ set_parameter_value_inquire (stmtblock_t *block, tree var,
   /* Don't evaluate the UNIT number multiple times.  */
   se.expr = gfc_evaluate_now (se.expr, );
 
-  /* UNIT numbers should be greater than zero.  */
+  /* UNIT numbers should be greater than the min.  */
   i = gfc_validate_kind (BT_INTEGER, 4, false);
+  val = gfc_conv_mpz_to_tree (gfc_integer_kinds[i].pedantic_min_int, 4);
   cond1 = build2_loc (input_location, LT_EXPR, logical_type_node,
 			  se.expr,
-			  fold_convert (TREE_TYPE (se.expr),
-			  integer_zero_node));
+			  fold_convert (TREE_TYPE (se.expr), val));
   /* UNIT numbers should be less than the max.  */
   val = gfc_conv_mpz_to_tree (gfc_integer_kinds[i].huge, 4);
   cond2 = build2_loc (input_location, GT_EXPR, logical_type_node,

Re: [PATCH] correct -Wrestrict handling of arrays of arrays (PR 84095)

[Siddhesh Poyarekar]

On Friday 23 February 2018 09:22 PM, Martin Sebor wrote:
> I see no failures in this test in any of the recently reported
> results on any targets except those below:
> 
>   https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01530.html
>   https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01514.html
> 
> There are a large number of failures in these reports in many
> tests that were reported previously (before r257910), suggesting
> something else is wrong.  They all seem to use -fpic.
> 
> If you referring to some other report or your own result please
> post a link or say what target/configuration, etc..

This was on my x86_64 box (Xeon(R) CPU E5-2623) and a standard
x86_64-pc-linux-gnu native build.  It was after an incremental build
though, so I'll schedule a fresh one next week to confirm if you think
that shouldn't happen.

Siddhesh

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

[Siddhesh Poyarekar]

On Friday 23 February 2018 09:20 PM, David Malcolm wrote:
> Do we have a PR open for this yet?
> 
> I believe this is an example of where this bit (for the Python case):
>   https://github.com/imageworks/OpenColorIO/pull/518

There is now:

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

Siddhesh

Re: [PATCH][committed] Fix ICE in maybe_record_trace_start

[Jeff Law]

On 02/22/2018 03:59 AM, Tom de Vries wrote:
> On 02/12/2018 07:32 PM, Jeff Law wrote:
>> diff --git a/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
>> b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
>> new file mode 100644
>> index 000..0ca0b9f034b
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
>> @@ -0,0 +1,36 @@
>> +int foo;
>> +typedef long unsigned int size_t;
>> +typedef short unsigned int wchar_t;
>> +struct tm
>> +{
>> +  int tm_mday;
>> +  int tm_mon;
>> +  int tm_year;
>> +};
>> +size_t
>> +__strftime (wchar_t * s, size_t maxsize, const wchar_t * format,
>> const struct tm *tim_p)
>> +{
>> +  size_t count = 0;
>> +  int len = 0;
>> +  size_t i, ctloclen;
>> +  unsigned long width;
>> +  {
>> +    if (foo)
>> +  {
>> +    {
>> +  wchar_t *fmt = L"%s%.*d";
>> +  len = swprintf ([count], maxsize, fmt, "-", width, 0);
>> +    }
>> +    if ((count) >= maxsize)
>> +  return 0;
>> +  }
>> +    else
>> +  {
>> +    len =
>> +  swprintf ([count], maxsize - count, L"%.2d/%.2d/%.2d", 42,
>> 99, 0);
>> +    if ((count) >= maxsize)
>> +  return 0;
>> +
>> +  }
>> +  }
>> +}
> 
> Hi,
> 
> when compiling this test for nvptx, the missing declaration for swprintf
> results in this default declaration in the .s file based on the
> arguments of the first call:
> ...
>     .extern .func (.param.u32 %value_out) swprintf (.param.u64
> %in_ar0, .param.u64 %in_ar1, .param.u64 %in_ar2, .param.u64 %in_ar3,
> .param.u64 %in_ar4, .param.u32 %in_ar5);
> ...
> 
> and this error message when ptxas process the second call:
> ...
> ptxas regs-arg-size.o, line 97; error   : Type or alignment of argument
> does not match formal parameter '%in_ar3'
> ptxas regs-arg-size.o, line 97; error   : Type or alignment of argument
> does not match formal parameter '%in_ar4'
> ptxas fatal   : Ptx assembly aborted due to errors
> nvptx-as: ptxas returned 255 exit status
> ...
> 
> When adding a declaration in the source like so:
> ...
> diff --git a/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
> b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
> index 0ca0b9f034b..81943a2c459 100644
> --- a/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
> +++ b/gcc/testsuite/gcc.c-torture/compile/regs-arg-size.c
> @@ -1,6 +1,7 @@
>  int foo;
>  typedef long unsigned int size_t;
>  typedef short unsigned int wchar_t;
> +extern int swprintf(wchar_t *wcs, size_t maxlen, const wchar_t *format,
> ...);
>  struct tm
>  {
>    int tm_mday;
> ...
> 
> the declaration changes to:
> ...
> .extern .func (.param.u32 %value_out) swprintf (.param.u64 %in_ar0,
> .param.u64 %in_ar1, .param.u64 %in_ar2, .param.u64 %in_ar3);
> ...
> and test test-case passes.
> 
> Is it ok to update the test-case like this, or should it require
> effective target 'untyped_assembly' (which is false for nvptx).
It's OK to update the test in either way -- I don't think either change
would compromise the test.  Adding the prototype seems like the better
choice to me.

I need to remember that PTX (and the PA) are much more sensitive to
these issues than any other port and once a testcase minimization is
complete to go back and make sure we have suitable prototypes.

jeff

Re: [PATCH] correct -Wrestrict handling of arrays of arrays (PR 84095)

[Martin Sebor]

On 02/22/2018 08:17 PM, Siddhesh Poyarekar wrote:

On Friday 02 February 2018 05:15 AM, Martin Sebor wrote:

PR middle-end/84095 - false-positive -Wrestrict warnings for memcpy within array

gcc/ChangeLog:

PR middle-end/84095
* gimple-ssa-warn-restrict.c (builtin_memref::extend_offset_range): New.
(builtin_memref::set_base_and_offset): Same.  Handle inner references.
(builtin_memref::builtin_memref): Factor out parts into
set_base_and_offset and call it.

gcc/testsuite/ChangeLog:

PR middle-end/84095
* c-c++-common/Warray-bounds-3.c: Adjust text of expected warnings.
* c-c++-common/Wrestrict.c: Same.
* gcc.dg/Wrestrict-6.c: Same.
* gcc.dg/Warray-bounds-27.c: New test.
* gcc.dg/Wrestrict-8.c: New test.
* gcc.dg/Wrestrict-9.c: New test.
* gcc.dg/pr84095.c: New test.


This is causing failures in Warray-bounds-2.c in the testsuite:

FAIL: c-c++-common/Warray-bounds-2.c  -Wc++-compat  memcpy (test for
warnings, line 67)


I see no failures in this test in any of the recently reported
results on any targets except those below:

  https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01530.html
  https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01514.html

There are a large number of failures in these reports in many
tests that were reported previously (before r257910), suggesting
something else is wrong.  They all seem to use -fpic.

If you referring to some other report or your own result please
post a link or say what target/configuration, etc..

Martin



FAIL: c-c++-common/Warray-bounds-2.c  -Wc++-compat   (test for warnings,
line 72)
FAIL: c-c++-common/Warray-bounds-2.c  -Wc++-compat  strncpy (test for
warnings, line 178)
FAIL: c-c++-common/Warray-bounds-2.c  -Wc++-compat   (test for warnings,
line 183)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++98 memcpy (test for
warnings, line 67)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++98  (test for warnings,
line 72)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++98 strncpy (test for
warnings, line 178)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++98  (test for warnings,
line 183)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++11 memcpy (test for
warnings, line 67)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++11  (test for warnings,
line 72)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++11 strncpy (test for
warnings, line 178)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++11  (test for warnings,
line 183)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++14 memcpy (test for
warnings, line 67)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++14  (test for warnings,
line 72)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++14 strncpy (test for
warnings, line 178)
FAIL: c-c++-common/Warray-bounds-2.c  -std=gnu++14  (test for warnings,
line 183)

Siddhesh

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

[David Malcolm]

On Fri, 2018-02-23 at 09:10 +0530, Siddhesh Poyarekar wrote:
> Libraries like gtk/glib[1] and python[2] use functions with common
> argument subsets to register callbacks.  The working idea behind it
> is
> to have a flag in the structure (or some other pre-determined method)
> that specifies how the callback is cast and called.
> 
> Fix this by not throwing a warning when functions with different
> argument list lengths (of M and N where M < N) have compatible
> argument types for the first M arguments.

Do we have a PR open for this yet?

I believe this is an example of where this bit (for the Python case):
  https://github.com/imageworks/OpenColorIO/pull/518

[...snip...]


Dave

Re: [Patch AArch64] Turn on frame pointer / partial fix for PR84521

[David Malcolm]

On Fri, 2018-02-23 at 11:32 +, Ramana Radhakrishnan wrote:
> This fixes a GCC-8 regression that we accidentally switched off frame
> pointers in the AArch64 backend when changing the defaults in the
> common
> parts of the code. This breaks an ABI decision that was made in GCC
> at
> the dawn of the port with respect to having a frame pointer at all
> times.  If we really want to turn this off lets have a discussion
> around
> that separately.
> 
> For now turn this back on and I believe this will leave PR84521
> latent
> again with -fomit-frame-pointer and (hopefully) make the ruby issue
> go
> away. I'm asking Sudi to pick that up.

FWIW I was able to successfully build ruby on aarch64 with this patch
(on gcc116).

[...snip...]

Re: [config patch] Fwd from binutils: add ax_pthread.m4 to config/ directory

[Joshua Watt]

On Mon, 2018-02-19 at 17:24 -0800, Cary Coutant wrote:
> Please see this patch posted to the binutils list:
> 
>https://sourceware.org/ml/binutils/2018-02/msg00260.html
> 
> where Joshua proposes to add the ax_pthread.m4 script, from the
> autoconf macro archive, to the config/ directory in order to improve
> gold's configure-time detection of thread support.
> 
> Is the config/ part of this patch OK?
> 
> config/
> * ax_pthread.m4: New file.
> 
> -cary

Ping? I can repost this as a patch here instead of linking to the
binutils thread if necessary.

Thanks,
Joshua Watt

Re: [Patch AArch64] Turn on frame pointer / partial fix for PR84521

[Jakub Jelinek]

On Fri, Feb 23, 2018 at 11:32:57AM +, Ramana Radhakrishnan wrote:
> This fixes a GCC-8 regression that we accidentally switched off frame
> pointers in the AArch64 backend when changing the defaults in the common
> parts of the code. This breaks an ABI decision that was made in GCC at
> the dawn of the port with respect to having a frame pointer at all
> times.  If we really want to turn this off lets have a discussion around
> that separately.
> 
> For now turn this back on and I believe this will leave PR84521 latent
> again with -fomit-frame-pointer and (hopefully) make the ruby issue go
> away. I'm asking Sudi to pick that up.

I don't think it will change anything on PR84521 testcase with
-fomit-frame-pointer, only make it pass without either of
-f{,no-}omit-frame-pointer where it previously failed.  It will still fail
with -fomit-frame-pointer and didn't use to fail and won't fail with
explicit -fno-omit-frame-pointer.

The general decision if frame pointers should be used by default or not
depends on performance (so the patch to change it in generic code really
seems to be weird); if -fomit-frame-pointer is faster than
-fno-omit-frame-pointer in general, then it is a sane default.  Code like
backtrace can't assume frame pointers are always available anyway, because
some frames could be compiled with -fomit-frame-pointer and generally there
is unwind info that can be used for backtrace like purposes (though,
for some strange reason aarch64 doesn't enable -fasynchronous-unwind-tables
by default).

Jakub

Re: C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692)

[Marek Polacek]

On Fri, Feb 16, 2018 at 04:10:20PM -0500, Jason Merrill wrote:
> On Mon, Feb 5, 2018 at 1:45 PM, Jason Merrill  wrote:
> > On Mon, Feb 5, 2018 at 8:37 AM, Marek Polacek  wrote:
> >> On Fri, Feb 02, 2018 at 02:11:27PM -0500, Jason Merrill wrote:
> >>> On Thu, Jan 25, 2018 at 4:16 PM, Marek Polacek  wrote:
> >>> > This is a similar problem to 83116: we'd cached a constexpr call, but 
> >>> > after a
> >>> > store the result had become invalid, yet we used the wrong result again 
> >>> > when
> >>> > encountering the same call later.  This resulted in evaluating a 
> >>> > THROW_EXPR
> >>> > which doesn't work.  Details in
> >>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692#c5
> >>> >
> >>> > The fix for 83116 didn't work here, because when evaluating the body of 
> >>> > the
> >>> > ctor via store_init_value -> cxx_constant_value we are in STRICT, so we 
> >>> > do
> >>> > cache.
> >>>
> >>> > It seems that we may no longer rely on the constexpr call table when we
> >>> > do cxx_eval_store_expression, because that just rewrites *valp, i.e. the
> >>> > value of an object.  Might be too big a hammer again, but I couldn't 
> >>> > think
> >>> > of how I could guard the caching of a constexpr call.
> >>>
> >>> > This doesn't manifest in C++14 because build_special_member_call in 
> >>> > C++17 is
> >>> > more aggressive with copy elisions (as required by P0135 which changed 
> >>> > how we
> >>> > view prvalues).  In C++14 build_special_member_call produces a 
> >>> > CALL_EXPR, so
> >>> > expand_default_init calls maybe_constant_init, for which STRICT is 
> >>> > false, so
> >>> > we avoid caching as per 83116.
> >>>
> >>> So it sounds like the problem is using cxx_constant_value for the
> >>> diagnostic when it has different semantics from the
> >>> maybe_constant_init that follows right after.  I guess we want a
> >>> cxx_constant_init function that is a hybrid of the two.
> >>
> >> So like the following?  Thanks,
> >>
> >> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >>
> >> 2018-02-04  Marek Polacek  
> >>
> >> PR c++/83692
> >> * constexpr.c (cxx_constant_init): New function.
> >> * cp-tree.h (cxx_constant_init): Declare.
> >> * typeck2.c (store_init_value): Call cxx_constant_init instead of
> >> cxx_constant_value.
> >>
> >> +/* Like cxx_constant_value, but non-strict mode.  */
> >> +
> >> +tree
> >> +cxx_constant_init (tree t, tree decl)
> >> +{
> >> +  return cxx_eval_outermost_constant_expr (t, false, false, decl);
> >> +}
> >
> > Hmm, that doesn't do the TARGET_EXPR stripping that
> > maybe_constant_init does.  I was thinking of a version of
> > maybe_constant_init that passes false to allow_non_constant.  Probably
> > by making "maybe_constant_init" and cxx_constant_init both call the
> > current function with an additional parameter.  And then the existing
> > call to maybe_constant_init can move under an 'else' to avoid
> > redundant constexpr evaluation.
> 
> Want me to take this over?

Sorry again for the delay.

I tried to do what you suggested.  There was one twist: it regressed
constexpr-nullptr-2.C, in particular we lost diagnostics for

constexpr int* pj0 = &((S*)0)->j;   // { dg-error "not a constant 
expression" }
constexpr int* pj1 = &((S*)nullptr)->j;  // { dg-error "not a constant 
expression" }

because when maybe_constant_init_1 saw a constant:

5142   else if (CONSTANT_CLASS_P (t))
5143 /* No evaluation needed.  */;

so it didn't call cxx_eval_outermost_constant_expr which is supposed to give
the error.  I fixed it by adding "&& allow_non_constant" so now it gives the
proper diagnostics.

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

2018-02-23  Marek Polacek  

PR c++/83692
* constexpr.c (maybe_constant_init_1): New function.
(maybe_constant_init): Make it a wrapper around maybe_constant_init_1.
(cxx_constant_init): New function.
* cp-tree.h (cxx_constant_init): Declare.
* typeck2.c (store_init_value): Call cxx_constant_init instead of
cxx_constant_value.  Move the maybe_constant_init call under an 'else'.

* g++.dg/cpp1z/constexpr-83692.C: New test.

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 47ff90cb055..26d0d099a05 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -5123,8 +5123,8 @@ fold_non_dependent_expr (tree t)
 /* Like maybe_constant_value, but returns a CONSTRUCTOR directly, rather
than wrapped in a TARGET_EXPR.  */
 
-tree
-maybe_constant_init (tree t, tree decl)
+static tree
+maybe_constant_init_1 (tree t, tree decl, bool allow_non_constant)
 {
   if (!t)
 return t;
@@ -5139,10 +5139,10 @@ maybe_constant_init (tree t, tree decl)
 t = TARGET_EXPR_INITIAL (t);
   if (!is_nondependent_static_init_expression (t))
 /* Don't try to evaluate it.  */;
-  else if (CONSTANT_CLASS_P (t))
+  else if (CONSTANT_CLASS_P 

[PATCH] Add sanitizer support for AArch64 ILP32

[Adhemerval Zanella]

This patch adds asan support for aarch64 ilp32.  It is based on 'official'
glibc support branch [1] (which is in turn based on Linux branch [2]).

Main changes for libsanitizer is the kernel ABI support for internal
syscalls. Different than x32, ILP32 tries to leverage 32-bits syscalls
with kernel ABI for 64 bit argument passing (ftruncate for instance)
are passed using the new Linux generic way for 32 bits (by splitting
high and low in two registers).

So instead of adding more adhoc defines to ILP32 this patch extends the
SANITIZER_USES_CANONICAL_LINUX_SYSCALLS to represent both 64 bits
argument syscalls (value of 1) and 32 bits (value of 2).

The shadow offset used is similar to the arm one (29).

I did a sanity check on aarch64-linux-gnu and x86_64-linux-gnu without
any regressions.

PS: I sent this change llvm-commit, but it got stalled because llvm
lack aarch64 ilp32 support and noone could confirm no breakage due
missing buildbot.  Also the idea is not sync it back to libsanitizer.

gcc/

* gcc/config/aarch64/aarch64.c (aarch64_asan_shadow_offset): Add
TARGET_ILP32 support.

libsanitizer/

* libsanitizer/sanitizer_common/sanitizer_internal_defs.h
(uhwptr, OFF_T, operator_new_size_type): Define for
SANITIZER_AARCH64_ILP32.
* libsanitizer/sanitizer_common/sanitizer_linux.cc (SYSCALL_LL64):
New define: wrap a 64-bit argument for syscall.
(internal_ftruncate, internal_stat, internal_lstat, internal_unlink,
internal_rename, internal_lseek): Add support for
SANITIZER_USES_CANONICAL_LINUX_SYSCALLS equal to 2.
(FileExists): Use internal_stat regardless.
* libsanitizer/sanitizer_common/sanitizer_platform.h
(SANITIZER_AARCH64_ILP32): Define.
(SANITIZER_USES_CANONICAL_LINUX_SYSCALLS): Define to 1 or 2 depending
of the expected architecture ABI.
* libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
(CHECK_SIZE_AND_OFFSET(ipc_perm,mode): Define for AArch64 ILP32.
* libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
(struct_kernel_stat_sz, struct_kernel_stat64_sz,
__sanitizer___kernel_uid_t, __sanitizer___kernel_gid_t): Likewise.
[__sanitizer_dirent] (d_ino, d_off): Likewise.

[1] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/arm/ilp32
[2] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
---
 gcc/config/aarch64/aarch64.c   |  5 ++-
 .../sanitizer_common/sanitizer_internal_defs.h | 12 +++
 libsanitizer/sanitizer_common/sanitizer_linux.cc   | 40 ++
 libsanitizer/sanitizer_common/sanitizer_platform.h | 15 ++--
 .../sanitizer_platform_limits_posix.cc |  3 +-
 .../sanitizer_platform_limits_posix.h  | 13 +--
 6 files changed, 69 insertions(+), 19 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 33c90ef..eebf85b 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -16171,7 +16171,10 @@ aarch64_split_dimode_const_store (rtx dst, rtx src)
 static unsigned HOST_WIDE_INT
 aarch64_asan_shadow_offset (void)
 {
-  return (HOST_WIDE_INT_1 << 36);
+  if (TARGET_ILP32)
+return (HOST_WIDE_INT_1 << 29);
+  else
+return (HOST_WIDE_INT_1 << 36);
 }
 
 static rtx
diff --git a/libsanitizer/sanitizer_common/sanitizer_internal_defs.h 
b/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
index edd6a21..aef83c2 100644
--- a/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
+++ b/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
@@ -117,9 +117,9 @@ typedef signed   long long sptr;  // NOLINT
 typedef unsigned long uptr;  // NOLINT
 typedef signed   long sptr;  // NOLINT
 #endif  // defined(_WIN64)
-#if defined(__x86_64__)
-// Since x32 uses ILP32 data model in 64-bit hardware mode, we must use
-// 64-bit pointer to unwind stack frame.
+#if defined(__x86_64__) || SANITIZER_AARCH64_ILP32
+// Since x32 adn AArch64 ILP32 use ILP32 data model in 64-bit hardware mode, 
+// we must use 64-bit pointer to unwind stack frame.
 typedef unsigned long long uhwptr;  // NOLINT
 #else
 typedef uptr uhwptr;   // NOLINT
@@ -144,7 +144,7 @@ typedef int error_t;
 typedef int pid_t;
 
 #if SANITIZER_FREEBSD || SANITIZER_NETBSD || SANITIZER_MAC || \
-(SANITIZER_LINUX && defined(__x86_64__))
+(SANITIZER_LINUX && (defined(__x86_64__) || SANITIZER_AARCH64_ILP32))
 typedef u64 OFF_T;
 #else
 typedef uptr OFF_T;
@@ -154,8 +154,8 @@ typedef u64  OFF64_T;
 #if (SANITIZER_WORDSIZE == 64) || SANITIZER_MAC
 typedef uptr operator_new_size_type;
 #else
-# if defined(__s390__) && !defined(__s390x__)
-// Special case: 31-bit s390 has unsigned long as size_t.
+# if (defined(__s390__) && !defined(__s390x__)) || SANITIZER_AARCH64_ILP32
+// Special case: 31-bit s390 and AArch64 ILP32 have unsigned long as size_t.
 typedef unsigned long operator_new_size_type;
 # else
 typedef 

[PATCH] Fix tsan race_on_mutex.c testcase (PR80551)

[Segher Boessenkool]

The testcase did not match the glibc internal names while it should.
This fixes it.  Pre-approved by Jakub in the PR; committing.


Segher


2018-02-23  Segher Boessenkool  

gcc/testsuite/
PR testsuite/80551
* c-c++-common/tsan/race_on_mutex.c: Change regexp to allow
__GI___pthread_mutex_init as well.

---
 gcc/testsuite/c-c++-common/tsan/race_on_mutex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c 
b/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c
index def1d47..2e4b7ac 100644
--- a/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c
+++ b/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c
@@ -42,5 +42,5 @@ int main() {
 /* { dg-output "#1 Thread2.* .*(race_on_mutex.c:22|\\?{2}:0) (.*)" } */
 /* { dg-output "  Previous write of size \[0-9]\+ at .* by thread 
T1:(\n|\r\n|\r)" } */
 /* { dg-output "(#0 \[^\n\r\]*(\n|\r\n|\r))?" } */
-/* { dg-output "#\[01\] (__)?pthread_mutex_init \[^\n\r\]* (.)*" } */
+/* { dg-output "#\[01\] ((__GI_)?__)?pthread_mutex_init \[^\n\r\]* (.)*" } 
*/
 /* { dg-output "#\[12\] Thread1.* .*(race_on_mutex.c:12|\\?{2}:0) .*" } */
-- 
1.8.3.1

C++ PATCH for c++/70468, ICE with constructor delegation via typedef.

[Jason Merrill]

tsubst_initializer_list needs the same error checking as
cp_parser_mem_initializer_list.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit f51f20ad47d24aee54bfbe26f31c48e0f8a78def
Author: Jason Merrill 
Date:   Thu Feb 22 18:06:53 2018 -0500

PR c++/70468 - ICE with constructor delegation via typedef.

* pt.c (tsubst_initializer_list): Check for other mem-initializers
with constructor delegation.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index bc03f0e818e..85d1adbbe3c 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -23558,6 +23558,7 @@ static tree
 tsubst_initializer_list (tree t, tree argvec)
 {
   tree inits = NULL_TREE;
+  tree target_ctor = error_mark_node;
 
   for (; t; t = TREE_CHAIN (t))
 {
@@ -23674,6 +23675,28 @@ tsubst_initializer_list (tree t, tree argvec)
   in_base_initializer = 0;
 }
 
+ if (target_ctor != error_mark_node
+ && init != error_mark_node)
+   {
+ error ("mem-initializer for %qD follows constructor delegation",
+decl);
+ return inits;
+   }
+ /* Look for a target constructor. */
+ if (init != error_mark_node
+ && decl && CLASS_TYPE_P (decl)
+ && same_type_p (decl, current_class_type))
+   {
+ maybe_warn_cpp0x (CPP0X_DELEGATING_CTORS);
+ if (inits)
+   {
+ error ("constructor delegation follows mem-initializer for 
%qD",
+TREE_PURPOSE (inits));
+ continue;
+   }
+ target_ctor = init;
+   }
+
   if (decl)
 {
   init = build_tree_list (decl, init);
diff --git a/gcc/testsuite/g++.dg/cpp0x/dc9.C b/gcc/testsuite/g++.dg/cpp0x/dc9.C
new file mode 100644
index 000..b87f5ce618d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/dc9.C
@@ -0,0 +1,30 @@
+// PR c++/70468
+// { dg-do compile { target c++11 } }
+// { dg-additional-options -w }
+
+struct S {}; 
+
+template < typename = S > 
+class A 
+{
+public:
+  A () : f0 (), f1 () {}   // { dg-error "" }
+
+private:
+  typedef A<> f0; 
+  int f1;
+};
+
+template < typename = S, typename = S > 
+class B
+{
+}; 
+
+template < typename T1, typename T2 > 
+B < T1, T2 > << (B < T1, T2 >&, const int) 
+{
+  A<> (); 
+}
+
+template 
+B < S, S > << (B < S, S >&, const int);

[Patch, fortran] PR83148 [8 regression] ICE: crash_signal from toplev.c:325

[Paul Richard Thomas]

Committed as 'obvious' in revision 257930.

Cheers

Paul

2018-02-23  Paul Thomas  

PR fortran/83148
* trans-const.c : Clean up some whitespace issues.
* trans-expr.c (gfc_conv_initializer): If an iso_c_binding
derived type has a kind value of zero, set it to the default
integer kind.

2018-02-23  Paul Thomas  

PR fortran/83148
* gfortran.dg/class_68.f90: New test.
Index: gcc/fortran/trans-const.c
===
*** gcc/fortran/trans-const.c   (revision 257826)
--- gcc/fortran/trans-const.c   (working copy)
*** gfc_build_localized_cstring_const (const
*** 133,139 
  
  
  /* Return a string constant with the given length.  Used for static
!initializers.  The constant will be padded or truncated to match 
 length.  */
  
  tree
--- 133,139 
  
  
  /* Return a string constant with the given length.  Used for static
!initializers.  The constant will be padded or truncated to match
 length.  */
  
  tree
*** gfc_conv_constant_to_tree (gfc_expr * ex
*** 303,309 
  
/* If it is has a prescribed memory representation, we build a string
   constant and VIEW_CONVERT to its type.  */
!  
switch (expr->ts.type)
  {
  case BT_INTEGER:
--- 303,309 
  
/* If it is has a prescribed memory representation, we build a string
   constant and VIEW_CONVERT to its type.  */
! 
switch (expr->ts.type)
  {
  case BT_INTEGER:
*** gfc_conv_constant (gfc_se * se, gfc_expr
*** 389,400 
if (expr->ts.type == BT_DERIVED && expr->ts.u.derived
&& expr->ts.u.derived->attr.is_iso_c)
  {
!   if (expr->symtree->n.sym->intmod_sym_id == ISOCBINDING_NULL_PTR 
!   || expr->symtree->n.sym->intmod_sym_id == ISOCBINDING_NULL_FUNPTR)
! {
!   /* Create a new EXPR_CONSTANT expression for our local uses.  */
!   expr = gfc_get_int_expr (gfc_default_integer_kind, NULL, 0);
! }
  }
  
if (expr->expr_type != EXPR_CONSTANT)
--- 389,400 
if (expr->ts.type == BT_DERIVED && expr->ts.u.derived
&& expr->ts.u.derived->attr.is_iso_c)
  {
!   if (expr->symtree->n.sym->intmod_sym_id == ISOCBINDING_NULL_PTR
! || expr->symtree->n.sym->intmod_sym_id == ISOCBINDING_NULL_FUNPTR)
!   {
! /* Create a new EXPR_CONSTANT expression for our local uses.  */
! expr = gfc_get_int_expr (gfc_default_integer_kind, NULL, 0);
!   }
  }
  
if (expr->expr_type != EXPR_CONSTANT)
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 257826)
--- gcc/fortran/trans-expr.c(working copy)
*** gfc_conv_initializer (gfc_expr * expr, g
*** 6868,6873 
--- 6868,6875 
  
/* The derived symbol has already been converted to a (void *).  Use
 its kind.  */
+   if (derived->ts.kind == 0)
+   derived->ts.kind = gfc_default_integer_kind;
expr = gfc_get_int_expr (derived->ts.kind, NULL, 0);
expr->ts.f90_type = derived->ts.f90_type;
  
Index: gcc/testsuite/gfortran.dg/class_68.f90
===
*** gcc/testsuite/gfortran.dg/class_68.f90  (nonexistent)
--- gcc/testsuite/gfortran.dg/class_68.f90  (working copy)
***
*** 0 
--- 1,25 
+ ! { dg-do compile }
+ !
+ ! Test the fix for PR83148.
+ !
+ ! Contributed by Neil Carlson  
+ !
+ module fhypre
+   use iso_c_binding, only: c_ptr, c_null_ptr
+   use iso_c_binding, only: hypre_obj => c_ptr, hypre_null_obj => c_null_ptr
+   private
+   public :: hypre_obj, hypre_null_obj
+ end module
+ 
+ module hypre_hybrid_type
+   use fhypre
+   type hypre_hybrid
+ type(hypre_obj) :: solver = hypre_null_obj
+   end type hypre_hybrid
+ end module
+ 
+   use hypre_hybrid_type
+   class(hypre_hybrid), allocatable :: x
+   allocate (x)
+ end
+ 

Re: [Patch AArch64] Turn on frame pointer / partial fix for PR84521

[James Greenhalgh]

On Fri, Feb 23, 2018 at 11:32:57AM +, Ramana Radhakrishnan wrote:
> This fixes a GCC-8 regression that we accidentally switched off frame
> pointers in the AArch64 backend when changing the defaults in the common
> parts of the code. This breaks an ABI decision that was made in GCC at
> the dawn of the port with respect to having a frame pointer at all
> times.  If we really want to turn this off lets have a discussion around
> that separately.
> 
> For now turn this back on and I believe this will leave PR84521 latent
> again with -fomit-frame-pointer and (hopefully) make the ruby issue go
> away. I'm asking Sudi to pick that up.
> 
> Bootstrapped and regression tested on AArch64-none-linux-gnu but I see
> one regression in gcc.c-torture/execute/960419-2.c which needs to be
> looked at next (PR84528, thanks Kyrill).
> 
> Ok to put in and then look at PR84528 ?

OK.

Are your testsuite chanmges just the revert of r254814, your ChangeLog
should reflect that.

Thanks,
James

> 
> gcc/ChangeLog:
> 
> 2018-02-23  Ramana Radhakrishnan  
> 
> PR target/84521
>   * common/config/aarch64/aarch64-common.c
> (aarch_option_optimization_table[]): Switch
> off fomit-frame-pointer
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-02-23  Ramana Radhakrishnan  
> 
>   * gcc.target/aarch64/lr_free_2.c: Adjust test.
>   * gcc.target/aarch64/spill_1.c: Likewise.
>   * gcc.target/aarch64/test_frame_11.c: Likewise.
>   * gcc.target/aarch64/test_frame_12.c: Likewise.
>   * gcc.target/aarch64/test_frame_13.c: Likewise.
>   * gcc.target/aarch64/test_frame_14.c: Likewise.
>   * gcc.target/aarch64/test_frame_15.c: Likewise.
>   * gcc.target/aarch64/test_frame_3.c: Likewise.
>   * gcc.target/aarch64/test_frame_5.c: Likewise.
>   * gcc.target/aarch64/test_frame_9.c: Likewise.

[Patch AArch64] Turn on frame pointer / partial fix for PR84521

[Ramana Radhakrishnan]

This fixes a GCC-8 regression that we accidentally switched off frame
pointers in the AArch64 backend when changing the defaults in the common
parts of the code. This breaks an ABI decision that was made in GCC at
the dawn of the port with respect to having a frame pointer at all
times.  If we really want to turn this off lets have a discussion around
that separately.

For now turn this back on and I believe this will leave PR84521 latent
again with -fomit-frame-pointer and (hopefully) make the ruby issue go
away. I'm asking Sudi to pick that up.

Bootstrapped and regression tested on AArch64-none-linux-gnu but I see
one regression in gcc.c-torture/execute/960419-2.c which needs to be
looked at next (PR84528, thanks Kyrill).

Ok to put in and then look at PR84528 ?

gcc/ChangeLog:

2018-02-23  Ramana Radhakrishnan  

PR target/84521
* common/config/aarch64/aarch64-common.c
(aarch_option_optimization_table[]): Switch
off fomit-frame-pointer

gcc/testsuite/ChangeLog:

2018-02-23  Ramana Radhakrishnan  

* gcc.target/aarch64/lr_free_2.c: Adjust test.
* gcc.target/aarch64/spill_1.c: Likewise.
* gcc.target/aarch64/test_frame_11.c: Likewise.
* gcc.target/aarch64/test_frame_12.c: Likewise.
* gcc.target/aarch64/test_frame_13.c: Likewise.
* gcc.target/aarch64/test_frame_14.c: Likewise.
* gcc.target/aarch64/test_frame_15.c: Likewise.
* gcc.target/aarch64/test_frame_3.c: Likewise.
* gcc.target/aarch64/test_frame_5.c: Likewise.
* gcc.target/aarch64/test_frame_9.c: Likewise.
diff --git a/gcc/common/config/aarch64/aarch64-common.c 
b/gcc/common/config/aarch64/aarch64-common.c
index 71d395398c7..7fd93050037 100644
--- a/gcc/common/config/aarch64/aarch64-common.c
+++ b/gcc/common/config/aarch64/aarch64-common.c
@@ -47,6 +47,8 @@ static const struct default_options 
aarch_option_optimization_table[] =
   {
 /* Enable section anchors by default at -O1 or higher.  */
 { OPT_LEVELS_1_PLUS, OPT_fsection_anchors, NULL, 1 },
+/* Disable fomit-frame-pointer by default.  */
+{ OPT_LEVELS_ALL, OPT_fomit_frame_pointer, NULL, 0 },
 /* Enable -fsched-pressure by default when optimizing.  */
 { OPT_LEVELS_1_PLUS, OPT_fsched_pressure, NULL, 1 },
 /* Enable redundant extension instructions removal at -O2 and higher.  */
diff --git a/gcc/testsuite/gcc.target/aarch64/lr_free_2.c 
b/gcc/testsuite/gcc.target/aarch64/lr_free_2.c
index 5d9500f4fb1..e2b9490fab1 100644
--- a/gcc/testsuite/gcc.target/aarch64/lr_free_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/lr_free_2.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-options "-fno-omit-frame-pointer -fno-inline -O2 -ffixed-x2 -ffixed-x3 
-ffixed-x4 -ffixed-x5 -ffixed-x6 -ffixed-x7 -ffixed-x8 -ffixed-x9 -ffixed-x10 
-ffixed-x11 -ffixed-x12 -ffixed-x13 -ffixed-x14 -ffixed-x15 -ffixed-x16 
-ffixed-x17 -ffixed-x18 -ffixed-x19 -ffixed-x20 -ffixed-x21 -ffixed-x22 
-ffixed-x23 -ffixed-x24 -ffixed-x25 -ffixed-x26 -ffixed-x27 -ffixed-x28 
--save-temps -mgeneral-regs-only -fno-ipa-cp -fdump-rtl-ira" } */
+/* { dg-options "-fno-inline -O2 -ffixed-x2 -ffixed-x3 -ffixed-x4 -ffixed-x5 
-ffixed-x6 -ffixed-x7 -ffixed-x8 -ffixed-x9 -ffixed-x10 -ffixed-x11 -ffixed-x12 
-ffixed-x13 -ffixed-x14 -ffixed-x15 -ffixed-x16 -ffixed-x17 -ffixed-x18 
-ffixed-x19 -ffixed-x20 -ffixed-x21 -ffixed-x22 -ffixed-x23 -ffixed-x24 
-ffixed-x25 -ffixed-x26 -ffixed-x27 -ffixed-x28 --save-temps 
-mgeneral-regs-only -fno-ipa-cp -fdump-rtl-ira" } */
 
 extern void abort ();
 
diff --git a/gcc/testsuite/gcc.target/aarch64/spill_1.c 
b/gcc/testsuite/gcc.target/aarch64/spill_1.c
index c9528cb21da..847425895d4 100644
--- a/gcc/testsuite/gcc.target/aarch64/spill_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/spill_1.c
@@ -14,3 +14,5 @@ foo (void)
 }
 
 /* { dg-final { scan-assembler-times {\tmovi\tv[0-9]+\.4s,} 2 } } */
+/* { dg-final { scan-assembler-not {\tldr\t} } } */
+/* { dg-final { scan-assembler-not {\tstr\t} } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_11.c 
b/gcc/testsuite/gcc.target/aarch64/test_frame_11.c
index 67f858260d9..f162cc091e0 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_11.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_11.c
@@ -5,7 +5,7 @@
  * optimized code should use "stp !" for stack adjustment.  */
 
 /* { dg-do run } */
-/* { dg-options "-fno-omit-frame-pointer -O2 --save-temps" } */
+/* { dg-options "-O2 --save-temps" } */
 
 #include "test_frame_common.h"
 
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_12.c 
b/gcc/testsuite/gcc.target/aarch64/test_frame_12.c
index 02e48b4acac..62761e7ff9b 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_12.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_12.c
@@ -4,7 +4,7 @@
  * number of callee-save reg >= 2.  */
 
 /* { dg-do run } */
-/* { dg-options "-O2 -fomit-frame-pointer --save-temps" } */
+/* { dg-options "-O2 --save-temps" } */
 
 

Re: [PATCH] PR 84519 Handle optional QUIET specifier for STOP and ERROR STOP

[Janne Blomqvist]

On Thu, Feb 22, 2018 at 10:16 PM, Steve Kargl
 wrote:
> On Thu, Feb 22, 2018 at 09:42:02PM +0200, Janne Blomqvist wrote:
>> Fortran 2018 adds a new QUIET specifier for the STOP and ERROR STOP
>> statements, in order to suppress the printing of signaling FP
>> exceptions and the stop code. This patch adds the necessary library
>> changes, but for now the new specifier is not parsed and the frontend
>> unconditionally adds a false value for the new argument.
>>
>> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
>>
>
> OK.

Thanks. Committed as r257928.

The corresponding OpenCoarrays pull request is
https://github.com/sourceryinstitute/OpenCoarrays/pull/510


-- 
Janne Blomqvist