Re: [Aarch64] PR target/83009: Relax strict address checking for store pair lanes

[James Greenhalgh]

> On 8 May 2018, at 02:58, Andre Vieira (lists) 
>  wrote:
> 
> Hi Richard,
>> On 07/05/18 11:14, Richard Sandiford wrote:
>> "Andre Vieira (lists)"  writes:
>>> Hi,
>>> 
>>> See below a patch to address PR 83009.
>>> 
>>> Tested with aarch64-linux-gnu bootstrap and regtests for c, c++ and fortran.
>>> Ran the adjusted testcase for -mabi=ilp32.
>>> 
>>> Is this OK for gcc-9?
>>> 
>>> Cheers,
>>> Andre
>>> 
>>> PR target/83009: Relax strict address checking for store pair lanes
>>> 
>>> The operand constraint for the memory address of store/load pair lanes
>>> was enforcing strictly hardware registers be allowed as memory
>>> addresses.  We want to relax that such that these patterns can be used
>>> by combine.  During register allocation the register constraint will
>>> enforce the correct register is chosen.
>> 
>> Nice spot.
>> 
>>> diff --git a/gcc/config/aarch64/predicates.md 
>>> b/gcc/config/aarch64/predicates.md
>>> index 
>>> 5d41d4350402b2a9e5941f160c6ab6f933bfff90..f29bc8e74f0070589014ac87fd22a95723ba9be8
>>>  100644
>>> --- a/gcc/config/aarch64/predicates.md
>>> +++ b/gcc/config/aarch64/predicates.md
>>> @@ -222,7 +222,7 @@
>>> ;; as a 128-bit vec_concat.
>>> (define_predicate "aarch64_mem_pair_lanes_operand"
>>>   (and (match_code "mem")
>>> -   (match_test "aarch64_legitimate_address_p (DFmode, XEXP (op, 0), 1,
>>> +   (match_test "aarch64_legitimate_address_p (DFmode, XEXP (op, 0), 0,
>>>  ADDR_QUERY_LDP_STP)")))
>>> 
>>> (define_predicate "aarch64_prefetch_operand"
>> 
>> Very minor, but it'd be good to change it to a real bool parameter
>> at the same time, for consistency with aarch64_mem_pair_operand.
>> (Patch LGTM otherwise FWIW.)
>> 
> Good shout! Thank you. Attached new version.

I’m happy to take Richard’s review here. The patch looks good to me.

Ok for trunk,

Thanks,
James

(Trying a mobile mail client, apologies if this bounces)

[PATCH] Fix std::codecvt_utf8 for Mingw

[Jonathan Wakely]

While testing a series of patches to add Mingw support for
std::filesystem I discovered that codecvt_utf8 was producing
wchar_t values with the wrong endianness. This fixes it.

* src/c++11/codecvt.cc (__codecvt_utf8_base::do_in)
[__SIZEOF_WCHAR_T__==2 && __BYTE_ORDER__!=__ORDER_BIG_ENDIAN__]: Set
little_endian element in bitmask.
* testsuite/22_locale/codecvt/codecvt_utf8/69703.cc: Run all tests.
* testsuite/22_locale/codecvt/codecvt_utf8/wchar_t/1.cc: New.

Tested powerpc64le-linux and x86_64-w64-mingw32, committed to trunk.

I think I'll backport this too, as it only affects Mingw.


commit b4404efe99cb8690d6ef3edd3ae42fa86b543ef2
Author: Jonathan Wakely 
Date:   Sat May 19 02:30:36 2018 +0100

Fix std::codecvt_utf8 for Mingw

* src/c++11/codecvt.cc (__codecvt_utf8_base::do_in)
[__SIZEOF_WCHAR_T__==2 && __BYTE_ORDER__!=__ORDER_BIG_ENDIAN__]: Set
little_endian element in bitmask.
* testsuite/22_locale/codecvt/codecvt_utf8/69703.cc: Run all tests.
* testsuite/22_locale/codecvt/codecvt_utf8/wchar_t/1.cc: New.

diff --git a/libstdc++-v3/src/c++11/codecvt.cc 
b/libstdc++-v3/src/c++11/codecvt.cc
index 259de807758..3a1a825070c 100644
--- a/libstdc++-v3/src/c++11/codecvt.cc
+++ b/libstdc++-v3/src/c++11/codecvt.cc
@@ -1086,7 +1086,12 @@ do_in(state_type&, const extern_type* __from, const 
extern_type* __from_end,
 reinterpret_cast(__to),
 reinterpret_cast(__to_end)
   };
-  auto res = ucs2_in(from, to, _M_maxcode, _M_mode);
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+  codecvt_mode mode = {};
+#else
+  codecvt_mode mode = little_endian;
+#endif
+  auto res = ucs2_in(from, to, _M_maxcode, mode);
 #elif __SIZEOF_WCHAR_T__ == 4
   range to{
 reinterpret_cast(__to),
diff --git a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8/69703.cc 
b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8/69703.cc
index 36f18a59947..56872267d1b 100644
--- a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8/69703.cc
+++ b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8/69703.cc
@@ -68,7 +68,6 @@ test03()
   VERIFY( in[2] == U'c' );
 }
 
-
 void
 test04()
 {
@@ -90,6 +89,6 @@ main()
 {
   test01();
   test02();
-  test01();
-  test02();
+  test03();
+  test04();
 }
diff --git a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8/wchar_t/1.cc 
b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8/wchar_t/1.cc
new file mode 100644
index 000..c44f91f357e
--- /dev/null
+++ b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8/wchar_t/1.cc
@@ -0,0 +1,52 @@
+// 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
+// .
+
+// { dg-do run { target c++11 } }
+
+#include 
+#include 
+#include 
+
+void
+test01()
+{
+  const char out[] = u8"\u00A33.50";
+  wchar_t in[8] = {};
+  std::codecvt_utf8 cvt;
+  std::mbstate_t st;
+  const char* no;
+  wchar_t* ni;
+  auto res = cvt.in(st, out, out+6, no, in, in+8, ni);
+  VERIFY( res == std::codecvt_base::ok );
+  VERIFY( in[1] == L'3' );
+  VERIFY( in[2] == L'.' );
+  VERIFY( in[3] == L'5' );
+  VERIFY( in[4] == L'0' );
+
+  char out2[8] = {};
+  char* no2;
+  const wchar_t* ni2;
+  res = cvt.out(st, in, ni, ni2, out2, out2+8, no2);
+  VERIFY( res == std::codecvt_base::ok );
+  VERIFY( out2 == std::string(out) );
+}
+
+int
+main()
+{
+  test01();
+}

Re: Rb_tree constructor optimization

[Jonathan Wakely]

On 17/05/18 16:10 +0100, Jonathan Wakely wrote:

On 15/05/18 07:30 +0200, François Dumont wrote:
Here it is again even more simplified. Should I backport the Debug 
mode fix to 8 branch ?


Yes, please do backport the include/debug/* changes.



    * include/bits/stl_tree.h
    (_Rb_tree_impl(_Rb_tree_impl&&, _Node_allocator&&)): New.
    (_Rb_tree(_Rb_tree&&, _Node_allocator&&, true_type)): New, use latter.
    (_Rb_tree(_Rb_tree&&, _Node_allocator&&, false_type)): New.
    (_Rb_tree(_Rb_tree&&, _Node_allocator&&)): Adapt, use latters.
    * include/debug/map.h
    (map(map&&, const_allocator_type&)): Add noexcept qualitication.
    * include/debug/multimap.h
    (multimap(multimap&&, const_allocator_type&)): Add noexcept 
qualification.

    * include/debug/set.h
    (set(set&&, const_allocator_type&)): Add noexcept qualitication.
    * include/debug/multiset.h
    (multiset(multiset&&, const_allocator_type&)): Add noexcept 
qualification.

    * testsuite/23_containers/map/cons/noexcept_default_construct.cc:
    Add checks.
    * testsuite/23_containers/map/cons/noexcept_move_construct.cc:
    Add checks.
    * testsuite/23_containers/multimap/cons/noexcept_default_construct.cc:
    Add checks.
    * testsuite/23_containers/multimap/cons/noexcept_move_construct.cc:
    Add checks.
    * testsuite/23_containers/multiset/cons/noexcept_default_construct.cc:
    Add checks.
    * testsuite/23_containers/multiset/cons/noexcept_move_construct.cc:
    Add checks.
    * testsuite/23_containers/set/cons/noexcept_default_construct.cc:
    Add checks.
    * testsuite/23_containers/set/cons/noexcept_move_construct.cc:
    Add checks.

Ok to commit ?


Yes, OK for trunk - thanks.




I'm seeing lots of new testsuite failures after this commit, see
https://gcc.gnu.org/ml/gcc-testresults/2018-05/msg02025.html

Re: [PATCH][AArch64] Implement usadv16qi and ssadv16qi standard names

[James Greenhalgh]

On Mon, May 14, 2018 at 08:38:40AM -0500, Kyrill Tkachov wrote:
> Hi all,
> 
> This patch implements the usadv16qi and ssadv16qi standard names.
> See the thread at on g...@gcc.gnu.org [1] for background.
> 
> The V16QImode variant is important to get right as it is the most commonly 
> used pattern:
> reducing vectors of bytes into an int.
> The midend expects the optab to compute the absolute differences of operands 
> 1 and 2 and
> reduce them while widening along the way up to SImode. So the inputs are 
> V16QImode and
> the output is V4SImode.
> 
> I've tried out a few different strategies for that, the one I settled with is 
> to emit:
> UABDL2tmp.8h, op1.16b, op2.16b
> UABALtmp.8h, op1.16b, op2.16b
> UADALPop3.4s, tmp.8h
> 
> To work through the semantics let's say operands 1 and 2 are:
> op1 { a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13, a14, a15 }
> op2 { b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10, b11, b12, b13, b14, b15 }
> op3 { c0, c1, c2, c3 }
> 
> The UABDL2 takes the upper V8QI elements, computes their absolute 
> differences, widens them and stores them into the V8HImode tmp:
> 
> tmp { ABS(a[8]-b[8]), ABS(a[9]-b[9]), ABS(a[10]-b[10]), ABS(a[11]-b[11]), 
> ABS(a[12]-b[12]), ABS(a[13]-b[13]), ABS(a[14]-b[14]), ABS(a[15]-b[15]) }
> 
> The UABAL after that takes the lower V8QI elements, computes their absolute 
> differences, widens them and accumulates them into the V8HImode tmp from the 
> previous step:
> 
> tmp { ABS(a[8]-b[8])+ABS (a[0]-b[0]), ABS(a[9]-b[9])+ABS(a[1]-b[1]), 
> ABS(a[10]-b[10])+ABS(a[2]-b[2]), ABS(a[11]-b[11])+ABS(a[3]-b[3]), 
> ABS(a[12]-b[12])+ABS(a[4]-b[4]), ABS(a[13]-b[13])+ABS(a[5]-b[5]), 
> ABS(a[14]-b[14])+ABS(a[6]-b[6]), ABS(a[15]-b[15])+ABS(a[7]-b[7]) }
> 
> Finally the UADALP does a pairwise widening reduction and accumulation into 
> the V4SImode op3:
> op3 { c0+ABS(a[8]-b[8])+ABS(a[0]-b[0])+ABS(a[9]-b[9])+ABS(a[1]-b[1]), 
> c1+ABS(a[10]-b[10])+ABS(a[2]-b[2])+ABS(a[11]-b[11])+ABS(a[3]-b[3]), 
> c2+ABS(a[12]-b[12])+ABS(a[4]-b[4])+ABS(a[13]-b[13])+ABS(a[5]-b[5]), 
> c3+ABS(a[14]-b[14])+ABS(a[6]-b[6])+ABS(a[15]-b[15])+ABS(a[7]-b[7]) }
> 
> (sorry for the text dump)
> 
> Remember, according to [1] the exact reduction sequence doesn't matter (for 
> integer arithmetic at least).
> I've considered other sequences as well (thanks Wilco), for example
> * UABD + UADDLP + UADALP
> * UABLD2 + UABDL + UADALP + UADALP
> 
> I ended up settling in the sequence in this patch as it's short (3 
> instructions) and in the future we can potentially
> look to optimise multiple occurrences of these into something even faster 
> (for example accumulating into H registers for longer
> before doing a single UADALP in the end to accumulate into the final S 
> register).
> 
> If your microarchitecture has some some strong preferences for a particular 
> sequence, please let me know or, even better, propose a patch
> to parametrise the generation sequence by code (or the appropriate RTX cost).
> 
> 
> This expansion allows the vectoriser to avoid unpacking the bytes in two 
> steps and performing V4SI arithmetic on them.
> So, for the code:
> 
> unsigned char pix1[N], pix2[N];
> 
> int foo (void)
> {
>int i_sum = 0;
>int i;
> 
>for (i = 0; i < 16; i++)
>  i_sum += __builtin_abs (pix1[i] - pix2[i]);
> 
>return i_sum;
> }
> 
> we now generate on aarch64:
> foo:
>  adrpx1, pix1
>  add x1, x1, :lo12:pix1
>  moviv0.4s, 0
>  adrpx0, pix2
>  add x0, x0, :lo12:pix2
>  ldr q2, [x1]
>  ldr q3, [x0]
>  uabdl2  v1.8h, v2.16b, v3.16b
>  uabal   v1.8h, v2.8b, v3.8b
>  uadalp  v0.4s, v1.8h
>  addvs0, v0.4s
>  umovw0, v0.s[0]
>  ret
> 
> 
> instead of:
> foo:
>  adrpx1, pix1
>  adrpx0, pix2
>  add x1, x1, :lo12:pix1
>  add x0, x0, :lo12:pix2
>  ldr q0, [x1]
>  ldr q4, [x0]
>  ushll   v1.8h, v0.8b, 0
>  ushll2  v0.8h, v0.16b, 0
>  ushll   v2.8h, v4.8b, 0
>  ushll2  v4.8h, v4.16b, 0
>  usubl   v3.4s, v1.4h, v2.4h
>  usubl2  v1.4s, v1.8h, v2.8h
>  usubl   v2.4s, v0.4h, v4.4h
>  usubl2  v0.4s, v0.8h, v4.8h
>  abs v3.4s, v3.4s
>  abs v1.4s, v1.4s
>  abs v2.4s, v2.4s
>  abs v0.4s, v0.4s
>  add v1.4s, v3.4s, v1.4s
>  add v1.4s, v2.4s, v1.4s
>  add v0.4s, v0.4s, v1.4s
>  addvs0, v0.4s
>  umovw0, v0.s[0]
>  ret
> 
> So I expect this new expansion to be better than the status quo in any case.
> Bootstrapped and tested on aarch64-none-linux-gnu.
> This gives about 8% on 525.x264_r from SPEC2017 on a Cortex-A72.
> 
> Ok for trunk?

You don't say it explicitly here, but I presume the mid-end takes care of
zeroing the accumulator register before the loop (i.e. op3 in your sequence
in 

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

[Paolo Carlini]

Hi,

On 19/05/2018 01:40, Jason Merrill wrote:

On Fri, May 18, 2018 at 1:40 PM, Paolo Carlini  wrote:

Hi again,

I'm playing with a wild, wild idea: would it make sense to try *first* an
expression? Because, a quickly hacked draft appears to handle very elegantly
all the possible cases of "junk" after the declarator, eg:

 void foo()
 {
 if (void bar()JUNK);
  }

and the parenthesized case, etc, etc. Before trying to seriously work on
that I wanted to ask...

We'd need to try parsing as a declaration whether or not parsing as an
expression works, since any ambiguous cases are treated as
declarations [stmt.ambig].
Yeah, that complicates the implementation of my idea. However, I'm 
thinking that at least *in the specific case of cp_parse_condition* from 
the computational complexity point of view probably we wouldn't regress 
much, because declarations are rare anyway, thus in most of the cases we 
end up doing both anyway. If we do expressions first and we save the 
result, then I believe when we can handle the declarator as something 
which cannot be a function or an array even if we don't see the 
initializer much more easily, we easily have a better diagnostic for 
things like


    if (int x);

(another case we currently handle pretty badly, we don't talk about the 
missing initializer at all!), we cope elegantly with any junk following 
the wrong function/array declaration, etc. See that attached, if you are 
curious, which essentially passes the testsuite modulo a nit (*) which 
doesn't have anything to do with [stmt.ambig] per se (which of course is 
*not* correctly implemented in the wip).


Can you give me your opinion about the more detailed idea, in particular 
whether we already have good infrastructure to implement [stmt.ambig] in 
this context, thus to keep the first parsing as an expression around, 
possibly returning to it if the parsing as a declaration fails??


I hope I'm making sense, it's again late here... in any case the wip 
patch I did much earlier today ;)


Paolo.

(*) Has to do with David's access failure hint not handling deferred 
access checks (accessor-fixits-6.C).
Index: parser.c
===
--- parser.c(revision 260347)
+++ parser.c(working copy)
@@ -11527,6 +11527,33 @@ cp_parser_selection_statement (cp_parser* parser,
 }
 }
 
+/* Helper function for cp_parser_condition.  Enforces [stmt.stmt]/2:
+   The declarator shall not specify a function or an array.  Returns
+   TRUE if the declarator is valid, FALSE otherwise.  */
+
+static bool
+cp_parser_check_condition_declarator (cp_parser* parser,
+ cp_declarator *declarator,
+ location_t loc)
+{
+  if (function_declarator_p (declarator)
+  || declarator->kind == cdk_array)
+{
+  if (declarator->kind == cdk_array)
+   error_at (loc, "condition declares an array");
+  else
+   error_at (loc, "condition declares a function");
+  if (parser->fully_implicit_function_template_p)
+   abort_fully_implicit_template (parser);
+  cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
+/*or_comma=*/false,
+/*consume_paren=*/false);
+  return false;
+}
+  else
+return true;
+}
+
 /* Parse a condition.
 
condition:
@@ -11545,12 +11572,20 @@ cp_parser_selection_statement (cp_parser* parser,
 static tree
 cp_parser_condition (cp_parser* parser)
 {
+  cp_parser_parse_tentatively (parser);
+
+  /* Try the expression first.  */
+  tree expr = cp_parser_expression (parser);
+
+  if (cp_parser_parse_definitely (parser))
+return expr;
+
+  cp_parser_parse_tentatively (parser);
+
   cp_decl_specifier_seq type_specifiers;
   const char *saved_message;
   int declares_class_or_enum;
 
-  /* Try the declaration first.  */
-  cp_parser_parse_tentatively (parser);
   /* New types are not allowed in the type-specifier-seq for a
  condition.  */
   saved_message = parser->type_definition_forbidden_message;
@@ -11563,6 +11598,7 @@ cp_parser_condition (cp_parser* parser)
_class_or_enum);
   /* Restore the saved message.  */
   parser->type_definition_forbidden_message = saved_message;
+
   /* If all is well, we might be looking at a declaration.  */
   if (!cp_parser_error_occurred (parser))
 {
@@ -11570,7 +11606,8 @@ cp_parser_condition (cp_parser* parser)
   tree asm_specification;
   tree attributes;
   cp_declarator *declarator;
-  tree initializer = NULL_TREE;
+  tree initializer;
+  location_t loc = cp_lexer_peek_token (parser->lexer)->location;
 
   /* Parse the declarator.  */
   declarator = cp_parser_declarator (parser, CP_PARSER_DECLARATOR_NAMED,
@@ -11582,19 +11619,7 @@ cp_parser_condition (cp_parser* parser)
   attributes = 

[PATCH] correct/improve handling of -Walloc-size-larger-than (PR 82063)

[Martin Sebor]

The -Walloc-size-larger-than= option is supposed make it possible
to disable the warning by specifying a limit that's larger than
the default of PTRDIFF_MAX (the handler for the option argument
gets around the INT_MAX maximum for numeric arguments by accepting
suffixes like MB or GB).  Unfortunately, a silly typo in the handler
prevents this from working correctly, and because there is no
-Wno-alloc-size-larger-than option it's impossible to suppress
unwanted instances of this warning.

The attached patch removes these shortcomings by:

1) fixing the typo,
2) letting the argument handler accept excessively large arguments
   (> ULLONG_MAX) and treat them as infinite,
3) adding -Wno-alloc-size-larger-than option to disable the warning

The patch also issues a warning for invalid arguments (they either
reset the limit to zero or leave it at PTRDIFF_MAX otherwise).

I'm looking for approval to commit this patch to trunk and all
release branches that support the option (8 and 7).

For trunk, as the next step, I'd like to generalize the argument
handler and move it where other similar options (for example,
-Wlarger-than, -Walloca-larger-than, -Wframe-larger-than, and
-Wstack-usage) can make use of it.

Martin
PR c/82063 - issues with arguments enabled by -Wall

gcc/c-family/ChangeLog:

	PR c/82063
	* c.opt (-Wno-alloc-size-larger-than): New option.

gcc/ChangeLog:

	PR c/82063
	* calls.c (alloc_max_size): Correct a logic error/typo.
	Treat excessive arguments as infinite.  Warn for invalid arguments.

gcc/testsuite/ChangeLog:

	PR c/82063
	* gcc.dg/Walloc-size-larger-than-1.c: New test.
	* gcc.dg/Walloc-size-larger-than-10.c: New test.
	* gcc.dg/Walloc-size-larger-than-11.c: New test.
	* gcc.dg/Walloc-size-larger-than-12.c: New test.
	* gcc.dg/Walloc-size-larger-than-13.c: New test.
	* gcc.dg/Walloc-size-larger-than-14.c: New test.
	* gcc.dg/Walloc-size-larger-than-15.c: New test.
	* gcc.dg/Walloc-size-larger-than-16.c: New test.
	* gcc.dg/Walloc-size-larger-than-17.c: New test.
	* gcc.dg/Walloc-size-larger-than-2.c: New test.
	* gcc.dg/Walloc-size-larger-than-3.c: New test.
	* gcc.dg/Walloc-size-larger-than-4.c: New test.
	* gcc.dg/Walloc-size-larger-than-5.c: New test.
	* gcc.dg/Walloc-size-larger-than-6.c: New test.
	* gcc.dg/Walloc-size-larger-than-7.c: New test.
	* gcc.dg/Walloc-size-larger-than-8.c: New test.
	* gcc.dg/Walloc-size-larger-than-9.c: New test.
	* gcc.dg/Walloc-size-larger-than.c: New test.

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index c48d6dc..99b0326 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -308,6 +308,10 @@ C ObjC C++ LTO ObjC++ Var(warn_alloc_size_limit) Warning Joined LangEnabledBy(C
 -Walloc-size-larger-than= Warn for calls to allocation functions that
 attempt to allocate objects larger than the specified number of bytes.
 
+Wno-alloc-size-larger-than
+C ObjC C++ LTO ObjC++ Alias(Walloc-size-larger-than=, 18446744073709551615EiB,none) Warning
+-Wno-alloc-size-larger-than Disable Walloc-size-larger-than= warning.  Equivalent to Walloc-size-larger-than= or larger.
+
 Walloc-zero
 C ObjC C++ ObjC++ Var(warn_alloc_zero) Warning
 -Walloc-zero Warn for calls to allocation functions that specify zero bytes.
diff --git a/gcc/calls.c b/gcc/calls.c
index f0e9d3b..e00d647 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1230,65 +1230,81 @@ static GTY(()) tree alloc_object_size_limit;
 static tree
 alloc_max_size (void)
 {
-  if (!alloc_object_size_limit)
-{
-  alloc_object_size_limit = max_object_size ();
+  if (alloc_object_size_limit)
+return alloc_object_size_limit;
 
-  if (warn_alloc_size_limit)
-	{
-	  char *end = NULL;
-	  errno = 0;
-	  unsigned HOST_WIDE_INT unit = 1;
-	  unsigned HOST_WIDE_INT limit
-	= strtoull (warn_alloc_size_limit, , 10);
+  alloc_object_size_limit = max_object_size ();
 
-	  if (!errno)
-	{
-	  if (end && *end)
-		{
-		  /* Numeric option arguments are at most INT_MAX.  Make it
-		 possible to specify a larger value by accepting common
-		 suffixes.  */
-		  if (!strcmp (end, "kB"))
-		unit = 1000;
-		  else if (!strcasecmp (end, "KiB") || strcmp (end, "KB"))
-		unit = 1024;
-		  else if (!strcmp (end, "MB"))
-		unit = HOST_WIDE_INT_UC (1000) * 1000;
-		  else if (!strcasecmp (end, "MiB"))
-		unit = HOST_WIDE_INT_UC (1024) * 1024;
-		  else if (!strcasecmp (end, "GB"))
-		unit = HOST_WIDE_INT_UC (1000) * 1000 * 1000;
-		  else if (!strcasecmp (end, "GiB"))
-		unit = HOST_WIDE_INT_UC (1024) * 1024 * 1024;
-		  else if (!strcasecmp (end, "TB"))
-		unit = HOST_WIDE_INT_UC (1000) * 1000 * 1000 * 1000;
-		  else if (!strcasecmp (end, "TiB"))
-		unit = HOST_WIDE_INT_UC (1024) * 1024 * 1024 * 1024;
-		  else if (!strcasecmp (end, "PB"))
-		unit = HOST_WIDE_INT_UC (1000) * 1000 * 1000 * 1000 * 1000;
-		  else if (!strcasecmp (end, "PiB"))
-		unit = HOST_WIDE_INT_UC (1024) * 1024 * 1024 * 1024 * 1024;
-		  else if (!strcasecmp (end, "EB"))
-		unit = 

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

[Jason Merrill]

On Fri, May 18, 2018 at 1:40 PM, Paolo Carlini  wrote:
> Hi again,
>
> I'm playing with a wild, wild idea: would it make sense to try *first* an
> expression? Because, a quickly hacked draft appears to handle very elegantly
> all the possible cases of "junk" after the declarator, eg:
>
> void foo()
> {
> if (void bar()JUNK);
>  }
>
> and the parenthesized case, etc, etc. Before trying to seriously work on
> that I wanted to ask...

We'd need to try parsing as a declaration whether or not parsing as an
expression works, since any ambiguous cases are treated as
declarations [stmt.ambig].

Jason

Re: [PATCH] Make __ibm128 a distinct type, patch 2 of 2 (PR 85657)

[Michael Meissner]

Here is patch 2 of 2 to make __ibm128 a distinct type.  This patch makes the
long double pack and unpack builtins only work if the long double type is IBM
extended double.  It adds two new builtins to pack and unpack __ibm128 types.

This has been tested on a little endian power8 system with bootstrap and
regression test (with the previous patch also applied).  Can I check this into
the trunk and the GCC 8 branch?

[gcc]
2018-05-18  Michael Meissner  

PR target/85657
* config/rs6000/rs6000-builtin.def (BU_IBM128_2): New helper macro
for __builtin_{,un}pack_ibm128.
(PACK_IF): Declare __builtin_{,un}pack_ibm128.
(UNPACK_IF): Likewise.
* config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): The mask
for long double builtins (RS6000_BTM_LDBL128) requires that long
double is IBM extended double.
(rs6000_invalid_builtin): Add a new error message if the long
double {,un}pack builtins are used when long double is IEEE
128-bit floating point.
* config/rs6000/rs6000.h (RS6000_BTM_LDBL128): Update comment.
* doc/extend.texi (PowerPC builtins): Update documention for
__builtin_{,un}pack_longdouble.  Add documentation for
__builtin_{,un}pack_ibm128.

[gcc/testsuite]
2018-05-18  Michael Meissner  

PR target/85657
* gcc.target/powerpc/pr85657-4.c: New tests for pack/unpack
__ibm128 builtin functions, and whether an appropriate error
message is generate if the long double pack/unpack are used when
long double is IEEE 128.
* gcc.target/powerpc/pr85657-5.c: Likewise.
* gcc.target/powerpc/pr85657-6.c: Likewise.


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] RISC-V: Add RV32E support.

[Jim Wilson]

This adds support for -march=rv32e and -mabi=ilp32e.  This is mostly the work
of Kito Cheng and Monk Chiang.  I forward ported the patch to current sources,
which needed a few fixes.  I fixed the mask clearing/setting so that using
multiple -march/-mabi options works right.  I added some docs for the new
options.

This was tested with binutils/gcc builds and make checks, both with and without
the RV32E support enabled.  There were no regressions.

Committed.

Jim

Kito Cheng 
Monk Chiang  

gcc/
* common/config/riscv/riscv-common.c (riscv_parse_arch_string):
Add support to parse rv32e*.  Clear MASK_RVE for rv32i and rv64i.
* config.gcc (riscv*-*-*): Add support for rv32e* and ilp32e.
* config/riscv/riscv-c.c (riscv_cpu_cpp_builtins): Define
__riscv_32e when TARGET_RVE.  Handle ABI_ILP32E as soft-float ABI.
* config/riscv/riscv-opts.h (riscv_abi_type): Add ABI_ILP32E.
* config/riscv/riscv.c (riscv_compute_frame_info): When TARGET_RVE,
compute save_libcall_adjustment properly.
(riscv_option_override): Call error if TARGET_RVE and not ABI_ILP32E.
(riscv_conditional_register_usage): Handle TARGET_RVE and ABI_ILP32E.
* config/riscv/riscv.h (UNITS_PER_FP_ARG): Handle ABI_ILP32E.
(STACK_BOUNDARY, ABI_STACK_BOUNDARY): Handle TARGET_RVE.
(GP_REG_LAST, MAX_ARGS_IN_REGISTERS): Likewise.
(ABI_SPEC): Handle mabi=ilp32e.
* config/riscv/riscv.opt (abi_type): Add ABI_ILP32E.
(RVE): Add RVE mask.
* doc/invoke.texi (RISC-V options) <-mabi>: Add ilp32e info.
<-march>: Add rv32e as an example.

gcc/testsuite/
* gcc.dg/stack-usage-1.c: Add support for rv32e.

libgcc/
* config/riscv/save-restore.S: Add support for rv32e.
---
 gcc/common/config/riscv/riscv-common.c | 29 -
 gcc/config.gcc | 10 +---
 gcc/config/riscv/riscv-c.c |  4 +++
 gcc/config/riscv/riscv-opts.h  |  1 +
 gcc/config/riscv/riscv.c   | 25 +-
 gcc/config/riscv/riscv.h   | 17 +++--
 gcc/config/riscv/riscv.opt |  5 
 gcc/doc/invoke.texi|  7 --
 gcc/testsuite/gcc.dg/stack-usage-1.c   |  6 -
 libgcc/config/riscv/save-restore.S | 46 +-
 10 files changed, 133 insertions(+), 17 deletions(-)

diff --git a/gcc/common/config/riscv/riscv-common.c 
b/gcc/common/config/riscv/riscv-common.c
index 9db83015aed..8a78aebc320 100644
--- a/gcc/common/config/riscv/riscv-common.c
+++ b/gcc/common/config/riscv/riscv-common.c
@@ -27,7 +27,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "flags.h"
 #include "diagnostic-core.h"
 
-/* Parse a RISC-V ISA string into an option mask.  */
+/* Parse a RISC-V ISA string into an option mask.  Must clear or set all arch
+   dependent mask bits, in case more than one -march string is passed.  */
 
 static void
 riscv_parse_arch_string (const char *isa, int *flags, location_t loc)
@@ -48,6 +49,8 @@ riscv_parse_arch_string (const char *isa, int *flags, 
location_t loc)
 {
   p++;
 
+  *flags &= ~MASK_RVE;
+
   *flags |= MASK_MUL;
   *flags |= MASK_ATOMIC;
   *flags |= MASK_HARD_FLOAT;
@@ -57,6 +60,8 @@ riscv_parse_arch_string (const char *isa, int *flags, 
location_t loc)
 {
   p++;
 
+  *flags &= ~MASK_RVE;
+
   *flags &= ~MASK_MUL;
   if (*p == 'm')
*flags |= MASK_MUL, p++;
@@ -77,6 +82,28 @@ riscv_parse_arch_string (const char *isa, int *flags, 
location_t loc)
}
}
 }
+  else if (*p == 'e')
+{
+  p++;
+
+  *flags |= MASK_RVE;
+
+  if (*flags & MASK_64BIT)
+   {
+ error ("RV64E is not a valid base ISA");
+ return;
+   }
+
+  *flags &= ~MASK_MUL;
+  if (*p == 'm')
+   *flags |= MASK_MUL, p++;
+
+  *flags &= ~MASK_ATOMIC;
+  if (*p == 'a')
+   *flags |= MASK_ATOMIC, p++;
+
+  *flags &= ~(MASK_HARD_FLOAT | MASK_DOUBLE_FLOAT);
+}
   else
 {
   error_at (loc, "-march=%s: invalid ISA string", isa);
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 8edd0cdbaed..96ae6a88a0d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4077,19 +4077,20 @@ case "${target}" in
 
# Infer arch from --with-arch, --target, and --with-abi.
case "${with_arch}" in
-   rv32i* | rv32g* | rv64i* | rv64g*)
+   rv32e* | rv32i* | rv32g* | rv64i* | rv64g*)
# OK.
;;
"")
# Infer XLEN, but otherwise assume GC.
case "${with_abi}" in
+   ilp32e) with_arch="rv32e" ;;
ilp32 | ilp32f | ilp32d) with_arch="rv32gc" ;;
lp64 | lp64f | lp64d) with_arch="rv64gc" 

[PATCH] Make __ibm128 a distinct type, patch 1 of 2 (PR 85657)

[Michael Meissner]

This patch is the first of two patches to make the __ibm128 type a distict
type.  Previously, when I impemented __ibm128, I had defined it to be long
double on systems where long double used the IBM extended double format.
Segher asked that I always create the type as a distinct type.  For C++, I have
chosen to use u8__ibm128 as the mangling for __ibm128.

I discovered in writing this patch, I needed to tweak the table of the
conversion functions, and I had to converting types that have different modes,
but have the same representation.

The second patch will add new unpack/pack builtin functions for __ibm128.  That
patch will also give an error if the long double default is changed, and the
user uses the pack/unpack long double functions.

I have done bootstrap tests on a little endian power8 system, and verified that
there were no regressions.  I also verified that the new tests run correctly.
I also have looked at the code for -mabi=ieeelongdouble, to verify that it is
still working when the default for long double is changed.

Can I install this in the GCC 9 trunk?  This will need to be back ported to GCC
8.2.

[gcc]
2018-05-18  Michael Meissner  

PR target/85657
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Do not
define __ibm128 as long double.
* config/rs6000/rs6000.c (rs6000_init_builtins): Always create
__ibm128 as a distinct type.
(init_float128_ieee): Fix up conversions between IFmode and IEEE
128-bit types to use the correct functions.
(rs6000_expand_float128_convert): Use explicit FLOAT_EXTEND to
convert between 128-bit floating point types that have different
modes but the same representation, instead of using gen_lowpart to
makean alias.
* config/rs6000/rs6000.md (IFKF): New iterator for IFmode and
KFmode.
(IFKF_reg): New attributes to give the register constraints for
IFmode and KFmode.
(extendtf2_internal): New insns to mark an explicit
conversion between 128-bit floating point types that have a
different mode but share the same representation.

[gcc/testsuite]
2018-05-18  Michael Meissner  

PR target/85657
* gcc.target/powerpc/pr85657-1.c: New test for converting between
__float128, __ibm128, and long double.
* gcc.target/powerpc/pr85657-2.c: Likewise.
* gcc.target/powerpc/pr85657-3.c: Likewise.
* g++.dg/pr85667.C: New test to make sure __ibm128 is
implementated as a separate type internally, and is not just an
alias for long double.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(.../trunk) (revision 260267)
+++ gcc/config/rs6000/rs6000-c.c(.../branches/ibm/ieee) (revision 
260381)
@@ -608,8 +608,6 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfi
 builtin_define ("__RSQRTEF__");
   if (TARGET_FLOAT128_TYPE)
 builtin_define ("__FLOAT128_TYPE__");
-  if (TARGET_LONG_DOUBLE_128 && FLOAT128_IBM_P (TFmode))
-builtin_define ("__ibm128=long double");
 #ifdef TARGET_LIBC_PROVIDES_HWCAP_IN_TCB
   builtin_define ("__BUILTIN_CPU_SUPPORTS__");
 #endif
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (.../trunk) (revision 260267)
+++ gcc/config/rs6000/rs6000.c  (.../branches/ibm/ieee) (revision 260381)
@@ -16345,35 +16350,28 @@ rs6000_init_builtins (void)
  floating point, we need make sure the type is non-zero or else self-test
  fails during bootstrap.
 
- We don't register a built-in type for __ibm128 if the type is the same as
- long double.  Instead we add a #define for __ibm128 in
- rs6000_cpu_cpp_builtins to long double.
+ Always create __ibm128 as a separate type, even if the current long double
+ format is IBM extended double.
 
  For IEEE 128-bit floating point, always create the type __ieee128.  If the
  user used -mfloat128, rs6000-c.c will create a define from __float128 to
  __ieee128.  */
-  if (TARGET_LONG_DOUBLE_128 && FLOAT128_IEEE_P (TFmode))
+  if (TARGET_FLOAT128_TYPE)
 {
   ibm128_float_type_node = make_node (REAL_TYPE);
   TYPE_PRECISION (ibm128_float_type_node) = 128;
   SET_TYPE_MODE (ibm128_float_type_node, IFmode);
   layout_type (ibm128_float_type_node);
-
   lang_hooks.types.register_builtin_type (ibm128_float_type_node,
  "__ibm128");
-}
-  else
-ibm128_float_type_node = long_double_type_node;
 
-  if (TARGET_FLOAT128_TYPE)
-{
   ieee128_float_type_node = float128_type_node;
   lang_hooks.types.register_builtin_type 

Re: [patch] Improve support for up-level references (1/n)

[Eric Botcazou]

> + /* If the next declaration is a PARM_DECL pointing to theDECL,
> +we need to adjust its VALUE_EXPR directly, since chains of
> +VALUE_EXPRs run afoul of garbage collection.  This occurs
> +in Ada for Out parameters that aren't copied in.  */
> + if (next
> + && TREE_CODE (next) == PARM_DECL
> + && DECL_HAS_VALUE_EXPR_P (next)
> + && DECL_VALUE_EXPR (next) == decl)
> +   SET_DECL_VALUE_EXPR (next, x);
> 
> maybe you can explain the GC issue a bit.

It's the issue with GCed tables pointing to each other (which one is marked 
first?) applied to the VALUE_EXPR table.  Not clear it's worth verifying since 
it's marginal, but I guess it's cheap enough to do in decl_value_expr_insert.

-- 
Eric Botcazou

Re: [PATCH , rs6000] Add missing builtin test cases, fix arguments to match specifications.

[Segher Boessenkool]

On Thu, May 17, 2018 at 02:40:11PM -0700, Carl Love wrote:
> On Thu, 2018-05-17 at 15:31 -0500, Segher Boessenkool wrote:
> > On Wed, May 16, 2018 at 12:53:13PM -0700, Carl Love wrote:
> > > diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> > > b/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> > > index b0267b5..1f3175f 100644
> > > --- a/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> > > +++ b/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> > > @@ -18,7 +18,7 @@ vector char scz;
> > >  vector unsigned char uca =
> > > {0,4,8,1,5,9,2,6,10,3,7,11,15,12,14,13};
> > >  vector unsigned char ucb =
> > > {6,4,8,3,1,9,2,6,10,3,7,11,15,12,14,13};
> > >  vector unsigned char uc_expected =
> > > {3,4,8,2,3,9,2,6,10,3,7,11,15,12,14,13};
> > > -vector char ucz;
> > > +vector unsigned char ucz;
> > 
> > Why?  Was this a bug in the test case, does it quieten a warning?
> 
> I was actually just making the naming consistent with the rest of the
> variable naming.  It doesn't impact the functionality.  The other
> variables, uca, ucb for example have their types explicitly stated as 
> "unsigned char" where the leading "u" stands for unsigned, "c"
> represents char.  However, we have ucz as type char not explicitly
> "unsigned char".  So, was just looking for consistency in the
> name/declaration.

Ah ok.

> > > diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c
> > > b/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c
> > > index 1e690be..f1eb78f 100644
> > > --- a/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c
> > > +++ b/gcc/testsuite/gcc.target/powerpc/altivec-7-be.c
> > > @@ -1,4 +1,4 @@
> > > -/* { dg-do compile { target powerpc*-*-* } } */
> > > +/* { dg-do compile { target powerpc64-*-* } } */
> > 
> > This is not correct.  The target triple is the (canonical) name of
> > the
> > architecture the compiler is built for, but you can do for example
> > powerpc64-linux-gcc -m32, because we are a biarch target; a typical
> > way to test is
> 
> OK, wasn't thinking about the fact that the change makes it a 64-bit
> only test.  The test is supposed to be for big endian, i.e. the name is
> altivec-7-be.c.  We have another test file altivec-7-le.c for little
> endian testing.  The change was trying to make it a BE only test but as
> you point out, I lose the 32-bit testing.  The 32-bit mode will
> obviously be BE.  The thinking was powerpc64-*-* restricts the test to
> BE where as powerpc64le-*-* restricts the test to LE.  So I need to
> qualify that on 64-bit I only want to run if I am on a 64-bit BE
> system.  How can I do that?

I attach a patch that introduces "be" and "le" selectors, so you can say
/* { dg-do compile { target powerpc64-*-* && be } } */
(completely untested so far, YMMV).

> > > diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c
> > > b/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c
> > > index 2dd4953..c74c493 100644
> > > --- a/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c
> > > +++ b/gcc/testsuite/gcc.target/powerpc/builtins-1-le.c
> > > @@ -1,5 +1,5 @@
> >  /* { dg-do compile { target { powerpc64le-*-* } } } */
> > > -/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-
> > > mcpu=*" } { "-mcpu=power8" } } */
> > > +/* { dg-skip-if "do not override -mcpu" { powerpc64le-*-* } { "-
> > > mcpu=*" } { "-mcpu=power8" } } */
> > 
> > This makes no difference, does it?  Please keep it as it was.
> 
> Ditto, trying to make this only run on LE as there is also a test file
> builtins-1-be.c with  /* { dg-do compile { target { powerpc64-*-* } } }
> */ for testing on BE.  

But the testcase already only runs on powerpc64le, this change to the
dg-skip-if doesn't change anything afaics.


Segher


--- 8< ---
>From c98a698aa4bc9e753cd9c53a9970713406795195 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Segher Boessenkool 
Date: Fri, 18 May 2018 16:13:38 +
Subject: [PATCH] be/le

---
 gcc/testsuite/lib/target-supports.exp | 16 
 1 file changed, 16 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index cfc22a2..53367f3 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2641,6 +2641,22 @@ proc check_effective_target_long_neq_int { } {
 }]
 }
 
+# Return 1 if we're generating big-endian code.
+
+proc check_effective_target_be { } {
+return [check_no_compiler_messages be object {
+   int dummy[__BYTE_ORDER__ == ORDER_BIG_ENDIAN__ ? 1 : -1];
+}]
+}
+
+# Return 1 if we're generating little-endian code.
+
+proc check_effective_target_le { } {
+return [check_no_compiler_messages le object {
+   int dummy[__BYTE_ORDER__ == ORDER_LITTLE_ENDIAN__ ? 1 : -1];
+}]
+}
+
 # Return 1 if the target supports long double larger than double,
 # 0 otherwise.
 
-- 
1.8.3.1

Re: [PATCH] Warn for ignored ASM labels on typdef declarations PR 85444 (v.3)

[Will Hawkins]

Hello again!

Thanks to the feedback of Mr. Myers and those on the PR, I have
created a version 3 of this patch. This version introduces a new
warning flag (enabled at Wall) -Wignored-asm-name that will flag cases
where the user specifies an ASM name that the compiler ignores.

Test cases included. Results from make bootstrap and/or make -k check
are available upon request.

Please let me know what I can do to make this better and bring it up
to the standards of the community! Thanks again for the feedback on
this patch during the previous two revisions!

Sincerely,
Will Hawkins


2018-05-18 Will Hawkins 

PR c,c++/85444
* gcc/c/c-decl.c: Warn about ignored asm label for
typedef declaration
* gcc/cp/decl.c: Warn about ignored asm label for
typedef declaration
* gcc/testsuite/gcc.dg/asm-pr85444.c: c testcase.
* gcc/testsuite/g++.dg/asm-pr85444.C: c++ testcase.

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index c48d6dc..ab3a9af 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -595,6 +595,10 @@ Wignored-attributes
 C C++ Var(warn_ignored_attributes) Init(1) Warning
 Warn whenever attributes are ignored.

+Wignored-asm-name
+C C++ Var(warn_ignored_asm_name) Warning LangEnabledBy(C C++,Wall)
+Warn whenever assembler names are specified but ignored.
+
 Wincompatible-pointer-types
 C ObjC Var(warn_incompatible_pointer_types) Init(1) Warning
 Warn when there is a conversion between pointers that have incompatible types.
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index 3c4b18e..5a1ecd7 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -5177,7 +5177,11 @@ finish_decl (tree decl, location_t init_loc, tree init,
   if (!DECL_FILE_SCOPE_P (decl)
   && variably_modified_type_p (TREE_TYPE (decl), NULL_TREE))
 add_stmt (build_stmt (DECL_SOURCE_LOCATION (decl), DECL_EXPR, decl));
-
+  if (asmspec_tree != NULL_TREE)
+{
+  warning (OPT_Wignored_asm_name, "asm-specifier is ignored in "
+   "typedef declaration");
+}
   rest_of_decl_compilation (decl, DECL_FILE_SCOPE_P (decl), 0);
 }

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 10e3079..4c3ee36 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6981,6 +6981,11 @@ cp_finish_decl (tree decl, tree init, bool
init_const_expr_p,
   /* Take care of TYPE_DECLs up front.  */
   if (TREE_CODE (decl) == TYPE_DECL)
 {
+  if (asmspec_tree != NULL_TREE)
+{
+  warning (OPT_Wignored_asm_name, "asm-specifier is ignored for "
+   "typedef declarations");
+}
   if (type != error_mark_node
   && MAYBE_CLASS_TYPE_P (type) && DECL_NAME (decl))
 {
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ca3772b..63f81f4 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -286,7 +286,8 @@ Objective-C and Objective-C++ Dialects}.
 -Wformat-y2k  -Wframe-address @gol
 -Wframe-larger-than=@var{len}  -Wno-free-nonheap-object
-Wjump-misses-init @gol
 -Wif-not-aligned @gol
--Wignored-qualifiers  -Wignored-attributes  -Wincompatible-pointer-types @gol
+-Wignored-qualifiers  -Wignored-attributes  -Wignored-asm-name @gol
+-Wincompatible-pointer-types @gol
 -Wimplicit  -Wimplicit-fallthrough  -Wimplicit-fallthrough=@var{n} @gol
 -Wimplicit-function-declaration  -Wimplicit-int @gol
 -Winit-self  -Winline  -Wno-int-conversion  -Wint-in-bool-context @gol
@@ -4523,6 +4524,14 @@ Warn when an attribute is ignored.  This is
different from the
 to drop an attribute, not that the attribute is either unknown, used in a
 wrong place, etc.  This warning is enabled by default.

+@item -Wignored-asm-name @r{(C and C++ only)}
+@opindex Wignored-asm-name
+@opindex Wno-ignored-asm-name
+Warn when an assembler name is given but ignored. For C and C++, this
+happens when a @code{typdef} declaration is given an assembler name.
+
+This warning is also enabled by @option{-Wall}.
+
 @item -Wmain
 @opindex Wmain
 @opindex Wno-main
diff --git a/gcc/testsuite/g++.dg/asm-pr85444.C
b/gcc/testsuite/g++.dg/asm-pr85444.C
new file mode 100644
index 000..f1f8f61
--- /dev/null
+++ b/gcc/testsuite/g++.dg/asm-pr85444.C
@@ -0,0 +1,13 @@
+/* Fix Bugzilla 8544 -- asm specifier on typedef silently ignored.
+   { dg-do compile }
+   { dg-options "-Wignored-asm-name" } */
+
+typedef struct
+{
+  int a;
+} x asm ("X"); /* { dg-warning "asm-specifier is ignored" } */
+
+int main()
+{
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/asm-pr85444.c
b/gcc/testsuite/gcc.dg/asm-pr85444.c
new file mode 100644
index 000..73ccea0
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asm-pr85444.c
@@ -0,0 +1,14 @@
+/* Fix Bugzilla 8544 -- asm specifier on typedef silently ignored.
+   { dg-do compile }
+   { dg-options "-Wignored-asm-name" } */
+
+typedef struct
+{
+  int a;
+} x asm ("X"); /* { dg-warning "asm-specifier is ignored" } */
+
+int main()
+{
+  return 0;
+}
+

On Mon, Apr 30, 2018 at 3:56 PM, Joseph Myers  wrote:
> On Mon, 30 Apr 

[PATCH 2/2][Aarch64] Improve FP to int conversions

[Michael Collison]

This patch improves additional cases of FP to integer conversions with 
-ffast-math enabled.

Example 1:

double
f5 (int x)
{
  return (double)(float) x;
}


At -O2 with -ffast-math

Trunk generates:

f5:
scvtf   s0, w0
fcvtd0, s0
ret


With the patch we can merge the conversion to float and float-extend and reduce 
the sequence to one instruction at -O2 and -ffast-math

f5:
scvtf   d0, w0
ret

Example 2

int
f6 (double x)
{
  return (int)(float) x;
}


At -O2 (even with -ffast-math) trunk generates

f6:
fcvts0, d0
fcvtzs  w0, s0
ret

We can merge the float_truncate into the fix at the rtl level

With -ffast-math enabled and -O2 we can now generate:

f6:
fcvtzs  w0, d0
ret

Bootstrapped and regression tested on aarch64-linux-gnu. Okay for trunk?

2018-05-15  Michael Collison  

* config/aarch64/aarch64.md:
(*df2): New pattern.
(truncdfsf_2: New pattern.
(*fix_to_sign_extenddi2): Ditto.
* gcc.target/aarch64/float_int_conv.c: New testcase.


gnutools-6527-pt2.patch
Description: gnutools-6527-pt2.patch

[PATCH 1/2][Aarch64] Improve FP to int conversions

[Michael Collison]

This patch improves additional cases of FP to integer conversions.

Example 1:

unsigned long
f7 (double x)
{
  return (unsigned) y;
}


At -O2

Trunk generates:

f7:
fcvtzu  w0, d0
uxtwx0, w0
ret

With the patch we can merge the zero-extend and reduce the sequence to one 
instruction at -O2

f7:
fcvtzu  x0, d0
ret

Bootstrapped and regression tested on aarch64-linux-gnu. Okay for trunk?

2018-05-15  Michael Collison  

* config/aarch64/aarch64.md:
(*fix_to_zero_extenddfdi2): New pattern.
* gcc.target/aarch64/fix_extend1.c: New testcase.


gnutools-6527-pt1.patch
Description: gnutools-6527-pt1.patch

Re: [PATCH] Support lower and upper limit for -fdbg-cnt flag.

[Martin Liška]

On 05/18/2018 04:07 PM, Rainer Orth wrote:

Please fix.


Thanks for the report, will install obvious fix.

Martin
>From af8fbed777a1583fc2ac865e0e15cbb24fee6a81 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 18 May 2018 16:27:22 +0200
Subject: [PATCH] Fix typo in test-case.

gcc/testsuite/ChangeLog:

2018-05-18  Martin Liska  

	* gcc.dg/pr68766.c: Change pruned output.
---
 gcc/testsuite/gcc.dg/pr68766.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/pr68766.c b/gcc/testsuite/gcc.dg/pr68766.c
index 83f0e14b7d2..097e555eb01 100644
--- a/gcc/testsuite/gcc.dg/pr68766.c
+++ b/gcc/testsuite/gcc.dg/pr68766.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -ftree-vectorize -fdbg-cnt=vect_loop:1" } */
 /* { dg-additional-options "-mavx2" { target { i?86-*-* x86_64-*-* } } } */
-/* { dg-prune-output "dbg_cnt 'vect_loop' set to 1-1" } */
+/* { dg-prune-output "dbg_cnt 'vect_loop' set to 0-1" } */
 
 int a, b, g, h;
 int c[58];
-- 
2.16.3

[PATCH] avoid assuming that a DECL necessarily has a constant size (PR 85826)

[Martin Sebor]

Under some apparently rare conditions a DECL can have a non-
constant size that the fix for bug 85753 committed last week
into trunk was not prepared for.  The attached change removes
the assumption to avoid the ICE that otherwise results.

Martin

PS The test case that triggers the ICE makes use of variable-
length structs and local functions, both of which are fairly
obscure GCC extensions that I tend to forget to consider when
writing GCC code.  I tried to construct a less convoluted (and
strictly conforming) test case but in all of those I've come
up with a variable-length object is represented by a pointer
(pointing to memory returned by __builtin_alloca_with_align()).
Is there a straightforward way to create a variable-size DECL
that doesn't rely on GCC extensions?
PR tree-optimization/85826 - ICE in gimple-ssa-warn-restruct on a variable-length struct

gcc/ChangeLog:

	PR tree-optimization/85826
	* gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Avoid
	assuming that a DECL necesarily has a constant size.

gcc/testsuite/ChangeLog:

	PR tree-optimization/85826
	* gcc.dg/Wrestrict-17.c: New test.


Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c	(revision 260371)
+++ gcc/gimple-ssa-warn-restrict.c	(working copy)
@@ -278,7 +278,10 @@ builtin_memref::builtin_memref (tree expr, tree si
   && array_at_struct_end_p (ref))
 ;   /* Use the maximum possible offset for last member arrays.  */
   else if (tree basesize = TYPE_SIZE_UNIT (basetype))
-maxoff = wi::to_offset (basesize);
+if (TREE_CODE (basesize) == INTEGER_CST)
+  /* Size could be non-constant for a variable-length type such
+	 as a struct with a VLA member (a GCC extension).  */
+  maxoff = wi::to_offset (basesize);
 
   if (offrange[0] >= 0)
 {
Index: gcc/testsuite/gcc.dg/Wrestrict-17.c
===
--- gcc/testsuite/gcc.dg/Wrestrict-17.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/Wrestrict-17.c	(working copy)
@@ -0,0 +1,20 @@
+/* PR tree-optimization/85826 - ICE in gimple-ssa-warn-restruct on
+   a variable-length struct
+   { dg-do compile }
+   { dg-options "-O2 -Wall" }  */
+
+int f (int n)
+{
+  typedef struct { int a[n]; } S;
+
+  S a;
+  __attribute__ ((noinline)) S g (void) { return a; }
+
+  a.a[0] = 1;
+  a.a[9] = 2;
+
+  S b;
+  b = g ();
+
+  return b.a[0] == 1 && b.a[9] == 2;
+}

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

[Paolo Carlini]

Hi again,

I'm playing with a wild, wild idea: would it make sense to try *first* 
an expression? Because, a quickly hacked draft appears to handle very 
elegantly all the possible cases of "junk" after the declarator, eg:


    void foo()
    {
        if (void bar()JUNK);
 }

and the parenthesized case, etc, etc. Before trying to seriously work on 
that I wanted to ask...


Paolo.

Re: [PATCH] PR libstdc++/85098 add missing definitions for static constants

[Ville Voutilainen]

On 18 May 2018 at 19:13, Jonathan Wakely  wrote:
> In C++11 and C++14 any odr-use of these constants requires a definition
> at namespace-scope.  In C++17 they are implicitly inline and so the
> namespace-scope redeclarations are redundant (and allowing them is
> deprecated).
>
> PR libstdc++/85098
> * include/bits/regex.h [__cplusplus < 201703L] (basic_regex::icase)
> (basic_regex::nosubs, basic_regex::optimize, basic_regex::collate)
> (basic_regex::ECMAScript, basic_regex::basic, basic_regex::extended)
> (basic_regex::awk, basic_regex::grep, basic_regex::egrep): Add
> definitions.
> * include/bits/regex_automaton.h (_NFA::_M_insert_state): Adjust
> whitespace.
> * include/bits/regex_compiler.tcc (__INSERT_REGEX_MATCHER): Add
> braces around body of do-while.
> * testsuite/28_regex/basic_regex/85098.cc: New
>
> I think we should backport this to the branches, although nobody seems
> to have ever noticed the bug until recently (and it's not a
> regression).

+1 for backporting this.

[PATCH] PR libstdc++/85098 add missing definitions for static constants

[Jonathan Wakely]

In C++11 and C++14 any odr-use of these constants requires a definition
at namespace-scope.  In C++17 they are implicitly inline and so the
namespace-scope redeclarations are redundant (and allowing them is
deprecated).

PR libstdc++/85098
* include/bits/regex.h [__cplusplus < 201703L] (basic_regex::icase)
(basic_regex::nosubs, basic_regex::optimize, basic_regex::collate)
(basic_regex::ECMAScript, basic_regex::basic, basic_regex::extended)
(basic_regex::awk, basic_regex::grep, basic_regex::egrep): Add
definitions.
* include/bits/regex_automaton.h (_NFA::_M_insert_state): Adjust
whitespace.
* include/bits/regex_compiler.tcc (__INSERT_REGEX_MATCHER): Add
braces around body of do-while.
* testsuite/28_regex/basic_regex/85098.cc: New

I think we should backport this to the branches, although nobody seems
to have ever noticed the bug until recently (and it's not a
regression).

Tested powerpc64le-linux, committed to trunk.

commit fcb6ab3a65df7123d6bab6567fbc57f4542cbbad
Author: Jonathan Wakely 
Date:   Fri May 18 15:56:17 2018 +0100

PR libstdc++/85098 add missing definitions for static constants

In C++11 and C++14 any odr-use of these constants requires a definition
at namespace-scope.  In C++17 they are implicitly inline and so the
namespace-scope redeclarations are redundant (and allowing them is
deprecated).

PR libstdc++/85098
* include/bits/regex.h [__cplusplus < 201703L] (basic_regex::icase)
(basic_regex::nosubs, basic_regex::optimize, basic_regex::collate)
(basic_regex::ECMAScript, basic_regex::basic, basic_regex::extended)
(basic_regex::awk, basic_regex::grep, basic_regex::egrep): Add
definitions.
* include/bits/regex_automaton.h (_NFA::_M_insert_state): Adjust
whitespace.
* include/bits/regex_compiler.tcc (__INSERT_REGEX_MATCHER): Add
braces around body of do-while.
* testsuite/28_regex/basic_regex/85098.cc: New

diff --git a/libstdc++-v3/include/bits/regex.h 
b/libstdc++-v3/include/bits/regex.h
index 92cf96c7e70..12e830b2c68 100644
--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -776,6 +776,48 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   _AutomatonPtr_M_automaton;
 };
 
+#if __cplusplus < 201703L
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::icase;
+
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::nosubs;
+
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::optimize;
+
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::collate;
+
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::ECMAScript;
+
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::basic;
+
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::extended;
+
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::awk;
+
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::grep;
+
+  template
+constexpr regex_constants::syntax_option_type
+basic_regex<_Ch, _Tr>::egrep;
+#endif // ! C++17
+
 #if __cpp_deduction_guides >= 201606
   template
 basic_regex(_ForwardIterator, _ForwardIterator,
diff --git a/libstdc++-v3/include/bits/regex_automaton.h 
b/libstdc++-v3/include/bits/regex_automaton.h
index ff87dcc245d..11a31acbefe 100644
--- a/libstdc++-v3/include/bits/regex_automaton.h
+++ b/libstdc++-v3/include/bits/regex_automaton.h
@@ -333,7 +333,7 @@ namespace __detail
"Number of NFA states exceeds limit. Please use shorter regex "
"string, or use smaller brace expression, or make "
"_GLIBCXX_REGEX_STATE_LIMIT larger.");
-   return this->size()-1;
+   return this->size() - 1;
   }
 
   // Eliminate dummy node in this NFA to make it compact.
diff --git a/libstdc++-v3/include/bits/regex_compiler.tcc 
b/libstdc++-v3/include/bits/regex_compiler.tcc
index 3342f146c9d..8af920e5fe9 100644
--- a/libstdc++-v3/include/bits/regex_compiler.tcc
+++ b/libstdc++-v3/include/bits/regex_compiler.tcc
@@ -295,7 +295,7 @@ namespace __detail
 }
 
 #define __INSERT_REGEX_MATCHER(__func, ...)\
-   do\
+   do {\
  if (!(_M_flags & regex_constants::icase))\
if (!(_M_flags & regex_constants::collate))\
  __func(__VA_ARGS__);\
@@ -306,7 +306,7 @@ namespace __detail
  __func(__VA_ARGS__);\
else\
  __func(__VA_ARGS__);\
-   while (false)
+   } while (false)
 
   template
 bool
diff --git 

Re: RFC (libstdc++): C++ PATCH for c++/58407, C++11 deprecation of implicit copy

[Jonathan Wakely]

On 18/05/18 11:58 -0400, Jason Merrill wrote:

On Fri, May 18, 2018 at 11:55 AM, Jason Merrill  wrote:

On Fri, May 18, 2018 at 10:51 AM, Jonathan Wakely  wrote:

On 18/05/18 10:29 -0400, Jason Merrill wrote:


The second patch is some libstdc++ changes to avoid warnings from uses
of the standard library when this warning is on.  More are almost
certainly needed.  Jonathan, how would you like me to handle this WRT
the library?  Check in both patches and let you follow up as needed?



Yes, please go ahead and commit the library patch, we'll deal with the
rest as needed (I'll give myself a TODO to test with -Wdeprecated-copy
and fix what I find).

I'm not sure we need the "Avoid implicit deprecation" comments. Adding
defaulted definitions is good style anyway, so needs no justification.
I'll make sure nobody removes them again in the name of cleaning up
unnecessary noise (which they aren't).


OK.


Did you change your mind about leaving the exception hierarchy without
the defaulted ops, to get warnings for slicing?


Yes, because the warning also triggers in cases where we know the
dynamic type of the object, such as

exception e;
throw e;

I think a slicing warning should be separate.

Also because these functions are required by the standard, as below.


I've just realised that our user-declared destructors on the exception
classes (which exist so we can control where the key function is
emitted) mean they have no implicit move ops. But the standard implies
they should have implicitly-declared move ops (because it doesn't
declare any special members for those classes). I'll open a bug.


Hmm, looks to me like it declares special members.

21.8.2 Class exception [exception]

namespace std {
  class exception {
  public:
exception() noexcept;
exception(const exception&) noexcept;
exception& operator=(const exception&) noexcept;
virtual ~exception();
virtual const char* what() const noexcept;
  };
}


...though this is not true of many of the derived exception classes.


Right. std::exception has no data members anyway, so moving is the
same as copying. For the derived types the standard declares them
like:

namespace std {
 class logic_error : public exception {
 public:
   explicit logic_error(const string& what_arg);
   explicit logic_error(const char* what_arg);
 };
}

But we define:

 class logic_error : public exception
 {
   [...]

   virtual ~logic_error() _GLIBCXX_TXN_SAFE_DYN _GLIBCXX_USE_NOEXCEPT;

   [...]
 };

And this means there is no move constructor or move assignment operator.

Re: RFC (libstdc++): C++ PATCH for c++/58407, C++11 deprecation of implicit copy

[Jason Merrill]

On Fri, May 18, 2018 at 11:55 AM, Jason Merrill  wrote:
> On Fri, May 18, 2018 at 10:51 AM, Jonathan Wakely  wrote:
>> On 18/05/18 10:29 -0400, Jason Merrill wrote:
>>>
>>> The second patch is some libstdc++ changes to avoid warnings from uses
>>> of the standard library when this warning is on.  More are almost
>>> certainly needed.  Jonathan, how would you like me to handle this WRT
>>> the library?  Check in both patches and let you follow up as needed?
>>
>>
>> Yes, please go ahead and commit the library patch, we'll deal with the
>> rest as needed (I'll give myself a TODO to test with -Wdeprecated-copy
>> and fix what I find).
>>
>> I'm not sure we need the "Avoid implicit deprecation" comments. Adding
>> defaulted definitions is good style anyway, so needs no justification.
>> I'll make sure nobody removes them again in the name of cleaning up
>> unnecessary noise (which they aren't).
>
> OK.
>
>> Did you change your mind about leaving the exception hierarchy without
>> the defaulted ops, to get warnings for slicing?
>
> Yes, because the warning also triggers in cases where we know the
> dynamic type of the object, such as
>
> exception e;
> throw e;
>
> I think a slicing warning should be separate.
>
> Also because these functions are required by the standard, as below.
>
>> I've just realised that our user-declared destructors on the exception
>> classes (which exist so we can control where the key function is
>> emitted) mean they have no implicit move ops. But the standard implies
>> they should have implicitly-declared move ops (because it doesn't
>> declare any special members for those classes). I'll open a bug.
>
> Hmm, looks to me like it declares special members.
>
> 21.8.2 Class exception [exception]
>
> namespace std {
>   class exception {
>   public:
> exception() noexcept;
> exception(const exception&) noexcept;
> exception& operator=(const exception&) noexcept;
> virtual ~exception();
> virtual const char* what() const noexcept;
>   };
> }

...though this is not true of many of the derived exception classes.

Jason

Re: RFC (libstdc++): C++ PATCH for c++/58407, C++11 deprecation of implicit copy

[Jason Merrill]

On Fri, May 18, 2018 at 10:51 AM, Jonathan Wakely  wrote:
> On 18/05/18 10:29 -0400, Jason Merrill wrote:
>>
>> The second patch is some libstdc++ changes to avoid warnings from uses
>> of the standard library when this warning is on.  More are almost
>> certainly needed.  Jonathan, how would you like me to handle this WRT
>> the library?  Check in both patches and let you follow up as needed?
>
>
> Yes, please go ahead and commit the library patch, we'll deal with the
> rest as needed (I'll give myself a TODO to test with -Wdeprecated-copy
> and fix what I find).
>
> I'm not sure we need the "Avoid implicit deprecation" comments. Adding
> defaulted definitions is good style anyway, so needs no justification.
> I'll make sure nobody removes them again in the name of cleaning up
> unnecessary noise (which they aren't).

OK.

> Did you change your mind about leaving the exception hierarchy without
> the defaulted ops, to get warnings for slicing?

Yes, because the warning also triggers in cases where we know the
dynamic type of the object, such as

exception e;
throw e;

I think a slicing warning should be separate.

Also because these functions are required by the standard, as below.

> I've just realised that our user-declared destructors on the exception
> classes (which exist so we can control where the key function is
> emitted) mean they have no implicit move ops. But the standard implies
> they should have implicitly-declared move ops (because it doesn't
> declare any special members for those classes). I'll open a bug.

Hmm, looks to me like it declares special members.

21.8.2 Class exception [exception]

namespace std {
  class exception {
  public:
exception() noexcept;
exception(const exception&) noexcept;
exception& operator=(const exception&) noexcept;
virtual ~exception();
virtual const char* what() const noexcept;
  };
}

Jason

Re: Fix PR85782: C++ ICE with continue statements inside acc loops

[Jakub Jelinek]

On Fri, May 18, 2018 at 08:30:44AM -0700, Cesar Philippidis wrote:
> Ping.

Ok.

> For reference, I've attached the patch for gcc7.

Jakub

Re: Fix PR85782: C++ ICE with continue statements inside acc loops

[Cesar Philippidis]

Ping.

For reference, I've attached the patch for gcc7.

Cesar

On 05/15/2018 07:11 AM, Cesar Philippidis wrote:
> This patch resolves the issue in PR85782, which involves a C++ ICE
> caused by OpenACC loops which contain continue statements. The problem
> is that genericize_continue_stmt expects a continue label for the loop,
> but that wasn't getting set up acc loops. This patch fixes that by
> calling genericize_omp_for_stmt for OACC_LOOP statements, because
> OACC_LOOP and OMP_FOR statements are almost identical at this point of
> parsing.
> 
> I regression tested it on x86_64-linux with nvptx offloading.
> 
> Is this ok for trunk and the stable branches?  The patch for the stable
> branches is slightly different, because cp_genericize_r uses if
> statements to check for statement types instead of a huge switch statement.
> 
> Cesar
> 
> 
> trunk-pr85782.diff
> 
> 
> 2018-05-15  Cesar Philippidis  
> 
>   PR c++/85782
> 
>   gcc/cp/
>   * cp-gimplify.c (cp_genericize_r): Call genericize_omp_for_stmt for
>   OACC_LOOPs.
> 
>   gcc/testsuite/
>   * c-c++-common/goacc/pr85782.c: New test.
> 
>   libgomp/
>   * testsuite/libgomp.oacc-c-c++-common/pr85782.c: New test.
> 
> 
> diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
> index eda5f05..55aef86 100644
> --- a/gcc/cp/cp-gimplify.c
> +++ b/gcc/cp/cp-gimplify.c
> @@ -1463,6 +1463,7 @@ cp_genericize_r (tree *stmt_p, int *walk_subtrees, void 
> *data)
>  case OMP_FOR:
>  case OMP_SIMD:
>  case OMP_DISTRIBUTE:
> +case OACC_LOOP:
>genericize_omp_for_stmt (stmt_p, walk_subtrees, data);
>break;
>  
> diff --git a/gcc/testsuite/c-c++-common/goacc/pr85782.c 
> b/gcc/testsuite/c-c++-common/goacc/pr85782.c
> new file mode 100644
> index 000..f213a24
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/goacc/pr85782.c
> @@ -0,0 +1,11 @@
> +/* PR c++/85782 */
> +
> +void
> +foo ()
> +{
> +  int i;
> +  
> +  #pragma acc parallel loop
> +  for (i = 0; i < 100; i++)
> +continue;
> +}
> diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85782.c 
> b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85782.c
> new file mode 100644
> index 000..6f84dfc
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85782.c
> @@ -0,0 +1,32 @@
> +/* PR c++/85782 */
> +
> +#include 
> +
> +#define N 100
> +
> +int
> +main ()
> +{
> +  int i, a[N];
> +
> +  for (i = 0; i < N; i++)
> +a[i] = i+1;
> +
> +  #pragma acc parallel loop copy(a)
> +  for (i = 0; i < N; i++)
> +{
> +  if (i % 2)
> + continue;
> +  a[i] = 0;
> +}
> +
> +  for (i = 0; i < N; i++)
> +{
> +  if (i % 2)
> + assert (a[i] == i+1);
> +  else
> + assert (a[i] == 0);
> +}
> +
> +return 0;
> +}
> 

2018-05-18  Cesar Philippidis  

	PR c++/85782

	gcc/cp/
	* cp-gimplify.c (cp_genericize_r): Call genericize_omp_for_stmt for
	OACC_LOOPs.

	gcc/testsuite/
	* c-c++-common/goacc/pr85782.c: New test.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/pr85782.c: New test.


diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index 00214e9..4fbb8b5 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -1473,7 +1473,8 @@ cp_genericize_r (tree *stmt_p, int *walk_subtrees, void *data)
 genericize_break_stmt (stmt_p);
   else if (TREE_CODE (stmt) == OMP_FOR
 	   || TREE_CODE (stmt) == OMP_SIMD
-	   || TREE_CODE (stmt) == OMP_DISTRIBUTE)
+	   || TREE_CODE (stmt) == OMP_DISTRIBUTE
+	   || TREE_CODE (stmt) == OACC_LOOP)
 genericize_omp_for_stmt (stmt_p, walk_subtrees, data);
   else if (TREE_CODE (stmt) == PTRMEM_CST)
 {
diff --git a/gcc/testsuite/c-c++-common/goacc/pr85782.c b/gcc/testsuite/c-c++-common/goacc/pr85782.c
new file mode 100644
index 000..f213a24
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/goacc/pr85782.c
@@ -0,0 +1,11 @@
+/* PR c++/85782 */
+
+void
+foo ()
+{
+  int i;
+  
+  #pragma acc parallel loop
+  for (i = 0; i < 100; i++)
+continue;
+}
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85782.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85782.c
new file mode 100644
index 000..6f84dfc
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85782.c
@@ -0,0 +1,32 @@
+/* PR c++/85782 */
+
+#include 
+
+#define N 100
+
+int
+main ()
+{
+  int i, a[N];
+
+  for (i = 0; i < N; i++)
+a[i] = i+1;
+
+  #pragma acc parallel loop copy(a)
+  for (i = 0; i < N; i++)
+{
+  if (i % 2)
+	continue;
+  a[i] = 0;
+}
+
+  for (i = 0; i < N; i++)
+{
+  if (i % 2)
+	assert (a[i] == i+1);
+  else
+	assert (a[i] == 0);
+}
+
+return 0;
+}

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

[Paolo Carlini]

Hi,

On 18/05/2018 16:45, Jason Merrill wrote:

I guess it's desirable to also give this error when the declarator is
followed by ) or ; rather than other tokens that could be more
expression (like in A(a).x in the comment).

I can certainly try to implement this, maybe just something minimal to begin
with, as you say ) or ; alone would be safe and would already take care of
all the tests I have around.

Certainly, unconditionally deferring at that point to cp_parser_expression
leads to *very* bad error-recovery. For fun, try with 8.1.0:

 void foo()
 {
   for (;void bar(););
 }

and it gets worse.

It would also need to be only for a non-parenthesized declarator,
which can't be an expression; a parenthesized declarator can be, as in
this well-formed testcase:

bool (bar()) { return 0; } // declaration

void foo()
{
   for (;bool (bar());); // expression
}

Thanks for clarifying that. I'll make sure we have such testcases.

Interestingly, if we aren't careful about that in the new code, 
libstdc++-v3 doesn't even build, eh!


Paolo.

Re: [PATCH][GCC][AArch64] Correct 3 way XOR instructions adding missing patterns.

[Richard Earnshaw (lists)]

On 30/04/18 15:12, Tamar Christina wrote:
> Hi All,
> 
> This patch adds the missing neon intrinsics for all 128 bit vector Integer 
> modes for the
> three-way XOR and negate and xor instructions for Arm8.2-a to Armv8.4-a.
> 
> Bootstrapped and regtested on aarch64-none-linux-gnue and no issues.
> 
> Ok for master? And for backport to the GCC-8 branch?
> 
> gcc/
> 2018-04-30  Tamar Christina  
> 
>   * config/aarch64/aarch64-simd.md (aarch64_eor3qv8hi): Change to
>   eor3q4.
>   (aarch64_bcaxqv8hi): Change to bcaxq4.
>   * config/aarch64/aarch64-simd-builtins.def (veor3q_u8, veor3q_u32,
>   veor3q_u64, veor3q_s8, veor3q_s16, veor3q_s32, veor3q_s64, vbcaxq_u8,
>   vbcaxq_u32, vbcaxq_u64, vbcaxq_s8, vbcaxq_s16, vbcaxq_s32,
>   vbcaxq_s64): New.
>   * config/aarch64/arm_neon.h: Likewise.
>   * config/aarch64/iterators.md (VQ_I): New.
> 
> gcc/testsuite/
> 2018-04-30  Tamar Christina  
> 
>   * gcc.target/gcc.target/aarch64/sha3.h (veor3q_u8, veor3q_u32,
>   veor3q_u64, veor3q_s8, veor3q_s16, veor3q_s32, veor3q_s64, vbcaxq_u8,
>   vbcaxq_u32, vbcaxq_u64, vbcaxq_s8, vbcaxq_s16, vbcaxq_s32,
>   vbcaxq_s64): New.
>   * gcc.target/gcc.target/aarch64/sha3_1.c: Likewise.
>   * gcc.target/gcc.target/aarch64/sha3_1.c: Likewise.
>   * gcc.target/gcc.target/aarch64/sha3_1.c: Likewise.
> 
> Thanks,
> Tamar
> 

As just discussed off-list.  There's no point in marking an operation as
commutative in the register constraints if the constraints are
identical.  If it didn't match with the first ordering of the operands,
swapping them over can't help and just wasted cycles.  So please drop
the redundant % markers.

OK for trunk with that change.

This isn't a regression, so I don't think it warrants a back-port.

R.

> 
> rb9185.patch
> 
> 
> diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def 
> b/gcc/config/aarch64/aarch64-simd-builtins.def
> index 
> b383f2485e5a287c6d833122d6be0c9ff2ef72a2..439d4837fe724b33d4c1bd834570fb464f47eb5b
>  100644
> --- a/gcc/config/aarch64/aarch64-simd-builtins.def
> +++ b/gcc/config/aarch64/aarch64-simd-builtins.def
> @@ -599,14 +599,16 @@
>VAR1 (BINOPU, crypto_sha512su0q, 0, v2di)
>/* Implemented by aarch64_crypto_sha512su1qv2di.  */
>VAR1 (TERNOPU, crypto_sha512su1q, 0, v2di)
> -  /* Implemented by aarch64_eor3qv8hi.  */
> -  VAR1 (TERNOPU, eor3q, 0, v8hi)
> +  /* Implemented by eor3q4.  */
> +  BUILTIN_VQ_I (TERNOPU, eor3q, 4)
> +  BUILTIN_VQ_I (TERNOP, eor3q, 4)
>/* Implemented by aarch64_rax1qv2di.  */
>VAR1 (BINOPU, rax1q, 0, v2di)
>/* Implemented by aarch64_xarqv2di.  */
>VAR1 (TERNOPUI, xarq, 0, v2di)
> -  /* Implemented by aarch64_bcaxqv8hi.  */
> -  VAR1 (TERNOPU, bcaxq, 0, v8hi)
> +  /* Implemented by bcaxq4.  */
> +  BUILTIN_VQ_I (TERNOPU, bcaxq, 4)
> +  BUILTIN_VQ_I (TERNOP, bcaxq, 4)
>  
>/* Implemented by aarch64_fmll_low.  */
>VAR1 (TERNOP, fmlal_low, 0, v2sf)
> diff --git a/gcc/config/aarch64/aarch64-simd.md 
> b/gcc/config/aarch64/aarch64-simd.md
> index 
> 1154fc3d58deaa33413ea3050ff7feec37f092a6..12fea393fa74f04a61c0c81342898dfc0e7228b5
>  100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -5955,13 +5955,13 @@
>  
>  ;; sha3
>  
> -(define_insn "aarch64_eor3qv8hi"
> -  [(set (match_operand:V8HI 0 "register_operand" "=w")
> - (xor:V8HI
> -  (xor:V8HI
> -   (match_operand:V8HI 2 "register_operand" "%w")
> -   (match_operand:V8HI 3 "register_operand" "w"))
> -  (match_operand:V8HI 1 "register_operand" "w")))]
> +(define_insn "eor3q4"
> +  [(set (match_operand:VQ_I 0 "register_operand" "=w")
> + (xor:VQ_I
> +  (xor:VQ_I
> +   (match_operand:VQ_I 2 "register_operand" "%w")
> +   (match_operand:VQ_I 3 "register_operand" "w"))
> +  (match_operand:VQ_I 1 "register_operand" "w")))]
>"TARGET_SIMD && TARGET_SHA3"
>"eor3\\t%0.16b, %1.16b, %2.16b, %3.16b"
>[(set_attr "type" "crypto_sha3")]
> @@ -5991,13 +5991,13 @@
>[(set_attr "type" "crypto_sha3")]
>  )
>  
> -(define_insn "aarch64_bcaxqv8hi"
> -  [(set (match_operand:V8HI 0 "register_operand" "=w")
> - (xor:V8HI
> -  (and:V8HI
> -   (not:V8HI (match_operand:V8HI 3 "register_operand" "w"))
> -   (match_operand:V8HI 2 "register_operand" "w"))
> -  (match_operand:V8HI 1 "register_operand" "w")))]
> +(define_insn "bcaxq4"
> +  [(set (match_operand:VQ_I 0 "register_operand" "=w")
> + (xor:VQ_I
> +  (and:VQ_I
> +   (not:VQ_I (match_operand:VQ_I 3 "register_operand" "w"))
> +   (match_operand:VQ_I 2 "register_operand" "w"))
> +  (match_operand:VQ_I 1 "register_operand" "w")))]
>"TARGET_SIMD && TARGET_SHA3"
>"bcax\\t%0.16b, %1.16b, %2.16b, %3.16b"
>[(set_attr "type" "crypto_sha3")]
> diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
> index 
> 

Re: PR85817

[Jeff Law]

On 05/18/2018 02:49 AM, Prathamesh Kulkarni wrote:
> Hi,
> In r260250, the condition
> 
> if (integer_zerop (retval))
>   continue;
> 
> was added before checking retval was of pointer type which caused
> functions having return type apart from void *, to be marked as
> malloc. The attached patch gets rid of the above check since we do not
> wish to mark function returning NULL as malloc.
> Also, it adds a check to return false if all args to phi are 0,
> although I am not sure if this'd actually trigger in practice since
> constant propagation should have folded the phi into constant 0
> already.
> 
> Bootstrap+test in progress on x86_64-linux-gnu and aarch64-linux-gnu.
> OK to commit if passes ?
So I just checked and it appears this will resolve the riscv64 issue.

The additional marking was ultimately causing the alias analysis code to
narrow the aliasing scope of a local variable that had its address taken
-- to the point where it was no longer considered escaping.

With the variable no longer escaping, calls were no longer may-defs of
the variable and Wuninitialized could perform a more precise analysis
and determined the variable was used potentially uninitialized.

In reality the uninitialized use is guarded in such a way that it won't
be used uninitialized, but without some kind of late inlining the
analysis wouldn't be able to see the use is properly guarded.

With the more restrictive marking, the variable is considered escaping
again and thus is may-def'd by random calls and we don't trigger the
-Wuninitialized warning anymore.


Thanks,
Jeff

Re: RFC (libstdc++): C++ PATCH for c++/58407, C++11 deprecation of implicit copy

[Jonathan Wakely]

On 18/05/18 10:29 -0400, Jason Merrill wrote:

The second patch is some libstdc++ changes to avoid warnings from uses
of the standard library when this warning is on.  More are almost
certainly needed.  Jonathan, how would you like me to handle this WRT
the library?  Check in both patches and let you follow up as needed?


Yes, please go ahead and commit the library patch, we'll deal with the
rest as needed (I'll give myself a TODO to test with -Wdeprecated-copy
and fix what I find).

I'm not sure we need the "Avoid implicit deprecation" comments. Adding
defaulted definitions is good style anyway, so needs no justification.
I'll make sure nobody removes them again in the name of cleaning up
unnecessary noise (which they aren't).

Did you change your mind about leaving the exception hierarchy without
the defautled ops, to get warnings for slicing?

I've just realised that our user-declared destructors on the exception
classes (which exist so we can control where the key function is
emitted) mean they have no implicit move ops. But the standard implies
they should have implicitly-declared move ops (because it doesn't
declare any special members for those classes). I'll open a bug.

Re: [PATCH][AARCH64][PR target/84882] Add mno-strict-align

[Richard Earnshaw (lists)]

On 27/03/18 13:58, Sudakshina Das wrote:
> Hi
> 
> This patch adds the no variant to -mstrict-align and the corresponding
> function attribute. To enable the function attribute, I have modified
> aarch64_can_inline_p () to allow checks even when the callee function
> has no attribute. The need for this is shown by the new test
> target_attr_18.c.
> 
> Testing: Bootstrapped, regtested and added new tests that are copies
> of earlier tests checking -mstrict-align with opposite scan directives.
> 
> Is this ok for trunk?
> 
> Sudi
> 
> 
> *** gcc/ChangeLog ***
> 
> 2018-03-27  Sudakshina Das  
> 
> * common/config/aarch64/aarch64-common.c (aarch64_handle_option):
> Check val before adding MASK_STRICT_ALIGN to opts->x_target_flags.
> * config/aarch64/aarch64.opt (mstrict-align): Remove RejectNegative.
> * config/aarch64/aarch64.c (aarch64_attributes): Mark allow_neg
> as true for strict-align.
> (aarch64_can_inline_p): Perform checks even when callee has no
> attributes to check for strict alignment.
> * doc/extend.texi (AArch64 Function Attributes): Document
> no-strict-align.
> * doc/invoke.texi: (AArch64 Options): Likewise.
> 
> *** gcc/testsuite/ChangeLog ***
> 
> 2018-03-27  Sudakshina Das  
> 
> * gcc.target/aarch64/pr84882.c: New test.
> * gcc.target/aarch64/target_attr_18.c: Likewise.
> 
> strict-align.diff
> 
> 
> diff --git a/gcc/common/config/aarch64/aarch64-common.c 
> b/gcc/common/config/aarch64/aarch64-common.c
> index 7fd9305..d5655a0 100644
> --- a/gcc/common/config/aarch64/aarch64-common.c
> +++ b/gcc/common/config/aarch64/aarch64-common.c
> @@ -97,7 +97,10 @@ aarch64_handle_option (struct gcc_options *opts,
>return true;
>  
>  case OPT_mstrict_align:
> -  opts->x_target_flags |= MASK_STRICT_ALIGN;
> +  if (val)
> + opts->x_target_flags |= MASK_STRICT_ALIGN;
> +  else
> + opts->x_target_flags &= ~MASK_STRICT_ALIGN;
>return true;
>  
>  case OPT_momit_leaf_frame_pointer:
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 4b5183b..4f35a6c 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -11277,7 +11277,7 @@ static const struct aarch64_attribute_info 
> aarch64_attributes[] =
>{ "fix-cortex-a53-843419", aarch64_attr_bool, true, NULL,
>   OPT_mfix_cortex_a53_843419 },
>{ "cmodel", aarch64_attr_enum, false, NULL, OPT_mcmodel_ },
> -  { "strict-align", aarch64_attr_mask, false, NULL, OPT_mstrict_align },
> +  { "strict-align", aarch64_attr_mask, true, NULL, OPT_mstrict_align },
>{ "omit-leaf-frame-pointer", aarch64_attr_bool, true, NULL,
>   OPT_momit_leaf_frame_pointer },
>{ "tls-dialect", aarch64_attr_enum, false, NULL, OPT_mtls_dialect_ },
> @@ -11640,16 +11640,13 @@ aarch64_can_inline_p (tree caller, tree callee)
>tree caller_tree = DECL_FUNCTION_SPECIFIC_TARGET (caller);
>tree callee_tree = DECL_FUNCTION_SPECIFIC_TARGET (callee);
>  
> -  /* If callee has no option attributes, then it is ok to inline.  */
> -  if (!callee_tree)
> -return true;

I think it's still useful to spot the case where both callee_tree and
caller_tree are NULL.  In that case both options will pick up
target_option_default_node and will always be compatible; so you can
short-circuit that case, which is the most likely scenario.

> -
>struct cl_target_option *caller_opts
>   = TREE_TARGET_OPTION (caller_tree ? caller_tree
>  : target_option_default_node);
>  
> -  struct cl_target_option *callee_opts = TREE_TARGET_OPTION (callee_tree);
> -
> +  struct cl_target_option *callee_opts
> + = TREE_TARGET_OPTION (callee_tree ? callee_tree
> +: target_option_default_node);
>  
>/* Callee's ISA flags should be a subset of the caller's.  */
>if ((caller_opts->x_aarch64_isa_flags & callee_opts->x_aarch64_isa_flags)
> diff --git a/gcc/config/aarch64/aarch64.opt b/gcc/config/aarch64/aarch64.opt
> index 52eaf8c..1426b45 100644
> --- a/gcc/config/aarch64/aarch64.opt
> +++ b/gcc/config/aarch64/aarch64.opt
> @@ -85,7 +85,7 @@ Target RejectNegative Joined Enum(cmodel) 
> Var(aarch64_cmodel_var) Init(AARCH64_C
>  Specify the code model.
>  
>  mstrict-align
> -Target Report RejectNegative Mask(STRICT_ALIGN) Save
> +Target Report Mask(STRICT_ALIGN) Save
>  Don't assume that unaligned accesses are handled by the system.
>  
>  momit-leaf-frame-pointer
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 93a0ebc..dcda216 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -3605,8 +3605,10 @@ for the command line option @option{-mcmodel=}.
>  @item strict-align

Other targets add an @itemx for the no-variant.

>  @cindex @code{strict-align} function attribute, AArch64
>  Indicates that the compiler should not assume that unaligned memory 
> references
> -are handled by the system.  The 

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

[Jason Merrill]

On Fri, May 18, 2018 at 10:30 AM, Paolo Carlini
 wrote:
> Hi,
>
> On 18/05/2018 16:19, Jason Merrill wrote:
>>
>> On Fri, May 18, 2018 at 10:05 AM, Paolo Carlini
>>  wrote:
>>>
>>> Hi,
>>>
>>> On 18/05/2018 15:56, Jason Merrill wrote:

 I had in mind moving the call to cp_parser_check_condition_declarator
 into the block controlled by cp_parser_parse_definitely; this is a
 semantic check that should follow the syntactic checks.  If there's no
 initializer, it doesn't parse as a condition declaration, so we don't
 want to complain about it being a semantically invalid condition
 declaration.
>>>
>>> If we do that we are back to something very, very, similar to what I
>>> posted
>>> at the beginning of the thread, right? Therefore, for all the testcases
>>> which don't have an initializer we end-up with *horrible*, literally
>>> *horrible* cascades of errors, plus we ICE on the c++/84588 variants
>>> without
>>> an initializer.
>>
>> Ah.  Why is that?
>>
>> I guess it's desirable to also give this error when the declarator is
>> followed by ) or ; rather than other tokens that could be more
>> expression (like in A(a).x in the comment).
>
> I can certainly try to implement this, maybe just something minimal to begin
> with, as you say ) or ; alone would be safe and would already take care of
> all the tests I have around.
>
> Certainly, unconditionally deferring at that point to cp_parser_expression
> leads to *very* bad error-recovery. For fun, try with 8.1.0:
>
> void foo()
> {
>   for (;void bar(););
> }
>
> and it gets worse.

It would also need to be only for a non-parenthesized declarator,
which can't be an expression; a parenthesized declarator can be, as in
this well-formed testcase:

bool (bar()) { return 0; } // declaration

void foo()
{
  for (;bool (bar());); // expression
}

Jason

RFC (libstdc++): C++ PATCH for c++/58407, C++11 deprecation of implicit copy

[Jason Merrill]

C++11 specified that the implicitly-declared copy constructor and
assignment operator are deprecated if one of them, or the destructor,
is user-provided.  This patch implements that; I've recently been
fixing some uses in the compiler of those deprecated copies.

Rather than bundle this into -Wdeprecated-declarations, I've
introduced a new -Wdeprecated-copy so that people can turn off this
specific deprecation if it causes problems for them; it certainly
complains about a lot of the G++ and libstdc++ testsuite.  But in this
patch it's enabled by -Wall.

We don't warn about elided copies from a temporary, as in that case no
actual copy is occurring; this is particularly important in the
context of C++17 mandatory copy elision, but makes sense under all
standards.

I've changed cp_warn_deprecated_use to handle all the checks for
whether we actually want the warning rather than repeat them at every
call site.

I needed to change build_aggr_init to only set TREE_USED if the
initialization has some effect so that libgomp.c++/ctor-5.C wouldn't
break with an error about threadprivate after the variable has been
used.

The second patch is some libstdc++ changes to avoid warnings from uses
of the standard library when this warning is on.  More are almost
certainly needed.  Jonathan, how would you like me to handle this WRT
the library?  Check in both patches and let you follow up as needed?
Hold off until you've had a chance to make the necessary library
changes?

Tested x86_64-pc-linux-gnu.
commit a785eb5aa4898eff68af834a08d88577bf7685d9
Author: Jason Merrill 
Date:   Tue May 15 17:42:34 2018 -0400

PR c++/58407 - deprecated implicit copy ops.

* call.c (build_over_call): Warn about deprecated trivial fns.
* class.c (classtype_has_user_copy_or_dtor): New.
(type_build_ctor_call): Check TREE_DEPRECATED.
(type_build_dtor_call): Likewise.
* decl2.c (cp_warn_deprecated_use): Move from tree.c.
Add checks.  Return bool.  Handle -Wdeprecated-copy.
(mark_used): Use it.
* decl.c (grokdeclarator): Remove redundant checks.
* typeck2.c (build_functional_cast): Likewise.
* method.c (lazily_declare_fn): Mark deprecated copy ops.
* init.c (build_aggr_init): Only set TREE_USED if there are
side-effects.

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index c48d6dced8d..5114543c128 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -464,6 +464,11 @@ Wdeprecated
 C C++ ObjC ObjC++ CPP(cpp_warn_deprecated) CppReason(CPP_W_DEPRECATED) Var(warn_deprecated) Init(1) Warning
 Warn if a deprecated compiler feature, class, method, or field is used.
 
+Wdeprecated-copy
+C++ ObjC++ Var(warn_deprecated_copy) Warning LangEnabledBy(C++ ObjC++, Wall)
+Mark implicitly-declared copy operations as deprecated if the class has a
+user-provided copy operation or destructor.
+
 Wdesignated-init
 C ObjC Var(warn_designated_init) Init(1) Warning
 Warn about positional initialization of structs requiring designated initializers.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 4d04785f2b9..1df4d14dfe6 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8168,21 +8168,30 @@ build_over_call (struct z_candidate *cand, int flags, tsubst_flags_t complain)
 		/* See unsafe_copy_elision_p.  */
 		|| DECL_BASE_CONSTRUCTOR_P (fn));
 
-  /* [class.copy]: the copy constructor is implicitly defined even if
-	 the implementation elided its use.  */
-  if (!trivial && !force_elide)
+  fa = argarray[0];
+  bool unsafe = unsafe_copy_elision_p (fa, arg);
+  bool eliding_temp = (TREE_CODE (arg) == TARGET_EXPR && !unsafe);
+
+  /* [class.copy]: the copy constructor is implicitly defined even if the
+	 implementation elided its use.  But don't warn about deprecation when
+	 eliding a temporary, as then no copy is actually performed.  */
+  warning_sentinel s (warn_deprecated_copy, eliding_temp);
+  if (force_elide)
+	/* The language says this isn't called.  */;
+  else if (!trivial)
 	{
 	  if (!mark_used (fn, complain) && !(complain & tf_error))
 	return error_mark_node;
 	  already_used = true;
 	}
+  else
+	cp_warn_deprecated_use (fn, complain);
 
   /* If we're creating a temp and we already have one, don't create a
 	 new one.  If we're not creating a temp but we get one, use
 	 INIT_EXPR to collapse the temp into our target.  Otherwise, if the
 	 ctor is trivial, do a bitwise copy with a simple TARGET_EXPR for a
 	 temp or an INIT_EXPR otherwise.  */
-  fa = argarray[0];
   if (is_dummy_object (fa))
 	{
 	  if (TREE_CODE (arg) == TARGET_EXPR)
@@ -8191,7 +8200,7 @@ build_over_call (struct z_candidate *cand, int flags, tsubst_flags_t complain)
 	return force_target_expr (DECL_CONTEXT (fn), arg, complain);
 	}
   else if ((trivial || TREE_CODE (arg) == TARGET_EXPR)
-	   && !unsafe_copy_elision_p (fa, arg))
+	  

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

[Paolo Carlini]

Hi,

On 18/05/2018 16:19, Jason Merrill wrote:

On Fri, May 18, 2018 at 10:05 AM, Paolo Carlini
 wrote:

Hi,

On 18/05/2018 15:56, Jason Merrill wrote:

I had in mind moving the call to cp_parser_check_condition_declarator
into the block controlled by cp_parser_parse_definitely; this is a
semantic check that should follow the syntactic checks.  If there's no
initializer, it doesn't parse as a condition declaration, so we don't
want to complain about it being a semantically invalid condition
declaration.

If we do that we are back to something very, very, similar to what I posted
at the beginning of the thread, right? Therefore, for all the testcases
which don't have an initializer we end-up with *horrible*, literally
*horrible* cascades of errors, plus we ICE on the c++/84588 variants without
an initializer.

Ah.  Why is that?

I guess it's desirable to also give this error when the declarator is
followed by ) or ; rather than other tokens that could be more
expression (like in A(a).x in the comment).
I can certainly try to implement this, maybe just something minimal to 
begin with, as you say ) or ; alone would be safe and would already take 
care of all the tests I have around.


Certainly, unconditionally deferring at that point to 
cp_parser_expression leads to *very* bad error-recovery. For fun, try 
with 8.1.0:


    void foo()
    {
      for (;void bar(););
    }

and it gets worse.

Paolo.

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

[Jason Merrill]

On Fri, May 18, 2018 at 10:05 AM, Paolo Carlini
 wrote:
> Hi,
>
> On 18/05/2018 15:56, Jason Merrill wrote:
>>
>> I had in mind moving the call to cp_parser_check_condition_declarator
>> into the block controlled by cp_parser_parse_definitely; this is a
>> semantic check that should follow the syntactic checks.  If there's no
>> initializer, it doesn't parse as a condition declaration, so we don't
>> want to complain about it being a semantically invalid condition
>> declaration.
>
> If we do that we are back to something very, very, similar to what I posted
> at the beginning of the thread, right? Therefore, for all the testcases
> which don't have an initializer we end-up with *horrible*, literally
> *horrible* cascades of errors, plus we ICE on the c++/84588 variants without
> an initializer.

Ah.  Why is that?

I guess it's desirable to also give this error when the declarator is
followed by ) or ; rather than other tokens that could be more
expression (like in A(a).x in the comment).

Jason

Re: [PATCH][RFC] Radically simplify emission of balanced tree for switch statements.

[Martin Liška]

On 05/18/2018 03:55 PM, Rainer Orth wrote:
> Hi Martin,
> 
>> So the patch looks fine, only very very slightly binary is produced. I'm
>> going to install the patch so that
>> I can carry on more complex patches based on this one.
> 
> it seems you didn't properly test the testsuite part: I see
> 
> +UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower 
> "Removing basic block"
> +UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower 
> "loop depth 1, count 3"
> +UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump-not switchlower 
> "Invalid sum"
> +UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump-not switchlower 
> "loop depth 1, count 2"
> 
> everywhere.  The log has
> 
> gcc.dg/tree-prof/update-loopch.c: dump file does not exist
> 
> Obviously you forgot the adapt the dg-final* files for the dumpfile
> name.  If I do, three of the failures go away, but
> 
> FAIL: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1 "Removing 
> basic block"
> 
> remains (on 32 and 64-bit Linux/x86_64).
> 
> Please fix.
> 
>   Rainer
> 

Thanks for opened eyes, following patch will fix that.
It's quite obvious, I'll install it right after tests will finish.

Martin
>From 7ae0c7d4a81166dbf5e9dff5d35e4c9d63b1c058 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 18 May 2018 16:17:57 +0200
Subject: [PATCH] Remove redundand pass pass_lower_switch.

gcc/ChangeLog:

2018-05-18  Martin Liska  

	* passes.def: Remove a redundant pass.
---
 gcc/passes.def | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/passes.def b/gcc/passes.def
index 050009464ea..055d354f959 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -399,9 +399,8 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_lower_vaarg);
   NEXT_PASS (pass_lower_vector);
   NEXT_PASS (pass_lower_complex_O0);
-  NEXT_PASS (pass_lower_switch_O0);
   NEXT_PASS (pass_sancov_O0);
-  NEXT_PASS (pass_lower_switch);
+  NEXT_PASS (pass_lower_switch_O0);
   NEXT_PASS (pass_asan_O0);
   NEXT_PASS (pass_tsan_O0);
   NEXT_PASS (pass_sanopt);
-- 
2.16.3

Re: Aliasing 'this' in a C++ constructor

[Nathan Sidwell]

On 05/18/2018 10:12 AM, Jakub Jelinek wrote:


Or is it invalid to dereference s before it has been constructed?


Yes, Marc found:

"During the construction of an object, if the value of the object or any 
of its subobjects is accessed through a glvalue that is not obtained, 
directly or indirectly, from the constructor’s this pointer, the value 
of the object or subobject thus obtained is unspecified."


nathan
--
Nathan Sidwell

Re: Aliasing 'this' in a C++ constructor

[Jakub Jelinek]

On Fri, May 18, 2018 at 09:57:42AM -0400, Jason Merrill wrote:
> > But what is invalid on:
> > struct S { int foo (S *); int a; } s { 2 };
> > int S::foo (S *x)
> > {
> >   int b = this->a;
> >   x->a = 5;
> >   b += this->a;
> >   return b;
> > }
> > int main ()
> > {
> >   if (s.foo () != 7)
> > abort ();
> > }
> >
> > I think if you make this a restrict pointer, this will be miscompiled.
> 
> We're only talking about the 'this' pointer in a constructor, not a
> normal member function like foo.

Oops, sorry, missed that.
Make it then:

struct S { S (S *); int a; } s ();
S::S (S *s)
{
  this->a = 2;
  s->a = 3;
  if (this->a != 3)
abort ();
}

Or is it invalid to dereference s before it has been constructed?

Jakub

Re: [PATCH] Support lower and upper limit for -fdbg-cnt flag.

[Rainer Orth]

Hi Martin,

> On 05/16/2018 03:39 PM, Alexander Monakov wrote:
>> On Wed, 16 May 2018, Martin Liška wrote:
 Hm, is the off-by-one in the new explanatory text really intended? I think
 the previous text was accurate, and the new text should say "9th and 10th"
 and then "first 10 invocations", unless I'm missing something?
>>>
>>> I've reconsidered that once more time and having zero-based values:
>>> * -fdbg-cnt=event:N - trigger event N-times
>>> * -fdbg-cnt=event:N:(N+M) - skip even N-times and then enable it M-1 times
>>>
>>> Does that make sense?
>> 
>> Yes, I like this, but I think the implementation does not match. New docs 
>> say:
>> 
>>> -For example, with @option{-fdbg-cnt=dce:10,tail_call:0},
>>> -@code{dbg_cnt(dce)} returns true only for first 10 invocations.
>>> +For example, with @option{-fdbg-cnt=dce:2:4,tail_call:10},
>>> +@code{dbg_cnt(dce)} returns true only for third and fourth invocation.
>>> +For @code{dbg_cnt(tail_call)} true is returned for first 10 invocations.
>> 
>> which is good, but the implementation reads:
>> 
>>>  bool
>>>  dbg_cnt_is_enabled (enum debug_counter index)
>>>  {
>>> -  return count[index] <= limit[index];
>>> +  unsigned v = count[index];
>>> +  return v >= limit_low[index] && v < limit_high[index];
>>>  }
>> 
>> which I believe is misaligned with the docs' intention. It should be the
>> other way around:
>> 
>>   return v > limit_low[index] && v <= limit_high[index];
>
> Note that I changed count[index]++ to happen after dbg_cnt_is_enabled. I'm
> reverting that
> and now it works fine with your condition.

I'm seeing a testsuite regression for

+FAIL: gcc.dg/pr68766.c (test for excess errors)

on 32 and 64-bit Solaris/x86, Linux/x86_64, also seen on i686-pc-linux-gnu,
powerpc64le-unknown-linux-gnu.

Excess errors:
dbg_cnt 'vect_loop' set to 0-1

Either the adjustment to gcc.dg/pr68766.c is wrong or not generic.

Please fix.

Rainer

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

Re: Aliasing 'this' in a C++ constructor

[Nathan Sidwell]

On 05/18/2018 09:21 AM, Marc Glisse wrote:

what about comparisons to this?  I thought restrict implied such a 
comparison was 'never the same'?


ie. if the ctor was:
 selfie (selfie *ptr) : me (ptr==this ? 0 : ptr) {}


It is tempting to think so, but I don't see any language to that effect.


Ok then, thanks for the explanations.

nathan

--
Nathan Sidwell

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

[Paolo Carlini]

Hi,

On 18/05/2018 15:56, Jason Merrill wrote:

I had in mind moving the call to cp_parser_check_condition_declarator
into the block controlled by cp_parser_parse_definitely; this is a
semantic check that should follow the syntactic checks.  If there's no
initializer, it doesn't parse as a condition declaration, so we don't
want to complain about it being a semantically invalid condition
declaration.
If we do that we are back to something very, very, similar to what I 
posted at the beginning of the thread, right? Therefore, for all the 
testcases which don't have an initializer we end-up with *horrible*, 
literally *horrible* cascades of errors, plus we ICE on the c++/84588 
variants without an initializer. If you like we can do that and defer 
the other related issues - strictly speaking c++/84588 would be fixed - 
to another new bug.


Paolo.

Re: Aliasing 'this' in a C++ constructor

[Marc Glisse]

On Fri, 18 May 2018, Jakub Jelinek wrote:


On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote:

On 05/18/2018 08:53 AM, Marc Glisse wrote:


As long as you do not dereference ptr in the constructor, that shouldn't
contradict 'restrict'. The PR gives this quote from the standard:

"During the construction of an object, if the value of the object or any
of its subobjects is accessed through a glvalue that is not obtained,
directly or indirectly, from the constructor’s this pointer, the value
of the object or subobject thus obtained is unspecified."

which reads quite close to saying that 'this' is restrict.

Indeed it is, thanks.

what about comparisons to this?  I thought restrict implied such a
comparison was 'never the same'?

ie. if the ctor was:
  selfie (selfie *ptr) : me (ptr==this ? 0 : ptr) {}


But what is invalid on:
struct S { int foo (S *); int a; } s { 2 };
int S::foo (S *x)
{
 int b = this->a;
 x->a = 5;
 b += this->a;
 return b;
}
int main ()
{
 if (s.foo () != 7)
   abort ();
}

I think if you make this a restrict pointer, this will be miscompiled.


The patch is only for constructors, not for all member functions.

--
Marc Glisse

Re: Aliasing 'this' in a C++ constructor

[Jason Merrill]

On Fri, May 18, 2018 at 9:53 AM, Jakub Jelinek  wrote:
> On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote:
>> On 05/18/2018 08:53 AM, Marc Glisse wrote:
>>
>> > As long as you do not dereference ptr in the constructor, that shouldn't
>> > contradict 'restrict'. The PR gives this quote from the standard:
>> >
>> > "During the construction of an object, if the value of the object or any
>> > of its subobjects is accessed through a glvalue that is not obtained,
>> > directly or indirectly, from the constructor’s this pointer, the value
>> > of the object or subobject thus obtained is unspecified."
>> >
>> > which reads quite close to saying that 'this' is restrict.
>> Indeed it is, thanks.
>>
>> what about comparisons to this?  I thought restrict implied such a
>> comparison was 'never the same'?
>>
>> ie. if the ctor was:
>>   selfie (selfie *ptr) : me (ptr==this ? 0 : ptr) {}
>
> But what is invalid on:
> struct S { int foo (S *); int a; } s { 2 };
> int S::foo (S *x)
> {
>   int b = this->a;
>   x->a = 5;
>   b += this->a;
>   return b;
> }
> int main ()
> {
>   if (s.foo () != 7)
> abort ();
> }
>
> I think if you make this a restrict pointer, this will be miscompiled.

We're only talking about the 'this' pointer in a constructor, not a
normal member function like foo.

Jason

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

[Jason Merrill]

On Fri, May 18, 2018 at 4:41 AM, Paolo Carlini  wrote:
> Hi,
>
>>> On 18/05/2018 01:21, Jason Merrill wrote:

 On Thu, May 17, 2018 at 5:54 PM, Paolo Carlini
  wrote:
>
> On 17/05/2018 16:58, Jason Merrill wrote:
>>
>> On Thu, May 17, 2018 at 10:27 AM, Paolo Carlini
>>  wrote:
>>>
>>> PS: maybe better using function_declarator_p?
>>
>> I think so, yes.  The relevant rule seems to be "The declarator shall
>> not specify a function or an array.", so let's check for arrays, too.
>
> Agreed. I had the amended patch ready when I noticed (again) that it
> wasn't
> addressing another related class of issues which involves declarators
> not
> followed by initializers. Thus I tried to fix those too, and the below
> which
> moves the check up appears to work fine, passes testing, etc. Are there
> any
> risks that an erroneous function / array as declarator is in fact a
> well
> formed expression?!?

 That doesn't matter; if it parses as a declarator, it's a declarator,
 even if it's an ill-formed declarator.  But...

 +  bool decl_p = cp_parser_parse_definitely (parser);
 +  if (!cp_parser_check_condition_declarator (parser, declarator,
 loc))
 +return error_mark_node;

 ...if cp_parser_parse_definitely returns false, parsing as a
 declarator failed, so we shouldn't look at "declarator".
>
> What I'm attaching below isn't affected by this problem: I moved the check
> further up - *before* maybe calling cp_parser_simulated_error because an
> initializer isn't in sight - and is carried out only when
> !cp_parser_error_occurred, thus cp_parser_declarator succeeded .
> cp_parser_commit_to_tentative_parse is called when the check fails.
> Bootstrapped and tested on x86_64-linux.

I had in mind moving the call to cp_parser_check_condition_declarator
into the block controlled by cp_parser_parse_definitely; this is a
semantic check that should follow the syntactic checks.  If there's no
initializer, it doesn't parse as a condition declaration, so we don't
want to complain about it being a semantically invalid condition
declaration.

Jason

Re: [PATCH][RFC] Radically simplify emission of balanced tree for switch statements.

[Rainer Orth]

Hi Martin,

> So the patch looks fine, only very very slightly binary is produced. I'm
> going to install the patch so that
> I can carry on more complex patches based on this one.

it seems you didn't properly test the testsuite part: I see

+UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower 
"Removing basic block"
+UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower "loop 
depth 1, count 3"
+UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump-not switchlower 
"Invalid sum"
+UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-dump-not switchlower 
"loop depth 1, count 2"

everywhere.  The log has

gcc.dg/tree-prof/update-loopch.c: dump file does not exist

Obviously you forgot the adapt the dg-final* files for the dumpfile
name.  If I do, three of the failures go away, but

FAIL: gcc.dg/tree-prof/update-loopch.c scan-tree-dump switchlower1 "Removing 
basic block"

remains (on 32 and 64-bit Linux/x86_64).

Please fix.

Rainer

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

Re: Aliasing 'this' in a C++ constructor

[Jakub Jelinek]

On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote:
> On 05/18/2018 08:53 AM, Marc Glisse wrote:
> 
> > As long as you do not dereference ptr in the constructor, that shouldn't
> > contradict 'restrict'. The PR gives this quote from the standard:
> > 
> > "During the construction of an object, if the value of the object or any
> > of its subobjects is accessed through a glvalue that is not obtained,
> > directly or indirectly, from the constructor’s this pointer, the value
> > of the object or subobject thus obtained is unspecified."
> > 
> > which reads quite close to saying that 'this' is restrict.
> Indeed it is, thanks.
> 
> what about comparisons to this?  I thought restrict implied such a
> comparison was 'never the same'?
> 
> ie. if the ctor was:
>   selfie (selfie *ptr) : me (ptr==this ? 0 : ptr) {}

But what is invalid on:
struct S { int foo (S *); int a; } s { 2 };
int S::foo (S *x)
{
  int b = this->a;
  x->a = 5;
  b += this->a;
  return b;
}
int main ()
{
  if (s.foo () != 7)
abort ();
}

I think if you make this a restrict pointer, this will be miscompiled.

Jakub

Re: PR85817

[Jeff Law]

On 05/18/2018 02:49 AM, Prathamesh Kulkarni wrote:
> Hi,
> In r260250, the condition
> 
> if (integer_zerop (retval))
>   continue;
> 
> was added before checking retval was of pointer type which caused
> functions having return type apart from void *, to be marked as
> malloc. The attached patch gets rid of the above check since we do not
> wish to mark function returning NULL as malloc.
> Also, it adds a check to return false if all args to phi are 0,
> although I am not sure if this'd actually trigger in practice since
> constant propagation should have folded the phi into constant 0
> already.
> 
> Bootstrap+test in progress on x86_64-linux-gnu and aarch64-linux-gnu.
> OK to commit if passes ?
FWIW, I'm currently digging into a bootstrap failure on riscv64 that is
triggered by the original change to allow functions returning NULL to
potentially be malloc candidates.  I'll give things a spin with this
patch as well.

jeff

Re: Aliasing 'this' in a C++ constructor

[Jason Merrill]

On Fri, May 18, 2018 at 8:34 AM, Marc Glisse  wrote:
> On Fri, 18 May 2018, Richard Biener wrote:
>> On Fri, May 18, 2018 at 2:25 PM Marc Glisse  wrote:
>>
>>> this lets alias analysis handle the implicit 'this' parameter in C++
>>> constructors as if it was restrict.
>>
>> OK.  Please give C++ folks the chance to chime in on the semantics.
>
> (Cc: said C++ folks)

I suppose it's technically valid to write something like

void f()
{
  A a;
  a.~A();
  new () A(a);
}

but that's pretty pathological and useless, so I'm not concerned about
messing with it.

Jason

[COMMITTED, AARCH64, SVE TESTSUITE] Remove a couple of xfail from slp_5.c

[Sudi Das]

Hi

Since Richard Biener's commit from 16th May:

commit 2f05c3c7324cd293b7b2ba197e0a88d9749361cc
Author: rguenth 
Date:   Wed May 16 13:08:04 2018 +

the test case slp_5.c had started showing a couple of XPASS failures.
XPASS: gcc.target/aarch64/sve/slp_5.c -march=armv8.2-a+sve  scan-assembler-not 
\\tld2d\\t
XPASS: gcc.target/aarch64/sve/slp_5.c -march=armv8.2-a+sve  
scan-assembler-times \\tld1d\\t 3

Richard Sandiford helped to confirm that these xfails can now be
removed since the said commit fixed the issue that was preventing the
expected behavior. This patch does the same.

Testing done: Only test case change, so only ran the testcase on 
aarch64-none-linux-gnu.

Committed as an obvious fix.

Thanks
Sudi

*** gcc/testsuite/ChangeLog ***

2018-05-18  Sudakshina Das  

    * gcc.target/aarch64/sve/slp_5.c: Remove xfail for tld1d and tld2d.diff --git a/gcc/testsuite/gcc.target/aarch64/sve/slp_5.c b/gcc/testsuite/gcc.target/aarch64/sve/slp_5.c
index 7ff12c5..b75edc69e 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/slp_5.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/slp_5.c
@@ -42,11 +42,11 @@ TEST_ALL (VEC_PERM)
 /* { dg-final { scan-assembler-times {\tld1b\t} 1 } } */
 /* { dg-final { scan-assembler-times {\tld1h\t} 2 } } */
 /* { dg-final { scan-assembler-times {\tld1w\t} 3 } } */
-/* { dg-final { scan-assembler-times {\tld1d\t} 3 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times {\tld1d\t} 3 } } */
 /* { dg-final { scan-assembler-not {\tld2b\t} } } */
 /* { dg-final { scan-assembler-not {\tld2h\t} } } */
 /* { dg-final { scan-assembler-not {\tld2w\t} } } */
-/* { dg-final { scan-assembler-not {\tld2d\t} { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not {\tld2d\t} } } */
 /* { dg-final { scan-assembler-times {\tuaddv\td[0-9]+, p[0-7], z[0-9]+\.b} 4 { xfail *-*-* } } } */
 /* { dg-final { scan-assembler-times {\tuaddv\td[0-9]+, p[0-7], z[0-9]+\.h} 4 { xfail *-*-* } } } */
 /* { dg-final { scan-assembler-times {\tuaddv\td[0-9]+, p[0-7], z[0-9]+\.b} 2 } } */

Re: Aliasing 'this' in a C++ constructor

[Marc Glisse]

On Fri, 18 May 2018, Nathan Sidwell wrote:


On 05/18/2018 08:53 AM, Marc Glisse wrote:

As long as you do not dereference ptr in the constructor, that shouldn't 
contradict 'restrict'. The PR gives this quote from the standard:


"During the construction of an object, if the value of the object or any of 
its subobjects is accessed through a glvalue that is not obtained, directly 
or indirectly, from the constructor’s this pointer, the value of the object 
or subobject thus obtained is unspecified."


which reads quite close to saying that 'this' is restrict.

Indeed it is, thanks.

what about comparisons to this?  I thought restrict implied such a comparison 
was 'never the same'?


ie. if the ctor was:
 selfie (selfie *ptr) : me (ptr==this ? 0 : ptr) {}


It is tempting to think so, but I don't see any language to that effect.

C11 has this example:

void h(int n, int * restrict p, int * restrict q, int * restrict r)
{
  int i;
  for (i = 0; i < n; i++)
p[i] = q[i] + r[i];
}
h(100, a, b, b) --> valid (because no write)

We have https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962 about using 
alias information to simplify pointer comparisons.


--
Marc Glisse

Re: [PATCH][RFC] Add dynamic edge/bb flag allocation

[David Malcolm]

On Fri, 2018-05-18 at 13:11 +0200, Richard Biener wrote:
> The following adds a simple alloc/free_flag machinery allocating
> bits from an int typed pool and applies that to bb->flags and edge-
> >flags.
> This should allow infrastructure pieces to use egde/bb flags
> temporarily
> without worrying that users might already use it as for example
> BB_VISITED and friends.  It converts one clever user to the new
> interface.
> 
> The allocation state is per CFG but we could also make it global
> or merge the two pools so one allocates a flag that can be used for
> bbs and edges at the same time.
> 
> Thus - any opinions welcome.  I'm mainly targeting cfganal algorithms
> where I want to add a few region-based ones that to be O(region-size)
> complexity may not use sbitmaps for visited sets because of the
> clearing
> overhead and bitmaps are probably more expensive to use than a
> BB/edge
> flag that needs to be cleared afterwards.
> 
> Built on x86_64, otherwise untested.
> 
> Any comments?

Rather than putting alloc/free pairs at the usage sites, how about an
RAII class?  Something like this:

class auto_edge_flag
{
public:
   auto_edge_flag (function *fun)
   : m_flag (alloc_edge_flag (fun)), m_fun (fun)
   {}

   ~auto_edge_flag ()
   {
  free_edge_flag (m_fun, m_flag);
   }

   operator int () const { return m_flag; }

private:
  int m_flag;
  function *m_fun;
};


> Templating the core flag allocator comes to my mind (up to max
> HOST_WIDE_INT) as well as moving the implementation elsewhere
> (hwi.h?).

Maybe wrap the data type up in a class?  Passing around an "int *"
seemed a bit low-level to me.  (But maybe that's me overthinking it)

[...snip...]

> diff --git a/gcc/cfgloop.c b/gcc/cfgloop.c
> index 8af793c6015..64ad42c83ca 100644
> --- a/gcc/cfgloop.c
> +++ b/gcc/cfgloop.c
> @@ -1539,6 +1539,7 @@ verify_loop_structure (void)
>/* Check irreducible loops.  */
>if (loops_state_satisfies_p
> (LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS))
>  {
> +  int saved_irr_mask = alloc_edge_flag (cfun);

 auto_edge_flag saved_irr_mask (cfun);

[...snip...]


Dave

Re: [PATCH] gcov: add new option -t that prints output to stdout (PR gcov-profile/84846).

[Martin Liška]

On 05/18/2018 02:46 PM, Nathan Sidwell wrote:
> On 05/18/2018 08:29 AM, Martin Liška wrote:
>> Hi.
>>
>> It's requested by LCOV folks, they want to be able to print to stdout
>> instead of into a file.
>>
>> Survives make check -k -j10 RUNTESTFLAGS="gcov.exp"
> 
> I guess you looked at abstracting the output file a bit earlier, and passing 
> in a FILE* to the outputting routines?  That would be nicer, but if not 
> practical, this is ok.

Would be nice, but as we have quite some prologue and epilogue for file 
creation, let me please install the patch.

Thanks,
Martin

> 
> nathan
> 

Re: Aliasing 'this' in a C++ constructor

[Nathan Sidwell]

On 05/18/2018 08:53 AM, Marc Glisse wrote:

As long as you do not dereference ptr in the constructor, that shouldn't 
contradict 'restrict'. The PR gives this quote from the standard:


"During the construction of an object, if the value of the object or any 
of its subobjects is accessed through a glvalue that is not obtained, 
directly or indirectly, from the constructor’s this pointer, the value 
of the object or subobject thus obtained is unspecified."


which reads quite close to saying that 'this' is restrict.

Indeed it is, thanks.

what about comparisons to this?  I thought restrict implied such a 
comparison was 'never the same'?


ie. if the ctor was:
  selfie (selfie *ptr) : me (ptr==this ? 0 : ptr) {}

nathan

--
Nathan Sidwell

Re: Aliasing 'this' in a C++ constructor

[Marc Glisse]

On Fri, 18 May 2018, Nathan Sidwell wrote:


On 05/18/2018 08:34 AM, Marc Glisse wrote:

(Cc: said C++ folks)

On Fri, 18 May 2018, Richard Biener wrote:


On Fri, May 18, 2018 at 2:25 PM Marc Glisse  wrote:


Hello,



this lets alias analysis handle the implicit 'this' parameter in C++
constructors as if it was restrict.


I think the following bizarre code is nevertheless well-formed:

struct selfie {
 selfie *me;
 selfie (selfie *ptr) : me (ptr) {}
};

selfie bob ();


As long as you do not dereference ptr in the constructor, that shouldn't 
contradict 'restrict'. The PR gives this quote from the standard:


"During the construction of an object, if the value of the object or any 
of its subobjects is accessed through a glvalue that is not obtained, 
directly or indirectly, from the constructor’s this pointer, the value of 
the object or subobject thus obtained is unspecified."


which reads quite close to saying that 'this' is restrict.

--
Marc Glisse

Re: [PATCH] gcov: add new option -t that prints output to stdout (PR gcov-profile/84846).

[Nathan Sidwell]

On 05/18/2018 08:29 AM, Martin Liška wrote:

Hi.

It's requested by LCOV folks, they want to be able to print to stdout
instead of into a file.

Survives make check -k -j10 RUNTESTFLAGS="gcov.exp"


I guess you looked at abstracting the output file a bit earlier, and 
passing in a FILE* to the outputting routines?  That would be nicer, but 
if not practical, this is ok.


nathan

--
Nathan Sidwell

Re: [PATCH] Print working directory to gcov files (PR gcov-profile/84846).

[Nathan Sidwell]

On 05/18/2018 08:42 AM, Martin Liška wrote:

V2: pwd is renamed to cwd, which is a better name.

Martin



ok thanks.

nathan

--
Nathan Sidwell

Re: Aliasing 'this' in a C++ constructor

[Nathan Sidwell]

On 05/18/2018 08:34 AM, Marc Glisse wrote:

(Cc: said C++ folks)

On Fri, 18 May 2018, Richard Biener wrote:


On Fri, May 18, 2018 at 2:25 PM Marc Glisse  wrote:


Hello,



this lets alias analysis handle the implicit 'this' parameter in C++
constructors as if it was restrict.


I think the following bizarre code is nevertheless well-formed:

struct selfie {
  selfie *me;
  selfie (selfie *ptr) : me (ptr) {}
};

selfie bob ();

nathan

--
Nathan Sidwell

Re: [PATCH] Print working directory to gcov files (PR gcov-profile/84846).

[Martin Liška]

V2: pwd is renamed to cwd, which is a better name.

Martin
>From a42365bc6987fc13d3a3cd4b98d7d64d94f7f318 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 18 May 2018 13:58:58 +0200
Subject: [PATCH] Print working directory to gcov files (PR
 gcov-profile/84846).

gcc/ChangeLog:

2018-05-18  Martin Liska  

	PR gcov-profile/84846
	* coverage.c (coverage_init): Write PWD to .gcno file.
	* doc/gcov.texi: Document how working directory is printed.
	* gcov-dump.c (dump_gcov_file): Print PWD.
	* gcov.c (output_intermediate_file): Likewise.
	(read_graph_file): Read PWD string.
	(output_lines): Print PWD.
---
 gcc/coverage.c| 1 +
 gcc/doc/gcov.texi | 5 +
 gcc/gcov-dump.c   | 2 ++
 gcc/gcov.c| 7 +++
 4 files changed, 15 insertions(+)

diff --git a/gcc/coverage.c b/gcc/coverage.c
index 32ef298a11f..9e0185acd09 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1269,6 +1269,7 @@ coverage_init (const char *filename)
 	  gcov_write_unsigned (GCOV_NOTE_MAGIC);
 	  gcov_write_unsigned (GCOV_VERSION);
 	  gcov_write_unsigned (bbg_file_stamp);
+	  gcov_write_string (getpwd ());
 
 	  /* Do not support has_unexecuted_blocks for Ada.  */
 	  gcov_write_unsigned (strcmp (lang_hooks.name, "GNU Ada") != 0);
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index 59235876aaa..54625ce67cb 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -189,6 +189,7 @@ one entry per line
 
 @smallexample
 version:@var{gcc_version}
+cwd:@var{working_directory}
 file:@var{source_file_name}
 function:@var{start_line_number},@var{end_line_number},@var{execution_count},@var{function_name}
 lcount:@var{line number},@var{execution_count},@var{has_unexecuted_block}
@@ -210,6 +211,7 @@ Here is a sample when @option{-i} is used in conjunction with @option{-b} option
 
 @smallexample
 version: 8.1.0 20180103
+cwd:/home/gcc/testcase
 file:tmp.cpp
 function:7,7,0,_ZN3FooIcEC2Ev
 function:7,7,1,_ZN3FooIiEC2Ev
@@ -441,6 +443,7 @@ Here is a sample:
 
 @smallexample
 -:0:Source:tmp.cpp
+-:0:Working directory:/home/gcc/testcase
 -:0:Graph:tmp.gcno
 -:0:Data:tmp.gcda
 -:0:Runs:1
@@ -508,6 +511,7 @@ counts, and the output looks like this:
 
 @smallexample
 -:0:Source:tmp.cpp
+-:0:Working directory:/home/gcc/testcase
 -:0:Graph:tmp.gcno
 -:0:Data:tmp.gcda
 -:0:Runs:1
@@ -596,6 +600,7 @@ When you use the @option{-b} option, your output looks like this:
 
 @smallexample
 -:0:Source:tmp.cpp
+-:0:Working directory:/home/gcc/testcase
 -:0:Graph:tmp.gcno
 -:0:Data:tmp.gcda
 -:0:Runs:1
diff --git a/gcc/gcov-dump.c b/gcc/gcov-dump.c
index ba432db51c7..0ae7e944483 100644
--- a/gcc/gcov-dump.c
+++ b/gcc/gcov-dump.c
@@ -220,6 +220,8 @@ dump_gcov_file (const char *filename)
 
   if (!is_data_type)
 {
+  printf ("%s:cwd: %s\n", filename, gcov_read_string ());
+
   /* Support for unexecuted basic blocks.  */
   unsigned support_unexecuted_blocks = gcov_read_unsigned ();
   if (!support_unexecuted_blocks)
diff --git a/gcc/gcov.c b/gcc/gcov.c
index 6bbfe33ca33..8ed6e0d4d3f 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -432,6 +432,9 @@ static unsigned bbg_stamp;
 /* Supports has_unexecuted_blocks functionality.  */
 static unsigned bbg_supports_has_unexecuted_blocks;
 
+/* Working directory in which a TU was compiled.  */
+static const char *bbg_cwd;
+
 /* Name and file pointer of the input file for the count data (gcda).  */
 
 static char *da_file_name;
@@ -1037,6 +1040,7 @@ output_intermediate_file (FILE *gcov_file, source_info *src)
 {
   fprintf (gcov_file, "version:%s\n", version_string);
   fprintf (gcov_file, "file:%s\n", src->name);/* source file name */
+  fprintf (gcov_file, "cwd:%s\n", bbg_cwd);
 
   std::sort (src->functions.begin (), src->functions.end (),
 	 function_line_start_cmp ());
@@ -1550,6 +1554,7 @@ read_graph_file (void)
 	   bbg_file_name, v, e);
 }
   bbg_stamp = gcov_read_unsigned ();
+  bbg_cwd = xstrdup (gcov_read_string ());
   bbg_supports_has_unexecuted_blocks = gcov_read_unsigned ();
 
   function_info *fn = NULL;
@@ -2918,6 +2923,8 @@ output_lines (FILE *gcov_file, const source_info *src)
   const char *retval;
 
   fprintf (gcov_file, DEFAULT_LINE_START "Source:%s\n", src->coverage.name);
+  fprintf (gcov_file, DEFAULT_LINE_START "Working directory:%s\n",
+	   bbg_cwd);
   if (!multiple_files)
 {
   fprintf (gcov_file, DEFAULT_LINE_START "Graph:%s\n", bbg_file_name);
-- 
2.16.3

Re: Aliasing 'this' in a C++ constructor

[Marc Glisse]

(Cc: said C++ folks)

On Fri, 18 May 2018, Richard Biener wrote:


On Fri, May 18, 2018 at 2:25 PM Marc Glisse  wrote:


Hello,



this lets alias analysis handle the implicit 'this' parameter in C++
constructors as if it was restrict.



Bootstrap+regtest on powerpc64le-unknown-linux-gnu.


OK.  Please give C++ folks the chance to chime in on the semantics.

Thanks,
Richard.


2018-05-18  Marc Glisse  



 PR c++/82899
gcc/
 * tree-ssa-structalias.c (create_variable_info_for_1): Extra

argument.

 (intra_create_variable_infos): Handle C++ constructors.



gcc/testsuite/
 * g++.dg/pr82899.C: New testcase.



--
Marc Glisse


--
Marc Glisse

Re: [PATCH] gcov: add new option -t that prints output to stdout (PR gcov-profile/84846).

[Martin Liška]

I forgot to document the option. Fixed that.

Martin
>From 81236af4d1fac4c278b29e65162b3f73593a7d08 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 18 May 2018 14:22:06 +0200
Subject: [PATCH] gcov: add new option -t that prints output to stdout (PR
 gcov-profile/84846).

gcc/ChangeLog:

2018-05-18  Martin Liska  

	PR gcov-profile/84846
	* gcov.c (print_usage): Add new -t option.
	(process_args): Handle the option.
	(generate_results): Use stdout as output when requested by
	the option.

gcc/ChangeLog:

2018-05-18  Martin Liska  

	PR gcov-profile/84846
	* doc/gcov.texi: Document -t option of gcov tool.
---
 gcc/doc/gcov.texi |  5 +
 gcc/gcov.c| 36 +---
 2 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index 9d5cdbc8e03..c249a28c12e 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -134,6 +134,7 @@ gcov [@option{-v}|@option{--version}] [@option{-h}|@option{--help}]
  [@option{-p}|@option{--preserve-paths}]
  [@option{-r}|@option{--relative-only}]
  [@option{-s}|@option{--source-prefix} @var{directory}]
+ [@option{-t}|@option{--stdout}]
  [@option{-u}|@option{--unconditional-branches}]
  [@option{-x}|@option{--hash-filenames}]
  @var{files}
@@ -319,6 +320,10 @@ directory, and the pathname to the source directory is not wanted when
 determining the output file names.  Note that this prefix detection is
 applied before determining whether the source file is absolute.
 
+@item -t
+@itemx --stdout
+Output to standard output instead of output files.
+
 @item -u
 @itemx --unconditional-branches
 When branch probabilities are given, include those of unconditional branches.
diff --git a/gcc/gcov.c b/gcc/gcov.c
index 92972e29b4d..0ee9c0e55b7 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -462,6 +462,10 @@ static int flag_unconditional = 0;
 
 static int flag_gcov_file = 1;
 
+/* Output to stdout instead to a gcov file.  */
+
+static int flag_use_stdout = 0;
+
 /* Output progress indication if this is true.  This is off by default
and can be turned on by the -d option.  */
 
@@ -831,6 +835,7 @@ print_usage (int error_p)
   fnotice (file, "  -p, --preserve-pathsPreserve all pathname components\n");
   fnotice (file, "  -r, --relative-only Only show data for relative sources\n");
   fnotice (file, "  -s, --source-prefix DIR Source prefix to elide\n");
+  fnotice (file, "  -t, --stdoutOutput to stdout instead of a file\n");
   fnotice (file, "  -u, --unconditional-branchesShow unconditional branch counts too\n");
   fnotice (file, "  -v, --version   Print version number, then exit\n");
   fnotice (file, "  -w, --verbose   Print verbose informations\n");
@@ -874,6 +879,7 @@ static const struct option options[] =
   { "object-directory", required_argument, NULL, 'o' },
   { "object-file",  required_argument, NULL, 'o' },
   { "source-prefix",required_argument, NULL, 's' },
+  { "stdout",		no_argument,   NULL, 't' },
   { "unconditional-branches", no_argument, NULL, 'u' },
   { "display-progress", no_argument,   NULL, 'd' },
   { "hash-filenames",	no_argument,   NULL, 'x' },
@@ -888,7 +894,7 @@ process_args (int argc, char **argv)
 {
   int opt;
 
-  const char *opts = "abcdfhijklmno:prs:uvwx";
+  const char *opts = "abcdfhijklmno:prs:tuvwx";
   while ((opt = getopt_long (argc, argv, opts, options, NULL)) != -1)
 {
   switch (opt)
@@ -952,6 +958,9 @@ process_args (int argc, char **argv)
 	case 'w':
 	  flag_verbose = 1;
 	  break;
+	case 't':
+	  flag_use_stdout = 1;
+	  break;
 	case 'v':
 	  print_version ();
 	  /* print_version will exit.  */
@@ -1293,7 +1302,7 @@ generate_results (const char *file_name)
 	file_name = canonicalize_name (file_name);
 }
 
-  if (flag_gcov_file && flag_intermediate_format)
+  if (flag_gcov_file && flag_intermediate_format && !flag_use_stdout)
 {
   /* Open the intermediate file.  */
   gcov_intermediate_filename = get_gcov_intermediate_filename (file_name);
@@ -1325,7 +1334,9 @@ generate_results (const char *file_name)
 	}
 
   accumulate_line_counts (src);
-  function_summary (>coverage, "File");
+
+  if (!flag_use_stdout)
+	function_summary (>coverage, "File");
   total_lines += src->coverage.lines;
   total_executed += src->coverage.lines_executed;
   if (flag_gcov_file)
@@ -1333,14 +1344,25 @@ generate_results (const char *file_name)
 	  if (flag_intermediate_format)
 	/* Output the intermediate format without requiring source
 	   files.  This outputs a section to a *single* file.  */
-	output_intermediate_file (gcov_intermediate_file, src);
+	output_intermediate_file ((flag_use_stdout
+   ? stdout : gcov_intermediate_file), src);
 	  else
-	output_gcov_file (file_name, src);
-	  fnotice 

[PATCH] gcov: add new option -t that prints output to stdout (PR gcov-profile/84846).

[Martin Liška]

Hi.

It's requested by LCOV folks, they want to be able to print to stdout
instead of into a file.

Survives make check -k -j10 RUNTESTFLAGS="gcov.exp"

Ready for trunk?
Thanks,
Martin

gcc/ChangeLog:

2018-05-18  Martin Liska  

PR gcov-profile/84846
* gcov.c (print_usage): Add new -t option.
(process_args): Handle the option.
(generate_results): Use stdout as output when requested by
the option.
---
 gcc/gcov.c | 36 +---
 1 file changed, 29 insertions(+), 7 deletions(-)


diff --git a/gcc/gcov.c b/gcc/gcov.c
index 92972e29b4d..0ee9c0e55b7 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -462,6 +462,10 @@ static int flag_unconditional = 0;
 
 static int flag_gcov_file = 1;
 
+/* Output to stdout instead to a gcov file.  */
+
+static int flag_use_stdout = 0;
+
 /* Output progress indication if this is true.  This is off by default
and can be turned on by the -d option.  */
 
@@ -831,6 +835,7 @@ print_usage (int error_p)
   fnotice (file, "  -p, --preserve-pathsPreserve all pathname components\n");
   fnotice (file, "  -r, --relative-only Only show data for relative sources\n");
   fnotice (file, "  -s, --source-prefix DIR Source prefix to elide\n");
+  fnotice (file, "  -t, --stdoutOutput to stdout instead of a file\n");
   fnotice (file, "  -u, --unconditional-branchesShow unconditional branch counts too\n");
   fnotice (file, "  -v, --version   Print version number, then exit\n");
   fnotice (file, "  -w, --verbose   Print verbose informations\n");
@@ -874,6 +879,7 @@ static const struct option options[] =
   { "object-directory", required_argument, NULL, 'o' },
   { "object-file",  required_argument, NULL, 'o' },
   { "source-prefix",required_argument, NULL, 's' },
+  { "stdout",		no_argument,   NULL, 't' },
   { "unconditional-branches", no_argument, NULL, 'u' },
   { "display-progress", no_argument,   NULL, 'd' },
   { "hash-filenames",	no_argument,   NULL, 'x' },
@@ -888,7 +894,7 @@ process_args (int argc, char **argv)
 {
   int opt;
 
-  const char *opts = "abcdfhijklmno:prs:uvwx";
+  const char *opts = "abcdfhijklmno:prs:tuvwx";
   while ((opt = getopt_long (argc, argv, opts, options, NULL)) != -1)
 {
   switch (opt)
@@ -952,6 +958,9 @@ process_args (int argc, char **argv)
 	case 'w':
 	  flag_verbose = 1;
 	  break;
+	case 't':
+	  flag_use_stdout = 1;
+	  break;
 	case 'v':
 	  print_version ();
 	  /* print_version will exit.  */
@@ -1293,7 +1302,7 @@ generate_results (const char *file_name)
 	file_name = canonicalize_name (file_name);
 }
 
-  if (flag_gcov_file && flag_intermediate_format)
+  if (flag_gcov_file && flag_intermediate_format && !flag_use_stdout)
 {
   /* Open the intermediate file.  */
   gcov_intermediate_filename = get_gcov_intermediate_filename (file_name);
@@ -1325,7 +1334,9 @@ generate_results (const char *file_name)
 	}
 
   accumulate_line_counts (src);
-  function_summary (>coverage, "File");
+
+  if (!flag_use_stdout)
+	function_summary (>coverage, "File");
   total_lines += src->coverage.lines;
   total_executed += src->coverage.lines_executed;
   if (flag_gcov_file)
@@ -1333,14 +1344,25 @@ generate_results (const char *file_name)
 	  if (flag_intermediate_format)
 	/* Output the intermediate format without requiring source
 	   files.  This outputs a section to a *single* file.  */
-	output_intermediate_file (gcov_intermediate_file, src);
+	output_intermediate_file ((flag_use_stdout
+   ? stdout : gcov_intermediate_file), src);
 	  else
-	output_gcov_file (file_name, src);
-	  fnotice (stdout, "\n");
+	{
+	  if (flag_use_stdout)
+		{
+		  if (src->coverage.lines)
+		output_lines (stdout, src);
+		}
+	  else
+		{
+		  output_gcov_file (file_name, src);
+		  fnotice (stdout, "\n");
+		}
+	}
 	}
 }
 
-  if (flag_gcov_file && flag_intermediate_format)
+  if (flag_gcov_file && flag_intermediate_format && !flag_use_stdout)
 {
   /* Now we've finished writing the intermediate file.  */
   fclose (gcov_intermediate_file);

Re: Aliasing 'this' in a C++ constructor

[Richard Biener]

On Fri, May 18, 2018 at 2:25 PM Marc Glisse  wrote:

> Hello,

> this lets alias analysis handle the implicit 'this' parameter in C++
> constructors as if it was restrict.

> Bootstrap+regtest on powerpc64le-unknown-linux-gnu.

OK.  Please give C++ folks the chance to chime in on the semantics.

Thanks,
Richard.

> 2018-05-18  Marc Glisse  

>  PR c++/82899
> gcc/
>  * tree-ssa-structalias.c (create_variable_info_for_1): Extra
argument.
>  (intra_create_variable_infos): Handle C++ constructors.

> gcc/testsuite/
>  * g++.dg/pr82899.C: New testcase.

> --
> Marc Glisse

[PATCH] Print working directory to gcov files (PR gcov-profile/84846).

[Martin Liška]

Hi.

Simple format extension which prints working directory of TU when it was 
compiled.
It's requested by LCOV folks.

Survives make check -k -j10 RUNTESTFLAGS="gcov.exp"

Ready for trunk?
Thanks,
Martin

gcc/ChangeLog:

2018-05-18  Martin Liska  

PR gcov-profile/84846
* coverage.c (coverage_init): Write PWD to .gcno file.
* doc/gcov.texi: Document how working directory is printed.
* gcov-dump.c (dump_gcov_file): Print PWD.
* gcov.c (output_intermediate_file): Likewise.
(read_graph_file): Read PWD string.
(output_lines): Print PWD.
---
 gcc/coverage.c| 1 +
 gcc/doc/gcov.texi | 5 +
 gcc/gcov-dump.c   | 2 ++
 gcc/gcov.c| 7 +++
 4 files changed, 15 insertions(+)


diff --git a/gcc/coverage.c b/gcc/coverage.c
index 32ef298a11f..9e0185acd09 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1269,6 +1269,7 @@ coverage_init (const char *filename)
 	  gcov_write_unsigned (GCOV_NOTE_MAGIC);
 	  gcov_write_unsigned (GCOV_VERSION);
 	  gcov_write_unsigned (bbg_file_stamp);
+	  gcov_write_string (getpwd ());
 
 	  /* Do not support has_unexecuted_blocks for Ada.  */
 	  gcov_write_unsigned (strcmp (lang_hooks.name, "GNU Ada") != 0);
diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index 59235876aaa..9d5cdbc8e03 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -189,6 +189,7 @@ one entry per line
 
 @smallexample
 version:@var{gcc_version}
+pwd:@var{working_directory}
 file:@var{source_file_name}
 function:@var{start_line_number},@var{end_line_number},@var{execution_count},@var{function_name}
 lcount:@var{line number},@var{execution_count},@var{has_unexecuted_block}
@@ -210,6 +211,7 @@ Here is a sample when @option{-i} is used in conjunction with @option{-b} option
 
 @smallexample
 version: 8.1.0 20180103
+pwd:/home/gcc/testcase
 file:tmp.cpp
 function:7,7,0,_ZN3FooIcEC2Ev
 function:7,7,1,_ZN3FooIiEC2Ev
@@ -441,6 +443,7 @@ Here is a sample:
 
 @smallexample
 -:0:Source:tmp.cpp
+-:0:Working directory:/home/gcc/testcase
 -:0:Graph:tmp.gcno
 -:0:Data:tmp.gcda
 -:0:Runs:1
@@ -508,6 +511,7 @@ counts, and the output looks like this:
 
 @smallexample
 -:0:Source:tmp.cpp
+-:0:Working directory:/home/gcc/testcase
 -:0:Graph:tmp.gcno
 -:0:Data:tmp.gcda
 -:0:Runs:1
@@ -596,6 +600,7 @@ When you use the @option{-b} option, your output looks like this:
 
 @smallexample
 -:0:Source:tmp.cpp
+-:0:Working directory:/home/gcc/testcase
 -:0:Graph:tmp.gcno
 -:0:Data:tmp.gcda
 -:0:Runs:1
diff --git a/gcc/gcov-dump.c b/gcc/gcov-dump.c
index ba432db51c7..210e9e46c2e 100644
--- a/gcc/gcov-dump.c
+++ b/gcc/gcov-dump.c
@@ -220,6 +220,8 @@ dump_gcov_file (const char *filename)
 
   if (!is_data_type)
 {
+  printf ("%s:pwd: %s\n", filename, gcov_read_string ());
+
   /* Support for unexecuted basic blocks.  */
   unsigned support_unexecuted_blocks = gcov_read_unsigned ();
   if (!support_unexecuted_blocks)
diff --git a/gcc/gcov.c b/gcc/gcov.c
index 6bbfe33ca33..92972e29b4d 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -432,6 +432,9 @@ static unsigned bbg_stamp;
 /* Supports has_unexecuted_blocks functionality.  */
 static unsigned bbg_supports_has_unexecuted_blocks;
 
+/* Working directory in which a TU was compiled.  */
+static const char *bbg_pwd;
+
 /* Name and file pointer of the input file for the count data (gcda).  */
 
 static char *da_file_name;
@@ -1037,6 +1040,7 @@ output_intermediate_file (FILE *gcov_file, source_info *src)
 {
   fprintf (gcov_file, "version:%s\n", version_string);
   fprintf (gcov_file, "file:%s\n", src->name);/* source file name */
+  fprintf (gcov_file, "pwd:%s\n", bbg_pwd);
 
   std::sort (src->functions.begin (), src->functions.end (),
 	 function_line_start_cmp ());
@@ -1550,6 +1554,7 @@ read_graph_file (void)
 	   bbg_file_name, v, e);
 }
   bbg_stamp = gcov_read_unsigned ();
+  bbg_pwd = xstrdup (gcov_read_string ());
   bbg_supports_has_unexecuted_blocks = gcov_read_unsigned ();
 
   function_info *fn = NULL;
@@ -2918,6 +2923,8 @@ output_lines (FILE *gcov_file, const source_info *src)
   const char *retval;
 
   fprintf (gcov_file, DEFAULT_LINE_START "Source:%s\n", src->coverage.name);
+  fprintf (gcov_file, DEFAULT_LINE_START "Working directory:%s\n",
+	   bbg_pwd);
   if (!multiple_files)
 {
   fprintf (gcov_file, DEFAULT_LINE_START "Graph:%s\n", bbg_file_name);

Aliasing 'this' in a C++ constructor

[Marc Glisse]

Hello,

this lets alias analysis handle the implicit 'this' parameter in C++ 
constructors as if it was restrict.


Bootstrap+regtest on powerpc64le-unknown-linux-gnu.

2018-05-18  Marc Glisse  

PR c++/82899
gcc/
* tree-ssa-structalias.c (create_variable_info_for_1): Extra argument.
(intra_create_variable_infos): Handle C++ constructors.

gcc/testsuite/
* g++.dg/pr82899.C: New testcase.

--
Marc GlisseIndex: gcc/testsuite/g++.dg/pr82899.C
===
--- gcc/testsuite/g++.dg/pr82899.C	(nonexistent)
+++ gcc/testsuite/g++.dg/pr82899.C	(working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-optimized" } */
+
+struct A {
+  int i;
+  A(A&);
+};
+int X;
+A::A(A):i(42){
+  a.i=0;
+  X=i;
+}
+
+/* { dg-final { scan-tree-dump "X = 42;" "optimized" } } */
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c	(revision 260347)
+++ gcc/tree-ssa-structalias.c	(working copy)
@@ -5928,25 +5928,28 @@ check_for_overlaps (vec fiel
 	return true;
   lastoffset = fo->offset;
 }
   return false;
 }
 
 /* Create a varinfo structure for NAME and DECL, and add it to VARMAP.
This will also create any varinfo structures necessary for fields
of DECL.  DECL is a function parameter if HANDLE_PARAM is set.
HANDLED_STRUCT_TYPE is used to register struct types reached by following
-   restrict pointers.  This is needed to prevent infinite recursion.  */
+   restrict pointers.  This is needed to prevent infinite recursion.
+   If ADD_RESTRICT, pretend that the pointer NAME is restrict even if DECL
+   does not advertise it.  */
 
 static varinfo_t
 create_variable_info_for_1 (tree decl, const char *name, bool add_id,
-			bool handle_param, bitmap handled_struct_type)
+			bool handle_param, bitmap handled_struct_type,
+			bool add_restrict = false)
 {
   varinfo_t vi, newvi;
   tree decl_type = TREE_TYPE (decl);
   tree declsize = DECL_P (decl) ? DECL_SIZE (decl) : TYPE_SIZE (decl_type);
   auto_vec fieldstack;
   fieldoff_s *fo;
   unsigned int i;
 
   if (!declsize
   || !tree_fits_uhwi_p (declsize))
@@ -6006,21 +6009,21 @@ create_variable_info_for_1 (tree decl, c
   if (fieldstack.length () == 0
   || fieldstack.length () > MAX_FIELDS_FOR_FIELD_SENSITIVE)
 {
   vi = new_var_info (decl, name, add_id);
   vi->offset = 0;
   vi->may_have_pointers = true;
   vi->fullsize = tree_to_uhwi (declsize);
   vi->size = vi->fullsize;
   vi->is_full_var = true;
   if (POINTER_TYPE_P (decl_type)
-	  && TYPE_RESTRICT (decl_type))
+	  && (TYPE_RESTRICT (decl_type) || add_restrict))
 	vi->only_restrict_pointers = 1;
   if (vi->only_restrict_pointers
 	  && !type_contains_placeholder_p (TREE_TYPE (decl_type))
 	  && handle_param
 	  && !bitmap_bit_p (handled_struct_type,
 			TYPE_UID (TREE_TYPE (decl_type
 	{
 	  varinfo_t rvi;
 	  tree heapvar = build_fake_var_decl (TREE_TYPE (decl_type));
 	  DECL_EXTERNAL (heapvar) = 1;
@@ -6235,35 +6238,38 @@ make_param_constraints (varinfo_t vi)
 }
 
 /* Create varinfo structures for all of the variables in the
function for intraprocedural mode.  */
 
 static void
 intra_create_variable_infos (struct function *fn)
 {
   tree t;
   bitmap handled_struct_type = NULL;
+  bool this_parm_in_ctor = DECL_CXX_CONSTRUCTOR_P (fn->decl);
 
   /* For each incoming pointer argument arg, create the constraint ARG
  = NONLOCAL or a dummy variable if it is a restrict qualified
  passed-by-reference argument.  */
   for (t = DECL_ARGUMENTS (fn->decl); t; t = DECL_CHAIN (t))
 {
   if (handled_struct_type == NULL)
 	handled_struct_type = BITMAP_ALLOC (NULL);
 
   varinfo_t p
 	= create_variable_info_for_1 (t, alias_get_name (t), false, true,
-  handled_struct_type);
+  handled_struct_type, this_parm_in_ctor);
   insert_vi_for_tree (t, p);
 
   make_param_constraints (p);
+
+  this_parm_in_ctor = false;
 }
 
   if (handled_struct_type != NULL)
 BITMAP_FREE (handled_struct_type);
 
   /* Add a constraint for a result decl that is passed by reference.  */
   if (DECL_RESULT (fn->decl)
   && DECL_BY_REFERENCE (DECL_RESULT (fn->decl)))
 {
   varinfo_t p, result_vi = get_vi_for_tree (DECL_RESULT (fn->decl));

Re: [PATCH GCC][5/6]implement live range, reg pressure computation class

[Bin.Cheng]

On Fri, May 4, 2018 at 5:23 PM, Bin Cheng  wrote:
> Hi,
> Based on previous patch, this one implements live range, reg pressure 
> computation
> class in tree-ssa-live.c.  The user would only need to instantiate the class 
> and
> call the computation interface as in next patch.
> During the work, I think it's also worthwhile to classify all live range and 
> coalesce
> data structures and algorithms in the future.
>
> Bootstrap and test on x86_64 and AArch64 ongoing.  Any comments?

Updated patch in line with change of previous patch.

Thanks,
bin
>
> Thanks,
> bin
> 2018-04-27  Bin Cheng  
>
> * tree-ssa-live.c (memmodel.h, ira.h, tree-ssa-coalesce.h): Include.
> (struct stmt_lr_info, free_stmt_lr_info): New.
> (lr_region::lr_region, lr_region::~lr_region): New.
> (lr_region::create_stmt_lr_info): New.
> (lr_region::update_live_range_by_stmt): New.
> (lr_region::calculate_coalesced_pressure): New.
> (lr_region::calculate_pressure): New.
> * tree-ssa-live.h (struct stmt_lr_info): New declaration.
> (class lr_region): New class.
From 98a97779ac475f89bd7f476a7c5fd045d83b79d6 Mon Sep 17 00:00:00 2001
From: Bin Cheng 
Date: Fri, 4 May 2018 09:42:04 +0100
Subject: [PATCH 5/6] region-reg-pressure-20180504

---
 gcc/tree-ssa-live.c | 167 
 gcc/tree-ssa-live.h |  49 +++
 2 files changed, 216 insertions(+)

diff --git a/gcc/tree-ssa-live.c b/gcc/tree-ssa-live.c
index 7447f7a..e432bbe 100644
--- a/gcc/tree-ssa-live.c
+++ b/gcc/tree-ssa-live.c
@@ -23,6 +23,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "coretypes.h"
 #include "backend.h"
 #include "rtl.h"
+#include "memmodel.h"
+#include "ira.h"
 #include "tree.h"
 #include "gimple.h"
 #include "timevar.h"
@@ -34,6 +36,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-dfa.h"
 #include "dumpfile.h"
 #include "tree-ssa-live.h"
+#include "tree-ssa-coalesce.h"
 #include "debug.h"
 #include "tree-ssa.h"
 #include "ipa-utils.h"
@@ -1200,6 +1203,170 @@ calculate_live_ranges (var_map map, bool want_livein)
 }
 
 
+/* Live range information for a gimple stmt.  */
+struct stmt_lr_info
+{
+  /*  ID of the stmt.  */
+  unsigned id;
+  gimple *stmt;
+  /* Live ranges after the stmt.  */
+  bitmap lr_after_stmt;
+};
+
+/* Call back function to free live range INFO of gimple STMT.  */
+
+bool
+free_stmt_lr_info (gimple *const & stmt, stmt_lr_info *const , void *)
+{
+  gcc_assert (info->stmt == stmt);
+  if (info->lr_after_stmt != NULL)
+BITMAP_FREE (info->lr_after_stmt);
+
+  free (info);
+  return true;
+}
+
+lr_region::lr_region (struct loop *loop)
+  : m_loop (loop),
+m_varmap (NULL),
+m_liveinfo (NULL),
+m_stmtmap (new hash_map (13))
+{
+  memset (m_pressure, 0, sizeof (unsigned) * N_REG_CLASSES);
+}
+
+lr_region::~lr_region ()
+{
+  m_stmtmap->traverse (NULL);
+  delete m_stmtmap;
+}
+
+struct stmt_lr_info *
+lr_region::create_stmt_lr_info (gimple *stmt)
+{
+  bool exist_p;
+  struct stmt_lr_info **slot = _stmtmap->get_or_insert (stmt, _p);
+
+  gcc_assert (!exist_p);
+  *slot = XCNEW (struct stmt_lr_info);
+  (*slot)->stmt = stmt;
+  (*slot)->lr_after_stmt = NULL;
+  return *slot;
+}
+
+void
+lr_region::update_live_range_by_stmt (gimple *stmt, bitmap live_ranges,
+  unsigned *pressure)
+{
+  int p;
+  tree var;
+  ssa_op_iter iter;
+
+  FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_DEF)
+{
+  p = var_to_partition (m_varmap, var);
+  gcc_assert (p != NO_PARTITION);
+  if (bitmap_clear_bit (live_ranges, p))
+	pressure[ira_mode_classes[TYPE_MODE (TREE_TYPE (var))]]--;
+}
+  FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_USE)
+{
+  p = var_to_partition (m_varmap, var);
+  gcc_assert (p != NO_PARTITION);
+  if (bitmap_set_bit (live_ranges, p))
+	pressure[ira_mode_classes[TYPE_MODE (TREE_TYPE (var))]]++;
+}
+}
+
+void
+lr_region::calculate_coalesced_pressure ()
+{
+  unsigned i, j, reg_class, pressure[N_REG_CLASSES];
+  bitmap_iterator bi, bj;
+  gimple_stmt_iterator bsi;
+  auto_bitmap live_ranges;
+  bitmap bbs = get_bbs ();
+
+  EXECUTE_IF_SET_IN_BITMAP (bbs, 0, i, bi)
+{
+  basic_block bb = BASIC_BLOCK_FOR_FN (cfun, i);
+  bitmap_copy (live_ranges, _liveinfo->liveout[bb->index]);
+
+  memset (pressure, 0, sizeof (unsigned) * N_REG_CLASSES);
+  EXECUTE_IF_SET_IN_BITMAP (live_ranges, 0, j, bj)
+	{
+	  tree var = partition_to_var (m_varmap, j);
+	  reg_class = ira_mode_classes[TYPE_MODE (TREE_TYPE (var))];
+	  pressure[reg_class]++;
+	}
+
+  for (bsi = gsi_last_bb (bb); !gsi_end_p (bsi); gsi_prev ())
+	{
+	  gimple *stmt = gsi_stmt (bsi);
+	  struct stmt_lr_info *stmt_info = create_stmt_lr_info (stmt);
+	  /* No need to compute live range information for debug stmt.  */
+	  if (is_gimple_debug (stmt))
+	continue;
+
+	  for (j = 

[PATCH] Add VRP stmt folding to EVRP

[Richard Biener]

While working on somehow re-ordering the first VRP pass after loop-header
copying I noticed that EVRP doesn't do VRP stmt simplifications.  The
following adds this alongside the usual testsuite adjustments.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2018-05-18  Richard Biener  

* gimple-ssa-evrp.c (class evrp_folder): Add simplify_stmt_using_ranges
method.
(evrp_dom_walker::before_dom_children): Call it.

* gcc.dg/tree-ssa/pr21559.c: Adjust.
* gcc.dg/tree-ssa/pr45397.c: Likewise.
* gcc.dg/tree-ssa/pr61839_1.c: Likewise.
* gcc.dg/tree-ssa/pr61839_2.c: Likewise.
* gcc.dg/tree-ssa/pr61839_4.c: Likewise.
* gcc.dg/tree-ssa/vrp17.c: Likewise.
* gcc.dg/tree-ssa/vrp18.c: Likewise.
* gcc.dg/tree-ssa/vrp23.c: Likewise.
* gcc.dg/tree-ssa/vrp24.c: Likewise.
* gcc.dg/tree-ssa/vrp58.c: Likewise.
* gcc.dg/vrp-min-max-1.c: Likewise.
* gcc.dg/vrp-min-max-3.c: New testcase.

diff --git a/gcc/gimple-ssa-evrp.c b/gcc/gimple-ssa-evrp.c
index c9bbf09a406..b9a054fd2ee 100644
--- a/gcc/gimple-ssa-evrp.c
+++ b/gcc/gimple-ssa-evrp.c
@@ -47,6 +47,8 @@ class evrp_folder : public substitute_and_fold_engine
  public:
   tree get_value (tree) FINAL OVERRIDE;
   evrp_folder (class vr_values *vr_values_) : vr_values (vr_values_) { }
+  bool simplify_stmt_using_ranges (gimple_stmt_iterator *gsi)
+{ return vr_values->simplify_stmt_using_ranges (gsi); }
   class vr_values *vr_values;
 
  private:
@@ -180,6 +182,12 @@ evrp_dom_walker::before_dom_children (basic_block bb)
  update_stmt (stmt);
  did_replace = true;
}
+  if (evrp_folder.simplify_stmt_using_ranges ())
+   {
+ stmt = gsi_stmt (gsi);
+ update_stmt (stmt);
+ did_replace = true;
+   }
 
   if (did_replace)
{
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr21559.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr21559.c
index 0906351350e..b4065668ff8 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr21559.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr21559.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-vrp1-details" } */
+/* { dg-options "-O2 -fdump-tree-evrp-details -fdump-tree-vrp1-details" } */
 
 static int blocksize = 4096;
 
@@ -33,7 +33,7 @@ void foo (void)
 
 
 /* First, we should simplify the bits < 0 test within the loop.  */
-/* { dg-final { scan-tree-dump-times "Simplified relational" 1 "vrp1" } } */
+/* { dg-final { scan-tree-dump-times "Simplified relational" 1 "evrp" } } */
 
 /* Second, we should thread the edge out of the loop via the break
statement.  We also realize that the final bytes == 0 test is useless,
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr45397.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr45397.c
index 18c7f0bcecc..af75a75b1e2 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr45397.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr45397.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-phiopt1" } */
+/* { dg-options "-O2 -fdump-tree-phiopt1 -fdump-tree-evrp" } */
 
 int foo_add (const unsigned char *tmp, int i, int val)
 {
@@ -18,6 +18,7 @@ int foo_mul (const unsigned char *tmp, int i, int val)
 
 /* All cases should end up using min/max for the saturated operations and
have no control flow.  */
+/* { dg-final { scan-tree-dump-not " & 255;" "evrp" } } */
 /* { dg-final { scan-tree-dump-times "MAX_EXPR" 3 "phiopt1" } } */
 /* { dg-final { scan-tree-dump-times "MIN_EXPR" 3 "phiopt1" } } */
 /* { dg-final { scan-tree-dump-not "if " "phiopt1" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr61839_1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr61839_1.c
index 9f8168a81f2..d44c7dc1882 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr61839_1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr61839_1.c
@@ -1,6 +1,6 @@
 /* PR tree-optimization/61839.  */
 /* { dg-do run } */
-/* { dg-options "-O2 -fdump-tree-vrp1 -fdump-tree-optimized" } */
+/* { dg-options "-O2 -fdump-tree-vrp1 -fdisable-tree-evrp 
-fdump-tree-optimized" } */
 /* { dg-require-effective-target int32plus } */
 
 __attribute__ ((noinline))
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr61839_2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr61839_2.c
index 638189e66e5..cfec54de991 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr61839_2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr61839_2.c
@@ -51,4 +51,4 @@ int bar2 ()
 /* Dont optimize 972195717 % 0 in function bar.  */
 /* { dg-final { scan-tree-dump-times "972195717 % " 1 "evrp" } } */
 /* May optimize in function bar2, but EVRP doesn't perform this yet.  */
-/* { dg-final { scan-tree-dump-times "972195715 % " 0 "evrp" { xfail *-*-* } } 
} */
+/* { dg-final { scan-tree-dump-times "972195715 % " 0 "evrp" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr61839_4.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr61839_4.c
index 5c026c89c7d..a346912d121 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr61839_4.c
+++ 

[PATCH v2] C/C++: Add -Waddress-of-packed-member

[H.J. Lu]

On Thu, May 17, 2018 at 10:32:56AM -0700, H.J. Lu wrote:
> On Mon, May 14, 2018 at 8:00 PM, Martin Sebor  wrote:
> > On 05/14/2018 01:10 PM, H.J. Lu wrote:
> >>
> >> On Mon, May 14, 2018 at 10:40 AM, H.J. Lu  wrote:
> >>
> >> $ cat c.i
> >> struct B { int i; };
> >> struct C { struct B b; } __attribute__ ((packed));
> >>
> >> long* g8 (struct C *p) { return p; }
> >> $ gcc -O2 -S c.i -Wno-incompatible-pointer-types
> >> c.i: In function ‘g8’:
> >> c.i:4:33: warning: taking value of packed 'struct C *' may result in
> >> an
> >> unaligned pointer value [-Waddress-of-packed-member]
> 
> 
>   ^
>  That should read "taking address" (not value) but...
> >>>
> >>>
> >>> The value of 'struct C *' is an address. There is no address taken here.
> >>>
>  ...to help explain the problem I would suggest to mention the expected
>  and actual alignment in the warning message.  E.g.,
> 
>    storing the address of a packed 'struct C' in 'struct C *' increases
>  the
>  alignment of the pointer from 1 to 4.
> >>>
> >>>
> >>> I will take a look.
> >>>
>  (IIUC, the source type and destination type need not be the same so
>  including both should be helpful in those cases.)
> 
>  Adding a note pointing to the declaration of either the struct or
>  the member would help users find it if it's a header far removed
>  from the point of use.
> >>>
> >>>
> >>> I will see what I can do.
> >>
> >>
> >> How about this
> >>
> >> [hjl@gnu-skx-1 pr51628]$ cat n9.i
> >> struct B { int i; };
> >> struct C { struct B b; } __attribute__ ((packed));
> >>
> >> long* g8 (struct C *p) { return p; }
> >> [hjl@gnu-skx-1 pr51628]$
> >> /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
> >> -B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -S n9.i
> >> n9.i: In function ‘g8’:
> >> n9.i:4:33: warning: returning ‘struct C *’ from a function with
> >> incompatible return type ‘long int *’ [-Wincompatible-pointer-types]
> >>  long* g8 (struct C *p) { return p; }
> >>  ^
> >> n9.i:4:33: warning: taking value of packed ‘struct C *’ increases the
> >> alignment of the pointer from 1 to 8 [-Waddress-of-packed-member]
> >> n9.i:2:8: note: defined here
> >>  struct C { struct B b; } __attribute__ ((packed));
> >
> >
> > Mentioning the alignments looks good.
> >
> > I still find the "taking value" phrasing odd.  I think we would
> > describe what's going on as "converting a pointer to a packed C
> > to a pointer to C (with an alignment of 8)" so I'd suggest to
> > use the term converting instead.
> 
> How about this?
> 
> [hjl@gnu-skx-1 pr51628]$ cat n12.i
> struct B { int i; };
> struct C { struct B b; } __attribute__ ((packed));
> 
> struct B* g8 (struct C *p) { return p; }
> [hjl@gnu-skx-1 pr51628]$ make n12.s
> /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -S n12.i
> n12.i: In function ‘g8’:
> n12.i:4:37: warning: returning ‘struct C *’ from a function with
> incompatible return type ‘struct B *’ [-Wincompatible-pointer-types]
>  struct B* g8 (struct C *p) { return p; }
>  ^
> n12.i:4:37: warning: converting a pointer to packed ‘struct C *’
> increases the alignment of the pointer to ‘struct B *’ from 1 to 4
> [-Waddress-of-packed-member]
> n12.i:2:8: note: defined here
>  struct C { struct B b; } __attribute__ ((packed));
> ^
> n12.i:1:8: note: defined here
>  struct B { int i; };
> ^
> [hjl@gnu-skx-1 pr51628]$
> 
> > I also think mentioning both the source and the destination types
> > is useful irrespective of -Wincompatible-pointer-types because
> > the latter is often suppressed using a cast, as in:
> >
> >   struct __attribute__ ((packed)) A { int i; };
> >   struct B {
> > struct A a;
> >   } b;
> >
> >   long *p = (long*)   // -Waddress-of-packed-member
> >   int *q = (int*)   // missing warning
> >
> > If the types above were obfuscated by macros, typedefs, or in
> > C++ template parameters, it could be difficult to figure out
> > what the type of the member is because neither it nor the name
> > of the member appears in the message.
> 
> How about this
> 
> [hjl@gnu-skx-1 pr51628]$ cat n13.i
> struct __attribute__ ((packed)) A { int i; };
> struct B {
>   struct A a;
> } b;
> 
> long *p = (long*)
> int *q = (int*)
> [hjl@gnu-skx-1 pr51628]$ make n13.s
> /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -S n13.i
> n13.i:6:18: warning: taking address of packed member of ‘struct A’ may
> result in an unaligned pointer value [-Waddress-of-packed-member]
>  long *p = (long*)
>   ^~
> n13.i:7:16: warning: taking address of packed member of ‘struct B’ may
> result in an unaligned pointer value [-Waddress-of-packed-member]
>  int 

[PATCH] Support variables in expansion of -fprofile-generate option (PR gcov-profile/47618).

[Martin Liška]

Hi.

Following patch enables to generate more parallel profiles for applications
that do intensive # of invocations. There's some discussion in the PR.

So one example:

$ gcc -fprofile-generate=/tmp/slavia/%p/%q{CPU}/ empty.c -O2 && ./a.out
$ l /tmp/slavia/22234/x86_64/empty.gcda
-rw-r--r-- 1 marxin users 172 May 18 13:20 /tmp/slavia/22234/x86_64/empty.gcda

Ready for trunk?
Thanks,
Martin

gcc/ChangeLog:

2018-05-18  Martin Liska  

PR gcov-profile/47618
* opts.c (expand_profile_data_prefix): New function.
(finish_options): Use it.

libgcc/ChangeLog:

2018-05-18  Martin Liska  

PR gcov-profile/47618
* libgcov-driver-system.c (replace_filename_variables):
New function.
(gcov_exit_open_gcda_file): Use it.
---
 gcc/opts.c | 35 
 libgcc/libgcov-driver-system.c | 73 ++
 2 files changed, 108 insertions(+)


diff --git a/gcc/opts.c b/gcc/opts.c
index 33efcc0d6e7..fc337a9463f 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -690,6 +690,38 @@ default_options_optimization (struct gcc_options *opts,
 			 lang_mask, handlers, loc, dc);
 }
 
+/* Expand variables in x_profile_data_prefix.
+   Currently we support following options:
+
+   %w - current working directory
+   */
+
+static void
+expand_profile_data_prefix (gcc_options *opts)
+{
+  if (opts->x_profile_data_prefix != NULL)
+{
+  const char *needle = "%w";
+  unsigned needle_strlen = strlen (needle);
+  while (true)
+	{
+	  char *p = CONST_CAST (char *, strstr (opts->x_profile_data_prefix,
+		needle));
+	  if (p)
+	{
+	  *p = '\0';
+	  char *r = concat (opts->x_profile_data_prefix, getpwd (),
+p + needle_strlen, NULL);
+
+	  free (CONST_CAST (char *, opts->x_profile_data_prefix));
+	  opts->x_profile_data_prefix = r;
+	}
+	  else
+	break;
+  }
+}
+}
+
 /* After all options at LOC have been read into OPTS and OPTS_SET,
finalize settings of those options and diagnose incompatible
combinations.  */
@@ -1059,6 +1091,9 @@ finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
   if (opts->x_align_labels > MAX_CODE_ALIGN_VALUE)
 error_at (loc, "-falign-labels=%d is not between 0 and %d",
 	  opts->x_align_labels, MAX_CODE_ALIGN_VALUE);
+
+  /* Expand variables in x_profile_data_prefix.  */
+  expand_profile_data_prefix (opts);
 }
 
 #define LEFT_COLUMN	27
diff --git a/libgcc/libgcov-driver-system.c b/libgcc/libgcov-driver-system.c
index 0df44239363..d45ac4b31ba 100644
--- a/libgcc/libgcov-driver-system.c
+++ b/libgcc/libgcov-driver-system.c
@@ -128,6 +128,77 @@ create_file_directory (char *filename)
 #endif
 }
 
+/* Replace filename variables in FILENAME.  We currently support expansion:
+
+   %p - process ID
+   %q{ENV} - value of environment variable ENV
+   */
+
+static char *
+replace_filename_variables (char *filename)
+{
+  char buffer[16];
+  char empty[] = "";
+  for (char *p = filename; *p != '\0'; p++)
+{
+  unsigned length = strlen (filename);
+  if (*p == '%' && *(p + 1) != '\0')
+	{
+	  unsigned start = p - filename;
+	  p++;
+	  char *replacement = NULL;
+	  switch (*p)
+	{
+	case 'p':
+	  sprintf (buffer, "%d", getpid ());
+	  replacement = buffer;
+	  p++;
+	  break;
+	case 'q':
+	  if (*(p + 1) == '{')
+		{
+		  p += 2;
+		  char *e = strchr (p, '}');
+		  if (e)
+		{
+		  *e = '\0';
+		  replacement = getenv (p);
+		  if (replacement == NULL)
+			replacement = empty;
+		  p = e + 1;
+		}
+		  else
+		return filename;
+		}
+	  break;
+	default:
+	  return filename;
+	}
+
+	  /* Concat beginning of the path, replacement and
+	 ending of the path.  */
+	  unsigned end = length - (p - filename);
+	  unsigned repl_length = strlen (replacement);
+
+	  char *buffer = (char *)xmalloc (start + end + repl_length + 1);
+	  char *buffer_ptr = buffer;
+	  memcpy (buffer_ptr, filename, start);
+	  buffer_ptr += start;
+	  memcpy (buffer_ptr, replacement, repl_length);
+	  buffer_ptr += repl_length;
+	  memcpy (buffer_ptr, p, end);
+	  buffer_ptr += end;
+	  *buffer_ptr = '\0';
+
+	  free (filename);
+	  filename = buffer;
+	  p = buffer + start + repl_length;
+	}
+}
+
+  return filename;
+}
+
 static void
 allocate_filename_struct (struct gcov_filename *gf)
 {
@@ -216,6 +287,8 @@ gcov_exit_open_gcda_file (struct gcov_info *gi_ptr,
 }
   strcpy (dst, fname);
 
+  gf->filename = replace_filename_variables (gf->filename);
+
   if (!gcov_open (gf->filename))
 {
   /* Open failed likely due to missed directory.

[PATCH][RFC] Add dynamic edge/bb flag allocation

[Richard Biener]

The following adds a simple alloc/free_flag machinery allocating
bits from an int typed pool and applies that to bb->flags and edge->flags.
This should allow infrastructure pieces to use egde/bb flags temporarily
without worrying that users might already use it as for example
BB_VISITED and friends.  It converts one clever user to the new interface.

The allocation state is per CFG but we could also make it global
or merge the two pools so one allocates a flag that can be used for
bbs and edges at the same time.

Thus - any opinions welcome.  I'm mainly targeting cfganal algorithms
where I want to add a few region-based ones that to be O(region-size)
complexity may not use sbitmaps for visited sets because of the clearing
overhead and bitmaps are probably more expensive to use than a BB/edge
flag that needs to be cleared afterwards.

Built on x86_64, otherwise untested.

Any comments?

Templating the core flag allocator comes to my mind (up to max
HOST_WIDE_INT) as well as moving the implementation elsewhere (hwi.h?).

Thanks,
Richard.

>From 739d8f202a161b4714cad8b19844ae5fa7924118 Mon Sep 17 00:00:00 2001
From: Richard Guenther 
Date: Fri, 18 May 2018 13:01:36 +0200
Subject: [PATCH 4/4] add dynamic cfg flag allocation

* cfg.h (struct control_flow_graph): Add edge_flags_allocated and
bb_flags_allocated members.
(alloc_flag): Declare.
(free_flag): Likewise.
(alloc_bb_flag): New inline function.
(alloc_edge_flag): Likewise.
(free_bb_flag): Likewise.
(free_edge_flag): Likewise.
* cfg.c (alloc_flag): New function.
(free_flag): Likewise.
(init_flow): Mark static bb and edge flag allocated.
* cfgloop.c (verify_loop_structure): Allocate temporary edge
flag dynamically.

diff --git a/gcc/cfg.c b/gcc/cfg.c
index 11026e7209a..30fc417d28f 100644
--- a/gcc/cfg.c
+++ b/gcc/cfg.c
@@ -79,6 +79,8 @@ init_flow (struct function *the_fun)
 = EXIT_BLOCK_PTR_FOR_FN (the_fun);
   EXIT_BLOCK_PTR_FOR_FN (the_fun)->prev_bb
 = ENTRY_BLOCK_PTR_FOR_FN (the_fun);
+  the_fun->cfg->edge_flags_allocated = EDGE_ALL_FLAGS;
+  the_fun->cfg->bb_flags_allocated = BB_ALL_FLAGS;
 }
 
 /* Helper function for remove_edge and clear_edges.  Frees edge structure
@@ -1167,3 +1169,26 @@ get_loop_copy (struct loop *loop)
   else
 return NULL;
 }
+
+/* Allocate a bit from *POOL and return a corresponding mask.  */
+
+int
+alloc_flag (int *pool)
+{
+  int bitnum = clz_hwi (*pool);
+  /* out of bits */
+  gcc_assert (bitnum != 0);
+  int mask = 1 << (HOST_BITS_PER_INT - bitnum);
+  gcc_assert ((*pool & mask) == 0);
+  *pool |= mask;
+  return mask;
+}
+
+/* Release a bit with MASK to *POOL.  */
+
+void
+free_flag (int *pool, int mask)
+{
+  gcc_assert (popcount_hwi (mask) == 1 && (*pool & mask) == mask);
+  *pool &= ~mask;
+}
diff --git a/gcc/cfg.h b/gcc/cfg.h
index 0953456782b..23b02346751 100644
--- a/gcc/cfg.h
+++ b/gcc/cfg.h
@@ -74,6 +74,10 @@ struct GTY(()) control_flow_graph {
 
   /* Maximal count of BB in function.  */
   profile_count count_max;
+
+  /* Dynamically allocated edge/bb flags.  */
+  int edge_flags_allocated;
+  int bb_flags_allocated;
 };
 
 
@@ -121,4 +125,28 @@ extern basic_block get_bb_copy (basic_block);
 void set_loop_copy (struct loop *, struct loop *);
 struct loop *get_loop_copy (struct loop *);
 
+extern int alloc_flag (int *);
+extern void free_flag (int *, int);
+
+inline int
+alloc_edge_flag (struct function *fn)
+{
+  return alloc_flag (>cfg->edge_flags_allocated);
+}
+inline int
+alloc_bb_flag (struct function *fn)
+{
+  return alloc_flag (>cfg->bb_flags_allocated);
+}
+inline void
+free_edge_flag (struct function *fn, int mask)
+{
+  free_flag (>cfg->edge_flags_allocated, mask);
+}
+inline void
+free_bb_flag (struct function *fn, int mask)
+{
+  free_flag (>cfg->bb_flags_allocated, mask);
+}
+
 #endif /* GCC_CFG_H */
diff --git a/gcc/cfgloop.c b/gcc/cfgloop.c
index 8af793c6015..64ad42c83ca 100644
--- a/gcc/cfgloop.c
+++ b/gcc/cfgloop.c
@@ -1539,6 +1539,7 @@ verify_loop_structure (void)
   /* Check irreducible loops.  */
   if (loops_state_satisfies_p (LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS))
 {
+  int saved_irr_mask = alloc_edge_flag (cfun);
   /* Record old info.  */
   auto_sbitmap irreds (last_basic_block_for_fn (cfun));
   FOR_EACH_BB_FN (bb, cfun)
@@ -1550,7 +1551,7 @@ verify_loop_structure (void)
bitmap_clear_bit (irreds, bb->index);
  FOR_EACH_EDGE (e, ei, bb->succs)
if (e->flags & EDGE_IRREDUCIBLE_LOOP)
- e->flags |= EDGE_ALL_FLAGS + 1;
+ e->flags |= saved_irr_mask;
}
 
   /* Recount it.  */
@@ -1576,22 +1577,23 @@ verify_loop_structure (void)
  FOR_EACH_EDGE (e, ei, bb->succs)
{
  if ((e->flags & EDGE_IRREDUCIBLE_LOOP)
- && !(e->flags & (EDGE_ALL_FLAGS + 1)))
+ && !(e->flags & saved_irr_mask))
{
 

Re: [PATCH][arm][2/2] Remove support for -march=armv3 and older

[Richard Earnshaw (lists)]

On 17/05/18 11:26, Kyrill Tkachov wrote:
> Hi all,
> 
> We deprecated architecture versions earlier than Armv4T in GCC 6 [1].
> This patch removes support for architectures lower than Armv4.
> That is the -march values armv2, armv2a, armv3, armv3m are removed
> with this patch.  I did not remove armv4 because it's a bit more
> involved code-wise and there has been some pushback on the implications
> for -mcpu=strongarm support.
> 
> Removing armv3m and earlier though is pretty straightforward.
> This allows us to get rid of the armv3m and mode32 feature bits
> in arm-cpus.in as they can be assumed to be universally available.
> 
> Consequently the mcpu values arm2, arm250, arm3, arm6, arm60, arm600,
> arm610, arm620, arm7, arm7d, arm7di, arm70, arm700, arm700i, arm710,
> arm720, arm710c, arm7100, arm7500, arm7500fe, arm7m, arm7dm, arm7dm are
> now also removed.
> 
> Bootstrapped and tested on arm-none-linux-gnueabihf and on arm-none-eabi
> with an aprofile multilib configuration (which builds quite a lot of
> library
> configurations).
> 
> Ramana, Richard, I'd appreciate an ok from either of you that you're
> happy for this to go ahead.

OK.

It seems slightly strange that we remove the mode32 feature, but not the
mode26 feature, though I can see how it occurs as a consequence of this
cleanup.

However, we're no longer interested in supporting ARMv4 running in
mode26 (and I think in reality mode26 support was dropped several
releases back), so we should just drop that feature bit as well.
Perhaps you could do a follow-up to remove that too?

Thanks,

R.

> 
> Thanks,
> Kyrill
> 
> [1] https://gcc.gnu.org/gcc-6/changes.html#arm
> 
> 2018-05-17  Kyrylo Tkachov  
> 
>     * config/arm/arm-cpus.in (armv3m, mode32): Delete features.
>     (ARMv4): Update.
>     (ARMv2, ARMv3, ARMv3m): Delete fgroups.
>     (ARMv6m): Update.
>     (armv2, armv2a, armv3, armv3m): Delete architectures.
>     (arm2, arm250, arm3, arm6, arm60, arm600, arm610, arm620,
>     arm7, arm7d, arm7di, arm70, arm700, arm700i, arm710, arm720,
>     arm710c, arm7100, arm7500, arm7500fe, arm7m, arm7dm, arm7dmi):
>     Delete cpus.
>     * config/arm/arm.md (maddsidi4): Remove check for arm_arch3m.
>     (*mulsidi3adddi): Likewise.
>     (mulsidi3): Likewise.
>     (*mulsidi3_nov6): Likewise.
>     (umulsidi3): Likewise.
>     (umulsidi3_nov6): Likewise.
>     (umaddsidi4): Likewise.
>     (*umulsidi3adddi): Likewise.
>     (smulsi3_highpart): Likewise.
>     (*smulsi3_highpart_nov6): Likewise.
>     (umulsi3_highpart): Likewise.
>     (*umulsi3_highpart_nov6): Likewise.
>     * config/arm/arm.h (arm_arch3m): Delete.
>     * config/arm/arm.c (arm_arch3m): Delete.
>     (arm_option_override_internal): Update armv3-related comment.
>     (arm_configure_build_target): Delete use of isa_bit_mode32.
>     (arm_option_reconfigure_globals): Delete set of arm_ach3m.
>     (arm_rtx_costs_internal): Delete check of arm_arch3m.
>     * config/arm/arm-fixed.md (mulsq3): Delete check for arm_arch3m.
>     (mulsa3): Likewise.
>     (mulusa3): Likewise.
>     * config/arm/arm-protos.h (arm_arch3m): Delete.
>     * config/arm/arm-tables.opt: Regenerate.
>     * config/arm/arm-tune.md: Likewise.
>     * config/arm/t-arm-elf (all_early_nofp): Delete mentions of
>     deleted architectures.
> 
> 2018-05-17  Kyrylo Tkachov  
> 
>     * gcc.target/arm/pr62554.c: Delete.
>     * gcc.target/arm/pr69610-1.c: Likewise.
>     * gcc.target/arm/pr69610-2.c: Likewise.
> 
> armv3.patch
> 
> 
> diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
> index 
> 0a318877f10394e2c045d2a03a8f0757557136cf..16a381c86b6a7947e424b29fe67812990519ada9
>  100644
> --- a/gcc/config/arm/arm-cpus.in
> +++ b/gcc/config/arm/arm-cpus.in
> @@ -48,15 +48,9 @@
>  
>  # Features - general convention: all lower case.
>  
> -# Extended multiply
> -define feature armv3m
> -
>  # 26-bit mode support
>  define feature mode26
>  
> -# 32-bit mode support
> -define feature mode32
> -
>  # Architecture rel 4
>  define feature armv4
>  
> @@ -215,10 +209,7 @@ define fgroup ALL_FPU_INTERNAL   vfpv2 vfpv3 vfpv4 fpv5 
> fp16conv fp_dbl ALL_SIMD_I
>  # -mfpu support.
>  define fgroup ALL_FP fp16 ALL_FPU_INTERNAL
>  
> -define fgroup ARMv2   notm
> -define fgroup ARMv3   ARMv2 mode32
> -define fgroup ARMv3m  ARMv3 armv3m
> -define fgroup ARMv4   ARMv3m armv4
> +define fgroup ARMv4   armv4 notm
>  define fgroup ARMv4t  ARMv4 thumb
>  define fgroup ARMv5t  ARMv4t armv5t
>  define fgroup ARMv5te ARMv5t armv5te
> @@ -232,7 +223,7 @@ define fgroup ARMv6zk ARMv6k
>  define fgroup ARMv6t2 ARMv6 thumb2
>  # This is suspect.  ARMv6-m doesn't really pull in any useful features
>  # from ARMv5* or ARMv6.
> -define fgroup ARMv6m  mode32 armv3m armv4 thumb armv5t armv5te armv6 be8
> +define fgroup ARMv6m  armv4 thumb armv5t armv5te armv6 be8
>  # This is suspect, the 'common' ARMv7 subset excludes the thumb2 'DSP' 

Re: [PATCH][arm][1/2] Remove support for deprecated -march=armv5 and armv5e

[Richard Earnshaw (lists)]

On 17/05/18 11:26, Kyrill Tkachov wrote:
> Hi all,
> 
> The -march=armv5 and armv5e options have been deprecated in GCC 7 [1].
> This patch removes support for them.
> It's mostly mechanical stuff. The functionality that was previously
> gated on arm_arch5 is now gated on arm_arch5t and the functionality
> that was gated on arm_arch5e is now gated on arm_arch5te.
> 
> A path in TARGET_OS_CPP_BUILTINS for VxWorks is now unreachable and
> therefore is deleted.
> 
> References to armv5 and armv5e are deleted/updated throughout the
> source tree and testsuite.
> 
> Bootstrapped and tested on arm-none-linux-gnueabihf.
> Also built a cc1 for arm-wrs-vxworks as a sanity check.
> 
> Ramana, Richard, I'd appreciate an ok from either of you that you're
> happy for this to go ahead.
> 

I agree, time for this code to go.

OK.

R.

> Thanks,
> Kyrill
> 
> [1] https://gcc.gnu.org/gcc-7/changes.html#arm
> 
> gcc/
> 2018-05-17  Kyrylo Tkachov  
> 
>     * config/arm/arm-cpus.in (armv5, armv5e): Delete features.
>     (armv5t, armv5te): New features.
>     (ARMv5, ARMv5e): Delete fgroups.
>     (ARMv5t, ARMv5te): Adjust for above changes.
>     (ARMv6m): Likewise.
>     (armv5, armv5e): Delete arches.
>     * config/arm/arm.md (*call_reg_armv5): Use arm_arch5t instead of
>     arm_arch5.
>     (*call_reg_arm): Likewise.
>     (*call_value_reg_armv5): Likewise.
>     (*call_value_reg_arm): Likewise.
>     (*call_symbol): Likewise.
>     (*call_value_symbol): Likewise.
>     (*sibcall_insn): Likewise.
>     (*sibcall_value_insn): Likewise.
>     (clzsi2): Likewise.
>     (prefetch): Likewise.
>     (define_split and define_peephole2 dependent on arm_arch5):
>     Likewise.
>     * config/arm/arm.h (TARGET_LDRD): Use arm_arch5te instead of
>     arm_arch5e.
>     (TARGET_ARM_QBIT): Likewise.
>     (TARGET_DSP_MULTIPLY): Likewise.
>     (enum base_architecture): Delete BASE_ARCH_5, BASE_ARCH_5E.
>     (arm_arch5, arm_arch5e): Delete.
>     (arm_arch5t, arm_arch5te): Declare.
>     * config/arm/arm.c (arm_arch5, arm_arch5e): Delete.
>     (arm_arch5t): Declare.
>     (arm_option_reconfigure_globals): Update for the above.
>     (arm_options_perform_arch_sanity_checks): Update comment, replace
>     use of arm_arch5 with arm_arch5t.
>     (use_return_insn): Likewise.
>     (arm_emit_call_insn): Likewise.
>     (output_return_instruction): Likewise.
>     (arm_final_prescan_insn): Likewise.
>     (arm_coproc_builtin_available): Likewise.
>     * config/arm/arm-c.c (arm_cpu_builtins): Replace arm_arch5 and
>     arm_arch5e with arm_arch5t and arm_arch5te.
>     * config/arm/arm-protos.h (arm_arch5, arm_arch5e): Delete.
>     (arm_arch5t, arm_arch5te): Declare.
>     * config/arm/arm-tables.opt: Regenerate.
>     * config/arm/t-arm-elf: Remove references to armv5, armv5e.
>     * config/arm/t-multilib: Likewise.
>     * config/arm/thumb1.md (*call_reg_thumb1_v5): Check arm_arch5t
>     instead of arm_arch5.
>     (*call_reg_thumb1): Likewise.
>     (*call_value_reg_thumb1_v5): Likewise.
>     (*call_value_reg_thumb1): Likewise.
>     * config/arm/vxworks.h (TARGET_OS_CPP_BUILTINS): Remove now
>     unreachable path.
>     * doc/invoke.texi (ARM Options): Remove references to armv5, armv5e.
> 
> gcc/testsuite/
> 2018-05-17  Kyrylo Tkachov  
> 
>     * gcc.target/arm/pr40887.c: Update comment.
>     * lib/target-supports.exp: Don't generate effective target checks
>     and related helpers for armv5.  Update comment.
>     * gcc.target/arm/armv5_thumb_isa.c: Delete.
>     * gcc.target/arm/di-longlong64-sync-withhelpers.c: Update effective
>     target check and options.
> 
> libgcc/
> 2018-05-17  Kyrylo Tkachov  
> 
>     * config/arm/libunwind.S: Update comment relating to armv5.
> 
> armv5-remove.patch
> 
> 
> diff --git a/gcc/config/arm/arm-c.c b/gcc/config/arm/arm-c.c
> index 
> 7c741e9fe66a0e086556272a46c4cd709996ce36..4471f7914cf282c516a142174f9913e491558b44
>  100644
> --- a/gcc/config/arm/arm-c.c
> +++ b/gcc/config/arm/arm-c.c
> @@ -212,9 +212,9 @@ arm_cpu_builtins (struct cpp_reader* pfile)
>  {
>int coproc_level = 0x1;
>  
> -  if (arm_arch5)
> +  if (arm_arch5t)
>   coproc_level |= 0x2;
> -  if (arm_arch5e)
> +  if (arm_arch5te)
>   coproc_level |= 0x4;
>if (arm_arch6)
>   coproc_level |= 0x8;
> diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
> index 
> 96972a057e7459874ef0bdac5e6379fb666e4189..0a318877f10394e2c045d2a03a8f0757557136cf
>  100644
> --- a/gcc/config/arm/arm-cpus.in
> +++ b/gcc/config/arm/arm-cpus.in
> @@ -60,14 +60,14 @@ define feature mode32
>  # Architecture rel 4
>  define feature armv4
>  
> -# Architecture rel 5
> -define feature armv5
> -
>  # Thumb aware.
>  define feature thumb
>  
> -# Architecture rel 5e.
> -define feature armv5e
> +# Architecture rel 5t.
> +define feature armv5t
> +
> +# Architecture rel 5te.
> +define feature armv5te
>  
>  # XScale.
>  

Re: [PATCH] Improve get_ref_base_and_extent with range-info

[Richard Biener]

On Thu, 17 May 2018, Richard Biener wrote:

> 
> The following makes use of range-info to improve the basic building
> block of the alias-oracle so we can tell that in
> 
>   a[0] = 1;
>   for (int i = 5; i < 17; ++i)
> a[i] = i;
>   a[0] = 2;
> 
> the ao_ref for a[i] does not alias the a[0] acceses.  Given range-info
> is not always going to improve things over knowledge gained from
> the type size of the access I'm only improving it over information
> gathered from the size.
> 
> For the above this allows us to DSE the first store with another
> DSE improvement I'm testing separately.
> 
> Bootstrap & regtest in progress on x86_64-unknown-linux-gnu.

I've committed the following sligtly safer with respect to
flexarray - I'll improve it as followup but need to refactor things
a bit for that.  I've also adjusted graphite testcases producing
dead data.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2018-05-18  Richard Biener  

* tree-dfa.c (get_ref_base_and_extent): Use range-info to refine
results when processing array refs with variable index.

* gcc.dg/tree-ssa/ssa-dse-35.c: New testcase.
* gcc.dg/graphite/scop-10.c: Adjust to avoid dead code.
* gcc.dg/graphite/scop-6.c: Likewise.
* gcc.dg/graphite/scop-7.c: Likewise.
* gcc.dg/graphite/scop-8.c: Likewise.
* gcc.dg/graphite/scop-9.c: Likewise.

diff --git a/gcc/testsuite/gcc.dg/graphite/scop-10.c 
b/gcc/testsuite/gcc.dg/graphite/scop-10.c
index 20d53510b4e..d04183072f3 100644
--- a/gcc/testsuite/gcc.dg/graphite/scop-10.c
+++ b/gcc/testsuite/gcc.dg/graphite/scop-10.c
@@ -22,7 +22,7 @@ int toto()
 b[i+k] = b[i+k-5] + 2;
 }
 
-  return a[3][5] + b[1];
+  return a[3][5] + b[2];
 }
 
 /* { dg-final { scan-tree-dump-times "number of SCoPs: 1" 1 "graphite"} } */
diff --git a/gcc/testsuite/gcc.dg/graphite/scop-6.c 
b/gcc/testsuite/gcc.dg/graphite/scop-6.c
index 1da486a2ddf..9bc1d9f4ccd 100644
--- a/gcc/testsuite/gcc.dg/graphite/scop-6.c
+++ b/gcc/testsuite/gcc.dg/graphite/scop-6.c
@@ -23,7 +23,7 @@ int toto()
 b[i+k] = b[i+k-5] + 2;
 }
 
-  return a[3][5] + b[1];
+  return a[3][5] + b[2];
 }
 
 /* { dg-final { scan-tree-dump-times "number of SCoPs: 1" 1 "graphite"} } */
diff --git a/gcc/testsuite/gcc.dg/graphite/scop-7.c 
b/gcc/testsuite/gcc.dg/graphite/scop-7.c
index 2f0a50470e9..f4f3093fcaf 100644
--- a/gcc/testsuite/gcc.dg/graphite/scop-7.c
+++ b/gcc/testsuite/gcc.dg/graphite/scop-7.c
@@ -23,7 +23,7 @@ int toto()
 b[i+k] = b[i+k-5] + 2;
 }
 
-  return a[3][5] + b[1];
+  return a[3][5] + b[2];
 }
 
 /* { dg-final { scan-tree-dump-times "number of SCoPs: 1" 1 "graphite"} } */
diff --git a/gcc/testsuite/gcc.dg/graphite/scop-8.c 
b/gcc/testsuite/gcc.dg/graphite/scop-8.c
index 3ceb5d874d6..b06265108c6 100644
--- a/gcc/testsuite/gcc.dg/graphite/scop-8.c
+++ b/gcc/testsuite/gcc.dg/graphite/scop-8.c
@@ -23,7 +23,7 @@ int toto()
 b[i+k] = b[i+k-5] + 2;
 }
 
-  return a[3][5] + b[1];
+  return a[3][5] + b[2];
 }
 
 /* { dg-final { scan-tree-dump-times "number of SCoPs: 1" 1 "graphite"} } */
diff --git a/gcc/testsuite/gcc.dg/graphite/scop-9.c 
b/gcc/testsuite/gcc.dg/graphite/scop-9.c
index 93888728b0d..b19291be2f8 100644
--- a/gcc/testsuite/gcc.dg/graphite/scop-9.c
+++ b/gcc/testsuite/gcc.dg/graphite/scop-9.c
@@ -18,7 +18,7 @@ int toto()
 b[i+k] = b[i+k-5] + 2;
 }
 
-  return a[3][5] + b[1];
+  return a[3][5] + b[2];
 }
 
 /* { dg-final { scan-tree-dump-times "number of SCoPs: 1" 1 "graphite"} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-35.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-35.c
new file mode 100644
index 000..1f21670406f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-35.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dse1-details" } */
+
+int a[256];
+void foo (void)
+{
+  a[0] = 1;
+  for (int i = 5; i < 17; ++i)
+a[i] = i;
+  a[0] = 2;
+}
+
+/* { dg-final { scan-tree-dump-times "Deleted dead store" 1 "dse1" } } */
Index: gcc/tree-dfa.c
===
--- gcc/tree-dfa.c  (revision 260322)
+++ gcc/tree-dfa.c  (working copy)
@@ -529,6 +529,49 @@ get_ref_base_and_extent (tree exp, poly_
/* Remember that we have seen an array ref with a variable
   index.  */
seen_variable_array_ref = true;
+
+   wide_int min, max;
+   if (TREE_CODE (index) == SSA_NAME
+   && (low_bound = array_ref_low_bound (exp),
+   poly_int_tree_p (low_bound))
+   && (unit_size = array_ref_element_size (exp),
+   TREE_CODE (unit_size) == INTEGER_CST)
+   && get_range_info (index, , ) == VR_RANGE)
+ {
+   poly_offset_int lbound = wi::to_poly_offset (low_bound);
+   /* Try to constrain maxsize 

Re: PR85817

[Richard Biener]

On Fri, 18 May 2018, Prathamesh Kulkarni wrote:

> Hi,
> In r260250, the condition
> 
> if (integer_zerop (retval))
>   continue;
> 
> was added before checking retval was of pointer type which caused
> functions having return type apart from void *, to be marked as
> malloc. The attached patch gets rid of the above check since we do not
> wish to mark function returning NULL as malloc.
> Also, it adds a check to return false if all args to phi are 0,
> although I am not sure if this'd actually trigger in practice since
> constant propagation should have folded the phi into constant 0
> already.
> 
> Bootstrap+test in progress on x86_64-linux-gnu and aarch64-linux-gnu.
> OK to commit if passes ?

OK.

Thanks,
Richard.

Re: [PATCH] libstdc++/85184 remove __glibcxx_assert assertions from

[François Dumont]

On 15/05/2018 18:56, Jonathan Wakely wrote:

As I said in the bugzilla PR, these assertions are all to catch our
own mistakes, not user error.

If we're comfortable the code is correct then we should remove them.

Should we wait until near the end of stage 1, to get more time with
these checks in place?



I am in favor of doing this cleanup now.

We will surely forget it later and we have proper tests to track our dev 
mistakes rather than assertions.


François

PR85817

[Prathamesh Kulkarni]

Hi,
In r260250, the condition

if (integer_zerop (retval))
  continue;

was added before checking retval was of pointer type which caused
functions having return type apart from void *, to be marked as
malloc. The attached patch gets rid of the above check since we do not
wish to mark function returning NULL as malloc.
Also, it adds a check to return false if all args to phi are 0,
although I am not sure if this'd actually trigger in practice since
constant propagation should have folded the phi into constant 0
already.

Bootstrap+test in progress on x86_64-linux-gnu and aarch64-linux-gnu.
OK to commit if passes ?

Thanks,
Prathamesh
2018-05-18  Prathamesh Kulkarni  

PR middle-end/85817
* ipa-pure-const.c (malloc_candidate_p): Remove the check integer_zerop
for retval and return false if all args to phi are zero.

testsuite/
* gcc.dg/tree-ssa/pr83648.c: Change scan-tree-dump to
scan-tree-dump-not for h.

diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index 567b615fb60..528ea6695ac 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -940,9 +940,6 @@ malloc_candidate_p (function *fun, bool ipa)
   if (!retval)
DUMP_AND_RETURN("No return value.")
 
-  if (integer_zerop (retval))
-   continue;
-
   if (TREE_CODE (retval) != SSA_NAME
  || TREE_CODE (TREE_TYPE (retval)) != POINTER_TYPE)
DUMP_AND_RETURN("Return value is not SSA_NAME or not a pointer type.")
@@ -972,37 +969,44 @@ malloc_candidate_p (function *fun, bool ipa)
}
 
   else if (gphi *phi = dyn_cast (def))
-   for (unsigned i = 0; i < gimple_phi_num_args (phi); ++i)
- {
-   tree arg = gimple_phi_arg_def (phi, i);
-   if (integer_zerop (arg))
- continue;
+   {
+ bool all_args_zero = true;
+ for (unsigned i = 0; i < gimple_phi_num_args (phi); ++i)
+   {
+ tree arg = gimple_phi_arg_def (phi, i);
+ if (integer_zerop (arg))
+   continue;
+
+ all_args_zero = false;
+ if (TREE_CODE (arg) != SSA_NAME)
+   DUMP_AND_RETURN ("phi arg is not SSA_NAME.");
+ if (!check_retval_uses (arg, phi))
+   DUMP_AND_RETURN ("phi arg has uses outside phi"
+" and comparisons against 0.")
+
+ gimple *arg_def = SSA_NAME_DEF_STMT (arg);
+ gcall *call_stmt = dyn_cast (arg_def);
+ if (!call_stmt)
+   return false;
+ tree callee_decl = gimple_call_fndecl (call_stmt);
+ if (!callee_decl)
+   return false;
+ if (!ipa && !DECL_IS_MALLOC (callee_decl))
+   DUMP_AND_RETURN("callee_decl does not have malloc attribute"
+   " for non-ipa mode.")
+
+ cgraph_edge *cs = node->get_edge (call_stmt);
+ if (cs)
+   {
+ ipa_call_summary *es = ipa_call_summaries->get (cs);
+ gcc_assert (es);
+ es->is_return_callee_uncaptured = true;
+   }
+   }
 
-   if (TREE_CODE (arg) != SSA_NAME)
- DUMP_AND_RETURN ("phi arg is not SSA_NAME.");
-   if (!check_retval_uses (arg, phi))
- DUMP_AND_RETURN ("phi arg has uses outside phi"
-  " and comparisons against 0.")
-
-   gimple *arg_def = SSA_NAME_DEF_STMT (arg);
-   gcall *call_stmt = dyn_cast (arg_def);
-   if (!call_stmt)
- return false;
-   tree callee_decl = gimple_call_fndecl (call_stmt);
-   if (!callee_decl)
- return false;
-   if (!ipa && !DECL_IS_MALLOC (callee_decl))
- DUMP_AND_RETURN("callee_decl does not have malloc attribute for"
- " non-ipa mode.")
-
-   cgraph_edge *cs = node->get_edge (call_stmt);
-   if (cs)
- {
-   ipa_call_summary *es = ipa_call_summaries->get (cs);
-   gcc_assert (es);
-   es->is_return_callee_uncaptured = true;
- }
- }
+ if (all_args_zero)
+   DUMP_AND_RETURN ("Return value is a phi with all args equal to 0.");
+   }
 
   else
DUMP_AND_RETURN("def_stmt of return value is not a call or phi-stmt.")
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr83648.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr83648.c
index febfd7d9319..884faf81167 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr83648.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr83648.c
@@ -12,4 +12,4 @@ void *h()
 }
 
 /* { dg-final { scan-tree-dump "Function found to be malloc: g" 
"local-pure-const1" } } */
-/* { dg-final { scan-tree-dump "Function found to be malloc: h" 
"local-pure-const1" } } */
+/* { dg-final { scan-tree-dump-not "Function found to be malloc: h" 
"local-pure-const1" } } */

Re: [PATCH GCC][2/6]Compute available register for each register classes

[Bin.Cheng]

On Fri, May 4, 2018 at 5:21 PM, Bin Cheng  wrote:
> Hi,
> This is the second patch computing available/clobber registers for register 
> classes.
> It's the same as the original patch posted 
> @https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01022.html
>
> Bootstrap and test on x86_64 and AArch64 ongoing.  Any comments?
Same as previous one.
The original version of this patch was approved by Jeff
@https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01810.html
Jeff, any new comments or the approval is valid?

Thanks,
bin

>
> Thanks,
> bin
> 2017-04-27  Bin Cheng  
>
> * cfgloop.h (struct target_cfgloop): Change x_target_avail_regs and
> x_target_clobbered_regs into array fields.
> (init_avail_clobber_regs): New declaration.
> * cfgloopanal.c (memmodel.h, ira.h): Include header files.
> (init_set_costs): Remove computation for old x_target_avail_regs and
> x_target_clobbered_regs fields.
> (init_avail_clobber_regs): New function.
> (estimate_reg_pressure_cost): Update the uses.
> * toplev.c (cfgloop.h): Update comment why the header file is needed.
> (backend_init_target): Call init_avail_clobber_regs.
> * tree-predcom.c (memmodel.h, ira.h): Include header files.
> (MAX_DISTANCE): Update the use.
> * tree-ssa-loop-ivopts.c (AVAILABLE_REGS, CLOBBERED_REGS): New marco.
> (ivopts_estimate_reg_pressure, determine_set_costs): Update the uses.

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")​ (Take 2)

[Paolo Carlini]

Hi,


On 18/05/2018 01:21, Jason Merrill wrote:
On Thu, May 17, 2018 at 5:54 PM, Paolo Carlini 
 wrote:

On 17/05/2018 16:58, Jason Merrill wrote:

On Thu, May 17, 2018 at 10:27 AM, Paolo Carlini
 wrote:

PS: maybe better using function_declarator_p?

I think so, yes.  The relevant rule seems to be "The declarator shall
not specify a function or an array.", so let's check for arrays, too.
Agreed. I had the amended patch ready when I noticed (again) that 
it wasn't
addressing another related class of issues which involves 
declarators not
followed by initializers. Thus I tried to fix those too, and the 
below which
moves the check up appears to work fine, passes testing, etc. Are 
there any
risks that an erroneous function / array as declarator is in fact a 
well

formed expression?!?

That doesn't matter; if it parses as a declarator, it's a declarator,
even if it's an ill-formed declarator.  But...

+  bool decl_p = cp_parser_parse_definitely (parser);
+  if (!cp_parser_check_condition_declarator (parser, 
declarator, loc))

+    return error_mark_node;

...if cp_parser_parse_definitely returns false, parsing as a
declarator failed, so we shouldn't look at "declarator".
What I'm attaching below isn't affected by this problem: I moved the 
check further up - *before* maybe calling cp_parser_simulated_error 
because an initializer isn't in sight - and is carried out only when 
!cp_parser_error_occurred, thus cp_parser_declarator succeeded . 
cp_parser_commit_to_tentative_parse is called when the check fails. 
Bootstrapped and tested on x86_64-linux.


Thanks!
Paolo.

//
Index: cp/parser.c
===
--- cp/parser.c (revision 260347)
+++ cp/parser.c (working copy)
@@ -11527,6 +11527,34 @@ cp_parser_selection_statement (cp_parser* parser,
 }
 }
 
+/* Helper function for cp_parser_condition.  Enforces [stmt.stmt]/2:
+   The declarator shall not specify a function or an array.  Returns
+   TRUE if the declarator is valid, FALSE otherwise.  */
+
+static bool
+cp_parser_check_condition_declarator (cp_parser* parser,
+ cp_declarator *declarator,
+ location_t loc)
+{
+  if (function_declarator_p (declarator)
+  || declarator->kind == cdk_array)
+{
+  cp_parser_commit_to_tentative_parse (parser);
+  if (declarator->kind == cdk_array)
+   error_at (loc, "condition declares an array");
+  else
+   error_at (loc, "condition declares a function");
+  if (parser->fully_implicit_function_template_p)
+   abort_fully_implicit_template (parser);
+  cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
+/*or_comma=*/false,
+/*consume_paren=*/false);
+  return false;
+}
+  else
+return true;
+}
+
 /* Parse a condition.
 
condition:
@@ -11571,6 +11599,7 @@ cp_parser_condition (cp_parser* parser)
   tree attributes;
   cp_declarator *declarator;
   tree initializer = NULL_TREE;
+  location_t loc = cp_lexer_peek_token (parser->lexer)->location;
 
   /* Parse the declarator.  */
   declarator = cp_parser_declarator (parser, CP_PARSER_DECLARATOR_NAMED,
@@ -11582,6 +11611,11 @@ cp_parser_condition (cp_parser* parser)
   attributes = cp_parser_attributes_opt (parser);
   /* Parse the asm-specification.  */
   asm_specification = cp_parser_asm_specification_opt (parser);
+
+  if (!cp_parser_error_occurred (parser)
+ && !cp_parser_check_condition_declarator (parser, declarator, loc))
+   return error_mark_node;
+
   /* If the next token is not an `=' or '{', then we might still be
 looking at an expression.  For example:
 
Index: testsuite/g++.dg/cpp0x/cond1.C
===
--- testsuite/g++.dg/cpp0x/cond1.C  (nonexistent)
+++ testsuite/g++.dg/cpp0x/cond1.C  (working copy)
@@ -0,0 +1,23 @@
+// PR c++/84588
+// { dg-do compile { target c++11 } }
+
+void foo()
+{
+  if (int bar() {})  // { dg-error "condition declares a function" }
+;
+
+  for (;int bar() {};)  // { dg-error "condition declares a function" }
+;
+
+  while (int bar() {})  // { dg-error "condition declares a function" }
+;
+
+  if (int a[] {})  // { dg-error "condition declares an array" }
+;
+
+  for (;int a[] {};)  // { dg-error "condition declares an array" }
+;
+
+  while (int a[] {})  // { dg-error "condition declares an array" }
+;
+}
Index: testsuite/g++.dg/cpp1y/pr84588-1.C
===
--- testsuite/g++.dg/cpp1y/pr84588-1.C  (nonexistent)
+++ testsuite/g++.dg/cpp1y/pr84588-1.C  (working copy)
@@ -0,0 +1,25 @@
+// { dg-do compile { target c++14 } }
+
+struct a {
+  void b() {}
+  void c(void 

Re: [PATCH GCC][1/6]Compute type mode and register class mapping

[Bin.Cheng]

On Fri, May 4, 2018 at 5:21 PM, Bin Cheng  wrote:
> Hi,
> This is the updated version patch set computing register pressure on TREE SSA
> and use that information to direct other loop optimizers (predcom only for 
> now).
> This version of change is to follow Jeff's comment that we should reuse 
> existing
> tree-ssa-live.c infrastructure for live range computation, rather than 
> inventing
> another one.
> Jeff had another concern about exposing ira.h and low-level register stuff in
> GIMPLE world.  Unfortunately I haven't got a clear solution to it.  I found 
> it's
> a bit hard to relate type/type_mode with register class and with available 
> regs
> without exposing the information, especially there are multiple possible 
> register
> classes for vector types and it's not fixed.  I am open to any suggestions 
> here.
>
> This is the first patch estimating the map from type mode to register class.
> This one doesn't need update and it's the same as the original version patch
> at https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01021.html
>
> Bootstrap and test on x86_64 and AArch64 ongoing.  Any comments?
Hi,
The original version of this patch was approved by Jeff
@https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01808.html
Jeff, some new comment now or the old approval is still valid?
Guess your major concern is about exporting ira.h to gimple world?

Thanks,
bin

>
> Thanks,
> bin
> 2018-04-27  Bin Cheng  
>
> * ira.c (setup_mode_classes): New function.
> (find_reg_classes): Call above function.
> * ira.h (struct target_ira): New field x_ira_mode_classes.
> (ira_mode_classes): New macro.

Fix tree-ssa-strlen handling of partial clobber (PR85814)

[Richard Sandiford]

In this PR we have:

  c_5 = c_4(D) + 4;
  c_12 = c_5 + 1;
  *c_5 = 2;
  a = 2;// A
  c_21 = c_12 + 1;
  *c_12 = 2;
  a = 2;// B
  c_28 = c_21 + 1;
  *c_21 = 2;
  a = 2;
  c_7 = c_28 + 1;
  *c_28 = 2;

where a is a global int.  We decide that A can't clobber *c_5 == c_4[4]
because the latter implies that c_4 is an object of 5 bytes or more,
whereas a has exactly 4 bytes.

The assumption for B and *c_5 is the same, but when considering B and
*c_12, we only follow the definition of c_12 to c_5 + 1 (for good
reason) and so have *c_12 == c_5[1].  We then don't have the same
size guarantee and so assume that B could clobber *c_12.  This leads
to a situation in which the strinfo for c_5 is still valid but the
next strinfo (c_12) isn't.  We then segfaulted while trying to get
the strinfo for c_21 + 1 == c_5 + 3 because get_stridx_plus_constant
assumed that c_5's next strinfo (c_12) would be valid too.

And of course it should be valid really.  It doesn't make sense for the
string based at c_5 to be valid but a substring of it to be invalid.
I don't think we can guarantee that such weird corner cases never
happen though, even if we tried to avoid this one.

One possibility would be to mark c_12 as valid on the basis that c_5
is valid, but I'm not sure the complication is worth it given that it
seems to trigger very rarely.  A better optimisation would be to get
the unroller to clean up after itself a bit more...

Although this particular instance of the bug relies on r249880, I think
we could have similar problems in GCC 7.  It would be much harder to
trigger though, especially since it relies on unfolded IR like the above.

Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
OK for trunk and GCC 8?

Richard


2018-05-18  Richard Sandiford  

gcc/
PR tree-optimization/85814
* tree-ssa-strlen.c (get_stridx_plus_constant): Cope with
a null return from get_strinfo when unsharing the next
strinfo in the chain.

gcc/testsuite/
PR tree-optimization/85814
* gcc.dg/torture/pr85814.c: New test.

Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c   2018-03-13 15:06:00.657514354 +
+++ gcc/tree-ssa-strlen.c   2018-05-18 09:05:44.691476297 +0100
@@ -795,9 +795,9 @@ get_stridx_plus_constant (strinfo *bases
   si = new_strinfo (ptr, idx, build_int_cst (size_type_node, nonzero_chars),
basesi->full_string_p);
   set_strinfo (idx, si);
-  if (chainsi->next)
+  if (strinfo *nextsi = get_strinfo (chainsi->next))
 {
-  strinfo *nextsi = unshare_strinfo (get_strinfo (chainsi->next));
+  nextsi = unshare_strinfo (nextsi);
   si->next = nextsi->idx;
   nextsi->prev = idx;
 }
Index: gcc/testsuite/gcc.dg/torture/pr85814.c
===
--- /dev/null   2018-04-20 16:19:46.369131350 +0100
+++ gcc/testsuite/gcc.dg/torture/pr85814.c  2018-05-18 09:05:44.689476382 
+0100
@@ -0,0 +1,7 @@
+int a;
+void b(char *c)
+{
+  c += 4;
+  for (int i = 0; i < 4; i++)
+a = *c++ = 2;
+}

Re: [patch] Improve support for up-level references (1/n)

[Richard Biener]

On Fri, May 18, 2018 at 9:43 AM Eric Botcazou  wrote:

> Hi,

> the compiler has had built-in support for nested functions for a long
time,
> which makes it possible to support them in GNU C (as an extension) and in
Ada;
> Fortran uses them too but marginally.  The support was entirely rewritten
for
> GCC 4 and a few rough edges have remained since then, which are quite
visible
> in languages where they are first-class citizens like Ada.

> The first rough edge is the stack usage at -O0: it is twice as large as
needed
> for variables subject to up-level references.  So you declare an array of
2KB
> bytes on the stack, factor out some code that reads it into a child
function
> and then you suddenly need 4KB of stack instead of 2KB.  Even at -O0 this
can
> be annoying for very embedded platforms.

> The attached patch fixes it and also contains a tweak to
use_pointer_in_frame
> for the sake of consistency but with no functional changes in practice.

> Tested on x86-64/Linux, OK for the mainline?

+ /* If the next declaration is a PARM_DECL pointing to the
DECL,
+we need to adjust its VALUE_EXPR directly, since chains of
+VALUE_EXPRs run afoul of garbage collection.  This occurs
+in Ada for Out parameters that aren't copied in.  */
+ if (next
+ && TREE_CODE (next) == PARM_DECL
+ && DECL_HAS_VALUE_EXPR_P (next)
+ && DECL_VALUE_EXPR (next) == decl)
+   SET_DECL_VALUE_EXPR (next, x);

maybe you can explain the GC issue a bit.  I also think that you should
adjust
the next DECL_VALUE_EXRP before setting DECL_VALUE_EXPR on decl so
we can do sth like the following to verify we do not face this very
situation
(it's of course incomplete verification, we could search for a suitable
place
in some of the IL verifiers but I'm not sure there is one early enough and
catching all decls).

diff --git a/gcc/tree.c b/gcc/tree.c
index 68165f4deed..ded12782aea 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -6340,7 +6340,14 @@ decl_value_expr_lookup (tree from)

h = value_expr_for_decl->find_with_hash (, DECL_UID (from));
if (h)
-return h->to;
+{
+  /* Chains of value-exprs run afoul of garbage collection, make
+ sure we never end up with those.  */
+  gcc_checking_assert ((TREE_CODE (h->to) != PARM_DECL
+   && TREE_CODE (h->to) != VAR_DECL)
+  || !DECL_HAS_VALUE_EXPR_P (h->to));
+  return h->to;
+}
return NULL_TREE;
  }

@@ -6351,6 +6358,12 @@ decl_value_expr_insert (tree from, tree to)
  {
struct tree_decl_map *h;

+  /* Chains of value-exprs run afoul of garbage collection, make
+ sure we never end up with those.  */
+  gcc_checking_assert ((TREE_CODE (to) != PARM_DECL
+   && TREE_CODE (to) != VAR_DECL)
+  || !DECL_HAS_VALUE_EXPR_P (to));
+
h = ggc_alloc ();
h->base.from = from;
h->to = to;



> 2018-05-18  Eric Botcazou  

>  * tree-nested.c (use_pointer_in_frame): Tweak.
>  (lookup_field_for_decl): Add assertion and declare the
transformation.


> 2018-05-18  Eric Botcazou  

>  * gnat.dg/stack_usage5.adb: New test.

> --
> Eric Botcazou

[PING^2][RFC] Use gfc_decl_attributes in fortran frontend

[Tom de Vries]

On 01/13/2016 05:21 PM, Tom de Vries wrote:

On 17/12/15 13:08, Tom de Vries wrote:

Hi,

Consider this patch, which reduces max_len of the oacc function
attribute to 0:
...
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 8556b70..60f4ad3 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -93,7 +93,7 @@ static const struct attribute_spec
gfc_attribute_table[] =
 affects_type_identity } */
    { "omp declare target", 0, 0, true,  false, false,
  gfc_handle_omp_declare_target_attribute, false },
-  { "oacc function", 0, -1, true,  false, false,
+  { "oacc function", 0, 0, true,  false, false,
  gfc_handle_omp_declare_target_attribute, false },
    { NULL,    0, 0, false, false, false, NULL, false }
  };
...

The patch is obviously incorrect, but the idea here is to try to trigger
this error in decl_attributes:
...
   else if (list_length (args) < spec->min_length
    || (spec->max_length >= 0
    && list_length (args) > spec->max_length))
 {
   error ("wrong number of arguments specified for %qE"
  " attribute",
  name);
...

When running goacc.exp=routine-4.f90, we trigger the error, but then run
into an assert.

The assert is caused by the fact that %qE is not handled by the fortran
format decoder gfc_format_decoder, so this assert triggers in pp_format:
...
 ok = pp_format_decoder (pp) (pp, text, p,
  precision, wide, plus, hash);
 gcc_assert (ok);
...


So, it seems that we call decl_attributes from the fortran frontend
without installing a format decoder that can handle any potential errors.

This patch attempts to fix that, but having little experience in both
diagnostics and fortran frontend, I'm not sure if this is the right way.

After applying the patch, the assert is fixed and we can see the actual
error without having to start up the debugger:
...
src/gcc/testsuite/gfortran.dg/goacc/routine-4.f90:121:0: Error: wrong
number of arguments specified for ‘oacc function’ attribute
...

Thanks,
- Tom

0001-Use-gfc_decl_attributes-in-fortran-frontend.patch


Use gfc_decl_attributes in fortran frontend

---
  gcc/fortran/error.c  | 18 --
  gcc/fortran/gfortran.h   |  2 ++
  gcc/fortran/trans-decl.c | 18 ++
  3 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/gcc/fortran/error.c b/gcc/fortran/error.c
index 8f57aff..fd66d75 100644
--- a/gcc/fortran/error.c
+++ b/gcc/fortran/error.c
@@ -1417,11 +1417,18 @@ gfc_errors_to_warnings (bool f)
  }

  void
-gfc_diagnostics_init (void)
+gfc_diagnostics_fortran (void)
  {
    diagnostic_starter (global_dc) = gfc_diagnostic_starter;
    diagnostic_finalizer (global_dc) = gfc_diagnostic_finalizer;
    diagnostic_format_decoder (global_dc) = gfc_format_decoder;
+}
+
+void
+gfc_diagnostics_init (void)
+{
+  gfc_diagnostics_fortran ();
+
    global_dc->caret_chars[0] = '1';
    global_dc->caret_chars[1] = '2';
    pp_warning_buffer = new (XNEW (output_buffer)) output_buffer ();
@@ -1433,13 +1440,20 @@ gfc_diagnostics_init (void)
  }

  void
-gfc_diagnostics_finish (void)
+gfc_diagnostics_tree (void)
  {
    tree_diagnostics_defaults (global_dc);
    /* We still want to use the gfc starter and finalizer, not the tree
   defaults.  */
    diagnostic_starter (global_dc) = gfc_diagnostic_starter;
    diagnostic_finalizer (global_dc) = gfc_diagnostic_finalizer;
+}
+
+void
+gfc_diagnostics_finish (void)
+{
+  gfc_diagnostics_tree ();
+
    global_dc->caret_chars[0] = '^';
    global_dc->caret_chars[1] = '^';
  }
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index d203c32..1f7cdc2 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2687,6 +2687,8 @@ bool gfc_find_sym_in_expr (gfc_symbol *, 
gfc_expr *);

  void gfc_error_init_1 (void);
  void gfc_diagnostics_init (void);
  void gfc_diagnostics_finish (void);
+void gfc_diagnostics_fortran (void);
+void gfc_diagnostics_tree (void);
  void gfc_buffer_error (bool);

  const char *gfc_print_wide_char (gfc_char_t);
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 8c4fa03..9ed1d07 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1326,6 +1326,16 @@ add_attributes_to_decl (symbol_attribute 
sym_attr, tree list)

  }


+static tree
+gfc_decl_attributes (tree *node, tree attributes, int flags)
+{
+  tree res;
+  gfc_diagnostics_tree ();
+  res = decl_attributes (node, attributes, flags);
+  gfc_diagnostics_fortran ();
+  return res;
+}
+
  static void build_function_decl (gfc_symbol * sym, bool global);


@@ -1567,7 +1577,7 @@ gfc_get_symbol_decl (gfc_symbol * sym)

    /* Add attributes to variables.  Functions are handled elsewhere.  */
    attributes = add_attributes_to_decl (sym->attr, NULL_TREE);
-  decl_attributes (, attributes, 0);
+  gfc_decl_attributes (, attributes, 0);

    /* Symbols from modules should have their assembler names 

Re: GCC 6 backports

[Martin Liška]

On 04/25/2018 03:16 PM, Jan Hubicka wrote:
>> Hi.
>>
>> Sending GCC 6 branch backports.
>> Patches can bootstrap on ppc64le-redhat-linux and survives regression tests.
>> I'm going to install the patches.
>>
>> Martin
> 
>> >From e0d32b1f9e0dd0486e63040e1ab8f5d8e9f0fbd5 Mon Sep 17 00:00:00 2001
>> From: marxin 
>> Date: Tue, 10 Apr 2018 07:24:59 +
>> Subject: [PATCH 1/4] Backport r259265
>>
>> gcc/lto/ChangeLog:
>>
>> 2018-04-10  Richard Biener  
>>  Martin Liska  
>>
>>  PR lto/85248
>>  * lto-symtab.c (lto_symtab_merge_p): Handle noreturn attribute.
> 
> Support for syntactic duplicates was new at that time and several
> changes was made later. So enabling more of them may lead to troubles.
> Did you test that this works for Firefox build?

No, but I've just tested Libreoffice build w/ LTO and it's successfully built.

Martin

> 
> Honza
> 

Re: [RFC][PR64946] "abs" vectorization fails for char/short types

[Richard Biener]

On Fri, May 18, 2018 at 4:37 AM Kugan Vivekanandarajah <
kugan.vivekanandara...@linaro.org> wrote:

> Hi Richard,

> Thanks for the review. I am revising the patch based on Andrew's comments
too.

> On 17 May 2018 at 20:36, Richard Biener 
wrote:
> > On Thu, May 17, 2018 at 4:56 AM Andrew Pinski  wrote:
> >
> >> On Wed, May 16, 2018 at 7:14 PM, Kugan Vivekanandarajah
> >>  wrote:
> >> > As mentioned in the PR, I am trying to add ABSU_EXPR to fix this
> >> > issue. In the attached patch, in fold_cond_expr_with_comparison I am
> >> > generating ABSU_EXPR for these cases. As I understand, absu_expr is
> >> > well defined in RTL. So, the issue is generating absu_expr  and
> >> > transferring to RTL in the correct way. I am not sure I am not doing
> >> > all that is needed. I will clean up and add more test-cases based on
> >> > the feedback.
> >
> >
> >> diff --git a/gcc/optabs-tree.c b/gcc/optabs-tree.c
> >> index 71e172c..2b812e5 100644
> >> --- a/gcc/optabs-tree.c
> >> +++ b/gcc/optabs-tree.c
> >> @@ -235,6 +235,7 @@ optab_for_tree_code (enum tree_code code,
const_tree
> > type,
> >> return trapv ? negv_optab : neg_optab;
> >
> >>   case ABS_EXPR:
> >> +case ABSU_EXPR:
> >> return trapv ? absv_optab : abs_optab;
> >
> >
> >> This part is not correct, it should something like this:
> >
> >>   case ABS_EXPR:
> >> return trapv ? absv_optab : abs_optab;
> >> +case ABSU_EXPR:
> >> +   return abs_optab ;
> >
> >> Because ABSU is not undefined at the TYPE_MAX.
> >
> > Also
> >
> > /* Unsigned abs is simply the operand.  Testing here means we
don't
> >   risk generating incorrect code below.  */
> > -  if (TYPE_UNSIGNED (type))
> > +  if (TYPE_UNSIGNED (type)
> > + && (code != ABSU_EXPR))
> >  return op0;
> >
> > is wrong.  ABSU of an unsigned number is still just that number.
> >
> > The change to fold_cond_expr_with_comparison looks odd to me
> > (premature optimization).  It should be done separately - it seems
> > you are doing

> FE seems to be using this to generate ABS_EXPR from
> c_fully_fold_internal to fold_build3_loc and so on. I changed this to
> generate ABSU_EXPR for the case in the testcase. So the question
> should be, in what cases do we need ABS_EXPR and in what cases do we
> need ABSU_EXPR. It is not very clear to me.

Well, all existing ABS_EXPR generations are obviously fine.  Then there
are transforms that are not possible w/o ABSU_EXPR like the narrowing
you performed here.  This is becasue for ABS_EXPR you can't simply avoid
the undefined
behavior by performing the operation on unsigned integers... (that's similar
to signed integer division of -INT_MIN / -1 -- the result is representable
in
unsigned but not in signed).


> >
> > (simplify (abs (convert @0)) (convert (absu @0)))
> >
> > here.
> >
> > You touch one other place in fold-const.c but there seem to be many
> > more that need ABSU_EXPR handling (you touched the one needed
> > for correctness) - esp. you should at least handle constant folding
> > in const_unop and the nonnegative predicate.

> OK.
> >
> > @@ -3167,6 +3167,9 @@ verify_expr (tree *tp, int *walk_subtrees, void
*data
> > ATTRIBUTE_UNUSED)
> > CHECK_OP (0, "invalid operand to unary operator");
> > break;
> >
> > +case ABSU_EXPR:
> > +  break;
> > +
> >   case REALPART_EXPR:
> >   case IMAGPART_EXPR:
> >
> > verify_expr is no more.  Did you test this recently against trunk?

> This patch is against slightly older trunk. I will rebase it.

> >
> > @@ -3937,6 +3940,9 @@ verify_gimple_assign_unary (gassign *stmt)
> >   case PAREN_EXPR:
> >   case CONJ_EXPR:
> > break;
> > +case ABSU_EXPR:
> > +  /* FIXME.  */
> > +  return false;
> >
> > no - please not!  Please add verification here - ABSU should be only
> > called on INTEGRAL, vector or complex INTEGRAL types and the
> > type of the LHS should be always the unsigned variant of the
> > argument type.

> OK.
> >
> > if (is_gimple_val (cond_expr))
> >   return cond_expr;
> >
> > -  if (TREE_CODE (cond_expr) == ABS_EXPR)
> > +  if (TREE_CODE (cond_expr) == ABS_EXPR
> > +  || TREE_CODE (cond_expr) == ABSU_EXPR)
> >   {
> > rhs1 = TREE_OPERAND (cond_expr, 1);
> > STRIP_USELESS_TYPE_CONVERSION (rhs1);
> >
> > err, but the next line just builds a ABS_EXPR ...
> >
> > How did you identify spots that need adjustment?  I would expect that
> > once folding generates ABSU_EXPR that you need to adjust frontends
> > (C++ constexpr handling for example).  Also I miss adjustments
> > to gimple-pretty-print.c and the GIMPLE FE parser.

> I will add this.
> >
> > recursively grepping throughout the whole gcc/ tree doesn't reveal too
many
> > cases of ABS_EXPR so I think it's reasonable to audit all of them.
> >
> > I also miss some trivial absu simplifications in match.pd.  There are
not

[patch] Improve support for up-level references (1/n)

[Eric Botcazou]

Hi,

the compiler has had built-in support for nested functions for a long time, 
which makes it possible to support them in GNU C (as an extension) and in Ada; 
Fortran uses them too but marginally.  The support was entirely rewritten for 
GCC 4 and a few rough edges have remained since then, which are quite visible 
in languages where they are first-class citizens like Ada.

The first rough edge is the stack usage at -O0: it is twice as large as needed 
for variables subject to up-level references.  So you declare an array of 2KB 
bytes on the stack, factor out some code that reads it into a child function 
and then you suddenly need 4KB of stack instead of 2KB.  Even at -O0 this can 
be annoying for very embedded platforms.

The attached patch fixes it and also contains a tweak to use_pointer_in_frame 
for the sake of consistency but with no functional changes in practice.

Tested on x86-64/Linux, OK for the mainline?


2018-05-18  Eric Botcazou  

* tree-nested.c (use_pointer_in_frame): Tweak.
(lookup_field_for_decl): Add assertion and declare the transformation.


2018-05-18  Eric Botcazou  

* gnat.dg/stack_usage5.adb: New test.

-- 
Eric BotcazouIndex: tree-nested.c
===
--- tree-nested.c	(revision 260239)
+++ tree-nested.c	(working copy)
@@ -236,23 +236,25 @@ get_frame_type (struct nesting_info *inf
   return type;
 }
 
-/* Return true if DECL should be referenced by pointer in the non-local
-   frame structure.  */
+/* Return true if DECL should be referenced by pointer in the non-local frame
+   structure.  */
 
 static bool
 use_pointer_in_frame (tree decl)
 {
   if (TREE_CODE (decl) == PARM_DECL)
 {
-  /* It's illegal to copy TREE_ADDRESSABLE, impossible to copy variable
- sized decls, and inefficient to copy large aggregates.  Don't bother
- moving anything but scalar variables.  */
+  /* It's illegal to copy TREE_ADDRESSABLE, impossible to copy variable-
+	 sized DECLs, and inefficient to copy large aggregates.  Don't bother
+	 moving anything but scalar parameters.  */
   return AGGREGATE_TYPE_P (TREE_TYPE (decl));
 }
   else
 {
-  /* Variable sized types make things "interesting" in the frame.  */
-  return DECL_SIZE (decl) == NULL || !TREE_CONSTANT (DECL_SIZE (decl));
+  /* Variable-sized DECLs can only come from OMP clauses at this point
+	 since the gimplifier has already turned the regular variables into
+	 pointers.  Do the same as the gimplifier.  */
+  return !DECL_SIZE (decl) || TREE_CODE (DECL_SIZE (decl)) != INTEGER_CST;
 }
 }
 
@@ -263,6 +265,8 @@ static tree
 lookup_field_for_decl (struct nesting_info *info, tree decl,
 		   enum insert_option insert)
 {
+  gcc_checking_assert (decl_function_context (decl) == info->context);
+
   if (insert == NO_INSERT)
 {
   tree *slot = info->field_map->get (decl);
@@ -272,6 +276,7 @@ lookup_field_for_decl (struct nesting_in
   tree *slot = >field_map->get_or_insert (decl);
   if (!*slot)
 {
+  tree type = get_frame_type (info);
   tree field = make_node (FIELD_DECL);
   DECL_NAME (field) = DECL_NAME (decl);
 
@@ -290,9 +295,29 @@ lookup_field_for_decl (struct nesting_in
   TREE_ADDRESSABLE (field) = TREE_ADDRESSABLE (decl);
   DECL_NONADDRESSABLE_P (field) = !TREE_ADDRESSABLE (decl);
   TREE_THIS_VOLATILE (field) = TREE_THIS_VOLATILE (decl);
+
+	  /* Declare the transformation and adjust the original DECL.  */
+	  if (VAR_P (decl))
+	{
+	  tree next = DECL_CHAIN (decl);
+	  tree x
+		= build3 (COMPONENT_REF, TREE_TYPE (field), info->frame_decl,
+			  field, NULL_TREE);
+	  SET_DECL_VALUE_EXPR (decl, x);
+	  DECL_HAS_VALUE_EXPR_P (decl) = 1;
+	  /* If the next declaration is a PARM_DECL pointing to the DECL,
+		 we need to adjust its VALUE_EXPR directly, since chains of
+		 VALUE_EXPRs run afoul of garbage collection.  This occurs
+		 in Ada for Out parameters that aren't copied in.  */
+	  if (next
+		  && TREE_CODE (next) == PARM_DECL
+		  && DECL_HAS_VALUE_EXPR_P (next)
+		  && DECL_VALUE_EXPR (next) == decl)
+		SET_DECL_VALUE_EXPR (next, x);
+	}
 	}
 
-  insert_field_into_struct (get_frame_type (info), field);
+  insert_field_into_struct (type, field);
   *slot = field;
 
   if (TREE_CODE (decl) == PARM_DECL)
-- { dg-do compile }
-- { dg-options "-Wstack-usage=512" }

procedure Stack_Usage5 (C : Character) is

  S : String (1 .. 300);

  procedure Set is
  begin
S (1) := C;
  end;

begin
  Set;
end;

Re: Documentation patch for -floop-interchange and -floop-unroll-and-jam.

[Richard Biener]

On Thu, May 17, 2018 at 8:36 PM Toon Moene  wrote:

> The documentation of both options is still inconsistent, in both the
> trunk and the gcc-8 branch.

> The following is my suggestion to clear this up (and move
> -floop-unroll-and-jam close to -floop-interchange.

> ChangeLog:

> 2018-05-17  Toon Moene  

>  * doc/invoke.texi: Move -floop-unroll-and-jam documentation
>  directly after that of -floop-interchange. Indicate that both
>  options are enabled by default when specifying -O3.

> OK for trunk and gcc-8 ?

OK.

Richard.


> --
> Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
> Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Re: [PATCH GCC][4/6]Support regional coalesce and live range computation

[Richard Biener]

On Thu, May 17, 2018 at 5:49 PM Bin.Cheng  wrote:

> On Thu, May 17, 2018 at 3:04 PM, Richard Biener
>  wrote:
> > On Tue, May 15, 2018 at 5:44 PM Bin.Cheng  wrote:
> >
> >> On Fri, May 11, 2018 at 1:53 PM, Richard Biener
> >>  wrote:
> >> > On Fri, May 4, 2018 at 6:23 PM, Bin Cheng  wrote:
> >> >> Hi,
> >> >> Following Jeff's suggestion, I am now using existing tree-ssa-live.c
> > and
> >> >> tree-ssa-coalesce.c to compute register pressure, rather than
inventing
> >> >> another live range solver.
> >> >>
> >> >> The major change is to record region's basic blocks in var_map and
use
> > that
> >> >> information in computation, rather than FOR_EACH_BB_FN.  For now
only
> > loop
> >> >> and function type regions are supported.  The default one is
function
> > type
> >> >> region which is used in out-of-ssa.  Loop type region will be used
in
> > next
> >> >> patch to compute information for a loop.
> >> >>
> >> >> Bootstrap and test on x86_64 and AArch64 ongoing.  Any comments?
> >> >
> >> > I believe your changes to create_outofssa_var_map should be done
> > differently
> >> > by simply only calling it from the coalescing context and passing in
the
> >> > var_map rather than initializing it therein and returning it.
> >> >
> >> > This also means the coalesce_vars_p flag in the var_map structure
looks
> >> > somewhat out-of-place.  That is, it looks you could do with many less
> >> > changes if you refactored what calls what slightly?  For example
> >> > the extra arg to gimple_can_coalesce_p looks unneeded.
> >> >
> >> > Just as a note I do have a CFG helper pending that computes RPO order
> >> > for SEME regions (attached).  loops are SEME regions, so your
RTYPE_SESE
> >> > is somewhat odd - I guess RTYPE_LOOP exists only because of the
> >> > convenience of passing in a loop * to the "constructor".  I'd rather
> >> > drop this region_type thing and always assume a SEME region - at
least
> >> > I didn't see anything in the patch that depends on any of the forms
> >> > apart from the initial BB gathering.
> >
> >> Hi Richard,
> >
> >> Thanks for reviewing.  I refactored tree-ssa-live.c and
> >> tree-ssa-coalesce.c following your comments.
> >> Basically I did following changes:
> >> 1) Remove region_type and only support loop region live range
computation.
> >>  Also I added one boolean field in var_map indicating whether we
> >> are computing
> >>  loop region live range or out-of-ssa.
> >> 2) Refactored create_outofssa_var_map into
> > create_coalesce_list_for_region and
> >>  populate_coalesce_list_for_outofssa.  Actually the original
> >> function name doesn't
> >>  quite make sense because it has nothing to do with var_map.
> >> 3) Hoist init_var_map up in call stack.  Now it's called by caller
> >> (out-of-ssa or live range)
> >>  and the returned var_map is passed to coalesce_* stuff.
> >> 4) Move global functions to tree-outof-ssa.c and make them static.
> >> 5) Save/restore flag_tree_coalesce_vars in order to avoid updating
> >> checks on the flag.
> >
> >> So how is this one?  Patch attached.
> >
> > A lot better.  Few things I noticed:
> >
> > +  map->bmp_bbs = BITMAP_ALLOC (NULL);
> >
> > use a bitmap_head member and bitmap_initialize ().
> >
> > +  map->vec_bbs = new vec ();
> >
> > use a vec<> member and map->vec_bbs = vNULL;
> >
> > Both changes remove an unnecessary indirection.
> >
> > +  map->outofssa_p = true;
> > +  basic_block bb;
> > +  FOR_EACH_BB_FN (bb, cfun)
> > +   {
> > + bitmap_set_bit (map->bmp_bbs, bb->index);
> > + map->vec_bbs->safe_push (bb);
> > +   }
> >
> > I think you can avoid populating the bitmap and return
> > true unconditionally for outofssa_p in the contains function?
> > Ah, you already do - so why populate the bitmap?
> >
> > +/* Return TRUE if region of the MAP contains basic block BB.  */
> > +
> > +inline bool
> > +region_contains_p (var_map map, basic_block bb)
> > +{
> > +  if (bb == ENTRY_BLOCK_PTR_FOR_FN (cfun)
> > +  || bb == EXIT_BLOCK_PTR_FOR_FN (cfun))
> > +return false;
> > +
> > +  if (map->outofssa_p)
> > +return true;
> > +
> > +  return bitmap_bit_p (map->bmp_bbs, bb->index);
> >
> > the entry/exit block check should be conditional in map->outofssa_p
> > but I think we should never get the function called with those args
> > so we can as well use a gcc_checking_assert ()?
> >
> > I think as followup we should try to get a BB order that
> > is more suited for the dataflow problem.  Btw, I was
> > thinking about adding anoter "visited" BB flag that is guaranteed to
> > be unset and free to be used by infrastructure.  So the bitmap
> > could be elided for a bb flag check (but we need to clear that flag
> > at the end of processing).  Not sure if it's worth to add a machinery
> > to dynamically assign pass-specific flags...  it would at least be
> > less error